evm MeasurableNewsIssue308

The Measurable NewsThe Magazine of the Project Management Institute’s College of Performance Management

Summer 2008, Issue 3

See our VENDOR / SERVICES listing on page 18.

Continued on page 19.

The Measurable News is now accepting

sponsorship for the Fall 2008 issue.

With sponsorship, you receive

• 4-color, 1/3-page ad on front cover

• 4-color, full-page ad on back cover

• Priority publication of two articles from profes-sionals in your organi-zation

Too good to be true?

Find out more! Contact Managing Director

Gaile Argiro 703.370.7885

[email protected]

Did you hear?

By Fredric L. Plotnick, Esq., P.E., Engineering & Property Management Consultants, Inc. and Drexel University

Update on RDM

AbstractThe new format of the Relationship Diagramming Method (RDM) variant of the Critical Path Methodology (CPM) for Planning and Scheduling was introduced in 2005 in the 6th edition of the industry bible, CPM in Construction Management, O’Brien and Plotnick, McGraw-Hill. Further details were presented at the PMI College of Scheduling annual conference by Fredric Plotnick, in April of 2006, as noted in ENR (06/05/06.)

T he original format for CPM, developed fifty years ago in 1957, has since been renamed as ADM or Arrow Diagramming Method (also called AOA for Activity-on-Arrow) to distinguish it from the PDM or Precedence Diagramming Method (also called AON for

Activity-on-Node) variant which was first implemented in 1964. Another variant of the same era was PERT or Program Evaluation Review Tech-nique developed by the U.S. Navy for development of the Polaris Missile System, and which focused more upon defined milestones than upon the loosely defined activities between such milestones.

All three formats included weaknesses due to the limitations of com-puters of that era. The original ADM and PERT formats were designed to operate on computers lacking random access memory (RAM) and limited to linear access memory. Old cartoons illustrating computers with large reel-to-reel magnetic tape (or even punched paper tape) provide an indication of the limitations that the early software designers had to overcome. Many of the arcane rules of older CPM specifications, such as “skip numbering” (or identifying events as 5, 10, 15, rather than 1, 2, 3) are founded in these historical limitations.

mailto:[email protected]

http://www.deltek.com/evreadiness

3The Measurable NewsSummer 2008, Issue 3

The Measurable News is an official publication of the College of Performance Management (CPM), 101 S. Whiting Street, Suite 320, Alex-andria, VA 22304, telephone 703.370.7885. The Measurable News is published four times per year.

Editorial StaffPublisher

College of Performance Management

Managing Director Gaile Argiro

Story Editor Peter Schwarz

Designer Amanda Mitchell

Vice President of Communications Robert Horrigan

Editorial Copy Editorial contributions, photos, and miscella-neous inquiries should be addressed and sent to the Editor at CPM headquarters. Please follow the author guidelines posted on the PMI-CPM Web site. Letters submitted to the editor will be considered for publication unless the writer requests otherwise. Letters are subject to edit-ing for style, accuracy, space, and propriety. All letters must be signed, and initials will be used on request only if you include your name. CPM reserves the right to refuse publication of any letter for any reason. We welcome articles relevant to project management. The Measur-able News does not pay for submissions. Articles published in The Measurable News remain the property of the authors.

AdvertisingAdvertising inquiries, submissions, and payments (check or money order made payable to the College of Performance Management) should be sent to CPM headquarters. Advertising rates are $1000 (taken) for inside front or back cover (full-page ad only), $800 for other full-page ads, $500 for half-page ads, and $300 for quarter-page ads. Issue sponsorships are avail-able at $2500 per issue. Rates are good from January 1, 2008 – December 31, 2009. CPM reserves the right to refuse publication of any ad for any reason.

SubscriptionsAll CPM publications are produced as a ben-efit for CPM members. All change of address or membership inquiries should be directed to: PMI Headquarters, Customer Care Depart-ment, Four Campus Boulevard, Newtown Square, PA 19073-3299 • Phone 610.356.4600 • Fax 610.356.4647 • [email protected].

All articles and letters represent the view of the authors and not necessarily those of CPM. Advertising content does not signify endorse-ment by CPM. Please notify CPM for single copy or reproduction requests. Appropriate charges will apply.

© 2008 by the College of Performance Management. All rights reserved.

Advertising Rates

Contact Managing Director Gaile Argiro at PMI-CPM Headquarters for more information:

phone 703.370.7885 • [email protected]

Inside front/back cover ................ $ 1000

Full page ..........................................$ 800

Half page ........................................$ 500

Quarter page ..................................$ 300

Sponsor an issue ............................$2500

Full-page ad only — taken next issue

Size: 5 x 7 inches or 10 x 3.5 inches

Size: 7.5 x 10 inches

Size: 5 x 3.5 inches

includes ads on front and back cover

Table of Contents

Update on RDMBy Fredric L. Plotnick, Esq., P.E., Engineering & Property Management Consultants, Inc. and Drexel University ..................1

From the President…By John Singley, PhD, PMP ................................................................5

Performance Based Payments (PBPs) If it walks, talks, and quacks like EVM … It must be EVMBy Quentin W. Fleming and Joel M. Koppelman, Primavera Systems, Inc. .....................................................................7

Earned Value Forecast Accuracy and Activity CriticalityBy Mario Vanhoucke and Stephan Vandevoorde ..................... 13

IPM-2008: Call for Participation .........................17

The Use and Impact of Earned Value Management on Software ProjectsBy Walt Lipke .................................................................................... 33




Summer 2008, Issue 34 The Measurable News

PMI-CPM GOVERNING BOARD 2008–2010

PresidentJohn Singley, PhD, PMP

[email protected]

Executive Vice PresidentSusan Wood

[email protected]

Vice President of FinanceCathy Ahye

[email protected]

Vice President of AdministrationMarilyn McCauley

[email protected]

Vice President of Conference & EventsBarry Schuler 703.456.0707

[email protected]

Vice President of Education & CertificationJoe Houser

[email protected]

Vice President of Research & StandardsKym Henderson 61.414.428.537

[email protected]

Vice President of CommunicationsRobert Horrigan

[email protected]

Past PresidentNeil Albert

[email protected]

Delivering A New “Steady-State”: Portfolios, Programs and Projects

IPM 200820th Annual International Integrated Program Management Conference November 17–19, 2008Hilton Alexandria Mark Center, Alexandria, VACall 703.845.1010 and ask for “IPM Conference rate”

Co-sponsored by…

JOIN US FOR …

Learn from…• Professional Education Training Seminars• Special Guest Speakers• Tools Tracks• Topical Workshops• Practice Symposia

For program information…

Socialize and network at…• Newcomers Orientation• Speakers-only Reception• All-attendee Reception

Gaile Argiro [email protected] 703.370.7885 fax 703.370.1757 www.pmi-cpm.org




mailto:VPConf&[email protected]





[email protected]




From the President…John Singley, PhD, PMP

I am very pleased to report that the PMI-CPM spring conference, EVM World 2008, held this May on the coast of the Gulf of Mexico in sunny Florida, USA, was our best ever. Over 400 people attended from around the world. For all of the details, please see “Past Events” on the PMI-CPM website (www.pmi-cpm.org), including a link to our

Electronic Library for all of the conference presentations. While you are on the website, consider coming to our fall conference, IPM 2008, to be held this November in Alexan-dria, Virginia, near the USA Capital. This conference is a must for USA federal project managers, as well as all practitioners interested in EVM and Integrated Program Management.

The PMI-CPM spring conference was also the venue for the annual PMI-CPM mem-bers’ meeting. The luncheon meeting was attended by nearly 150 members this year, setting a new attendance record. I was pleased to report to the members that PMI-CPM continues to be financially healthy and able to make excellent progress in improving and delivering professional products and services to PMI-CPM members and to the project management community. My brief annual report is posted on the PMI-CPM website (see “About PMI-CPM”). The annual meeting also provided an opportunity to update members on the PMI Virtual Communities Project.

The PMI Virtual Communities Project continues to unfold, revealing additional details on its poten-tial implications for the PMI College of Performance Management and the other PMI virtual communities [Specific Interest Groups (SIGs) and Colleges]. Just released is the PMI Virtual Communities Project De-liverables Package, the most comprehensive and clear statement thus far on PMI’s plans for all of its virtual communities. This document is a must-read for all PMI-CPM members. It has been posted, with its letter of transmittal from PMI, on the PMI-CPM website at www.pmi-cpm.org under “About PMI-CPM” (click on “Initiatives”). Please give us your comments on these PMI plans by using the Forum on the PMI-CPM web-site or by contacting me directly at [email protected].

• Professional Education Training Seminars• Special Guest Speakers• Tools Tracks• Topical Workshops• Practice Symposia

For program information…

http://www.projectrx.com

http://www.pmassoc.com/


Performance Based Payments (PBPs)If it walks, talks, and quacks like EVM… It must be EVM1

By Quentin W. Fleming and Joel M. Koppelman, Primavera Systems, Inc.

In October 1995, the Federal Acquisition Regula-tion (FAR subpart 32.10) was revised to create a new category of payments to suppliers on fixed-price contracts. They were called Performance-

Based Payments (PBPs). The intent was to move away from potentially high-risk payments based simply on the incurrence of seller costs, to payments based on the physical completion of authorized work. This was a most positive move in the opinion of the authors. To be successful, it required a close working relationship between the buyers and sellers, the technical project managers, and the contracting community to fully define a performance measure-ment plan.

The concept of performance based payments is in fact a simple form of earned value management (EVM). But interestingly, nowhere in the FAR clause or any of the government’s supporting guid-ance documents is the term “earned value” ever mentioned. But if it walks, and talks and quacks like earned value, and it most certainly does, it must be a form of earned value management.

Progress Payments Based on Costs Incurred Under Fixed-Price ContractsFor many years contractor’s doing business with the United States Government (USG) have been receiv-ing interim payments for their work, based not on physical progress, but rather on the actual costs they incur in the performance on a job. Such practices were allowed under the FAR subpart 32.5. The fun-damental and questionable assumption with such payments was the belief that by spending money on a job, that commensurate progress would also be made. Not necessarily.

To be fair, there were a couple of provisions which gave some protection to the USG agencies and prime contractors making these types of pay-

ments. In the first place such payments were legally only interim loans, not final payments to suppliers. So such loans had to be later repaid, or liquidated by the suppliers. Also, payments were made not at full value of the costs incurred, but rather less a with-holding of typically 20%. Yet losses did occur, when payments were made ahead of physical progress and contractors failed to finish the job. Payments were paid at full value and the contractors for various rea-sons failed to finish all of the work, in which case a loss sometimes happened. A better approach to con-tractor financing had to be found and it was.

Performance-Based Payments-PBPs (FAR Subpart 32.10): how they workA new concept of contractor financing came out of the concerns expressed by private industry and the USG initiatives to improve contractor performance. One of the more important improvements was called Performance-Based Payments, or PBPs. It is a form of contractor financing based on the completion of authorized work. PBPs are for use on fixed-price contractual arrangements. The main focus is on the completion of authorized work, taking the form of milestones, points in time. No payments are paid to contractors until the agreed-to milestones are com-pletely finished.

At the time of contract award, or shortly there-after, the contract buyer and performing seller, supported by the technical support people, will sit down and define, negotiate, and agree on a series of milestones which completely defines the work to be done. Then a value is added to each milestone, tak-ing either the form of a percentage or dollar value, the sum of which must add up to the full value of the job. This process takes work, requires detailed early planning, but gets all critical parties working together to formulate a plan against which perfor-mance can be measured. Once the plan is in place

