Game Theory in Management

Whenever the topic of virtual management comes up, it’s almost inevitable that its near-cousin, distance management, also presents itself for analysis. I can understand why – as anyone who has read The World is Flat knows, far-flung team members, formed spontaneously into purpose-driven groups, are increasingly edging out the traditional organizational models of people occupying the same real estate as the most desired structure for high-performing projects. And, with the recent and dramatic improvements in long-range communications, equivalent advances in distance management would seem to be the perfect counterpart to giving direction to these virtual teams, right? Right?

Well, not so fast. There were some very good reasons why organizations tended to want to insist on their project teams being co-located, even if these organizations couldn’t clearly articulate why that was so. It may have been simply experience, or a sense that legitimate management just couldn’t be performed via cell phone, e-mail, and the occasional video conference. I believe that this reluctance to embrace distance management had, at its core, a valid concern, one that has wrecked projects and teams since, no doubt, before the pyramids were built (assuming, of course, that they weren’t built by aliens; or, if they were, that these aliens suffer from the same organizational behavior and performance pathologies that afflict us humans). This issue has to do with cooperation within the project team, and can be analyzed to reveal some valuable truisms using (what else?) game theory.

Let’s use the old game-theory standard, the Hawk-Dove Game. Imagine an environment with 100 generic birds, who can either act passively, going about foraging for food and consuming/storing everything they gather; or else they can act aggressively, either preventing other birds from foraging for the available foodstuffs, or else actively taking the passive birds’ food from them. When all of the birds act passively, like doves, the population’s payoff is maximized. However, introduce just one aggressive bird, a hawk, and the behavior of the entire population will change until it reaches what’s called a Nash Equilibrium (named after Thomas Nash, the central figure from the movie A Beautiful Mind). The Nash Equilibrium for the 100-bird Hawk-Dove game is 75/25, meaning that either 75% of the birds will act as dove all the time, or else each bird will act dovish 75% of the time, and hawkish the other 25%. For far-flung virtual project team purposes, the take-away assertion here is this: when all of your team members are exerting optimal effort in pursuing your project’s objectives, your performance payoff is maximized. However, introduce just one member who’s not exerting very much, or even working at cross-purposes to the project’s objectives in order to pursue a personal agenda, and the entire team will tend towards a Nash Equilibrium behavior set that can easily spell doom for your project.

And here’s where the value of the co-located team comes in: the moment any team member exhibits sub-optimal effort or talent, the attentive manager can respond immediately, either by removing the Jungle Fighter / inept team member, or else by influencing them to abandon their selected project-deviant strategy. The distance project manager rarely has access to this sort of insight: the Jungle Fighters in your project team don’t wear signs on their foreheads declaring their uncooperative proclivities, and are usually smart enough to not allow their masks to slip in telephone conversations, e-mails, and the occasional video conference.

So what I’m saying here is that the primary obstacle to effective distance project management is the tendency in some of your team members to either slack off, or else work to advance their own personal agendas instead of pursuing your project’s scope completion. Essentially, change human nature, and your distance management should come off just fine.

As my projectmanagement.com co-bloggers and columnists explore the realm of virtual project management, I (naturally) thought I’d take the opposite tack. Whereas last week’s piece reviewed those instances where people engaged in pursuing a given accomplishment will almost automatically engage in real-life project management techniques, like earned value and critical path analysis, there is another side to that coin: people who claim to be engaged in legitimate project management techniques, but are not.

Chief among these pretenders are the asset managers, e.g. accountants and financial analysts. Indeed, one of the fastest and most automatic ways of readily identifying the pros from the schmoes has to do with the return-on-investment (ROI) analysis. The ROI analysis is a tool that has utility exclusively in the asset management realm (and, frankly, not nearly as valuable in that arena as it has been cranked up to be), and any attempt to bring it into the arena of project management is a dead give-away. How do I know this? Well, a couple of mind exercises will make this assertion plain.

The ultimate goal of the asset manager is to maximize shareholder wealth. The ultimate goal of the project manager is to complete the project to the customers’ satisfaction, within the stated constraints of cost and schedule. A generic analyst announces that she has made available the information on whether or not a piece of equipment being considered for purchase has a positive return with respect to its cost by the time its value has depreciated to zero. Which manager is interested in this information?

Next, a PM is reviewing the schedule status on a Design Engineering task, which just happens to be on his schedule network’s critical path. The designer’s organization is well under budget, but may be late in delivering the drawings and specifications, meaning that the whole project may come in late. The same generic analyst (although by now we can pretty much guess what this analyst’s background is) wants time to discuss the cost of the office equipment the designer’s organization is incurring. Does the PM care about this piece of management data in the least?

