Game Theory in Management

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.

During my recent vacation, I was in a large Museum of Art located on a major University’s campus. More than one of the pieces on display was, essentially, a blank canvas. When I read its description plate, the verbiage began “While this may appear to be merely a blank canvas, it is actually…”

That’s when I stopped reading. It was a blank canvas, and no fifty-word assemblage on a brass plate was going to convince me otherwise. But there it was, hanging in a prominent place in an otherwise reputable gallery. I’m sure my experience is not unique – what is currently praised as art would not have passed for practical jokes 500 years ago (“Hey, guys, did you see that blank canvas Rembrandt revealed the other day? Isn’t he a gas?”).

But that’s the thing with art – it’s virtually impossible to define it in such a way as to encompass all that claims to belong to it, kind of like listening to risk analysts attempt to define what all is involved in risk management.

Science, on the other hand, is easy to clearly define. It’s the method by which theories are overturned or affirmed by repeatable, observable phenomena, preferably via reproducible experiments in a laboratory setting. Exhibit A has to be a piece (get it?) that award-winning economist Paul Krugman wrote in the New York Times on the topic of when the stock markets would recover from the 2016 United States Presidential election, saying “If the question is when markets will recover, a first-pass answer is never.”[i]

Oooops. I guess that wasn’t a very good example of successful Management Science based on projections stemming from verified theory (or even a half-baked guess), since in the 12 months following the 2016 election the markets added 35% to their value. Indeed, if we cut Mr. Krugman a bit of slack, and, by “never recovering” he meant a 5% retreat that stayed there, then his “never” scenario was off by a whopping 40 points within a year of his analysis. In contrast, the old PM device of predicting the future, of calculating the Estimate at Completion by dividing the Cost Performance Index (CPI) into the Budget at Completion (BAC), has been shown to be accurate to within 10 points. In other words, the lowliest Project Controls analyst is wayyy better at predicting the future than award-winning economists, which, I suppose, points to the vastly more truly scientific nature of PM over modern economics.

While Mr. Krugman’s analysis probably should not be used to make financial decisions, it is an excellent example of the kind of silliness that passes for usable Management Science, and this silliness isn’t confined to the New York Times. It’s all around us, and Project Management isn’t exempt. But, as in economics, it’s possible to push out volumes of documents and guidance that has no basis in actual scientific findings and still receive accolades from the community at large. Ah, but that’s where the “art” aspect of PM comes in. Think of Project Management as the generator of an information stream, one that feeds basic business needs (cost and schedule performance), but also fuels irrelevant or extraneous curiosities (the difference in contingency budget dollars between the 80% and 90% confidence intervals). Like art, those who imbibe in this information stream will develop their preferences for the kinds of data they believe to be crucial, must-have elements, and those they can do without. And all that’s okay by me. It’s only when third-party “experts” weigh in that the silliness proliferates.

Let’s go back to the art museum. There were several rooms in the galleries that featured works that would inspire people walking into that particular room to stop and exclaim how beautiful was the piece they were observing. I hung around the blank canvas room for a few minutes to conduct my own little survey. Nobody – nobody ­­– commented on how lovely the blank canvases were. They were, at best, curiosities. People wondered aloud how they came to be considered works of art in the first place. So, why were they there? I believe it's because a third party – neither the artist nor a person who saw the work and thought “Wow! This belongs in our museum!” – thought that paying museum customers ought to think of the work as, well, art.

Which returns us to the art of Project Management. When actual PMs select the information products they prefer to increase their odds of bringing in their projects on-time, on-budget, they communicate to the community at large which information streams are essential, and which are extraneous. It’s when third parties, those who do not pay for nor generate the information streams themselves, nor are they on the hook for completing work successfully, weigh in to inform everybody what they ought to use that quackery proliferates.

Put another way, I wonder if risk managers have framed blank canvases hanging on the walls of their homes.

[i] Krugman, Paul, “The Economic Fallout,” retrieved from https://www.nytimes.com/interactive/projects/cp/opinion/election-night-2016/paul-krugman-the-economic-fallout on August 20, 2018, 14:42 MDT.

