Game Theory in Management

When Glenda, the Good Witch of the North, makes this inquiry of the newly-arrived Dorothy in the movie The Wizard of Oz, Dorothy responds with alarm. Apparently, all witches in Kansas at the time could be readily identified by certain visual ques, most of which would be on display when we meet the Wicked Witch of the West a little later in the scene. Dorothy is completely unaware that, in Oz, there are good witches who present much more like, well, Glenda. But since Dorothy’s appearance is somewhere in-between Glenda’s and the Wicked Witch’s, Glenda is unsure, and has to pose the question.

Meanwhile, Back In the PM World (including Kansas)…

There’s a lot of churn in the PM industry these days about the features that must accompany a “good” Project Management Information System, or PMIS. The primary value of PM information systems lies in their ability to provide critical performance information to the projects’ decision-makers so that they can increase their odds of bringing in their scope on-time, on-budget. While the previous sentence is undeniably true, it does carry with it some rather prickly implications, the primary one being that any PM information stream that supported a provably successful project was just fine, and any – any – ex post facto analysis to the contrary is, well, wrong.

What About The Projects That Don’t End Successfully?

But it does not follow that any PM system that supports a failing project is automatically invalid. Consider the following payoff grid (for those of you who aren’t fans of payoff grids, I remind you of the title of this blog, and how game theory aficionados love these things):

I propose a simple two-step filter to test if a given PMIS is “good,” or “bad.”

• Was the project successful?
  • Yes: the PM system is fine.
  • No: Did the Cost/Schedule System accurately document the project’s performance issues at least three reporting cycles prior to the actual overruns or delays?
    • Yes: the PM system is fine.
    • No: in this circumstance – and ONLY in this circumstance – should we assume an actionable deficiency.

But the fact that PM experts rarely, if ever, follow this common-sense approach points to one of Hatfield’s Incontrovertible Rules of Management, that you can put fifty Project Management experts into a room and they will not agree on the color of an orange. Why so much disagreement? Because the standards being employed have veered away from objective, verifiable parameters.

Finally! A Valid Use For Risk Management!

I believe that a sure-fire tell that the people bestowing “good” or “bad” labels on Project Management Information Systems are unaware of the existence of good witches is if they threaten to identify a system as “bad” for its mis-application (or just missing) risk management program. Such a “finding” would represent ipso facto evidence that the evaluators are relying on epistemological ques that aren’t really relevant.

And, once these ques are misidentified, can simply handing the ruby slippers over to the Wicked Witch of the West be far behind?

I had to smile when I saw that the ProjectManagement.com theme for August was virtual project management. Back in my PMNetwork columnist days I actually wrote a piece by that very title, and it was fun to do. That column was based on the computer game The Sims, a version of which my older son had set up with a house that contained four members of a project team: the PM, an administrative assistant, an engineer, and a technician. We gave them all template personalities, and I wrote about the behaviors we witnessed, the strangest of which had to be the PM’s predilection for tickling the other members of the project team once he began to lose popularity. Happens all the time in your projects, right?

Since I wrote that piece over a decade ago, the producers of The Sims have come out with far more sophisticated versions of the game. If I were to recreate a nominal project office for an updated version of that column, I would have a few upgrades to interject myself, based on the archetypes described by Dr. Michael Maccoby in his book The Gamesman.

In The Gamesman, Dr. Maccoby describes four basic archetypes:

• The Craftsman doesn’t really care as much about who employs him, but does care about the quality of his output.
• The Company Man tends to adopt the persona of the team around him.
• The Jungle Fighter gets ahead by engaging in gossip and calumny, taking credit for others’ accomplishments and deflecting accountability for his own errors.
• The Gamesman (after whom, obviously, the book is named) doesn’t perceive his paycheck or other perks as representing a roof over his head and food on the table; rather, he sees these things as tokens in some grand game. Because of this, this type tends to both possess a mastery of the business they engage in, and are willing to take more risks than the other archetypes.

I have also previously written of the incomparable Dave Post, who worked with me on a paper presentation on the topic of Project Management implementation strategies. Dave pointed out another version of employee archetypes, in this case the types of reactions the project team could be expected to manifest in the implementation process. He theorized that, if the employees were to be represented on a bell curve, that:

1. The leading edge of the curve would represent the early-adapters. These people probably had beta-format VCRs (if you aren’t old enough to know what “beta format” means, I don’t want to hear from you; and, if you don’t know what a VCR is [was], are you really old enough to be on a project team?), and could be counted on to readily embrace the change being introduced.
2. About one standard deviation around the left side of the mean represents those who will accept the change, but only after they have been convinced that it will be beneficial to them in the short-to-medium term.
3. About one standard deviation towards the right side of the mean represents those who will resist participating in the implementation process, and will only come on-board when they realize that most of the rest of the organization has done so.
4. At the tailing edge towards the right of the curve are those who will oppose your implementation, no matter what pressure is brought to bear.

Did everybody notice how I switched from bullets to letters in the two lists? Dave and I, lacking originality (apparently), decided to refer to our archetypes by these letters. Somewhat coincidentally, these archetypes align with Dr. Maccoby’s rather loosely:

• As are Gamesmen,
• Bs are Craftsmen,
• Cs are Company Men, and
• Ds are Jungle Fighters.

When we discuss virtual project management, another way of stating this subject is the modelling of project management environments, where various strategies can be employed and tested for efficacy without actually endangering budgets or critical schedules. I believe that a key component is the modelling of the project team itself, with considerations of how the PM can handle the team’s interactions representing a key parameter.

And if you PMs believe that there are no Jungle Fighters, or Ds, in your project team, think again.

There’s a story I’ve used as an example in this blog before, about a display at the New York Metropolitan Museum of Art that was trash. I’m not engaging in hyperbolic art criticism here – it was literally litter, framed. One prescient critic pointed out that, if everything is “art,” then nothing really is, and I wholeheartedly agree with that assessment.

Meanwhile, back in the PM Universe, I’ve noticed another troublesome trend, particularly among Earned Value practitioners. It seems that almost every EV practitioner I’ve come across thinks of themselves as an “expert,” and can be counted on to allude to it, either in their CV or in discussions about how project management information systems ought to function or be implemented. Sometimes their claims to a high level of expertise have some viability, but other times they’re pretty spotty.

As An Example…

I’ve also already conveyed the story of the young woman who pretentiously demanded that all the managers in the room defer to her “expertise” in EV because she had the PMP® certification. I’m not even sure if she was aware that a significant percentage of the people she was trying to one-up also had PMP®s, or if she cared. She was an expert, by gum, and everyone else was to acknowledge her superiority by either agreeing with her, or else shutting up. It’s unfortunate she chose to use her new PMP® as a bludgeon rather than an accomplishment milestone, but that’s what she did. The funny thing about that story was that she had just asserted a concern that, on that particular project’s Cost Performance Report (Format I), the Earned Value figure didn’t equal the cumulative actual costs (ACWP).

“That’s right” the contractor’s project controls analyst calmly replied, “because that’s not how you calculate Earned Value.”

“Do you know PMI®?!” she stormed. “I’m a PMP®!”

The ensuing percentage of meeting participants who either rolled their eyes or face-palmed probably broke some sort of record.

Unfortunately, It’s Not That Rare

But I know for a fact that this phenomenon is not confined to the naïve-but-arrogant set. In several supposedly high-level meetings of people who have presented themselves as highly advanced in the field of cost performance management, many known-invalid arguments have cropped up, as if they should carry the day and settle the argument then taking place. I tease accountants a fair amount in this blog, but I will say this for them: they generally don’t allow arguments like the sunk-cost fallacy to enter into management decisions, much less let them completely settle a matter.

Conversely, it seems that EV “experts” can be bamboozled by even the simplest syllogisms, as if none of them had ever read Aristotle. Get a room full of these guys into an animated conversation, and the question-begging becomes commonplace. For the record, the phrase “this begs the question…” is not analogous to “this raises the question…”  The syllogism Begging the Question means to assume as true a premise that is either not established as fact, or else has not been agreed to by all participants. In the example I’m thinking of (and, again, have mentioned in a previous blog), the self-proclaimed expert was demanding deference because he had travelled overseas to consult on the topic of Earned Value. I swear I am not making this up. In fact, the fellow became rather irate when I called him on his clearly invalid assertion, that having one’s passport stamped somehow imparts advanced cost performance knowledge. Alarmingly, I had the distinct impression that, had I not done so, no one else in the room would have.

Why This Is A Problem

“So, Michael, what’s the problem here, really?” I can hear some readers say. “What if these EV practitioners think a lot of themselves? Whom does that hurt? Isn’t confidence a good thing, particularly in a consultant?” Well, yes and no. When these consultants start, say, writing guidance documents that are chock-full of these utterly unsupported hypotheses, and those guidance documents get adapted by auditing agencies, then the entire field of Earned Value Management suffers.

