Game Theory in Management

When last week’s blog, the one where I relay a story about a “manager” who had a Ph.D. in a technical field, but really didn’t know much about management, attracted more comments than I usually see, I realized I had touched on something of a sensitive subject. For those PM-types who are tasked with heading up a Project Management Office (PMO) with the objective of either advancing the PM capability within the macro-organization, or even introducing PM to the org, a whole host of seemingly irrational issues lie in wait to hinder or even derail your efforts altogether. While these issues may appear to be irrational, they do, in fact, have some rationale behind them, but they’re rather dark. I’d like to spend some time pulling back the curtain on these motives behind the PMO’s opposition. By no means am I guaranteeing a remedy to them – I’m just wanting to do some clarifying. It helps to know your opponents.

Prior to evaluating motives, let’s take a look at some of the more common tactics employed by those who seek to undermine the PMO’s mission. Virtually all of the opposition the PMO Director will encounter will be covert, and yet still highly effective. So, in no particular order, here are some of the ways the opposition will resist the expansion or advancement of PM.

1. The Silent Veto/Slow Roll. Back when I was writing the monthly back-page column for PMNetwork, I had the opportunity to get to know the other columnists, including the brilliant Bud Baker, now a professor emeritus at Wright State University. While researching my first book, Things Your PMO Is Doing Wrong (PMI Publishing, 2008), I communicated with Professor Baker about the phenomena I called “the silent veto.” This occurs when the other members of the macro-organization, especially the highly-placed members, tell you to your face that they’re happy to support your initiatives as you set up your PMO; but, when the time comes to actually do something, they’re strangely absent. Bud offered that his version of the silent veto was called “the slow roll,” which is similar, but with an insidious twist. Those who promise support actually provide some, but not really enough to attain the next level of capability maturity. Instead, these false allies will gauge just how much organizational leveraging would be needed to achieve the next milestone, and simply wait you out. They know that you won’t make it without their robust support, but they also know they can’t be perceived as failing the PM initiative, so they do actually help, just not enough and not in time.
2. The “It’s Too Difficult” Objection. This is one we PM-types kind of do to ourselves. By insisting on a robust PM capability, often without even considering the Quality, Affordability, Availability – pick any two configuration of the organization, those outside the PMO can actually have a point when they assert that the amount of time and energy needed to attain such a state isn’t worth the investment. The infuriating thing here, though, is that I’ve been hit with this condemnation even when the cost/schedule performance systems being proposed were extremely simple, and easy to implement.
3. I’ve also encountered the opposite of #2, the objection that, if the cost/schedule performance system is truly simple and easy to implement, then it can’t possibly deliver accurate or relevant information. Numbers 2 and 3 represent something of the classical Catch-22: if it’s not too expensive, then it’s a cheap imitation of the real thing, which is, by their definition, too expensive.
4. The “Too Small” Dodge. Ironically, the same people who will insist that their project work is too small to bother with a cost/schedule performance measurement system will typically be rather sensitive to overpaying for car repairs. They don’t object to performance measurement on principle, they just don’t think they should be subject to it, hence the old saw “project teams detest performance measurement because it vividly shows their lack of performance.”
5. The Low Risk Parry. A derivative of #4, the manager employing the Low-Risk Parry will attempt to assert that their project work is so routine and template-like that the use of a performance measurement system would be entirely superfluous. GTIM Nation knows of my disdain for risk management (no initial caps), on the basis that it consumes resources but return nothing of value, but this is a case where it’s actually damaging to PM writ large. By employing the risk managers’ (no initial caps) jargon, they are actually arguing against the use of PM techniques. The kicker is that they often get away with it.

Of course, there are other tactics, but in my experience these are the most common. Feel free to add the ones that irritate you the most in the comments section. Next week, in Part II, I’ll seek to reveal the motives of the people who tend to hinder PMs just on principle, and explore possible counter-measures.