Since my undergraduate degree is in English, and I have a particular affinity to the works attributed to William Shakespeare, I was somewhat taken aback to learn that the phrase “hoist with his own petard” originated in Hamlet (Act 3, Scene 4, the “Closet Scene”). In this particular case of ironic reversal, Hamlet is referring to the scheme between Claudius, Rosencrantz, and Guildenstern to have him murdered during a trip to England. I used to believe that it meant to be hung with the noose that the schemer had tied for someone else; in fact, it means to be blown up by a bomb created by the bomb-maker himself. In a play full of ironic reversals (Laertes is killed by the saber he himself had poisoned; Claudius is forced to drink the poisoned chalice he had intended Hamlet to drink, among others) this particular reversal remains ensconced in modern English idiom; even those who have no idea what the archaic meaning of “hoist,” or any idea at all what a “petard” is (or was) knows the meaning of the phrase. That is, perhaps everyone except Project Managers.

Not all PMs, to be sure, but a dangerous percentage. My regular readers know that I’ve spent considerable computer pixel-ink on the perniciousness of Processors, those claiming membership within the PM community who are more interested in making project teams obey what they consider the right way of doing PM, as opposed to Producers, who simply bring their projects in on-time, on-budget. The Producers know, often intuitively, that even simple Earned Value and Critical Path systems can produce extremely valuable cost and schedule performance information, information without which their jobs become extraordinarily difficult. Ah, but there’s the rub, as the melancholy Prince of Denmark might say. Processors know this too, but have no intention of allowing the notion that simplified systems will still deliver powerful information streams to become commonly accepted. No siree, these Processors are out to make a buck on their idle musings, and want the Producers to be the ones to pay.

The strategy to monetize their flawed business models is as familiar as it is transparent. They set up an approach similar to the jaws of a vice. The first premise is one that’s indisputably true: to track cost and schedule performance on project work, the Earned Value and Critical Path methodologies are irreplaceable. Projects that had eschewed these methodologies early in the project cycle ended up failing spectacularly, and remain as cautionary tales for any major project’s manager who believes himself to be so advanced as to not need such traditional tools. Critical Path and (especially) Earned Value are simply indispensable, and any PM claiming to the contrary is going to experience a major PM debacle. Oh, maybe not the very next project, or the one after that. But, sooner or later, it will happen.

The other jaw of this vice is where the Processors come in. You see, Earned Value is really a very simple concept. By placing a value on how much of the projects’ budget has been actually accomplished, or “earned,” much valuable information can be gleaned. In fact, the calculated Estimate at Completion (EAC), arguably the most valuable piece of Project Management information out there, can be accurately and reliably derived from two parameters: cumulative percent complete, and cumulative actual costs. That’s right: divide the former into the latter, and you have an estimate that’s been shown to be consistently accurate to within ten points of the real at-completion costs. Something similar happens in forecasting when the project will finish, based on performance. Divide the percent complete figure into cumulative duration, and you have a reliable estimate on total duration. It really is that simple.

“Not so!” claim the Processors. They will insist on a long list of both marginally and completely superfluous data collection and analysis techniques, such as:

• The time-phased budget must be derived using up-to-date resource dictionaries.
• Ditto for the Basis of Estimate.
• Variance Analysis Thresholds must be set tightly, as tight as possible.
• Ditto for Change Control Thresholds.
• Did I mention Change Control? The members of the Change Control Board must be highly educated and diverse stakeholders, some of whom probably hate your project.
• Time-phased Estimates to Complete, comparing the original Basis of Estimate to the actual costs on a line-item basis, “bottoms-up” Estimates at Completion…
• And don’t get me (re-) started on risk management.

I could go on (and often do), but you see my point. The second jaw of the vice, that of an overly-complex EV system being required, because, well, reasons, is pushing the whole concept of setting up and operating such systems into insufferable, if not intolerable territory. Already Earned Value is being slandered with a reputation of being so difficult and onerous to use that the newbies in the PM world avoid it like it’s a curse.

And here’s the ironic twist: many self-identified “experts” within the community are the ones larding up these Management Information Systems with the unnecessary requirements that make them less likely to be widely accepted, or employed. I would normally make some plea here, along the lines of “Hey, guys, we’re doing this to ourselves,” except for the fact that that’s not entirely accurate. The Processors are doing it to the Producers. Maybe it’s a sort-of payback for all that success that the Producers produce, while laughing at the Processors behind their backs.

Just keep in mind, you Processors: Fortinbras doesn’t know nor care about the subtleties or murderous machinations of the Danish Royal Court, and yet he’s the one crowned king at the end of the play.

And very few of the rest of them had a happy ending.

A few weeks ago I wrote about the main corollary stemming from the Triple Constraint/Iron Triangle (the familiar PM concept that Scope = Cost = Schedule, and you can’t change one without changing the other two). This corollary asserts that among the product/service characteristics of affordability, availability, and quality, the customer should expect/pick any two. In other words,

