One of the things that strike me as exceedingly weird about the way Change Control is currently practiced has to do with the establishment and use of a project’s Contingency Budget, or reserve. This is the amount that is “set aside” for “risk events,” and is tapped whenever said “risk events” take place. Already tired of my using quotation marks to signal the phrase “so-called”? I’m just getting warmed up.
So, how do these Contingency Budgets come into being in the first place? Well, they’re typically created after a thorough risk analysis has been performed on the cost, schedule, and scope baselines, including in-depth use of Monte Carlo and Decision-Tree Analysis techniques, and calculated to an 80% confidence interval through expert usage of the rules of probability. In other words, they’re pulled out of thin air, anywhere between a 5 to 15% flat rate.
As the project gets underway, the next phase of decision-making in the Change Control arena has to do with what “unexpected” things happen as the scope is pursued. In order to maintain discipline in the process used to change the cost, scope, or schedule baselines, a standard rule is that you can’t change one of these baselines without changing the other two. So, when a Baseline Change Proposal is issued to do just that, highly-trained experts will describe in detail what ought to be altered in the scope baseline first, and its ramifications for cost and schedule. This complete and even-handed assessment then goes to a Baseline Change Control Board, or BCCB, where its particulars are scrutinized prior to approval and implementation. In short, millions of dollars are removed from the contingency reserve based on hastily-assembled verbiage that contains syntax errors that would flunk a 7th grade essay, in order to re-align the cost baseline, coincidently enough, to the exact amount of the cumulative negative cost variance, and everybody’s supposed to be okay with that.
As the Contingency Budget nears its exhaustion point, the BCPs being placed before the BCCB undergo higher levels of scrutiny, particularly in those instances where the cumulative percent complete for the project is below half-way. Here is where the risk managers (finally!) begin to earn their pay, since, if the “event” that is driving the “request” happened to be included in the initial risk analysis, some claim of “I told you customers that this might happen!” suddenly becomes the legitimate basis for increasing the project’s overall budget. After carefully considering the original risk analysis, and taking into account several project management axioms such as “things change,” the BCP is approved, and the Contingency Budget moves ever closer to extinction, even as the cumulative cost variance is, once again, reset to zero.
Once the project nears completion, and the Contingency Budget is all but gone, “changes” are harder to “manage.” Should a meteor strike the project site, Godzilla himself wreck catastrophe, or a key supplier’s rates suddenly escalate (all equal events, save that one is perfectly predictable), the onus now falls on the previously-confident customer, who is placed in a most unfortunate position: pony up more funds, or see the project stall in-place, with nothing to show for it. Any attempt from the customer to pinpoint what should have taken place in baseline change space previously is pretty much futile (well, maybe not for the first two instances, but stay with me), since any forensic analysis – say, that the contractor shouldn’t have chewed up the Contingency Budget already on suspect grounds – almost always points to the customer being asleep at the BCCB switch.
So, going all the way back to the initial stages of the project, the question simply must be asked: for all of the baseline development, risk analysis, and baseline change negotiations that have taken place, wouldn’t a straight-up answer to the question in the title have saved a lot of money, time, and energy?
According to a paper by Michael Bloch, Sven Blumberg, and Jurgen Laartz, large Information Technology projects run 45% over budget, are 7% late, and deliver 56% less value than predicted.[i] Kind of reminds me of a couple of my nieces and nephews. Anyone familiar with IT project management has little reason to doubt their findings – many so-called traditional project management techniques seemed to lose at least some level of efficacy, just as traditional parenting techniques tend to fail when employed with a certain type of child. When they were originally introduced to software project management, Change Control techniques seemed an odd fit, not because of the failings of the techniques, but due to the unruly nature of IT projects.
In traditional project management, when a contractor sets out to build a building, ship, airplane, dam, or what have you, the original baseline with its three components – scope, cost, and schedule – were pretty much assumed to be an accurate capture of the project’s outcome, expressed in terms of deliverables, resources needed to meet those deliverables, and how long it would take, respectively. However, when IT projects began to grow in size and complexity, this otherwise useful premise simply had to be discarded. With few exceptions, software engineers could not have a crystal-clear, detailed vision of what their end-products would be like by the time they hit the commercial market. Software developers who had hoped their code would end up in an Ivy League school’s research lab could end up seeing entire blocks of it in graphic shoot-‘em-up games. Even software projects with relatively stable formulaic or quantification underpinnings would be susceptible to variances in available data feeds, or more intuitive ways to convey their outputs, not to mention considerations for the people who were actually hands-on-keyboards, using these systems. Something had to be done about Change Control.
So, along came the Agile and Scrum variants of project management. The interesting thing about Agile/Scrum is that the first element of traditional PM they discarded was traditional parenting (strikethrough) Change Control. In an project environment where the scope could be expected to change dynamically, the old process of writing up a change control notice or Baseline Change Proposal, documenting the precise nature of the change to each of the three baselines, complete with before and after resource-loaded Gantt Charts, and submitting such a package to the several tiers of approval was simply too staid to be workable. Instead, changes could be proposed, evaluated, approved, and set into motion in the course of a single daily meeting. It was as if the two kids could get away with disobeying, the one because the parents couldn’t catch them (Agile), and the other because all of the kids in the house were engaged in the exact same Change Control-defying behavior, and the parents (strikethrough) traditional PMs were outnumbered (Scrum). Problem solved, right?
Well, not so fast. With a lessening of the rigor involved in changing the baseline, the PM’s worst enemy, scope creep, had far more opportunities to encroach upon (and subsequently ruin) IT projects. Why? Because once everybody was okay with – let’s call it what it is – rubber baselines, the next legacy element of PM that could be dispensed with, cost and schedule performance systems, was also soon dispensed with. It’s really too bad, too, since it didn’t have to be that way. I actually did a webinar for PMI’s IT Special Interest Group (IT-SIG), in August of 2008, on how Earned Value Management Systems could be easily upgraded to keep up with an Agile/Scrum project.
From where I’m seeing these trends, the answer, I believe, is to update the Earned Value and schedule performance measurement systems to be applicable to rubber baselines (strikethrough) Agile/Scrum projects, so that their at-completion cost and schedule forecasts can come in to play. If the IT project so engaged is on a path to overruns or delays, the PM can know about it in time to do something about it. If not, she knows she has some latitude to indulge scope creep (strikethrough) dynamic changes to the scope baseline before overruns or delays become likely.
And, lastly, the parents will know in time to respond when their unruly kids are headed towards the tattoo parlor.
[i] Bloch, Michael, et.al, “Delivering large-scale IT projects on time, on budget, and on value,” retrieved from http://www.mckinsey.com/insights/business_technology/delivering_large-scale_it_projects_on_time_on_budget_and_on_value May 16, 2015, 13:17 MDT.
Project Award and Initiation Meeting
Attendees: Hamelin City Council, and one Mr. Pied Piper.
Councilman Marx chaired the meeting.
“So, Mr. … Piper, is it? We are in receipt of your proposal, and have a couple of questions about your stated Technical Approach.”
“Sure, Councilman. What would you like to know?”
“The entire tech approach section is comprised of two words: ‘Trust me.’”
“I prefer brevity.”
“You are fully aware of the scope in our Request for Proposal – elimination of the rats from this town.”
“Without explosives, property destruction, harm to humans or pets, and finish within the week?”
“Yeah, I read that section. I read the whole thing.”
“Well, then, your proposal is approved. When can you start?”
“Right away. I have a couple of questions of my own, though. First off, how many rats would you say we’re looking at?”
Councilman Marx leaned back in his chair, and then squirmed uneasily.
“Latest estimates are 2.3 rats per square meter. In fact, I believe one just crawled up my leg.”
“Doesn’t that creep you out?”
“I’m kind of getting used to them, but my wife detests them.”
“Yeah, I get that. Also, about my fee…”
“This is a cost plus award fee contract, with a ceiling of 20,000 marks.”
“So, if I get rid of the rats, without destroying property or harming non-rats, I get 20,000 marks?”
“If you do so prior to the end of the period of performance, I guarantee you will max out the award fee.”
“Okay, I will take you at your guarantee.”
Post-Project and Award Fee Meeting
“Okay, I got rid of the rats! Where’s my 20,000 marks?”
“Woah, there, Mr. Piper. It’s not that simple.”
“No. As promised, you maxed out the award fee, but that was up to 25% of the total project costs, which we felt was exceedingly generous. By our calculations, you spent one day here. At the rate of 10 marks per hour, and assuming you will bill us for an entire day, that puts you at 80 marks. Add in the per diem rate for Hamelin, plus your material expenses – one flute – and we have a total of 120 marks. With the award fee, that brings us to 145 marks.”
“145? What happened to 20,000?”
“This isn’t a firm fixed price contract, Mr. Piper. It’s cost plus award fee, which means we, as your customer, have to have some form of oversight over your work. Since you failed to disclose your technical approach, we couldn’t perform a risk analysis on it, and therefore evaluate your baselines. We are the offended party here, Mr. Piper, since you refused to comply with our baseline evaluation and change management requirements. But, since you did do such a remarkable job, the City Council of Hamlin is prepared to add to your remittance an additional 500 marks.”
“That’s still not even half of the original deal.”
“True, but we need to spend some money on inter-city relations. You know the town just downstream of Hamelin on the River Wesen, Holzminden? Well, their council is pretty upset with the tens of thousands of rat carcasses floating down the river, and they’re fixin’ to sue us through the Environmental Protection Agency.”
“That’s not my problem. I fulfilled the terms of the SOW to the letter, and I expect my 20,000 marks, or you’ll be sorry.”
“Threats won’t work here, Mr. Piper. Besides, what could you possibly do with nothing more than a flute?”
As we address the May theme, of Change Management, there are many elements…
OUCH! What the heck was that? A dart with Sodium Pentathol? Well, I’m kind of up against my deadline, so I’ll go ahead and see how far I can go before my writing degenerates into meaninglessness (Detractors! DO NOT post comments along the lines of “too late!”).
As I was saying, the main elements involved in Change Management have to do with a commonly-accepted aspect of project management, that no project is completed on-time, on-budget, with the original scope intact. There seems to always be unanticipated events that occur while the contractor is pursuing the scope, events that even the most advanced risk management-type (or least advanced – there really isn’t much difference) can’t anticipate. So, what happens when these unanticipated events – also known as “reality” – occur?
Well, the contractor typically prepares a document to change the scope, cost, and/or schedule baselines. entitled Baseline Change Proposals (BCPs), Baseline Change Notices (BCNs), or whatever, and their purpose is generally the same: to notify the customer that something has changed, it’s gonna take more money and time, and would you please sign your name on to this form so we can keep working?
Generally speaking, though, the nominal approach that most buyers use, that of awarding the contract to the lowest bidder, pretty much invites the nefarious tactic of “low-balling” the contract. This is where the less-than-virtuous proposing contractor deliberately bids a price below what they believe they can execute the scope, relying on the Change Management process to alter the cost and/or schedule baseline to get to a point where the work is actually profitable. Most buyers are aware of this tactic, which leads them to perform the management of baseline changes with a scrutiny that would put Sherlock Holmes to shame.
A version of this buyer/contractor conflict exists in many markets. Right out of my undergraduate work I lived with two roommates, one of whom was a Porsche mechanic. It didn’t matter if the customer came in for something as innocuous as an oil change – all of the mechanics employed at this shop were expected to find other “problems” requiring attention. Usually, the way to manage this effect at the car shop would be to have the member of the family who spent the most time as shade-tree mechanic do the negotiating with the service manager, so that marginally superfluous work, or repairs that should wait, could be declined.
Over on the project management side, though, much of the change management process is often tied up with the establishment and maintenance of certain reserve accounts, Management Reserve and Contingency being the most notorious. When these reserve accountants were first popularized, they had a specific function associated with them. Management Reserve (MR) would be established after the Performance Measurement Baseline had been set, and was created by the project manager issuing a request of each of her Control Account Managers to give back some of the budget (usually around 5%) that they had been originally allocated. If the CAMs neared the end of their part of the work, and needed the 5% back, then it was usually okay. Optimally, the CAMs would find a way to complete the work at a 5% savings; however, if some of them needed more than the 5% they had originally pushed back, then the whole of the project would not be automatically in an overrun condition.
However, the management of MR has been ruined (strikethrough) made weaker by the modern practice of re-defining it. Rather than have it serve a function, it is now often defined by who controls it, rendering it impotent. Previously, the PM had complete latitude with how the MR was used. Now, it’s just another way for the customer to scrutinize the PM, and potentially deny the funds (and latitude) needed for successful project completion.
Wow…the words on the screen are getting pretty blurry at this point. It’s too bad, too, ‘cuz I was just about to launch into a discussion about what I really think of…
There’s a very irksome characteristic of the management sciences that involves the re-introduction of established ideas, but with new names. Of course, if those ideas were all that in the first place, they wouldn’t need to be re-packaged and sold to the same people who had either tried them and found them wanting, or else rejected them out of hand in the first place.
Two examples pop to mind. In 1997, Eliyahu Goldratt published The Critical Chain, a novel about a business school professor who presents as a new and insightful tactic the idea that resources assigned to non-critical activities in a Critical Path Methodology (CPM) network can be temporarily re-assigned to the critical ones, and help shorten those activities, thereby compressing the project’s overall duration. Clever, no? The problem is, it’s an old and familiar tactic, better known by pre-1997 practitioners as “crashing the schedule.” It’s not even that novel a tactic. Anyone familiar with Critical Path Methodology would probably recommend it the first time their project’s end-date needed to be moved up.
There are other problems with critical chain (such as the added costs of assigning non-expert personnel to activities that just happened to be on the critical path), but that didn’t stop the novel’s protagonist from winning out in the end (wouldn’t you just know it?). But “critical chain” sounds so much cooler than “crash the schedule,” doesn’t it? “Crashing the schedule” is how those old guys, staring into their slow-phosphor-burning terminals and mumbling about the proper number of start-to-start relationships in the network would put it. “Critical chain” is how young, thin, hip students of young, thin, hip professors would articulate the concept.
It is, however, the same idea, with the same issues as before.
Another example is the “Life Cycle Costing” craze that hit in the 1980s. All of a sudden, estimators and cost baseline creators were being admonished to consider all of the costs a given project would incur, including post-delivery to the customer. The main example I remember from the trade magazines at the time had to do with buildings, and how important it was to take into account their predicted life-cycle energy costs and water consumption over theirs planned existence. The Life Cycle Costing push had the same two problems that critical chain had: the ideas were hardly new, and they were plagued with problems.
First off, the idea that a construction company would fail to take into account the heating and cooling costs of a building prior to selecting its design and materials is just plain goofy, if for no other reason than the accountants would want to know the basis for amortizing its depreciation. Of course the projected future costs of the projects were taken into account – otherwise it would have been impossible in almost all cases to procure funding.
Secondly, it’s really quite impossible to quantify the future of anything, and that includes the end-result of projects. Referring back to our sample building, other than commodities speculators, who believes that energy costs can be accurately priced going in to the future? And, if our building is in California, who would have believed back in, say, 1997, that water prices would spike eighteen years later, and usage controlled by the government? And those are relatively mild fluctuations compared to the chances of the building being consumed by wildfires, or earthquakes. The assertion that a given building’s “life cycle” can be accurately quantified should be considered as sound as the claims of a tarot card reader, who makes similar statements on the predicting of their customers’ “life cycle.”
Which brings us back to April’s theme, sustainability/green project management. When, in the history of business, has completing a project with an excess of wasted resources been considered a good idea? The answer is never. For example, the plastics industry was furthered from an abundance of the compounds left over from the petroleum cracking process. In economic terms, the very existence of leftover resources that even might have an economic use in a different venue is an automatic signal of a missed opportunity.
Don’t get me wrong – “sustainable” or “green” PM is a great idea, but it’s hardly new. I guess the re-branding of long-established concepts is what we have to do to stay young, thin, and hip.