Game Theory in Management

In the 1933 film The Invisible Man, Claude Rains plays Dr. Jack Griffin, who has discovered a potion that renders him invisible. He plots (what else?) world domination, and either kills or materially causes the deaths of a lot of people before he is, himself, killed by police, who can detect his whereabouts by the footprints Dr. Griffin leaves in the snow. And now, for what has to be a record for the earliest introduction of my trademark segue,

Meanwhile, Back In The Project Management World…

I believe that a whole bunch of projects have failed due to one causal element, and it has to do with one of the most enduring, yet invisible PM pathologies: the ineffectual implementation of a desired strategy. It’s evident in the literature, the paper presentations, the tone of PM educators – they know the right answer, but nobody’s heeding them. To live out their careers as latter-day Cassandras appears to be their fate.

Of course, it doesn’t have to be that way. After stepping on the Implementation rake hundreds of times, you’d think that everyone who crashed a project due to this would start to wise up. But, no: just check out some of the lower-level PM-themed conferences, and you will find them chock-full of eat-your-peas-style hectoring, especially in the Critical Path scheduling and Earned Value analysis sessions. Back when I was a regular attendee at such conferences, I found that I could expect pretty much the same presentation on the basics of Earned Value Management, with the addition of some extraordinarily tiresome scoldings to those organizations that weren’t doing it already. I have absolutely no idea how or why those paper presentation proposals kept getting approved. Invariably, at the next conference I would attend, some variant of this same presentation would be on the syllabus, without a scintilla of original research or experimental results, as if scolding by itself was an appropriate way of implementing a program.

However, as I pointed out in my first book, Things Your PMO Is Doing Wrong (PMI® Publishing, 2008), you can’t advance a capability maturity by leveraging organizational power. In other words, you can’t make your team get better at what they’re doing. They have to be led there, certainly; provided the right tools, no question. But any attempt at forcing a capability advancement will be inevitably blown to smithereens by one or more of the following land mines:

• The Silent Veto. This is where some members of your team present as ready and willing to step up and commit to the level of intellectual and energy investment needed to implement your strategy, and then … they kind of disappear. The actual performance isn’t forthcoming, and they always have a really good excuse as to why they missed certain deadlines.
• The Slow Roll. When I was writing the aforementioned PMI® - published book, I was in contact with my old PMNetwork columnist colleague, the brilliant Bud Baker, who was (at the time) a professor at Wright State University. Bud told me that, in his days in the military, their version of the Silent Veto was the Slow Roll, which is where the team actually does participate in the rolling out of the new capability or strategy, but just not quite enough to make it a success. The Slow Rollers seem to have an innate sense of how much energy is behind the impetus to implement the new scheme, and will make an excellent show of advancing the cause – just not quite enough to really make it happen.
• The “it’s too hard” objection. I once inherited a team that included an Administrative Assistant who was clearly less than thrilled that I was being brought on-board. She would work out her frustration by asking for detailed instructions for any task she would be assigned. It got rather comical (though I wasn’t laughing at the time) when I had to provide her with step-by-step directions for doing basic filing. It finally dawned on me that she knew all too well how to do the job – she was just pretending that any task sent her way was too difficult, or dramatically outside the range of activities that she would nominally be asked to do. It was easier to either assign someone else, or do the task myself.

Managers used to a highly hierarchical organizational structure, such as that which exists in the military, will have a greater tendency to be agitated by these implementation-wrecking tactics by the Project Team, and will often resist understanding and working with or around them. As far as these managers are concerned, once the technical agenda has been set, and the specific tasks communicated and assigned to the staff, that should be enough; and, if it isn’t, well, that’s just a sign of some organizational behavior and performance pathology (laziness, incompetence, insubordination, etc.) that can be addressed through disciplinary actions. They seem to never stop to consider that the reason that their projects fail is due to a poor (or even non-existent) implementation strategy, as if the very need for an implementation strategy has been negated due to their advanced placement within the organization. They are the Project Managers, dontchaknow, and their insights and instructions must be followed! Or else! But the real world of Project Management is no respecter of persons. You are either effective at leading the Team to on-time, on-budget completion of the scope, or you are not.