Reprinted with permission from the National Contract Management Association, Contract Management magazine, March 2008 issue.


FIGURE 1. PERFORMANCE BASED PAYMENTS.

A simple example of PBP is illustrated in Fig-ure 1. Here a construction job is broken into eight measurable milestones, with a value listed for each milestone, the sum of which adds up to the total job. As of the reporting period the first two milestones have been completed so the contractor is entitled to a payment of $110,000, less a holdback or retention of 10%, for a net payment to them of $99,000.

The construction industry has used a similar approach … Successfully for years

Interestingly, the construction industry has for many years been employing a type of performance based payments to its suppliers. Also, as with PBPs they typically do not use the term “earned value man-agement” either, but just as the FAR’s approach is similar to EVM, so is the construction payments to suppliers. The construction industry often refers to such payments as a “schedule of values.”

The fundamental difference with the construc-tion industry is the focus of monitoring. With con-struction they define work with use of tasks (bars), work that happens over a period of time. Thus the buyer and seller must agree on completed work as a percentage of completion of each task. This is con-trasted with PBPs which must be 100% complete in

order to receive payment. As with PBPs, care must be taken to not allow for the front-loading of the work tasks, or the over-valuation of completed work. They do not want to allow for over payment of completed work.

In many construction jobs the schedule of values is simply an output re-port from the critical path method (CPM) networks, available with most project management software pack-ages today. An example of a construction schedule of values is shown in Figure 2. This is the same project as

these same people will then monitor performance against their plan. Payments are paid to suppliers based on the completion of work, i.e., completion of milestones.

Each specified milestone can be severable (inde-pendent), or cumulative (dependent on completion of some earlier milestones). Each milestone once ap-proved as complete, is paid at full value, less a 10% withhold which is held by the buyer until the entire job is deemed complete. All payments are contract financing loans, which must be liquidated upon final deliveries or completion of the job. If done properly, PBP can result in less oversight by all parties during the performance period.

However, there are some risks with these type payments. Care must be taken by the buyer to pre-vent a front-loading of payments to the contractors. PBP are a simple form of EVM, but without the full benefits of EVM. They are like EVM in that perfor-mance is measured by the physical completion of authorized work and achieving the budget for such work. But since they are for fixed-price work, actual costs of performance are only available to the seller, not the buyer. Thus, the ability to use performance actuals to forecast final costs is only available to the seller. But that may be alright.


was displayed in Figure 1 using PBPs. Since task 3 with the schedule of values is partially com-plete, the payment to the supplier is greater using a schedule of values than with PBPs. Both con-cepts make payments at full value of work com-pleted, less a withholding or retention until the full job is completed.

PBPs are a simple form of EVM, but missing one key element: Actual costsEarned value management can be a powerful tool in the management of any project where the risks of cost growth exist. But on fixed-price arrangements, only the seller (supplier) of services is at risk for cost growth. The buyer is protected from cost increases by the contractual ar-rangement. As long as the specified work doesn’t change, and the seller can finish the job, there is no risk of cost growth to the buyer on fixed-price ar-rangements.

Thus, with PBPs, the benefits of earned value man-agement rest primarily with the sellers of services, not with the buyers. Nevertheless, both parties can benefit from a project management technique that can be used to define, plan, schedule, budget, status, and forecast the final cost and schedule requirements so that any projects can be successfully completed.

But, from the perspective of the performing seller, PBPs can be a simple but effective form of earned value management. In order to employ EVM, total contract performance must be planned, scheduled, and a budget assigned to all tasks, which will be earned at the time of completion of each task, i.e., when each task milestone is completed. Payments are made not simply on costs incurred, but rather on the completion of authorized work.

Thus if a seller completes a task valued at $100, they can compare the $100 earned versus the actual costs they incurred to complete the task and tell if they are hitting their budget, overrunning or under-running their budget. With EVM cost efficiency is easily determined by the value of work performed divided by the actual costs spent, referred to as the Cost Performance Index or CPI2. If the CPI is 1.0, the project is right on budget. Any CPI results less than 1.0 would indicate they are overrunning their budget. CPI values over 1.0 indicate they are under-running the effort. The CPI is likely the most important of the many EVM metrics which are available, and is considered an “early warning signal” to practitioners.

However, from the perspective of the buyer on fixed-price contracts, they do not see the actual costs of performance. Actual costs spent are only available to the sellers. But it really doesn’t matter since the buyer is only going to pay the budgeted amount for completed work since the arrangement is fixed-price. Remember, the sum of the value of all tasks on PBPs must equal the total value of their contract.

There is one last important point on the utility of EVM to sellers using PBPs. This issue deals with the ability to forecast the final costs to complete a project.

FIGURE 2. CONSTRUCTION SCHEDULE OF VALUES.

2See A Guide to the Project Management Body of Knowledge, PMBOK ® Guide, Third Edition, 7.3.2.2.


With EVM the sellers can quickly quantify what their final costs are likely to be, based on their actual performance to date. The EVM forecast formula: To-tal Project Budget divided by the Cost Performance Index. Thus if the seller is only part way through a contract, as early as only 20% complete, and they have been achieving a CPI of .90, they are likely to overrun this project by about 10%. They had bet-ter change their ways, or they will likely overrun by 10%. They get this important message early, in time to make a difference.

In SummaryWe find it most interesting the fact that Performance Based Payments-PBPs are in effect a simple form of earned value, but nowhere in any government documents do they call it earned value management. But it certainly is earned value. And the beauty to practitioners of earned value is that the technique is scalable. When project managers and technical team members understand the value of tracking their CPI

and other EVM metrics, they will find they have a most useful new tool, which can be used to better manage a simple one hundred thousand dollar proj-ect, or a complex one billion dollar project to a suc-cessful conclusion.

About the AuthorsQuentin W. Fleming is a management consultant specializing in earned value. He has been a consul-tant to the senior staff at Primavera Systems, Inc. since 1993. His personal website is www.QuentinF.com

Joel M. Koppelman is the cofounder and Chief Executive Officer (CEO) of Primavera Systems, Inc. His corporate website is www.Primavera.com

Fleming and Koppelman are the co-authors of Earned Value Project Management, originally pub-lished in 1996 by the Project Management Institute (PMI). Their third edition of this book was released in the fall of 2005. Over 80,000 copies of the book have been sold by PMI worldwide.

3111 North Tustin Avenue, Suite 250, Orange, CA 92865(714) 685.1730 (Phone) (714) 685.1734 (Fax)

Email: [email protected] Website: http://www.humphreys-assoc.com

Earned Value Management Systems

September 9 – 11, 2008 Adelphi, MD

December 3 – 5, 2008 Dallas, TX

2008 Public Seminars

Humphreys & Associates, Inc.A pragmatic, common sense approach to planning and controlling projects

Humphreys & Associates, Inc., is a management consulting firm specializing in Earned Value Project Management. Our experience encompasses the construction and utility industries, energy programs, the aerospace industry, and all acquisition branches of the U.S. Dept. of Defense, and foreign govern-ments. We have consulted and supported over 500 major organizations and trained more than 450,000 individuals. The principles of project management that we espouse are applicable to any project oriented environment. Some of our specific areas of expertise include: Proposal Preparation, Project Scheduling, Performance Measurement, Risk Assessment, Software Evaluation, System Audits, Customer Review Preparations, and Training.

Project Scheduling

October 15 – 17, 2008 Phoenix, AZ

Advanced Earned Value Management Techniques

October 20 – 22, 2008 Lake Tahoe, CA

US Review Team Workshop

TBA

http://www.humphreys-assoc.com

�

SAFRAN’S�“ONE�SOLUTION”�APPROACH�FOR�PROJECT�CENTRIC�ORGANIZATIONS:�

SAFRAN�PROJECT�l�SAFRAN�FOR�MICROSOFT�PROJECT�l�SAFRAN�PLANNER�l�SAFRAN�SCORECARD��

ENTERPRISE�PROJECT�MANAGEMENT�SOFTWARE�AND�SERVICES�FOR:�

ENERGY�AND�POWER�l�A&E/CONSTRUCTION�l�AEROSPACE�AND�DEFENSE��

GOVERNMENT�l�HIGH�TECH�l�ANSI�748�COMPLIANCE�

2132A CENTRAL AVENUE SE #253 l ALBUQUERQUE, NM 87106PHONE: 505.265.2229 l FAX: 505.265.0229 l WWW.SAFRANNA.COM

WWW.SAFRANNA.COM

NORTH AMERICAsimple | flexible | powerful

© Safran North America, LLC, All Rights reserved. All other trademarks mentioned herein are the property of their respective owners

W H A T H A S Y O U R P R O J E C T M A N A G E M E N T S Y S T E M D O N E F O R Y O U T O D A Y ?Too many software companies claim to be all things to all people by piecing together separate modules that provide the desired functionality with integration as an afterthought. SAFRAN provides integrated performance on the most widely accepted and industry tested technology.

SAFRAN PROJECT AND SAFRAN FOR MICROSOFT PROJECTProject management software from Safran provides organizations with superior visibility and insight into how time and resources are spent and into the overall health of their projects. Our solutions provide all of the power and functionality youneed out of the box based on your industry and business needs, integrated from the ground up; not after the fact.

Implementing Safran project management software decreased tangible and intangible project costs, increased efficiency almost 100% in day-to-day project planning and control, and reduced bid preparation times 75% - providing our customers with the competitive edge. From the individual project office to the enterprise, Safran provides the most up-to-date and powerful EPM solution today.

P R O J E C T �MA N A G E M E N T �F O R � T H E � �N E X T � G E N E R A T I O N �

�

http://www.safran.com

www.planview.com/mpm


Earned Value Forecast Accuracy and Activity Criticality

By Mario Vanhoucke1 and Stephan Vandevoorde2

Abstract This paper presents new simulation results on the forecast accuracy of earned value based metrics to predict a project’s final duration. This is the sec-ond paper in a series of papers based on the simulation study initially proposed by Vanhoucke and Vandevoorde (2007a). In a previous manuscript published in the Measurable News (Vanhoucke and Vandevoorde, 2007b), it has been shown that the earned schedule method outperforms, on average, the more traditional earned value based meth-ods to predict the final duration of a project, both for early and late projects. In the current manuscript, the simulation study is extended to new simulation scenarios that measure the influence of inaccuracies in the planned duration estimates for critical and non-critical activities on the accuracy of forecasting methods.

simulation settings. Section 3 compares the new forecast accuracy results with the ones previously discussed in Vanhoucke and Vandevoorde (2007b).

Simulation Scenarios The simulation study uses fictive projects for which an initial baseline schedule is constructed based on the straightforward critical path based calculations. The set of projects is the same as used in the Vanhoucke and Vandevoorde (2007a) research and contains 4,100 proj-ect networks with 30 activities and a varying number of precedence relations. During the simulation runs, the actual activity durations may differ from their original planned values, leading to an overall project finish-ing early or late. During each simulation run, the final project duration is predicted along the review periods during the life of the project by means of the EAC(t) formulas of the three forecasting methods, i.e. the planned value method PV (Anbari, 2003), the earned duration method ED (Jacob, 2003) and the earned schedule method ES (Lipke, 2003). Each simulation run contains 100 repetitions to guarantee convergence. Table 1 shows the four simulation scenarios used in the current paper. The second and third columns describe the change in the original planned duration for criti-cal and non-critical activities (increase, no change or decrease), while the last column shows the simulated effect of these changes on the real project duration.

