Game Theory in Management

The Battle of Jutland was an epic naval engagement that occurred from May 31 through June 1, 1916, between the English Royal Navy Grand Fleet and the German High Seas Fleet in the North Sea waters around Denmark. Over 240 ships were involved in what would become the largest naval engagement of World War I. Despite its massive scale, Germany was unable to break the blockade imposed by the British, and the significantly reduced fleets returned to their home ports with the status quo largely unchanged. There is a distinct possibility that Jutland is the most analyzed naval battle in history, but an American journalist working for the New York Times summed up the battle as “The German Navy has assaulted its jailer, but is still in jail.”[i]

I just love it when seemingly complex and highly layered events, literature, or ideas can be reduced to their basics. From the website Awkward.com comes this distilled version of Jane Eyre:

Jane Eyre

By Charlotte Bronte

Ultra-Condensed by Samuel Stoddard

(People are mean to Jane Eyre)

Edward Rochester

I have a dark secret. Will you stay with me no matter what?

Jane Eyre

Yes.

Edward Rochester

My secret is that I have a lunatic wife.

Jane Eyre

Bye.

(Jane Eyre leaves. Somebody dies. Jane Eyre returns.)

The End[ii]

My super-sensitive blogger’s ears can hear GTIM Nation say “But Michael! If large-scale historical events and instances of classical literature can be so reduced, doesn’t that imply that otherwise complex and layered theories within the Management Sciences can be, too?” To which I reply, yes, yes they can. Naturally, my mind turns to one of my favorite targets, the risk managers (no initial caps).

Of course, modern risk management (I’m just going to start using the acronym nic, so I don’t come across as redundant) is a massive industry, with piles and piles of literature describing its preferred techniques within the PM environment. And yet I believe that the whole shebang as it applies specifically to PM can be reduced to the following central question: If something goes wrong, who is going to pay for it? I’ll explain.

Consider the Firm Fixed Price (FFP) contract. The customer pays for the successful completion of the scope, by a specific date, for an agreed-to price. The contractor is on the hook for anything that goes wrong, whether it be weather, poor performance, force majeure, whatever. While risk managers (nic) may be very active in developing the analysis that helps inform whether or not the contractor should pursue the work in the first place, they really have no role post-contract award. The central question has already been answered.

But when we move into the other types of contracts, specifically the Cost-Plus variety (Cost Plus Fixed Fee, Cost Plus Award Fee), the central question is suddenly thrust into confusion. This is where the generation of post-project adjustments or adjudications occur, since such conflicts don’t arise if the project is successfully delivered on-time, on-budget. Something went wrong, and, unless the central question has been answered in a way that’s amenable to both parties, some form of conflict is inevitable.

In those cases where something has gone wrong, but the project is still in process, Change Control becomes the arena for discerning the answer to who pays, which is why Baseline Change Control is often such a formal process. For those of you fortunate enough to have not endured a Baseline Change Control Board proceeding, the main issues almost always revolve around (1) what went wrong?, (2) by how much (specifically, the cost and schedule impact), and, perhaps most importantly, (3) who’s to blame? Because if the contractor is performing poorly, or has selected a manifestly improper technical approach to accomplishing the project’s scope, then there’s really no case for even asking the client to pay for the reversal, even if the Contingency Reserve has been funded (NOT an automatic, by the way). The two most common ways by which the contractor asserts that it is appropriate to either tap the Contingency Reserve or request more budget is to assert that the setback was caused by the customer adding scope (scope creep), or point to any entry in the risk register (nic) that documented that the thing that went wrong was predicted (albeit with Gaussian hedging), and therefor falls under the “known unknowns” rubric. Itself reduced, it’s another way of the contractor saying “See! I told you this might happen. Now you have to pay for it!”, which is an additional indicator that all of risk management (nic) within the PM realm can be reduced to the question “If something goes wrong, who is going to pay for it?”

While the preponderance of the risk management (nic) industry would doubtless object to my summation, I don’t mind. I wouldn’t imagine Charlotte Bronte fans would be okay with Mr. Stoddard’s synopsis, either.

[i] Retrieved from https://strategyinhistory.com/the-battle-of-jutland-the-use-and-mis-use-of-sigint/ on 19 December 2023, 19:36 MST.

[ii] Retrieved from https://awkward.com/enjoy-these-condensed-versions-of-classic-books/ on 19 December 2023, 20:13 MST.

