EV-lite – earned value control for fast paced projects

Craig D. Peterson, PMP, Managing Consultant, EDS
Michael E. Oliver, PMP, Consultant Architect, EDS

History demonstrates the value of implementing earned value management systems (EVMS) on large complex projects. Earned value provides a solid means to substantiate project performance against progress payments. It gives management a means to financially audit the project as well as track progress. The benefits of EVMS are well worth the associated overhead necessary to administer it.

The birth of the digital economy however has added a new genre of projects. These projects are characterized as fast-paced, short-duration (3–12 months), small teams (6–8 people), with poorly defined requirements at the outset that continue to evolve over the life of the project.

While these projects could benefit from the planning rigor typical of projects preparing to use earned value reporting, it is rarely employed. Why? A combination of factors ranging from the expenditure ratio between the design and construction phases of IT development methods to the business urgency of these projects work against its adoption. Approaches that increase project overhead will find little acceptance. What if most of the benefits of EVMS could be gained through “relaxing” some of the traditional requirements? What if other controls and/or metrics could be introduced to compensate for these “relaxed” requirements? What if it was employed as a management control tool versus a financial accounting system? EV-lite and SVO improves tracking and control to this family of projects that historically experience poor performance. They fill the void between projects too small to justify earned value and large government projects that mandate its use. They provide the control needed for short-duration, fast-paced projects with evolving requirements and limited resources.

Our goal in the sections that follow is to first describe the five different EVMS approaches that we perceive to make up the full EVMS continuum. They cover most projects, including those fast-paced, short duration projects from the digital economy. Since one rarely gets “something for nothing,” we will also discuss the tradeoffs that are made when one adopts these approaches. More than an academic exercise, we have successfully used these approaches on a number of “live” projects.

The History of Earned Value

Earned Value Origins

The earliest versions of these techniques can be traced to formal contractor requirements that the US Air Force put into place in 1964. The rest of the US Department of Defense quickly recognized the value it provided. In 1967, they established the Cost/Schedule Control Systems Criteria (C/SCSC), created to standardize contractor cost and schedule performance reporting requirements on major acquisition contracts. C/SCSC provided a uniform reporting structure based around 32 (originally 35) management system requirements, i.e., criteria around the area of cost, schedule and planning, and tracking. This accommodated the needs of several key stakeholders. The project plan supporting the management reporting captures all the contract requirements (scope). Those responsible for contract performance received clear signals regarding the achievement of various deliverable objectives (schedule). Those responsible for tracking financial performance have this information tied to these same deliverables (cost). Overall, the system addresses the three key characteristics important to all project managers: scope, schedule and cost. Over time, these techniques were adopted by other US Government organizations, which had these same needs when administering large acquisition programs.

Traditional C/SCSC techniques have their “quirks.” particularly in its use of “dollars” to express all metrics that have “units” associated with them. Even schedule variance, the metric used to describe how much planned effort was not yet completed, is expressed in the unit of “currency.” While mainstream project participants might have issues with this, those closely affiliated with earned value data are the most comfortable with this type of information. Currency-based metrics have served as the foundation for all management decision-making systems since the birth of the industrial age.

The Industrial Revolution—A Parallel Problem Pointing Toward the Solution

Before the industrial revolution in the United States, American Manufacturing Methods were characterized as the “workshop system.” It was both difficult and rare for the owner to compute the typical financial metrics that we take for granted today: Cost of Goods Sold, Profit, etc. They had “managerial accounting” systems, that is to say, systems that facilitated management decision-making. This system worked fine until the mechanization of factories. The industrial revolution demanded far more funding than what was available. This gave birth to the capital markets, which in turn required standardized financial reporting for investors. Keeping two sets of “books” was difficult and time consuming. Academia solved the problem by devising systems and metrics that utilized an organization's financial data. Now, with only a single (financial) accounting system being needed, the managerial systems were abandoned.

How does all of this relate to earned value? EV was born by those “living” in the contracting/financial accounting “world.” As middle managers, they were well schooled in modern financial accounting practices. They were comfortable making decisions and expressing metrics with financial data. With this understanding, one can reasonably understand how they could have developed earned value from a project's financial data, and been comfortable describing “time” (schedule variance) using currency.

Managerial accounting systems, however, are coming back into vogue as a by-product of the “information revolution.” Computers have eliminated the manpower intensive nature of both handling and interpreting data. Managers are relearning the use of alternative information sources to make decisions. They are also learning that data does not always have to be “audit-able” to be useful. It is from this new perspective that earned value is being reexamined, resulting in exposure of some exciting possibilities.

