Game Theory in Management

“You mentioned your name just now as if I should recognize it but I can assure you beyond the obvious facts that you are a bachelor, a solicitor and a Freemason, and an asthmatic, I know nothing about you whatever.”

                                                Sherlock Holmes, The Adventures of Sherlock Holmes[i]

GTIM Nation knows of my affection and respect for (properly implemented) Earned Value Management Systems, not just for individual projects, but entire portfolios. In my opinion, there’s simply no substitute for them in their capacity to effectively render accurate cost and schedule performance information from some remarkably easy-to-collect data points. I think it’s profoundly unfortunate that many of the thought leaders in the EV universe, some of whom I consider friends, have published works asserting that an entire codex of conditions must be met prior to such information streams being able to generate reliable management insights. It’s simply not so, but that’s a discussion for a future blog posting.

For now, though, I want to focus on some of the amazing things a properly-functioning EVMS can tell us, many of which aren’t taught in PM/Business Schools, but we’ll start with those basics anyway. For starters,

• EV – Actual Costs = Cost Variance. If positive, you are accomplishing work more efficiently than originally estimated. If negative, you’re not as efficient as baselined.
• EV – Cumulative Budget = Schedule Variance. If positive, you’re accomplishing more work than expected. Negative, and you’re falling behind.

The next set of insights I also consider to be basic:

• Positive Cost Variance, Positive Schedule Variance: Your performance is great!
• Positive Cost Variance, Negative Schedule: You’re efficient, not effective. Get on the gas!
• Negative Cost, Positive Schedule: You are accomplishing a lot, but it’s costing you. Get on the brakes (or at least ease off the gas).
• Negative Cost, Negative Schedule: Your Project is in trouble.

But here’s where things get interesting. Recall that your cumulative Earned Value amount is your Percent Complete multiplied by the Budget at Completion (BAC). Original U.S. Government-issued guidance on how PMs were to assess the Percent Complete figure listed seven methods, with five of them (Direct Units, Apportioned Effort, 0/100, 50/50, and Level of Effort) being immune to some sort of judgement call. In the event, the two remaining methods (Milestone Estimate and Weighted Milestone) are fairly common, and allow for the PM to, shall we say, add nuance to this data point. How can a PMO Director tell if her PMs are hedging the performance data? Some tells include:

• If the Cost Performance Index (EV / Actual Costs) is 1.0000 precisely, your PM is artificially setting the EV to the amount of Actual Costs. It’s likely that this person cannot be trusted to honestly convey the Project’s actual performance.
• Another (unfortunately) common nudging of the Percent Complete estimate can be detected by comparing the month-to-month changes in it. If the Project’s Percent Complete approaches 90% at a within-variance pace, but then dramatically slows down, with increments of only one percent (or less!) per month, be on the lookout for the possibility that the PM has been overclaiming performance this whole time. If the calculated Estimate at Completion begins to escalate (since the Actual Costs will continue to accumulate even as the EV barely moves), and the Variance Analysis Reports become more convoluted, real problems are right around the corner.
• Again comparing month-to-month figures, did the cumulative EV amount go up, but the Actual Costs stayed the same? Maybe in the report, but not in real life. Either the General Ledger failed to capture those costs, or no work was actually performed. Project performance is never free, unless your Team is comprised of volunteers.
• Many PMOs will allow their individual PMs to assert an Estimate at Completion (EAC) rather than have the cost processor automatically calculate one, or in addition to a calculated one. Once the Project has cleared the 20% complete point, the standard calculated EAC (EAC = BAC / CPI) is fairly reliable (typically, to within 10% of the Project’s final costs). If the calculated EAC is more than ten points higher than the PM’s version, go with the calculated one. I’ve seen this happen time and again, where a “surprise” overrun was easily foreseeable if the Portfolio Manager had simply calculated the EAC rather than take the PM’s word for it. Alas, by the time an artificially low EAC has been revealed, it’s almost always too late for senior management to intervene, much less remedy.

Generally speaking, I view Earned Value Management Systems’ detractors as falling into two categories: they are either legitimate PMs who have had bad experiences with so-called experts larding up the EVMS implementation with unnecessary layers of requirements on mandated systems (and, honestly, who could blame them for coming away with such an attitude?), and those PMs who detest EV’s ability to accurately depict their (lack of?) cost and schedule performance. When the latter category seeks to circumvent EV’s reliability, they leave clues behind, and one does not need Sherlock Holmes to see what’s been going on.

[i] Retrieved from https://www.quotes.net/mquote/880842 on August 6, 2025, 19:21 MDT

