Then there was also the suggestion of putting a big dashboard on the wall, with a list of task and due dates and assignees. Of course this is very visible and a great way for everyone to see what everyone else is doing, but takes time to manage, and it didn’t seem to make sense to me to lose time managing multiple tasks lists in different places. Of course, if I could have a projector that would take the team’s task list right out of our web based tool and display it on a wall, now THAT would be awesome.

So, what is the best way to make sure work gets done, without breathing down that team member’s back (and I’m sure we can all think of atleast one team member that needs this kind of ‘help’)?

1. Regular status or ‘stand-up’ meetings are good, keep them standing so that the meeting is quick and on track, and have each team member report:

• What s/he just finished
• What s/he will be working on next
• If there are any issues holding him/her back

2. A strong web based project management and collaboration system, so that all team members can see the online dashboard that lists all critical deadlines and tasks with their assignees. The collaboration system will keep all details in one place so nothing will get lost in email folders or scribbled notes. Team members should be able to log into their personalized dashboard and see their upcoming tasks with due dates, and also get regular email reminders of their upcoming tasks and due dates.

3. And sure, a little bit of walking around is good. Don’t get me wrong, I’m not against checking in one-on-one with team members, just having been micro-managed in the past I’d prefer to avoid creeping over to that dark side.

What have you done to keep your team members on track, especially the ones who need a little extra attention?

And I’ve also had an opportunity to work with many people who don’t like tracking their time, who feel like it’s a waste of energy or forget to do it until weeks or a month has passed, or just don’t know how to do it properly. It pains me to see people who just don’t get it, and it’s even more painful when it comes time to report on a project and the data is either not there or not reliable, then what is an honest project manager to do?

Well, rather then let things get that far, I wanted to talk about some of the anti-time-tracking personalities and what we can do to help them.

The Forgetful One: The person who just can’t seem to get it into his routine that time needs to be logged regularly. This person is not necessarily opposed to tracking time, just gets caught up in other things and never remembers to do it. When it comes time to catch up on all the days that time hasn’t been tracked, numbers or guessed or fudged and inevitably inaccurate.
How we can help:

• Setup a daily calendar event to help remind him to track time. Send a reminder email each morning asking him if he logged his time from the day before.
• Make sure the system is as easy to use and as accessible as possible (I love the LiquidPlanner task timer system, so easy!). Make sure logging to specific tasks is intuitive and can be done quickly and painlessly (better to get more detail on a task than just time logged as “programming”).
• Put a huge and really annoying alarm clock at his desk, set to go off at 5:30 every day to remind him to log time!

The “Ashamed” One: The person who puts in decent chunks of overtime, but is afraid to log his time for fear that it will look like he is too slow and it takes him too long to finish tasks. He knows what the target budget is, and doesn’t want to make the project ‘look bad’ by adding more of his overtime hours to it.
How we can help:
Oh, how these people put gray hairs on my head…

• Explain to him that he should never be embarrassed or afraid to report time worked on a task. The only way we can ever learn from a project and improve our estimates is to see actual time spent on each task and compare that with the original estimates made.
• Yes, the budget might go over, but this is a fact of life and not only should he not be afraid or feel responsible, he should be comfortable (and proud) to show the rest of the team that he is committed enough to put in the extra time when needed to get the work done.

The Close-Minded One: This is the person who just doesn’t see the point in logging time, she thinks it’s a huge burden and can not find any benefit in doing it. Who cares how long she spent programming a little feature or sitting in an internal meeting? She’s already wasting her time in the meeting, why lose more time recording it in her time sheet? She’ll leave her time sheet empty for as long as possible and then just make rough guesses when time comes to fill in the blanks, sometimes many weeks later.
How we can help:

• If you work at a client services agency and bill based on hours worked then explain the direct correlation between the hours she records, and the dollars we will be charging that client (which will then eventually get to her paycheck)
• Show her the reports from the last few projects, and show her actual hours logged vs initial estimates made. If there is a striking difference between any of those totals (which, I’m sure there can be) then maybe she will see the importance of seeing how long things actually took and then using this information to make a better budget next time. If we can justify bigger budgets, than maybe she’ll get a bigger bonus next time around!
• Losing too much time in unnecessary meetings? The only way we’ll be able to figure that out is by looking at people’s time sheets and reporting on billable vs non-billable time. Not that all meetings are unnecessary of course, but we all know that some of them can run a little long at times…

What types of personalities have you encountered, and what have you done to show them the light?

To summarize, a mosquito brags to an iguana that he spied a farmer digging yams as big as mosquitoes. The iguana says “I would rather be deaf than listen to such nonsense”, and puts sticks in his ears and heads off through the jungle. The friendly python says good morning to the iguana, but after getting no response from the iguana, assumes that he is plotting some mischief against him. The python then looks for the first place he can find to hide, and shoots into a rabbit hole. The rabbit sees the snake and gets frightened, and runs across the clearing. The crow saw the rabbit, and flew into the forest crying an alarm. A monkey hears the crow and leaps through the trees, accidentally killing a baby owl. When the mother owl returns to find one of her babies dead she is so shocked and distressed that she is unable to wake the sun each day with her hooting. The nights grow longer, and when the King Lion calls a meeting to get to the bottom of the situation, the chain of events is traced back to the source of all the trouble — the pesky mosquito. Finding the culprit satisfies the mother owl, who calls the sun back again. But, the mosquito is forever plagued with a guilty conscience, compelling him to forever be a pest.