The Earned Value Continuum

Origin of the EV Continuum

Considering the project control value of EVMS, there must be simpler means to derive its benefits, particularly after examining the demands for financial audit-ability found in traditional earned value, which creates significant overhead and administrative burdens. This is particularly true for fast paced, small sized, short duration projects where these systems may not already be in place. In addition to cost accounting systems required for traditional project accountability, there are other project control system integration needs in areas such as fiscal accounting, time tracking and project planning/scheduling. They are needed to ensure costs (direct expenses and labor content) are correctly allocated to each individual work package/cost account. This is particularly true for software development projects, where a large cost component is the labor of knowledge workers.

There are, however, other characteristics typical of software development projects. These include:

• Project Speed—Projects typically take place in an overly compressed time frame from the start. Culturally, detailed planning is not valued.

• Ambiguous Requirements—What the customer considers to be “the” description of the business requirements is never complete. Much is taken for granted/understood or assumed/expected without being captured in the requirements document. Additionally, as the customer comes to understand the secondary/tertiary impacts of the new software on their existing systems, they discover additional changes that must be incorporated. Mid-project change is the norm.

• Limited Integrated Overhead/Support Infrastructure—As mentioned above, many IT project teams do not have systems integrating time, cost, and project planning. This makes any process requiring such an integrated system difficult to execute with manual systems. In all fairness to these groups, the choice to not employ integrated tool suites is usually a deliberate one. Many of these tools provide their integration functions at the expense of ease of use and flexibility that do not accommodate the fluid nature of IT projects. The authors have both consulted for a number of organizations who are contemplating abandonment of some of the stalwart integrated tool suites in favor of solutions built from components from different vendors to create a more fluid, integrated solution.

• High Labor Content/Small Staff Size—The major “expense” experienced on software development projects are the labor hours generated by a small project team. This team, while highly trained in software development, typically does not have extensive project management training/skills, or the time to administer non-integrated project management systems.

• Ratio of Design Phase expenditures to Construction Phase expenditures—In the construction industry, the design phase of a project may range someplace in the vicinity of 10% of the overall project cost. During the design phase of construction projects, specifications on paper detail the project in its entirety. Project plans are developed from these detailed specifications. By contrast, the ratio of the costs expended in software design in contrast to the costs expended in the construction phase of an IT project is much higher than 10% depending upon the development platform. Although that figure is improving with advancements in development platforms and design tools, in many IT development environments a good portion of the overall project's costs may be accrued before sufficient design detail exists to support detailed project planning.

Something was needed to provide the benefits of earned value, while accommodating the environmental aspects of the typical fast-paced IT project. We propose defining degrees of earned value implementation across different predetermined levels. Items typically found in a “full” earned value implementation would be deliberately relaxed to reduce administrative burden while at the same time, provide greater project control information than what is currently available to IT project managers. Knowing the propensity the IT community has for adopting the easiest of all “silver bullets” options offered, clearly defined guidelines are necessary to ensure implementation of the appropriate level of earned value rigor based on project complexity and risk.

The Five Part Continuum Model

What resulted was a five-part model defining different earned value implementation levels, with project risk being the principal selection criterion. These levels are:

Level 1. US DoD-compliant Implementation—Well known to major defense contractors, this approach requires adherence to specifically prescribed processes and procedures established through a long history of use. Specific guidelines define elements like record keeping and report formatting. This approach is recommended for projects with the highest level of risk stemming primarily from dynamic complexity as defined by magnitude of scope, number of projects and interproject dependencies, etc., particularly when a number of disparate entities will collaborate on the delivery. In such contexts, common standards for EVMS methods and reporting are critical for cross-program data aggregation.

Level 2. ANSI-compliant EVMS Implementation—The primary difference between this approach and the US DoD-compliant implementation is that a DoD implementation “prescribes” both the EVMS process and formats, whereas the ANSI-compliant one merely “describes” them. Under ANSI-compliant EVMS, users are simply told they have to meet the requirement. They are not told how it is to be done. This approach is also intended for high risk projects as defined by magnitude of scope, high dynamic complexity of the project environment, etc.