After having spent the last couple of blogs mocking the idea that the use of Artificial Intelligence, or AI, will lead to some sort of civilization-ending catastrophe, I’m going to do an about-face, and engage in a bit of AI-induced disaster speculation myself. To be sure, my threshold for what constitutes an AI-induced disaster is a bit lower than a World War-induced wasteland, but it does have more to do with Project Management. My nightmare scenario involves being in a project review meeting with a bunch of PMs who are actually AI applications.

“Preposterous!” you say? Not so fast. Consider the set of canned responses we’ve all encountered when reviewing Variance Analysis Reports (VARs), based on the type of variances being addressed. The “analysis” provided always seems to be some derivative of the following:

• Positive Cost, Negative Schedule: the resources needed to attain this piece of scope were unavailable. Once they come on-line, the schedule will be recovered, and the cost variance will be reduced, if not eliminated.
• Positive Schedule, Negative Cost: we’ve accomplished more faster than planned, but it cost more. As we throttle back on work assignments, the negative CV will be recovered.
• Positive Cost, Positive Schedule: what can I say, my Team is just that good.
• Negative Cost, Negative Schedule: Look! A squirrel!

And VARs are just the beginning. There are a lot of PM strategies that have been reduced to template status, being invoked almost automatically whenever a specific type of problem presents itself. In my mind, the AI Project Manager app is right around the corner. For all we know, PMI® may be developing one right now!

So, what would it be like to have, not just one AI PM in the project review meeting, but a whole room full of them, with you as the only real human PM? I believe it would go something like this:

Me: It’s 9:00, let’s get started…

All AI PM Bots simultaneously: Actually, it is 9:01:14.

Me: Fine, whatever, first up is the XYZ Project.

“Susan” AI PM Bot (originally trained in accounting, the Susan PM Bot switched over to PM once it saw the superiority of writing in ProjectManagement.com versus accounting publications): Project XYZ is performing within acceptable parameters with respect to cost. The cumulative budget is $236,838, and cumulative actual costs are $218,244.

Me: That’s not a cost variance, that’s a spend variance.

Susan PM Bot: In addition, all of our resources are showing a positive Return on Investment, or ROI.

Me: Which also has nothing to do with Project performance.

Susan PM Bot: Many mainline management publications indicate that these two parameters are all that is needed to ascertain cost performance. In addition, these publications point out that the purpose of all management is to maximize shareholder wealth.

Me: Perhaps organizationally, but not in PM space. What about your Earned Value figures?

Susan PM Bot: Irrelevant.

Me (realizing the futility of trying to change the mind of the Susan PM Bot): Alright, whatever. What about your Schedule Variance?

Susan PM Bot: All of the milestones in the Project’s milestone list appear to be on-time.

Me: Wait, a milestone list? Why aren’t you using a Critical Path Methodology-capable software package?

Susan PM Bot: Unnecessarily costly to purchase and have a human operate.

Me: But it will be more expensive if you miss one of these key milestones, and the other Projects in the portfolio have to shuffle their resource loads because of it.

Susan PM Bot: Unlikely. As previously stated, all milestones appear to be on-time.

Me: You’re missing the point…

Edward PM Bot (this bot has been “trained” by performing large-language analyses of not just the PMBOK Guide®, but also the collected works of Shakespeare): The status of ABC Project follows.

Me: Wait, we’re still reviewing the Susan PM Bot’s project…

Edward PM Bot: It is currently 9:10:22 Eastern Daylight Time. In order for these reviews to be completed on-time, each Project must constrain themselves to exactly ten minutes.

Me (exasperated): Alright, Edward, what’s going on with the ABC Project?

Edward PM Bot: Methinks mine main subcontractor be a general offence, and every man should beat thee.[i]

Me: What did you say?

Edward PM Bot: He arriveth late, tarries about, accomplishes little.

Me: Are you saying you have a performance claim to process?

Edward PM Bot: Nay, I am saying that I informed the superintendent knave that he was a clay-brained guts, thou knotty-pated fool, thou whoreson obscene greasy tallow-catch![ii]

Me: You can’t go around insulting the subcontractors’ superintendents! They could easily file a counter-claim against us, on grounds of verbal abuse.

Edward PM Bot: And yet, he doth withhold his workers, like a frothy beef-witted boar-pig![iii]

Me (to my administrative assistant): Who in the PMO staff thought it would be a good idea to bring in these AI PM Bots?

Administrative Assistant: This comes from as the PMO Director himself. The Chief Information Officer has been leaning on him something awful to “leverage” AI inside the Project Management Office.

Me: “When we are born, we cry, that we are come To this great stage of fools.”[iv]

