Game Theory in Management

Before I walk away from the ProjectManagement.com theme of Artificial Intelligence, or AI, I want to point out another one of the difficulties it has to overcome prior to taking over the world: it involves those strategies or tactics that require a specific sequence of decisions or choices to be made correctly in order for the whole scheme to succeed. As I pointed out last week, AI “learns” through trial-and-error. Like the Hexapawn Robot, if the programming employing an aspect of AI comes to a result that has been defined as a failure, it will remove the last decision made prior to the failure as an option, and launch the simulation again.

Now consider the chess tactic known as a “sacrifice.” This happens when a player will offer the opponent one of the pieces in order to secure a superior position, leading then to the counter-taking of more material from the opponent, or even checkmate. The combinations that include a sacrifice that also lead to a forced checkmate (or irresistibly superior position) happen as a precise sequence. However, if an AI application were to execute only the sacrifice portion of the sequence in the combination, it would likely present as a blunder, or failure, since it would appear to be a set of decisions that resulted only in the loss of material. Life in general and the business world in particular are filled with these kinds of scenarios, where any given strategy or approach to a given challenge becomes nonsensical if the particular tactics are taken out-of-sequence, or evaluated prior to their intended completion.

Then we also have the issue of assigning responsibility, for both success and failures. This is most often done by evaluating the sequence of events from the success/failure determination, but in reverse, and assessing the quality of the choices leading to that particular action. For example, if a bridge collapses, we don’t blame the bridge, but those who designed, built, and/or maintained it. Depending on the precise nature of the failure, the knowable aspects of the collapse are collected and binned in order to draw reliable conclusions about the nature of the failure, and who specifically is responsible. Often there are more than a single responsible party or event, with catastrophes typically being the result of an entire series of breakdowns. My favorite example, the sinking of the Titanic, had many such breakdowns, including:

• The lookouts didn’t have binoculars, even though they were on board. Why not? Because the White Star Line had fired the purser who had the key to the lockers where the binoculars were stored prior to the beginning of the cruise, and nobody wanted to break into the lockers.
• More well-known is the fact that there weren’t enough life boats on board. Why not? Several reasons, but the two that jump out are (1) there weren’t regulations in-place that required sufficient life boats for all passengers, and (2) with its water-tight compartments, it was believed that the Titanic was unsinkable, meaning that no life boats would then be necessary.
• There are many more, but I’ll wrap with the fact that the aforementioned water-tight compartments weren’t topped by water-tight decks. After four compartments had been breached by the collision with the iceberg, the ship listed forward enough so that the water in the compromised sections simply spilled over into the ones aft, leading to its eventual sinking.

In short, very few decisions of import are made in isolation, or by a single person. They almost always impact other people’s decisions or circumstances, in ways that are impossible to foresee, much less quantify, thereby making any template- or algorithm-based solution untenable.

In the Titanic’s case, the review board found, in addition to the too-few-lifeboats problem, that the ship was travelling too fast for the icy conditions, and that its design made it more vulnerable than had been previously thought.[i] Note that, except for the ship’s speed at the time of the collision, none of the other causal factors could be attributed to a single person.

Now tell me that all of these parameters could have been identified and precisely quantified in such a way that an AI app, performing however many iterations of a simulated crossing of the Atlantic, could have suggested a usable alternative strategy. No database could have known the precise location of the iceberg, or the speed that Captain E.J. Smith would select (even with the available ice warnings), or that the fired purser had kept the keys to the locker with the binoculars, and on and on. Without the perspective of history, it’s clearly impossible.

In this respect, AI shares a flaw with the risk managers (no initial caps). It’s simply impossible to know all of the relevant parameters that go into assembling a strategy for attacking complex problems, much less quantify those parameters into an evaluating algorithm that could never fail catastrophically. Sure, AI can “learn” enough for robots to walk, run, or dance, and I’m fairly sure that, one day, they will be driving cars across a busy city at rush hour, and doing so reliably crash-free. But for discovering and executing strategies that require a very specific set of tactics to be employed in a very specific order, like Project Management, I have to believe that those decisions will remain with us humans.