Level 3. EV-Lite—This is one of two sub-earned value implementations. In this approach, the only deviation from an ANSI-compliant implementation is that costs are collected at the project vs. control account level. All other earned value processes and implementation considerations remain. As a result, schedule variance can be calculated at the control account level, but cost variance can only be computed at the project level. This approach is intended for projects with an intermediate level of risk. While cost variance cannot be performed at the lower control account level, approximations can be taken at the completion of work packages to validate the estimating models employed. Key here is the understanding and acceptance that the actual costs incurred on this work package is just one of many possible outcomes that could have taken place. Absolute precision in the ultimate cost value (“to the penny”) does not impart any additional knowledge where a range of possible answers could have resulted. The approximation is “good enough.”

Level 4. SVO (Schedule Variance Only)—This is the second sub-earned value implementation. In this implementation, only schedule variance is tracked within the project. Costs are tracked/controlled using traditional cost accounting software. This approach was intended for projects with intermediate level risks that meet specific restrictions and consideration. Projects not meeting these restricts require escalation to one of the more rigorous processes defined above. The first restriction is that the project must be predominately composed of high labor content. The second is that this labor content is constant throughout the project's life (i.e., 10 people assigned from start to finish). The third is that overtime is either highly controlled (via another processes) or does not influence the client's bill (i.e., they are not billed for this time). Finally, the bid rates used within the project proposal and planning documents has minimal variance to the rates of those employed to complete the project's effort/tasks. Under these conditions, labor costs become essentially “fixed” versus the traditional “variable” view held by most managerial accountants. Here, the project management proverb “cost follows schedule” will hold true (i.e., over schedule will be over budget and visa versa). Under this approach, schedule variance is the only direct metric being collected through which to evaluate project performance; however, this measurement can be performed at the control account/work package level. Cost variances are approximated and are managed external to the project environment, utilizing existing accounting mechanisms and average “burn rates.” Again, these burn rates may prove “good enough” to validate the estimating models that were employed during project planning.

Level 5. No EVMS—This is here to “anchor” the other end of the continuum. Representing the “opposite” of the rigid requirements of the US DoD-compliant implementation, this category encompasses all projects where earned value is not being employed. There are, however, some improvements that can be made even here. We call this “No EVMS—Binary, and it is discussed in greater detail in a later section.

Pros, Cons, and Other Recommendations

The obvious advantages of the EV-Lite and SVO approaches are the dramatic reductions in effort associated with cost tracking and assignment. The ANSI areas effected are 2.3, 2.5, 2.8-2.12, 2.17-2.18, 2.21.1, and 2.22-2.24. In each of these, changes in the ways in which costs are collected and tracked within the project make them no longer “audit-able” to control accounts. These values are derived differently, making them more suitable as “management accounting system” or management control indicators (i.e., something close but not perfect) instead of absolute values. If the restrictions defined above are followed, these techniques will still send the appropriate signals in time for action by the project's leadership.

Additionally, all of these techniques benefit from the use of rigorous basic project management. Often neglected, rigorous project planning (i.e., WBS, OBS, and work package estimating) still pays. Controlling/eliminating the five (negative) behaviors Goldratt describes in his application of the theory of constraints to project management under the auspices of the “critical chain” concept pays additional dividends. Typically not practiced on most projects, these ideas include:

•Have a single managed reserve vs. many multiple pockets of reserves distributed to the project's tasks.

• Apply 100% effort from the start on each task and work towards durations and not planned due dates.

• If the opportunity presents itself, capture positive schedule variances to counter negative ones.

• Ensure constrained resources are managed so that there is no lost time.

• Avoid the inefficiencies that come with multitasking resources, particularly with constraints.

Application Examples

The examples provided in this section illustrate the application of the EV Continuum implementation from Level 3 down through Level 1. They are all taken from the same project to provide some means of contrasting the earned value results from each of these EV implementation levels. This respective project, conducted from September 1999 through November 2000, is representative of many projects in the digital economy. The project spanned 14 months, with a maximum team size of eight developers, an overall baseline effort budget of 4,264 effort hours and a total dollar cost of approximately $850,000. The schedule was developed and maintained with Microsoft Project 98®. The project team tracked their time against respective task assignments using Innate Management System's Timesheets product. Cost and schedule performance was evaluated on an effort-basis using the EV-Lite approach proposed in this paper enabled through an EDS proprietary tool for Microsoft Project called EVAnalyzer.

