Game Theory in Management

The Girl In My Life was an American television show that ran in the 1973-1974 season. It featured a person whose life had been bettered by a specific woman, who was in attendance in the audience and would join this person on the stage and receive a gift package. I was pretty young when this show aired on ABC, but the one episode I saw made quite an impression on me. It featured a fellow who came out on the stage to announce – I swear I’m not making this up – his status as a superhero, and he was dressed for the part. He appeared to be wearing tights and a cape, with some odd symbol on the middle of the costume’s chest area. The thing was, though, that he had essentially the same body build as (American actor) Jack Black – pudgy, and not very muscular at all. But he was all-in to the part: he announced his superhero name, enthusiastically asserting that his mission was to fight crime and protect the innocent, complete with little hops and uppercuts thrown at imaginary foes. In my estimation, had he actually encountered a hardened street criminal his life expectancy could probably be measured in nanoseconds.

Then came the really funny part: he announced the name of The Girl In His Life, confidently claiming that he could have never attained his superhero status if not for the support he received from her. The announcer calls this poor woman up on stage to ask her a few questions prior to actually presenting her with the modest gift package. I have to admit she held up quite well, considering the only genuine superpower being exhibited was her ability to not die of embarrassment.

Meanwhile, Back In The Project Management World…

In the ongoing discussion of hybrid management systems, how to evaluate them to know which are useful and which are probably bogus, I’m struck by how many assumptions are blithely accepted as true without any real evaluation against basic standards of management science. This is particularly ominous because of the prevalence of management systems (or information streams) that grossly over-sell their efficacy. Just as one does not become a superhero by putting on spandex, a management information system does not become valid by making a claim to “hybrid” status, or pushing out a piece of information with a certain name or title.

Specifically, our friends the accountants are really good at extracting from the general ledger the information asset managers need to perform their duties. I’m not arguing to the contrary. However, they fail utterly when they make forays into Project Management space, which they tend to do on a regular basis. Here’s a couple of incontrovertible facts: comparing budgets to actual costs does not generate a cost variance, and extrapolating spend rates and projecting them forward does not create an accurate or reliable Estimate At Completion (EAC). Adding insult to injury is the notion that the previous two assertions become false if only the “analysis” is performed at greater and greater levels of detail, or granularity. I’m sorry, but that’s just dopey. And yet, the practice of ascertaining cost performance based on this very comparison is so widespread that I’m fairly confident that it has attained near-universal acceptance.

Then we have another one of my favorite targets, the risk managers. Here are the two incontrovertible facts I would love for them to recognize: Gaussian curves can’t be used to predict the future (being willing to place a bet on the outcome of future events, which is what insurance providers do, is not the same as reliably predicting what’s going to happen to a given project), and stochastic ranges based on ordinal scales represent utterly useless pieces of (dis) information. Some management writers (with whom I am entirely in agreement) have gone further, arguing that such analysis is worse than useless, in that it is often genuinely misleading.[i] In the risk managers’ and accountants’ cases, they attempt to generate what are admittedly extremely valuable information streams from systems that simply can’t support them. What they end up sending up the reporting chain is the equivalent of corpulent delusional non-combatants inserting themselves into environments where they not only do not belong, but their presence is comically inappropriate.

Ah, but they have those wonderful superhero names titles, such as an estimate that’s in the “80% confidence interval,” or the “time-phased Estimate to Complete” (Hey! I wonder if that fellow from The Girl In My Life had a superhero name of “80% Confidence Interval Man”!). The reality is something very different when it comes to PMs attempting to acquire a greater amount of relevant management information, the data they’ll need to increase the odds of bringing in their projects on-time, on-budget. Standing in the epistemological breach against the monstrous spikey-mawed opponent of ignorance, the last thing they need is for a Jack Black-esque character, clad in spandex, to jump in and assure them of success.

Even if they do receive a modest prize package from the risk managers and accountants at the end.

[i]Hubbard, Douglas W., The Failure of Risk Management, Wiley and Sons,2009.

There have been several iterations of programs in the Star Trek universe, as well as multiple movies based on two of them. They span centuries and vastly different galaxy locales, but the one thing they all have in common is: someone is the commander of the starship at the center of the epic, and, in three of those instances, the starship’s name was Enterprise.