For now.

[i] Retrieved from https://www.history.com/news/titanic-1912-accident-investigation-reports on September 9, 2023, 21:35 MDT.

As is typical with science (particularly Management Science) trends, Artificial Intelligence, or AI, has received a lot of attention and material, and a significant portion of it is bogus. Some of the material I’ve seen is straight up laughable, particularly the idea that AI will end up controlling humans like some silicon-based, unavoidable tyrant. In my next blog I might explore how a PM-specific AI-based tyranny might manifest (it may not be that different from the current guidance-generating industry), but for now I want to focus on what AI is at its fundamental level, and why I’m not in a hurry to purchase AI-generated-dystopia insurance.

The Reader’s Digest Treasury for Young Readers (Reader’s Digest Association, 1963) is truly a treasure. Published sixty years ago, it’s full of really cool pieces – it was in this book that I first read a Sherlock Holmes story (The Adventure of the Speckled Band) – including brain teasers, puzzles, games, and projects, one of which deals directly with Artificial Intelligence. It’s there on page 176, in an article entitled “How to Play ‘Hexapawn[i],’” with instructions on how to build HER, the Hexapawn Educational Robot. And make no mistake – even in 1963, with personal computers not even being conceived as a practical possibility, HER represented true Artificial Intelligence. Here’s how it works.

Hexapawn is a simplified derivative of chess, played on a three square by three square board, populated by three white pawns and three black ones. Only two types of moves are allowed: the pawns may either move one square straight ahead to an unoccupied square, or it may capture diagonally. There are three ways to win: (1) by advancing a pawn to the third row, (2) by capturing all of the opponent’s pawns, or (3) placing your opponent in a position where he cannot move. To construct HER, you will need twenty-four matchboxes and some colored beads. On page 177 there’s an illustration of each of the possible 24 scenarios, with black dots representing the black pawns, and circles representing the white ones, on the nine-square board. Possible moves in each scenario are shown by colored arrows, and the HER always moves second.

To construct HER, copy the scenarios from Page 177, colored arrows and all, and paste each of them on top of one of the 24 matchboxes. Also place a black, blue, red and (for just a couple of the scenarios) green bead inside. Then make a move, and find the diagram of the position from the top of the matchboxes. Without looking, pull a colored bead from the box, and make the indicated move. Continue until either you or the HER has won. If you win, go to the last move/scenario that HER made, and remove that colored bead from the corresponding matchbox, eliminating that move from the available pool. In this way the HER “learns.” In the version described in the Treasury, the robot became a perfect player after losing eleven games. And this, GTIM Nation, perfectly and simply illustrates what AI is all about.

Consider: a machine can no more “learn” than 24 bead-containing matchboxes, at least not in the conventional sense. Ultimately, machines can only execute prior instructions, try random actions from a previously-defined set and eliminate the choices that led directly to undesirable outcomes, or perform some combination of the two. In a YouTube video entitled ”Open AI Broke Hide and Seek[ii],” the narrator describes how a simple digital version of the children’s game Hide and Seek was set up, with two bots being the “hiders,” and two being the “seekers.” The environment was a square room, with a smaller room in one corner, and two openings. Prior to any relevant bot behavior being observed, there were literally millions of games, with the failure of the bots to do anything “intelligent” being attributed to their “random” behavior. But that’s the whole point. Absent anything resembling real intelligence, the only way these bots could “learn” would be by playing the game and initiating some random move, arriving at an undesirable outcome, and then removing the losing choice from the repertoire, like HER did. That’s why it took millions of iterations for the Open AI application to happen across a workable strategy that any five-year-old could have ascertained within the first few instances of the game.

