Game Theory in Management

No self-respecting blogger on the topic of Game Theory can go long without referencing the Nash Equilibrium. Named after Thomas Nash, the central character in the movie A Beautiful Mind, it refers to

…a concept in game theory where the optimal outcome is when there is no incentive for players to deviate from their initial strategy. The players have knowledge of their opponent's strategy and still will not deviate from their initial chosen strategies because it remains the optimal strategy for each player.

Overall, an individual can receive no incremental benefit from changing actions, assuming other players remain constant in their strategies. A game may have multiple Nash equilibria or none at all.[i]

So, what does this Game Theory theory have to do with Change Management/Change Agency in a Project Management context (ProjectManagement.com’s theme for December)? Plenty.

I, like virtually every other Game Theorist out there, believe that the business world is highly analogous to some grand game, with economic rewards, certainly, but other prizes as well. Many aspects of the business world inform Game Theory hypotheses, such as the notion of the “logical man,” or one who will consistently (if not exclusively) act in their own observable self-interest, whether or not that self-interest is confined to economic benefits. Similarly, much of Game Theory makes an appearance in business environments, such as commodities trading, which often takes on the characteristics of a zero-sum game. Heck, even the brilliant Michael Maccoby named his most successful business behavioral archetype “the Gamesman[ii].”  I think it’s obvious that a substantial amount of overlap exists between the two realms.

Now, lets take another look at the Nash Equilibrium definition. “…there is no incentive for players to deviate from their initial strategy.” (emphasis mine) For those PM-types who have been brought into a medium-to-large organization to set up a Project Management Office, and (presumably) advance that organization’s PM capability, success involves way more than getting your PMP®, memorizing EIA 748, and knowing how to administer Critical Path Methodology software’s databases. You can flawlessly execute the following steps:

• Get the accountants to agree to collect costs by Work Breakdown Structure elements,
• Send the Project Controls specialists to Earned Value and Critical Path school (or hire ones with that expertise already),
• Train the PMs and Control Account/Work Package Managers in the basics of PM,
• Establish usable Scope, Cost, and Schedule baselines,
• …with Baseline Change Control Boards, staffed by willing participants,
• Arrange for monthly Project Reviews, where Gantt Charts and Cost Performance Reports are the main discussion points,

…and still fail miserably if your implementation strategy isn’t near-perfectly matched to the host organization. Why is this so? Because of the Nash Equilibrium. The players Project Team members have been playing this game working here for some time, and they will often perceive “no incentive … to deviate from their initial (non-PM-oriented) strategies.”

Also, consider the influence of our friends, the asset managers. Like us, they exert considerable effort in shaping the structure of the business model, and the Management Information Systems that make it work. Unlike us, their charter is, to a considerable extent, mandated by law. An Earned Value Management System is key to a successful PMO, but it doesn’t help at all when it comes to paying corporate taxes, and not paying taxes sends even very powerful people to jail. And I haven’t mentioned the very strict standards that go into preparing a profit-and-loss statement, or a balance sheet, or any of the other exhibits that form the basis of the asset managers’ function. The idea that the purpose of all management is to “maximize shareholder wealth” was pretty standard fare when I was attending business school. Long-term members of GTIM Nation know of my many objections to that little maxim, so I won’t rehash them here. I’m merely pointing out that, while basic PM-oriented cost performance practices and techniques are not incompatible with Generally Accepted Accounting Principles, in practice they do represent an alternative way of processing, presenting, and making decisions based on management information streams. My experience and education inform me that the introduction of project performance information systems that are not dependent on the general ledger represent something of a rival to the asset managers’ influence on the overarching business model. In other words, most of the organization has probably already adopted a series of non-PM-related management strategies, and there is no real incentive to change.

So, essentially, the advance-PM-capability game can be arrayed against us PM-types from the start, no doubt accounting for many failed attempts at doing so. Blaming such failures on such amorphous aspects such as “resistance to change” doesn’t do any good, particularly for those tasked with becoming change agents. This leaves us with an overwhelming (?) question: are we ready to win at effecting organizational change, even in those cases where the odds in the game are against us?

Well, are we?