Then there’s the problem I began describing in the first paragraph. If everyone is an expert, then it has the same effect as grade inflation at the Ivy League schools. So what if you graduated with honors from Harvard? So did 91% of your fellow class mates![i]

There’s really no point in trying to correct this problem through encouraging all these EVM experts to behave better. That’s simply not going to happen. I mean, look at the offerings from the typical EV symposium. I can almost guarantee that a majority (91%, even) will fall into one of the following categories:

• I saved my project by embracing EV (or its subvariant, My Project Did Great, And We Used Earned Value),
• Everyone should be doing EV, or
• The basics of EV, for the bazillionth time.

…and that’s it. Only occasionally do you see any new research proffered, or even an exhaustive analysis of past projects that have performed well using basic techniques compared to failed ones that did not. And just to be clear, if the EV seminars and symposiums are dropping the ball on advancing legitimate management science theories, then the venues that do perform this function are left to people like ProjectManagement.com bloggers.

As I’ve maintained in previous posts, the answer here is to return to the basics of true management science analysis. For those who have read Aristotle, we should embrace those writers who rely on logos, and eschew those who rely on ethos, i.e., the “experts.”

But, since everyone’s an expert, then nobody really is, so this problem is kind of solving itself.

[i] Retrieved from http://www.sfgate.com/news/article/Harvard-s-dirty-little-secret-is-out-grade-2868775.php on August 5, 2017, 2100 MDT.

My oldest son graduated Magna Cum Laude from a fairly prestigious law school, and works as a prosecutor. On those occasions when he visits home and gets into conversations with me, I sometimes like to tweak him by deliberately mis-using legal terms when I want to take exception to an assertion he’s made. A recent example went like this:

“Objection, your honor! Facts not entered as evidence!”

“You realize” he replied, “that what you just said is almost literally gibberish.”

“Not according to the television law shows I’ve seen.”

“Then you need to watch a higher caliber of law show.”

Later, when talking about that exchange with my wife, I admitted that I should stop doing that, lest I increase the odds of my son skipping trips back home in order to avoid such face-palm moments. But I hastened to add that, if there were television shows about Project Management (similar to “Law & Order,” would ours be “Cost & Schedule?”), and some of the terms we use on a regular basis were to seep into the common lexicon, I would be more tolerant of their modified, hipster connotations than our legal professional counterparts.

And then, almost as those words were leaving my mouth, I realized that they were utterly false.

In fact, it drives my face directly into my palm when I hear project managers misuse terms with which they should be completely familiar. It’s particularly cringe-worthy when the speaker has some sort of PM certification. A quick list includes the following. NOTE: all of these are actual quotes that I have heard in my time in PM.

“This task is too important to not be on the critical path.”  While not almost literally gibberish, it is extremely goofy, as any entry-level scheduler can tell you. Whether or not a task in a schedule network appears on the critical path has nothing whatsoever to do with its profile, or perceived “importance.” Its presence on the critical path is solely determined by its duration and schedule logic (e.g., which tasks have to be completed before others can begin). Now, I will concede that, once a CPM-capable software package has performed the forward and backward passes on the schedule network, and has identified the critical path, your typical PM will place more importance on the performance of the activities that are on it. But to assume that high-profile or perceived-to-be important tasks must therefore be on the critical path is a sure sign that the person who is asserting so has no idea what they’re talking about.

“There’s an 80% confidence interval that this project will not exceed (N) dollars.” Yeah, and there’s a 100% confidence interval that the person or persons who have performed the “analysis” that supports such an absurd position have absolutely no way of knowing that for certain. How do risk managers and analysts come up with the 80% confidence interval figure? Typically, it’s based on the following data points:

• Original estimate, in both cost and duration (at the level of the Work Breakdown Structure where the analysis occurs),
• Estimates of the odds of the task experiencing unplanned events,
• Estimates of the impact that such events may have,
• A calculation of the odds of occurrence, multiplied by the estimated impact, and then subtracted from the original budget in order to isolate the cost or schedule contingency amount.
• If a Monte Carlo analysis in used, the risk analysts will also pre-select a type of leaning-bell curve with which the artificially-generated “events” should conform. (Did I mention that the result, represented graphically, of the artificially- [or “randomly- “] generated events, is pre-selected?)

Okay, so what’s wrong with all this? Consider the steps, in order:

• Subjective data.
• Highly subjective data.
• Obscenely subjective data (can we even really call it “data”?)
• Statistical analysis of obscenely subjective data.
• Further analysis of obscenely subjective data, where the results are already established.

