Game Theory in Management

In last week’s blog I discussed environments where Project Teams were compelled to implement various aspects of PM, specifically Earned Value Management Systems, to an exacting standard. These systems, when properly functioning, provide an unparalleled view into the projects’ cost and schedule performance, critical information for both the customer needing to know when the project will wrap up, and at what cost, as well as the contractor seeking to meet those established goals. Project portfolios that consistently (and measurably) perform well will generally attract return business as well as new customers in that particular industry. Poor cost or schedule performance, well, doesn’t.

However, everyone current in the PM industry is well aware that the standards for “doing” Project Management have expanded, sometimes in valid ways, sometimes not. When I attend paper presentations that demonstrate more reliable ways of integrating the time-phased budget as computed by the Critical Path Methodology software package into the platform that processes Actual Costs and Earned Value, I come away believing that such time is well-spent. Conversely, if I’m somehow trapped in a presentation that goes on and on about the “need” to perform Monte Carlo analyses on projects in order to create a risk management plan (no initial caps), I begin to attempt a calculation of the conference center’s ballroom area by counting ceiling tiles, estimating their length and width (thank goodness most of them are perfect squares!), and wondering how much energy would be needed for them to start to fall down into the room, leading to an impromptu evacuation, and testing if I could summon enough of The Force, Count Duku-style, to make that happen.

So, if we’re being Forced (get it?) to “do” PM to a certain level of robustness, what does that entail, exactly? When attempting to answer this question, I think it’s important to keep in mind that common PM-related techniques, such as EVM- or CPM-based reporting systems are components of an overarching business model, whether they are perceived as such or not. Combining these components into a business model without a pre-planned structure is a sure way to drive the organization’s PMO into the ground. For example, Communications specialists will often advise the PMO to include all “stakeholders” in their Project-oriented communications, expanding the list of people who should receive, say, cost/schedule performance reports. If, by integrating the whole engage-all-stakeholders technique into the business model results in, say, competing organizations having access to monthly Variance Analysis Reports (VARs), then such an integration is clearly working against the overall mission of the PMO as well as its owning organization. Why bother to perform competitor/opposition research when their own Communications Managers tell you all about their performance issues?

GTIM Nation is aware of my predilection for basing a nominal PMO’s business model on the axiom Quality, Availability, Affordability – pick any two, and the folly of attempting to deliver all three. I believe that this axiom points to the fact that many business strategies are very capable of conflicting with others, no matter how attractive they appear in isolation. For example, who could possibly be against quality? Or, more specifically, which PMO Director could withstand the charge of allowing a sub-standard system to be implemented for a given portfolio? But that’s the thing – “sub-standard” according to whom? In an organizational environment where there are no external customers demanding strict compliance with overwrought procedures, with multiple small projects in need of just a simple cost/schedule control system, to pursue a supposed high-quality, universally-applied PM information system is not only doomed to fail, it’s actually akin to managerial malpractice.

Which leads me back to another one of Hatfield’s Management Axioms, that managerial leadership is predicated on three central attributes:

• Genuinely caring about the people on your Team. If you don’t care about them, they will tend to not care about you, or your technical agenda.
• Identifying the optimal (or at least workable) technical agenda. Teams hate having to proverbially bark up the wrong tree.
• A demonstrable passion to execute that technical agenda, alone if necessary. A “leader” positioning himself to bail on the scope is apparent to all.

While all three are key to success, in this blog I want to address the second one, identifying the optimal technical approach. One of the definitions of intelligence that I’ve come across is the ability to address novel situations and reach a desired outcome by recognizing similarities in previously-encountered circumstances, and making appropriate similar or adjusted choices. When it comes to PMOs attempting to compel an advancement in Project Management maturity, a real danger arises if that “advancement” isn’t based on the best technical approach for the circumstance. Such an approach has to not only further the PM capability, but flange up nicely with the macro-organization’s existing business model.

Otherwise your implementation strategy is likely to be reduced to waving your fingers in a clockwise direction, and saying “You will collect percent complete data at the reporting level of the WBS.”

