Client/server, imaging and earned value

a success story - Part II: the consultant's perspective

Tom Ingram, PMP

Question: “My project budget is 75 percent spent. How can I be certain that 75 percent of the work is done? How can I make sure we are on track for completion on budget?”

Answer: work breakdown structure and earned value!

Most project managers and executive sponsors have found themselves in this position. Midway through a project, the activity level is furious and your spreadsheet tells you that you have spent 75 percent of your budget (see Figure 1). On the surface things look good, but the hair on the back of your neck tells you that the work is not 75 percent done. The scary part is that you don't know for sure.

Earned value key benefits include:

  • Allowing us to hold people accountable to their estimates
  • Dealing with scope changes in a smooth, controlled fashion that does not disrupt accountability
  • Knowing that the planned work is done (rather than hoping or guessing).

To illustrate one approach to “knowing for sure,” let's look at a real example of earned value and work breakdown structure for a client/server imaging project.

The project began in the fall of 1994. In this case I was the project manager for the imaging system supplier (ViewStar Corporation) and Texas Instruments was the client. Figure 2, in which the earned value curve Budget Actual has been added to the data shown in Figure 1, shows that as of January 28, 1995, less than half of the “value” to be produced by this project was actually “earned.”

Figure 1. Questioning the Surface Data

Questioning the Surface Data

Basically, this meant that only half of the originally planned work was actually completed. Knowing this early allowed everyone to focus on completion of deliverables, make up the lost ground, and finish on time and on budget. This case study uses a simple example to illustrate how you can use the earned value concept to improve your chances of bringing projects in on time, on budget and as promised.

Let me mention that most of the concepts presented here were learned through my association with the Project Management Institute and the Project Management Professional (PMP) Certification that PMI offers. Also, the numbers quoted below have been slightly altered to protect TI and ViewStar confidential information.

Project Overview

This project involved approximately 30 users in the United States and another 50 around the world. Figure 1 on page 14 shows the general architecture. The application was for TI's Accounts Receivable department, using imaging technology to improve collection efforts and service to both internal and external customers. The technology was client/server based, with eight servers and a significant interface to the mainframe accounts receivable system. Some “bleeding edge” technology was desired by TI, so the project contained some material risks.

Illustrating the Key Concepts. To illustrate earned value and work breakdown structures, I will walk you through the major events and deliverables of the project. The drawings and tables in the figures are from the actual project. Be aware that these numbers only represent external consulting costs. This works well for illustration, but remember that you may need to account for product costs and internal labor in your own projects. The original data was recorded based on consulting days, but is converted to approximate dollars here for clarity.

Work Breakdown Structure Definition. Simply put, WBS is a project plan or task list that breaks down the tasks of a project under the key deliverables. Table 1 shows the WBS used in this project. Two key items differentiate this from a traditional Information Systems project plan:

1. Level of Detail. If you break each deliverable down to four-hour segments (called Work Packets), you will be hopelessly mired in detail and data entry time. If you use 200-hour work packets, you will only be managing at a high level and it might be a month or more before you discover that a task is not getting done. PMI's standard recommendation is to break down work packets so that they are no longer than your standard reporting period. In most cases this will be 40 hours, based on having a weekly project status report. In 20-20 hindsight, I should have broken the tasks down somewhat further in this project. It might have prevented our getting behind.

2. Accounting Codes. Stay with me. This is important. Look at the column titled WBS ID # in Table 1. Note that the deliverables have high-level numbers and the tasks are broken down underneath them so that an accounting roll-up can occur. Note that we have a budget (or estimate) and an actual for each work packet. Earned value cannot be tracked unless you adhere to this discipline and capture the actuals in a timely manner.

Earned Value Definition. When the customer signs off that a work packet is complete (see WBS definition above) you are entitled to claim the amount budgeted for that task as earned value. In Figure 2, the earned value line shows the accumulated total of signed-off, completed tasks. In summary, earned value is the dollar value of completed work based on budget estimates. It is critical to remember that earned value is based on proposed or budgeted estimates, not actual money spent. One overriding benefit of earned value is to hold suppliers, consultants and internal people accountable for their estimates and proposals.

Figure 2. Using Earned Value to Find the Answer

Using Earned Value to Find the Answer

Walking Through the Project