Granted, the earned value methods exercised on this project would not satisfy either the Full/DOD or ANSI EV implementation levels. They neither adhere to DOD prescriptions for reporting and auditing, nor would they satisfy all 32 ANSI earned value criteria. However, with at least the Level 3/EV-Lite approach, the BCWS, BCWP, and ACWP developed at each reporting were no different at the project level than they would have been with the full rigor of either Full/DOD or ANSI-compliant approaches. Furthermore, this was accomplished with minimal overhead. In fact, the actual evaluation of EV performance with EVAnalyzer is done with one click of a button. If the overall intent for developing EV information is project control, does the rigor of Full/DOD or ANSI matter, particularly when the resulting control information, available for management decision-making, is the same?


Approach: With EV-Lite, typical CPM schedule management rigor governs the creation and maintenance ofthe project schedule. Task value for EV-Lite purposes can be established either by resource loading the task and allowing the CPM schedule management tool to calculate cost build-up or by simply entering an estimated value for each task (without the overhead of resource loading). These values provide the basis for a time-phased cumulative cost baseline. EV-Lite task values can be stated in either currency or effort.

Cumulative BCWS for any reporting date is determined through any recognized EVMS technique. Cumulative BCWP is similarly accrued. ACWP is determined either from actual performance information (actual start, finish, and effort expended) recorded by project resources against their assigned tasks OR taken cumulatively from an external effort or cost-tracking tool that captures expenditures at a project level minimum.

Application Contexts: EV-Lite is ideal for projects that don't require the overhead rigor of ANSI/DOD-compliant EVMS criteria and the intent for applying EVMS is not financial management at the cost account level, but rather project control decision support at the project level. EV-Lite is also ideal when costs (whether stated in effort hours or currency) are recorded in a tracking tool at the project level only external to the project environment. In the authors’ experience, many organizations that contract on a time-and-materials basis for project delivery usually have existing (and sometimes proprietary) tools through which actual effort and other project expenditures are tracked and billed. Many of these systems only capture this data at the project level and rarely provide schedule management integration. The EVAnalyzer tool accommodates these usage contexts with an option that prompts the project manager to provide a total project cumulative ACWP value from an external source.

Results: Using EV-Lite, on May 25, 2000, the cumulative BCWS was 2,890 hours, the BCWP was 2,724 hours, and the ACWP was approximated at 2,303 hours. At the project level, this was an accurate statement of both cost and schedule performance.

Limitations/Cautions: If the cumulative project-level ACWP is being supplied from an external system, it's very important that only those costs modeled in the project's cost baseline be brought over for EV-Lite evaluation. Some projects that have used EV-Lite have occasionally overstated cumulative ACWP when some actual cost component that was never modeled in their cumulative baseline is brought over for analysis. The converse has also occurred on occasion. However, the magnitude of the cost variance for that reporting period is usually significant enough to warrant an investigation that reveals the root cause of the variance. By contrast, this rarely happens on projects that use EV-Lite in conjunction with tracking tools that integrate with their CPM schedule management tools as was the case on the project used for illustration purposes.

Maintenance of baseline integrity is also important. On typical digital economy projects, a number of changes may be introduced to the project environment as either the result of refining requirements or project plan evolution seen in the conversion of planning packages. To simplify maintenance of baseline integrity, EDS has proprietary tools for Microsoft Project.


Approach: With the SVO approach, typical CPM schedule management rigor governs the creation and maintenance of the project schedule. Task value for SVO purposes can be established either by resource loading the task and allowing the CPM schedule management tool to calculate cost build-up or by simply entering an estimated value for each task (without the overhead of resource loading). These values provide the basis for a time-phased cumulative cost baseline. SVO task values can be stated in either currency or effort.

Cumulative BCWS for any reporting date is determined through any recognized EVMS technique. Cumulative BCWP is similarly accrued. Since the only performance information posted to the project schedule is the actual start and finish dates of respective tasks, actual costs are approximated in either one of two ways:

• Extrapolating actual costs based on baselined FTE staff, or;

• Tracking the number of people who worked on the project between the current reporting period and the previous reporting period and applying a standard “burn rate” to approximate how many effort hours were most likely expended by those people during that time.

Application Contexts: SVO might be appropriate when expenditures are being managed external to the project and the intent of applying SVO is to understand the implications of schedule performance. Because of proprietary tools that simplify implementation of EV-lite, the authors have seen little use of SVO within their organization.

