Game Theory in Management

Before GTIM Nation accuses me of indulging in PM fan-boy-ism, allow me to point out that the supporters of virtually every management strategy or new business model never seem to be able to articulate those strategies’ or models’ upper limit of efficacy. One hundred and ten percent scalability seems to be baked into every single one of these cakes. Perhaps the most dramatic example of this comes from the world of psychology. B. F. Skinner, through his books Walden Two and Beyond Freedom and Dignity, essentially went from Pavlov observing that his dogs salivated when they heard the dinner bell all the way to asserting a basis for ordering all of human society. And, for the record, I have on several occasions pointed out that PM techniques are utterly ill-suited for Asset Management, or handling functions.

But to prove the assertion in the title, let’s engage in a couple of mental exercises. What kinds of cooperative efforts require “management”? I would argue that those would be the efforts where there are a lot of unknown parameters that have/will have bearing on the optimal decisions and strategies. For example, driving to work in the morning doesn’t require much in the area of management, since (for most of us) it’s down to a routine. Conversely, the act of driving the family across several States for a vacation does require some level of planning and on-the-spot changes to those plans, both with respect to one’s own behavior and the behavior of others – the very definition of management. What we have here is a sort of scale, where the routine and rarely-changes-from-the-baseline efforts are on one end, and the entirely novel, never-been-attempted (while requiring some level of resources) scope is on the other.

Recall one of the most common definitions of a “Project” as the creation of something novel (e.g., there’s only one Hoover Dam). Referring back to our scale, Project Management clearly belongs on the “entirely novel” side, but I want to argue something further. As the novelty of an effort moves towards the routine, so does the need for any kind of management. The manager overseeing an assembly line, where each of the workers know exactly what to do, will typically encounter malfunctioning machines, or workers not being able to show up to the facility, or upper management inflicting changes in requirements – things of that nature. The Project Manager, in addition to the types of problems encountered by her assembly line counterpart, can also expect to encounter far less foreseeable issues, often impossible to anticipate. There’s a reason why risk managers (no initial caps) seem to gravitate towards PM much more than they do to basic manufacturing. And, when they do weigh in on matters PM, they carry with them the whole other category of “unknown unknowns,” events that are utterly capricious in nature. I think the mere existence of “unknown unknowns” as a category of unforeseeable events that are still within the purview of the project’s scope is a tacit recognition of the whole lots-more-weird-stuff-happens-to-us effect.

Let’s take a look at the more routine side of this scale by posing a question about basic management science: is there a particular field or arena of business that’s home to a vast array of formulaic approaches to management? If you answered “yeah, that would be Asset Management,” go to the head of the class. The codex covering Asset Management – including Generally Accepted Accounting Principles – is so vast that universities grant graduate degrees in it. To even credibly engage in performing its basic functions requires an extremely-difficult-to-attain certification (the CPA). Almost by definition, Accountants rarely (if ever) encounter a genuinely novel situation or circumstance that has no precedent in either GAAP or tax law. Again, this codex is certainly vast, but my point is that it’s not set up to handle the unexpected. It very specifically spells out, step by step, what to do for a given situation or circumstance. Indeed, the Asset Managers’ cliched assertion that the point of all management is to “maximize shareholder wealth” points to the fact that they truly believe that every single decision made in the business world can be quantifiably reduced to an entry in a profit and loss statement which, in my mind, is clearly absurd. For those who would disagree with the previous sentence, consider the scenario where the Project Team has delivered on-time, on-budget, while overcoming a series of technical, labor, supplier, and even environmental problems unforeseen at the time of the freezing of the baseline. The customer sees this, recognizes the managerial acumen, and resolves to send all future, similar scope to this contractor. Here’s the million-dollar question: how does any of this get captured or quantified as an entry into the general ledger?

In the world of management, the rote is pretend management, and the new, never-before-tried is the real deal. One last request: remind me which end of this spectrum is dominated by PM?

One of the most fascinating games that we Game Theorists like to analyze is the Hawk/Dove game. Imagine a population of 100 generic birds. Each bird can either forage for their own food (Dove), or else aggressively attack other birds, and take their food away from them (Hawk). Which strategy will prevail? Without getting into the mathematics of the payoff grid[i], I can relay a couple of the findings from analyzing this setup:

