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.

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 progress stall, they see frantic activity picking up and they wonder “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% project plan meant the project was 90% done?

Using a project plan to estimate completion is useful 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.

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 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?  But 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 cancelled projects (see Shift Happens).  In fact, the degree of requirements shift is equal to the chance of a project being cancelled.

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.

Not Changing the Deadline Leads to Bad 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:

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)