“So!” I can hear GTIM Nation say, “If you’re so smart, how would you overcome the invisible man those implementation strategy landmines?” First, you…

Look at that! Out of pixel ink for this week. But, like The Invisible Man, GTIM Nation can expect a sequel.

What’s a “blaster?” We don’t know exactly, because a working model hasn’t been invented yet in this galaxy; however, we have many, many examples of how they work in the setting for the Star Wars movies, that galaxy far, far away, and have seen it in action. They come in various sizes, from a pistol-sized personal weapon all the way up to massive ship-mounted cannons. No matter the size, when fired they shoot out a bright segment of a beam of light, of various colors, accompanied by a distinctive high-pitched sound. The Jedi eschew them as being “uncivilized,” and “random.” Nevertheless, they appear to be the go-to weapon of virtually every non-Jedi or Sith combatant in the Star Wars series of films. A well-placed shot will kill on impact (e.g., Greedo in the original release), while a glancing shot will create a painful wound (Leia, in Return of the Jedi). The personal blasters used by storm troopers can take down armored vehicles (the Jawas’ sand crawler in the original), and transmit a considerable amount of heat (in The Empire Strikes Back, the walls in Cloud City that were hit near Luke were not only cratered, but at least one of them was maintaining a small flame).

In four of the first six Star Wars films, Darth Vader (the evil version of Anakin Skywalker) spends considerable time as an apex villain, naturally attracting his share of blaster fire. Not only is Vader capable of deflecting individual blasts using his light saber, he can completely absorb a personal blaster shot, from extremely close range, in the palm of his hand (The Empire Strikes Back). So, what does end up killing Darth Vader? It would appear to be a combination of exhaustion from participating in a light saber duel with his son, Luke Skywalker, followed closely by an intense dose of Sith “lightning,” intended to kill Luke but intercepted by Vader as the Emperor is being tossed down a massive power generating shaft.

Meanwhile, Back In The Project Management Galaxy World…

While my poison-pixel criticisms of common risk management analysis techniques have been bright, powerful, and leave flaming craters behind, they have not brought down the massive risk management empire, estimated at $11 Billion (USD) in 2016.[i] Since I view risk management as being the apex villain of the Project Management Galaxy World, it’s incumbent on me to stay true to my Jedi early PMP® training, and thwart their attempts at taking over the management universe. Think I’m exaggerating their intentions? The last time I challenged a well-known risk management expert to define the purview of RM, he responded “any event or condition that can have an impact on a project, positive or negative.” He was somewhat taken aback when I pointed out that that definition not only covered every other aspect of management, but of living life in general. So, yeah, I''m okay with the belief that they’re out to take over the management world.

But pointing out the logical flaws in their techniques appears to have done little more than earn me a spot on their “Most Despised Business Writers” list. Clearly, I need a more effective strategy if I’m going to convince a plurality of my readers that these guys are, well, wrong. And to find that strategy I only needed to look at their genre, where a better approach readily presented itself. You see, risk management falls within the genre of Predictive Analytics, along with regression analysis, descriptive systems, and … Game Theory!

As confirmed members of GTIM Nation know, one of the favorite tools of Game Theorists is the payoff grid. Personally, I can’t seem to string together more than five or six blogs in a row without using one. Let’s do one on risk management, shall we? Consider:

Let’s dismiss Scenario C right off the bat. If the risk analysts failed to predict an event that didn’t happen anyway, then the control set is literally infinite (though I can’t help to wonder what number would be assigned to the “wasn’t predicted, didn’t happen” scenario that involves a Sith Lord arriving on the project’s job site and destroying everything with a lightsaber).

Scenario B appears to contradict my thesis, no? The risk analyst predicted that something “positive or negative” would happen to the project, and that thing occurred! Let’s set this scenario aside for just a few more sentences.

