Game Theory in Management

Like stand-up comedians who spend too much time ridiculing television commercials, I don’t want to fall into the trap of making fun of consultants too often. True, they’ve been known to be wrong.

And can be arrogant towards the existing project team members.

And usually waaayyyyy overpriced.

And, if they stick around too long, become ipso facto evidence of executive ineptitude.

Some also have the unfortunate tendency to describe their time with your project team as one of their saving a woefully backward organization from ruination, due to their timely expertise, don’t you know.

But other than that…

Now that I’ve written the previous paragraph out, I’m not so reluctant to fall into the making-fun-of-consultants-too-often trap.

I’m not really worried that my friends who make their livings as consultants will be upset with me. They generally do not read this blog – they’re too busy consuming guidance-themed drivel that can be translated into eat-your-peas-style hectoring, on those occasions where they deign to stay current with PM literature at all. That’s how they make their money, generally speaking. I’ll explain.

Of course there are real value-added consultants, but there’s also the mock-worthy variety. How do you tell the difference? Check the following table:

Also consider the function your consultants fulfill. Anybody can sit around and offer up criticisms of the management decisions that have gone before. Hindsight is, as they say, twenty-twenty. It’s so easy, in fact, that people outside the project team should have to pay the PM for the luxury of doing so while everybody else pretends to listen to what they have to say.

But the ultimate consultant acid test will reveal the real deal, if you have one. Recall Hatfield’s Incontrovertible Rule of Management #11: the 80^th-percentile best managers who have access to 20% of the information they need to obviate a given decision will be consistently out-performed by the 20^th-percentile worst managers who have access to 80% of the information they need. This being the case, the consultants worth their weight in budget underruns will seek to set up and maintain such systems, without an iota of excess cost or difficulty.

And that’s how you tell the pros from the consultants.

When we left our hero last week, the secret conference room full of PAIN operatives had just erupted in a sound that can be best described as what would happen if somebody told a really funny joke at a Darth Vader impersonators’ convention. In the middle of the laughter, a man disguised as a waiter leaned over to my side.

“What are you doing here?” he whispered.

I looked up into the eyes of Cameron McGaughy, ProjectManagement.com’s managing editor.

“Cameron?! What are YOU doing here?”

“ProjectManagement.com has its ears open to these kinds of things. Anyway, the theme for March was supposed to be global communications. So, let me ask again – what are you doing here?”

“Well…” I whispered, “This kind of guidance issuance has an impact on how PM techniques are transmitted around the world, so there’s that.”

“You’re on pretty thin ice here, Raspberry, but carry on. We’ll see how this ends.”

As the laughter died down, the chairman continued.

“As we continue to insist on these line-item comparisons between budgets and actuals, the original baselines will be turned to rubber, engendering endless debate about supremacy of policy preferences. The confusion emanating from these debates will cloud the issue for years!”

I held up my hand.

“Do any of these documents you’re issuing actually add to the practical use of Earned Value techniques?”

Gasps again erupted from the participants, this time moving enough air to disturb some of the papers on the table before them.

“Why would you ask that, Max? Aren’t you on board with our true purpose?”

“Oh, yeah, sure I am. It’s just that I was told that we had to maintain some sort of veneer of valid management science advancement.”

Again the room began murmuring, with an occasional “Oh, yeah” and “he’s right, darn it” becoming audible.

“That’s true” the chairman responded, “but highlighting the divide between practical application and what we’re presenting as true goes too far.”

He continued “So we are on an acceptable pace to attain our final goal.”

I hoped someone would pipe us and ask “That being?”, but nobody did. However, another attendee did ask “Okay, boss. But once we’ve attained that goal, who’s going to maintain the ‘you’re doing it right’ versus the ‘you’re doing it wrong’ ledger? Our friends over in software development blew up our previous attempts when they came up with that incredibly practical ‘agile’ and ‘scrum’ business, and it’s taken this long to get back to where we are now.”

That’s when it hit me: the purpose of this little council was to create a codex of project management rules and regulations that would provide these so-called experts with the ability to demand adherence to process, and eschew practicality in application.  If it worked out, they would be empowered to forever say “you’re doing it wrong,” and point to some part of this codex to back them up.