Seein’ as how I’m a baby boomer, my personal preference is William Shatner as James Tiberius Kirk, from the original series (sorry, The Original Series, or TOS). He was insightful, courageous, and a full reading of his commendations received is so long that it would make a court martial prohibitively protracted. Kirk also had the advantage of having been created by writers who understood basic plot structure. As all us baby boomers know, having been taught basic plot structure by eighth grade, the most compelling stories and scripts have an introduction, rising action, a climax (where the protagonists overcome the central problem or antagonists through a combination of endurance, talent, and some luck), and then on to falling action and the denouement.

Jean-Luc Picard, played by the brilliant actor Patrick Stewart, was captain of the Enterprise in the series Star Trek: The Next Generation (TNG). Unfortunately for Jean-Luc, his writers would consistently (and infuriatingly) engage in the extraordinarily cheesy device of dues-ex-machina. Dues ex machina dates from ancient Greek theater, where a script would develop along classical lines but, at the climax, some Greek god would be literally craned onto the stage, and use his or her supernatural powers to resolve the plot’s central conflict. Even the ancient Greeks knew this was a singularly unsatisfying way to resolve a play, but Star Trek TNG’s writers were seemingly bereft of this millennia-old insight. Almost every week, TNG fans were presented with a central problem, rising action, and, at the climax, the “god” of superior understanding would be craned onto the sound stage. Oh, it was just all a big misunderstanding! We Federation officers failed to appreciate where you seemingly hostile aliens were coming from! We’re sorry!

Finally, the prequel series, Enterprise, featured captain Jonathon Archer, played by Scott Bakula. Sadly for Captain Archer, Enterprise also suffered from dismal writing. I would sum it up as an ongoing request for permission from all non-humans to be allowed to play in the galactic sandbox, and being okay with it when all the other players were mean to us, because, well, reasons.

Meanwhile, Back In The Project Management World…

Some years ago there was a big push from a few of the major Project Management-related software producers to introduce “enterprise” programs, or systems that could handle all of the information needs for a given organization’s executive management. It was, perhaps, one of the earliest attempts at developing a hybrid management system. Of course, if an organization could actually produce such a comprehensive and insightful information stream, it could expect profit margins in the same ball park as the current crop of tech giants. These initiatives usually crashed and burned, and I’m pretty sure I know the reason why – it’s because their writers didn’t follow the right plot structure.

As an example, I’m familiar with one producer of a Project Management-related software that launched an initiative to provide such an across-the-organization system by combining their already-established PM system with utilities that would normally belong to the general ledger. I actually had an opportunity to interact with this company’s senior management around this time, and attempted to tell them why I though this initiative was vulnerable, based on my opinion that all organizations had to have a working general ledger in order to pay taxes – in other words, to get into and stay in business in the first place. Since poaching various aspects of the general ledger in a bid to claim enterprise-wide utility would endanger the workings of the general ledger itself, I predicted that few would use the upgrade. Although I was ultimately proved right, at the time the execs didn’t want to hear it, and breezily dismissed me and my ideas.

The part of the structure they got wrong is familiar to my regular readers: management science deals with three very different arenas. Asset Management is about maximizing shareholder wealth, and its primary information base is the general ledger. Project Management is centered on delivering projects on-time, on-budget, and its primary information streams come from Critical Path Methodology (CPM) and Earned Value Methodology (EVM) systems. The often mis-understood Strategic Management is NOT simply a high-level conflation of the other two. Instead, its target is to maximize market share, either through advertising, improving the product or service, or by undermining the competition. Therefore, any software platform that can legitimately lay claim to “enterprise” management must be able to distill the timely, accurate, and relevant information streams from each area, and produce that information in a way that allows the organization’s top decision makers to understand the trade-offs among the three areas inherent in the high-level decisions they make. I discuss more precisely how to do exactly that in my second book, but for the sake of brevity in this blog post I’ll leave it with the notion that simply peeling off aspects of the systems from one area and attempting to tractor-beam it into another is doomed to fail. In other words, craning in a piece of data from another management arena and expecting that to resolve your organization’s central conflict is a truly cheesy approach to management.

I’ll leave my readers with one last observation on the value of valid management information system structures as analogous to science fiction naval architecture: the original series’ (sorry, The Original Series’) Enterprise has been expertly restored and is conspicuously placed in the Smithsonian Air & Space Museum. The other Enterprises, well, aren’t.