Results: Applying the “staff head count/burn rate” technique to approximate actual costs, on May 25, 2000, the cumulative BCWS was 2,890 hours, the BCWP was 2,724 hours, and the ACWP was approximated at 3,964 hours.

Limitations/Cautions: A number of cautions should be observed about the resulting information. While the schedule performance information has a decent degree of accuracy (depending upon the extent to which integrity of the schedule baseline has been maintained), as the name for this approach implies, the emphasis is SVO (Schedule Variance Only). The approximated actual cost information is open to considerable latitude in accuracy. In the case of this particular project, the costs derived from an assumed burn rate of 40 hours per person per project week (also used in the development of the schedule model as the basis for resource availability). Even allowing for someone to state, “I only worked half of my time on the project this week,” the approximated costs were overstated by 1,660 hours (the project was actually running a positive cost variance of 420 effort hours on May 25, 2000).

The approximation of actual costs based on a staff count and an assumed “burn rate” may over or understate actual costs as illustrated in this example. This range of error may mask a mounting exercise of uncompensated overtime. Shifting to approximation of actual costs derived from baseline FTE staff does little to alleviate the margin of error because the only difference between ACWP approximated from baselined FTE staff and the BCWS will result from the accrual method for cumulative BCWS.

No EVMS—Binary

Approach: The binary approach is a limited means of conveying some indication of schedule accomplishment at a total project level. In the binary approach, every task has a value of one (1). The lowest level tasks in the project schedule must be no greater than two weeks in duration. While the schedule does not require assignment of resources or a logic network, it must represent a “reasonable” approach for expediting the project. [Note: Relaxing the requirement of a task dependency network is based on the assumption that tasks are being positioned in time for execution by constraint dates like Start No Earlier Than or Must Start On.] A schedule baseline is established for all start and finish dates.

Schedule accomplishments are recorded by indicating that each task is either complete or incomplete, hence the designation “binary.” Schedule performance is evaluated by comparing the number of tasks that should be complete by the status reporting date (Planned Percent Completebin) as established by the baseline start and finish dates to the number of tasks that are actually complete (Actual Percent Completebin). For example, if some project's baseline finish dates indicate that at the end of Week 12, 24 of the projects 68 detail tasks should be complete, the PPCbin = (24/68) * 100 or 35%. At the end of Week 12, only 22 of those 68 tasks were actually complete. The APCbin = (22/68) * 100 or 32%. The delivery variance (DVbin) = APCbin—PPCbin or –3%. By plotting the DVbin at each reporting interval, some sense of the schedule performance trend may be established.

Application Contexts: The “No EVMS—Binary” approach is suitable for project and program environments where little to no CPM schedule management skills exist and insufficient time or resources are available to either develop or acquire those skills. This approach was successfully used on a number of Year 2000 renovation programs.

Results: On the status reporting date of May 25, 2000, the sample project exhibited a PPCbin of 68%, an APCbin of 55%, and a DVbin of –13%.

Limitations/Cautions: While the negative delivery variance is sufficient to indicate the project has fallen behind schedule, the data points are not useful beyond this indication. However, when this technique was used to evaluate Year 2000 project and program performance, each project schedule in a program was required to decompose detailed project work into tasks not exceeding two weeks in duration. With a weekly reporting cycle, the greatest degree to which any one project could slip without being noticed was one week. The task duration granularity combined with the weekly reporting cycle resulted in project team behaviors that were cognizant not to let their schedule slip—the program managers could see and quickly drill-down to find that slippage. While the binary approach data has significant limitations, providing Year 2000 program sponsors with overall program delivery variance trends was sufficient to assuage their fears that adequate progress was being made and the projects in the Year 2000 renovation portfolio were on track with their schedule performance.


The Results

While only one example is reviewed above, we have successfully employed these techniques on a number of different projects. The results are always the same: significant and valuable project control information is obtainable from non-audit-able earned value implementations. While the stringent audit requirements built into the US DoD and ANSI-compliant approaches are very appropriate for large, complex, multiyear projects (and programs), their administrative overhead keeps these techniques from being employed on projects whose risk levels warrant more detailed control systems. The Level 3–5 implementations we describe above provide sufficient control and the managerial information needed to make fast-paced IT projects successful.

Finally, one should note that even with giving up control account financial auditing, these “new levels” continue to satisfy the major tenant of the EVMS ANSI-Standard:

