Game Theory in Management

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.

In his best-selling book The Black Swan; The Impact of the Highly Improbable (Random House, 2007) Nassim Taleb likens what investment brokers, commodities traders, and stock exchange analysts do to snatching nickels from the path of oncoming steam rollers. If I could be so presumptuous as to paraphrase Taleb, another way of putting that would be to say that those who make a living managing portfolios do so while adopting tenets of management theory that are not only flawed, they actually lead to a perspective that prevents the ready identification of profound economic hazards.

In one of my previous blogs, I made reference to a few of these management ideas:

·         The point of all management is to maximize shareholder wealth.

·         Risk Management techniques are applicable to all potential project events, both positive and negative.

·         Quantitative Analysts, or “quants,” on whom the seeming whole of Wall Street investors depend, can consistently generate usable causal analysis of market trends based on observations of thousands of data points pertaining to the various markets.

The first bulleted assumption, which has been pushed by business schools all over academia as irrefutable for decades, is one of the easiest to overturn. Consider what happens during a hostile takeover, as an example. Typically, when a hostile takeover begins, the target company’s stocks jump in value, often significantly. Therefore, if the point of all management was to maximize shareholder wealth, then, in a hostile takeover, no acquiring company would ever follow through on the attempt, and no target company would ever resist. And yet, over and over you see potential target organizations not only failing to sit back and happily watch their company’s equity go up, they will actually engage in tactics that negatively impact their profit and loss statements (like taking a “poison pill”) to avoid the takeover. Clearly, the “maximize shareholder wealth” meme has its limits, but those consultants, accountants, and professors whose paychecks depend on the acceptance of that assertion will never admit as such. And, as such, the theories they propagate that have as a component the maximize shareholder wealth assertion will ultimately prove flawed.

Take also the Risk Management crowd’s basic analysis techniques, the Decision-Tree Analysis and the Monte Carlo simulation. Each requires large amounts of speculation from control account managers, along the lines of identifying potential project-impacting events, their potential impact, and the odds of their occurrence. Once these numbers are collected, the Risk Management aficionados simply love crunching those numbers in various formulas (which, invariably at some point pull in a Gaussian curve) and pretend to deliver some quantification of how the project’s future will unfold. This fails for two very simple reasons:

·         The data used to feed these analyses is pure speculation, and

·         The future cannot be quantified.

As for the quants, they may have been absent from statistics class the day their professors made clear that correlation is NOT causation (generally stated at the beginning of the first day of class). Instead, they pore over massive amounts of data associated with their areas of investment, seeking to place causal links between predecessor events and successor changes in wealth creation or destruction. Then, when they believe they have discovered a certain causal loop, they will make recommendations one way or the other when the presumed causal predecessor events manifest again. I’m not saying they're stupid – far from it. I’m going, however, to paraphrase Ronald Reagan, and say that they just know lots of things that just ain’t so.

With management “science” notions such as these (among many) influencing the current academic debate (not to mention the myriad software platforms) on what constitutes portfolio management, it’s no wonder they entire area of discussion is completely, well, screwed up. Want to know how to navigate your way to a legitimate portfolio management system? Either order my recently-released, must-have book Game Theory in Management (Gower Publishing, 2012), or stay tuned to this blog. The former will give you your answers immediately, the latter will take a bit more time.