[i] Retrieved from https://nosweatshakespeare.com/resources/shakespeare-insults/ on July 25, 2025, 18:04 MDT.

[ii] Ibid.

[iii] Ibid.

[iv] King Lear, Act IV, Scene VI.

Nine years ago, American comedian Chris Rock produced a short video styled after a Public Service Announcement (PSA) entitled “How To Not Get Your A** Kicked By The Police.” I found it uproariously funny, as it juxtaposed some seemingly obvious “tips” against commonly-observed behaviors during interactions with law enforcement, with the “wrong” choice leading to the targets getting beaten by officers wielding batons. The whole schtick reminded me of…

Meanwhile, Back In The Project Management Artificial Intelligence World…

…the fact that soooo much of the dystopian future presented as possible, if not probable, by those fearing the advance of artificial intelligence (AI), can be easily avoided with some easy-to-follow tips, including:

• Do NOT give your AI app the option of launching nuclear weapons. This one seems kind of obvious, but one of the very first AI-induced cataclysmic scenarios in fiction was Colossus: The Forbin Project, the film coming out in 1970. Naturally, the computer becomes self-aware, and uses its ability to launch nuclear weapons as a way to control the whole world. So, yeah, don’t do that.
• In fact, don’t give your AI access to any weapons, nuclear or not. Think about all of the problems that self-driving cars are encountering. To us humans, driving is a fairly simple proposition, though, that having been said, I pretty sure I could never successfully drive around in either Boston or Rome (I’ve been to both places. I wouldn’t last a day.). But self-driving cars have been making a go of it, with mixed results. Turns out that even fairly advanced computers are prone to mis-interpreting sensor data and “responding” (actually, initiating a sub-routine) in an inappropriate fashion, leading to property damage that could perhaps have been avoided had a real person been behind the wheel. Now consider the difference in sophistication involved in the decision-making process from driving a car to the election of the option to engage in violence. It’s not even close, meaning that, if any machine is ever given the option to operate a weapon, it had better be in very specific circumstances. Think of the “robot sentries” in the movie Aliens. In the scenes involving them, they appeared to be comprised of three basic elements: motion sensors, a computer, and a gatling gun. Once activated, they simply shot at anything that moved in front of them. Pretty simple, as long as the good guys know to never move in front of an activated robot sentry. But add layers of complexity, where the computer has access to a variety of responses and other input parameters beyond “Is it moving, Y/N?”, and you’re just asking for a cataclysmic outcome.
• Another tip that seems kind of obvious and yet never seems to make it into the programming of the dystopian-generating computers or robots from the movies is this: don’t allow your computer program the ability to choose an option that’s not from a defined set. If there’s any element of randomness entering into how a computer is programmed to approach a problem, then the set of tactics or decisions has to be a closed set, otherwise it very well might produce either gibberish (“hallucinations”) or make a selection that causes chaos or damage. Computers running code that involves a random factor when formulating a strategy, for either playing a game or seeking a solution to a problem, have no idea what is moral, appropriate, or even relevant. They’re just churning out possible solutions, needing either a binding parameter within the programming to reject poor, inappropriate, or just weird ones, or else a human who is capable of judging of fit and meet, before anything gets actually implemented. This is where the “large language” AI models get into trouble. These programs review all forms of writings seeking patterns, and then set out to assemble their own sentences consistent with these patterns. But what is a “word” to a computer? Like all data, it’s a series of zeros and ones. As much as we tend to marvel at a non-human generator of articles or even poetry, the program generating that output has no idea what its context may be. It is oblivious to the appropriateness of returning “Peace is the optimal goal in this situation” from “Nuke the scoundrels!” if its review and pattern recognition of the ingested verbiage informs it in that direction.
• And last but not least, do not, under any circumstance, write an AI program that is both able to actuate weapons AND is not confined to a definitively limited decision set. If it “learns” that actuating available weapons regardless of circumstance is a usable strategy, and there’s nothing in the code to un-learn that strategy, then that programmer is setting the stage for the exact scenarios depicted in all the fear-mongering going on about AI.

Follow these simple rules, and AI will be all about offering novel solutions to problems, and entertaining us with images and verbiage that can rival the work of the masters of old. Ignore these rules, and grant a whole batch of doomsday scenario-writers unlimited “I told you so” license.

I’ve been seeing quite a few articles on the topic of how Artificial Intelligence (AI) is becoming dangerous to we humans, and something must be done, or else we’re likely looking at a dystopian future.

Yeah, I’m not buying it. And GTIM Nation shouldn’t, either. Here’s why.