• The payoff for the entire population is maximized when every member behaves like a Dove.
• With the introduction of just one Hawk, however, the mixed strategy will quickly conform to the Nash Equilibrium[ii], of 25% Hawk, 75% Dove.
• If the available amount of foodstuffs is insufficient to feed the entire population, selecting the Dove strategy exclusively will lead to certain death.

Okay, so we’re obviously not talking about literal birds here, but humans in an environment where strategic options are extremely limited, reduced to the binary decision to act passively or aggressively with respect to the other members of the population. Of course, in real-life human interactions within, say, a certain organization or Project Team, the decision(s) to employ a passive strategy (perform your job duties as assigned, to the best of your ability, while assisting others doing the same thing) or a more aggressive one (pursue your own interests, even at the expense of the other members of the Team, or by bending the rules) are not so Boolean. Almost everyone engages in a “mixed strategy,” composed of actions that can be objectively aggressive, or objectively passive … or somewhere in-between. It’s this in-between area that makes the relevancy of games like Hawk/Dove to real-life situations somewhat ambiguous, meaning that any take-aways from such analyses won’t approach the precision of a calculated Nash Equilibrium. Essentially, Game Theory can lend credence to some usable axioms or somewhat dependable leading indicators of organizational failure, but can’t provide the basis for making specific organizational behavior and performance decisions.

Speaking of organizational behavior and performance decisions, GTIM Nation knows of my respect for the brilliant Michael Maccoby, particularly in his book The Gamesman: The New Corporate Leaders (Simon and Schuster, 1977). In this book, Maccoby posits four basic archetypes in the workplace:

• The Craftsman cares deeply about his actual output, but not so much as to the organization around him.
• Conversely, the Company Man cares very much about the organization around him, to the point of adopting its persona.
• The Jungle Fighter gets ahead through calumny and cloak-and-dagger strategies.
• The Gamesman does not perceive his paycheck as a roof over his head, or food on the table. Rather, this archetype sees his perks and renumerations as some sort of token in an elaborate game he’s playing. Because of this, the Gamesman is both more likely to have an advanced knowledge or capability in whatever industry in which he is engaged, and more willing to take risks than the others.

Now consider what happens when we combine the Maccoby Archetypes with the usable axioms from an analysis of the Hawk/Dove Game. If we were to bin the former into the structure of the latter, I believe Craftsmen and Company Men would tend to be Doves, while Jungle Fighters and Gamesmen would be Hawks. Recall the third bullet from the Hawk/Dove analysis, that, in the absence of sufficient supplies of food, selecting the Dove strategy exclusively means that bird will perish. In PM parlance, if there aren’t enough projects for all of the Project Teams in a given industry, relying exclusively on Craftsmen and Company Men to advance your organization – or even keep it afloat – might not be the best strategy.

“But Michael!” I can hear GTIM Nation say, “In virtually every other blog where you invoke the Maccoby archetypes, you roundly condemn the Jungle Fighters! Are you reversing that now?”

Not in the least. Jungle Fighters are absolute poison, no doubt about it. It just so happens that they share the Hawk bin with the Gamesmen, and together they make up the disruptive component of the organization, or Project Team.

All of which brings us back to the question in the title… are we talking disruptive data, or disruptive people? Because an absence of disruptive data may or may not represent management information system validity, but a complete absence of disruptive people may very well presage a competitive deficiency in your Project Team or macro-organization. The trick here is to differentiate between Jungle Fighters and Gamesmen when utilizing disruptive people. The acid test? While both Jungle Fighters and Gamesmen pursue their own interests, the Jungle Fighter will do so to the detriment of the Project Team, while the Gamesmen does so in cooperation with them[iii].

Also, Jungle Fighters have more of a buzzard-like appearance.[iv]

[i] For these formulae, see Game Theory In Management, pp. 22-26.

[ii] From Investopedia,” The Nash equilibrium is a component of game theory that asserts that a player will continue with their chosen strategy while knowing their opponent's strategy as they have no incentive to change course.”

[iii] My take, not Maccoby’s.

[iv] Same as iii.

