Game Theory in Management

It was another dark and stormy night. I was sitting at my desk, looking at my name stenciled across the frosted glass-paned door, yrrebpsaR ylnatS, eyE etavirP, when the phone rang.

“Raspberry? Is this you?”

I immediately recognized the voice as Ivan Gettim, probably the only detective on the force who would voluntarily interact with me.

“Yeah, it’s me, Ivan. What’s up?”

“Get out here to the Stratmon Mansion – it’s way out here by Riverside, and the local police don’t know how to even approach a homicide.”

“There’s been a homicide?”

“Yeah, old man Stratmon himself. Just get out here.”

By the time I arrived at the Stratmon Mansion, Ivan had assembled Stratmon’s family, friends, and members of his giant corporation’s Board in the spacious library.

“Raspberry! Glad you’re here. The tape outline there shows where the body was found. There are no signs of a forced entry, and none of the witnesses heard or saw anything unusual.”

“How did he die?”

“We don’t know that yet, either. There were no marks on his body, and the initial toxicology scan has ruled out poison. But he did have a pen in his hand, and nearby, on his desk, he wrote ‘strategic mgmt.’ Why do you suppose he wrote that, rather than his killer’s name?”

“Probably because he didn’t know his killer’s name, but did know the likely motive. It does suggest, though, that the people in this room are innocent – otherwise, he would have named one of them.”

A short, thin fellow with round wire-rimmed eyeglasses and wearing suspenders and a bow tie spoke up.

“I don’t know who killed him, but I do know how you can find who did.”

“This is Tut Tutworth, the head of accounting” Ivan explained.

“Lay it on me.”

“According to our last profit-and-loss statement, old man Stratmon recently had a large windfall hit the general ledger, from selling some assets he had originally acquired at bargain-basement prices.”

“Yeah. So?”

“Sooo…” Tut started, clearly annoyed, “just find the previous owner of that set of assets, and you have your killer.”

Ivan and I exchanged confused glances.

“Why? Was the previous owner somehow coerced into selling to Stratmon?”

“Not as far as I know, but he had to be furious. Wouldn’t you be?”

Confused glances all around.

“I may not know exactly where to start looking, but I think I have a clue” stated the pretty woman sitting next to Tutworth.

“And you are…?”

“Piem O’Dagger, the head of the Project Management Office.”

“What’s your clue?”

“I managed Stratmon’s entire project and program portfolio, and there was only one client whose projects were consistently plagued with cost and schedule performance problems.”

“Yeah. So?”

“Just find out who the client’s PM counterpart is, and you have your killer!”

More confused looks all the way around.

“Are you saying that this customer would resort to killing his contractor’s owner rather than seek other remedies? Who is this client, anyway?”

“An industrial laundry and chicken-themed restaurant chain in Albuquerque, New Mexico.”

Knowing glances all around.

“Still, that’s more than a little drastic. We’ve heard from the asset manager, and the project management office director – is there anybody here from the strategic management sector?”

More confused glances all around.

“I’m the head of finance and accounting, and Piem here is the director of the project management office – you can’t get any more strategic than that!” Tutworth stormed.

“You guys don’t get it, do you?” I stated. “Strategic management, or alignment, isn’t just doing asset management or program/project management at a high level, or on large portfolios.”

“Do tell” Piem began, icily, “how you define strategic alignment, and intend to find the killer.”

“Alright. But first, I need to talk to one person, and that person’s identity is…”

…going to have to wait for next week, since I’m out of space! In Part 2, we’ll have a working definition of strategic alignment, how the other types of management properly interact with it, and, just maybe, the identity of the killer.

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.