Game Theory in Management

According to SlangLang.net[i], the quote in the title was inaccurately attributed to musician Randy Jackson, a judge on the television show American Idol, presumably condensing the reasoning behind his eminent “no” vote for a contestant. In some ways American Idol was similar to the late 1970’s variety show The Gong Show, where members of the three-judge panel could interrupt the contestant in the middle of their performance by taking a mallet and striking a large gong. I’ve never watched an episode of American Idol, but I have seen scenes from other shows in its genre, such as America’s Got Talent, and I have to admit that seeing people with varying levels of talent performing in front of a team of judges (usually four of them) for a chance to advance towards additional performances and some ultimate prize reminded me of the corporate board room setting, where the director of a new Project Management Office (PMO) would be making a pitch for the other executives to, essentially, manage their work differently. One or two enlightened members of the organization’s upper management have somehow procured the resources to set up a PMO, and its leader must now convince the other high-level decision-makers of its utility. And the responses from those judges executives are often the same as this blog’s title, only expressed in management-ese. When I say these rejections come couched in management-ese, I’m referring to statements such as:

• “Our work is mostly level-of-effort, so any cost or schedule performance measurement system won’t apply.”
• “We can’t create a baseline, because the nature of the work is constantly changing.”
• “We don’t want a ‘full-up’ Earned Value Management System. They’re too difficult and expensive.”
• “Our customer doesn’t require those PM-based schedules or baselines, so why should we?”
• “If you’re going to do PM right, you’ll need to have Scope, Cost, and Schedule baselines, with actual costs being collected at the appropriate level of the Work Breakdown Structure, plus a full-up risk register (no initial caps) and formal Project Review meetings, and we just don’t have the time for all that.”

Of course, none of these objections are valid, as anyone with a gram of managerial acuity can readily attest. But, somehow, they seem to carry the anti-PM narrative forward, planting the seeds of eventual PMO failure. In a way, it would be better if these pseudo-executives would just grab a large mallet, and strike an outsized conference room-placed gong. That way the talent that the PMO director had assembled could just go ahead and find better gigs, rather than waste all the time trying to steer the organization’s business model towards something more rational.

It must be pointed out, though, that, if we PM-types were to be brutally honest with ourselves, much of the resistance towards advancing a Project Management capability within the macro-organization resides with us. Supreme confidence in the efficacy of the PMBOK Guide®, coupled with a dismissive attitude towards all who don’t recognize its utility, almost always produces an implementation strategy that simply doesn’t work. Generations of business school graduates who have been inculcated in the idea that the point of all management is to “maximize shareholder wealth,” or that the only true source of cost information is the general ledger, will rarely accept the new PM-oriented business model paradigms at face value. Nor will these be influenced by the threat of PMP®s tut-tutting resistance to the idea that they must now hire on multiple schedulers or cost performance system professionals. The notion that an organization’s PM capability can be advanced via eat-your-peas-style hectoring is both nonsensical and widespread, much like the reflexive resistance to it among the poorly-educated managerial class.

Adding to this level of inherent opposition from our end of the PM spectrum are those who insist that only robust (meaning, implemented and maintained the way they think it should be done) cost and schedule control systems can ever be considered acceptable, or even tolerable. The truth is that rather simple Earned Value Management Systems can produce powerful information streams, but many self-proclaimed experts relentlessly push for resource-loaded schedules, highly-detailed Work Packages, and few activities employing the milestone estimate method for collecting percent complete data as a bare minimum for all such systems. This, of course, has the effect of making EVMSs more difficult, expensive, and time-consuming to set up and maintain, while feeding into the inaccurate (and unfair) accusation that all EVMSs are difficult, expensive, and time-consuming to set up and maintain. In a very real sense, those who assume the intellectual high ground simply because they are PM-types, combined with those pushing for only thoroughly robust system implementation, are doing the rest of the PM world a huge disservice.

No wonder all of those outsized gongs are being installed in corporate board rooms.