Since the introduction of the earned schedule method, initially proposed by Lipke (2003), both researchers from the academic world as well as managers dealing with real-world

practical projects have critically analyzed the fore-casting power of the new method for predicting a project’s final duration.

Most research analyzed data from real-life proj-ects and concluded that the earned schedule method can better predict the total duration of a project [see e.g. Vandevoorde and Vanhoucke (2006); Hen-derson (2004, 2005)]. In a previous edition of the Measurable News [see reference Vanhoucke and Vandevoorde (2007b)] we have tested the forecast accuracy of three methods to predict the final project duration on a large and diverse set of fictive projects. We basically reviewed the results of the simulation study published in Vanhoucke and Vandevoorde (2007a) and concluded that the earned schedule method outperforms, on average, the two other methods [the planned value method (Anbari, 2003) and the earned duration method (Jacob, 2003)].

In this paper, new results from the same simula-tion study are presented. These results focus on the accuracy of the three methods for different scenarios measuring the activity criticality. The outline of the paper is as follows. Section 2 reviews the results of the previous simulation study and presents four new

1Ghent University, Tweekerkenstraat 2, 9000 Gent (Belgium) and the Vlerick Leuven Gent Management School, Reep 1, 9000 Gent (Belgium), [email protected] 2Fabricom GTI Suez, Rue Gatti de Gammond 254, 1180 Brussel (Belgium), [email protected]

13



SCENARIO 1: When both the critical and non-critical activities are performed faster than expected or with-out any change compared to the planned duration, the SPI and SPI(t) indicators will report an excellent performance (i.e. SPI > 1 and SPI(t) > 1) and the project will end sooner than expected.

SCENARIO 2: Similar to scenario 1, a project with de-lays for all activities will end later than expected and the schedule performance indicators will report a project delay during project execution.

These two scenarios have been tested in the study of Vanhoucke and Vandevoorde (2007b) and the results have shown that the earned schedule method outperforms both the planned value and earned dura-tion method for early (scenario 1) and late (scenario 2) projects. Moreover, the study has shown that the best forecast accuracy can be reached when the EAC(t) is calculated under the assumption that fu-ture project performance follows the current SPI or SPI(t) trend. Last, the results have also shown that the earned schedule method is stable along the prog-ress of the project, and certainly at the end of the proj-ect, where the other methods show an unreliable trend.

The two following scenarios have not been simu-lated yet and can be interpreted as follows:

SCENARIO 3: when critical activities are performed faster than expected and non-critical activities show delays, it might be possible that the schedule indica-tors report a low project performance (SPI < 1 and SPI(t) < 1) although the project finishes sooner than expected. In this case, many non-critical will be delayed within their activity slack (such that it does not lead to an overall project delay) while only a few critical activities are performed slightly faster than expected. Consequently, the schedule performance indicators will report a false warning signal predict-ing a project delay which turns out to be the opposite at the end of the project (project ahead of schedule).

SCENARIO 4: Similar to scenario 3, this scenario simu-lates project progress where the schedule perfor-mance indicators report a false warning signal. Tiny delays in only a few critical activities combined with faster performance in many non-critical activities obvi-ously leads to a total project delay, while the schedule performance indicators might report the opposite.

These last two scenarios have been inspired by Jacob and Kane (2004) who argue that earned value management indicators have to be calculated at the activity level and not at higher WBS levels. They illustrate their statement with a simple example and conclude that small delays in critical activities combined with much faster progress in non-critical activities can result in a false SPI value (in this case, SPI > 1), and hence, the SPI reports can possibly mask potential problems leading to wrong forecasts. Hence, the authors claim that the only way to obtain accurate schedule forecasting results is by applying the predictive methods on a single activity rather than on groups of activities. In the current study, we measure the earned value based metrics at the activ-ity level, but the schedule performance indicators are calculated at the project level (e.g. the SPI is equal to the total earned value divided by the total planned value of all activities at the current review moment). Although we realize that this approach might poten-tially mask certain project problems or opportuni-ties (cf. scenarios 3 and 4), it is our goal to test the influence of these false SPI values on the accuracy of the three forecasting methods. The results of the scenarios are discussed in the next section.

Simulation Results Figure 1 displays the forecast accuracy results of the simulation runs for all four scenarios. The ac-curacy has been measured as the percentage devia-tion between the actual project duration, measured at the end of each simulation run, and the average

TABLE 1: FOUR SIMULATION SCENARIOS FOR CRITICAL AND NON-CRITICAL ACTIVITIES.SIMULATION RUN CRITICAL ACTIVITIES NON-CRITICAL ACTIVITIES AHEAD OR DELAY?1 Decrease or no change Decrease or no change Project ahead of schedule2 Increase or no change Increase or no change Project delay3 Decrease Increase Project ahead of schedule4 Increase Decrease Project delay


of all duration forecasts EAC(t) measured during the progress of the project. Positive percentage deviations denote an average over-estimation of the real duration and negative percentages denote an average underestimation of the real project duration.3

The results in the figure confirm the previously reported results that the earned schedule method (ES) outperforms on average both the planned value (PV) and earned duration (ED) methods. Both scenario 1 and scenario 2 clearly show a better forecast accuracy close to 0%.

Scenarios 3 and 4, however, clearly show the power of the ES method, compared to the PV and ED methods. These scenarios have been simulated as special scenarios where the schedule performance indica-tors report a false warning signal. Figure 1 shows that this false warning signal has an immediate effect on the accu-racy of the EAC(t) measures, with the ES method show-ing the lowest accuracy. Scenario 3 reports a project delay during its progress, although the project ultimately finishes early. Hence, the indicators clearly show an overestima-tion (due to the false SPI and SPI(t) warnings). In these cases, the forecasts are no longer reliable, which explains the low performance of the ES method. Scenario 4 is similar, but opposite, leading to an underestimation of all forecasting methods, where the ES method has the low-est performance illustrating the unreliable character of the method for this scenario. Consequently, since the SPI(t) indicator is a reliable measure for the project performance along all stages of the project life cycle, the forecast accu-racy is eventually determined by the reported SPI(t) values along the life of the project. In case the SPI(t) reports false warning signals (cf. scenarios 3 and 4), the forecast accu-racy suffers from this error, resulting in a poor predictive quality of the EAC(t) for the ES method. Since the SPI in-dicator is less reliable compared to the SPI(t) (certainly at the late stage of the project, where the SPI indicator tends to go to one, regardless of the real project performance),

the forecast accuracy is more a random guess having an average forecast accuracy which does not vary as much between the four scenarios as for the ES method. Hence, the difference between correct SPI reports(scenarios 1 and 2) and false SPI reports (scenarios 3 and 4) is less than for the SPI(t) indicator in the ES method.

Conclusions In this paper, the forecast accuracy of three methods has been simulated under four different scenarios. The results show that under ‘normal’ circumstances the earned schedule method has the best perfor-mance, leading to small deviations between the du-ration forecast and the final project duration. Normal circumstances are defined as project progress where the schedule performance indicators report reliable results during the life of the project.

However, special scenarios have been simulated to force the schedule performance indicators to report unreliable results. Under these ‘unreliable’ circumstances, the earned schedule method performs worse than other methods. This illustrates the power of the earned schedule method, as the method’s fore-cast is strongly based on the schedule performance indicator SPI(t). Consequently, the ES can be con-sidered as a good forecasting predictor, forecasting the final project project duration in an accurate way

FIGURE 1: FORECAST ACCURACY (EAC(T) UNDER- OR OVERESTIMATIONS) FOR THE FOUR SCENARIOS.

3

and hence, there was no difference between under- and overestimations.


when the schedule performance indicator SPI(t) re-ports a correct warning signal about the current proj-ect performance.

Acknowledgements We acknowledge the support by the research col-laboration fund of PMI Belgium received in Brussels in 2007 at the Belgian Chapter meeting.

References Anbari, F. (2003). Earned value project management

method and extensions. Project Management Journal, 34:12–23

Henderson, K. (2004). Further developments in earned schedule. The Measurable News, Spring:15–17, 20–22.

Henderson, K. (2005). Earned schedule in action. The Measurable News, Spring:23–28, 30.

Jacob, D. (2003). Forecasting project schedule completion with earned value metrics. The Measurable News, March:1, 7–9.

Jacob, D. and Kane, M. (2004). Forecasting schedule completion using earned value metrics revisited. The Measurable News, Summer:1, 11–17.

Lipke, W. (2003). Schedule is different. The Measurable News, Summer:31–34.

Vandevoorde, S. and Vanhoucke, M. (2006). A comparison of different project duration forecasting methods using earned value metrics. International Journal of Project Management, 24:289–302.

Vanhoucke, M. and Vandevoorde, S. (2007a). A simulation and evaluation of earned value metrics to forecast the project duration. Journal of the Operational Research Society, 58:1361–1374.

Vanhoucke, M. and Vandevoorde, S. (2007b). Measuring the accuracy of earned value/earned schedule forecasting predictors. The Measurable News, Winter:26–30.

Author BiographiesDr. Mario Vanhoucke is an associ-ate professor at the Ghent Univer-sity and the Vlerick Leuven Gent Management School (Belgium). He teaches Project Management, Business Statistics, and Applied Operations Research. He is the

program director of the Commercial Engineers and

the advanced Master in Operations and Technology Management. He is partner of the company OR-AS (www.or-as.be), where he is involved in the devel-opment of a project scheduling software package with earned schedule tracking capabilities. His main research interest lies in simulation and optimiza-tion models in project scheduling and scheduling in the health-care sector. He is advisor to various PhD projects, in collaboration with different university hospitals. He has articles published in international journals, such as Annals of Operations Research, Management Science, Operations Research, The Ac-counting Review, International Journal of Produc-tion Research, Journal of the Operational Research Society, Journal of Scheduling, International Journal of Project Management, Project Management Jour-nal, European Journal of Operational Research, and Lecture Notes on Computer Science.

Stephan Vandevoorde is a division manager in Fabricom GTI Suez, for airport baggage handling systems. He has an industrial engineer diplo-ma and is a member of PMI, Project Management Belgium, PMI College of Performance Management, and

director of programs of the PMI Belgium Chapter. He has been working on a number of large-scale international projects (Europe, Asia) across many industries, including construction, retail, automo-tive, and airline. Stephan has extensive experience in using EVM techniques to assist in evaluating and predicting project performance, including the newly developed earned schedule concept. On several occa-sions, he has given presentations on different project management topics for V.I.K., Vlerick Management School, Ghent University, and Boston University, Brussels. In collaboration with the Institute for Busi-ness Development, Stephan is docent for the courses Earned Value Management and Project Management for the Construction industry.

CALL FOR PARTICIPATION

Delivering A New “Steady-State”: Portfolios, Programs and Projects

Join us and share your project performance management knowledge and experiences at the

20th Annual International IPM Conference!

IPM 2008 20th Annual International Integrated Program Management Conference November 17–19, 2008Hilton Alexandria Mark Center, Alexandria, VACall 703.845.1010 and ask for “IPM Conference rate”

Co-sponsored by…

CALL FOR PARTICIPATION

All materials must be in the format described in the Speaker Requirements available at www.pmi-cpm.org/pages/events/IPM08/ keynote_speakers.html. Submit your Abstract and biographies for the following sessions at www.pmi-cpm.org/submit/document.asp.

