Preparation

Develop an Initial Frame of Reference

Estimating relies upon past experience to predict future results. A frame of reference can lend credibility to initial estimates if the estimator can identify and analyse previous projects with similar attributes and characteristics.

When data for a similar project is unavailable, realistic metrics for developing an estimating model may be unobtainable. In this type of situation, the ideal approach is to conduct a pilot project and develop initial estimates based on the results of this pilot.

Review Project Attributes And Assumptions

The first step in developing an initial frame of reference is to review the attributes and assumptions of the project. Attributes describe the goals and scope of a project and include, but are not limited to:

  • purpose of the project;
  • business functions covered;
  • high level description of new requirements or functions;
  • organisational units potentially affected by the project and their location;
  • magnitude of the change to the current processes; and,
  • strategic nature of the project and interdependence to other initiatives.

Assumptions describe inferences and constraints about the project and include, but are not limited to:

  • package selection implementation versus custom development;
  • prior experience with similar technologies or applications;
  • subcontractor versus internal resources;
  • new versus existing hardware platforms and architecture; and,
  • implementation timeframes or business constraints.

If insufficient information regarding attributes and assumptions is available at this point, the project manager should re-evaluate the initial steps of the management plan.

Identify And Analyse Project Level Comparisons

Research should be conducted to determine if similar projects have previously been implemented. Comparable projects may exist within the organisation or may be projects undertaken by external organisations. Documented similarities and differences should be analysed to identify valid information. The principle information to be gathered from comparable projects is:

  • Number and level of functions;
  • Functional areas covered;
  • Organisational coverage, and number of users and locations impacted by the system;
  • Purchased or internally developed application;
  • Delivery approach;
  • Strategic nature of the system;
  • Duration of the implementation from approval through operational use;
  • Duration of major phases such as business requirements definition, functional design and construction;
  • Cost components (hardware, software, project and user team, equipment, facilities—external and internal);
  • Technical platforms and tools;
  • Types of resource skills needed;
  • Number of people and distribution across development phases; and,
  • Outside assistance used.

An estimate range should be developed by comparing the available information against the target project attributes and assumptions. The estimate should be documented for future comparison and reference.

Develop Initial Project Estimate

A project estimate should be developed as part of the management plan. Project objectives, scope, assumptions and approach were defined and documented at an initial level to begin the estimating process.

The procurement manager should determine the appropriate estimating methods, techniques and tools to develop the initial estimate. The concept behind an estimating model is to use known information about a project, phases and activities to generate estimates for unknown future work.

If previous experience with similar project(s) is available, initial estimates can be formulated at a macro-level, using a top down approach. If no previous experience exists, the ideal approach is to conduct a pilot for a small segment of the total work, and to formulate assumptions and estimates based on the pilot. If a pilot is not feasible, initial estimates should be developed at the detailed level, using a bottom up approach.

The procurement manager should discuss initial estimates with the steering committee. The procurement manager may need to spend time explaining the estimating process to the steering committee to help ensure they understand that more refined estimates will become available as the project progresses. Steering committee approval to proceed with the project is generally required at the end of the estimating process.

Break The Project Down Into Phases And Activities

The work to be accomplished should be broken down into phases and activities. The percentage of total effort required to complete each phase and activity should then be calculated. The use of a formal lifecycle methodology generally makes this process much easier. The work breakdown is an integral part of the estimating model and should be documented.

Break The Activities Down Into Tasks

The procurement manager and team leaders should break down the activities into tasks. The more detailed the task, the better the estimate. Initial work on functional or technical requirements may be required to achieve an adequate level of detail.

The procurement manager and team leaders should develop criteria and ratings for degrees of complexity to develop and implement the functional or technical tasks. Complexity factors should be assigned to each task. The number of ratings should be limited to minimize the time assigning ratings to tasks.

Populate The Estimating Model

The procurement manager should now develop an initial estimate by populating the estimating model. The model is populated by developing an initial estimate for one activity and one component (functional or technical). The initial estimate is comparable to a detailed estimate which is discussed in the next activity. The remainder of the model can be populated using the initial estimate, percentage of total effort, and complexity factors.

Basing the initial estimate on a single number is not recommended, as significant distortions are possible. To overcome this possibility, the project manager should develop an estimate range by developing initial estimates for several different combinations of activities and tasks. These different combinations should be used to populate the model, one at a time. Each result should be analysed and compared and a range should be established based on these “what if” scenarios.

Once several “what if” scenarios have been developed, the project manager should formulate assumptions about the number of resources, available hours per day, support and overhead estimates to calculate an approximate duration range.

The estimating model at the activity level is often surprisingly accurate because some functional or technical tasks will be overestimated and others will be underestimated. Estimates for a single functional or technical task will be less accurate than the overall estimate for the activity.

Procurement staff are often reluctant to commit to complexity ratings because of the lack of detailed analysis of the work involved. A useful technique is to use a “confidence rating” on each task, and to base the contingency allocated on the number of “low confidence” estimates.

Develop Estimate Range

The procurement manager derives an estimate range for the project using:

  • The initial frame of reference estimate from the first activity;
  • The estimating model results from the previous task;
  • Experience; adding a level of effort and duration for contingency. (This too may be based on the ’confidence rating’).

The procurement manager should incorporate this initial estimate into the management plan and discuss the estimate range with the steering committee. The estimate range should be updated periodically as actual experience and information on the project is gained. To help ensure regular updates occur, the project manager should develop and publish a schedule for updating the project estimates. The project sponsor and steering committee should be familiar with the schedule and should understand that successive estimates will be based on more actual project data, and will therefore provide a more realistic view of the total estimated project effort.

Processing...