In short, they wanted to entrench process over actual performance as the key to “proper” PM.

Along about this time I felt a small gap in-between my upper lip and fake mustache. Fearing that my disguise was beginning to fail, I decided to speak up one last time.

“We should arrange for Monolithic Corporation to make that determination.”

“We all agreed to not mention any company names” began the poorly-shaven fellow next to me. “Hey! What’s this?”

He then grabbed my fake mustache, and pulled it off my face. This time, the attendees gasped so loudly that loose papers leapt off of the table and were plastered onto their faces.

“Raspberry! Get him!”

In the time it took for the attendees to get their loose papers off of their faces, I sprinted down the hall and up the secret staircase. Charlie Gumshoe was waiting in the car just outside.

“Did you get it? Do you understand what they’re up to?”

“Yes, and yes. And you’re never gonna believe this…”

Situation: Dark and stormy night.

My mission: infiltrate the Project Association for Industry Non-Autonomy (PAIN), in order to glean their motives in churning out so many suspect guidance documents on project management information systems.

My name: Raspberry. Stanly Raspberry.

Duhh duh DUH duh. Duhh duh DUH duh DUHHHHHH……

The story you are about to read is not true. The names have not been changed, since they were made up in the first place.

Duhh duh DUH duh. Duhh duh DUH duh DUHHHHHH……

“That wig and fake mustache make you look like Geraldo Rivera” snarked Charlie Gumshoe, my contact within the force.

“Then why didn’t you do this disguise-and-infiltrate business yourself?” I asked.

“You know that officers of the force can’t do that, Raspberry – we need a free lancer, like you.”

Charlie was driving me to the facility where the key players from PAIN were scheduled to meet.

“Remember” he began, “only a few of these guys have ever met face-to-face. We ‘borrowed’ your entry credential when one of their members from Las Vegas turned up in the hospital, and told us what was going on when he was under anesthesia.”

“Then why do I need a disguise?”

“Because some of them might readily recognize you – we understand Monolithic Corporation has a heavy presence there.”

I might have known Monolithic had their meddlesome hands in this.

“Don’t forget” Charlie continued, “you’re Max from Las Vegas, but we’re not sure which interest you represent. Since all of these attendees consider themselves experts in the field of project management, only speak up if you are completely confident you have the intellectual high ground. Otherwise, just listen. We need to know why they are issuing all these guidance documents, some of which we believe have some instructions that make little practical sense. We just can’t figure out why any organization would go through all this trouble to issue shaky guidance.”

Charlie pulled up to what appeared to be an abandoned factory.

“This is where they’re meeting?”

“It’s the address on your invitation.”

I stepped out of the car, and walked through the door on the front of the shattered facade, as if I had been there before. Rubble was strewn about the puddle-ridden floor, but an exit sign on the far side of the room was brightly lit. I strode towards it, and noticed a device that looked very much like a badge reader. Checking my credential, it had a magnetic stripe – so, I used it.

The floor beyond the exit sign seemed to fall away, revealing a staircase going down to a basement. I walked down the stairs with a rising sense of apprehension. At the bottom of the stairs was a dimly-lit hallway, which terminated at a red door. I walked through the door.

Inside was an advanced-technology conference room, with a large C-shaped table. In the middle of the room, surrounded by the table, was a metal sculpture of what appeared to be seven or eight binders, each overflowing with pages, stacked atop each other.

“Max! We’ve been waiting for you! Now we can begin!” said the portly speaker, who took his seat at the top of the “C.”

“Our last issued guidance document mandated that cost performance systems compare the line items in the Basis of Estimate with their counterparts in the general ledger, as part of ‘cost performance management.’”

“Excuse me” I interjected, “but isn’t that just comparing budgets to actuals? And isn’t that automatically not ‘performance management’?”

There was an audible gasp from the participants.

“Why wouldn’t you want to know that?” demanded the poorly-shaved fellow sitting next to me.

“That’s not the issue. Whether you are comparing cumulative budget to cumulative actuals, or period line-item budgets to period line-item actuals, that’s certainly not Earned Value Management, and therefore not performance measurement.”

