Game Theory in Management

From the Contradictory Proverbs[i] web page, a few examples:

a)      Look before you leap.

b)      He who hesitates is lost.

a)      You’re never too old to learn.

b)      You can’t teach an old dog new tricks.

a)      Winners never quit.

b)      Quit while you’re ahead.

The web page’s list goes on and on, but you get the idea. So, who thinks that it’s at least possible that some of the management science theories that have been propagated and largely accepted over the past millennium are also only conditionally true, or even blatantly contradictory? Consider:

a)      Shareholder wealth is the appropriate goal of a business firm in a capitalist society.[ii]

b)      Make a customer, not a sale.[iii]

a)      The purpose of risk management is to identify potential problems before they occur so that risk-handling activities may be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.[iv]

b)      It is in the admission of ignorance and the admission of uncertainty that there is a hope for the continuous motion of human beings in some direction that doesn't get confined, permanently blocked, as it has so many times before in various periods in the history of man.[v]

In pursuing ProjectManagement.com’s theme for June, that of Strategic Alignment, by reviewing the current literature on the topic, there is, well, some silliness to wade through – so let’s get to it.

We’ll start with the most notorious category of management science that claims to produce critical information on an organization’s strategy selection but, in fact, is wholly inadequate for the role. That’s right, I’m talking about our friends, the accountants. The first set of contradictory proverbs in the second set illustrates pithily the difference in approach taken by the Asset Managers and Project Managers. Asset Management is largely predicated on the “maximize shareholder wealth” meme, as I have pointed out a few times in this blog. Conversely, Project Management is all about delivering the customers’ expected scope, within the customers’ time frame and budget.

While this means that PM theory is significantly closer to applicability in the Strategic Management world, the last pair of juxtaposed quotes represents a hint that we’re not quite there, either. Risk Management is big business, and considered in many quarters to be a key component of Project Management. But even if we PM-types concede the argument that some aspects of the project’s unfolding future can be captured and prepared for, there is no Gaussian-curve based technique that can possibly predict the behavior of the organization’s competitors, and performance against competitors is what Strategic Management is all about.

Soooo… with what, exactly, are we aligning our strategy? With popular but ultimately unsound, or even contradictory theories? Sadly, discussions of Strategic Management often devolve to such misalignment. In this month’s series, I hope to skewer some of these overreaching theories.

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