Game Theory in Management

After subjecting myself to numerous articles on the topic of Artificial Intelligence (AI), on its seemingly unlimited potential and unnerving capacity to bring about a dystopian future for all mankind, I thought I’d take a moment to consider AI’s most vexing limitation: the fact that complex problems only rarely have direct, simple solutions, but direct and simple are the only ways that AI can actually “learn.” This is not to say that AI can’t be used to discover solutions that hadn’t been previously considered, or that humans adapting an AI-generated solution can’t realize disastrous ends – not at all. I’m just saying that the popular view of AI’s “learning” technique may be imparting to it a level of sophisticated solution-providing that it simply doesn’t have, and likely can’t attain.

Consider that, at its very root, AI can only “learn” via trial-and-error. As an example, how would AI specifically arrive at a solution to, say, discovering which single-digit whole numbers add to ten? That algorithm would have to be limited to the numbers one through nine, calculate each of the possibilities, and then store the successful calculations. The pseudo-code would look something like this:

DO  UNTIL ALL OF THE SINGLE DIGIT WHOLE NUMBERS HAVE BEEN ADDED

DO UNTIL THE RESULT IS 10

ADD 1 PLUS 1

IS THE RESULT 10?

YES: STORE THE COMPONENTS

NO:

ADD 2 PLUS 1

IS THE RESULT 10?

YES: STORE THE COMPONENTS

NO:

ADD 3 PLUS 1

(These four lines incrementally repeat until the numbers 1 – 9 and 9 – 1 have been added together.)

END DO

END DO

TURN THE WORLD INTO A DYSTOPIAN NIGHTMARE

(Okay, that last line has nothing to do with ascertaining a solution to the example problem. It was a joke – though no computer would recognize it as such.)

Then, when the AI researcher retrieves the results, he will find that the stored components are 1 + 9, 2 + 8, 3 + 7, 4 + 6, 5 + 5, 6 + 4, etc. Now, compare this whole process to how a third-grader would attack the same problem, and you can begin to see how more complex or layered problems would be far more difficult to solve using only trial-and-error. Of course, even the most basic computers could execute the trial-and-error algorithm very, very quickly, but the problems that present themselves in Management Science space tend to be far more complicated than the example above – otherwise, we PM-types would find ourselves easily replaced by this nascent AI technology.

Note also that the AI researcher would have had to set up the algorithm with the necessary parameters. This is key to the whole AI-creating-dystopia narrative, where the various computers that had been created in order to address some major problem in real-time, like law enforcement or strategic nuclear arms usage, come up with a solution that never would have been selected by responsible executives or high-level decision-makers, but is, nevertheless, implemented before any actual person can slam the brakes on it. In short, the optimal strategies for major issues, like law enforcement or strategic nuclear arms usage, are so complex as to not be discoverable exclusively through trial and error. Past examples can inform the search for the optimal solution in these instances, including past failures, but they can’t serve as the only method for ascertaining such strategies, tactics, and decisions.

Another way of highlighting AI’s complexity problem would be to consider how the above pseudo-code would be modified if the problem moved from “discover each of the single-digit additive combinations result in 10” to “why do you want to know which single-digit combinations result in 10?” (which is, ironically, something that our comparison point third-grader may well ask prior to attacking the problem in the first place). Indeed, AI is likely to be comparatively helpless when enlisted to answer any question that begins with “why.” Why? (snicker) Because causality doesn’t lend itself to discovery via trial-and-error, unless the alternatives are both (1) identifiable and (2) quantifiable. Yes, we all know that the Titanic sank because it hit an iceberg, but that’s the simple answer – we do not need advanced AI to tell us so. However, if one wishes to consider more nuanced causal factors, such as the speed of the vessel, its rudder’s relative size, the alertness of the lookouts, the lack of watertight caps to the watertight doors, the unavailability of binoculars for the lookouts, and dozens of other factors, simply reading history books would be the way to go. Computers can already perform document searches, so AI doesn’t bring anything to the table there.