I'd like to take you through the major deliverables of the project to illustrate some of these concepts. It is important to note that Texas Instruments’ contract with ViewStar only permitted payment for services when the deliverable was signed off as complete. As we walk through the project, keep in mind the high degree of control that Texas Instruments is maintaining. The major deliverables were:

Base System Installation. This is the initial installation of the basic “out of the box” system. The contract budgeted $8,500 in consulting time. Due to some underestimation and some of the “bleeding edge” issues, we actually spent $13,600. Note that our earned value was only $8,500 (our proposed, budgeted amount). The overrun was our problem, not TI's.

Table 1. WBS and Budget-to-Actual Comparison

Base System Installation 10000 0 0 0
Site Readiness Workshop and Preparation Assistance 10100 3.5 2.9 3.5
SST Team Installs Software 10200 5 9.7 5
AST Workstation Testing 10300 0 0 0
Cache Utility Install/Training 10400 0 1 0
Subtotal   8.5 13.6 8.5
Functional Design Spec. 11000 0 0 0
Implementation Workshop 11100 1 1 1
Functional Design Spec and User Requirements 11200 2 10 2
Subtotal   3 11 3
Mainframe Download Custom Programming 12000 4 4.2 4
Subtotal   4 4.2 4
Prototype Defined and Developed 13000 0 4 0
Definition 13100 5 1.7 5
Development 13200 5 0.25 5
User Review 13300 3 0 3
Subtotal   13 5.95 13
Application Developed   0 0 0
Development 14100 5 7.1 5
Application Testing 14200 0.5 0.5 0.5
Application Acceptance Testing 14300 0.5 0 0.5
Subtotal   6 7.6 6
Production Rollout Assistance 15000 0 0 0
System Stress Testing 15100 1.5 1 1.5
Problem Resolution 15200 6.5 1.5 6.5
Documentation 15300 0 0 0
Subtotal   8 2.52 8
Post-Production Review 16000 0 0 0
Review (60 Day) 16100 0.5 0 0.5
Project Closeout 16200 0.5 .5 0.5
Subtotal   1 .52 1
Project Management 17000 5.5 6.65 5.5
Miscellaneous 18000 2.5 0 2.5
Project Totals1   51.5 52 51.5
1In thousands of dollars        
2Item adjusted by agreement with client        

Functional Design Specifications. Here is where we developed the specifications for customizing of the base product. ViewStar is more of a “toolkit” than a finished application, so this is an expected expense. Our proposal budgeted $3,000 for this work packet. I was required to “force-fit” the services proposal to a $52,000 total. I knew $3,000 was severely inadequate, but ViewStar wanted Texas Instrument's business, so we went ahead with the force-fit budget (sound familiar?).

The actual cost for the functional design specification was $11,000 but the earned value was only $3,000. At this point, ViewStar had actually spent $24,600, but only “earned” $11,500. Clearly, we had to regain control or we were going to have a disaster on our hands. It is interesting to point out that, due to the “earned value” concept, View-Star was fully responsible for this overage and had no basis for asking Texas Instruments for more money. Because the “earned value” graphic was produced for each weekly status meeting, TI knew the exact status and could see we were having some difficulty. They chose to act in a “win-win” manner and negotiated several items in good faith that helped us return to a mutual “win” outcome.

Project Management and Miscellaneous Items. Earned value for these items were taken each week. They did not necessarily produce measurable milestone deliverables, but they were necessary and consumed time and cost. We budgeted $8,000 and actually used only $6,700. Remember the key concept: The provider receives the budgeted amount when the deliverable is completed, no matter what was actually spent. Here we received more earned value than our cost, so we made up some of the ground lost on previous deliverables.

Mainframe Download Custom Programming. In this deliverable we worked with the client to create a custom program for downloading data from the mainframe. This involved considerable technical risk and our budget of $4,000 could have been severely inadequate. Fortunately, Texas Instruments had assigned two full time, capable people to this project. Paul Conner and Chris Fowler were able to accomplish the custom programming with only limited help from ViewStar, resulting in $4,200 of consulting time actually spent. We received earned value of $4,000 for completion of this deliverable.

Prototype Developed. We budgeted $13,000 for the prototype, which was about average for a project of this nature. I had seen many prototypes exceed their budgets substantially, so I was concerned about this area of the project. Because we were meeting weekly and reviewing the status of our earned value, the entire team remained focused on completing only the key user requirements in the prototype. Actual consulting dollars spent were $6,000, with an earned value of $13,000. We had made up $7,000 in lost ground, and the project was looking much healthier from the consultant's point of view.

