Game Theory in Management

One of the reasons I prefer episodes of Star Trek (the original series, or TOS) over Star Trek: The Next Generation (TNG) has to do with the writing of the former. The original series was far more likely to use traditional plot structure, typically including:

• Introduction to a major and (at least one) minor problem,
• Rising action,
• Climactic scene(s) where the major and minor plots are resolved, usually through some sort of conflict, that the protagonists must reach deep into their talents to attain,
• And a denouement, where we get a sense of what can be expected to happen to the protagonists going forward.

ST:TNG, by contrast, often employed an infuriating plot device which was essentially a derivative of the often (and appropriately)- derided technique of deus ex machina. Deus ex machina is an ancient trope, and gets its name from Greek plays where some “god” would be literally craned onto the stage at the climax, and use their super powers to set everything right. In futuristic iterations these derivative plots depended on the intercession of the goddess “communications,” and were structured so:

• Introduction to a major and (at least one) minor problem,
• Rising action,
• Climactic scene(s) where the major and minor plots are resolved, not through conflict or the protagonists needing to reach deep into their talents, but via the sudden realization that a breakdown in communications had occurred, the antagonists are really good guys, and we just all had a massive misunderstanding.
• The denouement, where the characters feel really good about themselves for “finding” a resolution to their problems that didn’t involve conflict.

Antiphanes was one of the earliest critics of this plot device, showing that even in 340 BCE the idea was already considered vacuous.

Meanwhile, Back In The Project Management World…

I’m not sure anyone else has noticed, but one of the central tenets of Agile/Scrum PM directly challenges one of the central tenets of Communications Management, that of whether or not it’s a good idea to engage all stakeholders when discussing project particulars. According to Paradigma, at the daily scrum meeting, the Product Owner, Scrum Master, or “any Stakeholder” may attend, but only as listeners.[i] I had previously criticized the “engage all stakeholders” idea as a poor tactic on the grounds that it’s always at least somewhat likely that, among the set of “stakeholders,” can be expected to be people who are neutral with respect to your project’s success, or even hostile to it. The Agile/Scrum world appears to be resistant to the same tactic, but for different reasons.

Recall that Agile/Scrum came into existence due to the fact that software development projects tend to be so dynamic that the more traditional PM methods for changing the project’s baselines (scope, cost, schedule) would be too slow to adequately respond to the newly-discovered (or realized) elements of the project that would have to be addressed in the short-term. Since scope creep is easily as lethal to Information Technology projects as any other, some form of change control had to be retained, just one that didn’t involve Baseline Change Control Boards meeting once per month, and only then passing, failing, or passing-with-conditions the proposed changes. The novel (and, apparently, successful) approach involved severely restricting specific types of communications, based on the roles of the people making up the stakeholder set.  Indeed, one of the particular reasons that certain members of the stakeholder set are not allowed to speak at the daily scrum meetings is to prevent the Product Owner from controlling the Development Team[ii]. The way I see it, the employment of specific rules regarding who may or may not communicate during daily scrum meetings is a tacit acknowledgement that many (if not most) of the technical difficulties encountered in IT projects have nothing to do with a lack of communication; rather, they represent genuine problems which must be overcome by the Project Team reaching deep into their talents, and overcoming them.

The stage, therefore, is set for GTIM Nation to reach into their accumulated talent and experience base, and overcome the central problem of so-called communications experts having their inane ideas infiltrate the codex of PM techniques and strategies, at least where Agile/Scrum is concerned. Rather than wait for one such expert to explain to me how I am a participant (or even “stakeholder” – get it?) in some massive misunderstanding, I think I’ll just set phasers to “stunningly insightful,” and lock them on target.

[i] Retrieved from https://en.paradigmadigital.com/techbiz/the-7-most-common-mistakes-of-the-daily-scrum-and-how-to-avoid-them/ on September 14, 2020, at 14:31 MDT.

[ii] Ibid.

Excuse me for asking the most obvious question in the room, but I simply must. Consider Generally Accepted Accounting Principles, or GAAP. Would you invest in a company that stated in its prospectus that it had adopted a “hybrid approach” in developing its profit and loss statement?

