Game Theory in Management

Lots of pixel ink has been spent attempting to define Leadership (ProjectManagement.com’s theme for October), typically as a preamble to instructing those who do not come by those qualities naturally on how to acquire them. I think such trains of thought are on the wrong track, particularly when the discussion turns to whether leaders are born into the role, or if they learn the necessary characteristics over time (i.e., are “made”). As GTIM Nation knows, I have previously laid out the three characteristics that I believe are central to the success of anybody who aspires to the role of managerial leadership, so:

• The managerial leader must be knowledgeable enough in their field to identify the optimal technical approach to resolving the scope being pursued by the Project Team or organization. Inept leaders soon find themselves with few or no willing followers.
• The managerial leader must care about the organization they have been assigned to head. The manager who does not care about the people working for them (or worse, holds them in contempt, or believes them to be basically interchangeable) can’t help but let such an attitude slip in front of their charges. Once the organization or Project Team knows that their leader doesn’t care about them, they will cease to care about the leader, as well as pursuing his technical agenda.
• The managerial leader, after having correctly identified the optimal technical approach to the organization’s mission, must be willing to invest her own energy and time to pursue it, alone if necessary. The brilliant Nassim Taleb describes this as “skin in the game,[i]” but my favorite metaphor for this characteristic has to do with World War II general George Patton. I’m fairly confident that, had Patton not been put in charge of the U.S. Third Army, and had instead been parachuted into the middle of Europe circa 1943, he would immediately begin attacking members of the Axis Powers, and not wait (nor whine) for whole armies to back him up.

A key component of this last bullet is courage. The willingness to pursue strategies that are derived from novel approaches to problem resolution will almost certainly draw criticisms from those who have previously tackled analogous problems in a different manner, and often these criticisms can become positively cacophonous. The problem, of course, is that novel approaches to problem resolution that are actually sub-optimal, or even flat-out wrong, will also draw criticism, meaning that the virtue of courage in managerial leadership is immediately converted to vice when the first bullet, having the technical expertise to correctly identify the optimal technical approach, is given short-shrift, or ignored.

Meanwhile, Back In The risk management (No Initial Caps) World…

With all of this as a backdrop, let’s take a look at the actual mechanics of developing a risk management plan or project risk analysis. The risk analyst, with Work Packages in hand, interviews the Subject Matter Experts on the Project Team in order to ascertain

• Potential impacts
• …of potential occurrences
• …expressed in amount of time added to the Schedule Baseline,
• …or resources added to the Cost Baseline.

Keep in mind that only in rare instances are the SMEs involved with the actual Scope Baseline also trained cost or schedule estimators, meaning that, even if they somehow have insight as to the odds of an in-scope, uncosted event occurring, they can only guess at the figure for the cost/schedule impact of said event. To quote the late Michael Crichton, guessing at parameters in a structured formula is simply an exercise in expressing our own prejudices. Also keep in mind who these SMEs are – members of the existing Project Team, and usually not the PM’s superiors. In other words, the entirety of the risk analysis is essentially to produce an expensive document of the PM’s organizational inferiors speculating on what could go wrong with the selected strategy, and substituting their prejudices for usable data parameters in order to add credence to the whole exercise.

Do I have to say it? This is not how leaders in general develop their strategies, nor how Project Management leaders in particular produce and pursue a technical agenda. Indeed, to allow a risk analysis to drive (or even influence) the production or pursuit of a given technical agenda is to allow the vague and poorly-quantified worries of those within the existing Project Team to determine the path forward, the precise opposite of leadership.

Engage the risk managers if your customer insists that you do so, but feel free to only pretend to ingest and respect their “analysis.” Then you can get back to doing real PM stuff, including leading.

[i]Taleb, Nassim, Skin In The Game, Hidden Asymmetries in Daily Life, Random House, 2018.

As GTIM Nation knows well, I maintain that Project Management Information Systems (PMISs) in general, and Earned Value Management Systems (EVMSs) in particular, serve two primary purposes:

• They put into the hands of the organization’s decision-makers the information they need to make, well, informed decisions, and
• They provide an audit trail to help explain the reasoning behind the multitude of decisions made during the execution of a project, for the purposes of creating a lessons-learned document, or for other, more nefarious evaluations.

It’s these more nefarious evals that drive a particular business model pathology. Since the Earned Value and Critical Path Methodology information streams provide a window into how projects are performing, and clients can respond generally either in a positive or negative fashion, the four possible scenarios can be evaluated using the Game Theorists’ favorite tool, the payoff grid:

Since Scenario 1A almost never happens, at least not to customers who are actually paying out money for the Cost Baseline as agreed-to (Firm Fixed Price Contracts are a different animal, but this is still a rarity, since poor-performing FFPs are likely to finish late). Even if they present as being content in the Project Review Meetings, you can bet real money that, the nanosecond they leave the presentation, they will be seeking means of extra-project remedy.

As for Scenario 1B, consider your own reaction when, say, you learn that a long-awaited and highly-coveted item is to be delivered to your home, and your on-line tracking app tells you it will be delivered two days earlier than originally scheduled. You’re thrilled; but, when the new, early date arrives, and no delivery takes place, how do you feel? Are you not keenly disappointed, if not furious? The shipper would have been better off in customer retention space if they had never asserted an early date in the first place since, had they not done so, and managed to have the item arrive just one day early, you would have been much happier, no? But now, after they’ve “promised” the item two days early, and failed to deliver it then, if they do manage to have it arrive one day early, all of the good will that would have been nominally generated has been blown to smithereens. In short, providing good cost or schedule performance information to the customer can be a mixed bag.

I’m going to jump to Scenario 2B, for reasons that will become clear. Some clients are inherently difficult to please – if the customer reacts in a negative fashion when things are going well, the Project had better finish with stellar performance figures. Otherwise, your organization will be vulnerable to the kind of narrative review that usually accompanies poor performing projects.

Finally, when you hand over the Earned Value and Critical Path reports that show precisely how badly your project is performing, and brace yourself for the inevitably reaction, one thought simply cannot be avoided: If I don’t have to, why should I give up this information?

I’m going to score Scenario 1A as a 0.5, due to its rarity, and Scenario 1B as a 0.75, per its explanation. This means that, based on our Payoff Grid, an advantage to providing the customer accurate cost/schedule performance information only scores a 1.25 out of 4.00, meaning, in Game Theory space anyway, it’s a bad idea to volunteer it if it’s not contractually required (which is, no doubt, why Earned Value and Critical Path-based reporting are so often contractually required). Which leads us to the fourteen most terrifying words in the PM lexicon, sometimes uttered when (1) the PM realizes that there’s a downside to volunteering accurate cost/schedule performance information, and (2) the PM thinks the customer will put up with squelching said information from being passed along: “It costs as much as it costs, and takes as long as it takes.” To be sure, this is a fairly accurate statement for many a high-tech project, where no reasonable basis for forming a cost/schedule baseline nor assessing percent complete exists. But for all other projects, The Fourteen Words imply something far more disturbing: your PM does not perceive that he is beholden to the customer’s expectations of cost or schedule performance. The reason I’m bringing this up in September, with ProjectManagement.com’s theme of Agile/Hybrid PM, is because invoking an Agile or Hybrid Project Management approach or strategy can often be used in lieu of The Fourteen Words, and that’s truly unfortunate. A simple Earned Value system can easily provide accurate cost performance and at-completion forecasts, even in Agile/Hybrid environs, and anyone who tells you differently is, well, wrong.

Or perhaps they’re just trying to avoid providing such information without actually uttering The Fourteen Words…

When I was a younger manager, and would find myself in a meeting with peers and superiors where some notion would be put forth that struck me as singularly dopey, only on rare occasions could I resist the temptation to point out its failings. The vast majority of the time I would be quick to point out the ideas’ flaws, typically using rather direct language to do so. Some people would appreciate my honesty and insight, but the majority would resent the daylights out of me. At the time I felt strongly that I had an intellectual duty to my employer to point out the follies of those who would set the technical agenda for a given project, but clearly lacked the experience, education, or intellect to do so. It wasn’t personal – to me, it was always business, and doing PM right is serious business.