[i] Retrieved from https://www.slanglang.net/memes/thats-gonna-be-a-no-from-me-dawg/ on February 21, 2022, 10:56 MST.

Sodium thiopental, marketed as Pentothal, is a drug that was used as anesthesia in the United States way back when I was having my wisdom teeth removed. For a long time it had the nickname “truth serum,” and when I was administered it I quickly found out why. It’s a good thing my oral surgeon and his assistant had my mouth propped open and full of gauze and instruments for the procedure – I would have told them anything they wanted to know, had they asked. To this day I’m not quite sure why. I seem to remember an overwhelming urge to be accepted by these two relative strangers. Also, I didn’t feel any pain.

Meanwhile, Back In The Project Management World…

Now, Pentothal’s use as a means of extracting an accurate account from a reluctant person has been reduced to near-elimination, with critics equating its use for this purpose as torture. That having been said, I must admit to being occasionally reminded of my experience with Pentothal during monthly project review meetings, particularly in those cases where the project being reviewed is passing cost and schedule performance data indicating that it’s clearly in trouble, but the PM is unwilling to own up to that fact. Sometimes they will seek to avoid any mention of difficulties, no matter how pronounced. An explanation of this phenomena is perhaps best illustrated by the Game Theorist’s favorite tool, the payoff grid, so:

Since every project wants to be in Scenario 2.A., we’ll skip straight to its congruent cousin, Scenario 1.B. Even if the PM perceives he is in over his head and doesn’t mind publishing the nature and extent of the project’s difficulties, this is an undesirable Scenario. It’s something of an admission of failure on the part of the PM, that the particular circumstances of the project were more than a match for that PM’s skills.

Where we get into PM nightmare territory is when there’s a disconnect between the cost and schedule performance information on a given project and that project’s reality. If the system is showing overruns or delays, when everything is really okay (Scenario 2.B.), then the organization’s executives are likely to become involved, potentially making decisions that (a) are best made by the PM, and (b) performance-neutral, or even counter-productive. If the PM didn’t have a problem before, she has one now. Its non-congruent partner, where the project really is in difficulty, but the cost/schedule performance systems aren’t alerting to it, is where “surprise” overruns and scheduling delays originate. And few things will irk a Program Manager more than learning that the projects in the portfolio, which were showing everything proceeding fine, are, in fact, comprised of elements in trouble.

This is where the invisible random flying Pentothal darts come in. In most project review meetings, there will be at least one person who is both savvy in the workings of Project Management Information Systems and is willing to challenge projects that show symptoms of even approaching Scenario 1.A. But to make such challenges, depending on the organization’s particular corporate culture, can be hazardous, even a career-limiting move (the dreaded CLM). I used to think that these challengers were either very brave or extremely naïve, but then I realized there was another possible explanation for people blurting out a truthful observation in an environment where it was dangerous to do so: they may have been injected with a tiny amount of Pentothal. But if it wasn’t administered via hypodermic needle, then how? Perhaps a small dart with its tip dipped could have been employed, but these must have been rendered invisible. Additionally, I noticed that these challengers wouldn’t take on all of the projects being presented in the review, and sometimes more than one person would assume the role of challenger. There must be some sort of randomizing element in the way these darts fly about the conference room.

As to who’s launching all these invisible, random flying Pentothal darts, I may take that up in a future blog, though I must admit to a certain fascination with the idea that PMI® has finally developed a more robust enforcement mechanism than publishing and certification training (I don’t really think they’re doing it. I’m just fascinated with the idea.). For the present, suffice to say that, if you happen to be in a project review meeting, and you are suddenly overcome with the urge to challenge anomalous cost/schedule information being presented in an everything-is-okay narrative, and you are neither exceptionally brave nor naïve, you may have been hit by one of these darts. This could be bad for your career.

That’s why you should beware of them.

“The secret is to work less as individuals and more as a team. As a coach, I play not my eleven best, but my best eleven.”  -- Knute Rockne