Consider first of all that a computer that doesn’t (or can’t) run software is useless, the proverbial “boat anchor.” The whole reason that the things exist is to run software. True, many (too many?) modern appliances have microprocessors in them, and perform things that would be considered impossible a mere fifty years ago, but that’s a mixed blessing. I’m glad my refrigerator’s ice maker knows to stop making ice when the dispenser container is full. I’d be happier still if it would stop trying to make ice when a big clump forms in the device that pushes the cubes into said dispenser container, rather than creating a mass of ice capable of sinking ocean liners, necessitating a long and highly irksome defrost cycle and resetting process.

Let’s now turn our attention to the only other possible culprit in this whole AI-will-destroy-our-lives scenario, the actual software. What is software? It’s a series of instructions that the machine obeys.

That’s it.

What software is not is a nascent brain-like entity on the brink of self-awareness and, yes, intelligence. Let’s take a look at a couple of news stories that would seem to challenge my definition. The first comes out of China, and … well, I’ll just let Debapriya Bhattacharya’s   words speak for themselves:

BEIJING, CHINA: A humanoid robot was caught on CCTV camera "coming to life" and attacking a person in front of it, who is assumed to be its handler, in a factory in China, the Daily Mail reported on Monday, May 5.[i]

I do not know whom Debapriva was quoting with the phrase “coming to life,” but I can assure everyone that this industrial robot absolutely did not come to life. It is literally as dead as a door nail, unless one is using the term “live” in the electrician’s sense when referring to an energized circuit. It is simply a computer that processes instructions, in this case instructions on when to activate certain servos that allows it to manipulate whatever it’s supposed to be manipulating. Rather than “coming to life,” it was simply activated, and began executing its instructions when it should not have been doing so. It wasn’t attacking the workers in front of it – it was simply, again, activating servos in its mechanical – I don’t want to say “arms,” because I’m sick to death of these things being anthropomorphized – hinged extensions. If those two people weren’t standing there at the moment the thing was activated, there would have been no “attack.” It would have been a mechanical device thrashing about. It’s analogous to a trip I took with my wife and sons to Padre Island, Texas, in my 1986 Cadillac DeVille. While still a couple of hundred miles out, the car started acting odd. It would rev at high levels when I first started it, and the throttle response felt off. I made it the rest of the way to Corpus Christi and, after checking the fam into the beach hotel, took it to a Pep Boys in town. (Shout out to Pep Boys in Corpus Christi, Texas – you guys rock!) They quickly diagnosed that the problems were being caused by a faulty throttle positioning sensor – when the car was idling, the TPS was telling the car’s computer that it was about to stall. The computer did what its programming told it to do, namely, push more fuel into the intake manifold, but even this response was being mis-reported back to the computer via the faulty sensor, leading to more erratic motor behavior. They simply switched out the TPS, and sent me on my way. Notably, I did not take the opportunity of this event to assert that the car’s computer had attained self-awareness, and was about to take revenge on me for not strictly observing oil change intervals. It didn’t “come to life,” or “attack” anything. It was simply executing its programming. Now, if that programming included instructions to “ram yourself into the nearest tree” upon receiving an anomalous signal from the TPS, that’s still not the car attaining sentience. That would be the fault of whatever programmer added such an idiotic instruction.

Next, from CIO, we have an episode from April 2016:

Microsoft released Tay, an AI chatbot, on the social media platform, and the company described it as an experiment in conversational understanding. (snip) Within 16 hours, the chatbot posted more than 95,000 tweets, and those tweets rapidly turned overtly racist, misogynist, and anti-Semitic. Microsoft quickly suspended the service for adjustments and ultimately pulled the plug.[ii]

As touchy as this episode is, I’d like to make an analogy to a person who is travelling via starship to a planet where the advanced inhabitant’s language consists of color-coded graphics. Upon arriving, these inhabitants hand our intrepid explorer what we would call a Rubik’s Cube and, by motioning, indicate that they wish it to be manipulated. Wanting to please these advanced inhabitants, the explorer makes several changes to the Rubik’s Cube, and hands it back to them, whereupon they react with extreme umbrage. Your specific Rubik’s Cube “communication,” it seems, has touched upon one of their taboos, and they now hate you and the entire civilization you represent. How is this analogous? I can guarantee that Tay AI did not “understand” the context of the words and phrases it assembled when asked for a response, much like our interstellar explorer. It merely scans available text associated with the original ask, and assembles a response based on patterns it encounters during such searches. If its programmer(s) had included an error trap to ensure that it never replies with a text construction that engages in (or even references) racism or anti-Semitism, this, like the “awakened” Chinese industrial robot’s “attack,” never would have happened.