Don’t misunderstand – much insight can be gleaned from setting up a digital environment, and then having a program execute random decisions across multiple iterations in pursuit of the stipulated goals. Almost invariably some strategy will succeed that the programmers/designers never considered viable. But we are talking about trial-and-error here. Digital errors may have no consequences, whereas using this approach in the real world often has significant ones. Also consider that Hexapawn only has twenty-four possible scenarios, whereas the PM environments’ possible situations are, well, endless.

I want to close by reiterating … wait. I need to find the matchbox with “closing paragraph strategies” from my GTIM Educational Robot, and pull out a bead to see what to write next.

[i] Gardner, Martin, “How To Play Hexapawn,” Reader’s Digest Treasury for Young Readers, pp. 176-177.

[ii] Retrieved from https://www.youtube.com/watch?v=rVxedkeOo7w on August 26, 2023, 20:12 MDT.

Last week I discussed some of the tactics that the Anti-Project Management crowd employs, and this week I’d like to review their strategies and motivations. Why do they act that way? I mean, let our friends the accountants announce a new module in the general ledger, say, payroll, and nobody even notices, even if it means the timecard entry process has just become harder than changing the password to your wireless router. But let someone introduce an Earned Value Management System (EVMS), and certain people start to scream like scalded howler monkeys. What gives?

Let me start with a caveat – if you are doing PM wrong, either in the characteristics of the system or its implementation strategy, then your opponents are on the right side of this conflict, motives notwithstanding. And while there are, no doubt, many reasons that would come into play in the execution of this thwarting-of-PM business, I believe there are three main drivers behind the PMO’s opponents. Here they are, in reverse order of severity.

3. A bad experience stemming from a previous forced PM implementation. Since the late 1960s, various United States Government entities that rely on multiple contractors to supply goods and services have had several levels of requirements for the implementation of PM techniques, specifically Earned Value- and Critical Path-based systems. In their most vigorous phases, a team of auditors would evaluate the target contractor and issue findings on deviations from the guidance, needing time and energy to correct. Forced PM implementations tend to be difficult and expensive, and those involved will often come away with a negative impression of PM in general.

2. It might be a passing fad. Do an internet search on “management fads.” What sets many of them apart is the amount of time, energy, and budget that organizations spent in pursuing the capabilities that these fads advertised as highly desirous, if not out-and-out necessary for survival, only to have them later revealed as only marginally beneficial. Of course, PM isn’t a fad, but the existence of hypothetical business model modifications that are tends to taint any management science initiative that hasn’t been widely accepted for over a century. And now, for the Number One reason your organization is trying to stymie your advancement of the PM Capability, I give you…

1. Business Schools – Even Elite Ones – Have Been Teaching Slanted Theory For Decades. I have little empathy for accountants who complain that they have to put in excessive hours at work. Why? Because their mantra, which has made its way into every aspect of modern management theory, that the point of all management is to “maximize shareholder wealth,” has brought about this and other business model pathologies. After all, if the purpose of all management is to maximize shareholder wealth, shouldn’t you press for ever more output in the form of unpaid overtime from those very assets, as long as their variable costs do not go up? And it’s not just the accountants – every single salaried member of the staff is in the same situation. Quick organizational health indicator: if the staff is chronically overworked, with significant expectations of unpaid overtime hours, it means that that organization has bought into the “maximize shareholder blah blah blah” concept, and your time there is likely to be stressful.

This instance of management science reductionism stands in stark contrast to the raison d’etre of PM, with its focus on delivering the customers’ scope within the customers’ cost and schedule parameters. To engage in a bit of hyperbole, we don’t care if the assets are over- or under-worked, just that the scope is being accomplished on-time, on-budget. And, if it is, then we don’t worry if Project Team members aren’t putting in any overtime at all, or even (gasp!) taking the occasional afternoon off. As long as the client is happy, attempting to wring more (potentially excessive in addition to being unpaid) effort out of the Project Team is often counter-productive, in that it can lead to a decline in morale.  Of course common management theory holders are put off by the rise of Project Management’s codex. They are epistemologically inconsistent, and no narrative that insists on the supremacy of Asset Management over PM can remain intact if a successful PMO implementation demonstrates its worth. Such a PMO would establish that they, and their nominal approach to creating and maintaining the organization’s business model, are misguided.