• Practice Symposia: Lessons learned and best practices on the implementation of Earned Value Management, updated on recent developments and integrating EVM with other management tech-niques.

• Workshops: Workshops provide a forum to introduce and develop new and emerging practices and techniques to im-prove program management using EVM, objectives are to identify potential solutions. Workshops are not intended to provide training or instruction on EVM.

• [email protected] • 703.370.7885 • www.pmi-cpm.org

Barry E. Schuler, PMI-CPM VP Conferences & Events • Simon Dekker, 2008 Conference Program Manager

Speaker Requirements

For General Conference Information

For information to advertise, contact Managing Director Gaile Argiro at 703.370.7885 or [email protected].

www.DekkerLtd.com

see our ad on p. 39

V E N D O R / S E R V I C E S

www.pmassoc.comsee our ad on p. 6

Your ad

could go

here!

V E N D O R / S E R V I C E S

www.deltek.com

see our ad on p. 2

www.humphreys-assoc.com

see our ad on p. 10

www.ProjectRX.com www.primavera.com/products/ costmanager/index.asp

www.arescorporation.comwww.aisc.com

www.systalex.com

[email protected] our ad on p. 11

www.mcri.com

see our ad on p. 32www.galorath.com

see our ad on p. 12www.planview.com/mpm

Your ad

could go

here!

see our ad on p. 5

www.lexemstrategy.com

http://www.DekkerLtd.com

http://www.pmassoc.com/


http://www.humphreys-assoc.com

http://www.projectrx.com

www.primavera.com/products/ costmanager/index.asp

http://www.arescorporation.com

http://aisc.com

http://www.lexemstrategy.com

http://www.systalex.com

http://www.safran.com


http://www.mcri.com



The introduction by IBM of the new computer architecture, including random access memory, pro-vided the ability to rapidly switch between two files, one for activity name and duration, and the other for the predecessor-successor restraints between activi-ties. This advancement permitted the implementation of PDM. However, computers still had quite limited memory and were relatively slow and expensive. Each computation of the critical path was typically an overnight affair and could cost several hundreds of dollars! The advent of the personal computer in the 1980s largely reduced the cost, but in an effort to speed the computation, software designers jettisoned some of the features of the mainframe programs that tended to increase accuracy of the results in certain circumstances. Thus, the ability was dropped to dis-tinguish between starting activity B three days after the start of activity A, a ten day duration activity, versus starting activity B after 30% of activity A was complete.

IntroductionIn the research leading to the release of the 6th edition of CPM in Construction Management, I reviewed the original mathematics from the early 1950s leading to CPM and PERT, and then reformu-lated and expanded both the algorithm for calcula-tions and the formats for data entry and reports. Although some portion of this information may be stored and reported from extensions to existing PDM software, it is important to understand that RDM is as different from PDM as are ADM and PERT. The main distinction is the redefinition of the differences between events, activities and restraints. Additional distinctions range from the introduction of new at-tributes (such as a Just-in-Time start, finish and float, discussed below) to the appreciation that the rela-tionship between two activities is more than restraint between activities (also discussed below.)

Just as CPM and PERT were distinguished from bar-charts and milestone charts by the recording of additional information used to create those charts (and thus automating the process of utilizing that information), RDM is distinguished from the older versions of CPM and PERT by recording more of

that information. This additional information may be generally classified into five additional groups of code fields:• events and event codes• the reason/why restraint code, an additional

description as to the reason why a restraint has been placed between two activities,

• duration codes to explain a given duration and how it should be used in calculations,

• additional and expanded types of restraints be-tween activities (and events), and

• relationship codes to further indicate the rela-tionship between two activities.

Events and Event CodesThe fundamental aspect of RDM is the reintroduc-tion of the concept of an event, or point in time, that was the hallmark of both ADM and PERT, but was eliminated in the implementation of PDM. However, RDM expands the use of events and attributes of events, and largely redefines the concepts of an ac-tivity and a restraint. In ADM, an activity is placed between two events, and an event is properly placed only at the start or finish of one or several activities. In RDM, while an activity is still placed between two events, an event may be placed at the start or finish of only one activity. More significantly, an event may be placed within an activity or be totally independent of any activity. Thus the scope or defi-nition of partial completion of an activity may be noted at such an internal event and true milestones (rather than merely zero duration activities) may be defined.

Events do not have an early start or early finish, nor a late start or late finish. Events, being a point in time, merely have an early occurrence and late oc-currence. Historically, these were referenced as TE and TL, referring to “time-early” and “time-late,” in the early writings on CPM and PERT. A special problem exists in converting “times” to “dates” in most CPM and PERT applications since most calen-dars are discontinuous. Unless the only calendar is a 24/7/365 calendar, then Monday afternoon at 4:00 PM is the same “time” as Tuesday morning at 8:00 AM This issue is exacerbated by weekends, holidays and seasonal shutdowns (11/15 to 3/15.) Thus, a code

Continued from page 1.


field must be reserved for reporting event times as the preceding (evening) or succeeding (morning) date associated with that time. (As an aid to memory, it may be remembered that Genesis reports the date of creation to be “the evening and the morning of the first day.”)

A number of event code fields in RDM are de-voted to recording whether an event is preceded or succeeded by an activity, counting the number of restraints preceding and/or succeeding an event, and similar tallies. These may include counting “exclu-sive predecessor restraints” and “exclusive successor restraints” where such are the sole restraint emanat-ing from or to the event at the other end of the re-straint. Where several events “exclusively” share the same predecessor events, these may be designated as concurrent events, similar to the ADM i-node com-mon to several activities.

The TE (time-early) of an event in ADM or PERT, or ES (early start) of an activity in ADM or PDM, is calculated as the latest TE or ES of all predecessors. This is so for most events in RDM. However, RDM also recognizes other choices for independent events not linked at the beginning or end of an activity. These choices include:• Do upon the completion of the 1st, 2nd, nth, or

last predecessor (note last is traditional default,)• Follow restraint ONE if 3rd event status is (not

occurred, occurred,) otherwise restraint TWO,• Follow restraint ONE if 3rd activity status is (not

started, started not finished, finished) , otherwise restraint TWO,

• Follow restraint ONE if random number w/i set limit, otherwise restraint TWO, and

• Follow restraint ONE if random number w/i limit #1, TWO if w/i limit #2, N if w/i limit #N, other-wise default restraint.

Note all but the first group of choices indicates multiple possible logic paths and the possibility of loops. The first group of choices also requires an alter-nate event to which restraints from subsequent triggers will lead in order to avoid a logical open end.

Reason/Why Restraint Code, Other Restraint Codes and Restraint Description FieldsThe second fundamental aspect of RDM is the sys-tematic recordation of the reason why a restraint has been placed between two activities. This is ac-complished by the provision of a reason/why code to each restraint and by further provision of a title or description field and user defined code fields to re-straints similar to that provided to activities.

In PDM, the distinction between an activity and restraint may be quite blurred, especially if a re-straint has been assigned a lag duration between activities. The main distinction is that to an activity may be assigned a title or description, while it is not possible to record any information relating to a re-straint other than relating to its predecessor, succes-sor, and quantum of lag duration. Another distinction is that durations of activities are generally measured by performance of the activity (in either days per-formed, days remaining or percent complete), while durations of restraints (lags) are generally measured by the passage of units of time (days) from a report-ed commencement (date).

RDM permits, encourages, and perhaps even re-quires some level of explanation or description be given to restraints as well as activities. At the very minimum, RDM will request whether the reason for the restraint is “physical” or “hard logic,” thus indi-cating that A must be performed before B (with ex-amples such as “gravity” or “owner’s specification” being the why for the restraint,) or that the reason for the restraint is “resource limitations” (with the specified resource, e.g. crew, craft, access, dollars, etc., being the why for the restraint), and that the superintendent or project manager merely chooses to perform A before B (as being the most economi-cal of possible choices). It is envisioned that RDM software will, if the description field is left blank, optionally provide a text description of “PREDS 1000, 1005; SUCCS 1015, 1020.” Other specialized reason/why code values are discussed below.

In ADM, restraints may emanate only from the end of an activity and conclude at the beginning of another activity. In PDM, restraints may emanate


from either the beginning or end of an activity and conclude at the beginning or end of another activity. In RDM, a restraint may emanate from the begin-ning or end or from within a partially performed activity and conclude at the beginning, end or within another activity. Therefore RDM will distinguish between starting B five days after A is started and performance reported on A (by either reporting a percent complete or a remaining duration being five days less than the original duration provided). Restraint durations in RDM may thus be deemed independent of or dependent upon the activity from which or to which such duration runs.

Duration CodesRDM permits (requires) more detailed informa-tion relating to the durations of both activities and restraints. Durations of activities may be further defined by use of an activity calendar or resource calendar. Durations of restraints, independent of measurement of activity progress (being measured solely from a reported activity start or finish date) may also be further defined by use of an activity calendar. Durations of restraints dependent upon the measurement of activity progress (being measured by units of scope performed, estimates of remaining duration, or percent of scope complete) are based on the calendar of the activity upon which such mea-surement is based.

Durations are also subject to three other assigned characteristics. These are:• Interruptible/continuous, • Performed/clocked/clock-checked, and • Out-of-sequence modified-logic/retained-logic/

progress-override. The interruptible/continuous attribute to duration

determines how the early start of an activity is to be calculated. If an activity is restrained by a finish-to-finish or start-to-finish type of restraint or by a con-straint pushing early finish beyond the calculation of early start plus remaining duration, there is a ques-tion whether the early start should remain as calcu-lated based upon its predecessors (and thus the span of time from the start of the activity until its comple-tion, including active and inactive periods of work, will be greater than the original duration entered), or should the early start be delayed until work may

be performed continuously. The primary purpose of such designation is to define the early start date to be used by successor start-to-start or start-to-finish restraints emanating from the activity.

However, both early start dates should be calcu-lated and recorded, even though only one may be used for determining the start of subsequent start-to-successor restraints. The knowledgeable practitioner may desire this information to utilize the additional start-float of the activity, or to start between the two early start dates with the hope to encourage the pre-decessor-to-finish activity to finish early. It is also recommended that software provide some indicator (by use, for example, of a “*” or italicized date text) where two possible early start dates may be reported, and some other indicator (by use, for example, of a “†” or underlined date text) where the activity is suc-ceeded by a start-to-start restraint, and thus it would be important to begin work “ASAP” even if such would require work on the activity to be interrupted.

The performed/clocked/clock-check attribute to duration determines how the duration is to be de-creased during updates. Most activities have scope where performance may be measured for purposes of updating. However, some activities, such as cur-ing of concrete or awaiting review of submittals by the engineer, are not subject to measurement and are typically updated by counting the number of days (or other unit of time) from a calculated or reported start date. This can be especially bothersome where the duration is greater than the period of an update, such as a 28 or 56 day cure period, or a 45 day review period. Updating in the field thus requires a manual count of such days, which is often missed and not re-ported, resulting in errors in the updated schedule.

Inclusion of the performed/clocked/clock-check attribute permits the scheduler to identify these types of activity while developing the logic network, thus reducing the effort for updating to that of recording an actual start where the attribute is set to clocked. A special case is provided where progress contin-ues automatically with the clock, but a visual check should be made to assure completion, such as for return of an approval of a submittal. The clock-check attribute will thus reduce the duration automatically to one day (or other time unit) requiring a manual entry of actual finish date (or zero remaining dura-


tion) when such is visually confirmed. Where the attribute is set to performed, updating is achieved by visual review and entry of remaining duration or per-cent complete.