It seems to me that much of the discussions on managing talent (ProjectManagement.com’s theme for February) revolves around a simple binary, illustrated in the Game Theorist’s favorite tool, the Payoff Grid, below:

When attracting or retaining “talent,” in those instances where you perceive a member of your Project Team to be talented, and they are, in fact, capable, then it’s all okay. Similarly, if someone wants to be part of your Team, and you perceive that they really can’t contribute, and this person, indeed, would add little or nothing to your Team, then the PM can deal with them on that basis. There’s a great deal of pixel ink spilled on the inherent injustice of Scenario 1.A., where a genuinely talented person has been judged to be unlikely to contribute, and how horrible such misjudgments can be, blah blah blah. I will touch on that shortly, just not in a conventional manner (GTIM Nation expects no less). For now, though, let’s look at Scenario 2.B, where a person has been hired on or transferred/assigned to your Project Team based on reputation, or education, or other factors that would normally point to a “talented” person when that person is not a serious contributor and may, in fact, ultimately detract from your Team’s cohesion and overall effectiveness.

The Impact Of Filter Conditions On Success

Based on the Payoff Grid above, the central question that needs to be resolved is: How to bridge the gap between what the PM perceives as “talent,” and who is actually “talented?” In the instance of Scenario 2.B., the person who has been perceived as talented when they actually aren’t pose a severe danger to your project’s success. These people didn’t attain the trappings of being highly capable without any true merit by accident. In these cases, it is entirely likely that the personnel who present as more capable than they really are belong to the Maccoby Archetype “Jungle Fighter,” who gets ahead via political machinations and skullduggery more than any genuine achievement. If members of this archetype have infiltrated your Project Team, they can (and will) cause major headaches, and can easily ruin your chances of coming in on-time, on-budget.

Let’s go back and re-evaluate the criterion used for assessing “talent.” If those criteria are valid, then it would take a great deal of effort for the not-talented person to join your Project Team. If those criteria are invalid, it’s much easier, as illustrated by another payoff grid:

Scenarios 4.A and 4.B represent the dangers involved when the PM is attempting to attract talent, hence the title of this particular blog. Note that, based on that particular row in the Payoff Grid (#4), what the two danger scenarios have in common is that the hiring manager is using either invalid criteria in an otherwise effective candidate-assessment process, or, in extreme cases, the whole assessment process is invalid. Attracting and retaining a highly-capable Project Team is tough enough as it is; but, if the selection criteria are flawed from the get-go, and sub-capable personnel are added to your Team while talented ones join only through extreme luck, guess what’s gonna happen to your overall capability. Keep in mind, also, that there’s an elevated possibility that these people who presented as capable while not really being so are Maccoby Archetype Jungle Fighters, meaning that overall Team cohesion is on a collision course with some major stress tests.

Circling back to the scenario where a truly talented individual is passed over due to bad selection criteria in the assessment model, what happens to those people? You’re not using them, and they don’t just evaporate. It’s reasonable to assume that they will find a position somewhere, and it’s entirely possible that that somewhere is going to be with your competition, either inside the macro-organization or with its outside competitors. This particular management nightmare scenario, where you’ve made the effort to attract talent but ended up rejecting it, has become a proverbial double-whammy: your ability to accomplish scope on-time, on-budget has been diminished, while your competitor’s has been enhanced.

Want to avoid that scenario? Make it a point to continually re-evaluate the criteria you use to add (or dismiss) members of your Project Team, to test for validity and relevance. Do this successfully, and who knows? You may get quoted in some ProjectManagement.com blog 90 years from now!

GTIM Nation knows of my respect for Michael Maccoby, particularly his book The Gamesman: The New Corporate Leaders (Simon and Schuster, 1976). In it, Maccoby posits four basic archetypes of workers in the corporate world:

• The Gamesman sees his particular industry as a type of game. Because of this, he is more likely to have mastered the “rules,” as well as being more likely to take chances.
• The Company Man tends to assume the persona of the team around him.
• The Craftsman doesn’t care so much about who he works for, but cares a great deal about the quality of his particular output.
• The Jungle Fighter gets ahead through political machinations and deceit more than actual performance.

If Maccoby is correct (and I believe he is), then the savvy PM would gain an organizational behavior and performance insight by correctly identifying which of the archetypes most closely match the members of the Project Team. The problem with placing your team members into bins, though, is that if you make a mistake, the damage to Team morale could easily exceed the benefit of optimal task assignments. What’s the savvy PM to do?

I’m a firm believer in the idea that elements of a person’s speech, from range of vocabulary to tempo of delivery, can reveal much about that person’s level of education, background, and, most importantly, thought processes. The way a person writes can be even more revealing. And, as luck would have it, PMs have access to a regular source of the Project Team’s (or, at least the Work Package and Cost Account Managers’) writings, the Variance Analysis Report, or VAR. For the sake of this exercise, we’ll assume that a particular Cost Account has encountered out-of-threshold negative cost and schedule variances. If your Team’s real-life VARs contain elements of the example styles below, you just might have a reliable identification method for the Maccoby archetypes!

The Craftsman:

Variance Analysis: Both the negative cost and schedule variances are due to the amount of rework required to get the scope right on this Control Account. Whomever agreed to the original scope baseline should have taken into account the fact that the novel technical approach, using largely untested technology, might result in our inability to achieve the reliability and quality standards set out in the Technical Scope Documents.

Corrective Action: We shouldn’t have ever agreed to use an untried technical approach in the first place. But, now that we’re here, we should immediately issue a stop work order to the subcontractor, and complete the work using the traditional engineering approach. We may carry this variance to completion.

The Gamesman:

Variance Analysis: We were aware that the subcontractor’s use of this new technology carried an element of risk with it, which is why this Work Package is referenced in the risk management (no initial caps) plan. It should be pointed out that, had this new technology performed as promised, this Work Package alone would have saved more money than the entire fixed fee amount.

Corrective Action: Simply file a Contingency Baseline Change Request, and reference the entry in the risk management (no initial caps) plan as justification.

The Company Man:

Variance Analysis: Technically, this variance should not have happened. My entire Work Package Team has followed the company’s procedures to the letter, and I have personally surveilled time sheet entries to guarantee that no one has mischarged down to the nanosecond.

Corrective Action: Procedure KHG-10008874-A3Cd, subparagraph E, recommends that, in the event of an out-of-threshold negative cost variance, where the offending WP is referenced in the risk management (no initial caps) plan, that a Contingency BCP be prepared. However, Procedure DIK-877640-H8B4, subparagraph N, states that, simply because an event makes an appearance in a risk register doesn’t mean that it should automatically be considered a change in scope. I will need to consult with company executives to see how they think I should handle this variance.

The Jungle Fighter:

Variance Analysis: Perhaps if some of the members of the Proposal Team – whom I won’t name, out of professional courtesy – were to show more fealty to this company’s standards and stated goals, this variance wouldn’t have happened in the first place. If it weren’t for my friends Ken and Jerry over in Risk Management (of course Jungle Fighters think that the term “risk management” deserves initial caps) we would be in grave difficulty.

Corrective Action: We should prepare and submit a Contingency BCP. If it gets hung up in the Baseline Change Control Board, we could make an emergency appeal to the BCCB’s Deputy Chief, who has a very close relationship with the customer’s representative, if you know what I mean.

Now, this listing of writing styles should in no way be considered definitive. But if you recognize the utility of attracting Gamesmen and Craftsmen, using Company Men where they can contribute best (in secondary or support roles), and getting the Jungle Fighters off of the Project Team, then these stylistic nuances might be your best indicator of those archetypes.

Also, I’ll thank GTIM Nation to refrain from doing exactly what I prescribe in this blog, and identifying my Maccoby archetype based on my writings down in the comments section. I don’t want to risk my reputation of complying with ProjectManagement.com’s directions, after all. If you know what I mean.

I’m old enough to remember when risk management (no initial caps) first wormed made its way into mainstream PM guidance. One of its funniest manifestations was an assertion that, if a given project could assert that it was really, really not risky, then many of the conventional Cost/Schedule performance measurement systems should then be considered superfluous, and therefore not mandated for government work. Of course, non-risky work didn’t need all of that high falutin’ risk analysis performed, at least when it came to making the case for the imposed level of rigor of the Project Management Information Systems (PMISs) applied to the work. Essentially, the early forays of risk management (no initial caps) into the PM world worked to undermine its overall utility, a vehicle for sending those pesky Critical Path and Earned Value zealots packing.

Flash forward to the introduction of Agile/Scrum Project Management. I believe that one of the main reasons that Agile/Scrum received such quick and broad acceptance in the Information Technology (IT) PM world was due to the fact that it addressed a widespread problem in that arena, that conventional configuration management/ change control techniques were inadequate for software engineering scope. A typical Baseline Change Control Board, made up of senior project and customer managers, would meet only once per month. Then, if a Baseline Change Proposal/Request (BCP/BCR) wasn’t considered acceptable by every member of the BCCB, it would be back to the proverbial drawing board to address the concerns of the Board, and a re-submission, to be considered next month. Agile/Scrum represented a way around such an ossified process. The people who were in a position to approve relatively minor baseline changes – the kind that happen all the time in IT projects – could do so in near real-time, and the new scope could be pursued in a far timelier manner, all without inviting the stigma of having a rubber baseline.

What’s a “rubber baseline?” It’s the bugaboo of us traditional PMs, the equivalent of this line from Shakespeare’s Henry VI, Part I:

Is this the Talbot, so much feared abroad
That with his name the mothers still their babes?

To have a rubber baseline means that you can change cost, or schedule, or (by implication) scope informally, almost at will. Variances magically go away, and, with them, the integrity of your project’s cost/schedule measurement systems. To the generation of PMs who still think that quoting Shakespeare is hip, to unknowingly engage a rubber baseline is to self-identify as completely inept, and to do so knowingly is to “smile, and smile, and be a villain.” (Hamlet, Act I, sc. V).

Interestingly, even though Agile/Scrum was originally developed for Information Technology projects, many other sectors have adapted it, including manufacturing. Even so, this approach may not have delivered on its highly-touted potential. According to one source, 75% of IT executives believe that their projects are “doomed from the start.”[i] Naturally, one has to wonder what the proximate cause of this sense of inevitable doom could be – is it hardware? Lack of talented personnel? Sub-standard coffee delivery service? Or could it be … the Project Management approach?

Since both Agile/Scrum and the implementation of a rubber baseline have in common a weakening (or even elimination) of the Configuration Management/Baseline Change Control process, what could we say separates, or distinguishes them? Let’s use the Game Theorists’ favorite tool, the payoff grid:

Members of GTIM Nation will quickly observe that the only okay scenario here is 1A. All of the others represent trouble, either because the project is being run by someone who doesn’t have the awareness that he shouldn’t be using a rubber baseline and, therefore, is likely to crash the project based on sheer ineptitude, or because he’s a villain who has successfully circumvented the very cost/schedule performance measurement systems that would alert his superiors when the project is in trouble. Don’t misunderstand – I’m not arguing against the use of Agile/Scrum in all cases. The brutal truth of the matter is that traditional approaches to maintaining baseline integrity had become moribund for projects being executed in a fast-moving environment, like Information Technology, and some change had to come on this front in order to keep PM relevant in those business situations.

But to remove all of the guardrails of traditional Configuration Management/Change Control, in the name of granting the PM more latitude of action, simply invites a management environment where “you’ll never find a more wretched hive of scum and villainy.” (Yeah, that’s from Star Wars. Were you expecting more Shakespeare?)

[i] Retrieved from https://blog.capterra.com/surprising-project-management-statistics/ on January 12, 2022, 16:47 MST.