They don’t call Project Management “the accidental profession” for nothing. Many of us arrived here from a business or management background, but a lot of us came into this profession via a more indirect route, specifically, through a technical discipline that landed us in front of a new project. And this is where it can get really interesting.

I recall one particular meeting I attended based on an invitation from a high-level executive who suspected his head of Program Controls was doing a poor job. The executive was right. This fellow wasn’t trained in PM – he had a Ph.D. in a technical discipline, and knew just enough PM jargon to insinuate himself into the newly-created slot he occupied. His Team was large, as was the conference room, so I just took a seat in the back and kept my ears open.

“Here’s the problem I want addressed” he began, standing in front of the rather large white board. He drew five large rectangles on the upper third portion of the white board.

“These represent the major program offices” he stated. He then drew about a dozen smaller rectangles in the middle third of the white board, in a different color.

“These are the major projects within the portfolio” he said, as he drew lines both between the mid-level rectangles and the high-level ones. He then drew around twenty small rectangles on the bottom third.

“These represent the organizations that perform the work.” Using another dry-erase marker color, he drew lines between the small rectangles and the mid-sized ones, with many of them reaching to the opposite side of the white board.

“Some of these projects cross programs, and most of them use multiple organizations, often at the same time.” Using yet another color, the lines drawn were proliferating.

“They also use some of the same facilities,” (more lines) “and, in some cases, the projects’ work overlaps with others.” At this point the white board looked like someone had thrown up on it after having eaten a massive amount of spaghetti with Skittles sauce. If he thought he was depicting a desired business model end-state, he was comically mistaken.

“We have to be able to capture all of these entities, and their relationships to each other, in order to create a comprehensive program plan.” The individual Team members, almost all Project Controls Specialist, were strangely silent. I guessed (rightly) that most of them recognized that this manager didn’t know what he was talking about, but were reluctant to offer their opinions about how to properly approach the problem. It wouldn’t be long before I found out why. After the meeting, I approached him, and asked for a sidebar. He knew me by reputation (I had actually trained most of the Project Controllers in this organization), and, after summoning his deputy, we sat in the foyer.

“When you say that you need to capture how the projects ‘overlap,’ that’s typically accomplished with a Work Breakdown Structure, where the scope is delineated in a hierarchical fashion. Which elements of scope belong to which project and program are then clearly defined. When you discuss the need to identify possible overloading or underloading of the resources needed, that’s usually done using a resource dictionary in your Critical Path Methodology software. By assigning specific resources to the activities laid out in your WBS, possible conflicts can be identified and avoided. Finally, the issue of more than one activity or organization using the same facility can be resolved by loading the work’s locator codes into the schedule baseline. Once the schedule baseline is calculated, those conflicts will also be identified.” The fact that I had to tell this fellow such fundamental things about PM was a bit frustrating, and I rather had the impression that he believed his technical Ph.D. should have entitled him to automatic deference in PM matters. I learned later that he was planning on solving his problem by purchasing and employing a specific software package, one based on the Earned Value Methodology. There appeared to be no effort at ascertaining whether or not the package cleanly interfaced with the CPM software, or the general ledger. I came to believe that he had simply seen a presentation by this particular software vendor, and had been sold without a clue of how the package would fit into the overarching MIS architecture – and he wasn’t about to change his mind. I then realized why the room of Project Controls analysts stayed silent – they knew it was futile to reset this fellow’s technical agenda towards something that might actually work.

Don’t misunderstand – I’m not saying a plurality, or even a sizeable proportion of technical Ph.D.s view their PM counterparts as intellectual inferiors. But PM isn’t easy. It’s not rocket science, but doing it right is not easy.

A few weeks ago I was complaining about the fictional Sherriff of Nottingham influencing (or even setting) modern organizations’ business models. This week I want to point out another dubious source of such influence, that being those wretched surveys, or polls.