The out-of-sequence modified-logic/retained-logic/progress-override attribute to duration also determines how the duration is to be decreased dur-ing updates. If an activity starts prior to the finish of its predecessor (or prior to the start of its predeces-sor where such is by a something-to-start restraint,) there is a question whether the CPM algorithm should calculate that work should stop on the started activity until all predecessors are complete, or may continue without regard to completion of predeces-sors. The first option is known as retained logic, the second as progress override. As discussed previously by the author at the PMI College of Scheduling con-ference in 2004, and thence elsewhere, a third option to be considered is modified logic. This modified logic calculates the early (or continuing) start of the started activity as the “datadate”, but sets the early finish as the latter of DD+RD or the early (contin-ued) start as calculated by the retained logic algorithm. (This “third way” was first introduced as “modified progress override,” and was later renamed “modified retained logic.” In internal discussions with Primav-era it was again renamed as “modified-logic.”)

While it has been suggested that the new modi-fied-logic algorithm should become the standard and that there should be no further need for the original two choices, there are situations where the older algorithms better approximate the real world. An example is where a restraint between activities is based solely upon allocation of resources, such as where the logic sequences the work of a painter from one room to another, and a second painter is hired and begins work on Room #2 before Room #1 is fin-ished. We would expect that the second painter could continue work on the day after the CPM update even though Room #1 is not yet completed. In fact, this re-straint could then be ignored in all future updates — while the painting of Room #1 may be required be-fore electrical and HVAC trim and possibly many other activities, the path to project completion will not run from painting Room #1 to painting Room #2. Assuming a robust software program for implemen-tation, the attribute could be set to progress override,

or at least highlighted for review, wherever the rea-son provided for the restraint is “resource.”

Calendars of Durations of Activities and RestraintsDevelopment of a calendar for use in scheduling algorithms is a complex and complicated endeavor. One of the most difficult issues is to set a minimum unit of duration for the calendar. On some projects, including most construction projects, the minimum duration is one day. If the work day begins at 8:00 A.M. and all the predecessors of an activity are expected to be complete by 10:00 A.M., the super-intendent will not typically mobilize the labor crew and other resources for that activity until the next morning at 8:00 A.M. Similarly, even if the work is being performed 24/7/365, if such work is being per-formed in three shifts per day, crews and resources are typically not mobilized for usage in the middle of a shift, but are deferred until the start of the next shift after completion of all predecessors to the new activity to be performed.

For other projects, including most design proj-ects, the minimum unit is one hour. Similar to the discussion for construction, few managers would become distressed if an engineer, receiving data re-quired to provide the next step of a design at 10:17 A.M., will continue to work upon and then button up other work being performed before commenc-ing upon the new design work at 11:00 A.M. Even if the minimum unit is one second, so long as some tasks may be completed in other than an increment of the minimum unit, this issue of elongation (rather than truncation) of the duration to the next incre-ment must be considered in development of a CPM algorithm calendar. However, in a production line or emergency setting, the period of elongation may be reduced if not eliminated and meaningful work can be commenced immediately upon completion of a predecessor activity.

As projects grow larger and are combined with other projects into programs and enterprise-wide programs, the issue grows more complex. A fast-track or design-build project calendar must contend with an hourly (or quarter-hourly) calendar for the

Continued on p. 24

Summer 2008, Issue 324 The Measurable NewsThe

Measurable News

designers as well as a daily (or shift) calendar for the construction crafts. While a robust calendar system will be able to accommodate two and three shifts per day, and hourly and sub-hourly minimum durations, the transfer between such calendars is best per-formed at the zero duration point-in-time event.

Types of ActivitiesAlthough not presented as a new element instituted with the introduction of RDM, the existence of dif-fering types of activities should be noted at this point. Durations of activities, the performance of which utilize resources, may be via an activity based calendar or upon a resource based calendar or calen-dars. Thus an activity may be performed on any day (or other time unit) where resources are permitted onto the project site (or the extended site where the activity is to be performed,) or may be limited to days when a resource or multiple resources are avail-able. If the duration is driven by multiple resources, then it must be further determined if progress may continue when any one of multiple resources are available, or only when all required resources are concurrently available.

Types of Restraints In PERT, there are no activities, only events and restraints (with or without durations) between such events. In ADM, events are connected by activities of specified duration (which also carry logic between events,) and restraints of zero duration. In PDM, it is generally understood that there are no events, but rather only activities (of specified duration) and restraints (with or without durations) between activi-ties. These restraints are generally understood to em-anate from the start or the finish of one activity and connect to the start or finish of another activity. Thus the four types of restraints available in current popu-lar CPM software are usually listed as finish-to-start, start-to-start, finish-to-finish and start-to-finish.

The belief in a limit of four types of restraints between activities is not totally correct. This is evidenced in the papers by Dr. Fondahl (credited with the development of PDM in the 1950s) and the mainframe computers software programs in the

late 1960s, 1970s and early 1980s. These programs distinguished between a Start restraint (delaying the start of the successor activity until OD-RD equals the lag duration – which must always be less than the duration of the predecessor activity), and a Be-gin restraint (measuring the lag duration based upon clocked time units from the reported start date.) Sim-ilarly, the programs distinguished between a Finish restraint (delaying a portion of the successor activity equal to the lag duration – which must thus always be less than the duration of the successor activity) and an End restraint (measuring the lag duration to delay the last moment of the successor activity.) The Start and Finish type restraints could be expressed in percent of predecessor and successor duration re-spectively. The Begin and End type restraints, how-ever, could only be expressed in time units.

Interestingly, it was the Begin restraint that morphed to the current start-to-start restraint, and the End restraint that morphed to the current finish-to-finish restraint. Certainly, the programming ef-fort required to effectuate such types of restraints is simpler, as there is no need to check that the lag du-ration is less than the activity duration of the prede-cessor or successor activity respectively. Therefore, the current restraint choices may all be classified as independent of the duration of the activities.

On the other hand, the old Start and Finish type of restraints may be expressed as percents of the prede-cessor and successor activity durations respectively (and must thus be verified as being less than 100% of such durations). Accordingly, these may be as dependent upon the duration of the activities. Since the old Start restraint type involves partial perfor-mance of the predecessor activity duration, RDM has renamed it to a “Partial-to-Start” restraint type. Similarly, since the old Finish restraint type involves deferring a portion of the successor activity duration until the finish of the predecessor activity, RDM has renamed it to a “Finish-to-Partial” restraint type.

Data collection and reporting for these two redis-covered restraint types may use any one of several formats. For the Partial-to-Start restraint duration, measurement may be by:• Time units of the predecessor activity performed

before successor activity may begin,

Continued from p. 22


• Percent of predecessor activity duration performed before successor activity may begin,

• Fraction of predecessor activity quantity performed before successor activity may begin, or

• Time units of the predecessor activity remaining to be performed before successor activity may begin.

For the Finish-to-Partial restraint duration, measure-ment may be by:• Time units of the successor activity duration re-

maining to be performed after finish of the prede-cessor activity,

• Percent of the successor activity duration remain-ing to be performed after finish of the predecessor activity,

• Fraction of the successor activity duration remain-ing to be performed after finish of the predecessor activity, or

• Maximum time units of the successor activity du-ration that may be performed prior to finish of the predecessor activity.

Exacerbating the issue are several questions relating to restraint durations. Obviously, the Partial-to-Start and Finish-to-Partial type of restraints are tied to the calendar of the activity, of which the restraint dura-tion is a subset of the activity duration. The Start-to-Start and Finish-to-Finish type of restraints must be assigned their own calendar, as well as the Finish-to-Start and Start-to-Finish restraint types.

Partial-to-Start and Finish-to-Partial type of re-straints will mimic the activity to which duration is tied with regard to interruptability and means of measurement (performed/clocked/clock-check,) while SS, FF, FS and SF type of restraints will de-fault to continuous and clocked by definition.

In situations of out-of-sequence progress, Partial-to-Start and Finish-to-Partial restraint durations will be linked to the modified-logic/retained-logic/prog-ress-override choice of the respective predecessor or successor activity duration. However, where mea-surement of the restraint duration is independent of the measured progress of the predecessor or succes-sor activity, such as for SS, FF, FS and SF restraints, the same issues for measurement of restraint durations arise as for activity durations performed out-of-sequence.

When considering all of these issues, there are some six types of restraints between activities with each having three or four sub-types. Note a seventh

type (Partial-to-Partial) is listed but would not be used due to the need for two restraint durations and restraint duration codes and the difficulties of such implementation. However, a fix is provided for such situations. A similar fix may be provided if two types of restraints are indicated, such as “start activity B three days after 50% of activity A is complete.” The listed restraints are:• Finish-to-Start – update restraint duration by

clocked time units from predecessor activity• Update restraint duration always from calculated

early finish of activity• Update restraint duration from actual finish of

activity if reported• Update restraint duration to minimum of ONE

until calculated early finish equals data-date • Start-to-Start – update restraint duration by


early start of activity• Update restraint duration from actual start of ac-

tivity if reported• Update restraint duration to minimum of ONE

until calculated early start equals “data-date.”• Partial-to-Start – update restraint duration from

progress of predecessor activity• Restraint runs from event within predecessor ac-

tivity at duration from event at activity start• Formats: time units complete, percent complete,

quantity units complete, time units remaining• Finish-to-Finish – update restraint duration by


early finish of activity• Update restraint duration from actual finish of

activity if reported• Update restraint duration to minimum of ONE

until calculated early finish equals “data-date.”• Finish-to-Partial – update restraint duration from

progress of successor activity• Restraint runs to event within successor activity

at duration to event at activity finish• Formats: time units remaining, percent remain-

ing, quantity units remaining, time units complete• Start-to-Finish – update restraint duration by

clocked time units from predecessor activity


• Update restraint duration always from calculated early start of activity

• Update restraint duration from actual start of ac-tivity if reported

• Update restraint duration to minimum of ONE until calculated early start equals data-date

• Partial-to-Partial – theoretical – would require two restraint durations

• Fix is to run Partial-to-Start to independent event, then Finish-to-Partial to successor activity