After a while it finally penetrated my thick head that, while dopey ideas would always be presented in such meetings, and would often seem to gain some level of traction with participants, I didn’t necessarily have to be the person to point out the folly. I belatedly began to realize that, if little ol’ me thought that what was being expressed was dumb, in a room of intelligent people the odds were pretty good that at least one other person thought so, too, and that person could probably convey the rational opposition better than I could.

Meanwhile, Back In The … Hey, Wait! We Never Left The Project Management World!

Seasoned members of GTIM Nation know all too well my rejection of risk management (no initial caps) theory, since I have regularly referred to its modern-day practice and techniques as openly fraudulent management science. Rather than go back over my (rather lengthy) list of reasons why risk management (no initial caps) as currently practiced is a monumental waste of time and money, I’m going to restrain my poison-pixel pen, and let the Agile/Scrum approach (ProjectManagement.com’s theme for September) aficionados take over.

First off, consider how Agile/Scrum PM got its moniker in the first place. According to Dictionary.com, the first three listed definitions of “agile” all have to do with being “quick,” or “active.”[i] It’s pretty clear to me that naming a PM strategy “agile” in the first place emphasizes its ability to spontaneously adapt to changing circumstances, in a way that demonstrably surpasses traditional Project Management techniques. In essence, rather than spending the time and money to develop a risk analysis document, and use it to generate the risk management plan, using decision tree, Monte Carlo, or wild guesses expert opinion in an ultimately vain attempt to quantify the future, Agile/Scrum addresses programmatic risk by relying on the Project Teams’ abilities to recognize problems and, ahem, deal with them. It really is that simple. It’s also why you won’t see risk experts performing their kabuki theater analysis techniques on software projects. Information Technology PMs know which aspects of traditional PM will help them bring their scope in on-time, on-budget, and risk management doesn’t make the cut. Yes, I know that Agile/Scrum’s main claim to fame is its ability to effectively streamline the configuration management cycle in such a way as to not introduce a vulnerability to that most lethal yet insidious of project-killers, scope creep. But I also know that it’s worth pointing out that, of the traditional vestiges of PM that were notably left out of the new paradigm, risk management (no initial caps), once considered one of the four “core” chapters in the PMBOK Guide®, has to be the most conspicuous.

In fact, back when I was doing my column for PM Network, I did a piece entitled “PMBOK, Schmimbok,” (PM Network, January 2007, pp.14)[ii] where I discussed the appropriateness of each of the then-chapters of the famous PM guidance. I challenged the notion that communications, quality, procurement, human resources, and (of course) risk were truly germane to project management, as opposed to any other kind of management. Flash forward to 2020, and what does Agile/Scrum do with each of these? Communications and quality are still major components, but specifically modernized for Information Technology projects’ environs, while procurement, human resources, and risk have fallen off the back of the epistemological truck altogether.  None of this is to say that each of these disciplines isn’t a vital aspect of conducting business; rather, I’m only challenging if they belong in a PM model streamlined for IT projects that, by the way, actually works pretty well.

So it would seem that all of that time I’ve spent challenging the risk managers’ (no initial caps) worldview on its merits was unnecessary. All I had to do was to await the more streamlined, agile variants of PM to gain traction, and merely note that they had jettisoned risk management (no initial caps) theory in its entirety. At the massive conference room table of PM codex development, I could have just shushed, and let the more intelligent and outspoken people take up the challenging of the dopey ideas while enduring the resentment of those who disagreed.

And it happened! I’ve been rescued by Agile/Scrum!

[i] Retrieved from https://www.dictionary.com/browse/agile?s=t on September 20, 2020, 20:-2 MDT.

[ii] http://www.pmnetwork-digital.com/pmnetwork/200701?pg=26#pg26

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.