Of course, Management Science in general, and PM in particular, is always changing, evolving in ways to deliver the structure that will change perspectives, update managers’ points of view, and enable (in our cases) the optimal PM strategies that will maximize the odds of bringing in our work, on-time, and on-budget, and I am absolutely not positing that this type of scholastic/intellectual churn should cease, or even become less brutal. That’s the way of business. But what does alarm me is when combinations of such structures or strategies are furthered with little more than a tentative claim to being a “hybrid” of already-established approaches representing their claims to legitimacy. Let me explain by picking on a favorite target, our friends the risk managers (no initial caps).

From my perspective the risk management afficionados made a huge splash around the turn of the millennium, claiming that their approaches to quantifying managerial decisions through statistical analysis of sheer speculations projections of possible future events would enable a significant leap forward in effective PM. My takeaway from the literature at the time was not so much that they were presenting a “hybrid” approach as much as they were positing that an overlay of risk management onto existing PM structures would represent a dramatic improvement. In a Point/Counterpoint article that appeared in PM Network[i], I pointed out to David Hillson that, by his definition of the term, nothing that occurs within the management world could be said to fall outside the purview of “risk management,” a position I maintain to this day. (If any member of GTIM Nation looks up the article, the photo of me is atrocious. Yeah, I must have provided it, but still. Fortunately, ProjectManagement.com has a far better picture, up and to the left of this blog.)

It didn’t take long, however, for several of the guidance-generating organizations to develop a “risk-based” approach to PM, and for this dribble to gain traction in the business publications world. And what was the ultimate effect of “risk-based” PM hypotheses? That, if your project could be classified as “low-risk,” you had license to dispense with several traditional, yet indispensable, aspects of setting up your Project Management Information Systems. Did this qualification of PM information system rigor lead to a noticeable uptick in the number of projects that came in on-time, on-budget, with risk-based PM being the proximate (or even material) cause?

No. No, it did not. In fact, quite the opposite happened, as many environmental projects that should have been conducted with a fairly robust PM information systems were allowed, instead, to report using fairly basic ones, leading to a net loss of PM capability maturity across this particular portfolio. Flash forward to today, and a similar effect appears to be underway with respect to addressing the question of required PM information system rigor by pointing to an approach that represents a “hybrid” of traditional PM and Agile/Scrum, should the subject project have anything at all to do with Information Technology, or IT. The Agile/Scrum approach to PM, of course, was developed specifically for software engineering work, where the particulars of some parts of the scope were either unknown (or even unknowable) or too imprecisely defined to be properly managed, and would require a faster resolution to updating or refining than the traditional Baseline Change Control Board could provide. This approach appears to be working: according to PMI® research, software projects coming in on-schedule have jumped from just 55% in 2013 to 80% in 2018.[ii]

But when the discussion turns to creating a viable ”hybrid” PM approach, flanging up “traditional” with Agile/Scrum, this sets off alarm bells in my head. All too often there’s no precise delineation of the particulars of which aspects of cost or schedule performance will be conducted by which approach. To move from the abstract to the more concrete, consider the following example. If you are the PM of an IT Project, a good way of portraying a hybrid approach would be to start with a few definitions, as in:

• A “daily sprint” is analogous to an “activity,”
• A “sprint” will be treated as a traditional “Work Package,”
• An “increment” is essentially a “Control Account,”
• And an “epoch” will function the same as a “Major Task,” or even the total product.

As long as each of these components retain their established (or establish-able) parameters of a clearly-defined scope, budget, and time-frame, this can work. One more indispensable piece will need to be developed: In the Work Breakdown Structure, identify which WBS elements will be managed via which structure, and ensure no mixed-approach Increments or Control Accounts exist (i.e., when viewing the WBS, no “traditional” Control Account has children identified as “sprints,” and no “Increment” is parent to a Work Package). This approach-identifying WBS is going to be the best guarantor that a given piece of scope is not being given short-shrift in its level of PM rigor. The reason for forbidding cross-approach Increments or Control Accounts is to ensure that, when cost/schedule performance data is being rolled-up through the WBS, that information doesn’t become muddled or confusing, and therefore misleading.