On most dark and stormy nights like this one, I would be sitting at my desk and looking at the letters stenciled on my frosted glass door, ylnatS yrrebpsaR, etavirP evitceteD, being one of only a few Project Management-oriented private investigators. But on this night I was in disguise, attending a high-level meeting of a panel of Project Management “experts.” They were completing the final draft of a guidance document intended to provide the structure for a so-called hybrid PM system for projects that didn’t really match the Agile/Scrum model, and sought to retain appropriate elements of traditional PM. Even though this meeting was being held in a typical convention center/hotel ballroom, well-lit and no armed guards, I had a sneaking suspicion that Monolithic Corporation was behind it. If there was a way to subvert proper PM techniques and approaches AND get the sub-standard version adopted by the PM community at large, Monolithic would find it, and this little comfab had all the markings of just such an initiative. However, my investigation was almost derailed before it had even started.

“Hi! My name is Jane, and I’m the president of the Division of Quantitative Governance. I don’t remember seeing you at these kinds of events” a woman dressed in a pant suit blurted. She took a moment to stare at my nametag. “Who do you work for, Andy …Strawberry?” She suppressed a snicker.

I was aware that, at one time, DQG was a significant player among the management-oriented professional societies, but had steadily lost membership. Jane seemed to attend all these seminars and symposiums, and, if she recognized me, I would be in trouble.

“I’m an independent consultant” I replied, which was technically true. “I have only a few clients, but they would be interested in whatever comes out of this meeting if it’s going to influence future guidance or requirements on how IT projects should be managed.”

“Oh, it’s going to influence it, all right” she exclaimed, apparently satisfied with my cover story. She continued, “Even now several large corporations are involved, ready to adapt whatever the writing committee recommends for combining these two types of systems.”

“Like a mutation?” I asked.

“It’s NOT a mutation, it’s a HYBRID!” she stormed.

“Whatever.”

Jane watched as I strolled over to the room’s tables, where the actual writers were hunkered down over their laptops, papers strewn about. There were several tall projection screens towards the front of the room, displaying the text under review at the moment, which happened to address change control. One of the writers appeared to not be engaged with the other “experts,” so I approached her.

“Hi!”

“Hi yourself.”

“Did you have any participation in that portion of the guidance?” I asked, gesturing towards the screen on the left.

“Maybe.”

“I was wondering if you would be kind enough to fill in a little bit of detail. The text appears to be using the terms ‘sprint,’ ‘epic,’ ‘Work Package,’ and ‘Control Account’ interchangeably. Are y’all asserting that sprints are to epics what Work Packages are to Control Accounts?”

“George!” she called out to one of the conversant groups. “Get over here, we have an inquisitive one.”

George strode up to me, dressed in a suit and holding a brandy snifter in one hand, and a cigar in the other. He was a large man, clearly not to be trifled with.

“Hello. Do you have a question for the expert committee?”

“Not necessarily. I was just reading the text on the screen on the left, and it appears to use some Agile/Scrum and traditional PM terms interchangeably in your mutant system.”

“It’s a HYBRID, not a mutant. And, so what?”

“Whatever. Unless you clearly define which Work Breakdown Structure elements ought to be covered by an Agile approach, and which shouldn’t, then the whole change control effort is in danger of being applied unevenly.”

George took a long pull on his cigar, and blew it towards me. Not exactly in my face, but not really trying to avoid it, either.

“The expert committee believes that the synergy created by leveraging these two methods into one, coherent model, will drive economies of scale and quality can be achieved.”

The word salad was an instant tip-off that this “expert” committee was in the process of influencing PM community standards in such a way as to justify an avoidance of doing formal aspects of project change control by invoking Agile/Scrum terminology, and drowning any dissent in a river of cross-discipline jargon. At this moment Jane walked up.

“I couldn’t help but overhear your question” she began. “That’s really an interesting perspective. Have you presented any papers at any of these PM seminars or symposiums?”

Concerned that my cover was about to be blown, I initiated a retreat.

“Thank you for your answer, George. I understand perfectly. But, hey, look at the time. I need to excuse myself.”

