Game Theory in Management

As the month of insightful rants on involving stakeholders in your projects comes to a close, I wanted to leave the subject with some usable guidelines for knowing when to follow the conventional wisdom on stakeholder involvement, and when to treat it like Sean Penn weighing in on foreign policy. In order to get there, though, we need to do some categorization.

There are two kinds of people: those who divide people into two categories, and those that don’t. So goes the saying, but, in our analysis of who our stakeholders are and whether or not they should be “engaged,” a bit of analysis of where they’re coming from and their relative capabilities is in order. Let’s start simple: of the people impacted by the successful (or unsuccessful) completion of your project (i.e., “stakeholders”), some of them will desire a successful outcome, and others won’t (see my previous piece on “engaging” the latter). Fair enough, but the people in these categories won’t be wearing signs announcing their loyalties. Assuming you are in a position to evaluate your stakeholders’ true alliances, proffered intentions, and competencies (depending on how good you are at reading people, this could be a rather large assumption), we can assemble a basic grid at this point to help evaluate our stakeholders:

·         There are those who want you to fail, and present as such.

·         And there are those who want you to fail, but pretend to want you to succeed.

·         Those who want you to succeed, and present as such.

·         And then there are those who want you to succeed, but present as if they want you to fail.

This last category is rather rare, and something odd must be going on in the background, like a union boss who’s thrilled at getting the work, but has to pretend to be mad at the compensation rate. This category also includes those who are nominally opposed to your project, but have a larger conflict with your major opponents – the old “enemy of my enemy” category. While Sir Winston Churchill believed these to be analogous to friends, I believe there’s a little more nuance involved with them. Since I have evaluated the extremely dangerous second category in previous posts, I won’t go back over that, but I will suggest a third category: the competent, and the inept. Now we have a three-dimensional analysis, as indicated in the following table:

Of course, we all hope that our project teams are entirely composed of Category As; alas, they never are. At the very least there’s always a sprinkling of Bs, with the chilling addition of the Category Gs (the so-called Jungle Fighters, from Michael Maccoby’s archetypes). As we move beyond the actual project team and into the realm of stakeholders who do not belong to our organization, we encounter more and more Category Es and Fs. How to handle these? Well, once you’ve categorized all of your stakeholders, here are my suggestions for dealing with them:

While much of the literature I’ve seen on the topic of stakeholder engagement asserts that all identified stakeholders should have input into your project’s management decisions, note that I have suggested that only Category A people should have such unfiltered access. I guess that means that, in my view, at least some of the conventional wisdom on this topic was written by Category B people – and now you know how to deal with them.

As many of my regular readers know, I view much of what passes for modern management science as being eerily similar to games, games that follow the predictable patterns examined in the field of game theory. Stakeholder management is no exception, but it has to be viewed from a certain angle to gain insight as to its patterns of success and failure. I know my last few blogs have been, umm, challenging (shall we say?) contemporary concepts of stakeholder management, but I have, believe it or not, performed some new scholarship on the matter which may help in certain circumstances.

Let’s begin with the precept that much of management is an information game. As long as the information streams are accurate, timely, and (most importantly) relevant, then the 20% poorest managers with 80% of the information they need to obviate a given decision will always out-perform the 80^th percentile best managers who have access to only 20% of what they need to know to ensure the correct decisions. This is where arrogance and stakeholder engagement enter into the equation. While arrogance as a personal trait is highly off-putting, in management it is fatal, since the arrogant manager does not believe himself to be error-prone, meaning that he will tend to not put in the extra effort to gain access to the data needed to make truly informed decisions. He begins to believe of himself that his hunches and instincts are suitable stand-ins for relevant information and, from that moment on, the projects he heads see their odds of a successful completion plummet.

From a third person perspective, though, this must appear as if the arrogant PM simply refuses to engage the people around him who may have the perspectives or insights necessary to complete the project(s) successfully. This tendency becomes clear if we engage in a little thought exercise: consider two PMs. One heads a project team of diverse personnel, who tend to approach problems in a wide variety of ways, ways that this PM would not normally engage as he pursues his scope. However, no one in this team has bothered to set up the management information systems (MISs) that collect, process, and deliver project performance data, or any other relevant data, for that matter. Project Manager B, by contrast, heads a project team of middle-age women, all of Irish descent, all with degrees from the same university, in the same subject, and are all married to men from Hawaii. Their kids attend the same school, and they are all fans of the same NFL team (the Atlanta Falcons). However, this project team has set up the MISs that provide accurate, timely, and relevant project information, including earned value and critical path methodology-based systems, as well as data relevant to the technology inherent in accomplishing the project’s scope. Which project team has the better chance of completing the project on-time, on-budget?

Now, to extend this little exercise a bit further, also imagine that project manager A is fully engaged with his team, and meets with them extensively. Is his lot improved? Imagine project manager B does not meet with her team at all – they simply (and literally) throw their reports over the transom to her door, and sneak off back to their cubicles. Have her chances of success been diminished?

I believe the management pathologies that have been identified by the stakeholder-engagement aficionados have, at their root, the twin evils of arrogance in executives and managers, and deficiencies in the delivery of accurate, timely, and relevant management information. I further believe that the techniques these well-intentioned ones push forward are actually remedies from the realm of organizational behavior and performance, designed to correct a pathology that actually originates in the information technology realm. Such cross-discipline remedies rarely work, however, and tend to come across like so much eat-your-peas-style hectoring.

Or, perhaps, I’ve arrived at these conclusions simply because I haven’t “engaged” the right “stakeholders.”

Some years back I was invited to participate in the creation of PMI’s® Practice Standard for Earned Value Management by its project manager, who had been reading my columns in PMNetwork magazine and wanted my input. Typically, contributors to these PMI® projects volunteer, and I had not intended to participate prior to the invitation due to the sheer number of pro bono writing requests I receive. But this one intrigued me, so I accepted the invitation, started writing, and prepared for the first meeting of the team.

The first such meeting was held in Costa Mesa, California, in a ballroom of the hotel where most of us were staying. Through this effort I would get to work with some truly talented people in the field, like the incomparable Gary Humphries and the insightful Jim Wrisley. However, there were some others whom I came to believe were there, not to add insights or help others, but for purposes more closely resembling self-aggrandizement. As the first session of reviewing my text got underway, these people – who, I must stress, fit the classic definition of “stakeholders” – set about their agenda.

The PM projected my first few paragraphs onto the screen. Half the room erupted into objections, while the others insisted those words were perfect for the stated document’s objectives. Then, the next few paragraphs would be projected, and the half of the stakeholders who had previously asserted that the writing was completely unacceptable did a one-eighty, and insisted that these next paragraphs were fine, whereas the previous supporters suddenly turned into the harshest critics. And so it went, hour after hour, the whole weekend long. We got nowhere.

Taking with me a pile of inchoate, often contradictory edits, I set about to try to appease the greatest number of critics in the run-up to the second meeting, this one being held in Kissimmee, Florida. This time, though, there were presentations and speeches to endure prior to tackling the actual verbiage. One widely-travelled fellow actually made a pitch that the opinions reflected in the Practice Standard ought to reflect only those who had an “international” take on the subject. Of course, he wasn’t appealing to being given a larger writing assignment – in my opinion he just wanted to have some sort of veto power over what the actual writers were doing, apparently based on the frequency with which his passport got punched. And so went the second session, again, getting absolutely nowhere.

A few months later PMI® was arranging for the principals of all of the then-commissioned practice standards to attend a series of sessions back in Pennsylvania. These were briefings from legal experts, warning of the consequences of plagiarism, presentations from PMI® execs, and a talk from a representative from the American National Standards Institute, better known as ANSI. Since this work’s PM couldn’t make this meeting, he hastily appointed me Deputy PM, and I made arrangements to attend.

At the ANSI presentation, the rep made a comment that I will never forget. He stated that, in order for any of our practice standards to be considered viable, they must pass a very basic test: that no person considered an expert in the field would object to anything put forth in the practice standard. I raised my hand.

“Excuse me, but we’re dealing with a bunch of project management-types here. You could put fifty of them in a room, and they wouldn’t agree on the color of an orange. How on Earth do you expect that level of consensus?”

The guy wouldn’t budge, which is when I began to realize our effort was doomed.

The Practice Standard would eventually be published, but with the words of a ghost writer. The PM simply could not overcome the division among the partisan stakeholders, and so resorted to a vehicle blissfully independent of the self-aggrandizers. My name is on the list of contributors for the first edition, but I’m fairly sure that very little of my actual input made it to the final draft. The document itself is fairly mushy, but, hey! At least we engaged the stakeholders, right?

Stakeholder management – what a concept, right? It implies a two-step process: (1) identify and engage your project’s stakeholders, and (2) somehow influence – “manage” – their impact on your pursuit of the project’s objectives.  Unfortunately, each of these steps is fraught with peril.

Let’s take the concept of engaging your project’s so-called stakeholders. Who are they, exactly? Linda Bourne, in her PMI® blog from September 22, 2009, says:

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) breaks down a stakeholder as a person or organization that:
•    Is actively involved in the project
•    Has interests that may be positively or negatively affected by the performance or completion of the project
•    May exert influence over the project, its deliverables or its team members

Hmmm… the second bullet is most interesting. “Has interests that may be positively or negatively affected by the performance or completion of the project” (emphasis mine). By this definition, General Hideki Tojo was a stakeholder in the Manhattan Project. Should Oppenheimer have “engaged” him? I would have loved to have composed that telegram:

Dear General Tojo – my name is J. Robert Oppenheimer (don’t worry about what the “J” stands for – nobody knows), and I’m the project manager on some work which will most definitely negatively affect your interests. It very well may, in fact, bring your war of aggression to a sudden conclusion, with you on the losing end. Could you arrange to come out to Alamagordo, New Mexico, for a little project briefing? I’ve been led to believe by some self-identified experts that your insights will go a long way towards improving our project performance or attaining project completion, or something.

Sincerely,

J. Bob

And Tojo’s hypothetical reply:

Dear J. Bob – thank you for your telegram of July 15. As an official stakeholder in your mysteriously unnamed project, I am most alarmed that your success will have a negative impact on me personally, and on my nation and its military. I must insist that you immediately cease all efforts on your project, even if it means the deaths of hundreds of thousands of Americans and Japanese should you fail. Thanks so much for engaging me.

Very Truly Yours,

Hideki

I’ve lost track of the number of times I’ve used this construction in this blog, but, do I really have to say it? To include in the definition of “stakeholder” those who actively seek your project’s failure is intellectual vacuousness, and to further assert that these must be included in the project’s decision-making process is sheer folly.  And yet, if Ms. Bourne’s citation is accurate, there’s PMI®, maintaining such a definition in the PMOK Guide® (as a point of fact, Linda’s blog was actually seeking to expand the definition of a stakeholder). Between pushing the concept of engaging stakeholders and the role of risk managers, I think PMI® has positioned itself institutionally as being willing to tolerate trendy, politically-correct nostrums rather than insisting on legitimate management science scholarship – but that’s just my opinion.

Of course, there are practical, usable truisms on the proper way to manage your project’s stakeholders, and I fully intend to explore these in this month’s subsequent blogs. But I wanted to come out of the starting gate (again) with something that I think should be fairly obvious in this particular area of management science, but isn’t: there’s a lot of flimflammery out there on this topic, and it ought to be ignored rather than enshrined in so-called knowledge guides.

As 2013 heads to a close, so, too, (mercifully) does my over-use of the metaphor behind my last few blogs, springboarding off of the title of Spencer Johnson’s best-seller, Who Moved My Cheese? In this book, miniature humans dwelling in a maze attempt to obtain caches of cheese, representing the attaining of goals and success. Since these caches move, the miniature humans deal with issues surrounding changing circumstances and the best way to deal with them.

And yet it must be pointed out that one of the primary causes of moved cheese …er, detrimentally-changed circumstances, is the presence of bad players within the project team. In Michael Maccoby’s book The Gamesman, the New Corporate Leaders, he outlines four basic worker archetypes:

·         The Craftsman doesn’t really care too much about the organization for which he works, but does care about the quality of his work and output.

·         The Company Man tends to adopt the persona of the macro organization around him.

·         The Gamesman (after whom, obviously, the book is named) sees his profession not as a means of putting food on the table or a roof over his head, but as a big, complex game, one that he intends to master.

·         And, finally, the Jungle Fighter, who gets ahead through calumny and other office-politic treacheries.

It’s this last I want to analyze, because they can be so damaging to the project and project team, and yet largely go unrecognized, much less properly handled.

For this discussion to move forward, we’ll need a precise definition of the term “office politics.” I think office politics should be defined as members of the organization pursuing goals that benefit them personally, but are either incompatible with, or even contrary to, the goals of that organization. These actions can be as mild as the decision of a salesperson to not smile as much to customers, or as major as a principal project team member seeking to ruin the standing of a perceived rival.

While the following two assertions should go without saying, especially among experienced managers, I will state them anyway: (1) Jungle Fighters are political animals, and those times they advance within the organization, they almost always do so via political tactics, and (2) Jungle Fighters are present in your project team, whether you know it or not. As a manager, you can significantly improve your projects’ odds of success if you can both identify the Jungle Fighters within your project team, and render ineffective their tactics.

How to Identify a Jungle Fighter.  This is actually easier than you might think, even if your brain isn’t wired like one of them. Jungle Fighters’ main (exclusive?) strategy is to change the perception of those above them in the organization, rather than actually accomplish anything tangible. They do this through two primary tactics: ex parte conversations, and accomplishment/error inflation/deflation.  Much like The Godfather’s Michael Corleone knew that the first one of his father’s lieutenants who came to him offering to arrange a meeting with Barzini was a traitor, you will know when any member of your project team seeks a private audience with you in order to criticize another member of the team that you have a Jungle Fighter on your hands.

Their other tactic, which I’m calling accomplishment/error inflation/deflation, is also aimed at altering perceptions. The Jungle Fighters will inflate and trumpet their contributions excessively, while playing down any errors they may have committed. While this is somewhat attributable to human nature, its inverse is not: they will make it a point to amplify the impact of the errors made by other members of the team, while minimizing their accomplishments. These are two sure-fire reveals of Jungle Fighters in your organization.

How to Render Ineffective Their Tactics. Thwarting these tactics can be simple, even deceptively (get it?) so. Refuse the ex parte conversation requests. Announce at your next project team meeting that, in the future, should any member of the team wish to talk about the performance of any other member, that all such reviews – including the relative value of team members’ accomplishments – will involve the team member being discussed. Stripped of the ability to tear down their organizational competitors unopposed, they will quickly realize the game has changed, and will either alter their behaviors to become genuine contributors, or else find another project team where they can persist in their Jungle Fighter ways.

Ultimately, the cheese still gets moved, just not due to treachery.