|
Estimations in Project Management
Our Estimations and What Happen Next
But how do people make estimations? Why do all the activities, in projects or in our lives, take much longer then we originally estimated? Let’s analyze a simple hypothetical example that shows how we estimation is done, in this case a software development project. Let’s assume that a programmer is already familiar with the scope of the task, but has not done any estimates yet. Here is a conversation between the programmer and project manager at the launch meeting where they discusses a project activity:
“How long is it going to take to build this puppy” ,the project manager asks the programmer about the task.
“Abo-o-out … five days”, the programmer answers almost with a slight hesitation.
“Are you sure?”
“Yes, if everything goes well, it should take about five days”
A few hours later the project manager enters this information into the project schedule. As schedules go, it is a masterpiece. It has at least hundred of different tasks and a dozen milestones. Information about cost and resources is well defined and contingency time is added as needed. Even holidays, company meetings, and vacations are entered in to the scheduling software. The project manager prints the schedule and sticks it to the wall. He is enjoying his creation the same way artists might enjoy their new pictures. “We had a big rush and the end of our last project,” he thinks, “this time everything should be great.”
Now the project starts. Actually, it does not start on time because three programmers are busy cleaning up some problems from a previous project. Then there was a change in the requirements. When it was time to start the task discussed by project manager and the programmer, the project is already late by at least three days. The project schedule is in tatters ignored, everyone knows there is more realism in a Star Trek movie than the Gantt chart hanging on the wall.
Finally, after a delay of three days, the programmer is ready to work on his task. He recalls his original estimate. “I should be able to do it in five days, maybe even faster,” he thinks. However, on Monday, he does start coding as he tries to understand the scope of the problem. By the end of the day, he realizes that he doesn’t have a clue how to start even though originally everything looked very straightforward. Tuesday, he spends the entire day learning about the new programming tools that he must use. Wednesday starts off with a fire drill and he spends an hour in the parking lot. After that, he spends a few hours on the phone answering questions regarding a previous project. Still he manages to begin coding. At this point, her realizes that that the volume of work required is much larger than he had anticipated. Throw in donut day on Friday, which is slow at the best of times, and our programmer has already burned through his original estimate.
The following Monday the programmer talks to the project manager.
“Everything is almost ready. I had some delays as I had to learn a new tool, but now all of the problems are resolved,” the programmer reports during the meeting. (“Almost” means about half of the work in IT language. The project manager knows about it, but prefers to ignore it; he doesn’t have a choice). After resolving few major issues and working on some issues that were discovered the previous week, the programmer finally completes the task on Friday .One week longer than the original estimate. The good news for project manager is that this task is not on the critical path. The bad news is that other tasks on the critical path have suffered the same
fate.
At this point, the project is delayed by at least one month. Contingency time has evaporated even after dropping few items from the list of features, it will still be difficult to release the product on time. Fortunately, the project manager knows where he can find more contingency time: testing and documentation. Testing is compressed to three days instead of three weeks, who needs testing when you have expert developers and documentation, well nobody reads it anyway.
Software projects very rarely fail completely or get canceled. Often releases are delayed or released with “quality and usability issues.” In the software world, this means that it will work, but not completely as planned – if it was a car, it might not have headlights and would occasionally shift into reverse when you turned on the windshield wipers. Customers may complain, but in most cases, the software will not be used as extensively as it was planned. It becomes “shelfware.”
This is the end of our saga, which started with a poor estimate and the creation an of unrealistic project schedule and ended ignominiously. Now, let’s try to understand how these mistakes were made. The root of the problem is in human psychology, which we will try analyze first.
|
solutions