Game Theory in Management

In my previous blog I used the dopey literary device of furthering the idea that a management science concept could be legitimately evaluated in a fictional setting. However, many business insights can be gleaned from analogous non-fictional events, especially war events, which is perhaps why battle analysis is such a popular exercise of management writers. In wrapping up our November theme of information technology and its impact on management, I want to evaluate some common but wrong-headed management science concepts, and how they are shown to be invalid by the way that events unfolded at the Battle of Midway.

Midway is an atoll, as the name implies, approximately midway across the Northern Pacific Ocean. After the Doolittle Raid against Japan in April 1942, the Japanese high command sought to extend the defensible perimeter around the home islands, and elected to invade and conquer Midway. And the Imperial Japanese Navy was fully capable of doing so – they had six large attack aircraft carriers, and multiple smaller carriers, battleships, cruisers, and support craft, manned and piloted by highly-trained and experience crews. Conversely, the United States had only three aircraft carriers, and one of those, the Yorktown, had been badly damaged at the Battle of the Coral Sea in May. The American aircraft could not perform as well as their IJN counterparts, and there were fewer of them. In fact, by any measure of pre-battle analysis, the situation for the U.S. Navy was virtually hopeless. But, the USN had one key advantage: they had better information.

The Japanese Naval code, nicknamed JN-25, was extremely sophisticated and considered unbreakable. However, American cryptologists had made impressive progress in reading IJN communications, and were becoming aware of an IJN target named “AF,” though it was unclear where AF was. A junior naval officer suggested that the commander of Midway transmit a plain signal that they were low on drinking water, and it was approaching crisis levels. Soon after, a JN-25 message was intercepted indicating  that AF was low on drinking water, and the USN knew that Midway was the target. By interpreting further communications, the Americans became aware of almost the entire Japanese order of battle, including major units assigned and an approximate timetable.  Admiral Chester Nimitz decided that his best response would be to place his only available carriers, Enterprise, Hornet, and the hastily and only partially-repaired Yorktown, in a position north and east of Midway, to counter the Japanese assault.

Conversely, Admiral Chuichi Nagumo had no idea that the Americans had been tipped off to his intent, much less his approximate order of battle. Nor was he aware that the USN had any units at all in a position to counter his mission. As he approached Midway, Nagumo had his four carriers prepare for an attack against ground targets, with some reserve aircraft prepared to attack ships in the unlikely possibility that the Americans had naval units in the area. On 4 June 1942 IJN carrier-based bombers attacked Midway, but failed to damage its facilities sufficiently to allow the commencement of the ground assault. As if to punctuate the need for another strike against the island, a wave of Midway-based high-altitude bombers arrived over the Japanese fleet, and dropped their bombs. Even though none hit, the need for another hit against Midway was apparent. As the first wave of Japanese dive bombers were returning, needing to refuel and requesting to be re-armed with more ground-assault ordnance, the scout seaplane from the cruiser Tone radioed in with the worst possible news – it had sighted an American fleet, including what appeared to be an aircraft carrier. Nagumo finally decided that the planes that had already been armed for ground assault be re-armed for naval targets, and that the returning aircraft would be recovered and refueled prior to the launching of the next assault.

It was at this moment that the American carrier-based planes converged on Nagumo’s task force. Once the torpedo planes were virtually wiped out by patrolling Zeros, the American dive bombers had scarcely-defended approaches to the Japanese carriers, three of which were reduced to blasted, burning metal within minutes. The Japanese would go on to lose all four of the participating carriers, along with over 3000 valuable pilots and crews, while the Americans lost the damaged Yorktown, destroyer Hamann, and 307 pilots and crew.

 So, what are the management science lessons here? As I discuss in my recently-released, must-have book, Game Theory in Management (Gower Publishing, 2012), I believe that no asset manager in the world would had advised Nimitz to even try to defend Midway – the imbalance of material was simply too stark, and the opportunity for exacting enemy losses remote. Similarly, which commonly-practiced risk management technique would have yielded a go-ahead advisory to Nimitz?  Note that the battle-winning intelligence had nothing to do with estimating the odds of the Japanese selecting a particular approach – the intelligence simply rendered an accurate picture of what was actually happening, real-time. In reality, the only advantage the USN had was in their pre-battle information – in every other category, the Americans were hopelessly overmatched, and yet the value (or even existence) of a superior information stream, providing timely, accurate, and relevant information, is not even taken into account in the business models of the asset or risk managers. In my thinking, this reveals the asset and risk management information streams to be far more confined in their range of efficacy than has been advertised.