The decision on how to designate the type and sub-type of a restraint, to avoid confusion amongst individ-uals familiar with the limited choices of PDM, remains an open question. One possible solution involves two codes, one for type of restraint and the other for type of restraint duration (or lag.) These may be expressed (with ## being a number) as: FS##E, FS##A, FS##M, SS##E, SS##A, SS##M, PS##C, PS##P, PS##/##Q, PS##R, FF##E, FF##A, FF##M, FP##R, FP##P, FP##/##Q, FP##C, SF##E, SF##A, SF##M.

Relationship CodesWhile the event, duration, reason/why and expanded lead/lag codes all involve additional recording of the information recognized (but perhaps not expressed) by project managers and their team members in crafting a CPM (or any project plan or schedule,) the relationship code is one that is generated during the calculation (by hand or computer) of a CPM. The purpose of the relationship code is to ascertain or calculate the relationships between the predecessor and successor activities (and/or events) of a restraint. Any similarity or difference between the predeces-sor and successor may be noted and reported. The quantity or quality of differences may also be noted and reported. Actions, either manually or via the com-puter software implementation, may be performed based upon the noted similarities and differences.

A simple use for a relationship code may be to highlight whenever a user defined activity code, such as code for which subcontractor is performing work, changes. Since the prime contractor is responsible for coordination of (or between) subcontractors, but not responsible for the internal coordination of a subcontractor’s scope of work, these are the “hand-offs” which must be carefully watched. This is per-haps similar to a game of football – it is rarer that a

turnover will occur while running with the ball – it is more common to have a turnover while passing the ball. Since the typical bar-chart display of a schedule does not provide an easy view of the relationships with other activities, it is all the more important that those restraints revealing such “handoffs” be high-lighted.

Handoffs between entities that have previously encountered problems, such as perhaps that between the mechanical and electrical subcontractors, may be highlighted as calling for a 1-day coordination peri-od (on a 5-day/week calendar.) A more advanced use may be to assure that there exists at least a 2-day lag (on a 5-day/week calendar) when a crew moves from one location to another in order to account for the necessary mini-demobilization and remobilization, tearing down and rebuilding of scaffolding, etc.

Another use is as a means to root out possibly miscoded “P” physical reason restraints where relationships indicate the same resource usage but differing locations or struc-tures. Similarly, any significant change in location for a “physical” type of restraint should be flagged for further review. However, it is beyond our predictive powers to anticipate all the uses that a new generation of schedulers may make for the implementation of such a relationship coding algorithm.

For example, the means to communicate a “hand-off” between subcontractors may be by using an alternate font (say italic and green) for the predeces-sor and successor activity descriptions and a logic line between bars (on the bar-chart view) or activity boxes (in pure logic view) in an alternate aspect (say dashed and green, with dashed and red indicating a “handoff” that is on the critical path). Also flagged “P” physical reason restraints may be in a blinking font during the diagnostic review.

Additional AttributesThe advent of PDM, where the calculated early fin-ish of an activity may be driven by a finish-to-finish restraint rather than the early start plus duration, and the calculated late start driven by a start-to-start restraint rather than late finish minus duration, re-quires the recognition of several new activity attri-butes. These include a Start Total Float, Finish Total

Continued on p. 28

EVM World 2009PMI-CPM 25th Annual International ConferenceMay 27–29, 2009 • Naples Grande ResortNaples, FL • 888.422.6177www.naplesgranderesort.com • www.naples-florida.comCPM Members: Early $600 • Regular $650Non-CPM Members: Early $700 • Regular $750Hotel: Government Rate — prevailing per diem Corporate Rate — $169

Delivering A New “Steady-State”: Portfolios, Programs and Projects20th Annual International Integrated Program Management Conference November 17–19, 2008Hilton Alexandria Mark Center, Alexandria, VARegistration: Early $700 • Regular $750Hotel Rate: $143 (phone 703.845.1010)http://www.pmi-cpm.org/pages/events/IPM08/conf_program.html

IPM 2008

Plan Ahead…Make your budget requests now for the best conferences on Earned Value Management!

PMI-College of Performance Management • 101 South Whiting Street, Suite 320 Alexandria, VA 22304 • 703.370.7885 • 703.370.1757• www.pmi-cpm.org


Float and Most Critical Total Float, hereafter notated at “STF”, “FTF” and “TF.” Many popular CPM soft-ware programs will permit the user to calculate one (and only one) of these three choices, while all three are of value to the knowledgeable scheduler.

For most applications, the TF attribute is the one that the scheduler and project team will review. However, the STF and FTF attributes also convey information. An overly high FTF value is indicative of a “hidden” open end, where the activity does not have a finish-to-something successor, and thus need never finish. This open end may be caused by poor initial logic, or may not be discovered until updating the project when work is performed out-of-sequence and choosing a “progress override” calculation al-gorithm. An overly high STF value may similarly be indicative of a “hidden” open end (assuming use of interruptible activity durations.) The very fact that the STF does not equal the FTF conveys real infor-mation to the scheduler (and project team) that the activity completion is driven by restraints and not by activity duration. (Thus increasing resources, provid-ing overtime, etc., will not speed the completion of this activity!)

RDM complements these features with additional attributes. The early start and early finish attributes represent the earliest times that an activity may start or finish, based upon the data-date. The late start and late finish attributes represent the latest time by which an activity must start or finish if earliest pos-sible project completion is not to be delayed. These attributes are typically denoted as ES, EF, LS and LF. Similarly for an event, the attributes time-early time and time-late time (TE and TL) represent the earliest time that an event may occur, based upon the data-date, and latest time by which it must occur, if not to delay completion of the project.

RDM adds a middle set of attributes for the lat-est time by which an event or activity must occur, start or finish, so that a specified successor event or activity may occur, start or finish as early as though this restraint did not exist. These attributes are thus

called just-in-time time, just-in-time start and just-in-time finish. These attributes are denoted as TJ, JLS and JLF. The new attributes, in turn, are used to cal-culate additional just-in-time total float attributes of SJTF (equal to LS-JLS,) FJTF (equal to LF-JLF) and JTF (equal to the more critical of the two.)

Specialized Reason/Why CodesThe means by which a restraint is designated as not to drive its successor (assuming its successor does have another predecessor which is driving,) is to set the restraint reason code “J” as for “just-in-time.” This is a specialized version of the “P” physical restraint, and will be treated as a “P” reason for all other purposes other than during the backward pass calculations. During the backward pass calcula-tion, the normal RDM algorithm of {LFPRED RE-STRAINT = LSSUCC ACTIVITY} is changed to {LFPRED RESTRAINT = ESSUCC ACTIVITY.} The resultant TJ, JLS and JLF times calculated will therefore be somewhere between the early and late times. If the restraint carrying the “J” reason is the sole restraint following a preceding event or activ-ity, the JTF of the restraint will equal the free float (“FF”) of the restraint or immediate preceding event or activity. However, that is where any similarity of JTF to FF will end; the JTF will continue backward through the string of activities leading to the des-ignated restraint, while the FF attribute is non-zero only for the last activity in the string.

Another set of specialized restraint reason codes relate to automated resource leveling routines and are generated by the RDM leveling algorithm to se-lectively replace and augment an “R” or “resource” reason. The first is the “S” or “suppressed” reason. When leveling upon a selection of a single resource, or multiple recourses, the first step of the scheduler should be to carefully review all restraints and delete those which carry those resources. If this is not done, the leveling routine is “hard-wired” to allocate the resource when released by a completed activity to a specific activity seeking resources, rather than allow-ing the computer to choose the most advantageous allocation. The RDM leveling algorithm therefore first converts all restraints from “R” to “S” where the “why” is any of the resources being subjected to the leveling algorithm.

Continued from p. 26


The RDM leveling algorithm then augments the specified logic restraints with additional restraints indicating from which activity the last resource was released that now permits the new successor activ-ity to proceed. These added restraints are provided a reason code of “L” or “leveled.” In viewing the pure logic diagram or other graphics thereafter, the scheduler may see the logic used by the leveling algorithm. The scheduler may choose to display, or not, the suppressed “S” logic, to see where it has been replaced, or confirmed as being correct (where the “S” restraint is alongside an “L” restraint.) Upon rescheduling or re-leveling, all “L” restraints are de-leted, all “S” restraints are reset to “R” and then may be set again to “S” depending upon the parameters of the scheduler’s request for leveling.

Specialized Types of EventsAs previously noted, the concept of events is central to a proper logic network and therefore to RDM. A number of limitations of CPM may be remedied by use of specialized types of events. In the original ADM version of CPM and in PERT, where two or more logic restraints or activity arrows (also carrying logic) or any combination thereof enter an event (or node,) processing stops until the early finish of each such re-straint or activity has been calculated. Then the early start of the event, and subsequent restraints or activi-ties, is calculated as the latest of such early finishes.

There are other possible outcomes for the merging of two logic paths, as discussed in the GERT litera-ture of the 1950s through the present, but not readily available in commercial software products. Several specialized event types, supported by fully function-al RDM, are discussed here.

The first of the specialized event types to be dis-cussed is setting of the early occurrence time based upon the 1st, 2nd, nth, or last early finish of multiple predecessor restraints. In the default setting or event type, the early occurrence of an event having mul-tiple predecessor logic will be the last or latest early finish of all such predecessors. However, an event type may be coded to set the early occurrence of the event to the first, second or nth early finish of all such predecessors. Part of the algorithm for imple-mentation of this feature includes the diagnostic to assure that none of the predecessors are “exclusive”

or emanating from activities that are not followed by some other successor in such manner to not create an open end.

A second class of special event types is to provide a choice of successor logic strings from an event, rather than indicating that all activities follow-ing such event may now be performed. This is the GERT “·OR·” statement to complement the PERT or CPM “·AND·” statement. The choice of logic restraint successor may be by a random number gen-erator (RNG) or by an explicit statement tying such to some attribute of another event. As examples, “A will be followed by B if RNG is ≥90%, by C if RNG is ≥50%, else by D,” “A will be followed by B if ac-tual finish reported for D, otherwise C.”

Other specialized event types include those re-quired to implement those discussed above, such as to provide closure to a string of activities that may be abandoned based upon the circumstances encoun-tered, and to reenter a loop, such as where a test, previously failed, is now to be retaken.

Specialized Types of Activities There are also a number of specialized activity types, many of which have been implemented in commercial software products, some of which have not. Activity duration is usually based upon a project calendar indicating when the activity may occur. Of-ten, the determining factor for performance is when the chosen resources for such activity are available. Thus, commercial software, such as that marketed by Primavera Systems, provides a choice between having an activity duration driven by the project calendar or driven by the calendar of a resource. Prior versions of Primavera also provided, when two or more resources may be considered as driving, a choice between the copulative and disjunctive, or between requiring all driving resources to be present to advance progress for one time unit, and requir-ing any one of several such driving resources to be present. These were known as meeting and indepen-dent activity types respectively. However, even if all driving resources are available for a specific time or date, the activity calendar must still permit work to be performed for that time period.

Other specialized activity types may include ham-mocks, with or without logic checking, steps or


tasks, and fragmented activities. Hammocks tradi-tionally have not carried logic, but rather have been used to summarize a group of activities between two points in time. In ADM and PERT, this was accom-plished by drawing the hammock between two event nodes; in PDM this was approximated by insertion of an activity restrained from the start of one activity and restraining the finish of some other activity. Tra-ditionally, a manual or automated check is also made to assure that the hammock spans actual logic and is not merely connecting any two events or activities. Misuse of hammocks in commercial software, that does not provide this type of validation check, can lead to the humorous instance of update progress on one chain of activities leading to the start of a ham-mock leading to non-progress on a separate chain of activities leading to the finish of the hammock, caus-ing the hammock to report a negative duration.

Since hammocks are typically used for manage-ment oversight, rather than day-to-day field opera-tions, the occasional error introduced by the lack of logic validation may perhaps be tolerated. However, the miscommunication to senior management that one milestone leads to another, rather than that it has merely been planned to occur prior to the other, should be noted as a different activity type than a proper hammock.

The concept of “steps” or “task” activities is to split an activity into two or more such tasks which each contribute to the total duration of the activity, but cannot be quantified as to timing within the ac-tivity. An example is the card game of “52 pickup” where we can estimate the total duration for picking up all the cards, and we can estimate the duration for picking up any subset of the cards, but we would not normally specify a sequence or order of pick-ing up such cards. Thus, since face cards represent 4/13th and number cards 9/13th of the total (or 31% v 69%,) if we were to report that we have picked up 1/3rd of the face cards and 2/3rd of the number cards, the step algorithm will compute that 56% of the activity has been complete and calculate the ap-propriate remaining duration.

The reintroduction of logic validation for ham-mocks permits another new feature of RDM, that of a hammock that does carry logic and a given dura-tion, but with its remaining duration determined

by the reported progress of the activities within the hammock. This is designated a Pacing Hammock and treats a group of activities having common (if not immediate) predecessor and successor events, as connected by the pacing hammock, much like the “steps” of a single activity. An example where this may be useful is where several pumps may be rigged, set, piped, powered, etc., onto a common foundation slab. Because the various activities may be performed by differing crews or subcontractors, they must be separately itemized. However, although only one or two pumps are rigged, etc. at a time, the order is not subject to pre-planning and will depend upon field conditions or chance. Thus the total time of these parallel chains of activities will be greater than the duration of any one chain. The algorithm behind the pacing hammock totals the original and remaining duration of all activities which have a common predecessor event and common successor event, compares such as a percentile, and applies that percentile to the original duration of the pacing hammock to determine its remaining duration.

Unlike a traditional hammock (with or without logic validation,) a pacing hammock contains op-erational information and should be printed on field reports, and such may still be too detailed for man-agement reports. Perhaps a different name should be applied to distinguish the two types of hammock. A similar issue should be noted for the activities that are part of pacing hammock. It may be desired that the detail of these activities, or fragments, should be generally be masked from reports on the entire project and reserved for detailed “three week look-ahead” and similar reports.

Specialized Types of Restraints In ADM, the only means to split the scope of one ac-tivity into two or more sequential scopes is to physi-cally split the activity into two or more activities. In PDM, a scope may be so split explicitly by a percent-age-complete-type of start-to-start restraint (as with the 1970s MSCS software system) or by implication with currently available commercial software such as Primavera. (Note that Deltek’s OpenPlan software currently supports a percentage-complete-type of start-to-start restraint, but does not support a match-ing finish-to-finish restraint.) RDM accomplishes


the split by explicitly using a partial-to-start restraint which creates an event node within the preceding activity (and similarly supports a finish-to-partial restraint which creates an event node within the suc-ceeding activity). These event nodes may then be further annotated by including an explicit explana-tion of how the scope has been split in the event de-scription field.

RDM also considers the situation where two (or more) sequential activities are combined into one continuous activity. This is analogous to setting the activity duration code switch to continuous rather than interruptible. The virtual linking of these activi-ties is accomplished by use of an additional special-ized type of restraint, designated as a Contiguous restraint type.

A similar result may be accomplished using ex-isting commercial software products by use of a free-float-constraint, assuming that the activity to be deferred until a successor activity may start has no other successors. The RDM activity preceding the contiguous restraint may have other successors, and they too will be deferred until the successor to the contiguous restraint may start.

Another specialized type of restraint introduced in RDM is the Concurrent restraint. This indicates that two or more activities must be performed con-currently. As is understood in CPM, the fact that two activities share the same predecessor does not guarantee that they must be performed concurrently, but only that such is possible. Once the common predecessor(s) of the two are finished, each of the two may be performed independently. The concur-rent restraint changes this and indicates a common dependency, such as the placement of an MSE wall and backfill of such wall, or the activities of a sur-geon and anesthesiologist.

Other specialized types of restraint may be added as users desire, such as a Duplicate restraint combin-ing the start-to-start and finish-to-finish restraints and similar to the old MSCS “Z” restraint. However, discussion of support for such extensions should be left for another day.

Where to NextOne of the disappointments of PDM has been the lack of standardization in notation and calculation algorithms such that the same information fed to two software products may provide differing results. In an effort to minimize this type of problem for RDM, a standard on both notation and calculation algo-rithms is being developed and will be administered via a Certification Trademark RDCPM™. Public comment on the draft standards, as promulgated in this paper, are welcome and should be sent to [email protected].

ConclusionThe RDM or Relationship Diagramming Method variant of CPM can provide a robust and mathemati-cally sound improvement to the field of Planning and Scheduling. It is currently being examined for imple-mentation by software vendors, such as Primavera Systems.

Author BiographyFredric L. Plotnick, Esq., PE, is CEO and principal consultant of Engineering & Property Management Consultants, Inc. He has bachelors, masters and doc-toral degrees in civil engineering and is a registered Professional Engineer in Pennsylvania, New Jersey and Florida. He is also an attorney and a member of the Bars of Pennsylvania, New Jersey, and Florida. Mr. Plotnick is an adjunct professor of the depart-ments of Engineering Management, Civil Engi-neering, and Construction Management at Drexel University, Philadelphia. He is a past president of the Philadelphia Chapter of the Pennsylvania Soci-ety of Professional Engineers and a past Construc-tion Group Chair of the Philadelphia Section of the American Society of Civil Engineers. Mr. Plotnick is currently Director of Academic Liaison and Chair of the Technical Research Track of the annual con-ference of the PMI Project Management Institute’s College of Scheduling, as well as a regular speaker for the PMI College of Performance Management and the AACEi Association for the Advancement of Cost Engineering International. Additional information may be found at www.fplotnick.com.

http://www.mcri.com


The Use and Impact of Earned Value Management on Software ProjectsBy Walt Lipke, Oklahoma City Chapter Member, Project Management Institute (USA)

AbstractThe Software Division at Tinker Air Force Base has used Earned Value Management (EVM) methods for approximately 20 years. The management method has had significant influence in the improvement of the software development and maintenance practices of the organization. This article, in a story telling manner, describes the use of EVM for managing software and how its system of management facilitated a natural evolution which lead to recognition, awards, and more importantly ….on time, at cost, quality software.

ing process for an item requiring maintenance. A TPS consists of software, an electrical-mechanical interface, and instructions for its use. The portion of the Division supporting Depot maintenance has annual revenue of approximately $40 million. The Depot support functions of the Division employ ap-proximately 360 people of which 300 are electronics engineers.

BeginningYou can just never predict how something may in-fluence your future. In 1979 I attended the 22 week Program Management Course (PMC) at the Defense Systems Management College located at Ft Belvoir, Va. A portion of the course was dedicated to EVM, termed at that time “Cost/ Schedule Control Systems Criteria,” or “C/SCSC.” The EVM course was taught from the perspective of its application to major acquisitions of the US Department of Defense. At the time, I could not visualize its application to the maintenance performed at the Depot. Thus, upon re-turning to my job, EVM was more or less forgotten.

In 1981, two years after the PMC learning experi-ence, the SD was to develop several TPSs for the avionics from a cargo aircraft. The project perfor-mance was disastrous, and the subsequent reputation created nearly doomed the organization.

During 1985, a major acquisition program pro-vided the SD the opportunity to develop several TPSs. With the cargo aircraft project still in work and suffering from a poor reputation, the SD was very fortunate to have this second chance. We knew that a better way was needed to plan the acquisition project and to track its progress. Gantt charts had

This story spans more than 20 years. There has been a considerable amount of excellent work throughout this entire span of time, performed by several dedicated and persevering people.

Although the period of the Earned Value Manage-ment (EVM) application covers two decades, it is not meant to imply that employing EVM for managing software requires an exorbitant time to implement. Rather, what is described is an evolution of practice from the experience of project failure to a desire to do better, and subsequently improvement and suc-cess. Included in the discussion are the outside influ-ences which impacted the actions taken.

In describing the Software Division’s (SD) use of EVM, we’ll cover the topic chronologically. The be-ginnings cover a period of time from 1979 to 1985. The effort to understand the software process oc-curred during 1987 through 1989. The period of sig-nificant, measured, process improvement was from 1989 to 1996. Then a period of evolving and refining the process is described, beginning in 1997 and con-tinues today.

Before EVM and its influence upon the software practices are described, an introduction to the mis-sion of the Software Division and its products is helpful to understanding. Tinker Air Force Base is an Air Force Depot, which performs maintenance and modification to several aircraft and jet engines, including their electronic systems. The SD supports the automated processes used during the mainte-nance actions. The primary products of the SD are Test Program Sets (TPS) and industrial automa-tion software. For clarification, a TPS is used along with automatic test equipment to execute the test-


proven to be insufficient for the cargo project. We turned to EVM and created a very rudimentary Work Breakdown Structure, using the “waterfall” model of software development with its system of phases and progress reviews. Earned Value was accounted on the safe side so that there was no fooling ourselves that progress was being made, when it wasn’t.

The acquisition project was a resounding success! Among all of the developers on the program, includ-ing the contract sources, the SD completed the first two TPSs and was the only developer to complete on time and within budget. Certainly, the success wasn’t solely due to implementing EVM, but using its methods did play a significant part.

Capturing the LessonsOne thing leads to another. In 1987, before the acqui-sition project (A) completed, we began another proj-ect, TPS development for a newer cargo aircraft (N). In many respects the N project was simply an exten-sion of the A project; there were many similarities. The lessons we learned from A were applied to the new project. Not only were the cost, schedule, and performance requirements met, the execution of the N project was considerably more efficient. The re-work was reduced, impressively, from approximately 45 percent for A to about 25 percent for N.

During the new project, some of the teachings of the Total Quality Management classes, which we reluctantly attended during the 1980s, were applied. Before the close of 1990, three documents were pre-pared to capture the processes, and a management steering team was established to maintain control of them. The three documents were: The TPS Develop-ment Guide, The TPS Project Management Guide, and The TPS Developer Training. Imbedded in the documents and the training were methods for apply-ing earned value. Over the period of time they were used, these process and training documents served the SD well.

Process ImprovementIn 1989 I attended the Software Engineering Insti-tute (SEI) Symposium, and was swept up by the dis-cussions of process maturity and improvement. By this time, due to the success on two projects, the SD

had developed a good reputation. Therefore, egotisti-cally, it was decided to conduct a SEI led self-assess-ment to validate that the SD processes were maturity level 3. The assessment was premature to the Secre-tary of the Air Force edict of 1993, requiring organi-zations to be Level 3 by 1998 or risk not being able to do business with the Air Force (AF). The SD was under no pressure to perform the capability assess-ment; however, we believed it was needed to baseline the organization.

The first SEI process maturity assessment was performed for the SD in 1990. The organization showed some Level 2 tendencies, but overall, the SD was Level 1 …..the lowest level of software engineering process maturity. As an organization, we were extremely disappointed with this result. However, being affirmed as Level 1 did serve as the impetus to the organization for the subsequent im-provement efforts.

Occurring about the same time as the assessment the Federal government initiated several things to streamline and reduce cost in its operations: “down-sizing,” Base Realignment and Closure (BRAC), and competition with industry. All of these things said essentially one thing to government workers, “No longer are your jobs secure.” With all of these pressures, it was believed that the performance and reputation of the SD would have to be much better than its competitors, within both government and industry, to obtain additional work and retain jobs. Also, we thought that new work opportunities would come from large acquisitions, and would involve winning a competition. Because large acquisitions oftentimes had EVM imposed, an assumption was made that it could become a contract requirement for the software competitors.

To better grasp EVM, we took a class. As we knew more, it was seen that EVM facilitated im-proving software process maturity. Clearly, the earned value approach provides a good mechanism for the Level 2 key process area, Project Tracking and Oversight. Certainly, having a recognizable work breakdown structure provides structure for another Level 2 area, Project Planning. Seeing other relationships between EVM and the SEI software engineering capability maturity model, we more rig-orously applied earned value management.


In 1993, the second SEI maturity assessment was scheduled. Virtually the entire SEI process staff came to Tinker AFB for the assessment. The assess-ment of the Software Division was the prototyping of a significantly revised assessment process for the SEI. Although the SEI staff was unfamiliar with EVM, they recognized the improvement made in our methods. The organization was assessed as SEI soft-ware process capability maturity Level 2, the first Air Force organization to achieve the rating.

Because of the notoriety from achieving the Level 2 rating, and Mr. Mosemann’s commitment to software process improvement, the Software Divi-sion was chosen to be the subject of a study of its economic benefits, i.e. return on investment (ROI). Mr. Mosemann, at the time, was the Deputy As-sistant Secretary of the Air Force for Communica-tions, Computers, and Support Systems; he wanted evidence that the SEI model for software process improvement provided “real results.” Software Productivity Research was selected to perform the study; they surveyed four of our projects, spanning the years 1988 through 1994 [1]. Mr. Mosemann ob-tained the evidence he sought: the conclusion of the study was that the SEI model has validity. The ROI from the improvement efforts was determined to be 7.5 to 1. The application of EVM contributed greatly to the economic benefit from improving the software engineering process.

By 1995, some of the managers within the SD were convinced that the application of EVM should be extended to include software maintenance proj-ects. One group prototyped the maintenance ap-plication and demonstrated that it was useful in the same way as it is for the longer software develop-ment projects; EVM enforced better project plan-ning and provided several levels of accountability. Consequently, earned value methods for software maintenance were implemented across all of the or-ganization.

In the quest to improve, an organizational set of management indicators was created. Having the standard indicators enforced common reporting and made the periodic management reviews much more productive. During this effort it was recognized that the TPS Development and Project Management

Guides were too focused on specific equipment and software tools. Consequently, the processes were generalized with the creation of the TPS Life Cycle Guide (LCG). As part of the LCG, a standard work breakdown structure (WBS) was defined. When ap-plied, the WBS is tailored to the specific needs of a project. Having a standard WBS has facilitated several planning and tracking improvements. Also, from having consistent data elements and standard management indicators, meaningful project history data has been accrued, thereby facilitating improved project planning.

In 1996, the Software Division underwent its third SEI software capability maturity assessment. The result was Level 4, the first in Federal Service! One of the Level 4 process areas is Quantitative Process Management (QPM). Conceptually, satisfaction of QPM indicates that management uses the data from its metrics to make decisions for controlling the pro-cess. The indicators from EVM significantly contrib-uted to satisfying this Level 4 process area.

The organization was very nearly assessed at capability Level 5; only one key process area was left unsatisfied, Defect Prevention. As seen later in the paper within the discussion of the Software Process Achievement Award, this process area was very likely achieved; however, it was missed, most likely, because we had not prepared for a level 5 assessment. The hopeful expectation before the as-sessment was an outcome of level 3 with some level 4 tendencies. Obviously, the result greatly exceeded everyone’s expectation — the SD, the lead assessor, and the SEI.

Evolving/RefiningAlso during 1996, the SD began the largest software development it had ever attempted. The management reserve (MR) for this effort was larger than the total budget of the vast majority of the division’s projects. Because of its size and the criticality of performing well on this project, we formalized the methods for managing MR. Our methods focused on answering two questions:

1) When should MR be applied?