Family Feud is an American television game show, which pits two teams of (usually) closely-related contestants in attempts to guess the answer to questions previously posed to the studio audience, based on the most popular response, the next most popular response, and so forth. Originally hosted by British actor Richard Dawson, subsequent hosts have included Ray Combs, Louie Anderson, Richard Karn, John O’Hurley, and Steve Harvey. Perhaps one of the most iconic lines that these hosts repeated in each show is uttered after a contestant has offered up what they believe was an audience response. In order to queue the operator of the board to show the correct answer, one of these hosts would call out “Survey says…!”[i] When a contestant’s answer appeared to have absolutely no connection to anything on the board, comedy gold could be had.

Meanwhile, Back In The Project Management World…

All valid Management Information Systems (MISs) have the same basic architecture, with three sequential steps:

1. Collect Data
2. Process the data into information
3. Deliver the information.

First, data is collected, based on some sort of discipline. Accountants, for example, need to know expenses, budgets, and other details about the assets they are tracking in the General Ledger. The data is then processed into usable information based on some sort of methodology. We PM types primarily use Earned Value and Critical Path methodologies. Finally, the information is presented to decision-makers in a format that’s actually usable. Pushing a balance sheet in front of a manager who is unfamiliar with GAAP is probably not the best way to support a business-related assertion.

Unfortunately, there are a good number of so-called MISs that do not follow this basic architecture, the most common invalid alternative being what I’ve nicknamed The Poll. The Poll is basically a central database or data depository, surrounded by input/output nodes. Going under names like “Action Item Trackers” or “Issues Management Systems,” these systems not only fail to incorporate a legitimate methodology, what they collect is often not even objective data. Opinions and unquantified observations can constitute a significant portion of the “data,” rendering these holding largely subjective, and, therefore, unreliable. Indeed, a handy litmus test for whether or not an entry into a poll-structured MIS has any merit resides in the answer to the question, “is this actionable right now?” If the answer is no, then the entry is suspect.

These Polls should not be confused with systems that record events that have already occurred. Lists of accidents or infractions can be informative as long as they’re not being used to try to precisely predict future occurrences. If Plant N has had 1.3 accidents per month that led to at least one worker having to spend time away from work, that can be valuable in assessing the overall safety environment. It’s kind of useless, though, when trying to predict the exact place and time of the next such accident.

The main problem with polls is that there’s always someone with more recent, accurate, or complete “data.” In an attempt to overcome these types of systems’ inherent unreliability, the protocols for access to them are usually pretty loose. Essentially, anybody within the organization who has an “observation,” “action item,” or “issue” can sign on, and make an entry. The more advanced versions of this type of system will accept downloads from scheduling systems that incorporate the Critical Path Methodology, but that simply raises the question, if the scheduling system is the source and residence of this data in the first place, why not just view it in the original?

Then we have the problem of how all of these “issues” or “action items” are to be categorized, or binned. By date, either of occurrence, or estimated resolution? By organization? Place? Project? Severity? No matter how these entries are categorized, some impacted manager will want to see them presented differently, in line with their specific function or area of expertise. Besides, if a worker becomes aware of a problem like an unsafe condition or activity, doesn’t the immediacy of such a situation demand that they stop work and alert those responsible, rather than going to a computer terminal to do some data entry?

Finally, poll-structured MISs have the inherent problem of answering the question “So what?” Randomly submitted “issues” or “action items” will need to be assigned to someone to “correct,” or else be dismissed. Just so we’re clear, random action items getting assigned to PMs is a clear example of the dreaded scope creep, in that it’s a piece of work that is (typically) not part of the original baseline, has not been formally added via the BCP process, but nonetheless has to be accomplished. And scope creep is poisonous to projects.

So, the next time a PM is hit with some “action item” that needs addressing stemming from an information system predicated on the poll model, and flunks the actionable test, that PM should feel free to imagine its contents being spoken by a Family Feud host, after the words “Survey says…!” Because what follows is not really reliable, and well may be better suited to game shows.

[i] Retrieved from https://www.shmoop.com/quotes/survey-says.html on July 14, 2023, 21:34 MDT.

