Game Theory in Management

I want to lead my readers on a little thought exercise. Imagine being a member of the Star Trek  alien race Vulcan. Vulcans are logical and intelligent, usually above human norms. Now imagine visiting Earth on February 2^nd of a given year in the 23^rd Century, in a town in central-Western Pennsylvania, where you see a large group of humans – some attired rather formally – gathering around a burrow of a large rodent, to observe whether or not it will “see its shadow.” Several near-logical things pop to mind:

·         Since we cannot know what the Marmota Momax perceives with respect to its shadow, the first line of inquiry should be to determine if the groundhog in question has a concept of casting a shadow.

·         That the humans, apparently, have not conducted such an investigation, the question now seems to turn on whether or not the groundhog casts a shadow, the assumption that, if it does, it will see it.

·         And change the weather.

·         Wait, that’s a leap. We’ll leave unchallenged (for now) the assumption that groundhogs are aware of their shadows, and those circumstances where such shadows are cast.

·         In other words, whether or not it is sunny.

·         So, if the line of inquiry now is to ascertain whether or not it is sunny, why are the humans pulling the rodent from the burrow? Can they not simply look up into the sky?

·         Additional lines of experimentation:

o   Move the rodent away from Pennsylvania, to see if it is specifically the groundhog’s shadow that portends weather patterns, or simply the fact that it happens to be in that locale.

o   If the former, many rodents from many locales should be pulled from their burrows on this date.

o   Alternately, the humans from those locales could simply look up to see if they can see the sun, and leave the rodentia alone.

…and so on.

In short, the whole concept is profoundly illogical.

So, where did it come from?

Lots of speculation on this. Most of it centers on the Northern European customs from farming communities. You see, misjudging the timing of Spring Planting could easily mean the difference between affluence and poverty, or even life and death. Assuming that the forest animals had some kind of instinctive knowledge of when the last freeze would occur, the farmers would study some of them closely, to tease out clues that could be used to ascertain the exactly appropriate day for planting. By degrees, we get the happenings at Punxsutawney.

The point? Things change, and they do so in such ways as to preclude reasonable forecasting (one estimate of Punxsutawney Phil’s accuracy rate sets it at a dismal 39%). Recall the old axiom, that which is measured gets managed. Well, here’s Hatfield’s addendum to that: the future cannot be quantified, therefore, it cannot be managed. How the unfolding future impacts a given project’s scope, cost, and schedule baseline can be managed, but this is a very different animal (get it?) from actually managing change.While “change” really cannot be managed, performance can; however, real performance management hinges on accurate performance measurement systems, which, in turn, depend on non-rubber baselines to function. 

So, there you have it: if the information you are gleaning from your de-burrowed rodent doesn’t change project performance, you’re not doing change management.

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 7^th 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.

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.”

“Sure.”

“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.”

“It’s not?”

“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…