Practical Effort Estimation
Once you have convinced senior management to back your project in principle, they are typically interested in the big questions of ‘how long will it take?’ and ‘how much will it cost?’. When you set out to answer those questions you are effectively making a prediction, or if the prediction is informed by a repeatable and credible method, an estimate. The reality of effort estimation is that it is difficult, it is seldom done rigorously and it is often the source of frustration and the foundation of failure.
Project governance is the activity that results in an external view of project progress for the consumption of management. Actual progress can only be measured against some expectation of predicted progress. Prior to the outset of project ‘kick-off’ the activity of effort estimation provides the milestones of predicted progress against which actual progress will be measured. Therefore, effort estimation is an integral part of project governance. At the outset of a project, the estimate is liable to be less reliable, and as time goes on it becomes more reliable because more information is available. The question must be ‘is it possible to implement a repeatable effort estimation process that is founded on sound, lightweight, and achievable principles that is tolerably accurate from the outset and which can be refined over time to become increasingly accurate?’
The recent DSDM Atern booklet on estimation by Osborne and Fazackerley makes for a readable and concise introduction to the subject of effort estimation. A quick summary of the approaches can be understood to include:
- Analogy: find a project you have done similar to the project under consideration. Determine how long the last project took, factor in the differences, the learning, the elements that are reusable and produce an estimate. Often expert judgement is cited as a separate method, but this seems identical to analogy, as an expert is required to create the analogy. The problem is that each expert does the estimate differently and arrives at different results so it is not much use in a systemic approach.
- Decomposition: break the project up into its constituent parts (analysis, design etc.) and then estimate the constituent parts. This suffers from the same limitation as analogy.
- Models such as COCOMO and Function Point Analysis (FPA). There is no evidence in the literature that these models are accurate and so they are not discussed in detail here. There is, however, a fundamental problem with these methods it is difficult to ignore. COCOMO is based on a prediction of lines of code that will feature in the final system. It is unclear how this might be determined prior to the system being complete, which rather defeats the purpose. FPA is based primarily on read/write cycles to the database which seems to suffer from the same limitation as COCOMO.
The Use Case Points Method (UCPM) was originated by Karner working on his Master’s thesis at the University of Oslo. He was greatly influenced by the work of Albrecht who came up with FPA. This is a criticism as the method suffers from being overly complex without the complexity necessarily adding any greater precision. This is not to say the UCPM is without merit, in fact it represents the basis of what can be considered the best approach to effort estimation, not least because it is an approach that features use cases. Use cases are at the heart of the PrinceLite doctrine that embraces the ability to produce unambiguous business requirements. (It is important to understand that an Agile ‘user story’ or a UML use case and its related scenarios are all related concepts. A user story can be understood as an informal use case.)
Page 1/2