• High-quality, affordable goods or services will require a wait;
• High-quality goods available immediately will be expensive, and
• Readily available, affordable goods won’t be of the highest quality.

This corollary is axiomatic among seasoned practitioners; in fact, ignorance of this effect is a “tell” that the person you’re dealing with isn’t very advanced in the PM sciences.

I want to combine this axiom with another established theory from economics, and I believe the combination will reveal some rather interesting insights. The combine-ee is the notion of how first, second, and third-hand purchasers change the nature of the industry supplying any given good or service. A first-hand purchaser is a person who is buying something for themselves. They seek out the vendor who matches most or all of their parameters, and perform the purchase themselves. A second-hand purchaser is someone who is buying something for another person, as in a gift. They often don’t know all of the intended recipients’ expectations in-depth, and will usually have a budget figure in mind that the intended recipient may or may not have been willing to spend.

Here's where it gets interesting. A third-party purchaser is buying something for another person, but not using their own money. Nassim Taleb’s recent book Skin In The Game addresses this phenomena, and is worth reading. An essential take-away is that, if you don’t have a direct interest in, this case, the way a management information system (MIS) should be designed and implemented, you shouldn’t weigh in. At all. My take is that such ones are so removed from the first-party purchasers’ model that any assertion or decision they make is bound to be flawed, and lead to poor management decisions.

Now, let’s combine these two truisms of affordability-availability-quality, and third-person purchaser limitations, and see what they yield in Project Management space. Let’s say you are the director of a PMO of a medium-to-large company, and the PM for a recently-won project comes to you for project management-type support. The canny PMO Director will ascertain the PM’s inclinations with regards to the availability, affordability, and relative quality of the support sought, and seek to accommodate these parameters. Conversely, the moribund PMO Director will have already decided the level of “quality” that the PM ought to have requested, leaving the only negotiating points the price and availability. Since most PMs will need their Critical Path and Earned Value systems in-place at the project’s start date, these PMO Directors will assume that their erstwhile clients will be compelled to purchase such support at whatever price point the PMO Director stipulates. This is how PM is sent backwards within industry, and at warp speed.

Consider what happens in second-party PM support scenarios. The PM of the new work goes to the PMO Director for support, but the level of PM rigor has already been established by the organization, usually through procedures. Hopefully, this level of rigor was placed into the Basis of Estimate in the project’s proposal, which means that the level of affordability, availability, and quality has already been established. So, no issues here, unless the new work isn’t entirely consistent with the other projects within the portfolio. Presumably, if the pre-determined level of rigor was too expensive, the proposal would not have won in the first place.

Now we come to the third-party option, and it’s not pretty. In those instances where some “stakeholder” places themselves into a position where they can demand a higher level of PM information system rigor, while they neither pay for such an increase, nor are they the ultimate recipients of the successful completion of the scope of the project, the opportunities for quackery increase exponentially. Assuming a position of PM authority or expertise, these people are in a position to damage both the suppliers’ ability to meet the clients’ expectations, and the latitude that the clients have in selecting contractors who meet their specific mix of availability, affordability, and quality. Since most contractors work on a Cost Plus Fixed Fee/Award Fee, or even Firm Fixed Price basis, the Affordability parameter has already been fixed. The Availability issue has already been established as well, since the cost and schedule baselines are typically fixed at the point of contract award. This leaves only the level of PM rigor which, if we are to observe the Triple Constraint, must remain consistent with the other particulars of the project. “Not so!”, say those “guidance”-generating organizations that like to assert their “expertise” in the PM industry. All major projects must perform analyses that the contractor PMs did not originally intend to provide, nor which their customers wanted in the first place. To do otherwise is to commit some inchoate sin against the purity of Project Management!

I find it fascinating that these guidance-generating organizations against whom I often rail never seem to publish documents calling for more affordable, or more available PM information systems. It’s always the same old thing, about how everyone needs to slather on the irrelevant Management Information System lard, like comparing basis of estimate to actual costs at the line-item level, time-phasing the Estimate to Complete, or performing Monte Carlo risk assessments. In fact, if you are involved in having to provide any of these analyses, I already know something about your project. It was either not competitively let, or else there are third-party stakeholders asserting some level of control over the PM information systems.

Forced to do useless things in PM space? Blame the Processors entrenched in the guidance-generating industry.