The earned value concept

taking step one--scope the project


Concerns of Project Managers

Quentin W. Fleming and Joel M. Koppelman, Primavera Systems, Inc., Bala Cynwyd, Pennsylvania


Planning a new project in which you intend to employ earned value performance measurement is no different than the initial planning steps necessary to implement any new project. It always helps to know what makes up the project, the whole project. We can think of at least three reasons why this is important to project managers.

First, you need to know when the party is over, when all of the work that you originally set out to do has been done. You need to have a tangible metric for the project called “Done.”

Second, you need to know when to draw the line when someone brings in more work for you to do than you had originally agreed to do. If you agree to peel ten baskets of potatoes and someone brings in an eleventh basket, you will want to ask for additional compensation (an adjustment in the project's price).

Third, and perhaps this is most critical to the earned value cost management concept, you will want to know how much of the entire job has been accomplished at any point in time. The issue is fundamental: If you do not know what constitutes 100 percent of a project, how will you ever know if you are 10 percent or 50 percent or 90 percent done? You must know what represents 100 percent of the project scope, in order to tell how much of it you have performed during the life of the project.

Chapter 5 in the proposed revision to PMI's Project Management Body of Knowledge (the PMBOK) covers the subject of scope management. In its opening paragraph it describes well the importance of any project knowing what it has agreed to do, and perhaps of greater importance, knowing what it has not agreed to do, which it calls the project boundaries:

WBS for an Energy Project

Figure 1. WBS for an Energy Project

Project Scope Management involves ensuring that the project does enough work, and only enough work, to deliver the business purpose of the project successfully. It is primarily concerned with the project's boundaries-inclusion as well as exclusions.1

One of the key pillars of the earned value cost management concept is that the project manager must know at all times what percentage of the physical work has been accomplished, the percent complete, as related to the total job. This information is needed in order to compare the physical work done to the actual costs spent in the same measured period. The relationship between the total physical work accomplished, as compared to the total dollars spent, provides the answer to: “what did we get for the dollars we spent.” For example, if you spent 40 percent of the total project's budget to accomplish only 30 percent of the total budgeted work, what do you call this condition? Answer: an overrun!


Starting sometime in the early 1960s there developed a school of thought centered on the belief that project managers needed a new tool, a tool similar in approach to the company organization chart. For years, corporate executives had been using their organization charts to conceptually define in graphical form: (1) who does what in the company, (2) who is responsible for what, and (3) who reports to whom within the organization.

The notion that project managers needed a special tool led to the creation of the WBS. The WBS is to the project manager what the organizational chart is to the company executive.

The WBS is a tool used by the project manager to define a project, and to give it cohesiveness so that the project can be managed as a one-time unique effort through the firm's permanent organization. A given company will likely have many projects being performed during the same time period, each competing for limited company resources. The WBS is the device that sets one project apart from all other projects within the same company.

An important point often missed: The WBS looks so much like an organizational chart that some people get confused about this issue and draw a project organizational chart which they label as their WBS. This is wrong. The project WBS is not the project's organization chart, but the WBS can be used to help in assigning work in a project. An example of a project WBS is shown in Figure 1, representing a WBS for an energy project. Note that this is a “product” oriented hierarchy that progressively breaks out the WBS elements from the top WBS box.

The emphasis for the WBS must be on the project, the project tasks, the unique work done to accomplish the project objectives. Some of the key words that should be a part of any viable WBS definition would be project end-items, project deliverables, project task and project subtasks, etc.

An insightful contribution was published in 1976, in which the author was defining what he called a Project Breakdown Structure (PBS):

The PBS is a graphic portrayal of the project, exploding it in a level-by-level fashion, down to the degree of detail needed for effective planning and control. It must include all deliverable end items…and includes the major functional tasks that must be performed...

The PBS would appear to have its primary focus on the product of the project, whereas the WBS has its focus on the project's work tasks.

The 1987 PMBOK's definition of a WBS is also quite informative and perhaps worthy of our review. The PMBOK defines a WBS as:

A task-oriented “family tree” of activities which organizes, defines and graphically displays the total work to be accomplished in order to achieve the find objectives of a project. Each descending level represents an increasingly detailed definition of the project objectives.1

By essentially forcing the definition of a project by its necessary work tasks into progressively greater detail with the use of a WBS, the total scope of the project takes form.

At the lowest WBS element the project is transformed from the brief task titles into a descriptive narrative, which can then evolve into what is referred to as the WBS dictionary. The WBS dictionary will also relate the work tasks to specific organizational units that will perform the actual work, perhaps in a matrix-type organizational form. Contract specialists will also have use for the WBS dictionary to serve as the basis for the contractual statement of work (SOW) between owner and the project manager.

Starting with the project definition in the form of a WBS defined by the project manager, the project evolves into the contractual document. Thus, there is better assurance that there will be a direct relationship between the work on a project and the product desired by the ultimate customer.


The WBS has always been an integral part of the earned value concept. A hierarchical structure of the project is required in order to relate the requirements of the project to elements of the company's organizational structure.

When the earned value concept was first introduced as a part of the C/SCSC in 1967, it mandated 35 management control system standards that must be met by any firm wishing to receive a contract for a major government system. Interestingly, the very first of these 35 criteria addresses the issue of defining the project with use of a WBS:

Define all authorized work and related resources to meet the requirements of the contract, using the framework of the contract work breakdown structure (WBS).4

In practice, the owner or the buyer of the project typically defines the first two or three levels of the WBS, which constitutes the way cost and schedule performance is to be monitored and reported during the life of the project. The project manager then typically defines the lower levels of the project, representing the way the work will be done.


There sometimes is a conflict between the best interests of a project and the objectives of the functional departments that will be supplying the resources to the proj ects. Because functional departments support multiple projects at the same time they may well have other competing priorities. This is typically accomplished by employing a matrix organizational form. Individual functional departments may not see the utility of them supporting projects operating within the confines of the project WBS. Moreover, their historical data may well be structured in another form, not consistent with the project's WBS.

The cost estimating functional departments in particular may have their data available in great detail, but collected and formatted along company organizational lines. Unless specifically directed, they will likely not see the utility of regrouping such data to match a given WBS arrangement for the project.

Sometimes the scheduling function will find the WBS environment confining. Scheduling is a critical function for any project and the people who perform this important role are unique individuals who will often best perform their work without restrictions of any sort. However, unless this critical function performs within the overall envelope of the project WBS, the opportunity for the project to integrate its costs with its schedules may be missed.

From an enterprise standpoint, only if all key project functions perform within the framework of the WBS will the project be in a position to integrate its various functions and maximize a project's performance. This is particularly true for the estimating, budgeting and scheduling functions. The success of its projects, it is felt, should be of greater consequence to a firm than the personal goals of any individual function. The WBS, if properly defined at the outset, can be the medium to negotiate for resources, to set priorities, and to measure progress in an integrated fashion.


We have been attempting to make the case for defining the project work before starting to perform the effort. Reaching an agreement on the project scope between the owner and contractor, between the buyer and seller, is important to any project.

All this discussion reminds us of a statement made by a person who worked in project management. When asked if the projects at his site ever overran their costs, he immediately replied, “We never overrun our project costs…any unfinished work gets moved into next year's projects.”5

Think about this remark for a minute. If one is given a budget to do a certain amount of work, spends all of the money, and then moves the unfinished work into next year's projects, what do you call this condition? Answer: a project budget overrun.

Scope management is vital to the effective management of any project. Understanding the scope of a project is essential when “earned value” is employed, because the performance must be measured throughout the life of the project…from baseline implementation until project closeout.

Scope management is a project manager's greatest challenge. It is also fundamental to the earned value cost management concept. Unless scope is tightly defined and managed throughout the life of a project, the ability to meet the mission of completing our projects on schedule and within budget will be severely jeopardized.


1. Project Management Institute (PMI). Project Management Body of Knowledge (PMBOK), revision draft 2.2 dated February 2, 1994, page 5-1.

2. Russell D. Archibald. ManagingHigh-Technology Programs and Projects (New York: John Wiley & Sons), 1976, page 141.

3. Project Management Institute (PMI). Project Management Body of Knowledge (PMBOK), 1987, page A-6.

4. United States Department of Defense Instruction 5000. 2, February 23, 1991, page 11-B-1-1, updated without change in text from DODI 7000. 2 of December 22,1967.

5. An anonymous quote.   ❏


Quentin W. Fleming has been senior staff consultant to Primavera Systems, Inc. since July 1993. He has over three decades of industrial experience, and was with the Northrop Corporation from 1968 until retiring in 1991. While there, he held various domestic and overseas management assignments. He served on a CEO-directed “earned value” corporate review team in 1989-90, and subsequently wrote the corporate policy directive on scheduling.

He has instructed the scope, time and cost management modules of the PMP exam on several occasions. He holds a bachelor's and master's degree in management, and has written six books, including Put Earned Value Into Your Manage. ment Control System (1983) and Cost/Schedule Control Systems Cri-teria—The Management Guide to C/SCSC (1992).


Joel M. Koppelman is co-founder, co-owner and president of Primavera Systems, Inc. He is a registered professional engineer who spent more than a decade in the managing of capital projects in the transportation industry. He earned a bachelor's degree in civil engineering from Drexel University, and an M.B.A. from the Wharton School of the University of Pennsylvania.

He was a vice president at Day & Zimmerman, Inc., where he was responsible for financial consulting assignments. Earlier he operated his own consulting firm, and was with Booz, Allen & Hamilton for five years as a senior consultant responsible for projects.

Mr. Koppelman is a member of several professional societies, he has delivered papers for AACE, APTA, ASCE, CMAA, CFMA, PMA, PMI, and has been a guest lecturer at several universities.

PMNETwork • May 1994



Related Content