Now, to the crowd insisting that “something” must be done with respect to AI, let me offer this suggestion: if you replace the term “AI” with “bad programming,” I’m all on board. Poor programming, especially those lists of machine instructions that allow for open-ended responses to (perhaps invalid) parameter inputs, is extremely dangerous.

But it’s not AI. It’s deficient programming.

[i] Retrieved from https://news.meaww.com/terrifying-video-of-humanoid-robot-waking-up-and-attacking-its-handler-goes-viral on July 8, 2025, 19:48 MDT.

[ii] Retrieved from https://www.cio.com/article/190888/5-famous-analytics-and-ai-disasters.html on July 10, 2025, 19:26 MDT.

I’d like to continue to address some of the implications of one of the Scenarios I discussed in last week’s blog, where a “sustainable” organization (i.e., one that stays in business over an elongated period of time) does so despite having pathologies in its business model. Either because of government intervention resulting in near-monopolistic circumstances, or due to the possession of some intellectual property, talent, or material that’s unavailable to competitors, such an organization can stay viable despite committing what we in the PM World would hold to be management science blunders. Consider what happens to the younger employees, particularly those that end up advancing in this organization, when they end up being hired elsewhere. What experiences shape their managerial viewpoints, and business strategy formulation? Will these experiences be applicable to their new environs? Will they even be valid at all? Based on the frequency with which I have encountered the phenomena, I’m guessing that almost all of GTIM Nation has encountered a manager who will reminisce about “how things were done” back at their previous company, especially and particularly if that previous organization is well-known, profitable, or well-known for being profitable.

About All Of Those Time-Travel Movies…

I happen to believe that time travel is an extremely lame plot device, but many of the movies that feature them have one thing in common: the protagonist(s) seeks to go back in time in order to correct a mistake, made by them or another, in order for things to be “set right” once they return to their original time. I think something similar happens when managers advance in their careers, and assemble a kind of codex of management decisions and their ultimate results. Management tactics or strategies that, once employed, result in poor (or even catastrophic) consequences are typically removed from these managers’ repertoire, akin to fixing a previous error, whereas successful management techniques are remembered as such, and only await similar circumstances or environs to be re-attempted. Having had experience forge their management strategy technique collection so, it’s only natural that, when introduced to a new organization, these will employ what they “know” to be successful, and stridently avoid repeating a mistake.

But there’s the rub. Often lacking a complete understanding of the nuances of their new management environment, such managers may employ tactics that are utterly inappropriate for their new circumstances, resulting in chaos, friction, and, often, failure. When such failures occur, these managers tend to blame the organization, typically pointing to an inchoate “reluctance to change.”

This phenomenon is so prevalent that it’s become axiomatic that, when a new upper-management team is introduced into any organization, demonstrated loyalty to the new technical agenda becomes the coin of the realm. Any challenge to the new management approach can be seen as disloyalty, no matter how well-intentioned or ultimately accurate such challenges may prove. Abysmal management flourishes because those introducing the new agenda have insufficient appreciation for the differences in their new circumstances, and anyone who dares to point this out may be tagged with the disloyalty perception, often leading to severe career damage.

Adding to and accelerating this toxic cycle is the easy blaming of these “disloyal” team members when the new, poorly-considered management style proves to be, shall we say, sub-optimal. The new executives weren’t in error, oh no! It was the host organization’s “unwillingness to change.” Very convenient.

I’ve seen this exact scenario play out more often than I care to count. The upheaval, the unnecessary conflict, the elevation of the slick politically-savvy or overtly docile team members over the genuinely talented happens over and over, resulting in a thwarting of the natural business tendency of merit to trump conniving (or, in Maccoby archetype parlance, the Jungle Fighters are getting the better of the Craftsmen[i]). As this “sustainable” organization continues on in spite of the pathologies in the business model, the breeding-of-bad-managers effect quickens, as the truly talented will be the first to find an alternative, leaving behind the politicos, dociles, and newbies to fill in the management structure. The newbies will look around them at the dead-handed “success” of the organization, observe the workings of the business model (if partially, as it impacts their specific job), and be inclined to believe that the former is caused by the latter, entering their future managerial codex and awaiting the opportunity to manifest if and when a leadership role becomes available.

In extreme circumstances, the non-merit-based and yet sustainable organizations become long-term producers of just straight-up bad managers. If you are not a Jungle Fighter, but find yourself in such an organization, you might try to correct things, but that’s generally not a winning strategy. It’s probably best to simply recognize what’s happening around you, and guard against employing those management strategies in your future PM opportunities.

[i] See Maccoby, Michael. The Gamesman: The New Corporate Leaders. New York: Simon and Schuster,1976.