h1

Estimating

December 10, 2012

Estimating in any development or engineering environment is always a challenge. Whatever you do, it always end up with a guess.

You have a good system in place; one of your experts can estimate how long things will take and you are delivering on time, customers and management are happy. Then you get a process improvement / standard / model expert / appraiser / auditor come in and you are told that you need to establish a PBS and a WBS, document your assumptions, estimate the size and the complexity and the skills, document all of this and use a well documented model / procedure / methodology / tool to translate that into the estimate your expert made originally.
What is the added value? What is the benefit? Surely the model is wrong to require so much additional work for no value. It is obvious that this was developed for bureaucratic organizations (CMMI for the US Department of Defense, Prince2 for the British government…).

Or you have misunderstood the model.

The purpose of standards and models is generally twofold:

  1. 1. Guarantee: can I as a customer know that you have satisfied the minimum requirements to guarantee the level of quality I should be entitled to expect?
  2. 2. Lessons learnt: do you have enough traces of what was done in order to identify how to repeat success and avoid the same mistakes next time?

If you are good at estimating, the model / standard should allow you to demonstrate why you know that the estimates are correct, and it should help you identify how to share the secret knowledge of your expert to allow others to estimate just as effectively.

Many times, I have been told that estimates are based on “experience”, which I translate as meaning memory. First, you need to acknowledge that most of us are better at remembering nice things rather than the bad or realistic (remember how it always snowed at Christmas and it never rained in summer when you were a child?). I also like to point out that the people with the most experience are the ones whose memory tends to start failing. But, I am told, we have our best people do the estimating… You know how to recognize the best people in your organization? They are those who find it easiest to find a job elsewhere.

The other issue with your estimates is the difficulty in identifying the over-estimates. I estimate a job will take 100 days, I say it will take 200 days, management / customer argue and I get “negotiated” down to 175 days. I then deliver the result after 150 days: earlier than scheduled and under budget – everyone is happy, but can you say I estimated correctly? I underestimated by one third!

If you estimate correctly, whether you use models and historical data or not, you should acknowledge that, in the end, your estimate is going to be wrong, except incidentally. Estimating and forecasting is predicting the future and even a crystal ball will not help you for that (not a reference to the tool of that name, which has the potential to help effectively).
If you estimate correctly, you should not be afraid to measure, in detail, the actual time and effort required to do the work against your estimates. This need not be difficult, it can be done efficiently with a pen and paper. Going back over your estimates, you should find about 50% of over-estimates and 50% under-estimates. Also, you should find less than 5% to be more than 95% off.

Many organizations I visit tell me that they cannot estimate the detailed work of their managers but work with a statistical model which may state that project management is x% of the project effort (worse case) or that it is broken down into standard fractions of estimating, planning, reporting, meeting… (less bad). The idea that they should then monitor the detail of their work is abhorrent and reinforces the concept that we cannot plan because we don’t know what managers do all day. If they are not willing to measure the time they take over a variety of tasks, we shall never know how efficient they are or how to help them. Time and effort can effectively be measured using paper and pen, entered into a spreadsheet later.

It is only when you are comfortable with these measurements that you will be able to identify what the real problems are and focus an improvement programme on helping your staff and customers in real terms; and, when all is said and done, your main purpose should be to identify how you can learn lessons so as to continuously improve. The models and standards are not asking for bureaucracy, they are asking for enough traces of what was done and why so that lessons can be learned and shared. Documentation is not bureaucracy, it is communication.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: