Game Theory in Management

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.

Two weeks ago, I complained about the so-called business fable literary technique being used to advance management “science” notions, followed by last week, where I took on the use of, essentially, anecdotal evidence to support already-arrived-at conclusions. Since I’ve left the risk management-types out of my scope of fire for a few weeks, it is, once again, their time.

The whole metaphor of cheese being moved comes from, of course, the book Who Moved My Cheese? by Dr. Spencer Johnson. The ready availability of cheese in this book represents the attainment of success and happiness, and any difficulty associated with obtaining the cheese is analogous to challenges and frustration. The ability to avoid challenges and frustration en route to success in the business world is highly coveted, to say the least. Much silliness has been put forward in this quest, but, silly as it is, it has been embraced (or even gulped down) by gullible managers, eager to be able to quantify the future and reap the rewards of doing so. Alas, the future cannot be quantified, and smart managers know this.

So, what truly constitutes excellent project management? I believe it lies in the ability to quickly grasp the nature of changing circumstances, and act accordingly. Indeed, virtually every business success can be attributed to someone who understood the changing landscape prior to their competitors, and acted accordingly, while almost every business failure can be chalked up to the opposite. Queue the entrance of: the risk managers.

I completely understand the appeal of the risk managers. To those so-called managers who are particularly poor at rapid-response to unanticipated events unfolding before their eyes, these guys must appear as god-sends. Using statistical jargon that would confound the typical MBA, these “analysts” assert that they can, in fact, quantify the future.

Sooo… what are the odds of my metaphorical cheese being (again, metaphorically) moved? It’s 100%, naturally. Circumstances within your project will change, and in ways you could not anticipate at its beginning. Really, think about it – would your expertise be needed if everything unfolded according to plan? While it’s easy (and more than a little rhetorically disingenuous) to set up fictional unwilling-to-change characters and knock them down, the reality is that the way the project team adjusts and adapts to changing conditions is the very heart of successful project management, and those unwilling to adapt were left by the wayside long ago.

And where are the risk managers? Well, they may (or may not) have predicted that some of the unfolding events not anticipated may have occurred, but my question is: so what? Did it alter the response of the project team? In the vast majority of cases, the so-called analysis of the risk managers did not nor would not have altered the project team’s reaction to those changing conditions. And that, gentle readers, means that the entire risk management empire is built on epistemological sand.

The tide can’t come in soon enough.