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.

Isango8 - providing project management and accounting support for SMEs in the South and South West

Who’s who on a project

There are number of people on a project team that are vital to success - just like a football team playing without a goalkeeper if you leave one of these people out then you risk a failed project!

The Sponsor - Sometimes called 'The project owner' they take ultimate responsibility for the project. They will often kick it off, will present the business case to the board and provide the regular updates. Their job is to remove roadblocks, provide motivation and be the champion for the entire scheme. They set the tone and a good project sponsor is worth their weight in gold.

The Project Manager - An experienced project manager will be the person who plans and runs the project. They will help build the team and continue to provide controls over the budget and work packages on a say to day basis. They enact the sponsor and steering group's decisions an provide feedback and feedforward throughout the teams.

The Specialist - You'll need specialists in functional areas on your project teams. People like finance, operations, HR, payroll are all vital to getting the full picture to ensure that your system is correctly set up.

The Independent Consultant - Someone who has experience from prior projects and different industries. They can bring best practice information to the table and also stay on the side of the company by giving totally independent and unbiased advice.

The Software Consultant - Provided by the vendor company they bring the in depth knowledge of the project and information regarding specific requirements of the software. They will also provide the link between the project and the vendor company.

The Tester - Typically the project will employ people at all levels throughout the organisation and in all departments to make sure that the test system provided does what it says on the tin. They can also be utilised to spread communication to the wider user community about how the project is going,

The Stakeholder - People often think that stakeholders are just people in senior positions but that couldn't be further from the truth. A stakeholder is anyone that has any contact or interest in the system you are putting in. A stakeholder will usually be board members who may not use the system but will want to see a good return on investment, Staff members who will want a system that is easy to use, managers who will want to ensure that controls and reporting are robust, suppliers and clients who may well integrate with the system electronically through order placement and payment services and anyone else who comes into contact with your new software. Each company will have its own stakeholder list and it is always a good idea to think about how you will communicate with them before during and after the project.

If you need help with building your project team or you need an independent consultant or specialist then Call us now and we can talk over the options

Subscribe to Blog via Email

If you'd like to receive notification of our blog postings then sign up here

Information presentation – how to use groupings

Groupings and space

In this video we show how the way you group your data and your use of space affect how easy it is to read

By using these methods you can ensure that your information is much easier and quicker to read. Removing the need for fancy fonts, lines and graphics through the simple use of space.