Tuesday, April 29, 2008

Planning to Fail

I'll be honest, I kind of suck as a Project Manager, (sorry, Dawn, but you've already hired me!!!!)  My problem lies around the attention to detail that a Project Manager needs.  When coming up with a project plan they need to ensure that all tasks for the project are actually accounted for in the project plan.  Having come from a large consulting company that part was actually made a lot easier by using a standard template that had all possible tasks and you actually remove the things you wouldn't be doing in this project.  (Removing things is a lot easier than adding things.)  By adding in some default assumptions about the size and complexity of the application, viola, out came a project plan.

The next step is assigning people to tasks.  This is where 90% of project managers make the biggest mistake.  If you have 80 hours worth of work and you have a person who works 8 hours a day, how long will it take to do the 80 hours of work?  If your answer was 10 days, congratulations, you are part of the 90%.  If you said something else, you knew it was a trick question and you decided to play games with me, so consider yourself part of the 90% as well.

Contingency.  Nothing is perfect.  No task is perfectly timed.  You plan for the unknown.  You plan for things that you can't forecast.  You add a certain percentage of the task time as contingency.  This is essentially a slush bucket of time to fix things or redo things that you didn't know you would have to do when you originally scheduled the task.

Sick Days.  While this 80 hours of work may not intersect with an employee being sick the longer the project is the more likely you are going to have sick employees.  Indeed, depending upon which survey you agree with the number of sick days per year for IT workers varies considerably, but probably averages out to about 1 day for every 25 to 30 days worked.  Some people try to cover sick days under contingency while others have a separate category for it.  (If the project is long enough, consider accounting for vacation time for all staff as well as support personnel.)

Miscellaneous Project Time.  Let's not forget about the fact that you are sending emails to this employee that he has to read (skipping development), or that he needs to attend a project meeting or fill out a project report, all of which is "non-productive" time.  Indeed, non-project time can be a considerable amount of time.

Longer hours = less productivity.  Studies have shown that for short periods of time, one to two weeks maximum, people can work longer hours without decreasing their hourly productivity.  After that, however, their productivity hits a rapid decline.  I worked on a project where 55 hour weeks were mandated.  After a couple of weeks of this they got just as much productivity out of people as they would have if a 40 hour week was enforced.

So, how long will it take for 80 hours of work to be done?  11.75 days +/- 1.4 days

How many days are going to be in the project plan?  10 days.  We're already off to a bad start and the project hasn't even began.  No wonder people dislike project plans or even planning in general.  You're already in trouble and you haven't even started.

No comments: