Game Theory in Management

I found myself thinking about the many similarities between billion-dollar-generating protagonists Luke Skywalker and Harry Potter recently (actually, it was one of the more productive ways to spend the free time with which I suddenly found myself, after setting aside time for March Madness, only to see my beloved University of New Mexico Lobos make an unexpectedly early exit). Consider:

·         Both are orphans, with mothers who had been renowned for their beauty,

·         and have been living with an Aunt and an Uncle, in an out-of-the-way place in order to hide them.

·         They both have an amazing talent, but, early on, are unaware they have it,

·         but the Aunt/Uncle are aware of it, and hope the boys do not grow up to be like their fathers.

·         An encounter with their eventual mentors reveals this talent, and who they really are in the stories’ larger conflict.

·         Both are pursued from birth by the story’s antagonists,

·         who are aware that the boys are somehow destined to thwart their evil intentions.

·         Both Luke and Harry have friends, but their primary ones are one man and one woman.

·         Early in the stories, it looks as if Luke/Harry will become romantically involved with their primary female friend,

·         but their primary female friend and primary male friend end up having the romantic relationship instead, and both Luke and Harry are okay with this.

·         Both Luke and Harry engage in one-on-one combat with their main antagonists, but the first encounter does not end decisively.

·         The second one-on-one encounter occurs while a much larger conflict is going on in the background, and ends with the protagonists victorious.

A review of the story’s antagonists reveals even more striking similarities:

·         Both Darth Vader and Voldemort have unusual appearances, having been on the losing end of a conflict prior to the timeframe of the telling of Luke’s and Harry’s stories.

·         They both dress in black, head-to-foot,

·         and have the unfortunate tendency to taunt their opponents during combat.

·         Both Vader and Voldemort have murdered underlings who disappointed them, and in a most casual manner.

·         Both story’s antagonists have battled Luke/Harry’s mentors, and lost, but somehow escaped capture,

·         but would go on to kill the mentors (although Voldemort does this indirectly, via Snape [see below]).

And, if you take into account the expanded list of antagonists (Emperor Palpatine and Snape), the list of similarities becomes even longer:

·         All four antagonists dress in black, head to foot.

·         The lower-ranked antagonists (Vader, Snape) are believed to have the potential to be on the right side of the conflict by Luke/Harry,

·         which, indeed, they are, but it is not revealed until Vader/Snape betray Palpatine/Voldemort.

Now, is this to say that Star Wars and its sequels represent the same story as Harry Potter, and its sequels? With such a long list of exact similarities, it might seem to the casual book/movie consumer that only the settings have changed.  And yet, I am wholly unaware of any attempts by George Lucas to file a plagiarism claim against J. K. Rowling (maybe it’s one of those “unintentional plagiarism” things, like George Harrison and “He’s So Fine”). Don’t get me wrong – I’m not saying such a claim should be forthcoming. I’m just noting how both stories’ plots appear to assume a remarkably similar, almost formulaic, arc.

By now, my regular readers are probably wondering “what on Earth does this have to do with project management?” It’s natural for us to try to recreate the conditions and environs that have led to success in the past in our current situations and projects, and to avoid those conditions we associate with past failures. However, this tendency needs to be recognized for what it is: an ossifying element that prevents us from adapting novel technical approaches to our project management problems. In larger organizations especially, there can be a standardization of approach to implementing project management techniques, and these approaches can become so formulaic that they morph into a rigid orthodoxy. And, by the time that sets in, the chances of your organization bringing in projects successfully – particularly and especially projects dealing with new technologies or situations – have just dropped precipitously.

In short, stop pointing your wands and exclaiming “Expecto Success Stategerium!”

Pity the poor Project Managment proprietor. Earlier this week, Pro Football Hall of Fame running back Emmitt Smith had this to say, about a proposed rule that would penalize a running back for hitting a tackler with the top of the helmet:

“I disagree with the rule altogether.  It doesn’t make any sense for that position.  It sounds like it’s been made up by people who have never played the game of football.’’

What does this have to do with managing a Project Management Office, or an organization of Project Controls specialists? Not much, except for the fact that, in most organizations, the answer to the question of how much project management or project controls support is needed for a given endeavor is almost never provided by people fluent in those arenas. The technicians, engineers, and programmers executing their projects’ scope often determine the level of project management and PM information systems support they need and, in my experience, they often get it wrong.

But the way they get it wrong offers a certain fascination. I first noticed a pattern of assessing PM talent demand when I was working for a rather large organization, which would periodically encounter on-the-job accidents. When these accidents occurred, upper management would respond in a very predictable way, decrying the lack of a “safety culture” within the organization, and mandating that all employees attend a series of safety presentations. A renewed focus on performing our jobs safely would then permeate the organization, even those elements that weren’t engaged in any particularly hazardous duties. As the accident rate dropped, so, too, did the overt emphasis on observing the myriad safety protocols put forward by the safety engineers. The unnecessary ones would be ignored first, with very little (if any) impact on the organization’s accident rate. Eventually, some of the basic safety principles would get worked around, and another avoidable, and yet somewhat grisly accident would occur, and the cycle would begin again.

It then struck me how similar this cycle is to the perceived demand for project management expertise. Projects would be muddling along, with the engineers wondering why they had to spend any money at all on project controls specialists or other PM-types, and making the case to save money by abandoning that area of expertise. Some projects would go on to finish successfully, reinforcing the narrative that money spent on the PMO was superfluous and a waste. But, inevitably and eventually, some project would go off the tracks, racking up huge delays and overruns, and all without the ability to have forewarned upper management that a problem even existed before it was too late to avert or mitigate the disaster. A cursory post-mortem would reveal an inadequacy in that project’s cost and schedule control systems, and the demand for those who could set up such systems would realize a dramatic increase. This would continue until a certain sense of complacency would re-enter the management culture, and the engineers would return to their questioning of the need for PM expertise.

All this time, the PMO managers, as well as those in charge of project controls organizations, were dealing with one of two problems: either the perceived demand for their organizations’ services was below supply (in which case they would scramble to find billable work for their people), or else demand far outstripped available talent, in which case their people were working overtime and experiencing burn-out. Depicted graphically, it looks something like this:

In this example, the appropriate level of expertise for this organization is 25 full-time equivalents (how does one calculate the “appropriate level”? For that, you will have to buy my recently-released, must-have book Game Theory in Management). Notice how, as complacency among the technical staff reduces their perceived level of demand to zero, the available talent lags in both amplitude and time. Because technical management is reluctant to come out against, well, reality, they will tend to not communicate their anti-PM sentiments until after these have become socialized and solidified, hence the time-lag in communicating the reduced demand to the owner of those assets. However, PM organization leaders also know that, at some point in the future, this demand curve will reverse itself, so that, even as perceived demand drops to zero, they won’t be rid of all of their talent. These managers will find a way to protect as many of their charges as they can. Note, also, that these managers won’t increase their talent pool to match the zenith of the curve, since they also know that the demand will inevitably drop once the risk of project disasters has faded from memory.

Organizations trapped in this cycle will experience myriad pathologies of business decision-making, which makes all these problems so frustrating to encounter. They are all so avoidable – but you can’t tell that to those who manifest a tendency to discount or even minimize what project management, as a discipline, can bring to the board room.

And that’s why we should pity the poor Project Management proprietor.

As my regular readers know, I regularly tear into the risk management types for the multitude of foibles that lace their approach to project management. I think they overstate their ability to provide relevant business information, their data is far, far more subjective than they are willing to admit, and that Nasim Taleb (in The Black Swan, the Impact of the Highly Improbable) was right when he asserted that overuse of the Gaussian Curve is the greatest intellectual fraud of the 20^th century. But, from a strategic management point of view, their error lies in the assumption that, given enough quantitative analysis, the best strategy can be discovered for most business situations. My take is that the best strategy is one of providing for a robust response to the unforeseeable events that will inevitably transpire on a given project, rather than attempting to calculate the likelihood and impact of such events unfolding. Is there an example out there that illustrates these rival positions?

Of course there is! (Why else would I have posed the question?) Many senior managers today had their view on the world influenced by the television series Star Trek. The original version of the series (nicknamed “the original series,” or TOS) had an iconic episode entitled “The Doomsday Machine.” In it, the starship Enterprise comes across her wrecked sister ship Constellation, which has evidently been in a horrific battle. As Captain Kirk and a boarding party investigate, they come across the  Constellation’s lone survivor, her captain, Commodore Decker (played brilliantly, I might add, by William Windom). Decker tells of what happened to his ship and crew, how they were attacked by an automated weapon of immense size and power. Just as Decker and Doctor McCoy beam back to the Enterprise, the “planet killer” reappears and attacks Enterprise.

With their Captains on board each other’s vessels, we now see played out how their competing strategies are enacted. Commodore Decker takes command of  Enterprise in order to continue with the strategy of “hitting it (the planet killer) with full phasers, at point-blank range!” Unfortunately, this is nothing more than a slight derivative of the strategy that ended up wrecking Constellation, and killing her crew, a fact that Enterprise’s first officer, Spock, points out. Spock also provides the reason that that strategy didn’t work – “The object’s hull is solid neutronium. There is no known way of blasting through it.” I would imagine not – neutronium is the almost incomprehensibly dense metal at the core of white dwarf stars, as they continue their path towards supernova and , eventually, black holes (how the creators of the planet killer extinguished the white dwarf star, mined and shaped its nuetronium into a funnel-like shape, and integrated its propulsion and defensive systems is not addressed). Decker’s strategy did not represent a very robust response the first time, and his modifications to that strategy won’t fare any better.

Kirk, on the other hand, accepts Spock’s analysis that his ship’s traditional weapons will be of no use in their current situation, and immediately abandons the strategy of attacking with those weapons. When Decker is relieved of command of Enterprise, he steals a shuttlecraft and commits suicide by flying it into the maw of the planet killer. Enterprise detects a minute reduction in the planet killer’s power emanations, and Kirk devises a new strategy. He will rig the Constellation’s impulse engines to detonate as she similarly flies into the planet killer’s interior. Naturally, there are some tense moments as Enterprise’s transporter system goes on and off-line, but, at the last possible moment, Kirk is beamed off of Constellation as she flies into the planet killer and detonates, permanently disabling the automated antagonist.

Note that Kirk had no pre-conceived strategy; or, if he did, he abandoned it immediately. He adapted to the situation, and developed a robust response to events as they unfolded. Conversely, Decker had a set strategy, and refused to significantly modify it, even in the face of overwhelming evidence that it didn’t work, and wouldn’t work in the future with nothing more than changing the range with which he confronted his foe. Don’t get me wrong – strategizing is great. But the truly insightful manager will be willing to abandon any strategy when the situation on-the-ground (or in deep space) calls for it.

And for those critics who might be tempted to assert that few real-life management situations are sufficiently similar to 50-year-old Star Trek episodes to provide insight, I have one question:

Are you really a Klingon infiltrator?

…and they’re not necessarily evil.

In last week’s blog (“Here’s a Communication Strategy: Don’t Communicate Your Strategy!”) we covered the folly of communicating any of the particulars of the organization’s intended strategy, due to one of three outcomes:

·         It’s so general that it really doesn’t communicate anything, and so wastes your intended audience’s time,

·         It’s accurate, true, and insightful, delighting your customers and shareholders alike, but tips off the competition to what you’re about to do, and

·         It’s inaccurate and untrue, angering your customers and shareholders.

As I discuss in my recently-released, must-have book, Game Theory in Management, one very interesting game that illustrates the dangers of transmitting your strategy is Diplomacy, regarded as the board game that has triggered more fist fights amongst friends than any other.

Diplomacy was supposedly the favorite game of both JFK and Henry Kissenger. It’s played on a board that has a representation of a map of Northern Europe just prior to the First World War. Each player is assigned a nation (or a part of a nation), and ground forces that can be used in either attacking other players’ territories or defending your own. The individual players don’t take turns – all players move their markers simultaneously. But here’s the catch: prior to the players actually moving, they spend time talking amongst themselves, making deals and scheming, and forming alliances, both true and fake. When it’s time to perform the move, the players write down on a piece of paper the move they will actually make. Then, at a given signal, the papers are turned over, and the markers moved accordingly.

The fascinating thing about Diplomacy (both the game and, I suppose, actual diplomacy) is that it’s virtually impossible to win without engaging in deceitful strategies. If, during your pre-move communications, you are always truthful, you have no hope of winning. In this, Diplomacy is very similar to Poker. The Poker player who always bids up winning hands and always folds on poor ones will be taken to the cleaners by the other players at the table.  At some point the strategies of underselling a winning hand, or overselling a losing one (“bluffing”) are called for, if, for no other reason, so that the other players (read: competition) do not have solid basis for anticipating your next move. Generally speaking, if your competition can accurately anticipate your next move, you will lose, and lose big. Consider the amount of energy going into keeping the timing and placement of the Normandy and Inchon landings a secret, not to mention Pearl Harbor. Preventing your competition/adversaries from correctly anticipating your next move is a very large part of strategic management, indeed.