No discussion of data disruption (ProjectManagement.com’s theme for July) would be complete without addressing that most difficult to define, yet central to all management information components, relevance. Dr. Watson was often surprised by Sherlock Holmes’ lack of awareness of popular news, which Holmes would explain as his desire to not overload his mind with data that was not relevant to his ability to solve crimes, demonstrating that the issue of data disruption has been with us since (fictional) Victorian London.

There are lots of definitions of the words relevant and relevancy, but, for the sake of this discussion, I’ll use the direct ”sufficiency to infer the conclusion.” What conclusion(s)? The one(s) that can provide the basis for, in our case, informed Project Management decisions. Recall my oft-stated derivative of the Pareto Principal, that the 80^th percentile best managers with access to only 20% of the information needed 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 so needed. In other words, the existence and availability of relevant management information easily trumps superior managerial judgement, all other things being equal. It’s the reason why junior managers, generally speaking, do not have nearly the latitude of action that their more senior counterparts do – if one is not sure of the capability of a given decision-maker, limiting their options in an environment where canned strategies haven’t been tried is always the safer strategy.

Many things can chip away at an information stream’s relevancy. Perhaps the most pernicious is the insertion of subjectivity into the data set. Throughout my career, every single time I’ve been asked to perform an analysis of the circumstances and events that led up to a surprise overrun, the presence of subjective data – namely, the so-called “bottoms-up” Estimate at Completion – has been the culprit. This method of generating an EAC involves re-estimating the project’s (or Control Account’s, or Work Package’s) remaining work, and adding this figure to the cumulative actuals. The folly of employing this method is best laid bare with a simple histogram, showing three bars per reporting period, typically stretching back 6-7 months prior to the reporting cycle that (finally!) fesses up to the overrun: one bar indicates the Budget at Completion (BAC), the second shows the Project Manager’s / bottoms-up EAC, and the third shows the calculated EAC, based on the data available at each reporting cycle. Each time I’ve performed this analysis and produced said histogram, the results have been the same. The BAC level remains level (or close to level) for the duration, barring some Baseline Change Proposal that got snuck in to try and alleviate the incoming disaster. The PM’s / bottoms-up EAC mirrors the BAC, right up until two reporting cycles prior to the obvious, where it ticks up a bit, and then jumps to the same level as the Calculated EAC has been showing all along. The level of subjectivity inherent in the PM’s EAC, or the estimators’ take on the remaining work, render that version of the EAC irrelevant to the task of alerting management of an upcoming overrun. I call this effect pernicious because, not only does it fail to perform the task of identifying and quantifying cost performance issues early on, it actually does the opposite. It hides such problems, all while a valid calculated EAC is available, if management was only canny enough to reject the bottoms-up imposter.

Lack of timeliness will also erode an information stream’s relevance. “Quickness is the essence of the war,” claimed Sun Tzu,[i] and lack of it is poison to the Management Information System. The history of warfare is filled with stories of commanders not receiving critical, tide-of-battle-changing information until it was too late. Actionable PM information has a much shorter shelf-life than, say, information coming out of the general ledger, due to the more dynamic nature of Project Management over Asset Management. A Control Account Manager turning in a travel voucher late is no big deal. That same CAM who reports the percent complete figure late can disrupt the entire project’s reporting cycle.

Finally, if we are to employ the relevancy filter to eliminate otherwise disruptive data, then the comprehensive data set must be accurate. Inaccurate (i.e., false) data rarely comes with a warning label. But make no mistake – the processing methodology that can produce relevant information without accurate data has not been invented, nor will it ever be.

“Data! Data! Data!” he cried impatiently. “I can’t make bricks without clay.”

                                    -- Sherlock Holmes, The Adventure of the Copper Beeches

…and so it is with us PM-types. But the types of information streams we use are different by type, not degree, from those used by the Asset Managers, or even Strategic Managers, and the distinction will forever fall upon the filter of relevance.

[i] Retrieved from https://wealthygorilla.com/35-powerful-sun-tzu-quotes-art-war/ on July 11, 2022, 18:14 MDT.

I recently attended a conference on Predictive Analytics and Machine Learning but found it, for the most part, rather disappointing. Two of the presentations that I attended really stood out, for different reasons. The first – a truly superb one – both demonstrated an advanced knowledge in the field, and passed along usable insights. It was presented, if I’m remembering correctly, by a professor from Northeastern University. The other was just a mess. It was an attempt to attach value judgements to the results of an analysis model dealing with sentencing and parole decisions. I found the entire premise to be vacuous, for the following reasons:

• For MISs that inform public policy, no model makes decisions. They can attempt to inform decision-makers, and the decision-makers may adhere to a template, but the models, themselves, do not make these decisions.
• Data can be complete or incomplete, relevant or irrelevant, but absolutely cannot be legitimately labelled morally right or morally wrong.
• Similarly, the methodology used to process the data into usable information (alternately referred to as “the model” or “analytics,” as in “predictive analytics”) can be valid, or invalid. It cannot be considered morally right or morally wrong.
• It was clear that the presenters who had analyzed this model were doing so from an incomplete data set, and had no idea that that was their problem, much less how to pursue a remedy.

Recall Hatfield’s Incontrovertible Rule of Management # (I lost track), that all valid Management Information Systems –even those laying claim to performing “predictive analytics” – have the same high-level structure, to wit:

• Data is collected, based on some discipline or set of parameters. In PM, we tend to want to know the scope of the work, and the amount of resources and time needed to accomplish it.
• The Data is processed into usable information, usually based on some sort of methodology. For we PM-types, Earned Value and Critical Path methodologies are central to our Management Information Systems (MISs).
• The information is delivered to the decision-makers in a way that they can actually understand and make use of it. Entry-level Project Controls specialists often err when they believe that all PMs can instantly understand a Gantt Chart, or a Cost Performance Report in Format 1.

It quickly became clear to me and my associates that, while the paper presenters and organizations manning booths in the Exhibitor’s Hall were demonstrably adept at collecting data and then using that data to better identify the buying habits of specific demographics (the better to target marketing efforts), they fell quizzically silent when the topic moved away from anticipating purchasing trends. The favorite “predictive” tool of our friends, the risk managers (no initial caps), the Monte Carlo analysis technique, was never mentioned in my hearing. An old saw in the Legal Profession is “If the facts are against you, argue the law. If the law is against you, argue the facts. If the law and the facts are against you, pound the table.”[i] I think the management science derivative would be “when you don’t have the actual algorithm at the heart of you MIS down, talk about the data. When you don’t have a real shot at collecting the comprehensive data set to make your model work, talk about the algorithm. When you have neither, fake it.”

Speaking of faking it, a common but utterly invalid method for creating a Management Information System that supposedly gives advanced warning of problems is to set up some form of a common data repository, call it something like an “action item manager,” and then have it collect data without a clearly-defined discipline or structure. The resulting “system” is, essentially, a poll, a data stack surrounded by input and output nodes. The problem with a poll is that someone always has better (more recent, or more accurate) data, so that its holdings are unreliable. Add to that the fact that massive amounts of subjectivity get shoe-horned into this “system,” and you have an environment perfectly suited to the generation of an invalid MIS, passing along highly subjective data as reliable information. What could go wrong?

Which gets us back to the whole notion of data being “disruptive.” Data, by definition, can be timely or late, relevant or irrelevant, but it can’t be wrong, or inaccurate (the term “bad data” is analogous to “bad facts.”). If a particular fact is found to be disruptive, the question has to be asked, disruptive to what? Or to whom? Well, to a particular belief, and the person holding that belief. In this sense, the whole of the PMBOK Guide® could conceivably be seen as disruptive to all of those business schools still teaching the obsolete concept that the purpose of all management is to “maximize shareholder wealth,” similar to the fact that the Earth casting a round shadow on the moon during a lunar eclipse is “disruptive” data to flat-earthers. Is your model or analysis technique delivering unexpected or unreliable output? It could be disruptive data, sure. Verify the data, of course, but suspect your analysis technique.

Or you could just pound the table.

[i] Sandburg, Carl, retrieved from https://www.goodreads.com/quotes/918291-if-the-facts-are-against-you-argue-the-law-if on July 4, 2022, 17:38 MDT.