Application Developed. If you recall, the Functional Design Specification was underestimated and we overspent considerably on it. The upside of this overage showed up in (a) a prototype completed for less than half of its budget; (b) a prototype that was easily developed into the final application; (c) a negligible overage on the final application development; and (d) relatively easy user sign-off on the final application.

We budgeted $6,000 and actually spent $7,600. Our earned value received was $6,000. Refer again to Figure 2. After completion of the application development milestone we had “earned” approximately $40,000 worth of the $52,000 “value” of this project. Note how the curves are coming together toward on-time, on-budget completion. The major technical risks were behind us and it was beginning to look like this was going to be a successful project for both supplier and client.

Production Rollout. At this point we had a happy client, but had overspent somewhat. Texas Instruments had a few minor items they wanted to add to the project that were not strictly within our scope or responsibility. Again operating in a “win-win” mode, we negotiated an agreement to provide these extras in exchange for the client taking over most of the production rollout responsibilities. This was possible because Texas Instruments had adequately staffed the project with strong people. Production Rollout Support was budgeted for $8,000. We actually spent only $3,000 and received earned value of $8,000. Our total earned value for the project was within a few dollars of the originally budgeted $52,000.

Some Observations

Our contract allowed us to shift dollars between the deliverables to help compensate for being over in one area and under in another. I strongly encourage you to add this provision to your contracts. If you don't, the project can quickly become unfair to the supplier.

Priorities change in most projects over time. In this case, we did not encounter material scope changes. If we had, they could have easily been handled by making sure the scope change and attendant cost was signed off by all parties; creating a new WBS line item and ID number; and adding the dollar value to the budget line in the graphic. This way the scope change simply becomes one more deliverable that is managed through earned value.

When the project is in trouble in a certain area, remember that the client's priorities are probably changing somewhat. We had an opportunity at the end of the project to do a few small favors for the client in exchange for an agreement that let us finish on budget. You may find similar opportunities as well.


Going through the discipline of work breakdown structures, earned value tracking and scope change management can yield strong benefits. It will allow you to hold internal and external people accountable for their promises. You will be able to deal with scope changes in a controlled fashion that maintains accountability. You will be confident that the planned work is actually getting done. By tracking earned value weekly you will help keep the project team focused and prevent procrastination.

If you are an experienced project manager, you can probably apply these concepts immediately. Please take into account that this example has been simplified and that the real world has a habit of throwing curve balls. To fully understand the concepts you will probably want to pursue PMP certification.

If you are new to project management, I would suggest that you begin studying for the PMP certification and pursue this goal. Along the way you will learn these concepts and many more that will improve your projects. If you need immediate application of this technique, but are unsure about how to proceed, I suggest that you retain a PMP-certified consultant.

I encourage you to continue improving your project management skills. Prior to studying for the PMP certification I had managed some 60 projects and believed that I knew what project management was all about. I am delighted (and humbled) to report that PMI has opened a whole new world of professionalism to me. PMI and the PMP certification have helped me believe that it is possible to consistently deliver client/server projects on time, on budget and as promised. My hope is that you will come to the same belief. img


A special word of thanks for the help I received in passing the PMP (Project Management Professional) exam and for TI's support in the use of these techniques. I was studying for the exam at the time and the backdrop of this project allowed me to see the benefits of the earned value concept first hand.

Ben Settle of Infotech Management, president of the Fort Worth PMI Chapter, tutored me in preparation for the exam. I had encountered the earned value concept before, but did not see any real applicability to Information Systems projects. Ben helped me through the PMP test and helped me learn the benefit of these techniques.

Stan Sigle, the project manager for TI and a PMI member, was also instrumental in the success of this project. Stan supported the use of PMI techniques and provided valuable feedback. He negotiated in good faith when things got tough on the project.

The assistance and cooperative spirit of Ben, Stan and the TI project team were a great benefit to me. Hopefully, this case study will be of benefit to you as well.

Tom Ingram, PMP, is a consulting manager for the Systems Consulting Group, a subsidiary of Cambridge Technology Partners. His book on client/server project issues is targeted for publication by PMI in 1996.

PM Network • December 1995



Related Content