I’ve been proposing an experiment to reveal the number of times Scenario A has happened. That experiment would be to have the risk managers and Earned Value analysts compile a list of projects/tasks at the reporting level of the Work Breakdown Structure that are going to overrun, and eliminate the agreed-upon tasks. The remainder would represent a workable test of risk management efficacy – and I’m confident I know who would win.

Scenario D happens all the time, but somehow doesn’t erode the confidence placed in risk management techniques. Why is that? It’s due to the same reason that Scenario B, when it actually occurs, fails to serve as supporting evidence.

Read any project’s risk management plan, or analysis. Whichever technique is employed (categorization, decision tree, Monte Carlo, whatever), the results are the same: There is an X% chance that scenario N will occur, having a cost impact of Y dollars and Z units of time. They’re not even really predicting anything! Such an analysis has all the relevance of being reminded that, prior to flipping a fair coin, the odds of it landing heads-up are 50-50. When Scenario A unfolds, the risk managers can point to not having actually predicted that that something would happen, just that there was a possibility that it would happen. And, when Scenario D unfolds, they can always point to that wandering invisible unicorn of doom, the “unknown unknown” events (actually, the whole definition of “known unknowns” and “unknown unknowns” struck me as highly circular at best, and flat-out tautology at worst).

So, what has our payoff grid revealed? That risk management can’t produce anything that’s actually evaluate-able. When they’re “right,” they’re brilliantly insightful, don’t you know, but when they’re wrong, well, they didn’t actually predict a specific scenario would unfold now, did they?

Using one Predictive Analytic technique to showcase the intellectual vapidity of another might seem to be a bit unfair. After all, those endowed with The Force have a limited ability to perform a mystical version of Predictive Analytics. But, that being the case, maybe the Sith risk analysts should have seen it coming…

[i] Retrieved from https://www.globenewswire.com/news-release/2017/03/15/937815/0/en/Assessing-the-17-1-Billion-Technologies-for-Assessing-Risk-Management-Markets-Global-Report-2017.html on 6 July 2019, 14:01 MDT.

EDUCBA.com provides the following distinction between “Descriptive Analytics” and “Predictive Analytics”:

Descriptive Analytics: This type of analytics is used to summarize or turn data into relevant information. In other words, it summarized what has occurred. This type of analytics has some meaningful impact but won’t be much helpful in forecasting.

Predictive Analytics: – Predictive analytics involves advanced statistical, modeling, data mining and one or more machine learning techniques to dig into data and allows analysts to make predictions. Predictive analytics is used to forecast what will happen in future.[i]

When I read this description, it reminded me of newly-minted managers, with the memories of their BBA or MBA graduation ceremonies fresh in their minds, arriving at their first assignments. It’s not that they’re ill-informed or anything – it’s just that what they think is new and innovative has actually been around for some time. In this case, the Project Management community has been on top of this epistemological mountain for so long, it’s easy to forget that we’re here, and the whippersnappers newcomers need to be reminded of that.

Let’s look at a couple of key sentences from the above, shall we? According to this author, Descriptive Analytics describes “what has occurred,” and “…won’t be much helpful (sic) in forecasting.”[ii] Well, I disagree. But before I prove that I’m right, let’s take in what this post says about Predictive Analytics, that it “allows analysts to make predictions” (as if such analysts need permission to predict anything). Also, it’s “used to forecast what will happen in the future.”[iii]

