Game Theory in Management

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!

I believe that one of the most fascinating things about history is that, while technology advances in amazing and utterly unpredictable ways, human nature tends to remain the same. Exhibit A for this assertion is the fact that, at the beginning of the 17^th Century, physicians believed that illness was caused by an imbalance of humours, a concept considered so utterly absurd by today’s medical professionals as to represent an embarrassment. It’s also a fair bet that 24^th Century physicians will look back at today’s medicine and consider it barbaric. Conversely, the author of Shakespeare’s plays (I’m an Oxfordian, myself) penned insights so profound that those works are considered masterpieces to this day, and probably will be for some time.

I think something very similar occurs in project management space. I remember back in the early 1990s using a robust Critical Path Methodology (CPM) software on the just-becoming-commonplace desktop computers. If your schedule network had more than a couple hundred activities, in order to have the software perform the forward pass, backward pass, find the critical path and compute float, you would have to give it the command to do so, and then pretty much just go to lunch, since it was going to take about an hour (particularly for the resource-loaded versions). These days, those calculations for a several thousand activity network can be accurately performed virtually instantaneously.

However, even as the robust PM software platforms become easier to use, and the traditionally easy-to-use ones become more robust, some problems remain intransigent, and these problems involve human nature. Consider the following (by no means exhaustive) list:

• Managers who fancy themselves experts at PM refusing to set up a legitimate Work Breakdown Structure (WBS).
• So-called project controls specialists putting Organizational Breakdown Structure (OBS) elements into the WBS.
• Accountants refusing to set up the project’s chart of accountants so as to collect actual costs based on the WBS.
• Executives refusing to employ Earned Value or Critical Path methodologies, even on their larger projects.
• Accountants (again) claiming to be able to perform cost performance without Earned Value, based only on the information available from the general ledger.
• Administrators claiming to be able to perform schedule performance analysis based on a list of milestones, and polling those responsible to see if they believe those milestones will be completed on-time.

Don’t think for a nanosecond that these human nature-based difficulties in attaining peak PM performance are confined to the uninitiated. The so-called experts, who present as if they are on our side, can be even worse, to wit:

• The insistence that all work – even scope that should not be managed as a project – be managed as a project.
• The imposition of absurdly brief time spans as the maximum duration an activity (or even Work Package) can be planned, or scheduled.
• Requirements for a risk register, risk management plan, Decision Tree or Monte Carlo analysis, etc.
• Imposing – as audit standards, no less – analysis techniques that involve comparing the time-phased budget to their direct counterparts in the actual costs from the General Ledger. This problem, of comparing budgets to actuals and claiming the result to be some form of cost performance analysis, is as old as it is pervasive – even among the so-called experts.
• Demands to “engage stakeholders,” even if these stakeholders are potentially hostile to your project’s outcome.
• Imposition of unrealistic quality control standards.
• Insistence on an extreme level of detail or granularity in project status reporting.

The real irony here is that the latter group – the so-called “experts” – are easily as damaging to the widespread acceptance of project management as a school of thought as are those who oppose it from ignorance, or intransigence. Both groups resist “doing” PM, the former because they don’t understand it, the latter because it’s not being done to their unscientific standards. The uninitiated maintain that even very basic project management information systems are too onerous, while the “experts” will assert that even advanced, capable systems aren’t onerous enough. The net impact is the same and, in my opinion, probably universal: project management, as a discipline, is frustrated in its attempts to gain more widespread acceptance.

And this frustration isn’t technological. It’s rooted in human nature, and will therefore probably remain the same. Hey! I wonder if some 24^th Century project manager uncovers this blog, and shows it to his friends, will they will laugh at how backward it is, or say something like “things really don’t change that much, do they?”

I was once assigned to provide project controls support to a fellow who thought of himself as highly advanced in project management. At our first meeting, after introductions, he told me he wanted a “swim lane chart.”

“A what?” I asked.

He proceeded to draw on the whiteboard a series of parallel, horizontal lines, and filled them with boxes representing activities, with arrows in-between them to indicate schedule logic. The areas in-between the horizontal lines were labelled with the names of some of the organizations participating in the project.

“Oh, okay, I get it.” I began. “It’s essentially a PERT chart, sorted by organization.”

“It’s a swim lane chart” he replied, emphatically, as if to contradict what I had just said. Rather than dither with a customer about the different label he wanted to give a common schedule format, I simply asked him about the Work Breakdown Structure.

“I don’t want a Work Breakdown Structure, I want a swim lane chart!” he insisted.

“I understand what you want, and I know how to produce one, but first I’m going to need a WBS in order to construct the schedule network we need to generate the ‘swim lane chart.’”

“Look,” he sighed, as if he were trying to communicate an extremely simple concept to a dull child, “I don’t want any of that other project controls stuff. All I really need to manage this work is a swim lane chart, regularly updated.”

At that point it became clear that this guy was deficient in his PM capabilities while fancying himself a genius, and that he held anyone who didn’t agree with him to be an ignoramus. In short, this fellow was (and probably still is) simply wrong.

And, being younger, I didn’t suffer this sort of wrong-headedness very well.

“Actually, in order to get you your ‘swim lane chart,’ we have to start with a couple of basics, and that includes a WBS. Let’s get started on that, and we’ll be one step closer to printing out the ‘swim lane chart.’”

After promising to get me the initial scope documents I would need to create the draft WBS, I left this fellow’s office and returned to mine, where my supervisor informed me that the PM had called and asked to have me removed from the project.  Which was okay, since, as I said, I didn’t (and still don’t) suffer this type of wrong-headedness very well. My replacement did a much better job, but I’m not entirely sure how she pulled it off. My guess is that she created a straw-man PERT chart, sorted by organization code, and then had the genius PM modify the activities, one by one, until they could be arranged into a rudimentary WBS – essentially, backing in to the Work Breakdown Structure (it would have been funny to see how they retroactively arranged the scope documentation, if that is the approach they took).

Fast forward to present-day, and I’m a blogger on a preeminent PM website, where the currency of the realm is ideas. What are these ideas? They represent theories, concepts, and techniques that help project managers do their jobs better. As with any body of knowledge (get it?), there are some good ideas, and some not so good. I’m sure it will not surprise any of my regular readers to learn that I believe that some of ProjectManagement.com’s competitors are pushing notions not derived through the scientific method – i.e., invalid – into the marketplace of PM ideas.

And, again, I don’t suffer this sort of wrong-headedness well.

A notable example of the notions I’m referring to is the idea that Estimates at Completion (EACs) ought to be time-phased. This is so wrong I’m having a hard time figuring out where to begin. An Estimate at Completion is just that – an estimate. It’s saying that, if the project continues on its current performance pace, it will cost X number of dollars. It is neither a request for more budget (when over the Budget at Completion), nor an offer to repatriate existing funds (if it’s under). It’s a performance indicator, nothing else.

But some other organizations maintain that this figure must be time-phased. What does that mean, exactly? It means that, if this notion is followed to its logical conclusion, they are mandating the creation of a rubber baseline. The existing cost baseline is the original time-phased estimate of the costs of the project. By stipulating the creation of multiple time-phased estimates, the original loses its relevance, and becomes, in the common parlance, “rubber.” It’s nearing uselessness because it’s being superseded by “more recent” information. But the altering of the cost baseline is a formal process. To do so otherwise is to set up the textbook definition of a rubber baseline. And those are not good. They are, indeed, often ruinous to projects that employ them.

So, I’m going to take my usual approach, and ridicule the notion. Those who embrace the idea that EACs need to be time-phased will consider me dumb, but that’s okay.

Because I think they’re simply wrong.