I left off last week’s blog by pointing out that a very common strategy for standing up a new Management Information System (MIS), one that entails problem or information deficiency analysis, selection of the solution, purchase, installation, training, and then…failure. Well, usually not complete and dramatic, like the HAL 9000 killing every astronaut on board the Discovery except for Dave in 2001, A Space Odyssey. Such failures usually have a closer resemblance to Deep Thought, the supercomputer developed by the Magratheans to solve the Ultimate Question of Life, the Universe, and Everything in The Hitchhiker’s Guide To The Galaxy. (WARNING: Spoiler Alert!) 

*  *  *  *  *

In the aforementioned Hitchhiker’s Guide, the Magratheans are highly desirous to learn the answer to the “ultimate question,” the meaning of “life, the universe, and everything.” To obtain this answer they spend 7.5 million years constructing a supercomputer they name “Deep Thought.” Upon finally completing Deep Thought and posing the question, Deep Thought replies with the first six words in this blog’s title. It ultimately delivers “the answer,” but it’s not one that the Magratheans can understand – it’s the number forty-two. When quizzed on how forty-two could possibly be the answer, Deep Thought responds by chiding the Magratheans for putting so vaguely-worded a question to it in the first place. When the Magratheans ask how the question should have been articulated originally, Deep Thought reveals that it can’t deliver that answer, but can help design the next-generation computer than can, but it will take around 10 million years.

So, what can we learn from the inestimable Douglas Adams?

I think Deep Thought’s story is strongly analogous to those organizations seeking a turnkey solution to their Management Information System problems. Is Chapter 28 of The Hitchhiker’s Guide an over-the-top exaggeration? Sure. Does it present the Magratheans as having a comically narrow obsession with obtaining their desired result? No doubt. But even with these distortions of scale, consider how closely this story aligns with the pursuit of large-scale turnkey “solutions.”

• Senior members of the organization are highly desirous of obtaining some information stream, one that will make most (if not all) of their management problems go away.
• A clearly-articulatable and precise scoping of the end-product is almost never available.
• Indeed, to the extent that specifics of the desired system are submitted for evaluation, they’re almost guaranteed to generate more conflict and confusion. There’s even disagreement among the Magratheans about whether or not the excessive time needed to deliver the answer is a good thing or a bad thing.
• While an acknowledgement of the vast amount of data needed to produce an answer is generally ceded, the precise methodology for converting that data into usable information remains hidden.
• When the solution is delivered, it’s not what those who posed the question had in mind. It is, for all practical purposes, either extremely disappointing, or out-and-out useless.

Then we come to the nominal implementation strategy for a turnkey solution. Unless we’re looking at a brand-new organization, or an established one with an absolutely barren MIS environment, the desired turnkey solution will displace an existing system (or systems) considered inadequate for the present demand. Problem is, not everyone who is counting on the continued functioning of these supposed inadequate systems believes they ought to be replaced. Even when the existing system is widely recognized as needing replacement, since the current operations staff is rarely consulted for its replacement, they will invariably resist the change. I could go on (and often do), but you see my point. One does not have to be a Magrathean to place high hopes (and massive budget amounts) in the establishment of a supposed turnkey solution only to have those hopes dashed (and budget wasted) on the ultimate result.

The solution? Don’t pursue an all-at-once answer. Consider how much easier it is to name specific added capabilities to existing systems to make them incrementally more robust as opposed to having one system generate an ill-conceived final resolution. Collect the obtainable, easily-captured features that can be added to existing systems, or derived from pulling and normalizing several extant programs. Triage these incremental upgrades, but, unintuitively, don’t give precedence to the most important ones. Prioritize the ones that are clearly articulatable, and relatively easy to add, meaning the least amount of hands-on-keyboards effort to collect the needed data. Ideally, the data could be pulled from existing systems, or accessible via a current system that’s not using an available feature.

The Magratheans executives who had their hearts set on a turnkey solution won’t be happy, at least not at first, so it will be important to document the successes of the incremental enhancements as they come on-line. Recall Hatfield’s Incontrovertible Rule of Management (whatever), from last blog, that the 80^th percentile best managers with access to just 20% of the information they need to obviate a given decision will be consistently outperformed by the 20^th percentile who have access to the information so needed. We’re not trying to jump straight from 20% to 80%, which is likely impossible anyway. Just take a couple of points at a time, and before you know it your executives will be making superior, and then optimal decisions.

All without you having to tell them “I’ll have to think about it.”