In the mid-1960s, the concept of introducing an Earned Value Management System (EVMS) for the proper management of United States Air Force projects was enacted through an approach known as the Cost/Schedule Control System Criteria, or C/SCSC, sometimes referred to as “the C-Spec.”[i] Soon this canned approach to generating and maintaining the information streams that would keep customers apprised of the performance of the projects within their purview expanded to the other branches of the U.S. Department of Defense, then on to the new Department of Energy, and somewhat unevenly to other U.S. Government organizations. While other project-oriented industries had been using various aspects of EV and Critical Path Methodology to manage their work for some time, the efforts to collect and structure these techniques into a single codex really got their start here, through MIL-STD-881A, DOD Instruction 5002, among others[ii]. PMI® itself began in 1969, with standardization efforts making up 10 – 15% of its work.[iii] The first edition of the PMBOK Guide® was published in 1996, representing the first major academic or institutional effort at collecting and codifying the techniques across all industries that we now recognize as germane to Project Management.

But here’s where things get a bit cattywampus. For hundreds of millions of dollars’ worth of United States Government contracts, demonstrably complying with the nascent C/SCSC was (and still is) a condition of doing business. It was essentially a waste of time to bid on one of these proposals if your organization wasn’t capable in what would be considered today as a fairly basic EVMS. It was a Boolean metric: either “do” Earned Value Management in a specific manner, or you can’t get the project award. In this respect, it was very much like the “implementation strategy” that accountants used: since no organization can conduct business without paying taxes, and taxes can only be assessed based on information within the general ledger, it was a their-way-or-the-highway situation. Back on the PM side, those seeking to embrace such business model characteristics as developing Work Breakdown Structures, or Responsibility/Accountability Matrices (RAMs), or Work Packages that roll up to Control Accounts, or collecting percent complete data, or aligning the General Ledger with the WBS, etc., etc., really didn’t have to develop an implementation strategy per se. They only needed to arrange to train we PM-types in those techniques and outputs, and set us loose on the projects. The mere threat of having your DoD customer label you with a “C/SCSC Non-compliant” charge was more than enough to, for example, get our friends, the accountants, on-board with aligning the chart of accounts with these projects’ WBSs.

Just A Little Bit More History…

Beginning in the late 1980s, various guidance-generating organizations began to loosen the requirements of the C-Spec, often invoking the assertion that “low risk” projects really didn’t need the level of cost/schedule performance measurement system robustness that high-value, “high risk” work did. The drip of organizations claiming to be exempt from the Earned Value and Critical Path Management specifications on those grounds became a torrent. Even extremely high-value, cutting-edge technology projects would assert Earned Value Management Systems to be inappropriate, with entirely predictable results: overruns and schedule delays.[iv] Once tried-and-true cost and schedule performance measurement systems were no longer required as a condition of doing business, project “managers” would often opt to “control” their costs by merely watching their actuals go by. And by “go by,” I mean escalate quickly into out-of-control status.

This effect coincided with that point in my career when I started attending PMI® Congresses and other PM-themed seminars, and I noticed an interesting trend: common to most of the sessions I attended was this underlying notion that, if the PM practitioner wasn’t performing the types of analyses that the speaker was presenting, well, that person wasn’t doing PM “right.” I nicknamed this argument eat-your-peas-style hectoring. Simply putting out there the assertion that the absence of robust EVM or CPM systems represents a transgression from what the PM zeitgeist demands in no way makes up for a singular lack of persuasion-based implementation strategies. The whole argument can be boiled down to “if your organization isn’t compelled to do PM right, and doesn’t do it anyway, then they’re a bunch of dolts,” and I, for one, don’t find that particularly compelling.

There are, of course, many valid and compelling reasons why significant aspects of project-oriented organizations’ business models should incorporate the PM techniques with which we’re all familiar. But I believe that the reason they haven’t been addressed broadly can be attributed to the fact that PM implementation used to be mandatory, a condition of doing business. That’s no longer the case in many situations.

And it shows.

[i] Retrieved from https://www.humphreys-assoc.com/evms/basic-concepts-earned-value-management-evm-ta-a-74.html on May 4, 2022, at 18:08 MDT.

[ii] Retrieved from https://www.pmi.org/learning/library/articles-cost-schedule-control-system-5454.

