Several times recently I've been involved in discussions about project estimation, sometimes with project managers and other times in general conversation about project failure. Here is my opinion on why both duration and effort are important in estimation and neither can be ignored. This my personal opinion and every project and organisation may differ and should be treated appropriately by using the correct project management and software design methods.
Background on Project Failure
The UK National Audit Office summarises the common causes of project failure as:
NAO/OGC Common causes of project failure
1. Lack of clear link between the project and the organisation's key strategic priorities, including agreed measures of success.
2. Lack of clear senior management and ministerial ownership and leadership.
3. Lack of effective engagement with stakeholders.
4. Lack of skills and proven approach to project management and risk management.
5. Lack of understanding of and contact with the supply industry at senior levels in the organisation.
6. Evaluation of proposals driven by initial price rather than long term value for money (especially securing delivery of business benefits).
7. Too little attention to breaking development and implementation into manageable steps.
8. Inadequate resources and skills to deliver the total delivery portfolio.
I define project failure as one that either goes over budget, over schedule or both, or fails to deliver what the stakeholders actually expected. Most media attention focuses upon costs and timescale, and let's face it project failure is not isolated to IT projects - Wembly Stadium, 2012 Olympic Bid, the Millennium Dome were not IT projects. Until recently Heathrow Terminal 5 was hyped as the way to run projects (Agile), yes it may have been on time and on budget but in the end it failed to meet stakeholder expectations – the users of the terminal were far from happy and executives lost their jobs.
The importance of duration and effort in estimation
When I ask for estimates I always ask for two numbers the duration and effort – just so that it is clear to me how much the work is costing and how long it will take to deliver. When it's an external contractor I'm interested in duration and the bottom line cost not the effort, so this note applies to internal projects.
Effort is the direct cost of running the project and I would expect a project manager to be able to break down the estimate into deliverables/artifacts/tasks/function points – for me they are all the same, a quantifiable item of work. The quantifiable item of work can be listed in a Scrum burn-down list or an item in a project plan, but the project plan and burn-down need to take into account duration, more on this later. This effort provides the basis for future estimation for performing the same or similar piece of work. Using a well managed timesheet system enables project managers to make better estimates for future projects based upon projects of similar size, complexity, and industry type (OK it's not quite that simple but I'm not writing a thesis here).
The effort estimate will be affected by a number of factors e.g. sick, holiday, training, going to meetings not related to the project. All the daily tasks that an employee will be expected to undertake. This is what makes up the duration estimate of the project – the bottom line is "how productive is a person each day in your organisation". So if the effort to complete a project is 100 man days but an employee can only spend 80% of their time doing productive work then the duration is 120 125 days to deliver the project.
(UPDATE - Oops. Basic math error, should be 125 days.)
Estimating duration and effort means that a project can meet schedule and costs, but accurate estimation is only possible with historic data – which is why using accurate timesheet systems is needed.
Most people in software hate completing timesheets. I know this because I did when I used to cut code – it's an unnecessary distraction and stops you getting on with doing fun things like designing and writing software.
If there is to be any professionalism in software engineering then developers and testers etc need to understand the importance of estimation. The problem is that every time a developer enters 8 hours development time when they really worked 12 just sets false expectations for the project manager and stakeholders. The next time a project is estimated the project manager looks at the timesheets and thinks "if I pay for 2 hours overtime I can get more from my team" and the team end up working 14+ hour days. OK, nobody wants this and I firmly believe in the Agile 8 hour days – even if I don't apply what I preach, but the responsibility lies with everyone on a project to ensure effective project estimation.
Applying the appropriate estimation
At Altio PRINCE and Agile (Scrum) techniques are used to deliver projects. PRINCE provides the control and communication, the use of burn-down charts and daily meetings ensure project duration and deliverables are constantly monitored.
Effort estimates are used to calculate cost and this is where it is important that staff book their time accurately otherwise a project can fail on cost because staff spent most of their time on work that was not project related and so should have booked their time accurately (and I do draw the line at having a "Rest Room" or "Cigarette Break" task). For Altio projects we use several estimation technique – the simplest being a spreadsheet that applies triangulation estimation using best, most likely and worst case scenarios.
A project manager then takes the estimated effort and populates a project plan with tasks and adjusts staff availability to get a duration.
To monitor a project in progress then duration is important and using burn-down charts with staff providing daily estimates of how long it will take to deliver being the key. This estimate by the team members is pure duration, if the person is only managing to work 2 hours a day and there is 10 hours of work left, then the duration is 5 days. It's down to the project manager to manage why the person is only doing 2 hours a day and to manage the risks that this dilution of work effort causes.
Constantly changing estimates
It is important to constantly review project in progress and adjust estimates based upon knowledge from previous projects and deliveries. Using PRINCE gateways as the time to re-estimate is important, as it is the time to provide the details to the stakeholders for them to make decisions.
Conclusion
There are lots of debates online about project estimation and ultimately every project will be different because of the people working on it, the technology being used and the expectations of the stakeholders.
Software projects are all about developing new and innovative systems otherwise we would just buy the most appropriate product off the shelf. This means there is no blue print for accurate software estimation – software engineers are not laying bricks to build a house so there is no way to say how many bricks per hour a person can lay and apply that to all projects (the analogy being lines of code = bricks).
REFERENCES
Listed below are a number of useful links and documents that I use for reference.
- http://www.itprojectestimation.com/estrefs.htm
- The Holy Grail of project management success, http://www.bcs.org/server.php?show=ConWebDoc.8418 accessed March 2007
- Wembley Stadium Project Management, http://www.bcs.org/server.php?show=ConWebDoc.3587, accessed March 2007
- Olympic bid estimates, http://www.telegraph.co.uk/sport/main.jhtml?xml=/sport/2007/02/08/solond08.xml, accessed March 2007
- UK Government PostNote on NHS Project Failure, http://www.parliament.uk/documents/upload/POSTpn214.pdf, access March 2007
- UK Government Post Note on IT Project Failures, http://www.parliament.uk/post/pn200.pdf, accessed March 2007
- Project Failure down to lack of quality, http://www.bcs.org/server.php?show=ConWebDoc.9875 , accessed March 2007
- Steve McConnell, Rapid Development, Microsoft Press,1996
- Martyn Ould, Managing Software Quality and Business Risk, Wiley,1999
- Art, Science and Software Engineering, http://www.construx.com/Page.aspx?hid=1202 , Accessed October 2006
- Simple and sophisticated is the recipe for Marks' success, Project Manager Today, page 4, March 2007
- Ian Sommerville, Software Engineering 8th Edition, Addison Wesley, 2007
- Barbara C. McNurlin & Ralph H. Sprague, Information Systems Management in Practice 7th Edition, Pearson, 2004
- Overview of Prince 2, http://www.ogc.gov.uk/methods_prince_2.asp, Accessed November 2006
- The New Methodology, http://www.martinfowler.com/articles/newMethodology.html, Accessed October 2006
- The Register – IT Project Failure is Rampant http://www.theregister.co.uk/2002/11/26/it_project_failure_is_rampant/, accessed October 2006
- Computing Magazine – Buck Passing Route of Project Downtime http://www.computing.co.uk/itweek/news/2183855/buck-passing-root-downtime, accessed February 2007
- National Audit Office – Delivering Successful IT Projects http://www.nao.org.uk/publications/nao_reports/06-07/060733es.htm, accessed March 2007
- Successful IT: Modernising Government in Action, UK Cabinet Office, page 21
- Project success: the contribution of the project manager, Project Manager Today, page 10, March 2007
- Project success: success factors, Project Manager Today, page 14, February 2007
- Six Sigma Estimation http://software.isixsigma.com/library/content/c030514a.asp , accessed October 2006
- Analogy estimation http://www-128.ibm.com/developerworks/rational/library/4772.html, accessed January 2007
- Symons MKII Function Point Estimation http://www.measuresw.com/services/tools/fsm_mk2.html, accessed March 2007
- COCOMO estimation http://sunset.usc.edu/research/COCOMOII/ accessed January 2007
3 comments:
you might also want to visit this site about employee background
You describe a project failure as one that has been underestimated in terms of money and time Gary, but what about the rare occasions where a project is overestimated? Where it comes in way earlier than predicted? At what point do you define a project a failure? Particularly an internal one, I suppose an overestimated external project is almost always a success as long as the client is happy.
Tom, I agree that a project that is over estimated can be a failure. I have a general rule that a project that is 20% under or over budget has been well run (to be honest 20% still isn't great). But an overestimated project that is delivered earlier has less of an impact, unless the organisation is really fine tuned, and most are not.
Collaborating on Project Success Provides a good description of success criteria.
Post a Comment