Why Estimate Projects?
Estimation is an essential part of any project methodology. Estimation is used for a number of purposes:
This document describes the techniques of used to produce reliable estimates for the work required to complete projects and tasks.
A spreadsheet template for Three Point Estimation is available together with a Worked Example illustrating how the template is used in practice.
The best people to undertake estimation are the staff who are going to do the work. The staff chosen to produce an estimate are typically drawn from IS, customers and/or service partners who have relevant experience of similar previous projects or tasks in the business area.
Our estimation process is based on three components:
The estimates are validated through peer review and are backed up by an experienced Project Manager who takes overall responsibility for the total. Estimates are reviewed and updated throughout the project lifecycle. Estimates, and the processes followed to produce them, are transparent and consistent across all projects.
The Three Point Estimation technique is based on statistical methods, and in particular, the Normal distribution. Three Point Estimation is the preferred estimation technique for IS Applications projects. In Three Point Estimation we produce three figures for every estimate:
a = the best case estimate
m = the most likely estimate
b = the worst case estimate
These values are used to calculate an E value for the estimate and a Standard Deviation (SD) where:
E = (a + (4*m) + b) / 6
SD = (b - a)/6
E is a weighted average which takes into account both the most most optimistic and pessimistic estimates provided and SD measures the variability or uncertainty in the estimate.
To produce a project estimate the Project Manager:
We then use the E and SD values to convert the project estimates to Confidence Levels as follows:
IS Applications use the 95% Confidence Level for all project estimates.
A spreadsheet template for Three Point Estimation is available together with a Worked Example illustrating how the template is used in practice.
Base and Contingency is an alternative estimation technique to Three Point Estimation. It is less scientifically based and cannot be used to provide Confidence Levels. It can be a useful technique where there is less detail available on which to base the estimate.
In Base and Contingency estimation all estimates have two components the base and the contingency. The base is the minimum expected time required, i.e. when everything goes well. The contingency is the amount of trust placed on the base when risks are are taken into account and is generally expressed as a percentage of the base. A figure of 10% -20% contingency is a typical figure rising to 50% or even greater for more risky tasks. Separating the base and contingency makes the estimation task easier. We can derive a base figure without having to take into account everything that might go wrong and then use risk analysis to determine the appropriate level of contingency. The assumptions that underpin the base estimate are recorded and the contingency reflects the confidence we have that these assumptions are correct.
The Project Manager will also consider project wide risks and undertake a risk analysis to determine the correct amount of contingency to allow for them. These risks are recorded in the project Risk Register. The contingency is based on the maximum costs to the project of the risk occurring weighted by an assessment of how likely it is to occur expressed as a percentage. Project contingency may be estimated in terms of money, resources or a mixture of both. Resource contingency is managed by adding a factor to individual task estimates.
To produce a project estimate the Project Manager:
Using this technique the Project Manager must be careful to avoid double-counting, i.e. adding contingency to both the project and task estimates for the same risk.
Typically we will distinguish between the technical tasks of the project, for example code development or package configuration etc, and overhead tasks such as project management or infrastructure support. Each technical task will be individually estimated whilst the estimate for each overhead tasks can often be calculated on a pro-rata basis. Key factors which will influence estimates for technical tasks are:
Typical overhead tasks include:
Project experience suggests potentially useful rules of thumb for deriving initial estimates for various overhead tasks. These are provided in Table 1 below.
| Task | Rule Of Thumb |
| Project Management | The Project Manager should be assigned between 20 and 25% of the non project management time for a typical project. (This works well for projects up to 6 months duration for longer running projects please consider allowing an additional 1 day project management time for each working week beyond beyond 6 months) |
| Quality Assurance | Allow a figure of 5% of the overall project estimate for quality assurance. |
| Business Analysis | Allow a figure of 20% of the time allowed for the technical tasks to complete the business specification. |
| Systems Analysis and Design | Allow a figure of 25% of the time allowed for the technical tasks to complete the design specification. |
| Peer Testing | Allow a figure of 10% of the time allowed for the technical tasks. |
| Integration Testing | Allow a figure of 15% of the time allowed for the technical tasks. |
| Acceptance Testing | Allow a figure of 15% of the time allowed for the technical tasks. |
| Deployment | Allow a figure of 5% of the time allowed for the technical tasks. |
Table 1 Rules Of Thumb For Estimating Overhead Tasks
This approach simplifies estimation and can provide a useful cross check of the technical estimates. However it is perfectly acceptable for overhead tasks to be decomposed and estimated separately where the Project Manager feels that this is more appropriate.
The Project Manager should assemble an estimation team for the project. The estimation team will include the Project Manager and other technical experts from IS - chosen to reflect the staff who will actually do the work. The estimation team may also include representative project stakeholders including customers and service partners. Four or five staff in total is a reasonable estimation team size for most projects. The quality of the estimate will only be as good as the estimation team's knowledge of the project so it is vital that they collectively understand, as far possible, everything that is known about the project at the time that the estimate is produced.
The estimation team will generally have at least two meetings. The first of these meetings will:
This meeting should be attended by a customer stakeholder who will play a key role in discussions on functionality requirements, usability issues etc.
The second meeting will typically take place a few days later to finalise the estimate. It is important that each member of the team prepares their own estimate of the work involved ahead of this second meeting (Delphi Technique). This ensure every member of the team is fully prepared and reduces the risk of individuals having over-influencing the results of the process. This second meeting:
At this meeting the Project Manager may ask members of the estimation team to take a lead role in the discussions for particular tasks. For example, a senior member of the proposed development team may lead the review of coding task estimates by walking-through their estimate of the work involved. This meeting will continue, perhaps with further break outs, until consensus is reached on the estimates for all tasks. (Where "Base and Contingency" technique is being used the Project Manager will then lead discussions to determine the overall project contingency using the same consensus building techniques.)
Notes
The Project Manager will monitor estimates throughout the project. Experience gained from previous stages is used to update the task list and the corresponding estimates. Risks are reviewed and contingencies adjusted as appropriate. The revised estimates are reviewed as part of the sign off process at the end of each stage in the project methodology. Completed estimates are signed off by the Project Manager and key project stakeholders. This will typically be done as part of the stage sign off as indicated in Table 2 below:
| Project Methodology Stage | Deliverable | Requirement |
Initiation |
Project Proposal |
Estimates to be signed off by the Project Sponsor and Project Services Programme Manager Note: A single estimation team should be established for each business area programme for estimating proposals produced as part of the Annual Planning process. This will reduce the number of estimation meetings required and improve consistency of estimation within the programme. |
Planning |
TOR |
Revised estimates to be provided with TOR and signed off by Project Manager, Project Sponsor and IS Applications Management. |
Business Analysis |
Analysis Sign Off Review (PPAR) |
Revised estimates signed off as part of PPAR. |
Systems Analysis And Design |
Design Sign Off Review (PPDR) |
Revised estimates signed off as part of PPDR. |
Build |
Build Sign Off Review (PPBR) |
Revised estimates signed off as part of PPBR. |
Integration |
Integration Sign Off Review (PPIR) |
Revised estimates signed off as part of PPBR. |
Acceptance |
Acceptance Sign Off Review (ASOR) |
Revised estimates signed off as part of Acceptance Sign Off Review. |
Deployment |
Deployment Sign Off Review (DSOR) |
Revised estimates signed off as part of Deployment Sign Off Review. |
Closure |
Closure Review | Actuals and estimates to be reviewed and reasons for divergence recorded as part of Closure Review. This is an important means of reviewing and improving the estimation process and building up a 'lesson learnt' database for projects. |
Table 2 Signing Off Estimates Within The Project Methodology
Project risks must be properly managed. There are many risks which can apply to projects which estimation techniques alone cannot adequately address. These include:
If any of these problems exist they should be addressed before the project is started!
All projects must have a Task Plan or Gantt Chart. This may be produced using ASTA Teamplan, Microsoft Project or Excel. This is used record the tasks, their estimated durations and any dependencies. The Task Plan is fundamental to determining an appropriate resourcing strategy for the project.
Projects must also have an appropriate change control mechanism. There is no point in estimating and then allowing the scope to change so that the estimates are no longer valid. The Project Issue and Change Control Log (PICCL) is used to record all changes and ensure that the impact of the change is fully considered before the change is approved.
Recent project management literature has discussed how best to deliver projects in matrix managed environments. This literature has identified the characteristics of optimally managed projects as:
Project Managers should try to bring their projects into line as far as possible with this model and book resources to the project, or as significant parts of the project as is possible, rather than individual tasks. Projects for which this approach is particularly recommended will typically have one or more of the following characteristics:
The Project Manager can indicate the requirement for "dedicated" resources as part of the Project Proposal and ToR.
For most Applications projects it will not be possible for the Project Manager to secure dedicated resources. For these projects and task estimates, including 95% confidence levels or contingencies as appropriate, are used to assign resources on a task by task basis.
However with this approach the Project Manager must be aware of a number of factors which can prevent the effective deployment of resources and threaten the overall success of the project:
The key to successfully managing and reducing these problems is communication. Early identification of potential problems by the development team, Project Manager and/or the customer is essential. To promote successful communication it is strongly recommended that the Project Manager identify staff to fulfil the following key technical roles at the outset of the project:
Once identified the staff resources can be secured by means of a 10% resource booking with the relevant Resource Manager. This approach will promote a team culture and provide more flexibility for the Project Manager to secure these key resources for meetings and other project activities. This approach is accommodated with the overall estimate as staff will only record time to the project for actual work done.
IS Applications staff resources are booked using ASTA Team
Plan. IS Infrastructure staff resources are booked by following the
procedures at:
http://www.ucs.ed.ac.uk/isd/archpub/itir/
Service Estimation
This guidance is intended for estimating project effort. We have also developed guidance on estimating the longer term costs of delivering IT services. This is available at:
The author would like to acknowledge the following sources used in the preparation of these guidelines:
(1) IT Project Estimation - A Practical Guide, Paul
Coombs Cambridge University Press
ISBN 0-52153285-X
(2) Project Management In The Real World, Paul Lyden - FISTRAL Training and
Consultancy http://www.albanorth.co.uk/
(3) Three Point Estimation, Paul Lyden - FISTRAL Training and Consultancy
http://www.albanorth.co.uk/
(4) Bad Estimates Don't Just Happen, Joseph A Lucas (2006) PM Centres USA
http://www.pmcentersusa.com/Portals/0/PMCUSA%20White%20Paper,%20Bad%20Estimates%20Just%20Dont%20Happen.pdf
Last Updated: 13/06/2011