I’d like to focus less on the mosquito who started it all, and more on the iguana and the pyton, and the other animals afterwards. When the iguana didn’t answer the python, the python thought that the iguana was plotting something evil against him. He then went to hide. The rabbit saw the python, she thought something was very wrong (and was scared of the python too) and scurried off. This continues, without anyone stopping to try to find out what was really wrong. Each animal just makes assumptions without asking any questions, and this ultimately leads to the death of a baby owl and prolonged darkness. Now, let’s believe the story and accept that animals talk to each other, the python did not try to find out what was really wrong with the iguana, and neither did any other animal afterwards. All went on assumptions without taking time to ask.

In the same way while working with a group on a project, it can be easy to make assumptions without asking more questions. This can easily lead a team member down the wrong path, resulting in wasted time and effort. People should not be afriad to ask questions of others in the group if there is something they do not understand, and the leader should always try to make information as crystal clear as possible. The sooner the misinformation is caught, the less damage that will be done, both in the real jungle…and the jungle that is your project.

Here is the description from the website:

Bob the Builder and his machine team are ready to tackle any project. As they hammer out the solutions that lead to a job well done, Bob and the Can-Do Crew demonstrate the power of positive-thinking, problem-solving, teamwork and follow-through. Most importantly, from start to finish, the team always shows that The Fun Is In Getting It Done!

What project manager wouldn’t love all of this? I mean, it sounds like the perfect project, doesn’t it?! Well, as anyone who’s seen one all the way through knows, not all projects go that perfectly.

