Game Theory in Management

GTIM Nation knows of my oft-repeated axiom, that, in order for any Management Information System (MIS) to add value, it must have the following three characteristics:

• It must be accurate. Inaccurate data or information is worse than useless, since it can easily lead to the exactly wrong managerial response.
• It must be timely. Old data or information is similarly risky to predicate decisions in the here-and-now.
• Finally, it must be relevant.

For those readers who see that last bullet and think, “Well, of course! Why is Michael pretending that this is some sort of insight?”, I can tell you in full confidence that the ability to discern which information streams are relevant, and which are not, is rare. And I can prove it.

Exhibit A has to be the very existence of so many irrelevant MISs. On several occasions in my career I’ve had to argue against the practice of substituting spend variances (Budget – Actual Costs) for valid Cost Variances (Earned Value amount – Actual Costs). It seems that every time I was drawn in to these discussions, the spend variance advocates were poring over Projects’ basis of estimate (BOE) at the line-item level, then comparing that to the general ledger’s costs at the same level, and then deluding themselves into believing that every time they came across a significant delta, it represented an “Aha!” moment. I would then propose the following mental exercise: Imagine you are the PM of a Project that originally budgeted $250K (USD) for labor, and $750K in heavy equipment. At the Project’s completion, they actually spent $500K in labor, and $400K in heavy equipment. Wouldn’t the spend variance indicate a severe overrun in labor costs, likely for the whole period of performance? And wouldn’t that be the wrong indicator of cost performance, since the Project actually finished with an underrun?

So, in the evaluation of Project performance, the spend variance is a bad information stream. Consider, though, that it meets two of my criteria, in that it’s usually available immediately after the accounting period has closed, meaning that it’s timely, and the arithmetic is fairly straight-forward, meaning that it’s accurate. The only element missing, the only one that renders the spend variance unusable as a performance indicator, is its relevance. As an aside, I was looking through my old accounting texts, and the only place I found where even the Asset Managers use the spend variance is when they’re calculating depreciation. For non-PMs who may be reading this, depreciation has absolutely nothing to do with Project Management.

Exhibit B has to do with the scarcity principle. Management Information Systems aren’t free, and they’re rarely cheap, especially the valid ones. I recall a conversation with a so-called Project Controls Manager, who was advocating for the aforementioned spending-variance-at-an-absurdly-detailed level report. After proposing the also aforementioned mental exercise, and his having no rational response, he resorted to asking “why wouldn’t anyone want to know this?” In my mind, the answer was so obvious that it might have actually attained mass, but I articulated it anyway. “Management Information Systems require time and energy, to collect the data, process the data into information, and deliver that information to the decision-makers. That’s time and energy that could be spent on relevant information streams, instead being wasted on … this.”

Next, I’ll just say this out loud: unless you are running for political office or awaiting a jury verdict, polls are irrelevant. Nevertheless, many MISs which are essentially polls will masquerade as legitimate, while they are anything but. Valid MISs all have the same basic architecture, delineated in the previous paragraph: data is collected based on a certain discipline; it is then processed into usable information using a specific process (for PM Types, this is usually Earned Value or Critical Path methodologies); it is then presented to the decision-makers in a format that they can readily understand. Polls, on the other hand, have an architecture that looks like a spider. They are basically a central data repository, surrounded by input/output nodes. Almost anybody can provide input, and almost anybody can extract data opinions from this repository. The problem with polls, though, is that somebody always has more recent or more accurate data, meaning that, in the MIS sense, they are utterly unreliable.  

Finally, I want to address that King of the Irrelevant MISs, risk management (no initial caps). What should the PM’s response be when their risk manager informs them that there is a 32.6% chance that a significant injury will occur on their Project in the next six months? Besides the obvious questions (How did you arrive at that figure? How do you know it’s not 32.3%, or 32.8%? Can you possibly narrow down the date range, or specify a location?), what action, immediate or future, is being recommended by this “information?” I believe that, since this “information” is not actionable, it’s straight-up irrelevant.

PMs in general, and PMO Directors in particular, would be well-served to develop a sense of detecting relevancy in their information streams, so as to best choose among the various Management Information Systems vying for establishment and maintenance. Once you have developed the Relevancy Power Skill (RPS), feel free to use it – your Project’s (and portfolio’s) success may very well depend on it.

“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.