Estimation Depends On…

I taught my estimation workshop twice last week and once the week before, and one thing remains true: Estimation depends on the project lifecycle, how the project is organized, the state of the requirements, and the number of people you have available.

I used a number of simulations to help people see how to estimate, and I noticed a number of interesting effects:

  • In the public workshops, people were more willing to experiment and live with a different lifecycle for a simulation (a more concurrent lifecycle, or an iterative or incremental approach)
  • In the on-site workshops, the participants recreated their environment, even when they said they wanted to try something new. Goes to show you how difficult it is to change.
  • Relative sizing is a great way to account for the difference in capabilities when you don’t have specialists or people with subject matter expertise. (“A 2 for this group is more time than a 2 if we had a so-and-so.”)

I encouraged people to try incremental and agile approaches to their projects in the workshop. The participants agreed that the approaches provided faster results, and still were concerned that they would not be able to implement those approaches at work. Some of the people were so accustomed to not having enough people, that even when I asked, “How many people for how long?” they could only assume they had access to the other one or two people in their small groups, even though we had 20 people in the room.

Yes, we encountered Parkinson’s Law (work expands to fill the time allotted), which is why I timeboxed the estimation time. “But we need more time for estimation!” “Do you get that time from your managers?” “No.” “So, maybe you can try some other approaches to make your estimates better in a shorter period of time?”

We discovered that non-functional requirements are more difficult to estimate than user stories or even use cases. And, it still amazed me that people are given broad brush requirements, and are then supposed to generate an accurate estimate (within 10%) with such little data. Yes, we talked about ways to iterate on your estimate to refine it. Will their managers listen? I don’t know.

We even had an opportunity to test out my claim: Multitasking nullifies all estimates. It never fails, when I teach an on-site workshop, some people think their work is more important than the workshop. Maybe it is. But I do know that when they leave and arrive and leave and arrive, it mimics what they do at work, and slows down their project. Because I break everyone into parallel groups, when they return, they can see the effect of their in-and-out behavior on their project.

When you estimate, make sure you think about how the project is organized, how many people you need when, and what information the requirements provide. Then show a confidence graph or a three-point estimate to explain how the estimate is really a guess, but a good guess, not a swag.

6 Replies to “Estimation Depends On…”

  1. I was in a course last week on proposal writing. Several people were in and out, in and out, in and out because they were (you guessed it) writing a proposal. Much of the class was about being organized and disciplined so that you could write a better proposal in less time without so much in and out in and out.

  2. As Yogi Berra said, “It’s hard to make predictions, especially about the future.” Estimates are just that, predictions about the future. They will be based largely on assumptions. To change our approach to estimating we must first change our assumptions about the future. I am not surprised that this is difficult to do in an in house training session. If you took people off site and took away their cellphone, blackberry, email access during the course you might more closely match the results of a public course.

    We are good at estimating what we know and not very good at estimating what we don’t know. If the project life cycle, the project organization, etc., allow us to know more, then they will make our estimating easier and our estimates more useful.

    As you have pointed out elsewhere, estimating is useless without timely feedback on actual performance against estimates and appropriate adjustments when actual performance does not match estimates.

    A fascinating topic.

  3. I’m a Project Manager and I use a very nice estimating tool that is in the market today which is CostXpert. I use the results I get from this software as a guide on how long and how much a new project would cost. And then we use Agile as our methodology. So far after using it for almost 2 years, together with Agile, most of my projects are on time (Well for my company’s part. Delays due to the customers are another story.). Hope this helps.

Leave a Reply