I’m really looking forward to an Artificial Intelligence (AI) – enhanced future. No, not the one where skeletal androids hunt down desperate enclaves of nuclear war survivors. I’m looking forward to a future where a goodly percentage of the management sciences precepts that have populated college-level textbooks and have been informing countless business model formations are subjected to millions upon millions of simulated transactions in a virtual free-market environment, and shown to be either valid… or not. Certainly the creation of such a free-market environment model that captures most of the necessary parameters and process representations would be a huge leap forward (note that I did not say “captures all of the necessary parameters.” That’s impossible.). But at some point a reliably scalable model will either be developed, or discovered already in-place somewhere, modified for a specific industry, locale, or business environment, and the simulations will begin showing which parts of the management sciences are reliable, suited for use in the real world, and which are, shall we say, sub-optimal (cough, risk management, cough).

Last month in this blog I discussed some of the limitations of AI that would prevent it from, well, creating a dystopian future where skeletal androids hunt down desperate enclaves of nuclear war survivors (https://www.projectmanagement.com/blog-post/75600/how-to-know-if-your-ai-assisted-pm-software-is-getting-ready-to-take-over-the-world). Central to this notion is the fact that AI can’t randomly create a strategy and simulate its execution if that strategy is not a possibility in the first place. Your hexapawn robot can’t generate a take-over-the-world strategy if that isn’t a legal move in hexapawn (spoiler alert! It isn’t.). GTIM Nation will recall my observation that there are three distinct types of management, each with its own goals, methods, and information systems:

• Asset Management, dedicated to “maximizing shareholder wealth,”
• Strategic Management, oriented towards maximizing market share with respect to the competing organizations in the field, and
• Project Management, whose goal is to meet (or exceed) the customer-specified parameters of scope, cost, and schedule.

Of these, Strategic Management is probably the most wide-open. Sure, there are regulations on what one can or cannot say in a television or radio commercial, but the decision of where to spend your advertising or hostile takeover dollars is largely up to the organization itself. The Marketer’s Bible: Your Guide To Marketing, Sales, Influence & Persuasion, Public Relations and Internet Marketing, by Richard C. Wilson, is 654 pages, and, based on the title alone, sounds like it's at least somewhat comprehensive. I’m pretty sure it does not have the force of law behind it. You can buy it and use its insights, or choose not to. It’s entirely up to you.

Similarly, the PMBOK Guide®, at just 250 pages (Seventh Edition), which Amazon says is #1 in Business and Finance[i], also does not have the rule of law behind it. Sure, the PMP® recert committee might look at you sideways if you are known to be in blatant violation of it, resulting in your project coming in way late and over budget, but it’s not like PMI® has an enforcement arm looking for such things (at least not that I’m aware of).

Generally Accepted Accounting Principles (GAAP), and its overseas counterpart the International Financial Reporting Standards, are entirely different critters. I tried to do an internet search on the size of the GAAP, and came up dry, but I’m fairly confident that the page count of its combined codex is wayyyy more than the PMBOK Guide® and The Marketer’s Bible combined. Not only that, but, in many instances, GAAP absolutely does have the force of law behind it. The accountant who sets up his organization’s chart of accounts in clear violation of GAAP is risking real legal trouble.

It's due to this reason that, while AI may have a profound effect on Project and Strategic Management, I would expect its impact on Asset Management to be rather muted. The GAAP codex is so massive and fixed that I would be very surprised if there were that many opportunities for even the creation of multiple various asset management strategies within GAAP’s confines to be tested for efficacy in millions of simulations. Indeed, the opposite may be true: due to the Asset Managers’ dubious ability to precisely value an investment when employing the Return-on-Investment formula, AI may actually increase the odds of returning a recommended strategy that would hinder the organization’s ability to advance in either PM or Strategic Management.

As an additional bonus, since the Asset Managers’ approach tends to dominate college-level business scholarship, AI-led advances in Project and Strategic Management may cause the gap between what’s taught in business schools and what works in the real world to grow – think Rodney Dangerfield’s character Thornton Melon in the movie Back To School. And when it does, it should be something to behold.

That’s why I’m looking forward to it.

[i] Retrieved from https://www.amazon.com/Guide-Project-Management-Knowledge-PMBOK%C2%AE/dp/1628256648/ref=asc_df_1628256648&mcid=356fda33ffbb3b53b427853a04ccc3fa?tag=bngsmtphsnus-20&linkCode=df0&hvadid=80264466333902&hvnetw=s&hvqmt=e&hvbmt=be&hvdev=c&hvlocint=&hvlocphy=&hvtargid=pla-4583863992928250&psc=1 on December 10, 2023, 10:08 MST.

Project Management disasters are often compared to train wrecks, mostly, I would imagine, because of their commonalities: the horrific results are often foreseeable, could have been avoided with some common sense, they have significant consequences, and they’re almost inevitable, in that, as long as there are trains running and projects to be managed, there will be train wrecks and massive overruns and delays. To carry this metaphor a bit further, what should one do if they were to find themselves in a passenger car on a train that was headed off of the rails, or on a project that was headed for a disastrous end?

I’ve had this type of conversation often with a brilliant friend and colleague – I’ll call him Doug, ‘cuz that’s his name – and from these discussions it appears that there are basically three alternatives:

• Rush to the locomotive, and try to convince the engineer to switch tracks or stop the train,
• Rush to the caboose (do they even have those anymore?), line up some pillows or padding against the fore bulkhead, and brace for impact, or
• Exit the train (Impossible, you say? I’ll point you to the opening scene in Indiana Jones and the Last Crusade, where a teenaged Indiana Jones does just that).

A fourth alternative, to do nothing and hope for the best, was excluded from our discussions for not being viable, even though I’m sure a plurality (if not majority) of people choose it.

Of course, many factors can and will influence both the choice of alternative and its timing, including:

• the proximity in time and space to the actual crash,
• the perceived receptiveness of upper management to entertaining strongly urged suggestions to modifying or abandoning the current course of action,
• the ability to remain within the organization while minimizing the personal impact of a project disaster,
• and the availability of workable exit strategies.

Sometimes the alternative selection and timing is obvious. If the project is headed for a terrible end, in the near-term, management is impervious to entreaties to change their course of action, there is no place within the macro-organization to insulate you from the project disaster’s consequences, and another perfectly acceptable position has been offered to you, the choice (exit) and timing (now) is pretty clear. More often, though, to the aware PM-type, the clues that things are going to go south in a big way present themselves much earlier, if more subtly.

It's been my experience that, much of the time, the primary determiner for which alternative to choose has to do with the perception of how receptive the engineer would be to taking advice or technical direction from someone perceived to have a lesser expertise in train driving. In some cases, access to the train’s engineer highly restricted, if not impossible. But these characteristics in and of themselves provide clues. If upper management is impervious to Project Team members’ urgings to update or abandon the technical agenda, it’s typically an indicator that the placement of the personnel within the PMO isn’t based on merit. Weak managers, who’ve attained their senior-level positions within the PMO based on something other than capability, are terrified of being challenged, especially and particularly when it comes to setting the technical agenda. I wrote one of my PMNetwork columns (The Variance Threshold) about an organization that was so entrenched in their ossified business model that an underground newsletter aping the format of the official company one was published, mocking the entire executive suite for their absolute refusal to listen to employees’ inputs or feedback. When the conductor/engineer is so insulated from the people on the rest of the train that he can’t even hear their warnings about the upcoming crash, forget about trying to get to the caboose to ride it out. Get off the train. Alternatively, if the PMO execs aren’t weak, it might be worth your while to get to them and describe, in objective terms (see last week’s blog), the nature of the problem, why it may have gone unnoticed thus far, and what to do about it. If they listen, you and the rest of the Team win. If they don’t, well, that’s another clue for you.

Now, I can hear GTIM Nation saying “Michael, where do the risk managers (no initial caps) fit into this over-extended analogy?” I’m glad y’all asked. The risk managers would be one of those guys back at the control center, placing a call to the engineer, so.

“There’s an 18.3 % chance you will have a crash.”

“Should I slow down?”

“I didn’t say that. You have a schedule to keep.”

“So, what am I supposed to do with that little estimate?”

“Do with it what you will. It came from a super computer running a kajillion Monte Carlo simulations, taking into account…”

“But you’re not recommending any specific course of action?”

“Right, but you’re not listening to the amount of really sophisticated stuff that went into…”

(Hangs up.)

In this way, the risk managers (no initial caps) can lay claim to some level of accuracy when it comes to predicting the future. If the wreck occurs, they can say that they warned as such. If it doesn’t happen, they can say that they never claimed that it would probably happen, just an 18.3% chance. Neat.

Ultimately, of course, it’s up to you to know if, upon attaining a high level of confidence that a wreck is in your short-to-mid-term future, you want to attempt to change the course of the train, insulate yourself from the effects of the wreck, or get off. Just keep in mind, if you do have such confidence that it’s going to happen, staying put and hoping is probably not the optimal approach.

I think one of the best lines from Indiana Jones and the Last Crusade (1989) occurs fairly early on in the movie, when a teenaged Indiana Jones emerges from a pirate archaeological site expecting to see the boy scout troop with whom he had arrived, only to see nobody at all, and blurts out “Everybody’s lost but me!” It’s similar to a meme I’d seen previously, along the lines of everybody who drives slower than me is an idiot, and those faster than me are maniacs. Using yourself as the baseline for the frame of reference with which others are evaluated is part of human nature, I suppose, but it does have implications for the management sciences, particularly PM.

In a blog from last month I asserted that a precise and comprehensive codex of how Project Management ought to be conducted is elusive, due to the broad nature of the kinds of work that fall under the PM rubric. I also pointed out by way of contrast that this is very different for our friends, the Accountants, whose Generally Accepted Accounting Principles (GAAP) are specific and comprehensive, able to address almost all scenarios involving quantifying and managing assets. Given that we PM-types are bereft of a codex that could come close to addressing almost all (or even a plurality) of the scenarios we face, what should serve as the basis for reliable analysis and decision-making where the PMBOK Guide® is lacking, or even silent?

Before I take on that question, I wish to discuss what we should not do. We should not arrive at the Project Team technical issues eval meeting with an attitude of “everybody’s lost but me.” Human nature or not, using one’s education and experience as the nominal baseline for evaluating potential strategies going forward is always going to be a risky proposition. Part of the very basis of intelligence is the ability to encounter novel situations, remember a (validly) analogous previous situation, and derive an approach to the new one based on what worked in the previous circumstances, or avoiding a known failed strategy. But when it comes to working out a technical approach on a project, given that projects are, by definition, unique ventures, everybody on the Project Team is likely to have in their experience database some event that they believe to be analogous to the present one, but virtually none of them will have the same event in mind.

Then we have those outside the Project Team, but are nonetheless weighing in on things like the appropriate technical approach. I’m referring here to consultants who, for the reasons stated above, might not only fail to advance the Project’s technical agenda, but could even detract from it. One of the first things they teach you in auditor’s school is that you never walk into the target organization/Project Team and just start carping about things being done in a way you don’t like. If you are going to issue any kind of finding at all, it must be (a) something that’s objectively (any other person can observe) going on, (b) is in direct violation of a specific rule, procedure, regulation, etc., and (c) attachable to the exact date/time/circumstances of the observed alleged violation to the exact rule, procedure, regulation, etc. being transgressed. I think this basic rule is used to avoid the very phenomena of an auditor waltzing into the middle of the target organization and starting with the whole “everybody’s lost but me” business. 

So, if that’s the approach to be avoided, which is to be embraced? Well, for that I’ll point to the character of Mr. Spock, from Star Trek. Spock is a Vulcan, a people whose entire basis for interacting with reality is based on a mastery of logic. Back here on Earth, the practice of engaging logic in the pursuit of analyzing the nature of these novel situations has consistently shown itself to maximize the odds of identifying the true nature of things, and informing the selection of workable (or even optimal) strategies to attain a solution. To illustrate what I’m talking about, I can’t recall a single instance where Mr. Spock draws a conclusion or makes a recommendation based on his educational background, or widely-perceived superior intelligence, and I’ve watched a lot of Star Trek (the original series – not so much the following stuff). Conversely, a person could read hundreds of pages of auditors’ or consultants’ findings/corrective action requests, and not see a single solitary reference to an academic study, or even refereed professional journal article. They will point to verifiable facts (the WBS Dictionary has a different title for Activity 1.4.3.2 than what appears in the Schedule Baseline), but then draw not-entirely-plausible conclusions from that little factoid (…showing a profound lack of Scope and Schedule Baseline integration).

The solution, of course, is to conduct the analysis of the Project’s central technical challenge in such a way as to reduce each of the assumptions to basic premises, which can be verified objectively or, at the very least, widely agreed to and supported. Place these premises into a valid logical structure, i.e., one that can be Venn diagrammed. If a known-successful approach is to be furthered, make sure that that success was based on a strongly analogous piece of scope.

Otherwise, you’ll be lost … and illogical.

I think I’ve detected some elements common to the horror stories based on some form of Artificial Intelligence (AI) fulfilling the role of antagonist, namely:

• An advanced computer, more advanced than the kinds of machines with which we’re used to interacting,
  • A quick side note – this advanced status can be due to some technological breakthrough in computer science with capabilities implications not fully understood by those who accomplished it, or some form of accidental merging of software, or even accidental exposure to an electrical field.
• This computer has been tasked with something specific, but somehow manages to make decisions outside the original boundaries,
• …decisions or choices that should have never been selected due to a lack of an overarching moral code,
• …and is in a position to implement those decisions in a way that can’t be stopped or mitigated by humans.

I’d like to take a look at these premises, one at a time, because they’re all pretty dopey. Let’s start with the second bullet, that the AI-based machine is, somehow, making decisions outside its original set tasks. In PM parlance, this would be Scope Creep, but to Cecil B. DeMill proportions. Recall my blog entry from August, The Ultimate AI Primer Came From ... Reader's Digest!, where I discussed creating an Hexapawn Robot. Briefly, one plays the Hexapawn Robot by retrieving a colored bead from a matchbox with the possible moves printed on the top, with corresponding-colored arrows on those maps indicating which move to make. Now, consider a scenario where the human involved in the game with the Robot makes a move, identifies the position on the appropriate matchbox, opens the matchbox to retrieve a colored bead, and instead pulls out a tightly-folded piece of paper that instructs the player to grab a weapon and attempt to take over the world. In order for any computer to engage in Scope Creep, somebody would have had to make that available as an option beforehand. The computer/robot simply cannot do such a thing on its own.

Next up let’s take a look at the decisions being made being outside any kind of a moral code, or even common sense. True, the value of using AI lies in its ability to uncover useful strategies based on multiple iterations of trial-and-error tests, and by “multiple” I mean, based on the complexity of the problem, potentially millions and millions of tests. That’s kind of the point – by limiting the number of parameters that create the boundary structures for the random generation of solutions, an approach that would have otherwise been overlooked due to the ethical mores of the people seeking a solution have a chance to show themselves, and re-enter the consideration pool. But if you ask your AI app to assist with blending pixels in a photoshop project, and it comes back and tells you to grab a weapon and attempt to take over the world, clearly the app’s programmer has failed to put an essential potential-solution guardrail in place. It’s not the app’s fault – the error belongs exclusively to the programmer who failed to include that little limiting factor in the tested scenarios generated.

Then we have the scenario where AI has furthered a possible strategy for addressing a given problem via multiple (again, potentially millions) of trial-and-error tests, but this time is in a position to actually implement said strategy. I mean, it’s one thing to drive a virtual car on a city street in a computer-generated simulation, but something very different when that same AI app is navigating an actual Honda Accord in downtown Dallas, Texas. The people in the buildings, other vehicles, and, yes, walking in the crosswalks being “hit” in the simulation don’t file massive lawsuits against the AI-driven vehicles’ manufacturer and software engineers. Essentially, there’s a big difference between an AI app arriving at and promoting the take-over-the-world strategy and being able to put such a strategy into motion.

Finally, let’s loop back to the first bullet, that some technology breakthrough, attained either through dedicated research or some accidental confluence of events and people, has led to the creation of the hardware piece of an AI system, and that’s to blame for the unexpected and unauthorized attempt at taking over the world. While mankind’s ability to develop technology that can prove to be extremely dangerous is a common plot driver in movies and novels, I think part of the intrigue here is that this is happening with (gasp!) computers. It’s easy to forget that these are the same kinds of machines that inexplicably fail right as you send a slide deck to the networked printer just moments before your huge presentation before your boss’ boss’ boss. I mean, nobody’s worried about a sudden technological advancement in microwave ovens leading to an unexpected and unauthorized takeover of the world, so why would calculators or word processers be any different?

Due to these factors, I’m fairly confident that we have nothing to fear from AI, at least not for the foreseeable future. Unless, of course, our AI-assisted PM software generates a Variance Analysis Report that reads “Cost Account is showing an out-of-threshold negative Cost Variance, indicating that IT’S TIME TO GRAB A WEAPON AND TAKE OVER THE WORLD!!!”