Lots of stuff to unpack here. I’ll start with the distinction between these two types of Analytics provided, that “Descriptive” refers to “what has occurred,” which veteran members of GTIM Nation call “hard data,” and “Prescriptive,” which “involves advanced statistical, modeling, data mining and one or more machine learning techniques to dig into data” – in other words, some subjective data is being injected into the number-crunching fray. But is historical, or “Descriptive” data of little use(ful) in forecasting? Consider this blog from a few weeks back, where I proposed a competition between risk management and Earned Value, to identify which tasks or projects were likely to overrun or come in late. I proposed that the risk managers create a list of such tasks, and the EV specialists do the same. After tossing out those tasks that both analysts believe will overrun or come in late, we would have a hard basis of comparison, and that my money would be on the EV peeps, who can reliably predict which tasks will get in trouble, and on a consistent basis. Not only that, but they DO NOT use ”advanced statistical, modeling, data mining and one or more machine learning techniques.” Quite the contrary, they need only the size of the original budget, cumulative actuals, the tasks’ start date, today’s date, and an estimate of the tasks’ percent complete. And that’s it. It’s accurate (to within 10 points on a consistent basis), simple, and it’s been around since the 1960s. No, I’m not kidding.

Well, what of the whippersnappers’ more recent techniques? They essentially fall into three categories:

• Risk management involves estimating the odds and impact of alternate scenarios,
• Regression bases their predictions on patterns that have occurred historically, and assume that similar outcomes will unfold when analogous situations or conditions are re-encountered, and
• Models, in which certain types of work or business activities are expected to unfold along the lines of a familiar template – Game Theory falls into this category.

Referencing the first bullet, the tried-and-true PM techniques of Earned Value and Critical Path Methodologies will always out-perform the risk analysts’ tactics. For this reason, I’m very confident that no serious fact-based rebuttal to my Variance at Completion challenge will be forthcoming.

As for the second bullet, it is the basis for much of the poison pixel-ink I’ve spilled on our friends, the Accountants. You see, when an accountant projects how much a specific task will end up costing when it’s complete, they typically use regression to make their estimates. They calculate how much the task has been spending, and assume it will continue to spend at that rate (or an average, or adjusted average, or whatever) for its duration. This calculation, while not as irrelevant as the risk managers’ output, still isn’t nearly as accurate at the EV technique.

About the third bullet – isn’t there a ProjectManagement.com blog about that?

So, it’s pretty plain to me that:

• Contrary to the citation, using data that covers things that have already occurred is, in fact, extremely valuable in predicting outcomes, given the right methodology;
• Statistics and modelling provide inaccurate and irrelevant information (“You have a 39% chance of overrunning”);
• Regression-based analysis, while relevant, isn’t nearly as accurate as the 1960s-era technique of calculating the Estimate/Duration at Completion, and
• Game Theory, with its payoff grids and Nash Equilibrium, can provide some insights in very specific, controlled circumstances; however, it has only a fraction of the predictive analytic power of even the most basic Earned Value or Critical Path Methodology-based system. (I’m comfortable making this statement a priori due to the massive amount of research I did while writing my second book, Game Theory in Management).

I don’t mean to come across like some curmudgeon (I should probably knock off the references to whippersnappers). It’s just that, when it comes to reliably predicting key Project Management data points, well, those techniques have been around for some time.

Before many of the whippersnappers were born, even.

[i] Retrieved from https://www.educba.com/data-analytics-vs-predictive-analytics/ on June 29, 2019, 21:38 MDT.

[ii] Ibid.

[iii] Ibid.

When the first scenes of the planet Coruscant appeared in the Star Wars movie The Phantom Menace (to you purists out there, the clip of Coruscant that appears near the end of The Return of the Jedi was added later), seasoned science-fiction consumers probably had a flashback to Isaac Asimov’s Foundation Trilogy, and the governing planet Trantor. Like Coruscant, Trantor has no open spaces – every acre has either been paved over or has a building on it. However, after the first Foundation galactic-wide government collapses, and almost everyone has abandoned the place, a remnant tear down some of the infrastructure, and begin farming the surface – something that Hari Seldon’s “psychohistory” algorithms failed to calculate predict.