“The essence of earned value management is that at some level of detail appropriate for the degree of technical, schedule, and cost risk or uncertainty associated with the program, a target value (e.g., budget) is established for each scheduled element of work” [emphasis added].

They also accomplish, and do not obviate, the basic concepts of an EVMS, again as noted from the ANSI-Standard:

• Plan all work scope for the program to completion.

• Integrate program work scope, schedule, and cost objectives into a baseline plan against which accomplishments may be measured.

• Objectively assess accomplishments at the work performance level.

• Analyze significant variances from the plan and forecast impacts.

• Provide data to higher levels for management decision-making and implementation of management actions.

Correctly and appropriately applied, EV-Lite and SVO provide much needed options in the wide gulf between DoD and ANSI-compliant and no earned value measurement information.


Abba, Wayne F. 1997. Earned Value Management—Reconciling Government and Commercial Practices PM: Special Issue January–, p. 58–63.

Christensen, David S. 1998, Fall. The Costs and Benefits of the Earned Value Management Process. Acquisition Review Quarterly, p. 373–386.

Corbett, Thomas. 1998. Throughput Accounting. Great Barrington, MA: North River Press.

Cost/Schedule Status Report (C/SSR) Joint Guide, May 1996.

Defense Contract Audit Agency. 1996. Earned Value Implementation Guide (DCAA Pamphlet 7641.47), Ft. Belvoir, VA.

Department of Defense Handbook. 1998. Work Breakdown Structure, MIL-HDBK-881.

Electronic Industries Alliance. 1998. EIA Standard—Earned Value Management System (ANSI/EIA-748-1998), Englewood, CO.

Fleming, Quentin W. 1988. Cost/Schedule Control Systems Criteria: The Management Guide to C/SCSC. Chicago, IL: Probus Publishing Co.

Fleming, Quentin W. 1997, Nov. Does Earned Value Work? Project Management Monthly, p. 10–16.

Fleming, Quentin W., and Koppleman, Joel M. 1994, Jan. The “Earned Value” Concept: Back to Basics. PM Network, p. 27–29.

Fleming, Quentin W., and Koppleman, Joel M. 1994, May. The “Earned Value” Concept: Taking Step One—Scope the Project. PM Network, p. 22–24.

Fleming, Quentin W., and Koppleman, Joel M. 1994, Sept. The “Earned Value” Concept: Taking Step Two—Plan and Schedule the Project. PM Network, p. 35–37.

Fleming, Quentin W., and Koppleman, Joel M. 1995, Jan. Taking Step Three with Earned Value: Estimate and Budget Resources. PM Network, p. 39–41.

Fleming, Quentin W., and Koppleman, Joel M. 1995, May. Taking Step Four with Earned Value: Estimate the Project Baseline. PM Network, p. 26–29.

Fleming, Quentin W., and Koppleman, Joel M. 1995, Sept. Monitoring Performance Against Baseline. PM Network, p. 9–14.

Fleming, Quentin W., and Koppleman, Joel M. 1996, Jan. Forecasting the Final Cost and Schedule Results. PM Network, p. 13–18.

Fleming, Quentin W., and Koppleman, Joel M. 1996, May. The Earned Value Body of Knowledge. PM Network, p. 11–15.

Fleming, Quentin W., and Koppleman, Joel M. 1996, Summer. The Essence & Evolution of Earned Value. Estimator Summer, p. 17–23.

Goldratt, Eliyahu M. 1984. Critical Chain. Great Barrington, MA: North River Press.

Goldratt, Eliyahu M. 1984. The Goal: A Process of Ongoing Improvement. Croton-on-Hudson, NY: North River Press.

Goldratt, Eliyahu M. 1990. The Haystack Syndrome. Croton-on-Hudson, NY: North River Press.

Goldratt, Eliyahu M. 1990. Theory of Constraints.Croton-on-Hudson, NY: North River Press.

Hounshell, David A. 1984. From the American System to Mass Production, 1800-1932. Baltimore, MD: John Hopkins University Press

Kerzner, Harold. 1998. Project Management—A Systems Approach to Planning, Scheduling, and Controlling. Berea, OH: Baldwin-Wallace College.

Noreen, Eric, Smith, Debra, and Mackey, James T. 1995. The Theory of Constraints and Its Implications for Management Accounting. Great Barrington, MA: North River Press.

Office of the Deputy Under Secretary of Defense (Acquisition Reform), 1997. Earned Value Management (EVM), October 1997.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville,Tenn.,USA



Related Content