Few things in the management world are as infuriating as having a good, or even great, initiative blown to smithereens by office politics. To be precise, I would like to define office politics as those actions taken by members of the organization that benefit themselves personally, while being neutral or even detrimental to the goals of the group or team with whom they are working. By this definition, office politics encompasses everything from idle gossip about coworkers, all the way to arguing against a course of action, not on technical merits, but because the person (or persons) making the counter-argument have something to lose should that action be adopted. I discussed in last week’s blog the brilliant Michael Maccoby, particularly his book The Gamesman; The New Corporate Leaders (Simon and Schuster, 1976). In it, Maccoby asserts four basic archetypes in the workplace:

• The Craftsman doesn’t care so much about for whom he works, but does care a great deal about the quality of his individual output.
• The Company Man tends to assume the persona of the organization around him.
• The Gamesman, after whom the book is named, doesn’t see his benefits as translating to a roof over his head or food on the table. Rather, he sees his renumerations as some kind of token in a grand game he’s playing. Because of this, he is both more likely to master the rules of this “game,” and be willing to take risks.
• Then we have the Jungle Fighter, who gets ahead through calumny and cloak-and-dagger tactics.

Jungle Fighters are both vile and ubiquitous, and are typically at the forefront of office politics. In an organization of any size, there will inevitably be some, and in those cases where the organization is based on a flawed (or, especially, pathologically flawed) business model, they may even represent the majority archetype. If a member of GTIM Nation finds themselves in such an organization, the only – and I do mean only ­­­­– solution is to get out, and as quickly as possible. For the rest of the business world, where the Jungle Fighter population is more manageable, and emergency disengagement is not necessary, your working life may still be made considerably worse by the presence of these people. What can be done?
First rule of dealing with Jungle Fighters actually comes from Sun Tzu, and The Art Of War, and it is this:

Do not engage an enemy more powerful than you. And if it is unavoidable and you do have to engage, then make sure you engage it on your terms, not on your enemy’s terms.[i]

Unless you are yourself an advanced Jungle Fighter (I prefer to believe there are very few or none within GTIM Nation), you cannot engage them on their terms. They’re too good at engaging in ex parte conversations and calumny, and they almost always get away with it. And, no, I’m not so Pollyanna-ish as to assert that these people can be overcome through sheer comparative accomplishments. Jungle Fighters will typically possess an amazing ability to be perceived as being highly involved in successful projects, and having relatively little to do with struggling ones.

Based on the assertion that these are the Jungle Fighters’ two favorite tactics – calumny and glomming onto successful work while distancing themselves from poorly performing tasks – two counter-strategies can be rather effective, if engaged in a timely manner. Number One: if you are a PM, and a member of your Team wants to discuss another member, stop them immediately, and invite the target to the discussion. End all ex parte conversations dealing with other Team members, their performance, or assignments. This is the Jungle Fighters’ bread-and-butter tactic. Without it, much of their power evaporates away.

Number Two: document your Scope Baseline in detail. Most PMs are familiar with the Responsibility/Accountability Matrix, or RAM. This is a matrix with the Work Breakdown Structure on one axis, and the Organizational Breakdown Structure on the other, so that each Control Account or Work Package in the Project has its performing organizational element identified. Once you have a detailed Scope Baseline arranged in a RAM, everyone’s role is clear. You won’t leave any ambiguity space for the Jungle Fighter to assert a contribution outside of their RAM assignment, nor will they be able to escape an association with a poorly-performing Work Package if, indeed, they were part of that assignment.

The easy strategy, of course, is to simply stay off of the Jungle Fighter’s radar screen, and, if you can accomplish this reliably, then fine. But if you can’t, I’ll leave you with one final Sun Tzu quote:

What is of supreme importance in war is to attack the enemy’s strategy.[ii]

[i] Retrieved from https://www.azquotes.com/quote/548824 on July 10, 2023, 18:16 MDT.

[ii] Ibid.