Yeah, I know it’s dangerous to reverse engineer motives from observed behaviors, but I’m fairly confident that, if those opposed to implementing even the most basic of PM techniques were to be hit by one of those random flying sodium pentothal-tipped darts, and asked why they are opposed, they would admit to one of these three, or a derivative. Or, I suppose, they could actually be right in their opposition.

Nah.

When last week’s blog, the one where I relay a story about a “manager” who had a Ph.D. in a technical field, but really didn’t know much about management, attracted more comments than I usually see, I realized I had touched on something of a sensitive subject. For those PM-types who are tasked with heading up a Project Management Office (PMO) with the objective of either advancing the PM capability within the macro-organization, or even introducing PM to the org, a whole host of seemingly irrational issues lie in wait to hinder or even derail your efforts altogether. While these issues may appear to be irrational, they do, in fact, have some rationale behind them, but they’re rather dark. I’d like to spend some time pulling back the curtain on these motives behind the PMO’s opposition. By no means am I guaranteeing a remedy to them – I’m just wanting to do some clarifying. It helps to know your opponents.

Prior to evaluating motives, let’s take a look at some of the more common tactics employed by those who seek to undermine the PMO’s mission. Virtually all of the opposition the PMO Director will encounter will be covert, and yet still highly effective. So, in no particular order, here are some of the ways the opposition will resist the expansion or advancement of PM.

1. The Silent Veto/Slow Roll. Back when I was writing the monthly back-page column for PMNetwork, I had the opportunity to get to know the other columnists, including the brilliant Bud Baker, now a professor emeritus at Wright State University. While researching my first book, Things Your PMO Is Doing Wrong (PMI Publishing, 2008), I communicated with Professor Baker about the phenomena I called “the silent veto.” This occurs when the other members of the macro-organization, especially the highly-placed members, tell you to your face that they’re happy to support your initiatives as you set up your PMO; but, when the time comes to actually do something, they’re strangely absent. Bud offered that his version of the silent veto was called “the slow roll,” which is similar, but with an insidious twist. Those who promise support actually provide some, but not really enough to attain the next level of capability maturity. Instead, these false allies will gauge just how much organizational leveraging would be needed to achieve the next milestone, and simply wait you out. They know that you won’t make it without their robust support, but they also know they can’t be perceived as failing the PM initiative, so they do actually help, just not enough and not in time.
2. The “It’s Too Difficult” Objection. This is one we PM-types kind of do to ourselves. By insisting on a robust PM capability, often without even considering the Quality, Affordability, Availability – pick any two configuration of the organization, those outside the PMO can actually have a point when they assert that the amount of time and energy needed to attain such a state isn’t worth the investment. The infuriating thing here, though, is that I’ve been hit with this condemnation even when the cost/schedule performance systems being proposed were extremely simple, and easy to implement.
3. I’ve also encountered the opposite of #2, the objection that, if the cost/schedule performance system is truly simple and easy to implement, then it can’t possibly deliver accurate or relevant information. Numbers 2 and 3 represent something of the classical Catch-22: if it’s not too expensive, then it’s a cheap imitation of the real thing, which is, by their definition, too expensive.
4. The “Too Small” Dodge. Ironically, the same people who will insist that their project work is too small to bother with a cost/schedule performance measurement system will typically be rather sensitive to overpaying for car repairs. They don’t object to performance measurement on principle, they just don’t think they should be subject to it, hence the old saw “project teams detest performance measurement because it vividly shows their lack of performance.”
5. The Low Risk Parry. A derivative of #4, the manager employing the Low-Risk Parry will attempt to assert that their project work is so routine and template-like that the use of a performance measurement system would be entirely superfluous. GTIM Nation knows of my disdain for risk management (no initial caps), on the basis that it consumes resources but return nothing of value, but this is a case where it’s actually damaging to PM writ large. By employing the risk managers’ (no initial caps) jargon, they are actually arguing against the use of PM techniques. The kicker is that they often get away with it.