Need I say more?

“We’ve spent more than we budgeted for the month, so we have a negative cost variance.”

I can’t even.

So, if you hear these phrases spoken aloud, and it’s not a case of a father exercising his right to irk his children, you will know that the speaker is not an authentic project manager.

Or else he just needs to watch a higher caliber of PM shows.

There’s a classic scene in the 1956 movie, Around the World in 80 Days, where English aristocrat Phileas Fogg (played perfectly by David Niven) is on the last leg of his epic journey, and finds himself in the mid-Atlantic on board the tramp steamer Henrietta. Due to storms and adverse winds, the Henrietta runs out of fuel well short of England, and, if Fogg can’t make it back to the starting spot of his journey on-time, he will lose his wager, and can expect a future of poverty. Realizing his situation, he makes a bold decision: he purchases the steamer on the spot, and then orders all flammable materials on-board that do not directly contribute to the ship’s navigation capabilities to be broken up and fed to the furnaces that drive the steam system.

As various wood planks and assorted burnable pieces of the Henrietta arrive in the ship’s engine room, the ship’s first officer, played by Andy Devine, laments their loss. But, when the wooden carved figure from the bowsprit arrives, the first officer cries aloud “No, not Henrietta!” (presumably, the nickname of the bowsprit itself.)

Alas, Henrietta the Figurehead herself is fed to the furnaces, and the ship makes it to port soon enough for Fogg to complete his journey on-time, and collect on his bet.

What does this have to do with Project Management? Well, I’m glad you asked.

There have been multiple efforts of late, both in private and public sector PM circles, to develop something called “Earned Value light,” or an Earned Value Management System that is not overly encumbered by superfluous techniques or processes, and delivers cost and schedule performance information with minimal cost and fuss. I think the existence of such initiatives is ipso facto evidence that those I have previously referred to as “processors” have gained ascendency in the project management world, and have made something as basic and straight-forward as a working EVMS into an extremely difficult endeavor. It may be too late to turn back their insidious encroachments into legitimate management science, but I mean to make the attempt by asking: what, exactly, is an EVMS for? What’s its purpose? And, if that question can be clearly and cleanly answered, the next one is: which current practices attached to the set-up and maintenance of Earned Value Systems are superfluous, and should be dissuaded, if not out-and-out abandoned?

Here's my take: Earned Value Management Systems exist for one purpose, and one purpose only: to put into the hands of the project’s decision-makers the cost and schedule performance information they need to make, well, informed decisions.

That’s it.

Michael, Do You Realize What You’re Implying?

Yes, I’m crystal clear on what that definition implies for the answer to the follow-on question. For, if my definition is right, it follows that these practices have nothing at all to do with Earned Value:

1. The creation of a time-phased Estimate to Complete,
2. Comparing actual costs at the line-item level to their counterparts in the cost baseline’s Basis of Estimate (BoE),
3. Performing a “bottoms-up” Estimate at Completion,
4. Mandating that an extremely accurate and recent Master Resource Dictionary be used in time-phasing the budget,
5. …among many other practices and techniques that have been larded onto essential EVM, with the blessings (if not insistence) of so-called “experts.”

However, some prominent procedure or guidance-generating organizations have pushed these add-ons relentlessly, asserting outright that to avoid them is to fail to “do” EV correctly, which I hold to be so much rubbish.

It essentially boils down to this: put yourself in Phileas Fogg’s shoes, except in this case, rather than come up with the criterion needed to get the S.S. Henrietta to her destination (reminder: burnable with no connection to the ship’s ability to navigate), you need to come up with the criterion for producing usable cost/schedule performance information with an absolute minimum of effort, time, and cost. Which “must-have” aspects of EV would you abandon? Which would you keep? From my point of view, get rid of anything – anything – that did not directly support the collection of a basic time-phased budget, actual costs at the reporting level of the Work Breakdown Structure, and a reliable estimate of the tasks’ percent complete at the end of the reporting period, again at the reporting level of the WBS. For example, from the list above,

1. …serves to help improve resource allocation (theoretically – I’m not convinced, but that’s what its adherents claim),
2. …is supposed to improve the quality of the original estimates,
3. …comes from sheer ignorance of the accuracy of calculated EACs and the inaccuracy of re-estimated ones, and
4. …is also supposed to improve the quality of original estimates.

None of which, obviously, have anything to do with delivering cost and schedule performance information to PMs and other decision-makers. Everything else – everything – is superfluous, and should be abandoned.

Even Henrietta.