Angry-sounding murmuring erupted among the attendees.

“But it does amp up the number and difficulty of approved processes, does it not?” asked the portly chairman.

“Oh, right!” I exclaimed, feigning enthusiasm, while realizing that I might be hearing clues about PAIN’s ultimate goal.

The chairman continued. “That, combined with our push to have Estimates to Complete constantly re-estimated, and then time phased, allows us to demand that same comparison on a month-by-month basis! No contractor performing project work can ever avoid a reportable deviation from such an analysis!”

At this point the room erupted in a sound that can be best described as what would happen if somebody told a really funny joke at a Darth Vader impersonators’ convention. In the middle of the laughter, a man disguised as a waiter leaned over to my side.

“What are you doing here?” he whispered.

Terrified that I had blown my cover, I turned to see that it was…

Wow, look at that! I’m out of space for this week. Tune in next week to see the amazing conclusion of Stanly Raspberry and the Procedure Conspiracy.

Think back to what you’ve read about traveling “medicine men” in the United States, circa 1870 to 1900. These men made a living by being able to mimic the true medical professionals of the day, and selling concoctions that looked, smelled, and tasted like how they thought medicine should look, smell, and taste. Of course, they could not be honest about their compounds’ true ingredients if they were to extract money from gullible audiences.

But that’s kind of the point, isn’t it?

As an aside, I’ve always wondered: doesn’t the alleged existence of “snake oil” – the clichéd main ingredient of these concoctions – imply the presence of a “snake press,” much as the existence of olive oil implies an olive press? And, if so, how hard would you have to press a snake to extract oil from it?

Meanwhile, back in the PM world…

A self-appointed guidance-generating organization recently issued a document (I don’t want to name the organization or guidance document directly, ‘cuz then I’d have to scale back the tone of my condemnation, and where’s the fun in that?) on Earned Value Management Systems, and one of their legitimate-sounding diktats ideas is that the Estimate at Completion (EAC) should be derived by re-estimating the project’s remaining work, and adding that figure to the cumulative actual costs. I simply have to ask: is this legitimate management science, or is it quackery?

The alternative method for deriving the EAC is to calculate it, with the most common formula being to divide the Budget at Completion (BAC) by the Cost Performance Index (CPI), so:

EAC = BAC / CPI

There are other formulas, but we’ll use this as the basis for comparison. Is it accurate, and can its accuracy be shown scientifically? Yes, and yes. Dave Christensen, Ph.D. has written several papers on the topic. Pulling data from real-life projects, Dr. Christensen has established that the calculated versions of the EAC are consistently accurate to around 10% of the projects’ final costs. For the record, one professional society has published data showing that a detailed cost estimate, produced by a professional estimator using off-the-shelf software, is accurate from 25% to 15% of the projects’ final costs. At this point it must also be noted that calculating the EAC is far easier than having to create a detailed re-estimate the remaining work. For those who object that the estimate of the activities’ percent complete – the basis of the CPI figure – is subjective, I would counter that every single line item of the new estimate is at least as subjective. In addition, the calculated EAC feels no pressure from upper management to make their at-completion forecasts palatable, unlike the re-estimated version. To sum up:

So, what gives?

Why would the more difficult, less accurate, and politically-prone version of a critical project performance parameter get the nod over its clearly superior alternative? When one considers the history of how poor hypotheses become embedded in a body of knowledge, the management sciences appear to be particularly vulnerable with regard to this very sort of issue. I will also point out that, once a profession begins to base their standards on this sort of expert speculation rather than methods that have established their superiority in multiple real-life projects, it virtually invites an invasion of poor guidance.

But that’s kind of the point, isn’t it?

Perhaps the experts pushing this kind of management science hypothesis can also let us know the exact pressure needed from the snake press to produce usable snake oil. I mean, if we're just speculating, why not?

Lagniappe

My webinar on the 16^th could have gone better. My stupid computer crashed three times, and needed a few minutes each time to re-boot and get back to the chat room. In a way, it was a left-handed blessing, in that it forced me to focus my ideas into a suddenly-reduced time frame. The gracious and professional Stephen Strickland (the host) said it went well, but I’m not looking forward to the attendee evals. Next time will be better, I promise.