I’ve mentioned The Foundation Trilogy and psychohistory previously, primarily because of its similarity to the philosophical underpinnings of modern risk management. Set thousands of years in the future, The Foundation Trilogy takes place in a galaxy populated by trillions of humans, scattered across myriad star systems. Psychohistory is predicated on the idea that, while it is impossible to predict the movement of a single atom of, say, oxygen, if you get billions and billions of O2 molecules into a container they start to behave in highly predictable ways. The Hari Seldon character has devised a method of calculating the most likely outcome of the collective Galactic Empire’s future, since there are so many people whose behavior, while individually unforeseeable, has become somewhat predictable in the aggregate. While we never actually see the algorithms that do all this amazingly accurate predicting, one gets the sense that it’s a combination of statistics, Game Theory, and Behaviorism, with turbocharged derivatives of Bayes’ Theorem thrown in for good measure.

Meanwhile, Back In The Project Management Galaxy World…

I recently attended a conference on predictive analytics. As with most conferences, it included keynote speeches, presentations, and workshops, with the standard exhibitors’ area set aside for vendors and their booths. One element of the conference that I did note, over and over, was a heavy emphasis on analyses based on Gaussian curves, all of which (well, all the ones I saw) were presenting ideas for better predicting the behavior of large populations based on analyzing the data from samples. For recent additions to Game Theory In Management Nation, I regularly assert that all valid Management Information Systems’ architecture can be reduced to three sequential steps:

1. Data is gathered based on some discipline or planned sampling program.
2. The data is processed into information, based on some methodology or model (for PM types, this is usually Earned Value or Critical Path methodologies).
3. The information is transmitted to decision-makers in a way that they can readily understand it, and use it to make decisions.

I noticed an interesting consistency among those presenting papers and the software vendors. Those presenting the papers largely addressed the issues of Step 1, collecting the data, with only an occasional mention of the problems inherent in the actual analyses. Similarly, the vendors seemed to be offering up solutions to data collection and standardization issues (“harmonizing” the data), but would usually punt when asked how they would propose actually processing the data into usable information, the all-important Step 2. One fellow told me that his software would simply use “whatever the customer’s preferred model” happened to be at the time. To be fair, Hari Seldon won’t introduce Psychohistory for another 10,000 years.

Until then, the whole business of reliably predicting the future is pretty much stuck in reverse. Analysts can observe what has happened in the past, overlay some sort of structure on to it, and then recommend a specific strategy if the present appears to be unfolding in an analogous fashion, but that’s about it. And even that series of steps can be accurately, if colloquially, chalked up to “experience.”

But perhaps the main intellectual fault of the whole predictive analytics/ risk management codex has to do with the extrapolation of large populations’ behavior(s) from a relatively small sample size. As marginal as that practice is, current risk management seeks to turn that on its head. They attempt to predict the cost or schedule behavior of a specific project based on patterns gleaned from many other (hopefully, similar) projects, something that not even Hari Seldon proposed (will propose?) as plausible. By definition, projects tend to be one-time endeavors. Even identical buildings are constructed on different sites, after all.  Paradoxically, the more standardized or routine the work to be done happens to be, the less demand for professional Project Managers. Stamping out identical widgets from a production line doesn’t need much PM support, while facilities or software applications that do something genuinely unique usually won’t succeed without it.

Meanwhile, Back On Trantor (Warning! Spoilers Ahead)…

The fate of the First Galactic Empire turned out to be very different from its calculated version due to the emergence of a character named The Mule, who had a mutant ability to influence people with whom he interacted without actually speaking to them. In other words, the prediction of the population’s future unraveled due to the introduction of a single, unpredictable person. But predictive analytics/ risk managers don’t seek to forecast the future of projects in general – they attempt to quantify what is going to happen to singular, specific projects.

My prediction? It won’t work 10,000 years from now, and it certainly won’t work in your next project.

For those of you in GTIM Nation who are used to my writing direct, immediately-usable strategies for better project execution, or team cohesion, or shotgun blasts against what I perceive as management pathologies, I must request some patience. I’ll get to that kind of stuff after the next 400 words or so, but I must first take a detour into, what I’m sure will strike many as, a more theoretical, philosophical bent. But, if you stay with me, I’m pretty confident I can make it worth your blog-consuming while.

