Game Theory in Management

In honor of the Olympics beginning later this month, I would like to turn my readers’ attention towards very large project management problems; or, better stated, with management problems of very large projects. There’s just something about very large projects that, when they go South, they do so in dramatic fashion, like the Hindenburg or the Titanic. Interestingly enough, Titanic had a sister ship named Olympic, which distinguished herself by colliding with two different ships in her career, which is, I suppose, a superior fate to either of her sisters (the third ship in the class, Brittanic, was sunk during World War I after striking a mine). One of the ships she hit wasn’t even moving, being a lightship.

So, in examining the whole the-bigger-they-are-the-harder-they-fall motif, I would like to discuss the National Ignition Facility, or NIF. As I state in my just-released must-have book, Game Theory in Management; Modelling Business Decisions and their Consequences (http://www.gowerpublishing.com/isbn/9781409442417 ),

The NIF was a project designed to help researchers answer questions surrounding nuclear fusion. The concept was to surround a pellet of a hydrogen isotope with 192 high-powered lasers that could deliver sufficient energy to the target quickly enough to induce nuclear fusion, the same type of reaction that the Sun uses. The project was spearheaded by a scientist, who swore to Senate Appropriations Committee staffers that if Lawrence Livermore National Laboratory was selected to build the project, he would make sure it stayed on budget. Unfortunately, cascading risk events rendered that promise impossible to keep. Work began in 1997 with an estimated budget of $1.1 billion. The final price was nearly quadruple that amount. The Wikipedia article on NIF states:

The Pulsed Power Conditioning Modules (PCMs) suffered capacitor failures, which in turn caused explosions. This required a redesign of the module to contain the debris, but since the concrete structure of the buildings holding them had already been poured, this left the new modules so tightly packed that there was no way to do maintenance in-place. Yet another redesign followed, this time allowing the modules to be removed from the bays for servicing. Continuing problems of this sort further delayed the operational start of the project, and in September 1999 an updated DOE report stated that NIF would require up to $350 million more and completion would be pushed back to 2006.[1]

More problems like this manifested, but perhaps the most damaging risk event had to do with dust. High-energy lasers do not react well to dust: if the various mirrors and lenses used to aim and manipulate the beams have so much as a speck on them, the damage can be explosive, immediate, and expensive. Insufficient consideration was given to the difficulties of performing an extremely large construction effort, with new technology and large, heavy, and expensive components, all in a clean room environment. The early problems with design, construction, and dust cascaded to the point that NIF became the poster child for the perils of failing to perform the project management function adequately.

The truly ironic aspect to the NIF management disaster was the lateness with which management embraced Earned Value and Critical Path-based management information systems. The original estimate of $1.1 Billion (USD) would turn into $4.2 Billion by the time the construction part of the project was complete. Now, it may well be that had NIF management approached the U.S. Department of Energy with an initial estimate of $4.2 Billion, the DOE may have approved the project anyway. But that’s not what happened, leaving the typical management analyst to wonder what might have been. Even a simple Earned Value Management System would have provided early warning of the upcoming overruns, as well as the delays. But such basic project management information systems weren’t implemented in the early phases of the project. Management felt that they could get a handle on the cost performance of the project without an EVMS, with not-enough-life-boats or let’s-fill-the-dirigible-with-Hydrogen-sized consequences (well, to be honest, nobody died, but $3.1 Billion could have done a lot of life-improving, don’t you think?).

Of course, there’s always the possibility that, had a functioning EVMS been in place early-on at NIF, it would have had a similar impact to project controller Frederick Fleet calling NIF’s PM, and shouting “The Cost Performance Index-based Estimate at Completion is indicating a massive overrun, right ahead!”, and then watching helplessly as the failure unfolded. But, from an information technology point of view, it would have at least given some credence to the idea that management wasn’t flying completely blind. Being at the helm of a large project crash leaves those responsible with only a couple of narratives to further, neither of which is very attractive:

·         The “I didn’t see it coming, but then, nobody could have seen it coming” story line. The problem here is, if this kind of problem is out there, lying in wait for any similar effort, why would anyone undertake that kind of project in the first place?

·         The “I knew it was a possibility, but I thought our response to that event would have alleviated its negative consequences” script. This is easily overturned by noting either the number of lifeboats on board being far fewer than needed, or the fact that the lack of an EVMS in the earliest stages rendered project personnel hopelessly ignorant of performance-based cost overruns.

Of course, hindsight is 20-20, and there is a distinct element of unfairness to criticizing management decisions after-the-fact. I understand that, and do not wish to, as they say in American football, “pile on.” On the other hand, if you are (were) in charge of a large project that incurred massive overruns and delays, and you didn’t have a working Earned Value Management System from the get-go, maybe, just maybe you deserve a bit of being piled-on.

What do you think?

In July, Gantthead writers and bloggers will be addressing very large, Olympic-sized themes, so for this, my last blog of June, I thought I’d get some small things out of the way.

First up is the spelling of the possessive impersonal pronoun. “It’s” is a contraction, of “it is.” And yet, when I look at the comments section of major news stories coming across the internet wire, time and time again I see people writing “it’s” when they really mean “its,” as if we should adjust our view on politics or religion based on the fevered rantings of a person who couldn’t pass seventh grade English. When I’m teaching my company’s Variance Analysis Report Preparation class, I make it a point to go up to the white board, and write the word “theirs.” Then, I call on someone in the class.

“What does that say?”

“Theirs.”

“Is it misspelled?”

“No.”

Then, I’ll write “his,” and then “hers,” and call on two more people, who both affirm neither possessive pronoun is misspelled. Then I’ll write “its.” This will invariably elicit giggles.

“You laugh,” I’ll begin, “but I guaran-dam-tee that if I review ten VARs prepared by this organization, I’ll find this error at least once. And you have no idea how stupid that makes us look.”

Next, I want to address those people who insist that any useful Earned Value analysis must be predicated on an extremely accurate estimate. And, if an extremely accurate estimate is not forthcoming, for whatever reason, then, well, the whole EV system must be abandoned. This is idiocy of Cecil B. DeMille proportions, which means, I suppose, that I’ve crossed the threshold from little things to big things, but stay with me. There is no cost management without Earned Value, period. Yet, there are many who either willfully ignore this assertion, or else have a motive for resisting it (yeah, accountants, I’m talking to you!). In order to avoid having a legitimate, simple EV system overtake their bogus faux-cost management system, they will attempt to push the narrative that EV systems are difficult, bulky, and expensive, none of which is true. Which brings us back to the must-have-very-accurate-baselines BS.

The truth is that extremely valuable management information can be gleaned from simple Earned Value systems, even when the time-phased budget is inaccurate. The traditional quick-and easy Estimate at Completion formula, Budget at Completion (BAC) divided by the Cost Performance Index (CPI), can be reduced algebraically to dividing cumulative actual costs (finally! The accountants are relative!) by the cumulative percent complete (on a task, or overall project). This calculation has been shown to be within 10% on projects or tasks that have surpassed the 15% completion point. Note that this piece of information – which has to be considered extremely valuable to anyone intelligent enough to read this blog  – does not require an accurate original estimate. It doesn’t even require a time-phased budget. Those who insist on excessive effort or accuracy in a project’s original budget are actually working against having a legitimate cost management system in place.

Finally, I want to vent my frustration on those who like to pretend they understand Critical Path theory, but really don’t. The most common and obvious manifestation of these people’s ignorance is when they insist that a certain task within the schedule network must be on the critical path, since it’s so important, don’t you know. Of course, whether or not a specific activity shows up on the critical path has nothing to do with its (notice I used the right one?) priority or visibility. It’s (again!) entirely a function of its (three in a row) duration and schedule logic, making anyone who posits to the contrary a mouth-breather.

Schedule logic. Did I say schedule logic? I was once involved in a major project, where the putative project controls contractor had put together a “schedule” in OpenPlan®. Problem was, he had constrained every single activity, both at the beginning and end, and had no – and I do mean none at all – logic ties between activities. When the software refused to calculate the critical path (no doubt sensing the knuckle-dragging intellect behind the scheduler), I was called in to help analyze. When I pointed out that the problem was that all of the activities were constrained, and there was no schedule logic, the project controls contractor geniuses responded by … kicking me off of the project. They actually called in a friend of mine, Brian, from an East coast location of my company, and took him to lunch after having shown him the files.

“So, Brian, what do you think is the problem?”

“All of your activities are constrained. You need to remove the constraints, and add schedule logic.”

“That sounds interesting, Brian. Sell me on that.”

“I’m not going to sell you on that. That’s the way it’s done!”

These are three little things that make me crazy, and I’m sure y’all have more to share. Here’s your chance. Oh yeah, and buy my book (http://www.ashgate.com/default.aspx?page=1751&calctitle=1&pageSubject=956&title_id=11616&edition_id=15149).

That was great of my old friend, Stanly Raspberry, Private Eye, to convey a story in my last blog, about how useless it was to have risk analyst Myron Tittle tag along with him on his last case, but I’m afraid Stanly’s points were a bit subtle. So, I’ll be a little bit more blatant: much of what is presented as modern risk management is fraudulent, and a complete waste of money and time.

I offer a more thorough debunking of current risk management theory in (Marlin Perkins moment alert!) my new book, Game Theory in Management, Modeling Business Decisions and Their Consequences (http://www.ashgate.com/default.aspx?page=1751&calctitle=1&pageSubject=692&sort=title&pagecount=2&title_id=11616&edition_id=15149), but, for this blog, a couple of well-placed arguments should get the discussion rolling (or roiling).  I want to start by picking off that most irksome of risk analysts’ assertions, that “risk management” also includes “opportunity.” Note the gratuitous inclusion of the word in the Project Management Institute’s (PMI®’s) PMBOK Handbook Series on the subject, Project and Program RISK MANAGEMENT, A Guide to Managing Project Risks and Opportunities (PMI Publishing, 1992).  The risk management aficionados simply love to claim that their Gaussian curve-based models can somehow quantify how the future will unfold, so, naturally, they simply had to change the definition of “risk” to include the good with the bad. Hence, the coining of the term “upside risk,” and the inclusion of the management of upside risk, or opportunity, in subsequent PMI publications that deal with the subject. Here is a brief list of reference works that exclude any mention of “opportunity,” or, indeed, anything but hazardous or negative events being associated with the word “risk”:

·         Webster’s New International Dictionary, Second Edition, Unabridged (this book weighs 16 pounds)

·         Webster’s New Collegiate Dictionary, 8^th Edition

·         The American Heritage Dictionary, 2^nd College Edition

·         The Oxford English Dictionary (which, incidentally, included the word’s etymology as coming from the Latin phrase “to run into danger.”)

But, let the Project Management Institute issue “guidance”with an utterly re-defined “risk,” and all right-thinking managers must immediately adopt the new version!

Current risk analysis techniques rely to a high degree on the experiences of the project’s experts to provide best-case, worst-case, and most-probable scenarios to serve as the basis for the estimators’ cost baselines and contingency reserves. Take away the statistical analyses, the confidence intervals and Monte Carlo simulations, and this is what you have – not what went before, but what those creating the baselines perceive as what went before. Our internal narratives – including the ones that explain why the past unfolded the way it did – are full of cognitive biases, rendering the strength of our causality analyses far weaker than we believe them to be (hence, quasi-surreal events like the celebration of Groundhog Day). Why would anyone believe that, once we flip these narratives forward across the Time Now line, they can provide a workable structure for how the future will come about? And no amount of Gaussian-curve-based models overlaying these narratives can magically bestow validity to them.

As I discuss in Game Theory in Management, it’s another example of a management information system far outstripping its epistemological boundaries, and its adherents being placed in the position to having to promise to be able to return information concerning the unfolding of future events, which is obviously absurd.  Nassim Taleb, in his wonderful work The Black Swan, The Impact of the HIGHLY IMPROBABLE (Random House Trade Paperback Edition, 2010) had these two gems:

·         Also, many readers (say, those who work in forecasting or banking) do not often understand that the “actionable step” for them is to simply quit their profession and do something more ethical. (page 334)

·         This proves that everything relying on “standard deviations,” “variance,” “least square derivation,” etc. is bogus. (page 355)

And yet, a Google search on the term “risk management” returned over 63 million results (June 17, 2012), many of them organizations that offer to perform risk management services. I find it ironic that when I write about the accuracy and reliability of Earned Value information, I invariably receive comments along the lines of “It’s only a tool! It has little to do with project success!” But, let me cast any dispersions against the, in my opinion, vastly over-sold efficacy of risk management techniques, and the exact opposite happens, and to a significantly higher degree. In my previous gig, writing The Variance Threshold column for PMNetwork magazine, people would write the managing editor demanding my firing for daring to state that the definition of risk had nothing to do with “opportunity.”

So, that being my experience, I believe there to be a high probability of this blog generating some lively discussion – unless, of course, the risk management types, after having read this piece, are willing to concede the argument.

And I find that unlikely.

Even though the weatherwoman predicted clear skies, it was, in fact, a dark and stormy night. I was staring at my name on my office door, yrrebpsaR ylnatS, eyE etavirP, when two men walked in. They were dressed in dark wool suits, with double-breasted blazers, button-down collars, covered with raincoats and fedoras.

“Are you Stanly Raspberry, Private Eye?”

“It’s what the door says.”

“No, the door says yrrebpsaR ylnatS, eyE etavirP.”

“Yeah, that’s me. Whaddaya need?”

“We’re from the government” one of them began, as he unfolded his badge wallet, “and we need some help from someone with your, say, experience.”

“What kind of ‘experience’ are you talking about?”

The two looked at each other with a mix of anxiety and being in on an inside joke.

“First off, we have a couple of questions for you. Didn’t you used to work for that other project management organization – the really big one?”

“Yeah, for over twelve years.”

“What happened?”

“They fired me. Didn’t like my attitude, I guess. What does this have to do with…”

Before I could finish my question, they dropped a leather portfolio on my desk. My eye quickly fixated on the logo etched into the upper right-hand corner – Monolithic, Inc. That was the “experience” they needed from me.

The previously-silent agent began speaking as I looked through the contents of the portfolio.

“Monolithic was supposed to develop some software that gathered Earned Value information on IT projects that accommodated Agile and Scrum. At the Critical Design Review, they presented the slides you see in front of you. We think there’s something wrong, but we don’t have anybody who is simultaneously an Earned Value expert, knows Agile, AND has taken on Monolithic before.”

“What do you want from me?”

“We have located the computer inside Monolithic’s headquarters that put together this briefing. We think it has the test versions of the software, as well. We can’t do anything improper, of course. But YOU could infiltrate their headquarters, download the previous drafts of the briefing, as well as the source code and notes from their sprints, without anyone having to get a search warrant, or even knowing it happened.”

“Okay,” I responded, “you guys know my rates.”

“One more thing” the first agent added. “We have these new risk management requirements”

“You’re insane.” I objected. “I have neither the time nor the inclination to do a risk management plan. Besides … they’re wastes of money.”

“No, it’s nothing like that. You just need to take Myron along.”

“Who’s Myron?”

Just then a short, balding, bespeckled little man appeared in the door.

“This is Myron Tittle. He’s an expert in risk management and analysis. He will be accompanying you to both help you achieve mission objectives, and to be our eyes and ears.”

“I work alone.”

“We’ll double your retainer.”

“Welcome aboard, Myron!”

* * * * *

We stealthily approached the edge of the woods on the hill overlooking Monolithic’s office building. It was 5:00 in the morning, but I knew that Monolithic’s over-pressured and overworked employees would start showing up soon. The perimeter was patrolled by guards, towed by menacing Dobermans.

“What’s your plan?” Myron queried, in his nasally little voice.

“We need to get past the guards. Once we’re in, I can get you to the office where the computer resides, and you should have about ten minutes to download your files. After that, we change into custodian’s uniforms, and simply walk out. They don’t check employees leaving, only arriving.”

“No, no, Mr. Raspberry” Myron chortled. “Even if you got past the guards, there’s a badge reader-activated steel door just inside the foyer. I estimate the odds of your plan working at 1 in 1,287. Since your original schedule for this project was around four hours, we should contact the agents and request a contingency reserve of 214 days.”

Just then, light streamed from a side door that had been opened by a guard who was on break, and was stepping out for a cigarette. He lit his cigarette, tossed the match, and then walked around to the far side of the building. I jumped to my feet, grabbed Myron by the arm, and started running for the open door.

“You were saying?”

* * * * *

We immediately headed for the office where the computer was located.

“Don’t make eye contact” I told Myron. “Act as if you are a nobody, and dread being here.”

We arrived at the target office, and went in. Myron produced a writable CD, booted up the computer, and starting searching directories.

“Here it is!” he exclaimed, quickly followed by an “uh, oh.”

“What is it?”

“This computer doesn’t have a CD burner. This being an ‘unknown unknown’ contingency event, I now estimate the odds of our successfully completing the remaining project scope at…”

“Here, use this” I told him as I handed him a thumb drive.

“How did you know that these computers couldn’t burn CDs? Oh, I know, it was based on your previous experience, compromising Monolithic’s security, right?”

“No, I just like having a spare thumb drive, especially for work like this.”

“Wow! I would estimate the value of your contingency plan at…”

“Myron! Just copy the files, okay?”

* * * * *

Back at the office, the two agents had returned. Although they had changed clothes, their appearances were remarkably similar to the evening before. I handed them the thumb drive.

“Another case solved by…”

“Not so fast, Raspberry!” one of them growled. “Your project’s been cancelled!”

“Cancelled? What do you mean?”

“When we received Myron’s request for a schedule contingency of 214 days, our program director immediately terminated the contract. We sent you an e-mail with the stop-work order at 5:12 a.m. this morning.”

“This is absurd! I performed the project’s scope perfectly!”

“Sorry, Raspberry, but our risk managers see it differently. By the way, you’ve been banned from further government work for three years.”

"Can I have my thumb drive back?"

"What thumb drive?"

“Uh huh. Is Myron available? I’d like to have a word with him.”

“He’s been reassigned to a project to prevent nuclear weapons from falling into the wrong hands.”

I reclined in my leather office chair, and sighed.

“We’re doomed.”

Yvonne Polmanteer’s comment on my previous blog started with the sentence “I see egos and politics becoming more and more of a stumbling block for projects,” and I think she’s spot-on. Like Gantthead contributors Kenneth Darter and Michael Wood, I have a few things to say about project politics, and I believe a little game theory can help. For the sake of this discussion, I’d like to define office or project politics as those acts performed by individuals that further their personal agendas at the expense of achieving the goals of either the project or the performing organization. Proceeding from this definition, I would like to discuss two similar creatures: Hawks, and Jungle Fighters.

As I discuss (Marlin Perkins alert!) in my newly released book, Game Theory in Management (http://www.ashgate.com/default.aspx?page=1751&calctitle=1&pageSubject=692&sort=title&pagecount=2&title_id=11616&edition_id=15149), a favorite game for evaluating, calculating, and predicting aggressive or passive behavior patterns is the Hawk-Dove game. Imagine two birds who share a common environment. If they act peaceably (like doves) towards each other, then they forage for food, and consume it. So their payoff for choosing a Dove strategy is the daily available food supply (V), divided by the two of them (V/2). Note that this strategy maximizes the payoff for the entire population of birds in the given environment. However, if the daily available food supply drops below the level to keep them both alive, then at least one of them must act aggressively (like a hawk) towards the other by taking part of its claim to the food supply if it is to avoid starvation. The Hawk’s payoff, then, becomes the entire food supply (V), minus the expense of actively taking the other bird’s food, or preventing them from foraging in the first place (C). Of course, the birds may elect a Hawk strategy even if starvation is not a threat.

Now, imagine a population of 100 birds. Again, the payoff for the entire population is maximized if they all select the Dove strategy. But, with the introduction of even one Hawk, the Nash Equilibrium – that point at which the individual game participants can not improve their payoffs by changing strategies – quickly works out to 25% Hawk, and 75% Dove. While this may manifest as 25% of the birds acting as hawks all of the time, the usual outcome is a given bird chooses to act aggressively one-quarter of the time, and like a dove the other times.

Industrial psychologist Michael Maccoby’s brilliant book The Gamesman (Simon and Schuster, 1976) posited four broad types of workers:

• Craftsmen, who don’t really care for whom they work, but care a good deal about the quality of their output;
• Company Men, who tend to adopt the persona of the organization for whom they work;
• Jungle Fighters, who indulge in calumny and deceit in order to get ahead, and
• Gamesmen, who view their participation in the workplace as a game, one they intend to win.

Of the Maccoby archetypes, the Jungle Fighters are clearly the most political. As they further their personal agendas (at the expense of the organization’s or project’s goals), they make it a point of minimizing the achievements of their perceived competitors on the team, while conveying and amplifying their mistakes. Like the Hawk-Dove game, the project team performs best when each of the participants pursue the team’s goals first and foremost; however, with the introduction of even one Jungle Fighter, the Nash Equilibrium for selecting Jungle Fighter strategies will be quickly realized, and it won’t stop or be confined to the existing number of Jungle Fighters on the team. Some members who would not ordinarily select Jungle Fighter strategies will soon find themselves in a position to either start, or have their standing and influence within the team severely eroded.

So, how does one counter?  Keeping in mind that the influence of office politics is widespread, powerful, and damaging, and that this blog’s title includes the term “101,” indicating beginning-level, I recommend the following tactics:

• Know that Jungle-Fighter-free project teams and organizations are extremely rare, and you will need to be able to identify the Jungle Fighters around you as early in the project as possible.
• Nullify their favorite tactic: the ex parte conversation. I once worked for a manager who inherited a highly political group. His first action was to announce that, if any employee came to him with a criticism or “concern” about another member of the team, he would immediately stop that conversation and call that other person into the office. The influence of the Jungle Fighters took an immediate and significant hit.
• Once they have been identified, and their favorite tactic removed as an option, if they continue to select Jungle Fighter (highly and negatively political) strategies, they must be eliminated from the project team or organization. Of course, if you are not a manager, this is difficult if not impossible.

Sadly, many organizations (a) don’t want to recognize that managing people in such a way as to deviate from a pure meritocracy is extremely damaging, and (b) recognize that politics is in play, but don’t want to do anything about it. Such organizations are vulnerable to a Jungle-Fighter-initiated tail spin, as more and more workers who would not normally engage in Jungle Fighter strategies come to believe that they must. These projects only end badly. So, the game then becomes one of recognizing when you are working for such an organization, and knowing when to leave a lost cause.