What’s the value of information technology to management? It changes history.

In a previous blog I lamented the use of the literary device of portraying a given management theory in a fictionalized setting, where – wouldn’t you just know it – the theory being presented, when adhered to, leads to fabulous success for the story’s protagonists. This device is disingenuous to Cecil B. DeMille proportions, but there’s no denying it works. Heck, Eliyahu Goldratt used it in his book Critical Chain, and not only did the book do well, there’s actually a Goldratt Institute now, despite the tenuousness of the underlying theory. Of course, I did not take this approach in my recently-released, must-have book, Game Theory in Management (Gower Publishing, 2012), but there’s still an opportunity to fictionalize some of my points in this blog. “If you can’t beat ‘em, join ‘em” goes the cliché, so, with no further ado…

The air was thick with tension when Captain Rodgers strode onto the bridge of his starship, the Geetim (how my book’s title sounds when you speak the acronym – get it?). Several alien species had come together to form a consortium, the Pimbockers, and their warships had been devastating Confederation merchant convoys. The President himself had ordered Rodgers to take the Geetim to patrol those areas of the convoys’ routes where the most devastation had occurred.

“Status report!” Rodgers commanded.

“The main engines are functioning at 94% efficiency, even though two of the cooling coils are down” answered the engineer. “Also, at this rate of fuel consumption, we will have to save cargos totaling over five billion credits in order to achieve a positive return on investment on this mission.”

“Well, that’s interesting, I guess, but why would I want to know that?”

“We were taught at the Academy that a Captain’s main priority is his ship. I threw in the bit about how much cargo we have to save in order for us to know if and when the mission is successful.”

“Yeah, but right now I need to know where the Pimbockers’ raiding ships are.”

“Theoretically speaking, they’re all over the map” the tactical officer stated, flatly.

“No, I meant right now, where are they with respect to the convoy we’re escorting?” Rodgers clarified.

Just then the pretty personnel officer stepped onto the bridge.

“I can help you with your problem” she stated.

“Thank goodness!” Rodgers replied.

“You are under-represented in officers who are descendant from people who were originally from the Southern hemisphere of Mars. But, if you demote your navigator, and promote Lt. B’alayer, you will be fine.”

“That’s not the problem I needed help for.”

“A Captain’s top priority is supposed to be his crew!”

“Look, not to be obstinate” Rodgers began, “but the way I see it, my immediate problem is that I don’t know where the bad guys are in relation to the convoy we’re supposed to be protecting. And, since I’ve already asked for this information twice, I’d really appreciate it you all would stop telling me the sort of information I’m ‘supposed’ to want, and give me what I asked for.”

All of the bridge officers assumed expressions of shock, the personnel officer especially so.

“We don’t use the term ‘bad guys’ any longer, sir.”

“Why not?”

“We can’t presume to know our opponents’ motives, much less if they are good or evil.”

Rodgers sighed, and slumped into his command chair.

“The first bridge officer who tells me where the, yes, bad guys are, and what we can do about them, gets a promotion.”

A junior officer, manning a console in the corner of the bridge, activated the viewing screen and spoke up.

“Sir, if you will look past the blue blinking light indicating our position, and the cluster of white lights showing the convoy, you will see three red lights indicating the position of the Pimbockers. They are currently attacking the lead ship of the convoy, but they are within range of our weapons. Our main batteries are currently trained on them, and are only awaiting your order to begin firing.”

“Open fire!” Rodgers ordered.

A bluish-white particle beam leapt from the Geetim, ripping into the hulls of the Pimbockers’ ships. One was blown apart, and the other two limped off.

The bridge erupted into a shouting argument, about who had delivered the information that was most important to Rodgers’ victory. Amid the din, the Captain motioned for the junior officer to step over.

“What’s your name, Lieutenant? How did you know precisely what I needed?”

“My name’s not important sir.  I knew what you needed because of a two-hundred year-old book, Game Theory in Management, by Michael Hatfield. He explored the epistemology of management information systems, but dealt with the subject in such a way as to make his insights intuitive to lay management.”

“Interesting. Where can I buy this book?”

“It’s available at http://www.gowerpublishing.com/isbn/9781409442417, for a very reasonable price.”

And then, everyone was happy, and peace and joy returned to the galaxy.

The End.

In my previous blog, I blathered on about how project management techniques often fail to perform as advertised in the information technology world, and for what reasons. Now, I want to examine how information technology fails project management in general, and for what reasons.