Next on my hit-list are the risk managers. As I’ve stated often, in a project’s earliest stages, where contingency budgets and what-if analyses are being prepared, these people have a role to play. However, once the project is underway, their analyses are a waste of time. The basic acid test here is: in those instances where a so-called risk event actually comes to pass, did any part of the risk analysis change the response of the project team to the occurrence? If the answer is no, then any and all effort and resources that went into such an analysis was wasted. It’s really little more than institutional worrying, trapped out in mind-boggling statistical jargon to help create the illusion of management science sophistication. But it is big business, with organizations offering this type of expertise being very widespread, and all advancing under the rubric of being part and parcel of legitimate, advanced project management. Of course, the inconvenient aspect of reality, that the future cannot be quantified, even by Gaussian Curves, never enters into these organizations’ promotional literature, so they can be expected to continue to be very widespread.

Finally, much as the famous Job Jar in the comic strip Hi and Lois is not a schedule by any reach of the imagination, so, too, do all action item listings fail to come close to fulfilling the function of a project schedule. All valid schedules’ entries have the following characteristics:

·         Projected duration

·         Projected start date

·         A previous determination of whether or not the entry exists within the scope of the given project

·         Whether it ought to be done before, during, or after other entries in the network.

Otherwise, what you have is, essentially, a poll, a repository of data that has not been (or may not be able to be) processed into usable management information. In political contests, poll data can be rather valuable, but in a project management setting it’s next to worthless. If the PM has hard data that the Design Engineering task is in danger of coming in late, who cares about the opinions of the other  stakeholders of the performance of the design engineers? Isn’t that data irrelevant?

Naturally, should any asset, risk, or action item advocates take exception to any part of this blog, feel free to leave a comment. After all, I’ve been disagreed with before – and you’ve been wrong before (hat tip to one of my heroes, the late William F. Buckley for that closing line).

What is project management, really? Yes, yes, I know there are definitions aplenty out there, but I think they can all be summarized as:

Project management is the smart way of pursuing and attaining a specified goal.

If you believe that this definition is overly broad, consider that I can still differentiate project management from asset and strategic management under this definition, since asset management can be defined as attaining a desired goal while consuming or using the fewest assets, and strategic management can be defined as attaining desired goals better than the others who also seek those goals.

Soooo … is project management virtually everywhere? Well, a lot of people pursue and attain their objectives in less-than-smart ways, but, sure, PM is everywhere, even if it’s not recognized as such. Think about the two main information streams that support smart project management decision-making: earned value, and critical path methodologies. Sound daunting, don’t they? Well, they’re not. Follow me on this little mental exercise for proof.

You’re the project manager on an effort to – oh, I don’t know, pick a scope statement – and you’ve just been informed by your accountant (hisssss!) that you have spent half of your budget. What’s the first thought that pops into your head? Is it not, “Am I half-finished?”? Guess what – you just performed an earned value cost performance analysis! And you didn’t even mean to! And, once you’ve answered that question, the next one is almost as automatic: “Was I supposed to be half done at this point?” Now look what you’ve done! An earned-value-based schedule performance analysis!

I know what you’re thinking: Okay, Michael, you got us on the virtual simplicity of earned value analysis (although we’re still a little sore at the EV purists who insist on all those added trappings). But critical path methodology is a completely different animal! That stuff’s complicated! Have you ever tried to drive some of those critical path method software packages?

But critical path is actually just more of the same – it just deals with having to do some things before you can start on others. For example, to prevent my home steam cleaner from being overwhelmed by strands of fur emanating by the ton from my 117-pound Collie (how does a 117-pound Collie shed tons of fur? You got me, brother, but it happens) and being scolded at length by the steam cleaner repairman, I have to vacuum immediately prior to steam-cleaning. So, if I allocate 30 minutes for vacuuming, and an hour for steam cleaning, I should be done in an hour and a half, right? (Wait! Did I just perform a forward pass on my schedule network?) Well, first I have to turn the vacuum over and pull Collie fur from the brushes. And, since the Collie himself needs to be brushed (constantly), I may as well do that first, so that the machines can pick up whatever fur I don’t collect from the brush and throw away. Already the preceding activity – vacuuming – has been set back at least 10 minutes. Since I have to finish vacuuming before I can start steam-cleaning, I’ve slipped my scheduled finish time of cleaning the floors by 10 minutes. Woah! I just pulled status and re-calced my finish time! Finally, if my hour-and-a-half target was pretty firm, I could talk my wife into steam-cleaning each room as soon as I’ve vacuumed it, meaning that, after the first room has been vacuumed, both machines are running concurrently. By doing so, I’ve “crashed the schedule.”

And yet, there’s often a strong negative connotation associated with the terms Earned Value, Critical Path, Forward Pass, Pull Status, and Crash the Schedule, even though, as our little mental exercise has shown, these terms are just part and parcel of pursuing even pedestrian goals with a little forethought. Shouldn’t our larger endeavors receive no less? And, by doing so, haven’t we “done” project management, no matter how inadvertently?

So, yeah, virtual project management is virtually everywhere.

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.”