Project Estimating and Cost Management

Parivs F. Rad PhD, PMP

• Verlag: Berrett-Koehler Publishers
• Jahr: 2001
• ISBN:
  9781567264548
• Auflage: 1
• Thema: Business
• Thema: Contabilità e budget

Improve the accuracy of project estimates and make better in-progress modifications by following the discipline-independent approach mapped out in this book. Learn the best ways to apply new tools, including a breakdown structure for both work and resources and proven estimating models. In addition, you'll gain insights into best practices for progress monitoring and cost management, as well as for dealing effectively with external projects.

CHAPTER 1

Introduction

Estimating is the art and science of using historical data, personal expertise, institutional memory, and the project scope statement to predict the resource expenditures, total cost, and duration of a project. A typical statement of project objectives will outline the attributes of a new physical deliverable, the details of performance enhancements to a system, or the purpose of a specific service. To estimate the project cost, the project manager must identify the various constituent physical elements and related activities necessary to meet the project objectives. Next, the project manager develops the estimate by summing the estimate of resources for these elements. Then, by extension, the project manager computes the elemental and project costs.

When the project is conceived, the estimate is extremely inaccurate because very little information is available about the expected deliverables, the project team, and the project environment. But, as the project evolves and more information becomes available, the estimate can be fine-tuned to a higher level of precision. Details of the objective, scope, quality, and desired delivery date are necessary for a comprehensive and accurate estimate. As these details become available, they in turn trigger enhancements in the work breakdown structure (WBS), the estimate, the schedule, and other planning documents. Further, the evolving planning documents could also include increasing details about the procedures that will be used in implementing the project.

The initial cost estimates of the elements and the project form the baseline budget for measuring the cost performance of the project during the implementation phase. This cost estimate, and therefore the budget, are initially very rough and inaccurate. When establishing the project budget on the basis of the project estimate, it is necessary to note whether the estimate was developed using a rough conceptual estimate technique or a detailed bottom-up estimate. If the budget was established during the early stages of project planning, the budget development process should allow some modification flexibility, primarily because early estimates are inaccurate.

Likewise, during the implementation phase, the project estimate serves as the base of reference for developing quantitative indicators of the project cost performance. Accordingly, depending on the accuracy and limitations of the estimate, appropriate contingencies, reserves, and flexibilities should also be incorporated into the budget. It is important to remember the degree of accuracy of the baseline estimate when making commitments, comparisons, and judgments during the budget development and project progress monitoring phases. In progressive organizations, the amount of budgeted funds for the project will go through several modifications as the details develop.

The credibility, accuracy, and completeness of the estimate are enhanced by the estimator’s skills in the areas of business, finance, engineering, technology, information systems, manufacturing, assembly, marketing, management, production planning, and all facets of project management activities. Since it is somewhat unrealistic to expect one person to have expertise in all these areas, organizations sometimes form estimating committees or estimating boards. The board members contribute their expertise from all technical disciplines impacted by the project such as business development, purchasing, contracting, financial management, and of course, project management.

The project’s cost estimate is derived by summing the resource expenditures and, consequently, the cost of the project’s individual component parts of the WBS. Likewise, with the hopeful expectation that estimating and scheduling processes use the same WBS, the estimate of the duration of the project’s component WBS elements is used in the development of the schedule network, which in turn formulates a time management structure. Therefore, there is an interdependent relationship between the project’s cost and the schedule. This interdependence must be taken into account during project implementation, when the changes in scope and specifications cause changes in the project’s cost and/or schedule. Furthermore, this relationship between cost and schedule must be continually reviewed as the project matures, detailed project plans are formulated, more definitive baselines are established, and finally, the inevitable tradeoffs are made during the implementation phase.

PROJECT SCOPE AND OBJECTIVES

The client’s needs and desires are communicated to the project personnel through documents such as the project’s charter, objectives, scope statement, and specifications. The terms requirements specifications and scope have been used interchangeably and sometimes differently depending on the industry in which the project is being implemented. Construction, industrial, and process projects refer to the description of the deliverable as scope and specifications. Scope refers to a broader expression of the client’s objectives while the term specifications refers to the detailed expression of the client’s objectives. Systems and software development projects often do not use the term scope while referring to deliverables, but they use the term requirements to describe the performance attributes of the projects, such as processing speed, error rate, database size, and the degree of friendliness of the deliverables. Systems and software projects use the term specifications to describe the attributes of the hardware. Hardware specifications for systems and software development projects might be either predetermined by the client as part of the project objectives or developed by the project team as one of the deliverable components.

Sometimes the quality of the project deliverable is not explicitly addressed as part of the definition of project objectives. Ironically, it is this issue of quality—independent of the volume of deliverables—that determines the usability of the product and the resulting satisfaction of the stakeholders. For the purposes of this book, quality and scope are treated collectively.

Project specifications are usually included in the contract documents if the project is an external project, and particularly if the contract is awarded on a lump sum basis. However, enlightened organizations develop specifications documents even for their internal projects. The objectives or specifications of an internal project are usually spelled out in the authorization memo that empowers the project manager to implement the project. The rationale for using specifications for an internal project is that, although an internal project does not involve a contract, it should have a set of well-defined scope and objectives, so that the delivery performance can be carefully monitored. The premise is that evaluation and monitoring of internal projects will become an ad-hoc activity if there are no focused objectives and, therefore, no detailed specifications.

The scope document includes the client’s wants and needs, the distinction being that “wants” are those items that would be desirable to have although not crucial to the success of the project, while “needs” are those items that are essential to the success and usability of the project deliverable. Again, this information will probably be very sketchy during the early stages of project evolution, and will be refined, clarified, and progressively elaborated as more information becomes available to the client and the project team.

Definition of project objectives involves detailing the project scope, attributes of the deliverables, acceptance tests, desired delivery date, expected budget, and team structure. When the client directs the activities of the project, the description of tools and techniques used in implementing the project are also included in the specifications document.

To some extent, the acceptance procedures and validation tests determine the physical quality and performance tolerances of the deliverable. Therefore, care should be taken to ensure that the tests reflect all the important operational facets of the product, and that these tests do not reflect frivolous features. In the same vein, the team should make every effort to craft the deliverable to the spirit of these tests and not necessarily to the letter of the tests, which might miss some important facet of the product. Due diligence on the part of the project team will promote client satisfaction, which is considered one of the most important indicators of a project’s success.

The desired delivery date signifies the date on which the client wishes to begin reaping the benefits of the deliverables, and, therefore, the most important date for the project’s schedule. Notwithstanding, for a variety of historical and operational reasons, several intermediate milestones are usually defined as part of project plans. Intermediate milestones are not crucial to the execution of the project, but the achievement of these milestones often signifies or verifies the expected pace of the project and the desired quality of the deliverables. The establishment of intermediate milestones can be in response to the needs and desires of the client, the collective project team, individual team members, or the stakeholders.

A carefully drafted project objective document is essential to the project’s success. The objective statement is the focal point and the definitive reference source for managing the triple constraints of the project during the implementation phase. Project procedures must include instructions on how to treat the project objective statement as a living document to be enhanced continually, albeit the current version of this statement will be used as a base of performance reference through the life of the project. Project management procedures must highlight uniform and consistent guidelines for the development of, and making modifications to, the baseline project objectives and specifications.

Project planning documents must include details of processes, procedures, and methodologies that will be used for monitoring the effectiveness and efficiency of the project team in implementing the project deliverable. Since the characteristics of the team can have subtle but significant impact on the project’s success, the characteristics of the project team must be outlined in planning the physical deliverable of the project. Team attributes that must be addressed are the skill of team members, th...