In the mid-1960s, the concept of introducing an Earned Value Management System (EVMS) for the proper management of United States Air Force projects was enacted through an approach known as the Cost/Schedule Control System Criteria, or C/SCSC, sometimes referred to as “the C-Spec.”[i] Soon this canned approach to generating and maintaining the information streams that would keep customers apprised of the performance of the projects within their purview expanded to the other branches of the U.S. Department of Defense, then on to the new Department of Energy, and somewhat unevenly to other U.S. Government organizations. While other project-oriented industries had been using various aspects of EV and Critical Path Methodology to manage their work for some time, the efforts to collect and structure these techniques into a single codex really got their start here, through MIL-STD-881A, DOD Instruction 5002, among others[ii]. PMI® itself began in 1969, with standardization efforts making up 10 – 15% of its work.[iii] The first edition of the PMBOK Guide® was published in 1996, representing the first major academic or institutional effort at collecting and codifying the techniques across all industries that we now recognize as germane to Project Management.
But here’s where things get a bit cattywampus. For hundreds of millions of dollars’ worth of United States Government contracts, demonstrably complying with the nascent C/SCSC was (and still is) a condition of doing business. It was essentially a waste of time to bid on one of these proposals if your organization wasn’t capable in what would be considered today as a fairly basic EVMS. It was a Boolean metric: either “do” Earned Value Management in a specific manner, or you can’t get the project award. In this respect, it was very much like the “implementation strategy” that accountants used: since no organization can conduct business without paying taxes, and taxes can only be assessed based on information within the general ledger, it was a their-way-or-the-highway situation. Back on the PM side, those seeking to embrace such business model characteristics as developing Work Breakdown Structures, or Responsibility/Accountability Matrices (RAMs), or Work Packages that roll up to Control Accounts, or collecting percent complete data, or aligning the General Ledger with the WBS, etc., etc., really didn’t have to develop an implementation strategy per se. They only needed to arrange to train we PM-types in those techniques and outputs, and set us loose on the projects. The mere threat of having your DoD customer label you with a “C/SCSC Non-compliant” charge was more than enough to, for example, get our friends, the accountants, on-board with aligning the chart of accounts with these projects’ WBSs.
Just A Little Bit More History…
Beginning in the late 1980s, various guidance-generating organizations began to loosen the requirements of the C-Spec, often invoking the assertion that “low risk” projects really didn’t need the level of cost/schedule performance measurement system robustness that high-value, “high risk” work did. The drip of organizations claiming to be exempt from the Earned Value and Critical Path Management specifications on those grounds became a torrent. Even extremely high-value, cutting-edge technology projects would assert Earned Value Management Systems to be inappropriate, with entirely predictable results: overruns and schedule delays.[iv] Once tried-and-true cost and schedule performance measurement systems were no longer required as a condition of doing business, project “managers” would often opt to “control” their costs by merely watching their actuals go by. And by “go by,” I mean escalate quickly into out-of-control status.
This effect coincided with that point in my career when I started attending PMI® Congresses and other PM-themed seminars, and I noticed an interesting trend: common to most of the sessions I attended was this underlying notion that, if the PM practitioner wasn’t performing the types of analyses that the speaker was presenting, well, that person wasn’t doing PM “right.” I nicknamed this argument eat-your-peas-style hectoring. Simply putting out there the assertion that the absence of robust EVM or CPM systems represents a transgression from what the PM zeitgeist demands in no way makes up for a singular lack of persuasion-based implementation strategies. The whole argument can be boiled down to “if your organization isn’t compelled to do PM right, and doesn’t do it anyway, then they’re a bunch of dolts,” and I, for one, don’t find that particularly compelling.
There are, of course, many valid and compelling reasons why significant aspects of project-oriented organizations’ business models should incorporate the PM techniques with which we’re all familiar. But I believe that the reason they haven’t been addressed broadly can be attributed to the fact that PM implementation used to be mandatory, a condition of doing business. That’s no longer the case in many situations.
And it shows.
[i] Retrieved from https://www.humphreys-assoc.com/evms/basic-concepts-earned-value-management-evm-ta-a-74.html on May 4, 2022, at 18:08 MDT.
[ii] Retrieved from https://www.pmi.org/learning/library/articles-cost-schedule-control-system-5454.
[iii] Wikipedia contributors. (2022, March 14). Project Management Institute. In Wikipedia, The Free Encyclopedia. Retrieved 00:17, May 5, 2022, from https://en.wikipedia.org/w/index.php?title=Project_Management_Institute&oldid=1077175134
[iv] Probably the worst offenders in this category – Information Technology projects – are notorious for both eschewing EVM, and having an absolutely abysmal record when it comes to overruns and delays.