In contrast with the number of times I had to sprint for my car to make a dashing getaway from Monolithic employees, this time I casually strode to the exit, made my way to my car, and drove away. Either Monolithic doesn’t have the reach or power I thought they did, or my disguise held, since it appears Monolithic has made no attempt to prevent me from posting this rep

When discussing hybrid Project Management systems (ProjectManagement.com’s theme for September), I think it’s very important that we be extra careful about what two PM approaches we’re combining into one. Consider two movies portraying human hybrids, Spider-Man (2002), and The Fly (1986). The former features teenager Peter Parker having his DNA altered by the bite of a genetically-modified spider, making Peter much stronger, more agile, and able to ascend walls with ease. With these powers Peter becomes a superhero, saving people from crimes, certain-death collisions or falls, and, naturally, supervillains.

Conversely, scientist Seth Brundle has his genetic code altered when he tests his teleportation device on himself, and a housefly happens to be in the transmitting chamber as Brundle is translated into energy. When he is re-constituted in the receiving chamber, he has housefly DNA encoded into all of his cells, which causes him to gradually transform into a nightmarish human/housefly hybrid and land the movie about him in the Science Fiction/Horror genre.

Meanwhile, Back In The Project Management World…

Back in the first half of the 20^th Century, when what we now know as Project Management was first gaining attention as Product Management, there was no talk of “hybrid” anything (at least not that I could find). You simply had a manager who was in charge of a specific product, and oversaw its life-cycle, from development through to delivery onto store shelves. Freed from the Asset Management aspects of the other managers’ responsibilities (fuel costs of the plant, promotion/demotion decisions for the staff, etc.), these Product Managers began to realize a need for different types of information streams, as in which tasks had to be completed prior to others starting (Critical Path Methodology), and, at the current rate of performance, how much would a given production run cost (Earned Value).

The term “hybrid management system” did not appear in the literature in the early days of the Cost/Schedule Control System Criterion, or C/SCSC, the (United States) Department of Defense guidelines for how their contractors should perform cost and schedule performance measurement on major projects. From my review of the literature (and enduring the word salad definitions – how, exactly, does one “recycle” a management structure?) the term “hybrid management” is almost exclusively confined to Information Technology (IT) projects and Quality programs, the latter having the characteristic of demonstrating attempts at complying with quality management standards without using excessively robust or expensive tools and processes. Each of these has profound PM implications. Let’s start with IT.

Have These Guys Ever Even Watched Australian Rules Football?

Agile/Scrum PM came about to address the highly fluid and dynamic nature of Scope Management within IT projects. The traditional aspects of change control, of setting up a Baseline Change Control Board, establishing cost and schedule change control thresholds, scheduling regular meetings of the BCCB and processing Baseline Change Proposals – all of these practices were far too moribund and constricting for a change that had to be either rejected or accepted and implemented within hours, if not minutes of its inception. Since IT projects are notorious for coming in late and over budget, the entire codex of PM couldn’t be abandoned, so some form of hybrid was clearly appropriate. By replacing the traditional scope management practices with “sprints,” which combined to form “epics,” which could be managed with far more latitude than other types of management approaches, a true hybrid management approach was born. The progress of the development of Agile/Scrum Project Management has to be considered a success, if due to nothing else than its widespread acceptance and utilization.

Conversely, the attempts at developing a hybrid Quality Management approach appear to have been uneven, at best. In previous posts I have recited the old business axiom of “Quality, affordability, availability: pick any two.” The Quality Managers seem to either be unaware of this truism, or reject it, since an improvement in quality of any product or service is usually presented as an indisputably desirable goal. For those organizations whose parameters of availability and affordability are already set, an improvement in quality, with its concurrent subtraction from the other two characteristics, is simply not an option. So, how do you get the Six Sigma guys to give you a break? Lay claim to doing all that quality stuff, just not at the level they want it! Hence, a “hybrid” management system is born, but, in this case, there is a far greater likelihood that whatever emerges from the teleporter receiving module is going to give first-year MBA candidates bad dreams rather than something that verifiably improves quality.

So, what’s the litmus test for which kind of hybrid management scheme introduces superheroic powers to its practitioners, and which kind translates them into six-foot-four biped insects? It is this: if the hybrid approach actually helps deliver project scope on-time, on-budget, it’s good, even if it appears to interfere with the projects’ ability to recreate an audit trail. If the hybrid approach is designed to keep Processors at bay, it’s monstrous.