2) What action should be taken, and to what extent?


The methods were published in the March 1999 issue of CrossTalk [2]. They are being utilized today for all of the SD’s software developments, and have received attention from several organizations, some of which are in foreign countries. In March 2002, the CrossTalk article was reprinted with some updates in Projects and Profits, a journal published by the Insti-tute of Chartered Financial Analysts of India [3].

Upon achieving the SEI software process maturity Level 4 rating, it was thought that the SD would be recognized within the US Air Force as a viable, low risk software provider. However, the division per-forms software work for foreign customers as well as those from the Department of Defense. At the time, the SEI capability maturity model for software process was not that well known outside of the US. Thus, there was some understanding that potential foreign customers might not recognize the meaning of the SEI Level 4 rating as readily as ISO 9001, the international standard for quality management systems. We believed that registration to ISO 9001 would achieve a more recognizable credential to potential foreign customers, thereby providing an-other avenue to increase our business. Once again, we were driven by the desire to survive as an orga-nization, in turn securing long-term careers for the employees.

An underlying principle of the ISO standard is the manner in which the supplier of the product or service treats the customer. Fundamentally, the sup-plier must try to satisfy both the customer’s written and unwritten needs. With regard to software prod-

uct development, customers, often times, are un-comfortable specifying the manner of project status reporting. The progress reporting, using the EVM indicators, proved to be an excellent method of provid-ing project status. It portrays to the customer measures of cost, schedule, and technical performance in a very concise, understandable, and meaningful way. Having earned value management methods in place helped the SD achieve ISO 9001 registration in 1998. At the time, there were not many software organizations having a SEI capability rating of Level 4 or Level 5 combined with the ISO 9001 credential. At this point, the Soft-ware Division truly became an elite software engi-neering organization.