At its core, PM Information Systems exist to show how specific parts of the overall project are performing, so as to provide an indication where finite managerial attention needs to be focused. So, as long as these “hybrid” approaches don’t interfere with that basic function, I’m completely good with the introduction of such mixed structures.

However, whenever they do not do so, then “hybrid” equals “danger.”

[i] Hatfield, M. & Hillson, D. (2008). Danger ahead?: Some project managers contend there's a silver lining in risk management; others say it's called opportunity. PM Network, 22(3), 76–80.

[ii] Retrieved from https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf on September 7, 2020, 17:42 MDT.

Yeah, I know it’s one day past August, with its ProjectManagement.com’s theme of communications, but there’s one more salient point I want to make. It has to do with non-verbal communications, but don’t worry – I would never send GTIM Nation members down the highly-subjective path of trying to interpret body language nuances or motions differentiated by the slightest of degrees (did she just cover her mouth with her left hand, or was it just past her chin?). No, this variety of non-verbals is much more blatant. In fact, it’s almost unavoidable. This set of communications has to do with the presentation style and types of arguments used to establish credibility within the PM world, but they both ultimately communicate the same thing: the speaker is incompetent, but is desperate to hide it. First under the microscope: appeals to irrelevant things or ideas.

Like everybody else in the Universe I have had occasion to work with people on a team effort where some disagreement about how to proceed would come up. In trying to understand and work through those differences, some people would be asked to explain where they were coming from, and they did just that: literally. Instead of discussing the PM strategy or technique at hand, they would talk about their travels overseas, as if getting one’s passport stamp automatically imbued them with PM insights. I guess they believed that the appeal of a cosmopolitan experience and its association with a broader, more enlightened knowledge base somehow advanced their take on management science in a more local setting. Do I have to say it? If your argument is supported by little more than material that is barely above home movies taken on vacation, then your assertions probably don’t belong in a managerial setting. By appealing to something so completely irrelevant to the topic at hand in order to persuade (or bully, really) others, what’s being communicated is clear: these people lack competence.

Next up is any appeal to who a person is, or has studied under, or is related to. We’ve all been subject to people who can’t keep from trying to showcase their credentials and, while irksome, isn’t necessarily an indicator of a complete lack of practical skill. It’s only when the technical discussion gets heated, and any of the participants suddenly swerves to what they believe is their social or academic rank that the incompetency alarm bells ought to go off. Examples of this kind of appeal to status are so common that I’m sure GTIM Nation has seen them regularly. The only thing that I tend to take away from such assertions is that the person making them isn’t confident in the technical merits of their assertions, and would really rather not have anybody evaluate them too closely.

Finally, there’s a certain bombastic, belligerent way of delivering a message, particularly when it comes to the implementation strategies proposed for Project Management Information Systems, and especially those predicated on either the Critical Path or Earned Value Methodologies. I’m well aware that many in our industry can be passionate and aggressive in their presentation styles, and I absolutely do not mean to cast aspersions on everyone in this category. But I would like to draw GTIM Nation’s attention to a very specific subset, that of those who are given to both passion and aggression, but layered with a heavy dose of condescension, along the lines of everybody-who-disagrees-with-me­-is clearly-an-idiot. The use of arrogant condescension, coupled with an aggressive delivery, is very off-putting to most people, and most people will also tend to avoid confrontations in a professional negotiation setting. The condescending person will use that tendency to their advantage in order to hide their incompetency, their failure to understand that the way PM Information Systems are actually implemented is a very different subject from their efficacy once in use.

Project communications grounded in legitimate premises and logically-derived conclusions do not need the well-travelled, the high-ranking, or the condescending to present them in such a way as to influence the Project Team. If you see any project communications presented in these ways, just ask yourself: what’s really being communicated here?

