Are We There Yet?

We associate "are we there yet?" with kids asking incessantly if a long trip is almost over.  It is generally funny, however, it is less funny on a project that should be complete; it is even less funny if it is your project.

Projects follow distinct phases:

1. Basic requirements are collected
2. Project plan and end date are established
3. Development starts
4. Projects track to the project plan

Often, tasks start off well until they all level off at 90-95% complete and get stuck.  Management was satisfied with progress until the project stalls, they see frantic activity picking up and they start asking  "are we there yet?."

Like a family vacation, this trip is sometimes not even close to being finished.  You  expect that if 9,000 hours have been spent on a project estimated at 10,000 hours that you would be 90% done.

Surprisingly this is not the case for 7 projects out of 10 -- have you ever worked on a project where a 90% complete project plan meant the project was 90% done?

Project Plans can give the Illusion of Control

 Estimating project completion using the project plan is valid if there is a direct correlation between the project goal and the project plan. You often discover that the goal and the plan differ late in a project. Project plans and results differ because:

• Requirements and tasks are missing
• The project is incorrectly estimated
• Work is performed on tasks that do not advance the project

Requirements and Tasks are Missing

Clearly missing requirements mean that more work will be necessary to get to the goal, but the time for this work is rarely added to the project deadline.

A relative of missing requirements is missing tasks, this occurs when the work breakdown structure is incomplete and more subtasks are necessary to complete a task than estimated.

In both cases, if there are 2,000 hours of missing requirements and tasks then a project initially forecasted for 10,000 hours should move the deadline to 11,000 hours.  Therefore if 9,000 hours are done then you are only 75% complete.

Project plans that show 90% complete when there are 20% of the tasks and requirements missing are really 75% complete.

Unfortunately, weak IT leadership, internal politics, and embarrassment over  poor estimates will not move the deadline and teams will have pressure put on them by overbearing senior executives to get to the original deadline even though that is not possible.

The Project is Incorrectly Estimated

There is much literature about how accurate estimates are possible and necessary to successful projects. Weak and uniformed IT leadership will cave in to senior management demands for project deadlines without formal estimates.

A typical CEO and VP Engineering interaction looks as follows:

CEO: We need feature X, how much will it cost and how long will it take to built?

VP Engineering: Well we need to define feature X properly, see how it will be implemented, determine if we have the necessary skill sets, and see what the impact to our other operations will be.  It will take time to do do this work.

CEO: We don't have time for formal estimates.  How hard can it be to add feature X?  By next Friday, I will need a ballpark estimate for time and cost.

VP Engineering: I'll see what I can come up with for next week.

Weak IT executives allow themselves to be bullied all the time by other executives that have no idea what is involved in IT projects.  The end result is an underspecified project that will be underestimated in time and cost (see Why Executive Declared Deadlines lead to Disaster)

The more inaccurate the requirements the more extra work there is to do to get to the target.  That is why short requirements processes lead to strongly shifting requirements and canceled projects (see Shift Happens).  In fact, the degree of requirements shift is equal to the chance of a project being canceled.

Work is Performed that Does Not Advance the Project

Even if a project is correctly specified, there are several activities that will be performed that will not advance the project:

• Some requirements can not be implemented as specified and time will be spent researching and implementing work arounds
• Some requirements will be ambiguously specified and be implemented incorrectly and need to be redone
• Some requirements will be inconsistent and require time and analysis to establish consistent requirements
• Infrastructure might need to be refactored when you discover that it will not support the code created later

Work executed on these activities will not advance your project and should not be counted in the total of completed hours.

So if 2,000 hours have been spent on activities that don't advance the project then if 9,000 hours have been done on a 10,000 hour project then you have really done 7,000 hours of the 10,000 hour project and you are only 70% done.

Project plans that show 90% complete when  20% has been spent on unproductive tasks are really 70% complete.

Unfortunately...

On projects you will have both missing tasks and unproductive activities.  So if 2,000 hours are unproductive and 2,000 hours are missing in a 10,000 hour project where 9,000 hours have been done then you have only done 7,000 hours on a 12,000 hour project you are only 58.3% done.

Project plans that show 90% complete when there are 20% missing requirements and 20% time spent unproductive tasks are really 53% complete.

Many of you have been in this situation before, you know that the project plan states that you are 90% done but you know that you are not even close to finishing the project.

 Not Changing the Deadline Leads to Worst Practices

Whether a project is off course because of missing activities or non-productive activities, not changing the project end date will lead to schedule pressure as the project advances and people slowly start to realize that you are not going to make it.

When it becomes clear that a project can't make it's original deadline many organizations will start common but deadly practices.  Excessive schedule pressure often leads to the following bad practices (see Stop It! No... Really stop it.):

• Friction within the team
• Friction amongst the managers
• Inadequate communication with  stakeholders
• Layoffs of key personnel

Solutions

There are only a few cures for the 'Are we there yet?' problem:

Intestinal Fortitude

1. IT management with the intestinal fortitude to hold out for the creation of proper work breakdown structures and formal estimates
2. Proper requirement processes that yield complete, consistent, and concise requirements
3. Proper change management processes to alter the project deadline when missing tasks and non-productive activities are encountered

Failure to comply with these 3 principles means that you will continue to be subject to chaotic environments where 7 out of 10 projects fail (see Executives: Understanding your Chances of a Successful Project)