What did I do? I promised to deliver this project in three months and on a specific date to the whole senior staff. I know better! Never promise a single date; there are too many tasks, one right after another, each one with a high level of uncertainty. Too many things can go wrong. I’m bound to break my promise.
But, I promised anyway. My customers demanded it. What do I do now? As project managers, making promises is something we do all the time. The three main things we promise are:
-
- the project will deliver everything asked of it
- the budget will be controlled and not exceeded), and,
- the project will finish on a specific date.
Even if the project is delivered on the promised date, what is my confidence level that my two other important parameters––the budget and the full scope described in the specifications document––will also be found acceptable? I’m in a deep, dark hole.
My lack of confidence comes from knowing about the variability of one task (See blog post What So Interesting About a Single Task). For the smallest project element––a single task––there will be a difference between how long the task is planned to take to how long it will actually take. Variability is at the heart of every task in every project.
Dominoes
But, what happens when we string a series of tasks, with a lot of potential variability, together? Watching one task after another get checked off is a satisfying experience. It’s a lot like watching hundreds of Dominoes fall into a pretty pattern.
But, this project is made up of over 200 tasks. In many places in the project network, one task must finish before the next one can start. These tasks are in predecessor order, which means the first task must be completed before the second task can start. The second task must finish before the third task can start, and so on. Can we predict the effect of one task’s variability on the next? Yes, we can, up to a point.
The Dependency of Tasks
Theoretically, if a project has three tasks, each tasks is planned to take three days, the total planned duration is nine days. Let’s be generous and say that each three day task will finish on time only 50% of the time. What’s the chance that these three tasks will finish after nine days? Flip a coin for me.
If the three tasks finish after nine days, it means there was little to no effect of variability across the three tasks. But, a single task planned for three days rarely takes three days to finish. Why? There are many inputs to the planning of a single task, e.g., the tangible information used to complete the work, the task description itself, the resources required, the agreed upon success criteria, the risks involved, and the task duration estimate. Each of these elements are only known once the task is being worked or has been completed.
What if almost every aspect of the single task planning was underestimated?
For example, each planned three day task took only two days to complete. That’s a total duration of six days, not nine.
What if almost every aspect of the single task planning was overestimated?
For example, each planned three day task took four days to complete. That’s a total duration of 12 days, not nine.
What if almost every aspect of the single task planning was both underestimated and overestimated?
For example, one task took two days, and the other two tasks took four days. That’s a total of 10 days, not nine. For example, one task took one day, and the other two tasks took five days. That’s a total duration of 11 days, not nine.
It’s easy to talk yourself out of corner if your project is effected by fire, war, terrorist activity, strike, lockout, flood or natural catastrophe. Even if your project is not effected by these things, do you find yourself making a bigger deal out of even the smallest excuses when you have to explain why you are or are going to be late?
Summary of Task Dependency
Why did I give in and make a promise about the project’s due date? I could blame it on our customers who is looking to find a supplier who’s deliveries are on time, every time. We would get more business from them (as long as we don’t compromise on the product’s features, quality, customer service, lead-time or pricing). And, if we can sustain our on-time delivery reliability over the long term, our customers would begin to trust us again.
But, at the end of the day, I have a reputation for making good on my promises. This time, I’ve exceed my own inflated optimism. In a moment of cockiness and self promotion, I may have set myself up for failure before the project starts. I only have myself to blame.
To predict the actual duration of a single task is hard enough. To predict the actual duration of a many single tasks dependent on each other in a predecessor relationship is even harder.
One Way Out
In your projects how many single tasks are there? And, how many of these single tasks are where the successor tasks are dependent on the predecessor(s)?
I know there has to be a better way. But, what due date should I have promise? Generally, I try not too paint myself into this dark and lonely corner. If pressed, one way out is to give a range of dates, from the best case to the worst case. Your software may not support this, but try to figure it out. It’s the only way to avoid being disappointed and manage some self-respect.