When discussing project communications (ProjectManagement.com’s theme for August), the so-called experts tend to spend a lot of time focused on the identities of the senders and receivers of the information. I think this whole discussion can be brought to an appropriately brief conclusion via the use of Game Theorists’ favorite tool, the payoff grid:

The communications experts I’ve read seem to spend a lot of time worrying about the scenario in the lower right hand block, which leads them to go on excessively about the “need” to expand outgoing communications to ensure it never, ever happens, seemingly oblivious to the fact that that strategy does absolutely nothing for the It’s all good scenarios, and dramatically amplifies the dangerous scenario in the upper left block. Additionally, consider the potential outcomes of the non-It’s all good scenarios. If some communication is withheld from a “stakeholder” who ought to have received it, what’s the worst that could happen? That the project isn’t a recipient of some sort of insight that might have helped it perform better? Now consider the potential downside of communicating relevant project information to an Inappropriate Recipient, a recipient that, perhaps, seeks to slow down (or even derail altogether) the project. Surely this latter should be considered far more detrimental to the chances of the project’s overall success than missing out on some potential insight. My main problem with the whole discussion, however, is that it completely misses a much larger point – Is what’s being communicated actually valid?

One of my guilty pleasures during the 1980s was watching the prime-time drama Dallas, where the famously Machiavellian J.R. Ewing would often use the ruse of sending out false information to his competitors, specifically Cliff Barnes, in order to induce them to take an action that would ultimately benefit Ewing Oil, if not ruin the competitors in the process. Since oil is a commodity, and commodities are notorious for their seemingly capricious and arbitrary price fluctuations, any piece of data that swerved near insider information could lead to astonishing profits (if true), or ruinously bad decisions (if false). J.R. was a master at manipulating such communications, and it wasn’t through simply lying. In one episode I recall J.R. actually did invest significant resources into an oil field that he knew would not produce, all in order to induce a reaction from the other members of the fictional cartel to which Ewing Oil belonged.

This being the case, what types of Project communications are most vulnerable to inaccuracies, or out-and-out mendacity? Several devious tactics are available to our latter-day Iagos, but the thing about the common tactics is that any PM, or auditors of PMs, knows them, and knows them well. Attempting them in today’s PM-savvy environment would be analogous to bringing your own set of marked cards into a Las Vegas casino, and expecting the dealer to use them – it simply wouldn’t work. So, is there any commonly-used information bit that is also vulnerable to misdirection? Yes, yes there is.

The information bit I’m referring to is the so-called bottoms-up EAC. Yeah, I know GTIM Nation is probably tired of my railing against it, but I’m not going to go back over the reasons why it’s bad information – I’m going to discuss how GTIM Nation members can reveal for themselves when they’re being lied to misled.

Recall the basis for the reliability of the calculated Estimate at Completion, the study performed by David Christensen on Cost Performance Index (CPI) stability.[i] Since the CPI virtually never changes more than ten points once the project has cleared the 20% complete point, a simple comparison of the CPI with its near-cousin, the To Complete Performance Index, can be quite illuminating. For those of you new to Earned Value analysis, the TCPI is calculated so:

To Complete Performance Index = Work Remaining / Budget Remaining

or

TCPI = (Total Budget – Cumulative Earned) / (Total Budget – Cumulative Actuals)

Like the CPI, everything’s going exactly as planned if the TCPI = 1.00. Unlike the CPI, if the TCPI is above 1.00, something’s probably wrong, and more wrong the further you get above 1.00. So, here’s the litmus test for evaluating whether or not you’re being hoodwinked by a “bottoms-up” EAC: If the subject project’s CPI is more than ten points below its TCPI, then any EAC more optimistic than the calculated one is almost certainly false. If you want to be conservative, go ahead and set the “this EAC is nonsense” indicator to trip if the TCPI is 15 or 20 points above the CPI. In any case, if the TCPI is more than 20 points higher than the CPI, then the project isn’t coming in on-budget, or even close.

And if that’s not the communication being relayed, you don’t need to be concerned about the who, you need to worry about the what.

[i] https://www.researchgate.net/publication/237574533_Cost_Performance_Index_Stability_Fact_or_Fiction