One more little tidbit – in the above paragraph, I had originally typed “…that the Titanic sand because…”, and the MSWord Review function didn’t find that odd. My advice, then, would be to tread carefully when tapping AI’s assistance in selecting a solution for an even remotely complex problem. You wouldn’t want the Titanic to sand, would you?

In last week’s blog, an alert GTIM Nation member added a comment that contained the following:

“Hence, many PMOs operate as a PAAC (Project Accountability Avoidance Office).[i]”

(Yes, the commenter subsequently addressed the fact that the Project Accountability Avoidance Office’s acronym is actually PAAO.)

This set my remaining active brain cells into overdrive, as I reflected on that sentence’s implications. In particular I remember reading about an interview question that went “Would you rather be part of an empire in its ascendency, or its decline?” Let’s set aside the sheer goofiness of this question actually being asked in an interview. Any thinking person would instantly recognize that the potential employer is going to prefer candidates that choose the former, and respond accordingly. But that question, I believe, points to one of the main implications of the term Project Accountability Avoidance Office, that I would articulate as “Project organizations begin with the goal of actually executing scope on-time, on-budget; however, over time, they tend to shift their overall focus on sustaining themselves as a PMO, collecting salaries and scolding internal opponents.” The movement over time from genuine PMO functions towards “Project Accountability Avoidance Office” purposes strikes me as a migration away from accomplishments outside the PMO (the macro-organization’s project portfolio) and towards the internal goals of self-perpetuation and well, to be blunt, influence peddling.

Recall the axiom “This is an unfair thing about war: victory is claimed by all, failure to one alone.” Originally attributed to Tacitus[ii], derivatives include “Success has a thousand fathers, failure is an orphan.” What would lead the nominal PMO to seek to engage in accountability avoidance, then? Would it not be … failure? Failure to bring Projects in on-time, on-budget? Rather than continue asking rhetorical questions, let me just drop this unattractive truth on the conference room table: when the project portfolio performs poorly in cost and schedule space, the whole reason for having a PMO in the first place comes into play. If such a PMO is already in sustaining-themselves mode, their tactics will become more and more off-putting, as they will attempt to justify their existence through narratives that are divorced from actual performance, and more along the lines of the eat-your-peas-style hectoring that I often decry in this blog.

And here is where a cruel irony of the Project versus Asset Management struggle manifests. There is no Return on Investment (ROI) without happy clients, which, in turn, doesn’t happen without effective PM. But, once those clients are being confronted by overruns and delays, the litmus test that will be used to overhaul (or even dismantle altogether) the PMO will be the ROI.

So, how does the PMO Director keep from crossing the line between legit PMO and the downward slope towards PAAO? For this I want to turn to one of the four Maccoby archetypes, the Company Man.

Quick refresher for recent GTIM Nation additions: the brilliant Michael Maccoby wrote a book entitled The Gamesman; The New Corporate Leaders (Simon and Schuster, 1976), in which he posits four worker archetypes:

• The Craftsman doesn’t really care for whom he works, but does care about the quality of his output.
• The Company Man tends to assume the persona of the team around him.
• The Jungle Fighter gets ahead through calumny and deception, clinging on to victors and distancing themselves from losers.
• The Gamesman doesn’t see his salary or other benefits as a roof-over-the-head, or food on the table. Rather, he sees his renumeration as some kind of token in a grand game he’s playing. Because of this he is both more likely to have attained a mastery of the “rules” of this “game,” while being more willing to take risks.

The canary in the PMO-to-PAAO path coal mine is going to be the Company Man. Craftsman and Gamesman will feel right at home in the legit PMO, Jungle Fighters in the PAAO, and each will feel out-of-place in the opposite environ. What are your Company Men doing? Remember that they tend to take on the persona of the organization around them, in this case, the PMO. Are they directly involved in advancing PM capability within the organization? Or are they attempting to distance themselves from failing/failed Projects, Jungle Fighter-style?

