Estimation Techniques/Guidelines for IS/IT Projects The best people to undertake project estimation are the staff who are going to do the work. The staff chosen to produce an estimate are drawn from IS/IT, business or customer areas, and/or service partners who have relevant experience of similar previous projects or tasks in the business area.
A typical estimation process is based on three components:
1. Expert judgment, i.e. consultation with qualified experts from within IS/IT and your business and/or service partners. This is supplemented, where required, by expert input from software suppliers and consultants.
2. Experience, i.e. comparison of the proposed project or task with one or more previously completed developments.
3. Task Decomposition, i.e. decomposing the project into components, i.e. the Work Breakdown Structure, and estimating these components individually to produce an overall estimate.
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, must be transparent and consistent across all projects.
Project And Task Estimation
Estimation Technique 1 - Base and Contingency
---------------------------------------------
Estimation is an inexact science and estimates are always subject to risk. All estimates therefore 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 taken into account. The contingency is generally expressed as a percentage of the base.
A figure of 10% -20% contingency is a typical contingency figure for straight forward tasks rising to 50% or even greater for more risky tasks. Separating the base and contingency makes estimation easier. We can derive a base figure without having to take into account everything that might go wrong and use risk analysis techniques 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:
* Decomposes the project into a list of estimable tasks, i.e. develops the Work Breakdown Structure (WBS)
* Estimates each task including any task contingency.
* Adds the estimates together.
* Adds the project contingency.
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.
Estimation Technique 2 - Three Point Estimation
-----------------------------------------------
An alternative estimation technique to "Base and Contingency" is three point estimation. This technique is based on statistical methods, and in particular, the normal distribution. For every estimate we produce three figures:
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 using the following formulae:
E = (a + (4*m) + b) / 6
SD = (b - a)/6
E is a sensible estimate for the task and is a weighted average which takes into account both the most optimistic and pessimistic estimates provided.
SD is the variability or uncertainty in the task estimate, and, in essence, is a measure of risk.
To produce a project estimate the Project Manager:
* Decomposes the project into a list of estimable tasks, i.e. develops the Work Breakdown Structure (WBS)
* Estimates each the E value and SD for each task.
* Calculates the E value for the total work the project as E (Work) = Σ E (Task)
* Calculates the SD value for the project work as SD (Work) = √Σ SD (Task)^2
(where ^2 := raised to the power of 2 = squared)
* Calculates the E value for the project duration as E (Duration) = Σ E (Critical Path Task)
* Calculates the SD for the project duration as SD (Duration) = √Σ SD (Critical Path Task)^2
We can use E and SD to convert these estimates to Confidence Levels as follows:
* Confidence Level in E value is approximately 50%
* Confidence Level in E value + SD is approximately 70%
* Confidence Level in E value + 2 * SD is approximately 95%
* Confidence Level in E value + 3 * SD is approximately 99.5%
Technical and Overhead Tasks
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:
* size and complexity of the task
* the skills and experience of the proposed development team and their familiarity with the technology being proposed.
* non functional requirements such as performance, reliability, code reusability etc.
Typical overhead tasks include:
* Project Management
* Business Analysis
* Systems Analysis and Design
* Testing
* Deployment Support (includes user training and implementation in live environment.)
Project experience suggests potentially useful rules of thumb for deriving initial estimates for various overhead tasks and these are provided below.
Task: Project Management
Rule Of Thumb: A full time Project Manager is required for every six staff assigned to the project.
Hence, if a project requires the equivalent of 2/3 full time staff, then applying this rule of thumb suggests that the Project Manager should be assigned between 33% and 50% or the duration of the project.
Task: Business Analysis
Rule Of Thumb: Allow a figure of 20% of the time allowed for the technical tasks to complete the business specification.
Task: Systems Analysis and Design
Rule Of Thumb: Allow a figure of 25% of the time allowed for the technical tasks to complete the design specification.
Task: Peer Testing
Rule Of Thumb: Allow a figure of 10% of the time allowed for the technical tasks.
Task: Integration Testing
Rule Of Thumb: Allow a figure of 15% of the time allowed for the technical tasks.
Task: Acceptance Testing
Rule Of Thumb: Allow a figure of 15% of the time allowed for the technical tasks.
Task: Deployment
Rule Of Thumb: Allow a figure of 5% of the time allowed for the technical 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 Estimation Team
Where appropriate the Project Manager may assemble an estimation team for the project - this is particularly appropriate technique for estimates produced during the Initiation and Planning stages of the Project Methodology.
The estimation team will include the Project Manager and other technical experts from IS/IT - chosen to reflect the staff who will actually do the work. The estimation team may also be supplemented by representative project stakeholders including customers and service partners. 4 or 5 staff in total is a reasonable number 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:
* Review and agree the project goals and identify any risks or assumptions.
* Discuss ways in which the goals may be met including design options.
* Identify key tasks.
This meeting may also 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 estimates. It is important that each member of the team prepares their own estimate of the work involved ahead of this second meeting. 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:
* Confirms the list of estimable tasks
* Confirm the estimates for each estimable and overhead task
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, the System Architect or 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
1. A typical estimation team will be composed of the following staff: the Project Manager, two developers, an IS/IT manager or team leader and one or two others such as a business stakeholder or customer, a technology specialist or an external supplier.
2. During estimation meetings it is vital that a note taker is appointed to record design decisions, assumptions and risks. These notes are an important deliverable from the sessions as they help ensure that the context for the estimate is fully understood.
3. Sufficient time should be allowed to enable the team to complete the estimation process. An allowance of 0.5 - 1 day for each member of the team is reasonable.
4. IS/IT Project Methodology templates for recording base/contingency and three point estimates must be developed if not available.