[iii] Wikipedia contributors. (2022, March 14). Project Management Institute. In Wikipedia, The Free Encyclopedia. Retrieved 00:17, May 5, 2022, from https://en.wikipedia.org/w/index.php?title=Project_Management_Institute&oldid=1077175134

[iv] Probably the worst offenders in this category – Information Technology projects – are notorious for both eschewing EVM, and having an absolutely abysmal record when it comes to overruns and delays.

On August 2, 216 BC, during the second Punic War, Roman consuls Lucius Aemilius Paullius and Gaius Terentius Varro led an army of over 80,000 men against a Carthagian force of around 50,000, led by Hannibal, at Cannae, a village on the southeastern part of the Italian peninsula. Due to an anomaly in the rules of command in the army of the Roman Republic, command of the Romans actually alternated day by day between Paullius and Varro, and history records Varro as having been in command on August 2^nd. Typically, when Roman forces had an adversary outnumbered to this extent, victory would be all but assured, regardless of who was in command. Unfortunately for the Republic, this would be a very a-typical confrontation. Without getting into the gory details, the Romans lost somewhere between 45,000 and 70,000 men killed, while Hannibal lost around 8,000. Cannae is considered to be one of the most lopsided, complete military victories in history. Since the battle took place on an open plain, it’s fairly obvious that the Romans were poorly commanded, despite their numerical superiority. Whether or not Paullius could have managed an order of battle better than Varro is pure speculation, other than the fact that it’s hard to imagine a worse handling of the forces than the one Varro produced. Kind of makes me wonder if those soldiers marching into battle had any misgivings about the whole odd-days-Paullius-is-in-command, other times it’s Varro arrangement. As canned strategies go, this one was pretty lame.

Meanwhile, Back In The Freudian Psychology World…

Sigmund Freud and his daughter Anna asserted the existence of ego defense mechanisms, defined as:

Defense mechanisms are psychological strategies that are unconsciously used to protect a person from anxiety arising from unacceptable thoughts or feelings. According to Freudian theory, defense (mechanisms) involve a distortion of (reality) in (some) way so that we are better able to cope with a situation.[i]

Among the ego defense mechanisms that may have a bearing on the PM World (or on the Battle of Cannae, for that matter) is one entitled rationalization, defined as:

Rationalization is a defense mechanism proposed by Anna Freud involving a cognitive distortion of “the facts” to make an event or an impulse less threatening. We do it often enough on a fairly conscious level when we provide ourselves with excuses.[ii] 

Varros was one of the few Romans who survived the Battle of Cannae. How, exactly, he explained his crushing, nation-endangering defeat to himself or to others is not noted in history, but he must have done a pretty good job of rationalizing it. There’s no record of his suffering any rebuke or career reversal as a result.

Meanwhile, Back In The Project Management World…

Have you ever been in a PMO where the head honcho seems to have walked into the office with his technical agenda already set, before he or she is even aware of the strengths and weaknesses of the PMO Team itself, much less the macro-organization taken as a whole? I have written in previous blogs of the axiom Affordability, Quality, Availability: pick any two, and how at the very least the person formulating the PMO’s implementation strategy needs to consider which two aspects to emphasize, and which one to give short-shrift. The alternative – to attempt to pursue all three aspects simultaneously – is simply a recipe for disaster. The first time a significant problem arises with, say, quality, the PMO head will focus on correcting it, usually by committing more resources to the problem. When those resources are unavailable for other demands, the PMO head will pivot to attracting more talent, which drives costs up, making the PMO’s services less affordable. Another pivot to addressing escalating costs, and the quality problems resurface, on and on, like a massive business model version of the old whack-a-mole arcade game.

As the downward spiral increases in intensity, so, too, will the tendency for the PMO head to rationalize away the causes of these difficulties, and the most common target is the macro-organization for being too recalcitrant to accept the technical agenda and implementation strategy offered up by the PMO.  It’s classic Freudian rationalization. The difficulties simply can’t be due to the poor technical agenda/implementation approach that didn’t even take into account the affordability-quality-availability paradigm, no siree. It simply must be due to the ignorance or organizational resistance of the rubes in the extant organization, failing to recognize the advanced capabilities of the PMO head. Yeah, that must be it.

So, What Did We Learn From This Little Foray Into Roman History And Freudian Psychology?

