March 31, 2008 – Estimating Lessons Learned – Communicating the Results
Back in December my 1997 Plymouth Neon was totaled when someone rear-ended me, forcing my car into the next one. It is an odd feeling to look into your rearview mirror and know that the car behind you isn’t stopping.
The insurance company sent me a check for a whopping $2,545. To quantify that massive amount, they compiled an 18 page document comparing my car to similar vehicles using mileage adjustment, feature assessments and other data. All that information was their justification of my car’s estimated value.
Lesson 13 – Tell them where you got the numbers.
An estimate is a guess based on the approach, assumptions and constraints that make up your understanding of the project. Theoretically your team’s estimate has some basis in reality. The key is to communicate that reality to your key stakeholders without them asking what color the sky is on your planet. In Lesson 10 we said to “Document your reasoning.” Let’s look closer at what that means.
Begin with the planned approach for the project. Are you cloning an existing application or starting on a new platform? Will there be a proof of concept performed? Is a pilot phase part of the process? Will it be a “big bang” conversion or phased in over time? Laying out the approach sets the foundation for the numbers. Keep track of any concepts that don’t make it and why they were dropped for future reference.
For constraints, any discussion or thought process that includes can’t, shouldn’t, must, or similar words needs to be recorded and confirmed. If you are saying “we can’t X if they don’t Y” or “we must have Z” then put it down on paper and bring it up.
Assumptions are more difficult to call out. In our minds we see them as obviously true. The hard part is pulling them out for examination and making sure everyone agrees. These can be negative assumptions (any discussion or thought process that ends “we’re not doing that”) or positive (“Marketing will surely have the brochures ready by then”). You may assume they are out of scope but unless it is stated there’s the chance others may think it is in.
Document these and you won’t end up looking at your estimate and saying “what were we thinking?”
Lesson 14 – Email doesn’t cut it.
Schedule a meeting and present your estimate. Sending out an email and expecting a meaningful response isn’t going to cut it. Either face to face or via an on-line conference, you need to walk it through. Explain the Type of Estimate (link) and your confidence level. Recap the estimating process used.
This is your chance to review and verify the approach, assumptions and constraints used to generate the estimate. Make sure everyone is heading in the same direction. Save time and energy by identifying the differences and adjust course earlier in the process.
Had my insurance company simply sent me a check for my Neon, I would have been disappointed and resentful, causing me to switch companies. Because the agent walked me through the numbers I understood that they probably gave me more than it was worth.
Lesson 15 – It is still just an estimate.
In the end, however precisely thought out, meticulously defined and well communicated, it is still an estimate. Things change and assumptions are proven untrue, but with a solid estimate as at its base, your project will be off to a good start.
2 comments:
Hi,
In the world of government contracting, these are Basis of Estimates (BOE). By documenting where the number comes from and the starting number (cost, hours, etc), if should provide a better starting point where we can agree or disagree on how similar the things are.
Unfortunately, that percentage and the associated costs can be "adjusted" by management to the point of being unworkable.
Mike
Dept of Doing
It is BOE in the private sector, too. I'm also glad to hear we in the private sector are not alone in management changing it. I've always marvelled at how they can cut 10% with the stroke of a pen after we have agonized for weeks to create the estimate.
Post a Comment