Since we’re doing management science here, keep in mind that it is entirely possible – even probable – that we have our own version of the “mad scientist” archetype. And these aren’t plotting to make themselves super-strong by altering DNA sequences. They’re dreaming up hybrid management schemes. Let’s make sure the movie version doesn’t land in the Science Fiction/Horror genre.

Yes, you read that right.

No, I’m not being reflexively iconoclastic, nor am I venting again about the overuse of clichés in business writing.

But here’s the thing about experienced Project Managers: projects are, by definition, one-off efforts. Of course, they are often similar to other projects, sometimes almost identically so. I also readily concede that many universal tactics, strategies and approaches are reliable, and should be employed. Experienced PMs often have a rather extensive array of technical approaches to their work assignments, and are usually right in their selections of said tech approaches. So, what’s the problem here, exactly?

Black swans. Black swans are the problem.

As originally articulated by Nassim Taleb in his best-selling book of the same name[i], a Black Swan event is one that has the following characteristics:

• It is unexpected and unpredictable,
• It has a significant impact, and
• After it has occurred, it’s almost universal human nature to believe that it could have been predicted, or at least planned for or mitigated.

The term gets its name from the discovery of black swans in Australia by the Dutch in 1697. Prior to that discovery, had you asked anybody in the world (outside of Australia) what color were swans, they would say “white,” since that was the only color of swans ever encountered. Had you pressed them further in this zoology quiz of 1696, and asked “Are you sure there are no orange, purple, green, or black swans?”, the answer would have been “Of course not.”

These types of events happen all the time, and projects are particularly susceptible to them, since they are, again by definition, novel. This being the case, the best PMs would be those who are able to have the most robust response to the unpredictable events that occur to the project, events that are not necessarily addressed by one of the canned strategies in that particular PM’s experience. Conversely, the worst PMs are going to be among the most experienced, who, nevertheless, cling to strategies that had worked on semi-analogous projects in the past, even when those strategies are clearly failing. In these cases the PMs' experience is actually working against them. They can easily become convinced that it’s not the technical approach to the unexpected problem that’s failing, but the Project Team’s reluctance to accept the flawed approach, or some other organizational factor (here we often hear of “cultural” issues, or “resistance to change”). As the repeatedly failed strategy is employed over and over again, the Project Team becomes less willing to execute it, reinforcing the PM’s notion that it’s the fault of the team and not the strategy. I’ve seen this tailspin ruin many a project.

As if that wasn’t bad enough, PMs have to deal with a factor they may not have heard of (unless they read my books or this blog), that of Metcalf’s Law. In short, Metcalf’s Law is the basis for much of Network Theory, with its main offshoot being the notion that very small variances in some nodes in an extensive network can have a cascading effect and deliver substantial, or even catastrophic impacts on other nodes, or even the entire network. It’s also known as the Butterfly Effect, encapsulated by the question “If a butterfly flaps its wings in Brazil, does it cause a hurricane in Texas?” Like Black Swan events, they are both significant in consequence, and utterly unpredictable.

Here’s where the risk managers come in. If they were to be completely intellectually honest, they would admit that what they are doing is monetizing the fear that PMs have of encountering Black Swan events, or being caught flat-footed by a cascading impact that began as a small perturbation. Consider also one of the main tools used in modern risk analysis, the generation of ordinal scales. Often presented as a grid, with an estimate of the probability of a given future event on one axis and its “impact” on the other, ordinal scales are obviously based on the experience of the analysts filling it out. Not only is personal experience highly variable from one risk analyst to the next, but memory is also inconstant. We tend to remember things we like to remember, and forget those that we don’t, even if those experiences have a direct bearing on the accuracy of the experienced-based risk assessment grid.

By overworking analyses based on Gaussian Curves, risk managers provide … well, what, exactly? Because generating stochastic ranges on things that might happen with their associated estimated impacts does absolutely nothing to stave off either scenario. It’s simply a reflection of what the experience of the risk analysts leads them to assert what they think the PM ought to worry about.

Essentially, the canny PM will know that experience isn’t always the best teacher. In fact, it’s often not even a friend.

[i] Taleb, Nassim Nicholas, The Black Swan; The Impact of the Highly Improbable, Random House, 2007.