If the latter, there’s at least a possibility that your PMO is starting to turn into a PAAO.

Three strategies will help avoiding that path: (1) keep your PMO lean, spending only on the things that actually improve Project performance, (2) base assessments of PMO value on actual portfolio cost/schedule performance – no appeals to what others hold to be “proper” management techniques, and (3) keep reading this blog.

[i] Freeman, George, from the comments section of the Game Theory In Management Blog, posted 16 April 2024.

[ii] Retrieved from https://dailystoic.com/success-many-friends-failure-orphan/ on 20 April 2024, 19:47 MDT.

Back in the 1970s a major American car manufacturer had an advertising campaign for one of their cars that included the assertion that their car, when compared to others in its category, had “more road-hugging weight!” I and my car enthusiast friends would often mock this assertion – anyone with a sense of the need to optimize a car’s power-to-weight ratio would instantly recognize that “selling point” as pretty lame – but, after all these years, I’m not sure we were mocking the right people.

Consider the mindset of the people who wrote the actual ad copy. They must have known more than the average car buyer about which car specifications would be considered attractive, and yet they included the more-weight data point as if it wasn’t a detriment. The more I (over-) think about it, the stranger it gets. I have to wonder if they considered going with “better ride,” which often accompanies heavier car chassis, or even “safer in a collision,” which is also associated with heft. Don’t get me wrong – I don’t know who put those ads together, or approved them for airing. My speculation, though, is that they knew going in that the “more road-hugging weight” assertion would not be attractive to consumers with an advanced knowledge about cars, and were, therefore, attempting to attract those people who would hear such a statement and consider it a preferable feature. They may have also been under the belief that those people who considered “more road-hugging weight” to be a positive thing outnumbered those who would instantly recognize it as a negative, at least among the population of those who made the ultimate decision in car purchases. The whole thing essentially begs for a clear-headed person, familiar with the actual goal of an automobile (to reliably, efficiently, and effectively transport people and cargo from Point A to Point B) to step up and say something.

Meanwhile, Back In The Project Management World…

Ah, yes, that perennial need for a clear-headed person to step up at critical times. This need is obviously not confined to advertising campaigns for 1970s-era cars. It is, in fact, ubiquitous, but this is a blog dedicated to Project Management, so I’ll confine my discussion to that arena by starting with the question, What is the point of a Project/Program Management Office (PMO)? Since I’ve posed this question to GTIM Nation previously, you only get go-to-the-head-of-the-class recognition if you are both a newbie AND answered “to provide PM-centric information to decision makers that is accurate, timely, and relevant.” In those cases where the PMO also serves as the organizational node for PMs, it also has to have a lot of meetings.

I’m not going to debate it – that’s the right answer, the warp and woof, the raison d’être

of the PMO. Of course, I’m fully aware that there are those who would disagree with this assertion, typically by maintaining that the PMO is also responsible for:

• Changing culture,
• Providing a thorough risk management (no initial caps) capability,
• Enhancing communications with “stakeholders,”
• Performing Six Sigma analyses.
• Maximizing the procurement process,
• Optimizing the recruiting approach,
• Training,

…or, perhaps most odious of all,

• Maximize shareholder wealth.

I take sharp exception to each of these claims, on the basis that these hangers-on to legitimate PM science fail to directly contribute to PM’s ultimate goal, to select those strategies and technical approaches that maximize the odds of bringing in the project on-time, on-budget. For those of you who are curious whether or not there’s a litmus test for what I consider a legit PMO purpose or not, it would be this: is it quantifiable?

The accuracy and timeliness of PM information can be gauged. Not so whether or not an organization’s culture is advancing with respect to its embrace of PM precepts. The risk managers (no initial caps) consistently flunk the relevancy test, as do the Six Sigma aficionados. Procurement and recruiting – which, incidentally, fall under the Asset Management umbrella – should work efficiently and effectively, but those standards of efficiency and effectiveness are entirely subjective.