In 1999, the Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) and the Software Engineering Institute (SEI) recognized the Software Division for its software engineering pro-cess improvements. A primary contributing factor to winning the Software Process Achievement Award is the on site, all day, question and answer session with the IEEE/SEI review team. The 1999 review team was made up of several very recognizable names in the software industry: Dr. Barry Boehm, Watts Hum-phrey, Dr. Vic Basili, Manny Lehman, and Bill Rid-dle. Even though the atmosphere throughout the day of the on site examination was very cordial, believe me, it is more than a little intimidating to present and defend your achievements to these gentlemen.

The SEI/IEEE Software Process Achievement Award is unique in that it may not be awarded to the year’s nominees; indeed, there have been several

years when no award was made. The award is made only when the review team is convinced that an organization has made significant progress. For this reason, the Software Process Achievement Award is regarded as the most prestigious award for software organizations.

The SEI technical report, CMU/SEI-2000-TR-014, is avail-able, describing the software pro-cess improvements which earned the award [4]. Figures 1, 2, and

FIGURE 1. PRODUCTIVITY / DEFECT IMPROVEMENTS.


3 are from the presentation made at the 1999 SEI Symposium; they are included, also, in the cited technical report. These figures il-lustrate the improvement results. Figure 1, Productivity/Defect Im-provements, is a compilation of the improvements over the years 1993 though 1998: effort was re-duced by 37 percent, cycle time by 15 percent, and defects by 99 percent. Using the six sigma quality rating system, the defect rate of 0.03 per thousand lines of source code is computed to be 5.5 sigma; i.e., extremely high quality software.

Figure 2, TPS Development Rework, shows the reduction in rework spanning the years 1984 through 1998; rework was re-duced from an initial estimate of 75 percent to 45 percent, then to 25 percent, and is now at 3 per-cent. For comparison, as reported in 2004 by the US Government Accountability Office, rework of 40 percent is not unusual for soft-ware development [5]. Figure 3 illustrates the economic benefits derived from the 10 years of US Air Force funding applied to the software process improvement initiative. For the investment of $6 million in software process improvement, the SD can show a reduction of 765 thousand man-hours with a corresponding reduction of cost equal to $50.5 million. There is no question, the use of earned value methods has played a sig-nificant role in these achievements; EVM has been a facilitator. Likewise, these achievements serve as a strong endorsement of the SEI and its model for software engineering process improvement.

Things change. Satisfying the quantitative man-agement criteria for Level 4 of the SEI software capability model once meant that the organization

used measures in its decision-making process. The criteria have since evolved and have been extended to mean the use of Statistical Process Control (SPC). The Cost Performance Index (CPI) indicator from EVM, and the Schedule Performance Index (SPI(t)) from Earned Schedule [6], provide a means for sta-tistically managing the software engineering process. In the years subsequent to winning the IEEE/SEI award, the SD evolved its use of CPI and SPI(t) into statistical applications. The applications are useful in predicting project outcomes, and have been shown

FIGURE 2. TPS DEVELOPMENT REWORK.

FIGURE 3. ECONOMIC BENEFIT.


beneficial in project planning. Several papers have been published in CrossTalk discussing these meth-ods [7, 8, 9, 10]. Once again, earned value helped meet the challenge.

In addition, the SD is applying a method for strat-egizing the recovery of a project, which appears headed for failure. Once again, we resorted to the EVM and ES indicators, CPI and SPI(t), for creating the approach. The published technique has shown to be beneficial [11].

SummaryThe Software Division has a lot to show for over the years 1985 through 2005. There has been recogniz-able, quantifiable improvement in the software devel-opment and maintenance processes. Integral to many of the software management improvements is the use of earned value methods. The credentials gained from improving, SEI Level 4 and ISO 9001, has placed the organization among the elite in the world. The winning of the 1999 IEEE/SEI Software Process Achievement Award was the final proof that the im-provement made is bona fide. And, most important, the “rubber hits the road” proof of the improvement is software products are consistently completed for acquisition and maintenance projects on time, at cost, and with excellent quality, many of which serve today for the US Air Force.

References1. Nowell, Jeff, “An Analysis of Software Process

Improvement,” Software Productivity Research, September 1994.

2. Lipke, Walter H., “Applying Management Reserve to Software Project Management,” CrossTalk, March 1999: 17–21.

3. Lipke, Walter H., “Applying Management Reserve to Software Project Management,” Projects and Profits, March 2002: 19–26.

4. Butler, Kelley and Walter Lipke, “Software Process Achievement at Tinker Air Force Base, Oklahoma,” CMU/SEI-2000-TR-014, September 2000.

5. United States Government Accountability Office, Defense Acquisitions: Stronger Management Practices Are Needed to Improve DOD’s Software Intensive Weapon Systems, GAO-04-393 (March 2004).

7. Lipke, Walt and Jeff Vaughn, “Statistical Process Control Meets Earned Value,” CrossTalk, June 2000: 16–20.

8. Lipke, Walt and Mike Jennings, “Software Project Planning, Statistics, and Earned Value,” CrossTalk, December 2000: 10–14.

9. Lipke, Walt, “Statistical Process Control of Project Performance,” CrossTalk, March 2002: 15–18.

10. Lipke, Walt, “Statistical Methods Applied to EVM: The Next Frontier,” CrossTalk, June 2006: 20–23.

11. Lipke, Walt, “Project Recovery: It Can be Done,” CrossTalk, January 2002: 26–29.

About the AuthorWalt Lipke retired in 2005 as depu-ty chief of the Software Division at Tinker Air Force Base. He has over 35 years of experience in the de-velopment, maintenance, and man-agement of software for automated testing of avionics. During his ten-ure, the division achieved several

software process improvement milestones, including the coveted SEI/IEEE award for Software Process Achievement. Mr. Lipke has published several arti-cles and presented at conferences, internationally, on the benefits of software process improvement and the application of earned value management and statisti-cal methods to software projects. He is the creator of the technique Earned Schedule, which extracts schedule information from earned value data. Mr. Lipke is a graduate of the USA DoD course for Pro-gram Managers. He is a professional engineer with a master’s degree in physics, and is a member of the physics honor society, Sigma Pi Sigma (SPS). Lipke achieved distinguished academic honors with the selection to Phi Kappa Phi (FKF). In March 2007, he received the PMI Metrics Specific Interest Group Scholar Award. In November, Mr. Lipke received the 2007 PMI Eric Jenett Project Management Excel-lence Award for his creation of the ES method and role in its worldwide propagation and use.


http://www.DekkerLtd.com

evm MeasurableNewsIssue308

Documents

Transcript of evm MeasurableNewsIssue308