Well, a few things, including:

• When the person setting the PMO’s technical agenda is using a canned strategy, without taking into account the new circumstances, the nature of the macro-organization, or skill set of the team, this strategy is almost guaranteed to fail,
• …especially if that canned strategy does not take into account which of the quality/affordability/availability characteristics are most important to the present situation.
• When it does, in fact, fail, the director of the PMO will tend to blame the very macro-organization that he neglected to adequately assess prior to the implementation attempt, engaging in the ego defense mechanism of rationalization. After all, look at all of the published guidance that agreed with him!
• If the person setting the technical agenda for the PMO received that assignment because it was “his turn,” or for any other reason than a record of success in highly analogous situations, then the attempt will almost certainly end badly.

But, somehow, Varros such PMO directors survive, and often don’t suffer any consequences. Odd, isn’t it?

[i] McLeod, S. A. (2019, April 10). Defense mechanisms. Simply Psychology. www.simplypsychology.org/defense-mechanisms.html.

[ii] Ibid.

As GTIM Nation knows, I’ve written previously about the notorious outlaw Billy the Kid, not so much because of him personally, but due to the disparity between the stories about him and the actual details of his biography. For example, American recording artist Billy Joel’s second album, Piano Man, featured a track entitled The Legend of Billy the Kid. It’s fortunate that the word “legend” appears in the title, since several of the specific assertions in the song’s lyrics are false. Consider the following table:

One has to wonder why Mr. Joel would bother being this specific about biographical details that are so at odds with the facts. It’s almost as if, when it comes to New Mexico history of the latter half of the 19^th century, he really doesn’t know what he’s singing about.

Meanwhile, Back In The Project Management World…

Most seasoned PM-types are frustratingly familiar with the difficulties inherent in trying to implement a cost and schedule performance measurement system for an organization that hasn’t worked with one previously, or is nominally disposed to resisting such implementations. Oft-heard objections include:

• It’s too difficult/time-consuming/expensive to implement (it’s not),
• If, by some miracle, you do find a way of getting one installed that’s not back-breakingly difficult, then it won’t return usable or reliable information (also demonstrably false).
• Only highly- (or over-) paid professionals can perform this feat (again, demonstrably false).
• Such systems aren’t applicable to the work this team is performing (if the work in question is a function or related to asset management, this is actually true. Unfortunately, many genuine project teams will attempt to invoke this objection),

…among others. The thing about these types of objections is that they are fairly easily refuted. Where the legend of Cost/Schedule Performance Measurement Systems, specifically Earned Value, begins to deviate strongly from its true nature is when we evaluate some of the assertions from supposed supporters of such systems.

Probably the most common example of this is the notion that the Cost Baseline (a.k.a., the Budgeted Cost of Work Scheduled, BCWS, Planned Value, or PV) must be derived from the most accurate Basis of Estimate available, with only the most recent element-of-cost, overhead rate, and anticipated escalation rates available considered acceptable. While, from an estimator’s point of view, these data elements should be the best available, from an Earned Value perspective they matter little (if any) to its reliability as an information stream. Consider the fact that, once work has commenced on a project, the EV calculation for estimating the at-completion costs has nothing to do with the accuracy of the original estimate. It’s counter-intuitive, but it’s true. The most common formula,

Estimate at Completion = Budget at Completion / Cost Performance Index

…can be reduced to

Cumulative Actual Costs / Percent Complete

…meaning that the original cost estimate is entirely superfluous for the purposes of this critical information bit.

There are many other instances of this effect, but y’all see my point. Legends about historical figures that find their way into entertainment venues usually do not lead to significant breakdowns in the advancement of the management sciences, with their associated loss of efficiency and missed opportunities. Legends that grow up around legitimate PM practices can (and will) do precisely that.

It's almost as if those singing about perpetrating these “rules” should re-brand them as “legends.”

[i] Wikipedia contributors. (2022, April 12). Billy the Kid. In Wikipedia, The Free Encyclopedia. Retrieved 19:38, April 16, 2022, from https://en.wikipedia.org/w/index.php?title=Billy_the_Kid&oldid=1082234887

[ii] Ibid.

[iii] Ibid.

[iv] Ibid.