Referring back to this blog’s title – what does a priori mean? According to Merriam-Webster online[i], it’s “relating to or derived by reasoning from self-evident propositions,” and “presupposed by experience.” I was reminded of this term recently when I was looking into the concept of interface management, and my internet search turned up an article in the Project Management Quarterly, from 1979 (!). The article, “Interface Management – an organization theory approach to project management”[ii] is chock-full of a priori assertions, which isn’t necessarily a bad thing in and of itself. I think what I find frustrating about this particular article is the overuse of inchoate but impressive-sounding assertions, none of which are verifiable through observation, or even falsifiable (which Karl Popper would probably argue renders it outside of the scientific method, even if we ARE talking Management Science). Some of the gems include:

• “Tight control of dynamic interfaces is essential to achieving project cost, schedule and scope targets.”[iii]
• (two bullets later) “Organizational factors should not be allowed to inhibit required project integration.”[iv]
• “Systems management is a key systems concept.”[v]

And those are just on the first page. Let’s take a look at these one at a time, shall we?

• We learn later in the article that a “dynamic interface” is a communication among stakeholders in the project, or even within the Project Team, that are other than “static.” This differentiation appears to hinge on whether or not the communication is regular and consistent, or ad-hoc and unpredictable. Just how are these interfaces to be “tight(ly) controlled?” Is the PM to sneak around the Project Team’s offices, waiting for one of them to contact a sub-contractor with some unauthorized question, and pounce if and when such an interface occurs? Also, how is this falsifiable? Could a Karl Popper aficionado approach this author after the fact, and state (with a straight face) “I successfully achieved my project’s cost, schedule, and scope targets, and I made no effort at all at controlling the dynamic interfaces, much less tightly. I insist you retract your thesis that such ‘control’ is ‘essential!’”?
• This notion that PM implementation strategies exist in the pure ether of a universe that allows only the mathematical and provable aspects of management science is just plain dopey. Management takes place in a world of people – real people – who will inevitably manifest some sort of organization behavior and performance pathology in any group they create. It’s just the way things are in the real world. If your PM strategy crashes and burns, and your best deflection tactic is to blame the “organizational factors,” then your strategy was poorly formulated from its inception. As I have pointed out in multiple previous blogs (usually, but not always, citing the excellent Michael Maccoby’s book The Gamesman), the “organizational factors” are part of the managerial landscape. Ignoring them, and then blaming them ex post facto for your failure to derive an appropriate management strategy is simply disingenuous.
• Okay, this last bullet is a simple tautology. I included it because it bugged me.

But the thing that these key assertions all have in common is that they are a priori assertions. None of them is verified (or even verifiable) through direct observation. I’m not just picking on this particular author (even though he is a Ph.D.) – this sort of supporting argumentation for furthering certain ideas about Project Management is, unfortunately, rather common. Examples include:

• The idea that “bottoms-up Estimates at Completion” need to be performed regularly,
• Critical Path schedule networks are rendered weaker by an excess of start-to-start relationships among activities,
• All stakeholders must be engaged,
• As well as almost the entire codex of risk management theory,

…and this is just a short list.

My solution? Outright rejection of all PM hypotheses that are not falsifiable is probably a bit extreme. I would settle for an honest re-examination of the non-falsifiable ideas that made it all the way into the PMBOK Guide®.

And for real-world PMs: take with a huge grain of salt any a priori assertion about the way you “should” or “must” do Project Management. If the one pushing the analysis technique can’t point to real-world examples of how his approach worked, then it probably doesn’t belong in the real world.

[i] Retrieved from https://www.merriam-webster.com/dictionary/a%20priori on 15 June 2019, 20:29 MDT.

[ii] Morris, P. W. G. (1979). Interface management—an organization theory approach to project management. Project Management Quarterly, 10(2), 27–37.

[iii] Ibid.

[iv] Ibid.

[v] Ibid.