In the United States, considerable political punditry pixel ink has been spilled on “The Swamp,” the nickname for the layer of bureaucrats whose collective decisions can seem to have a greater impact on public policy than those elected to office. But this hijacking of the authority to make key decisions within the organization is by no means confined to the civic sphere – it’s alive and well in the business sector, as well, and ignoring it only enhances its ability to shape the business model, often in ways that are counterproductive.

How did this management version of The Swamp get here in the first place? GTIM Nation knows of my reverence for the excellent Michael Maccoby, particularly his book The Gamesman; The New Corporate Leaders (Simon and Schuster, 1976). In it, Maccoby theorizes four basic archetypes in the workplace:

• The Craftsman doesn’t care so much about whom he works for, but cares a great deal about the quality of his output.
• The Company Man tends to assume the persona of the Team around him.
• The Gamesman doesn’t see his paycheck as food on the table or a roof over his head, but as a kind of token in some elaborate game he is playing. Because of this, the Gamesman archetype tends to (a) master the rules of this “game,” and (b) be more inclined to take risks.
• The Jungle Fighter gets ahead through cloak-and-dagger techniques, rarely through legitimate technical contribution.

So, how did the Jungle Fighter make his way into your organization, or, worse, your Project Team? He must have presented himself in his interview as being technically advanced, or at least more competent than the others applying for that job. I mean, he might have been straight-forward, and shared that his favorite workplace tactic was to engage in such toxic calumny that other Team members became afraid to even challenge the JF’s assertions in Team meetings, thereby assuming a patina of expertise, but I kind of doubt it. The very presence of any Jungle Fighter in the organization – and, I can assure you, there’s going to be at least one in any organization of size – means that some semblance of the dreaded Swamp is sure to follow.

Once this sort of unmerited managerial influence has a foothold, it’s enhanced by all of the members of the organization who have attained their positions through anything other than technical ability. I’m somewhat embarrassed to admit that, at one time, I sincerely believed that people advanced within their organizations based purely, or even mostly, on merit. Then I turned 14.

The reasons that people attain their ranks within a given hierarchy (other than entities like United States Chess) are often influenced by factors other than their technical capability. That’s not necessarily a bad thing, since each member’s ability to function within a team often makes the difference between success and failure. But being able to function at a high level with respect to inter-team relations does not make up for a lack of technical expertise, in my experience. If those in a position to determine, or even influence, the selection of the technical approach that the Project Team will be pursuing don’t know what they’re doing, no amount of interpersonal skills will save the project.

Meanwhile, In The Poker-Playing World…

In the game of poker, a “tell” is a change in a player’s expression or behavior that can serve as a clue as to their assessment of their hand. As with so many other games of skill with elements of randomness, some aspects of poker are highly analogous to the world of Project Management, and the presence of tells is one of them. If there are people in your organization in a position to influence the selection of the technical approach to the accomplishing of your Project’s scope, but are actually pretty clueless, how can they be identified? What are their tells?

It's my belief that one of the most obvious tells that someone who’s trying to influence the technical approach to accomplishing your project’s scope doesn’t really know what they’re talking about is a gross misjudgment of the level of rigor of the Project Management Information Systems, or PMISs. Most PM-types are wearily familiar with those who want little or no application of basic PM capabilities when some level is obviously called for, but the opposite is also true. Many projects that operate with highly detailed baselines, exhaustive Work Breakdown Structures, and over-regulated Critical Path schedules could operate just fine with far simpler information systems, but are prevented from doing so by their home organization’s policies and procedures.

Those pushing for little (or no) PM-based Management Information Systems are pretty much outing themselves as swamp critters, but what about those who insist on an overly burdensome system? A good litmus test here has to do with the question, Which is more important, attaining the scope on-time, on-budget, or provably following each and every requirement in the PM procedures? Of course, there are other tells (cough, insisting on a risk management [no initial caps] program, cough), but over-reliance on PM procedures to the point that they crowd out perfectly reasonable technical approaches to the Project’s central problem has to be one of the easiest to recognize.

So, look out, swamp people within the PMO! GTIM Nation knows how to recognize you when you bluff. You might just get called.