So, Bob the Builder has this great catchy theme song that my (almost) 3 year old loves to walk around singing, title of the song is “Can We Fix It?“. The words repeated throughout the song are “Can we fix it? Yes, we can!” It’s inspiring and very cute, I encourage everyone to check out the video. So, we decided to mess with our 3 year old a bit and change the lyrics, but really we just wanted to teach her an important lesson in project management (obviously . Our version of the song is:

“Can we fix it? No we can’t!”, or “Can we fix it? Maybe tomorrow!”

Don’t get me wrong, I’m all about being a positive thinker and having a good attitude about getting the work done. But, I also believe in being a realist and have learned lessons the hard way about the importance of being honest about the status and condition of a project. If something is going to be late, make sure people know it or make sure there is a plan to adjust scope so that the critical deliverables can still be completed on time. If something just isn’t possible, make sure to raise the flag as soon as possible. Better to get the information out early than stay quiet on it or mask the problems, only to have a more serious blowup at the end.

So, I hope that my daughters learn positive thinking and the power of teamwork from Bob, but I also want to make sure they get the extra lesson in realistic thinking and honesty from their parents!

This past July, the New York Times ran the article, “No Doubts: Women are Better Managers.” It was an interview with Carol Smith, SVP and Chief Brand Officer for the Elle Group, the media company. She explained what she does to be a great manager and why women will always be better managers.

More on the LiquidPlanner blog >

No, this is not a commercial for a Prozac, it’s a story about how I got caught at an incredibly inefficient process at an IKEA one day and almost lost it. I was working on a bunk bed project, had bought a used IKEA bunk bed for my 4 year old and discovered happily at 1am while building it that it was missing alot of critical hardware. So, rather than chase down the seller who had probably already gotten packed up and moved out of the city, I decided to go to the nearest IKEA to get the parts replaced.

I showed up at the returns/spare parts line with the instruction manual for the bed I was trying to build, the pieces of hardware I had left and a list in my head of what I needed. I saw one of those typical scenes in a store, a huge line of people looking really frustrated and just one or two customer service people helping. Then, lots of other IKEA staff were wandering around, attending to other areas that were not as crowded. It’s the kindof thing that makes you want to scream…watching people wandering around looking like they have nothing else to do when there clearly are long lines that need to be helped. I thought about Brooks Law for a moment, and decided that in this type of project adding resources might cause a slight delay intially just to get people setup and going, but ultimately will definitely make things go faster.

And wait, there’s more!
We all had to pick a number and wait for it to be called, the line moved at a pretty steady (slow) pace but than at a certain point things sped up. The line almost breezed through the last 8 numbers before me and then behold, the two people right before me had a seriously huge cart of stuff to return. Not only was there a lot to return, but there were major complications with their items. It made me think about the idea that software project tasks are either 0% done or 100% done. It’s impossible to predict the exact amount of work that will be required to get something done, anyone who’s managed programmers before knows that they love to say they are 95% done for the last 90% of the project. You can only get a truly accurate estimate when the task has completed. In the meantime, stick to ranges.

As I sat there waiting and watching the clock tick, I figured I should use the time wisely and made sure I had an exact list of the parts I needed. So, it took 5 minutes and I got my list down. I wish some of the other people around me would have thought of the same thing. I couldn’t stand watching the people at the head of the line rifling through their papers, I thought if they had only taken a few minutes to plan before it was time for them to get to the top of the line they would have saved everyone else a lot of time.

So, I’m not saying I’m an expert and that all my projects launch perfectly with the time/budget/scope triangle balanced to a tee. I enjoy learning about how to improve what I do and how to incorporate the right processes that will make my projects more successful. When I spend a lot of my time learning how to make things run more smoothly, it just pains me to see disorganization and chaos in a place where I have no control over things. Yes, I guess I could be one of those people to shout at the customer service reps to move the line along or lecture the others in line to be more organized, but I just don’t swing that way.
I suffer in silence, and wait for the moment to pass (well, sometimes at least…)

As he started on the route, he had three deliveries to make. He guessed his way through and got all three deliveries wrong. When he got to the end of the route, he was told that the deliveries were wrong and he had to go back and bring all of the packages to the correct places. At this point he’s running out of time, so he rushes through the pickup and drop-off, and ends up losing & breaking packages. By the end of the day he’s very frustrated and the other engines are disappointed in him.

So the lessons learned here are pretty simple…

1. Never assume that you completely understand the task at hand. It might seem simple at first, but once you’re in the thick of it, questions might come up that you won’t be prepared to answer unless you have a full understanding of the task.
2. Don’t be afraid (or too proud) to ask for help. This doesn’t just happen to trains, people will sometimes have pride issues, too. Better to ask what might seem like a stupid question now than look even more foolish later.
3. Rushing doesn’t pay! What you gain in time you lose in quality.

Do you have any Edward trains on your project teams? Better make sure they watch this episode!

Let me tell the story….

Worried Walrus really wants to ride a bike, but is afraid he’ll fall off. He has a conversation with “Positive Pig” about why he’s worried…

“If I fall off, I’ll get hurt. Then I’ll have to go to the doctor. And I’ll need medicine orbandages….or…stitches! Ohhhh!”

To which Positive Pig replies, “That’s silly, bicycle riding is fun and there is no reason to worry.”

The Worried Walrus goes on, “An awful lot can go wrong. You have to steer and pedal and balance. You have to look out in front of you and on both sides and make sure nowone is behind you…and not go too fast…and use your brakes.”

Reading further, we understand why the Worried Walrus has his title, “…If I get hurt, they’ll have to take me to the hospital in an ambulance. I can see it now, there’s a traffic jam on Main Street. The ambulance get’s stuck…”

And he ends up in the middle of nowhere walking through the rain in a dark night, wet and hungry and looking for anyone who can help him.

I won’t give away the rest of the story, you should pick up the book and find out for yourself!

But, I think this is a great example of Risk Identification. This is the process of discovering, defining and documenting risks before they become a problem in a project. The way I see it, the more creative you can be about it, the better. The project team should sit down and brainstorm on all of the possible risks to the project and get them documented. The document should detail the risk, the severity, impact and contingency plan (here’s a sample Risk Management Worksheet from the Gantthead site). At regular intervals throughout the project the team should revisit these risks, add new ones and archive anything that is no longer a risk. I recommend reading “Waltzing With Bears: Managing Risk on Software Projects” to find out more about risk management.

The goal of this is not to be worried like the Worried Walrus. Actually the opposite, the more creative thinking you can do in the beginning of the project to identify and then manage the potential risks, the less stress you will have and more sleep you will get at night.

So, I tried to have this same discussion with my 2 and 4 year old after reading the book to them and well…maybe I’ll try again in a few more years.

Of course, looks like some have already failed. When I was checking out Webworker daily for posts about project management tools, I saw some great posts and then plenty of junk comments. I’m not saying that people shouldn’t promote their products, but tell me who you are, and give me some reasons why I might want to use your product. Don’t pretend to be a project manager making a recommendation, identify yourself and be open about promoting your product. One of the reasons why I made the post about my relationship with LiquidPlanner was to always have it handy to link back to when I was promoting LiquidPlanner and wanted to identify myself.

I think someone who strikes this balance really well is Charles Seybold from LiquidPlanner (and am I using this opportunity to promote them again? It probably looks like it, but I happened to like what he was doing before I had this whole arrangement with them anyway). His avatar is great, it’s got the LiquidPlanner logo in the background and his face in the foreground. He does the same thing in his contributions on Twitter, a mix of product promotion and other interesting stuff. I think more organizat

I’ve seen many blog posts and articles about how to successfully represent your brand or organization on Twitter and other social media. It’s a tricky balance and I don’t claim to have found the perfect solution. But at the very least, when you want to talk about your product on project management blogs or via contributions to #PMOT, let us know who you are and why your stuff is so good.