[i] Retrieved from https://www.investopedia.com/terms/n/nash-equilibrium.asp on December 5, 2022, 18:33 MST.

[ii] Maccoby, Michael, The Gamesman, The New Corporate Leaders, Simon and Schuster, 1977.

Agile Project Management is very popular among Information Technology (IT) portfolios, and for good reason. It can be reliably employed to significantly increase the odds of any given IT project coming in on-time, on-budget. It is also a source of frustration for me, since it does have some notable shortcomings, but its afficionados tend to be oblivious to them.

Problem Number One is that, while Agile does streamline the configuration management problems that tend to accompany traditional PM and its Baseline Change Control Board (BCCB) lethargy, it can also impede the discovery and implementation of the optimal technical approach. To help illustrate this, let’s turn to the Game Theorists’ favorite tool, the payoff grid. Consider two scenarios (simultaneously), where a given IT Project is headed by a manager who has identified the optimal technical solution, and is pursuing it, versus an analogous Project where the PM is rather unsure or unclear about the best way of addressing the Project’s central problem. Add to this two environments, one Agile, the other traditional PM. Here are those scenarios in a payoff grid:

Let’s dispense with Scenario D first, since this is likely the environment that hatched Agile PM in the first place. If the PM has selected the optimal technical approach to the central problem of the IT project, the last thing she needs is an ossified BCCB curtailing her latitude of movement when it comes to configuration management. A key characteristic of Agile PM is that it reduces the number of opportunities for, ahem, stakeholders to influence the technical agenda in the name of expediting progress (take that, Communications specialists!), meaning that, if that very technical agenda is the best fit for the organization, most superfluous input isn’t even allowed a venue. Conversely, if the best technical approach is unclear or even unknown, a traditional PM approach (Scenario A) can provide greater opportunities for more voices to be heard in identifying it, assuming the PM is open to the greater number of stakeholders.

The remaining two scenarios are where we can easily get into Project Management problems, with no nominal capacity within Agile to correct. The most readily-available boogey-man for those wishing to avoid traditional PM techniques in IT projects, Scenario C, is rather difficult to refute. IT projects tend to be far too dynamic and fast-paced to have use of a BCCB that meets every month, or even bi-monthly, where almost any member can slam the brakes on a recommended or needed scope update. Recall the old saw that there are no solutions, only trade-offs. What’s being traded in Scenario B? Well, if the optimal technical approach is either unknown or unclear, the removal of the BCCB carries with it fewer stakeholders providing input. This input can be inessential, but every now and then it can also be game-changing in its capacity for steering management decisions in the right direction.

Then we have the problem of implementation. Probably the only genre of software that isn’t in need of some sort of consideration of how it is to be implemented to the wider organization is games, whose customers purchase it for entertainment. I believe most everyone else is looking to enhance a management capability, which means we’re tinkering with a business model. Make no mistake: no matter how blatantly obvious that an extant Management Information System (MIS) is failing to perform adequately, there will almost always be someone within the organization who will not want it to change. In a mid-to-large organization, you can even expect some members to actively work against any transition, which leads us to Problem Number Two: while Agile may enhance and streamline the Configuration Management process significantly, it really doesn’t address the implementation strategy. As stated earlier, this is irrelevant in the development of game software, but for virtually everything else it’s going to be an issue.

“But Michael!” I can hear GTIM Nation say, “why are you laying the implementation issue at the doorstep of Agile PM? Don’t other projects have similar problems?” No, not really. You generally don’t need to convince the members of the client organization to occupy a new office building, or municipality to hook up their power grid to a new dam. Software is different like that, and, since Agile lays claim to being an adaptation of traditional PM for Information Technology specifically, I think it should be at least somewhat on the hook for this oft-encountered barrier to successful project completion.

For those who insist that simply mandating the usage of a new or updated system, on pain of discipline, is sufficient for IT project success, I would counter that a lack of an appropriate technical approach to the actual implementation will more than negate any advantage from using Agile over traditional PM in the first place. The only question left is, what are you going to do about the other half of the Agile equation?

Nicknamed “The Prince of Paradox,[i]” philosopher and writer G.K. Chesterton asserted the following:

“In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, I don't see the use of this; let us clear it away. To which the more intelligent type of reformer will do well to answer: If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”[ii]

The shorthand version of this quote is “Don’t ever take a fence down until you know the reason why it was put up,” which is close to capturing the overall meaning, though I would add the observation that, where Chesterton thought the modern type of reformer would go up to the fence “gaily,” I would substitute “naively.” It’s an easy conceit that informs younger generations that all that was set up before with which they take exception was done so out of ignorance. Properly trained auditors know the basis for their comparisons, and appropriate methods for evaluating against any given audit standard. Poorly (or even un-) trained auditors simply show up and start condemning each and every condition or technique with which they disagree.

Meanwhile, Back In The Project Management World…

A common and frustrating characteristic of reformers, in this case those who would implement some more “advanced” PM capability, such as Agile/Scrum (ProjectManagement.com’s theme for November), is that they will often approach their work with the confidence that their proposed business model updates will work for their new organization, if only the targets of the reform would (a) recognize the superiority of the reformers’ approach, and (b) cooperate with it fully. This is pretty ironic, considering the practice of software engineers to conduct what’s known as A/B Testing. In situations where older code is undergoing significant additions or modifications, or when, say, a website isn’t performing as anticipated, a standard practice is to avoid implementing the modifications all at once, and instead update characteristics incrementally, constantly comparing the new version’s performance with the existing. By approaching the update in this fashion, the team avoids the scenario where they find themselves having worsened the situation from where it was when they began, with no idea precisely which change or combination of changes caused the reversal, and, therefore, no cogent path to reclaim their losses. Without a comprehensive knowledge of all of the other modules that interact with the one being changed, it’s almost guaranteed that a significant number of these modules will fail, perhaps causing the modules depending on them to also fail, initiating a cascading effect across the entire application. And, just to be clear, it is extremely difficult to get a handle on each and every connection among nodes in even a relatively simple network.

Somehow, though, this caution in tinkering with existing nodes in a network tends to evaporate when the discussion turns to implementing a novel PM strategy, such as Agile. Make no mistake: business models are highly complex networks, whether they came into existence through a master plan, or entirely holistically, by piecemeal. One might be able to change out, say, the software package for the general ledger with relatively few implementation issues, since the functioning of the GL is highly regulated. Not so with Project Management software packages or approaches, where even the appropriate level of system rigor tends to be a highly contested matter. If an organization finds itself in the software marketplace through, perhaps, some Project Team members developing an app that solves an acute problem afflicting entire portfolios, but that organization was ill-disposed towards setting up Work Packages and Control Accounts, it’s highly unlikely that they will suddenly embrace that very change just because they are now being asked or required to create Epics, Stories, and Sprints. And even in those circumstances where the organization has a fairly robust traditional PM capability, there may very well be legitimate reasons for not streamlining the configuration management/ change control process. It would, then, be a mistake to attempt an Agile management implementation until after those reasons can be discovered, evaluated, and addressed, lest they manifest in the new business model.

To be sure, all of this can be done. It simply requires the flexibility to be cognizant of the reasons behind the configuration of the existing business models. In short, it will require the Agile PM reformer to be, ahem, agile enough to hop over Chesterton’s Fence.

[i] Retrieved from https://www.christianitytoday.com/ct/2001/augustweb-only/8-27-52.0.html?paging=off#bmb=1 on November 11, 2022, 17:31 MST.

[ii] Chesterton, G.K., The Drift from Domesticity (1929).

Being the contrarian that I am, when I saw that ProjectManagement.com’s November theme was Agile PM, my thoughts (automatically?) went to compared to what? Agile PM, a favorite of the Information Technology set, was originally developed to accommodate the significantly more dynamic management environment where software projects are developed, since employing a traditional Baseline Change Control Board that meets once per month would be to condemn the typical IT project to an ossified configuration control-induced overrun/late delivery. I get that. By arranging the elements of the project’s scope into Epics and Sprints (roughly analogous to Control Accounts and Work Packages), the members of the Project Team with specifically assigned change control authorities could quickly modify the performance characteristics of that scope to account for unanticipated conditions or advances, enhancing the odds of an acceptable product being delivered on-time, on budget. Take a look at the list of antonyms for the word “agile,” from thesaurus.com[i]:

• dull
• ignorant
• lethargic
• lazy
• slow
• clumsy
• rigid (hence the reference in the title)
• stupid (really!)

…among others. Indeed, among the list of antonyms for ”agile,” I didn’t see any that had a positive connotation. So why in the world would anyone attempt to make the case against Agile PM? I’m glad I’m asking myself that question.

The problems inherent in Agile PM are pretty easy to uncover. A quick reading of The 13^th Annual State of Agile report makes them apparent. For example, the whole raison d’etre for Agile PM was to be able to deal with fast-developing changes in scope, right? Well, on page 11 of the report, under the open-ended question “How Success is Measured …with Agile Initiatives (emphasis in the original), we see this gem: “Product scope saw a decline over the past years going from 40% to 20% and falling to 12% this year.”[ii] For a business strategy designed to alleviate difficulties in modifying scope within the traditional PM structure, this is quite the poll question response. With respect to managing scope, its own practitioners appear to be losing faith in Agile’s ability to perform as advertised.

A glance at the topic of “Challenges Experienced Adopting & Scaling Agile” is also revealing. Survey respondents’ top three challenges were:

1. Organizational culture at odds with agile values
2. General organization resistance to change
3. Inadequate management support and sponsorship.[iii]

In addition to reminding GTIM Nation of Hatfield’s Incontrovertible Rule of Management #5, that one cannot advance a capability maturity by leveraging organizational power, I’ll add this quote from Nicolo Machiavelli:

“It must be considered that there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things.”[iv]

For every frustration the “traditional” PM-types have had in influencing organizational culture to do such basic things as setting up the general ledger’s chart of accounts to mirror the project’s Work Breakdown Structure, what the Agile PM practitioners attempt in business model influence space is even more difficult. The three “challenges” listed above are essentially the same complaint: the people we’re selling Agile to aren’t buying, and management won’t make them. I believe all three reflect the inherent difficulty in “initiat(ing) a new order of things.”

Finally, if we’re being brutally honest, I’m convinced that, should each member of your typical customer-attended sprint meeting OR Baseline Change Control Board be struck by a random flying sodium thiopental dart, at least one customer would admit to being on high alert to prevent the allocation of a cost adjustment for having overspent a Work Package or two (a “get-well” Baseline Change Proposal, or BCP), while the contractor is hyper-vigilant to prevent the addition of something that’s technically not in the baseline, at zero additional cost (scope creep). How this sub-rosa conflict plays out in a typical BCCB meeting tends to follow a familiar script, including lofty discussions on how contingency or management reserve is properly defined, estimated, and used. But how it’s played out in an Agile Planning meeting is a bit more convoluted. Instead of having a paragraph in a BCP template that addresses the nature of the change, with another spelling out its impact to the baselines, the Scrum Team will evaluate “User Stories” in the Sprint Review to evaluate completed tasks, and use those lessons to inform how to continue to work incomplete tasks. With these verbal User Stories – essentially, narratives – being, by definition, more fluid than their traditional, written-out versions, it seems to me that there would be an increased chance of either scope creep or get-well changes seeping into the cost and schedule baselines.

Sure, I’ll get with the ProjectManagement.com program and discuss some of the more gee-whiz aspects to Agile PM in later blogs. For now, I just had to go ahead and make the case for performing configuration management more traditionally, or, as the list of antonyms for “agile” puts it, “rigid.”

[i] Retrieved from https://www.thesaurus.com/browse/agile on November 4, 2022, 17:33 MDT.

[ii] The 13^th Annual State of Agile report, pp.11.

[iii] Ibid, pp. 12.

[iv] Retrieved from https://www.internetpillar.com/niccolo-machiavelli-quotes/ on November 4, 2022, 18:20 MDT.

