Game Theory in Management

In last week’s blog I listed the three key characteristics of a managerial leader, and then wrote about how the risk managers’ (no initial caps) agenda actually undermines that function. This week I would like to take that a step further, and discuss how to avoid attaining a leadership position by means other than through merit. I’ll begin by addressing the three easiest red-flags, derived from last week’s blog. To wit, if:

• You are not pursuing the optimal technical approach to the problem in front of the team, or
• You feel indifference, or even contempt, for the people on the team, or
• You have no skin in the game, i.e., no apparent personal stake in the successful outcome of the organization’s work, then…

…you may have arrived at the leader role for reasons other than merit. The next set of clues are a bit more subtle, but can be just as telling.

Consider what tends to happen when a garden variety new manager is brought in to an existing organization. The newbies typically have an expectation that the organization’s current performance is the baseline, and things will only get better now that they are there. Working from this assumption, take a look at what probably presents as the biggest threat, that their new technical agenda will be thwarted or frustrated by uncooperative extant personnel. For this reason, whenever a new manager comes into an organization, the tendency may be to attract, find, and reward loyalty, not talent. Why should talent be an issue? The organization was clearly performing at an acceptable level prior to the newbie arriving, and the newcomer represents an influx of talent, right? So, upmost in at least some rookies’ minds is to move through the Tuckman’s Stages of Group Development dynamic, specifically

• Forming
• Storming
• Norming
• Performing

…in such a way as to minimize the Storming phase. The newcomer may desire a return to organizational stability, with a subsequent cruise on into Performing space.

Here’s the problem with this entirely predictable, but strategically unsound approach: with the exception of replacement scenarios, the whole reason a new manager was introduced in the first place was usually because the target organization’s performance was disappointing, or even unacceptable. If the characteristic being sought out and rewarded is loyalty, then odds are that things are about to get worse. GTIM Nation knows of my respect for the brilliant Michael Maccoby, and his book The Gamesman, The New Corporate Leaders (Simon and Schuster, 1976). By attracting and rewarding loyalty rather than talent, the Maccoby archetypes that will succeed are the Company Men and the Jungle Fighters (who will feign loyalty), all at the expense of the most talented archetypes, the Craftsmen and Gamesmen. Put simply, this is an extremely hazardous transition strategy. With Company Men and Jungle Fighters placed in positions of authority over the Craftsmen and Gamesmen, the odds of arriving at the optimal technical approach – the very first characteristic of the managerial leader – have plummeted. Indeed, members of the latter two archetypes will tend to flee such organizations, likely to be replaced by more “loyal” team members, i.e., Company Men and Jungle Fighters. From an organizational behavior and performance point of view, this can easily become an unmanageable morass.

I mentioned last week that, in addition to the three essential characteristics for managerial leadership, an additional element – courage—was also key to success, and here’s another area where that becomes a factor. It takes a good measure of courage for the newly introduced manager to listen to those in the organization who may disagree with them, and to patiently and even-handedly review their criticisms’ validity before rejecting them and attributing their motivation to a lack of respect, or even insubordination. In short, newbie managers who aspire to legitimate leadership roles should never fear the Storming phase from Tuckman’s Stages, and instead use it as an opportunity to gauge which members of the inherited team are both talented, and have a personal stake in a successful outcome, the proverbial “skin in the game.” So, what’s the litmus test for whether or not criticism from the Project Team represents a legitimate technical approach alternative, or simply snarky opposition? If it’s not clear based on content, consider if the criticism/recommendation was intended to benefit the entire team, or just a subset (or even the critic alone). If it’s the former, it could well be legitimate. If the latter, not so much.

I would think it rather impossible to advise on how to become a leader in an 800-word weekly blog. But I do believe that such a venue does support relaying tips on how to avoid finding yourself in the role without a few foundational elements in place. In short, don’t become a non-leader.

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.