Now consider how much effort is put into selling the PM community writ large that each of these specialties should have a place at the table when it comes to establishing an overarching codex of PM practices and principals. All they would need to do is to conduct a valid study that showed, in whatever quasi-controlled experimental setting, that the PMO that spent time and energy pursuing, say, an advanced Communications Management capability was consistently bringing in its portfolio on-time, on budget, due to the adoption of CM techniques. I’ve never seen such a study even attempted.

It's almost as if all they have left to back their claims of their specialty’s PM relevancy is to assert the management science equivalent of “more road-hugging weight.”

No discussion of career advancement within Project Management (ProjectManagement.com’s theme for March) would be complete without an at least cursory compare-and-contrast exercise with the nominal career trajectory of our friends, the accountants. What pops to the surface of this cursory examination is the obvious fact that these two nominal career paths are very different, even though in each case we’re talking about bringing to the macro-organization a certain level of business expertise in matters ranging from the picayune (should we rent or buy the copier? Which estimating method should be used in deriving the Cost Baseline?) all the way to the future-defining (which indirect projects should be funded this year? Which projects in the portfolio represent the macro-organization’s core capabilities?).

I think the central reason that the Asset Managers’ nominal career trajectory is so different from the typical PM practitioner’s has to do with the fact that the general ledger is the system of record when it comes to determining how much tax revenue is due to the government. That’s the reason that all licensed businesses are required to have a general ledger before they can conduct any actual business. Compare this to the fact that, for the most part, even large project-oriented businesses are completely free to either embrace the tenets of PM as articulated by PMI® (or any of the other organizations promoting its practices), or to eschew them altogether. Granted, those organizations that do resist the precepts of PM are far more likely to fail, earlier rather than later, but the fact remains that they are still entirely able to ignore the PMBOK Guide® if they so desire. No such leeway is granted for the creation and maintenance of the general ledger. Conducting business without one can (and almost certainly will) lead to the arrest and imprisonment of the managers responsible. Can GTIM Nation imagine how the business world would be different, if PM was the law of the land, and it was the Asset Managers who had to convince the management universe of the efficacy of their information systems? Conventional wisdom would bestow axiomatic status to the assertion “The point of all management is to deliver the customers’ expectations on-time, on-budget,” and to hint that the point of all management is to “maximize shareholder wealth” would get one laughed out of the faculty lounges in business schools across the land (hey, a guy can dream, can’t he?).

The point here is, as long as there are governments keen on collecting tax revenue from businesses (essentially, forever), there’s going to be a baseline-level of demand for those who have a talent for creating and maintaining those types of information systems, i.e., accountants. We PM-types are left on our own, to seek out and support those organizations on the lookout for a competitive advantage when it comes to delivering scope on-time, on-budget. “But Michael!” I can hear GTIM Nation say, “That’s also a forever business environment! There will always be companies seeking such an advantage!” True, but, as pointed out earlier, those organizations that eschew PM won’t go to jail for it. And falling behind on Project cost and schedule performance can take time to become obvious to the clientele writ large.

Here, again, is an example of why the Asset Manager’s career path is different from the typical PM practitioner. If, at month-end close, the books don’t balance, the accountant/CFO has clearly erred. Conversely, if, at the project review meeting, a PM is showing an out-of-threshold negative cast and schedule variance, he has an opportunity via the Variance Analysis Report to accurately explain why … or to obfuscate, deflect, and deny the bad news in front of everyone’s eyes. Essentially, the accountants’ mistakes are clear, direct, and reliably quantifiable. The PM’s mistakes can be obscure, circuitous, and imprecisely quantifiable (hence the need for Variance Analysis Thresholds).

