12 principles of estimation best practice

Estimating is a key skill in ERP implementation projects. It’s vital to get a clear sight of how much your project is going to cost and how long it will take but what are the best practices for this vital skill?

Magne Jorgensen produced the top 12 estimating best practices and I’ve taken these and added in some of my real world experience and suggestions as to how you can manage the process.

(1) evaluate estimation accuracy, but avoid high evaluation pressure – Studies have shown that giving people a bonus or basing their appraisals on a good estimation track record actually decreases their ability and accuracy. Treat the estimation process as a collaborative effort and you’ll get better accuracy and a happier, more committed team.

(2) avoid conflicting estimation goals – It seems an obvious one but telling your analyst that you need a supremely accurate cost and then telling them that it mustn’t come in over X will make their work less reliable. Go for accuracy and not political expediency.

Thomsett (1996) gives an excellent example in his ‘software estimation game’

Boss: Hi, Mary. How long do you think it will take
to add some customer enquiry screens to the Aardvark
System?
Mary: Gee . . . I guess about six weeks or so.
Boss: WHAAT?!!!! That long?!!! You’re joking, right?
Mary: Oh! Sorry. It could be done perhaps in four
weeks . . .

We’ve all been there right?

(3) ask the estimators to justify and criticize their estimates – Very often a firm will have a culture of perfection and not being able to admit mistakes. In a project environment this is often disastrous. The truth is that any cost prediction will have shortcomings. Ask your estimator what these are and then take a view as to whether you mitigate or look for more information.

(4) avoid irrelevant and unreliable estimation information – Sometimes people include information in their estimate that is unreliable purely because they have nothing better to go on. The truth is you are better off understanding that there is no data rather than basing a decision on something that could be misleading.

(5) use documented data from previous development tasks – If you’ve done work in the area before, or even if you had a project in the company that wasn’t the same you can still use the lessons learned documentation to inform your estimates for the new project. You did do a lessons learned document didn’t you?

(6) find estimation experts with relevant domain background and good estimation records – Music to my ears. Get in an expert even if it is only to help with estimation. Studies show that experience of the software you are putting in is great but across a number of different platforms is even better.

(7) Estimate top-down and bottom-up, independently of each other – Don’t let the golden idea of how long a project should take affect the bottom up process of analysing out how long each task will take. Do both completely separately and you’ll get a much clearer view of the likely cost/time implications.

(8) use estimation checklists – if your software provider or partner has a checklist then so much the better but if not then sit down at the start of the analysis phase and think about all the bases you want to cover. You can add things in along the way if you forget something but make sure by the time you get to the point of choosing your software that you have covered everything in your original list.

(9) combine estimates from different experts and estimation strategies – Two heads are better than one or put another way you want the most expertise from as many different areas and with as many different points of view as you can. Get them all together then aggregate to give you an overall view.

(10) assess the uncertainty of the estimate – The only thing you can be certain about is that there is a certain level of uncertainty (with thanks to Rowan Atkinson). Estimates are only a guide but what you can do is put numbers around key points of your forecast to give you an idea as to how risky the project is.

(11) provide feedback on estimation accuracy and development task relations – this goes to points 5 and 6. If you want to identify who in your organisation is a particularly good analyst of projects then you also need to be developing them. Feedback is a vital component in this. Similarly feedback into a lessons learned document the results of your estimate versus the actual costs. You are keeping a lessons learned document right?

(12) provide estimation training opportunities – as above really. Good experienced estimators have been shown to be much more useful than a statistical model but they have to come from somewhere so start getting people involved in projects. if you are paying an outside consultant to come in and do this for you then make sure you allocate an internal person to shadow them, learn and develop the skills for in-house use.

Using these best practices when producing your project estimates will help give you the confidence that you are on the right lines and produce a better outcome.

If you’d like some external help with producing a cost estimate for your project then please do contact us -we’d be happy to help

References:
Jorgensen. M., 2004. A review of studies on expert estimation of software development effort. Journal of Systems and Software, 70(1–2), pp. 37-60.
Thomsett, R., 1996. Double Dummy Spit and other estimating games.American Programmer 9 (6), 16–22.

Posted in ERP, Project management, Resources, Systems, Thought and tagged , , , , , , .