Estimation is one of the most important components of project management. In my opinion it is second only to the creation of a work breakdown structure (WBS). Project schedule and costs are directly impacted by accuracy of the estimation. Whenever I bring up the subject of estimation as a topic of discussion, invariably someone will mention: “We typically end up underestimating the amount of time needed to complete tasks – especially unfamiliar tasks.”
In order to validate this I decided on embark on a bit of informal research on my own. I spoke with a number of people I know in the industry on their estimation process. The estimation process ranged from using informal methods to formal ones like COCOMO/COSYSMO and other parametric estimation tools. To summarize, here is the process that was followed:
- Create work breakdown structure (WBS)
- Estimate each task using whatever method their company uses
- Add safety to tasks to account for uncertainty
The one common theme that resonated was that everyone was reasonably confident that the tasks would be finished on time. After all, they did add safety to tasks to account for variation. So if we had safety protecting the tasks, why then do we not finish projects on time? Before we look at answering this question, let’s briefly look at the principle behind Theory of Constraints.
Theory of Constraints
We all know that the weakness of any chain is its weakest link. A chain will have ONE and only ONE weakest link. Strengthen the weakest link and you have strengthened the entire chain. Strengthening the non-weakest links is not going to help strengthen the chain. This is the principle behind Theory of Constraints (introduced by Eli Goldratt). This principle behind theory of constraints has been applied in manufacturing with tremendous success. Of late, this principle has also found success in project management (critical chain project management), retailing, healthcare and other service industries. Our focus will be on applying these principles to project management.
A project may be considered a chain – a set of dependent tasks all linked together in time. The goal of a chain is to ensure it can carry a certain rated capacity. Similarly the goal of a project is to help the business save money or increase revenue. The earlier the project can do that the better. So for project managers the goal of a project is to complete the project on time and on budget while all the agreed upon deliverables. What then would be the project constraint?
The critical path. If tasks on the critical path are late, the project will be late. The critical path, however, assumes resources will be available when needed. This is a wrong assumption, especially in a matrix organizational structure. Moreover, the critical path is typically constructed with estimates that have safety built into each task. A project critical path created with estimates that have safety built into each task will most likely be delivered late.
Issues with Task Estimation in Projects
The adjacent image shows the probability distribution curve of a task. This curve is plotted using time completion of just one task – the X-axis being the time it takes to complete the work and the Y-axis being the probability of completing the task at a certain time. This curve represents all the variation that could occur and will impact the task completion time.
The task cannot be completed before a minimum amount of time – this is marked in the graph shown as “Minimum”. At a certain point in time after the “Minimum” time, is an “Aggressive but possible time” at which the task could be completed. This also has a higher probability of completion. The curve then tapers off and theoretically does not reach a zero time since there may be times when a task may not be completed. However, somewhere after the “Aggressive but possible” time is an estimate that we provide for tasks. This is marked as “Highly Probable” in the graph. So far so good?
Just to remind you that this is just one task that we have repeatedly completed to get the above estimation curve. The fact that we get a bell shaped curve suggests that the same task cannot just have one completion time. There is a range of possibilities when the task will be completed. A lot of factors cause this variation. While we are not going to discuss the causes of the variation, I would like to point out that we cannot eliminate or even significantly reduce the sources of variation in IT projects. It’s an exercise in futility.
Now, going back to the above task, we can conclude that 50% of the time the task will complete before the median time and 50% of the time the task will be completed after the median time. As a refresher, a Median is a statistical value separating a higher and lower halves of a sample. The median will be at the centerpoint (i.e. center of time) of the Minimum and Highly Probable times. The Median is shown by the vertical line in the graph.
Let’s use an example. Assume the Highly Probable time to complete the task is 10 days and the Median is 5 days. This means that 50% of the time the task will complete in less than 5 days while for the remaining 50% of the time, the task will complete in greater than 5 days. Given this background, what estimate will you provide? Will you say 5 days or 10 days? If you are like most people, then you will play it safe and provide an estimate of 10 days for this task. In your mind this task has a 5 day buffer or safety.
Now imagine the estimates you provide your project manager. If your organization does not use any formal estimation tools, chances are that you will provide an estimate based on your worst past experience. This means that you will take into account all the disruptions that will happen to you along the way, your experience about how complete the requirements are, level of multitasking, etc., collectively defined as “Disruptions”. The greater these “disruptions” are in your experience, the higher the safety added to the task. Even if your organization uses a formal estimation tool, you will fight to embed safety into tasks based on your experience.
Now that you have your buffer, do you aim to work as fast as possible to complete the task? Again, if you are like most people, you will not. This is called Student Syndrome. I remember, when at University, we used to negotiate aggressively with our professors to extend deadlines on assignments. On achieving the extension, I did not immediately get to work on the assignment the same day. I procrastinated with the assignment (or paced myself accordingly) to ensure that I completed the assignment on the day it was to be submitted. Most times it was a scramble to complete them on time, even though we had negotiated significant safety time.
Student Syndrome is alive and kicking in projects too. Remember we all know when the task is to be completed. We allow ourselves to be “disrupted” (often it is not a choice) and we often scramble to complete tasks even with our safety built into the tasks. In order words, we consume all the safety upfront. And when we scramble, we then conclude that we underestimated the effort it will take to complete the task.
Here is an important lesson: If you add safety to every task, Student Syndrome will typically kick in and consume all safety upfront leaving you to scramble at the end.
If we believe that e have underestimated the effort then we will add more safety in future estimates. We then scramble again. This is a vicious cycle. In addition to Student Syndrome, Parkinson’s Law states that work will expand to fill the time allocated. Think about this. In your organization, are there rewards to completing tasks early? Or are there penalties to completing tasks late? If there is no motivation to complete tasks early, why would you report early completion of tasks? The first time you report an early completion, your manager is going to be happy. Report it a second time and you raise suspicion. Do it the third time and your project manager is going to cut your estimates. So you stop reporting early finishes or pace yourself so that you only finish on the due date. So projects get hurt with late task completion, but never benefit from early task completion.
Another important lesson: Projects do not benefit from early completion but are penalized for late completion. Parkinson’s Law kicks in to ensure work expands to fill the allocated time.
One more thing on adding safety to each task. You are probably aware that, the sum of local optimals is not equal to the global optimum. If you agree to this statement, then you will also have to agree that protecting each task on a project (local optima) does not protect the overall project (global optima).
Issues other than estimation
There are two other issues that I want to briefly touch upon that harms projects. One is Multitasking and the other is your Measurement System. Multitasking is a myth – there is no such thing as multitasking. Not focusing on tasks that need to be completed is also a big reason why projects are late.
Most project measurement systems are lagging indicators. What we need is a leading indicator to show if a project will be in trouble. If you are using Scrum you are probably using burn down charts and this is a reasonably good leading indicator.
To summarize, a combination of Parkinson’s Law, Student Syndrome, Multitasking and Measurement systems with lagging indicators are significant factors to project delays. Other factors like incorrect requirements, scope creep, etc. just compound this mess. Critical Chain Project Management provides a solution to the above problems. I’ll discuss that in detail in the next post.