With that kind of space between timely, accurate, and certain evaluation parameters and eventual PM reward (or comeuppance) being established, non-merit-based operators have all they need to move upward in the macro-organization’s PMO at the expense of the most talented. Only the long view, at the portfolio level, will reveal which PMs consistently bring in their scope on-time, on-budget, and even that is contingent on a broad-based Earned Value Management System (EVMS) that keeps track of all of the projects’ actual performance.

But EVMSs aren’t required. General Ledgers are. I think that’s the main reason why the career advancement of PMs is usually more uneven than that of the Asset Managers’/accountants’. All this having been conceded, I must admit that I kind of prefer the uneven trajectory. It keeps things from getting boring.

GTIM Nation knows of my low regard for risk management (no initial caps) analysis as a source for reliable management information. The one area, though, where it might be of some use is in the creation of a Contingency Budget for projects that have been negotiated as a Cost Plus-type contract. This type of contract is normally used for projects that involve a significant degree of risk, typically due to being performed at a venue where personal and materiel security can’t be guaranteed, or else due to the incorporation of new technology, truly novel scope, or some combination of these. Due to this inherent level of uncertainty, many project sponsors will allow for the development of a Contingency Budget, for work that is definitely in-scope, but isn’t in any of the baselines.

Ah, but there’s the rub: what, exactly, is in-scope, uncosted? This question is the very essence, the raison d’être of the whole Baseline Change Control process. For if there was an easy litmus test for which requests for additional budget were legitimate, and which were based on poor performance (and should therefore be rejected), then it wouldn’t take a multi-member Baseline Change Control Board to micro-evaluate each and every Baseline Change Proposal (BCP), deliberate it, and hand down a determination days (or even weeks) later. Such a litmus test could have conceivably prevented the entire Agile/Scrum Project Management theory codex from coming into existence, since its main purpose was to streamline configuration management in such a way as to keep BCCBs from delaying needed changes to software projects’ baselines that had to happen in the very near-term in order to prevent IT project failure.

Alas, such a litmus test does not exist, requiring the now-elaborate processes embedded in the Baseline Change Control Board charter to ensure the funding of true contingency events, the exclusion of false ones, and an equitable treatment of the in-between events. These processes are highly resistant to formulaic remedies and, due to this chaotic aspect, begin to assume the characteristics of some grand game. For example, a common assertion from the risk management (no initial caps) crowd is that, if an uncosted event occurs, and it was described in detail in that Project’s risk register, then the approval of the Contingency BCP should be somewhat automatic. However, if a true contingency event has happened, but it was not documented as a possibility, then the risk managers’ strategy with respect to the role of the risk register has to change, from being an adequate tool that captures potential risk events, to a document that only addresses some of the things that might happen, and we just missed this one, don’t you know. It’s the risk managers’ version of the heads-I-win, tails-you-lose trick, rephrased as “If it happens, and it’s in the risk register, it’s automatically a legit contingency event; but, if it’s not, it still might be a contingency event, we just need more time to tell you why.”

Then we have the very real possibility that either the customer or the PM may act in a way that would allow only one of them to win this game, as depicted in the following Payoff Grid:

Scenarios (B) and (C) depict the BCCB functioning as it should. Savvy customer oversight management will be on the lookout for Scenario (D), in order to prevent a “get well” BCP from getting through the process, and covering the costs of poor performance, a bad initial estimate, PM-initiated scope creep, or any of the other drivers of project overruns and delays. Conversely, PMs will work to prevent Scenario (A) from unfolding, which would lead to the contractor having to absorb the costs from an event that had nothing to do with the Project Team’s performance, or even the agreed-to Scope Baseline. It’s noteworthy that Scenario (A)’s outcome is exactly the same as those instances where the Customer induces scope creep, in that (1) the Project Team performs work that was not costed, but somehow slithered was informally introduced into the Scope Baseline. Within the game vernacular, this could be seen as either master-level play, or cheating, but what’s clear is that we’ve moved well beyond the nominal method of disposing business conflicts and into a winner/loser configuration, meaning we are, essentially, playing a game.

And Game Theory is what this blog is all about.