How long should it take?

Observations on the practice of estimation

I had heard this story long time back. There was this gentleman visiting a historical fort situated in a small village. He was walking his way to the fort but unaware of how far the place was. On the way, he saw an old man sitting on the steps of his house soaking the morning sun and asked him “Baba (loose translation: the revered), how long will it take to reach the fort?” The old man remained silent. Assuming the old man to be hard of hearing, the visitor continued his walk. In about two minutes, the old man called him back and told that it might take him forty minutes. Looking at the nonplussed and almost angry expression on the visitor’s face, the old man added “Son, unless I know your pace, how would I be sure of the time you would take?”

I wish the many of us in the project management community had the same patience and wisdom which the old man had in this story, when it comes to estimating and scheduling.

Through this blog I wanted to bring out some prevalent mistakes in estimation and scheduling.

Inherent inaccuracy: All the project managers (and their supervisors and customers) know that by its very definition every project is unique. The very first slide in any project management training course would say this. But probably this realization is only at the intellectual level. None probably wants to accept the fact that along with uniqueness comes uncertainty which in turn leads to inaccuracy in estimation. Moreover, this inaccuracy cannot be wished away till you are actually done with all the activities.

Single value certain estimates: Given the inaccuracy, shouldn’t the estimates have a range. Say 20 staff days plus minus 5. Or 10 staff days at 10% accuracy. But usually there is no range specified. You get to see only single and certain values.

Two, all the work elements get the same treatment. There is no distinction made on the uncertainty of the work element and thereby higher or lower tolerances in the estimates.

Same productivity for all resources: When resources are allocated to work elements it is assumed that all the resources have the same productivity. This simplifies duration estimation to division of work estimation by the number of resources. But unless the resource is a machine, you cannot assume same productivity. In fact, human beings are notorious for having different productivity at different times in the project. Needless to add, there are differences in productivity across humans too.

Progressive elaboration not considered: As project progresses, accuracy of the estimates is expected to improve. During the concept phase there would be a wide spread say -50% to +75%. During the design phase the spread would narrow further to say -35% to +50%. This implies that the project schedule gets re-baselined at the start of every phase if not more frequently. But this rarely happens. Once a schedule is base lined at concept stage, it is cast in stone. No re-estimation, no base lining.

Single project finish date: For all the reasons mentioned till now, should not schedule show the project finish date as a date with a range. Say 14-Aug-2010 plus minus 5 days.

But this is rarely the case.

Variations not anticipated: All schedules depict interconnected activities. Variation in one activity has a cascading impact on the schedule. Variation in a dependency outside the scope of your project may also impact your schedule. This is again a well known fact, which largely gets ignored. There is an entire new approach to scheduling called Critical Chain Project Management (Goldratt) which takes care of statistical variations and interdependencies. Even without buying the add-ons for CCPM to their existing scheduling software, project managers can use the concepts of feed buffer and project buffer put under the control of the project manager. But this is rarely done.

No Plan B: Most of the projects have foreseen risks. There is an elaborate risk register containing risk description, mitigation plan, owner etc. But when it comes to plan B, project managers behave like the proverbial ostrich with its head buried in sand. Foreseen risks with high exposure should prompt the project manager to be ready with plan B which would control the damage done by the risk. But one rarely gets to see plan B. Most of the contingency plans talk of communication and escalation like “inform the management” or “inform the customer” in place of a plan B.

So much said and done in the practice of estimations, I will be eager to know your view and experience regarding this topic.