Psychiatrist Eric Berne’s best-selling book Games People Play (Grove Press, 1964) had a profound impact on the way many people tended to evaluate the behavior of others. After introducing his theories on “Transactional Analysis,” Berne goes on to describe three dozen “games,” which are essentially attempts by those “playing” them to engineer circumstances and manipulate people into recreating scenarios that would lead to an anticipated emotional payoff. My main takeaway from the book is that, while such “games” are almost certainly being played, the hoped-for payoff is perhaps a bit more nuanced. I think the power of the sought-after payoff from the game can be divided into one of two bins: people so engaged are either trying to (a) reproduce the conditions of a previous, traumatic failure, in order to set it right by now making the “correct” decision(s) and escape the regret attached to that episode in their lives, or else (b) are recreating the conditions of a previous victory, confident that their earlier choices will once again produce successful results, along with the emotional reward that comes with it.

Meanwhile, Back In The Project Management World…

Translating Berne into a business model vernacular, we get a perfectly acceptable mode of behavior and operating: people influencing Team members and circumstances to implement a specific management strategy, with the anticipated payoff of a successful project. This person is either (a) using a business model known to have failed in its previous iteration, but will now succeed due to some key changes or modifications, or else (b) recycling a business model known to work in an analogous situation. Now, that all having been stipulated, I believe that there are Berne-like “games,” or canned, go-to strategies that many PMs employ in situations where they are clearly inappropriate, yet the playing PM is convinced that they are on-track for an economic, emotional, or even power payoff at the strategy’s conclusion. In Games People Play, Berne used clever titles (“Let’s you and him fight;” “If it weren’t for you;” “Wooden Leg”) for his games. Since he’s waayyy smarter than I am, I’ll employ the same technique.

“My Black Box: None Other!” In this game, the PM changes or introduces a new software platform that will be performing the project management-oriented cost and schedule performance analysis, specifically the Critical Path and/or Earned Value Methodology software, though sometimes this could include a system that pretends to function as a performance analyzer, but isn’t. In this latter category, so-called “action item trackers” are common. Nominally, this isn’t an issue, but can quickly become highly problematic when such choices are based not on an even-handed analysis of the best fit for the current PMO, but on previous experiences with projects that really have nothing at all to do with the existing organization or scope. The game proceeds as the PM procures the preferred software, installs it on the Project Team members’ computers, arranges for training, fires the metaphoric starting pistol, and then…nothing significant happens. Sure, he’ll get his project reports in his preferred format(s), but no noticeable change occurs in actual project performance. The PM playing the MBBNO game will then blame the members of the Project Team for not implementing this preferred “solution” correctly, making it appear that others are responsible for any failures.

“Assign Easy Work To Favorites, Impossible Work To Scapegoats.” The title of AEWTFIWTS pretty much says it all, but it’s worth examining, if for no other reason than to recognize when it’s happening within your PMO. If the PMO is more concerned with advancing certain favored people rather than maximizing the number of projects being brought in on-time, on-budget, then it will behave in such a way as to protect the reputations of those people at the expense of performing well with the more difficult scope. Truly talented PMs, when handed problematic projects, will often demonstrate their ability by bringing in disaster-headed work to marginally acceptable results, whereas the being-carried PMs will have the same results with rather simple scope to execute. If the entire portfolio appears to be performing at a just-acceptable level, the head of the PMO may be engaged in this game.

“Now I’ve Got You, You (Very Bad Term).” This is a derivative of one of Dr. Berne’s games, but in this case it involves a scenario where a genuinely talented PM is being overly scrutinized by colleagues to see if she violates any of the rules laid out in procedures or policy documents. Almost always carried out by the Maccoby archetypes of Company Man and Jungle Fighter, the ones playing this game aren’t as interested in actual project success as they are in maintaining a highly controlled hierarchy. If NIGYYVBT is being played in your organization, the very latitude of action the Project Teams need to succeed is being curtailed, and it’s not because those doing the scrutinizing have overall portfolio success as their objective.

Now, if any member of GTIM Nation is tempted to tape a hard copy of this blog on an offending manager’s door, I would advise against it. The three games I reviewed are just the tip of the iceberg, and there’s another little game out there I refer to as “We Only Pretend To Encourage Open Communications.”