Projects follow distinct phases:
- Basic requirements are collected
- Project plan and end date are established
- Development starts
- Projects track to the project plan
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 MissingClearly 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.
The Project is Incorrectly EstimatedThere 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 ProjectEven 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
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.
Not Changing the Deadline Leads to Worst PracticesWhether 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
SolutionsThere are only a few cures for the 'Are we there yet?' problem:
- IT management with the intestinal fortitude to hold out for the creation of proper work breakdown structures and formal estimates
- Proper requirement processes that yield complete, consistent, and concise requirements
- Proper change management processes to alter the project deadline when missing tasks and non-productive activities are encountered