Some schools of Communications Management thought hold that a significant contributor to the conflicts in personal relationships, business, foreign affairs, etc. is simple misunderstandings. When transmitting, we are told to be careful about the words we choose, monitor body language, and spend energy to understand where the intended receivers of our transmission are coming from. Similarly, when acting as receivers, we’re taught to, again, understand the motives and feelings (!) of the transmitter(s), watch their body language, and take in not just the denotative meaning, but any connotations that may be transmitted as well.  All of which reminds me of my early days in programming.

After I Tied My Horse To The Hitching Post…

When I was a junior in High School, I took a semester of computer programming. Half of it was in BASIC, the other half in FORTRAN (if those names don’t mean anything to you, I don’t want to hear about it). The mainframe computer wasn’t located on campus – we had to create a stack of punched cards that were loaded into a “hopper,” which would scan the cards, one by one, and transmit them over the land line via a modem to the mainframe’s location. Needless to say, much could (and did) go wrong with just the transmission phase (see where I’m going with this?). Even if there were no typographical errors in the punched cards, some of the cards could become dog-eared if they had been sent more than once, and this would cause a fatal interrupt of the transmission phase. Only after the entire deck – remember, there was one card per line of instruction – was successfully transmitted would your program run. If there were errors in the code itself, the real task of debugging began.

Which brings us back to the art of far-flung communications within the far-flung project team. Using the analogy of my pre-historic programming days, the so-called communications experts would have us believe that the majority of times your code didn’t execute as planned, it was because of typos in the punched cards, or a problem with the card hopper. It rarely seems to enter their lexicon that the program being transmitted has errors in it, and that’s the reason it won’t execute.

What Are We Communicating, Exactly?

One of the basic precepts of one of my favorite targets, the risk managers, is that such a thing as “upside risk,” exists, and it is the exact same thing as opportunity. The first time I encountered this bizarre notion was when I was writing the Variance Threshold column for PMNetwork magazine, and I dared to reference the commonly-held definition of the word “risk.” E-mailed complaints poured in from the risk management community. When I responded with the Webster’s, Oxford English Dictionary, and Wikipedia definitions of the word “risk,” pointing out that nowhere in those references did anything positive appear, much less the nominal antonym “opportunity,” the RM-types merely cranked up their vitriol. It turns out that they had successfully lobbied to have the term “risk” include this “upside risk/opportunity” aspect in the glossary section of the (then) version of the PMBOK Guide®, and they weren’t about to allow a mere columnist to challenge their definition.

In other words, their program didn’t work, so they sought to obfuscate this fact by blaming the card-hopper. It was my pointing out the obvious fact that, previous to their finagling, the word “risk” had nothing but negative terms associated with it, which had set them off. In fact, the methods for managing opportunity have nothing at all to do with Monte Carlo simulations, Decision-Tree analysis, or any of the other RM techniques, and no valid proposal management system is predicated on those techniques. But, in order to support the assertion that RM covers all potential occurrences to a project, both negative and positive, the risk management-types simply had to attempt to change the plain meaning of a commonly-known word in order for them to maintain their invalid concepts.

I’m Good With New Stuff – Really!

I’m well aware that it’s considered a significant step forward in project management space to take advantage of improvements in telecommunications technology that allows cross-continental project team meetings to occur easily and cheaply. I have no problem with that. What does cause me heartburn are the attempts to change the denotative meanings of commonly-known words in order to buttress dubious project management precepts and force them into a more prominent position within the PM codex. Being able to conduct teleconferences across the globe means little if the participants’ knowledge of the definitions of the words and terms being used are being incrementally altered away from their original meanings.

In short, the communications fail here isn’t that I can’t hear you. I can hear the words you are using just fine. You’re still wrong in the way you risk management-types (and others of your ilk) are using them.

Lagniappe

I'm doing a webinar this Thursday, March 16, at 1:00 EDT, sponsored by ProjectManagement.com. It's on basic Game Theory, and I'm giving away five of my overpriced books (Amazon has them for around $100). Hope to hear from my readers then!