I find myself thinking about the horror film genre, not because it’s near Halloween, and not because I like watching them (I don’t), but in the sense of trying to understand their attraction or, more precisely, where they derive their fascination among those who do like to watch them. The slasher ones are easy – nobody wants to be killed with a knife, particularly one wielded by a person wearing a hockey, “scream,” pin-head, or whatever that thing that “Jason” wears-type mask, all while seemingly able to walk through walls, unerringly know when a protagonist is alone and vulnerable, and is capable of surviving all manner of gruesome deaths themselves. Certainly the more complex sub-genre of these movies has to do with a description of a dystopian future, one where most people face extremely difficult daily challenges to simply survive due to some catastrophic failure of economics, foreign affairs, ecology, or … technology.

That we may experience in our lifetimes an economic downturn, war, or extreme weather event is scary, no doubt. But there’s just something about technology gone awry that’s frightening at a higher level. Robot butlers look really cool, until they band together to either enslave or wipe out humanity (I, Robot; the entire Terminator franchise, among many others). Curing disease is certainly noble, until non-human animals become the apex planetary species as an unintended consequence (Planet of the Apes franchise, Species, etc.). And let’s not forget the fears of self-aware supercomputers combined with advances in nuclear weapons technology becoming the ultimate buzz-kill (Colossus: The Forbin Project, etc.). These fictitious scenarios have a real fascination to them, unequalled by sharks, mummies, vampires, or werewolves in that, as unpleasant as interacting with any of these might be, they simply don’t rise to the level of creating a universal dystopian future for large swaths of the Earth’s population.

Meanwhile, Back In The Project Management World…

Have you ever noticed that, whenever an action/thriller movie features some type of technology that gets out-of-hand, it’s the Project Manager that’s usually tagged as the antagonist? For example, in Jurassic World (2015), in the dinosaur-themed park that must have required thousands and thousands of people to create and maintain, somehow the head of security, Vic Hoskins (played by Victor D’Onofrio) is the ultimate bad-guy for seeking to weaponize the critters when they (of course) escape their confines. In the aforementioned Colossus: The Forbin Project, the head designer/PM, Dr. Charles Forbin, is called out in the title of the movie, along with the fact that they specified that it’s about a project. I recognize we’re talking about fiction, but, in real-life analogous situations, you could be fairly confident that neither the designers of the dinosaur enclosures nor the person who thought it would be a swell idea to let Colossus communicate with Guardian (the President of the United States) would get nearly as much blame as Hoskins or Forbin for the ensuing disasters. When the technology works, its inventors/discoverers are heroes. When it causes widespread suffering, well, the PM should have had better motives, or more respect for the technology, dontchaknow.

All of which points to a new rule I want to add to Hatfield’s Incontrovertible List of Project Management Axioms, that it’s the Project Managers who are seen (rightfully) as being the person ultimately responsible for an activity’s actual outcome, whether it was part of the original plan or not. For example, when the aforementioned cloned dinosaurs start sprinting out of their clearly sub-standard enclosures, you wouldn’t expect to hear from the Asset Managers on the topic of the wisdom of awarding the barrier construction project to the lowest bidder. Nor would it seem plausible that the Strategic Managers would select that moment to remind everyone how a zoological park featuring facsimiles of animals long-extinct AND extremely dangerous could be expected to out-draw every other zoo in the world, combined. No, blame for fictional technology projects gone wrong and inducing a disastrous, if not out-and-out dystopian future gravitates to the PMs. It’s because we own the scope of our projects, particularly so when an outcome is bad, no matter how far removed from the original intent that eventual outcome becomes. Also, it’s interesting that we don’t see any risk managers (no initial caps) around to estimate the odds and impact of the dinosaur-like monsters escaping their containment, and eventually inflicting incalculable (get it?) levels of death and suffering on the world (as depicted in Jurassic World: Dominion [2022]). Before GTIM Nation reminds me of the Ian Malcolm character (played by Jeff Goldblum), I will point out that Malcolm’s character introduces himself as a chaos theoretician, not a risk manager, and quantified none of his predictions (though I will admit finding “life finds a way” as an entry in a risk register would be highly amusing).

To correct the tendency for PMs to receive a preponderance of blame for when some high-falutin’ project goes off the rails, I think the talented writers within GTIM Nation should send proposals to PMI® Publishing for sci-fi novels that feature a dystopian future avoided by a PMP®. Better yet, we should petition PMI® Publishing to commission such a work. Just think what the movie rights would be worth!