I was once in a project management office with a fellow who was intent on setting up an information stream that would deliver a report indicating the number of hours budgeted on all of the projects within that offices’ purview, by person, and then compare that to the number of hours those people were actually charging.  He was absolutely convinced that this comparison would yield a highly valuable piece of management information, and was not to be dissuaded. Nevertheless, I gave dissuading him my level best.

“First off, Biff,” I began (Biff wasn’t this guy’s name, but the name “Biff” does sound as if it might belong to someone who’s belligerently clueless, much like the antagonist in the Back to the Future franchise), that piece of information isn’t relevant.”

“How can you say it isn’t relevant?”

“For the same reason that comparing budgets to actuals is irrelevant. Just because you’re doing it on a line item by line item basis doesn’t suddenly make it meaningful.”

“But we have to be able to manage hours on these projects!”

“You’re sought-after information doesn’t accomplish that. What if a project substitutes two junior-level engineers for one senior-level engineer? The cost may actually go down, but your system would raise a red flag. And that doesn’t even address the whole issue of cost performance. Imagine a task budgeted with $25K in labor, and $75K in machinery. Let’s say it comes in at $70K in labor, and $25K in machinery. Your system would go insane, indicating a severe overrun in a task that, in fact, came in under budget.”

Then came Biff’s coup de gras, or so he thought:

“Why wouldn’t you want to know that information?” he taunted.

I think this question is the last refuge of pseudo-intellectual PM scoundrels. Good management is heavily reliant upon information, and by asking the question Biff was, in essence, daring me to contradict this obvious axiom.

“Besides the fact that that information is irrelevant, all information requires time and energy to collect, process, and deliver. In this case, all of the energy needed to set up your system would be utterly wasted. Furthermore, we could use that time and energy in pursuing relevant information – but not if we set up your system.”

Added resistance to Biff’s idea would eventually lead to its abandonment, but I believe this sort of discussion happens thousands of times a day, in hundreds of organizations. As I discuss in my recently-released, must-have book Game Theory in Management (Gower Publishing, 2012) all management information streams must be evaluated with respect to its accuracy, relevancy, and timeliness (or ART). If the information system in question is relevant, but inaccurate or not timely, then the tactics needed to improve in those areas should be employed to see if it’s a good idea to save the MIS in question. However, if the information stream is irrelevant, than no amount of accuracy or timeliness can save it, and it must be abandoned.

Take most risk management systems (please! Bada-bing). They may or may not be timely, but their claims to accuracy are patently absurd (80% confidence interval, anybody?). But, most damning of all, is that, once the project’s baseline is set, the output from the vast majority of risk analysis techniques is utterly irrelevant. Project managers inherently worry about things going wrong on their projects. What use is it of hearing the guesses (strikeout) estimates of the odds of the negative-impact event actually occurring? Unless risk analysis alters the response of the project team to the event – and, in virtually every case, it doesn’t – then the amount of time, energy, and expertise that goes in to performing risk management is a complete waste.

I’ve written other articles and blogs with assertions similar to the ones above, and , with rare exceptions, no risk management aficionado has dared to riposte.  Could it be that even they are beginning to realize the intellectually vacuous nature of their techniques?

Back in August of 2008 I wrote and presented a webinar for PMI®’s Information Technology Special Interest Group on the topic of integrating Earned Value techniques in Agile/Scrum environments (“Stop Those Divorce Proceedings!”). A few years prior to that, one of my PMNetwork columns, “Poor Man’s Project Controls,” made similar points about the unnecessary baggage that has been added to what is considered valid Earned Value Management Systems. And, years prior to that, I presented a paper at PMI®’s annual conference in Boston, entitled “The Bottoms-Up Myth,” about the absurd business practice of mandating a re-estimation of a project’s remaining budget, adding that figure to its cumulative actual costs, and then pretending the resulting Estimate at Completion had intrinsic value.

While the first work (obviously) was aimed at IT projects specifically, the latter two were not. What they all have in common is that they addressed parts of legacy project management that many so-called experts insist must be part of any valid PM information system or approach, but which, in fact, detract from the overall business models of the project where they’re applied, as well as their owning organizations in general. And those are just three examples – there are many, many more of instances of techniques and practices that are considered by the PM intelligentsia to be absolutely vital to “doing” project management correctly that are singularly counter-productive, and have no place in general PM approaches, but are even less appropriate in IT projects.

Consider the standard approach to configuration management. The stodginess of the whole process of identifying the needed change, capturing its scope, estimating the new budget and schedule, writing it up in a Baseline Change Proposal, and getting that BCP approved by the appropriate stakeholders is the probably the single strongest reason that Agile/Scrum was developed in the first place. Think about that – the traditional approach to a major aspect of project management was so moribund that an entire adjunct specialty line of project management was developed, just so IT projects could get around it.

Okay, so how did it become so stodgy? Well, in the construction industry, a favorite tactic of sneaky contractors bidding on cost-plus type contracts is to place a bid that is known to be lower than what they think they need to complete the project. Then, once they win as the lowest bidder, they begin to process change notices and proposals in an attempt to fool the customer into raising the budget ceiling. That’s why the change control process became so highly scrutinized, and why the layers of review and approval were put in place, all appropriate for that industry. Apparently, the experts did not hail from the software industry, where the inability to process rapid changes in input and output functions, not to mention overall processing, often proves fatal to the organization’s ability to meet customer expectations.  Add in the fact that cost-plus contracts are not quite as common in IT projects as they are in construction, and the possibility that some basic precepts of project management being introduced and codified that have little or nothing to do with best business practices in disparate industries becomes near-certainty.

Configuration management isn’t even the most egregious example of standard PM practices having a poor fit in the IT industry. Try performing a risk analysis based on a Monte Carlo simulation on an IT project to see what I mean.

What’s the remedy? I think IT project managers need to be fearless in their readiness to modify, or even abandon, many of the techniques associated with traditional project management, and to completely ignore PM experts from other fields who maintain that they are not “doing” PM properly. In this regard, I may be making PM writer history – I’m actually advocating not adopting aspects of traditional project management!

Just sit right back, and you’ll hear a tale

A tale of a fateful trip

That started from this tropic port

Aboard this tiny ship…

(Opening lines from the theme from United Artists Television’s Gillagan’s Island)

At the risk of alienating many readers, I believe anyone over the age of 30 knows what came about as the result of that “fateful trip.” Seven sitcom actors are “stranded” on Coconut Island, located in Kane'ohe Bay, Oahu, and repeat one of several plots to comic (?) effect for 98 episodes.

Now, back to the real world: what if the current state of project portfolio management theory was utterly lost, unable to overlay any of its prevalent hypotheses onto the tons of facts pouring in from the real world cause-and-effects of the modern macro economy in such a way as to explain them? Would the current array of quants and market analysts inform those who pay them? Would the award-winning economists of this world actually step up and admit that they didn’t know which trends would impact the direction of millions of wealth-creators and in what way in the next few years, months, or even days?

To ask the question is answer it. Of course they wouldn’t. The truth is that modern portfolio management theory can no more “manage” portfolios than they can predict the next incident of Bob Denver's character accidentally thwarting the attempt to get off of the island, and for the same reasons. While significant macroeconomic activity that will impact an organization’s complete listing of projects and assets will inevitably occur, as will incidents of naïve, but well intentioned bumbling from one particular castaway, it’s really quite impossible to accurately describe when, and under what precise circumstances. So, how do you know if your “portfolio management” organization and/or software is truly lost? Here are some hints:

·         The portfolio management function (or software) has no idea of the delineation of the project management and asset management realms.

·         The strategic management function appears to be little more than high-level asset management, or has as its ultimate goal the “maximizing of shareholder wealth.”

·         Your organization has a robust risk management system, and their analysts charge directly to all major projects (this particular one is a dead giveaway).

·         There is no regular, reliable information feed of the status of the organization’s proposal backlog, nor win rates (in dollars) based on customer and type of work.

·         Sadly, another sure indicator that your organization’s portfolio managers should probably take up residence in bamboo and grass huts occurs when they rely on software that is simply expanded versions of platforms that had previously served as general ledger, critical path, or earned value management systems.

I’ve already blogged at length of this inability to quantify the future as many claim to be able to do as part and parcel of their so-called portfolio management systems. So, what’s my alternative? I can capture it in three words:

Robustness in response.

When the unexpected occurs, as it always does, the organization with the best response will always beat out the one without. Is there, then, a systemic way of enacting the Boy Scouts’ motto, “Be Prepared”? Yes, and it lies with the ability to model your organization’s strengths and weaknesses across the three axes of asset, project, and strategic management.

Okay, how does that happen? Well, to get the full 411, you are going to have to purchase my recently-released, must-have book, Game Theory in Management (Gower :Publishing, 2012). Or keep reading this blog – at this rate, I should relay all of the research that went into the book along about 2020.