As I’ve been writing repeatedly, asset, project, and strategic management are different animals, with different goals, tactics, and information systems. If you neglect or dissemble in your asset management information system, then you are engaged in fraud, and you will probably go to jail (e.g., Enron). If you fail to set up or ignore your project management information system, you  should have never been placed in a managerial role, since you are inviting disaster (e.g., the National Ignition Facility). However, if you fail to insert some level of deceit in the strategic management information coming out of your organization, then it won’t take long for the other players at the table to come to a place where they can correctly anticipate your next strategic move. When that moment comes, your organization’s days are numbered.

Of course, the implication from the previous paragraph is that, for any software package that pretends to support the strategic management function, some level of informed deceit must be included. But, since this is never the case, the inescapable conclusion remains: none of the so-called enterprise or portfolio management systems currently available can truly fulfill those functions.

And those assertions, dear readers, are completely devoid of deceit.

A Google® search on the words “Communicate with stakeholders” returned over 8.5 million hits, and, without reading all of them, I’m fairly confident that most of these sites believe that such communications are a good thing. The problem here, as with other overly-extended project management precepts, is that the definition of “stakeholder” varies significantly depending on who you’re talking to, but it’s almost always overly broad.

According to eHow – money,

The broad definition of a “stakeholder” is anyone in a position to affect or be affected by the actions of a group or organization. [i]

Well, according to Metcalf’s Law (dealing with the ability of very small variances in distant nodes of a large network to have a massive, cascading effect on many other nodes of that network. Also known as the “Butterfly Effect”), that’s just about everybody on the planet.

To be fair, most of the scholarship on communicating with stakeholders does specify the need to tailor the message to the intended audience. But here’s the problem with that: if by “tailor” we actually mean “change,” then the message sent to the employees may be different than the message sent to customers, or even shareholders, and such changes are bound to be seen as duplicitous.

There’s also the problem of such “messages” falling into the hands of the organizations’ competitors. This threat is the primary reason why no organization’s mission statement ever contains any information that is, well, usable. It’s the same “delivering the best value to our customers while pursuing the goals of our shareholders” silliness, re-phrased in ever more convoluted syntax (and almost always in the weak passive tense, which makes me insane).

In my recently-released, must-have book, Game Theory in Management, I discuss games which have as a component communications among players. One of the most iconic is Chicken, made famous by the scene in Rebel Without a Cause where Buzz Gunderson gets stuck in his car as it careens off of a cliff. Whether both cars are headed for each other, or towards a cliff, the basic payout matrix is the same:

·         If Player A swerves and Player B does not, then Player A is considered to be cowardly (“chicken”), and Player B is considered brave.

·         And, vice-versa: if Player A does not swerve, but Player B does, A is brave, and B is chicken.

·         If both players swerve, then both are considered chicken (then why play in the first place?), and

·         If neither player swerves, then both die in a fiery car crash.

If this were represented in a payoff matrix, it would look like this:

So, just based on the rules and this payoff matrix, the only reasonable strategy to adopt would be to always swerve. But, if that’s the case, why would the game theory analyst ever even engage in a game of Chicken?

Because of the pre-game communications. Remember, based on the eHow—Money definition, your Chicken opponent is certainly a “stakeholder.” If, prior to actually getting into your car and speeding off to the critical decision point, you were to have a talk with your opponent, and convince him that you are either extremely brave (or crazy), and absolutely will not swerve, then you have increased the odds of selecting the no-swerve strategy, and living past then next ten minutes.  Conversely, if, after your interaction with your opponent, you come away convinced that he is brave enough (or crazy enough) to not engage in the swerve strategy, you would be well-advised to update your approach accordingly.

Which brings us back to why would anyone in the business world would communicate a strategy that’s worth hearing. If the message being delivered is inconsistent across the projected audiences, then the strategist will be seen as duplicitous. If the strategy being communicated is accurate and provides actual insight, then the competitors will inevitably catch wind of it, and use it to your strategic disadvantage. In attempting to communicate your strategy, you are either wasting people’s time, lying to them, or giving your competition an advantage. So, here’s my recommendation for communicating your strategy:

Don’t communicate your strategy.