Given ProjectManagement.com’s theme for August, communications, and my previous two blogs, Communicating With The Future, and Communicating With The Past, this blog’s title seems almost automatic. And, yes, I will continue to avoid an (extended) discussion of the silliness of the concept of sharing any and all project information with anyone with a claim to the “stakeholder” moniker. So, in the spirit of carpe diem, here’s GTIM’s take on what should be happening with communications management for your Project Team in the here and now.

The most common venue for a PM to communicate the status, issues, and adaptive strategies to her, ahem, stakeholders is the Project Review meeting, which typically occurs monthly. However, depending on one’s point of view, these communications can have very different purposes. Such cross-purpose communications can have highly damaging effects on these project reviews which, in turn, can harm the organization’s ability to consistently deliver projects on-time, on-budget. I will delineate the divergent points of view so:

• Upper management – usually the very people who have set up the project reviews and insist that they take place at least once per reporting period, with full PM attendance – tend to worry about one thing more than any other in project-oriented organizations: that they are sitting atop a project disaster, and no one is telling them about it. These execs have almost invariably attained their positions based on their own ability to deliver projects successfully, and are confident that they can help correct the problems being encountered by their subordinate PMs, if only the execs could learn about them in their early stages.
• Somewhere in middle management (the exact level varies organization-to-organization) and on down to the individual members of the Project Team, the main concern is very different: they want to execute the scope, to the best of their abilities, and would really like to avoid relatively clueless executives hovering over them, monitoring every decision. Such hovering is perceived (rightly, most of the time) as unnecessary interference, interference which can easily hinder the Project Team’s ability to successfully complete the project.

This being the case, added to the fact that it’s been weeks since I last used the Game Theorist’s favorite tool, the payoff grid, we have the following communications-changing scenarios:

I’ll start with Scenario 2B, where the project being reviewed appears to be doing well, but the PM appears to be reluctant to discuss its performance in detail. There’s a reason this presents as counterintuitive to the point of being highly anomalous – there’s something else going on here. Either the PM knows the numbers are optimistic, or perhaps even invalid, or possibly there’s another reason (politics, personnel issues) that project performance-threatening data is being overlooked by the Cost/Schedule systems. Unfortunately, the best strategy here is probably to leave it be, at least for the present time, lest the Execs be seen as meddling in projects that are doing just fine based on the existing data.

Scenario 2A is everybody’s favorite, and, if all of the projects in the portfolio find themselves here, then the project reviews can take very little time out of everybody’s day.

Now we’ll address Column 1, where communications systems undergo their stress-test. There’s a (relatively cynical) standard list of reasons for negative cost/schedule performance that tend to show up in Variance Analysis Reports, including:

• Vendor rate changes
• Equipment or material delivery delays
• Contingency event (in-scope, unplanned)
• Completely unforeseen event (e.g., pandemic)
• Formal scope change that hasn’t been reflected in the baseline yet
• Informal scope change (scope creep)
• Poor performance

If the negative variance being analyzed was due to any of the first five bullets, the PM, in theory, should not have any problems with presenting them accurately and in detail, landing us squarely in Scenario 1A. However, if the reasons for the negative variance(s) has to do with either (or both) of the last two bullets above, the tendency is going to be to go to Scenario 1B, the stuff of executive nightmares. To be sure, the PMs so involved do not wish to generate the nightmare scenario. They’re almost universally convinced that they can get the customer to own up to the added additional scope to the existing baseline, and appropriately increasing the cost and/or duration, or improving the performance of the Project Team, or…

The list of motives for “adjusting” the communications goes on and on, but it ultimately has the same, inevitable result. A problem that could perhaps be corrected if the organization’s leaders knew about it early enough gets submerged in order to avoid a perceived interference, and ends up costing the project, as well as its owning organization, dearly.

The solution? Communications experts should abandon the idea of expanding the number of people who receive information on projects’ performance, and instead push for more honesty to fewer “stakeholders,” particularly the ones belonging to the Project Teams’ organization.

And that’s how communications management can put an end to the Executive Team’s nightmares.