I was thrilled when Cameron sent us Projectmanagement.com writers the theme for October, since it so closely aligned with the extensive research I conducted when writing my recently-released, must-have book, Game Theory in Management (https://www.ashgate.com/default.aspx?page=641&calctitle=1&pageSubject=2064&pagecount=0&title_id=11616&edition_id=11979). Have you ever noticed how often management writers offer up novel or different definitions of the term "portfolio management?" I have, and I believe when writers employ this tactic (known as “showing your machinery”) it is a dead give-away that that particular term has never been adequately defined. Think about it: when the (lucky dog) writers for Sports Illustrated write the first paragraphs of their articles, do they ever take the time to define, say, what a football is?

Think about how many different definitions of “portfolio management” are out there. They all point toward some high-level, all-encompassing function that simultaneously “recognizes” the individual elements comprising the portfolio, while having a clear vision of the so-called big picture. Which is it? And, before you say “It’s both!”, ask yourself: if “portfolio management” is nothing more than some conflation of the micro and macro aspects of project/program management, why are those software packages that pretend to deliver “portfolio management” really little more than project management packages with a few asset management techniques thrown in? (For more on this, see my last blog.)

As I have blogged before, Isaac Asimov’s iconic Foundation trilogy introduced the concept of Psychohistory, discovered by the character Harry Seldon. Psychohistory is a structure that allows the future to be predicted via calculation. Obviously, such a structure has profound implications, most readily grasped by the politicians and captains of industry in Asimov’s projected future. Seldon and a group of scientists are sequestered away to a secret location to safeguard both the insights of Psychohistory and the existing (future) technology, since the galaxy has been calculated to be on the verge of a civilizational collapse. Seldon seeks to shorten the intervening “dark ages” by millennia.

While Asimov provides scant mathematical or theoretical insights into exactly how Psychohistory works, this reader came to the conclusion that it was some combination of game theory, risk management theory, and network theory. Interestingly enough, in the novels the whole scheme is nearly undone by the introduction of the character known as The Mule. The Mule has psychokinetic powers of persuasion, and nearly undoes the entire calculated recovery timeline. Being a mutant, his influence could not have been calculated or accommodated within the Psychohistory structure.

Like Psychohistory, the portfolio management branch of management science theory makes appeals to the capacity to evaluate situations and circumstances that are too complex to reduce mathematically, much less calculate optimal alternatives. Okay, it’s time for a little uncharacteristic (?!) Hatfield bluntness here. The products on the market today that claim to be capable of performing portfolio management are hopelessly inadequate to the task. So, too, is the body of literature that claims to address it (with the exception, of course, of my previously-mentioned, must-have book!). There are simply too many parameters to take into account. Adding to the mythology are several management science tenets that are accepted as absolutely true, but are, in fact, utterly invalid. As long as these tenets cling to portfolio management software and theory like Great Lake lampreys, neither should be taken seriously. Some of the most notable of these tenets include:

·         The point of all management is to maximize shareholder wealth.

·         Risk Management techniques apply to all potential project events, both positive and negative.

·         Quantitative Analysts, or “quants,” on whom the seeming whole of Wall Street investors depend, can consistently generate usable causal analysis of market trends based on observations of thousands of data points pertaining to the various markets.

Okay, let me go ahead and pull the pin on my rhetorical grenade and roll it out on top of the board room table. Each of the assertions in the previous three bullets is demonstrably false. Want to know the truth about them?

Well, to tempt a reputation as a tease, there are two ways for my readers to become informed about this particular topic: either keep reading this blog, or buy my previously-mentioned recently-released, must-have book. The more clever among my readers, who want more on this topic, can post challenging comments and provoke a response -- theoretically.

Back when I was working for Advanced Sciences, Inc., the company sent its upper management to a retreat in North Carolina to take a week-long class in Project Management. Since the attendees came from four different offices scattered around the United States, there were some mild dialect differences that led to a couple of entertaining interactions. But there was one phrase that seemed to be employed a lot, without a consensus on its meaning. That phrase: “slam dunk.”

To around half the attendees – those who, no doubt, either played basketball or at least kept up with a favorite team – the meaning was clear: a can’t-miss shot, something rather automatic. The other half seemed to think the term meant something analogous to getting slammed, or, put another way, to encounter excessive resistance, often from an internal source, for executing a certain approach to resolving a problem. Now, I was aware that the phrase meant very different things to different people, but I believe very few of the other attendees were so aware. Some of the outcomes were hilarious.

Manager with definition A: “So, if we can get our schedule baselines in good shape, then any government audit of them would be a slam dunk.”

Manager with definition B: “So, we don’t want that!”

Manager with definition A: “Don’t want what?”

Manager with definition B: “A government audit.”

Manager with definition A: “But I just got done saying it was something of a sure thing.”

Manager with definition B: “Like death or taxes.”

Manager with definition A: “What’s like death or taxes?”

Manager with definition B: “The government audit.”

Manager with definition A: “Of our baseline?”

Manager with definition B: “Yeah, I was agreeing with you.”

Manager with definition A: “Oh. Okay.”

Something similar happened when I was sent on a train-the-trainer class of a certain scheduling software platform that was attempting an expansion into portfolio management, which just happens to be this month’s Gantthead theme.  This expansion involved including in the scheduling software’s capabilities things like timesheet routing and approval, travel expense routing and approval, miscellaneous expense routing and approval – in other words, things that traditionally fell within the realm of the General Ledger, and Asset Management. At the end of the course, I and my colleagues were revealed to the president of this software company (his name may be recognizable to some of my readers, which would lead to an easy ID of the software I’m talking about, so I can’t be specific here. Sorry.) to be, not subcontract training company employees, but one of this software company’s larger customers. An audience with the president and his top veeps was hastily arranged, and our opinions of the new capabilities invited.

“You are established as a platform for project management information” I began. “If you wanted to expand your capability, you should have sought to perform more diverse PM functions, like Earned Value reporting formats, or creating the Basis of Estimate. Instead, you have expanded into areas usually covered by an organization’s General Ledger. So, if some company were to use your new portfolio management capabilities, would these supplant their existing systems? Or augment them? Was there any thought about how this new portfolio management system would interact with the General Ledger?”

I could almost see the light bulbs going off in the heads of the veeps, who were seated to either side and slightly behind the president. At least I was resonating with somebody.

“We’re confident that these new features will enhance our software’s ability to provide portfolio management capabilities…” the president began, as what he was saying began to strongly resemble the muffled trumpet used as a stand-in for whenever an adult communicates with Charlie Brown or one of his friends in the Peanuts specials. It seemed to me that an awful lot of effort went into this software’s upgrade without everyone involved being clear on the exact definition of “portfolio management.” It was almost as if this organization’s leaders were targeting information streams involved in executive management decision support, and coding them in to the existing system as adjuncts without really evaluating the valid components of portfolio management.

In my subsequent posts this month, I will explore the proper role of both the portfolio management function, and its appropriate supporting information streams, as well as those systems that pretend to provide the portfolio management function, but fall laughably short, and why. Yeah, yeah, I know – there are a lot of definitions of “portfolio management” out there, and many of them sound quite reasonable. They are, however, either wrong, or, at best, incomplete. I actually have the complete answer, and it’s shown in my recently-released must-have book, Game Theory in Management (http://www.ashgate.com/default.aspx?page=641&calctitle=1&pageSubject=2064&title_id=11616&edition_id=11979). Given the number of organizations hawking portfolio management capabilities, and the frequency with which they get it wrong, it should prove to be an interesting October.