Of course, there are other tactics, but in my experience these are the most common. Feel free to add the ones that irritate you the most in the comments section. Next week, in Part II, I’ll seek to reveal the motives of the people who tend to hinder PMs just on principle, and explore possible counter-measures.

They don’t call Project Management “the accidental profession” for nothing. Many of us arrived here from a business or management background, but a lot of us came into this profession via a more indirect route, specifically, through a technical discipline that landed us in front of a new project. And this is where it can get really interesting.

I recall one particular meeting I attended based on an invitation from a high-level executive who suspected his head of Program Controls was doing a poor job. The executive was right. This fellow wasn’t trained in PM – he had a Ph.D. in a technical discipline, and knew just enough PM jargon to insinuate himself into the newly-created slot he occupied. His Team was large, as was the conference room, so I just took a seat in the back and kept my ears open.

“Here’s the problem I want addressed” he began, standing in front of the rather large white board. He drew five large rectangles on the upper third portion of the white board.

“These represent the major program offices” he stated. He then drew about a dozen smaller rectangles in the middle third of the white board, in a different color.

“These are the major projects within the portfolio” he said, as he drew lines both between the mid-level rectangles and the high-level ones. He then drew around twenty small rectangles on the bottom third.

“These represent the organizations that perform the work.” Using another dry-erase marker color, he drew lines between the small rectangles and the mid-sized ones, with many of them reaching to the opposite side of the white board.

“Some of these projects cross programs, and most of them use multiple organizations, often at the same time.” Using yet another color, the lines drawn were proliferating.

“They also use some of the same facilities,” (more lines) “and, in some cases, the projects’ work overlaps with others.” At this point the white board looked like someone had thrown up on it after having eaten a massive amount of spaghetti with Skittles sauce. If he thought he was depicting a desired business model end-state, he was comically mistaken.

“We have to be able to capture all of these entities, and their relationships to each other, in order to create a comprehensive program plan.” The individual Team members, almost all Project Controls Specialist, were strangely silent. I guessed (rightly) that most of them recognized that this manager didn’t know what he was talking about, but were reluctant to offer their opinions about how to properly approach the problem. It wouldn’t be long before I found out why. After the meeting, I approached him, and asked for a sidebar. He knew me by reputation (I had actually trained most of the Project Controllers in this organization), and, after summoning his deputy, we sat in the foyer.

“When you say that you need to capture how the projects ‘overlap,’ that’s typically accomplished with a Work Breakdown Structure, where the scope is delineated in a hierarchical fashion. Which elements of scope belong to which project and program are then clearly defined. When you discuss the need to identify possible overloading or underloading of the resources needed, that’s usually done using a resource dictionary in your Critical Path Methodology software. By assigning specific resources to the activities laid out in your WBS, possible conflicts can be identified and avoided. Finally, the issue of more than one activity or organization using the same facility can be resolved by loading the work’s locator codes into the schedule baseline. Once the schedule baseline is calculated, those conflicts will also be identified.” The fact that I had to tell this fellow such fundamental things about PM was a bit frustrating, and I rather had the impression that he believed his technical Ph.D. should have entitled him to automatic deference in PM matters. I learned later that he was planning on solving his problem by purchasing and employing a specific software package, one based on the Earned Value Methodology. There appeared to be no effort at ascertaining whether or not the package cleanly interfaced with the CPM software, or the general ledger. I came to believe that he had simply seen a presentation by this particular software vendor, and had been sold without a clue of how the package would fit into the overarching MIS architecture – and he wasn’t about to change his mind. I then realized why the room of Project Controls analysts stayed silent – they knew it was futile to reset this fellow’s technical agenda towards something that might actually work.

Don’t misunderstand – I’m not saying a plurality, or even a sizeable proportion of technical Ph.D.s view their PM counterparts as intellectual inferiors. But PM isn’t easy. It’s not rocket science, but doing it right is not easy.