Game Theory in Management

The central problem when discussing creativity in the Project Management realm (ProjectManagement.com’s theme for February) is that we’re looking at two very different sides of the same coin. On the one hand, you have the templates, procedures, and canned strategies germane to the PM universe, including Work Breakdown Structures (WBSs), Earned Value and Critical Path Methodologies (EVM and CPM, respectively), Scope Management, and all the rest of the codex in the PMBOK Guide®. As anyone who has endured the PMP® examination process can attest, these concepts are all rather formalized and structured. However, the other hand is a very different schema indeed, where it’s common knowledge among PM practitioners that the ability to bring in a project on-time, on-budget is heavily reliant on finding innovative solutions to the unexpected problems that arrive with a bang at the PM’s front door, solutions that rarely have a standardized, template response. “How shall we find the concord of this discord?” (A Midsummer Night’s Dream). I think that the central question to finding the balance between what’s regarded as standardized techniques in approaching Project Management problems and having the management latitude to do whatever the heck the nominal PM wants to do hinges on one question: Does it work?

Not to put too fine a point on this, but I would like to point out the two criteria for evaluating whether or not something can be considered scientific, even in Management Science space:

• It has to be observable. Explaining phenomena that no one can perceive is as useless as arriving at an 80% confidence interval on a risk analysis.
• It has to be repeatable in an experimental setting. Theories that “explain” one-off occurrences are always suspect.

Based on this criterion, establishing the WBS early in the project is scientifically sound. This technique has been shown to serve well as the basis for the subsequent cost and schedule baselines time and again, while project work bereft of the same is almost always given to failure for any but the smallest, simplest of projects. Likewise, both Earned Value and Critical Path analysis are pretty standard for all but the most basic projects – if you want to have a fighting chance of bringing them in on-time, on-budget, that is. Which brings us to addressing our dichotomy: when is adopting a creative management strategy, nominally at odds with the standardized approach to managing a project well, a good idea? As GTIM Nation knows, any Game Theorist worthy of the name (and initial caps) will resort to a payoff grid, so:

In Scenario 1, the “Doesn’t care enough” bin doesn’t mean that the subject PM is visibly lackadaisical. It very well could be that they are simply so entrenched in their own approaches to PM problems that they can’t be convinced to abandon said approaches. When those canned strategies actually work, then these may be successful in spite of a lack of consideration of alternate, creative tactics.

The PM who cares enough to use tools known to work, but keeps an open mind when either they themselves or a member of the Project Team suggests a novel solution or approach, is going to be highly successful. This scenario is closest to describing The Gamesman archetype from Michael Maccoby’s brilliant work The Gamesman: The New Corporate Leaders (Simon and Schuster, 1976), which, based on Maccoby’s research, consistently experiences the most success.

Now, about that “don’t be dumb” mention in the blog’s title: if the named PM isn’t sufficiently motivated to do what it takes to bring in the project’s scope on-time, on-budget, one way of avoiding the use of the PM tools known to enhance success would be to listen to the Earned Value and Critical Path naysayers, and point to a “creative” management approach that eschews these tools. Experienced Project Controls Analysts have seen this scenario play out time and again, and, yes, they think those PMs trying to pull it off are dumb. Really dumb.

Finally, if the named PM really wants to perform well on the project, but only listens to our friends the Accountants and risk managers on how to do so, then they’re not really doing Project Management at all, but pursuing an obviously deficient derivative.

And I don’t do obviously deficient derivatives in this blog.

As promised at the end of last week’s blog, I’ve finally found a purpose for risk management, though I still refuse to do initial caps when referring to it (for alert GTIM Nation members who would say “You just used initial caps in the title of this blog for “risk management,” my response is, I use initial caps for each word in my titles). Before I reveal this quirky and yet valid reason, let’s take a quick view of the epistemology of Management Information Systems, or MISs (note the initial caps).

The key valid Project Management information streams have the following things in common:

1. They provide the actual decision-makers the data they need to make informed choices on their projects,
2. They further support the creation of an audit trail, or the (truthful) narrative on how the project has been executed, and the circumstances behind that execution,
3. …and they’re deserving of initial caps (e.g., Earned Value Management System, or Critical Path Methodology).

As I have previously pointed out in this blog, risk management utterly fails in number one, and therefore doesn’t qualify for number three. How do I know this? Because of the very definition of risk management offered up by some of their leading figures.

In a point-counterpoint article I contributed to in PMNetwork magazine many years ago, my risk management counterpart defined its purview as encompassing anything that might happen to a project, positive or negative, the latter being described as traditional risk management, the former belonging to “opportunity management.” Of course, management time is finite: the management information system that doesn’t accurately differentiate between where the project is in trouble and where it’s doing fine, and thereby pointing out where PM attention is needed is, well, useless. By their own admission, risk managers maintain that their specialty’s purview covers all things, positive or negative, needing of attention or not.

I’ve addressed many of the other reasons that risk management is such a disappointment in the delivering-relevant-information department in previous blogs, but a quick recap includes:

• Risk analysis (MSWord forces the first letter in a bulleted list to have initial caps) reports tell the PM exactly what? That there’s an X% chance that something will go wrong, resulting in $Y in added costs, or Z days in delays? Is this helpful?
• Especially when one considers that each of the parameters in the preceding bullet is little more than a wild-donkey guess.
• Then there’s their insufferable tendency to couch everything in Gaussian curve terminology (Carl Friedrich Gauss was a person, so I had to use an initial cap there).

“Alright, already, we know your objections to risk management” I can hear the two or three risk manager members of GTIM Nation (note the initial caps) saying, “but you promised a valid use for us! What is it, already?” I’m glad you guys asked.

From the second numbered entry above, Project Management MISs (at this point I’m basically trolling the risk managers with the whole initial caps business) provide a type of audit trail. I would further divide this audit trail into two bins:

• It generates the historical narrative, useful for future PMs to learn how best to tackle similar projects, and
• It gives customers who have, shall we say, an exceptionally developed curiosity about the choices being made by the Project Team, their basis, sensibility, etc., a sense that they’re in the middle of the day-to-day decisions that execute the project.

It’s this second bullet where risk management may actually be indispensable. Think about it: if your customer is hovering over your project so closely that you have to process a Baseline Change Proposal just to go to the restroom, there’s no better way of getting them to ease up a bit than by showing them that you have not only considered all of their worries, but you have “quantified” them in Gaussian curve jargon, and run a series of statistical analyses that would induce granite statues’ eyes to glaze over.

“If everyone minded their business,” the Duchess said in a hoarse growl, “the world would go round a great deal faster than it does.” (Alice in Wonderland, 1865).  So, here are the risk managers, making the world go round a bit faster, and for this they deserve recognition, even in the GTIM blog. I would like to point out, though, that had the risk management community reached out to me and explained the real purpose behind their schtick being to thwart overly hoverish customers (think about it: what customer is going to needle the PM who’s just waiting for an opportunity to discuss the significance of the gap between the median and average time for a given task?), then much of the pixel ink I’ve spent making fun of them could have been saved.

On second thought, and upon reviewing some of the risk management hate e-mail I’ve received, nevermind analyzing what might have been. The odds wouldn’t be good that they would ever receive initial capitalization status.

Looking over the list of techniques, strategies, and technical skills associated with an advanced level of PM expertise can be rather daunting. The more I read on the topic of what constitutes cutting-edge Project Management the less I see any kind of consensus on what makes up the core, or foundation of the PM codex. The most advanced financiers, heads of accounting departments, and even tax attorneys can agree that their industries are predicated on double-entry bookkeeping (developed, incidentally, in Medieval times). Strategic Managers can agree with advertising agency owners and newspaper publishers that the ability to differentiate their customers/organizations’ products or services from competitors (and thereby making them more appealing and gaining in market share) is the basis for their empires. But what are the essential elements of PM? What makes it both unique and necessary? And, perhaps most critical, what’s the best approach to answering the previous two questions?

Attempting to resolve such weighty questions as posited above using a priori arguments and “experts” sitting around hotel ballroom conference tables comparing their curriculum vitae is a fool’s errand, in my opinion. It’s this strategy that so muddied the waters in the first place. What happens whenever any scholastic or management science field of endeavor expands at the rapid pace seen by Project Management is that what would otherwise be a clear distinction between core and peripheral areas of expertise becomes blurred, as such technique’s advocates vie for recognition, if not supremacy. One of the most extreme examples of this came from our friends, the risk managers, who at one time actually tried to define their purview as anything that might have an “impact” to any given project, negative or positive (the latter being re-defined as “opportunity,” and no, I am not making this up).

Okay, so if the last place we should seek an answer as to what makes up the essential elements of PM is the focus group/business school faculty lounges, what does that leave us? As counter-intuitive as this may sound, I believe that much insight can be derived from the opposite of such environs – that is, in the construction trailers and shop-floor cubicles of hard hat and safety goggle-wearing front-line PMs.

Back when I was chasing my MBA I was in a group of students evaluating the business practices of a clothing manufacturing plant in our home town. This was before I had earned my PMP®, but after I had spent considerable time performing project controls functions for United States Government contractors. These contractors were operating under the nascent PM techniques and business rules that required the delivery of cost and schedule reports derived from Earned Value Methodology analysis, including a standard reporting format known as the Cost Performance Report, or CPR. As I and my fellow graduate students were being shown the machines that would take new deliveries of cloth, cut them to specific sizes based on the style of garments (in this case, pants), transfer the cut-outs to various other stitching, riveting, button-holing, zipper-installing, etc. machines, I noticed a certain grey box with wires emanating from it had been installed on each machine. This module produced a report that monitored each step of the process. These reports showed the amount of material originally planned for the lot along with the estimated amount of time for the entire job (the time-phased budget), the amount of energy, labor, and machine time used for that particular step (the actual cost of work performed), and the actual progress being made (the Earned Value figure). Sure enough, these reports were almost identical to the Cost Performance Reports that I had been generating for projects ranging from U.S. Department of Defense radiation research work, all the way to U.S. Department of Energy environmental clean-up jobs. Amazed, I queried the manager escorting us around the manufacturing floor (who was actually wearing safety glasses).

“These reports – are they specific to this place?”

“No, they’re industry standard.”

“Right down to the calculated Estimate at Completion?”

“Sure. We need to know that to coordinate when the next lot can start, and have access to common machines or people.”

“Do these machines come with this automated report-generating capability?”

“Yeah. They all do.”

“Have you ever heard of the Cost/Schedule Control System Criterion, or the Project Management Institute®?” (Just for the record, I didn’t actually say “Project Management Institute, circle R.”)

“Nope.”

I realized then that certain aspects of PM were central to its overarching schema, and Earned Value was one of those. Given that the cause of so many project overruns and delays is scope creep, I’m willing to venture that Scope and Schedule Management (specifically, the Critical Path Methodology) are also core aspects of PM. Using our acid test, using techniques we would have been likely to discover in our front-line PMs’ toolboxes, I’m willing to venture that the following are candidates for exclusion from that core:

• Risk
• Communications
• Quality (which is almost certainly a subset of Scope; however, to the extent it can be cleaved from Scope Management, it belongs on this list.)
• Procurement

A quick note about those last two – I’m not saying that they’re not essential management elements per se. They clearly are. I’m just dubious about whether or not they necessarily belong in the Project Managers’ wheelhouse.

So, for all you Project Management technique advocates out there, anxious to alert the rest of the PM world of the efficacy of your particular practice, ask yourselves this: if you were to pitch your idea to any manager who routinely wears safety goggles, ear plugs, and a hard hat to work, would you have a reasonable expectation that they would buy what you’re selling?

Lagniappe…

Brace yourselves, GTIM Nation: I have a management science world-changing announcement. This blog has actually discovered a key reason to do risk management! Crazy, right? And that reason is…

Look at that! Out of pixel ink for this week. Tune in next Monday for the dramatic reversal GTIM has for our friends, the risk managers!

As long-time members of GTIM Nation are aware, when evaluating technology in PM I like to compare and contrast it to the uneven but dramatic changes in computer science, cosmology, or even medicine. As for the latter, I think it’s fascinating to consider that in 100 years the things being taught in schools of medicine will appear to be as backward as medical technology from 1920 does to us in the here and now. To be fair, though, I readily concede that, had today’s medical tech been described to doctors 100 years ago, they would never believe it. In 1920, Vitamin D had not yet been discovered, penicillin was still eight years away, and the first kidney transplant was 34 years distant.[i] Even though X-Ray technology had been around since 1897, it was only this year that it became a routine part of diagnosing fractures in most hospitals. MRIs are 57 years away, as is angioplasty. Performing an internet search on strange medical practices in history is to review a series of deeds that would be considered torture in 2020.

Meanwhile, Back In The Project Management World…

Circling back to ProjectManagement.com’s theme for January, PM Technical Skills, I can’t help but wonder which PM technical skills will be considered bizarre or incomprehensively backwards by practitioners in the year 2120. But here’s where the analogy to medical science breaks down: Project Management is clearly not a hard science. It deals with the unknown. Yes, much of current PM theory is highly formulated – developing a Work Breakdown Structure, for example (although, even here, I wish I had a dime for every Organizational Breakdown Structure element I’ve found in WBSs supposedly developed by people advanced in Project Management), but it’s undeniable that what real PMs do in the real world is largely dominated by dealing with the unexpected.

“Not so!” I can hear my nominal nemeses, the risk managers, say. They have built an empire on the notion that advances in Project Management technology have provided a window into what is likely to happen to a given project, should the particular management team have the insight to invest in a rigorous risk analysis. My response: really? Let’s take a look at this window into the future, provided by our friends, the risk managers, and see if it’s not analogous to what medical practitioners from 1920 believed was technically advanced.

Read a typical risk analysis report. What you will see is a series of speculations about alternatives to the planned activities in the scope, cost, and schedule baselines, expressed in terms of odds of occurrence and cost and schedule impacts, usually pessimistic. Where do these speculations come from? Almost always from members of your project team whom the risk analysts have identified as subject matter experts – in other words, your Cost Account Managers (CAMs). If you are the Project Manager, ask yourself these questions: do you ever communicate with your CAMs? Do you have meetings with them? Do they not tell you what their concerns are, especially in the near term?

To ask these questions is to answer them. The implication, of course, is that your typical risk analyst does little more than interview your very own CAMs, write down their concerns, ask them to speculate (and let’s be clear here – when these CAMs are asked to “estimate” the odds of something bad happening to their Work Packages AND the cost and schedule impact, that’s what they’re doing: merely speculating) on some parameters, and then re-state these data points in Gaussian curve jargon. Do I have to state it (again)? This is openly fraudulent management science, and I find it hard to believe that it will be well received in the decades to come.

But, for the sake of argument, and out of a sense of humility that I really have no reason to suppose that my points of view will withstand the tests of history, let’s take a moment to assume that the “information” stream emanating from the risk analysts’ reports are valid and usable. What will the future PM do with them, exactly? Let’s say that, in the most recent project meeting, you have a CAM who tells you that she’s concerned that a certain subcontractor won’t be able to deliver on-time, and any delay may impact other activities. Your Critical Path Methodology expert (scheduler) can tell you which activities are dependent on an on-time delivery, and whether or not the task in question has any float to use. What can the risk analyst tell you? That the odds of the delay were originally estimated at X percent? Or that, should the feared delay actually take place, that it could have additional speculation-derived impacts? Does this “information” really help anybody?

I think that last rhetorical question is key. Much as one would think that someone would eventually inquire if the medieval medical practice of bloodletting actually helped patients – or even a single patient – the question has to be asked: how many projects can point to their risk analyses as the proximate cause (or even material cause) of coming in on-time, on-budget? Here in 2020, we can roll our eyes at the known invalid practices of PMs from one hundred years ago, like attempting to derive project cost performance by comparing budgets to actuals. As I have outlined above, I’m pretty confident that I know what current PM practices will cause similar eye-rolls in 2120, and I’ll be interested to see what GTIM Nation thinks will qualify under this category in the comment section.

But I’m not ruling out the possibility that risk management will be in, and management blogs will be considered passé.

[i] Retrieved from https://www.infoplease.com/math-science/health/medical-advances-timeline on 11 January 2020, 21:46 MST.

ProjectManagement.com’s January theme of PM Technical Skills got me to thinking about the sheer number of movies and science fiction novels predicated on the notion that mankind will develop technology that ends up destroying us, or reducing us to near-slavery conditions. A brief list includes:

• “HAL” from 2001, A Space Odyssey
• The entire Terminator franchise (6 movies, a television series, among others)
• Colossus: The Forbin Project (1970 movie)
• I, Robot (both the Asimov series and the movie)
• Omega Man
• I Am Legend
• Too many Star Trek franchise episodes to count

… among many others. Except for the bio-technology-wiping-us-out stories, almost all of them include computers and advancements in artificial intelligence (AI). As I pointed out in last week’s blog, advancements in PM software, while profound, are often given to pursuing irrelevant information streams, meaning we PM-types have a little more time before PM technology either wipes us out, or reduces us to near-slavery conditions (probably).

Consider: ENIAC, the world’s first electronic general-purpose computer, was put into service in December 1945[i]. By 1995 its entire capacity could be replaced by a single chip, slightly larger than a dime, even though the original device required 1,800 square feet.[ii] So, within fifty years the original had been overtaken by advances in technology to an extent almost inconceivable to its developers, and that dramatic difference was 25 years ago. Why is this relevant, you ask? PMI® was founded 50 years ago (well, technically, in 1969), and its growth has also been rather impressive. And yet, nobody seems to be concerned, or even aware, of the possibility that PMI®’s growth represents a threat to the dominant narrative in the business schools. So, as usual, it’s up to me to ask the question, and explore the possibilities.

If PMI® were to take over the business world, what would that look like? I would imagine that would depend on its “hook,” or that attribute which made it attractive to the business world writ large from its inception. I would argue that PMI®’s hook has been to make available the techniques and information streams that enable organizations to execute project work better, cheaper, and faster. This reminds me of the old joke, where two friends camping in the woods together have their camp invaded by a grizzly bear. One of the friends begins putting on his running shoes when the other admonishes “Why are you bothering to do that? You can’t outrun that bear!” To which the friend replies, “I don’t have to outrun him, I only have to outrun you!”

Meanwhile, Back In The Project Management World…

Similarly, those organizations who initially subscribed to the nascent PMI®’s worldview didn’t have to “do” PM perfectly – they only needed to do it better than the other organizations in the field in order to gain a competitive advantage, increasing the odds that said competition would fare more poorly in those projects that they executed. Now here’s where PMI® taking over the world becomes a possibility: by the laws of survival of the fittest, those organizations performing project work who eschewed the technical skills made available by PMI® were more likely to fail, meaning they would drop out of their specific market. Unless such organizations were absurdly lucky, such a winnowing process probably didn’t take much time – almost certainly less than, say, fifty years. Which implies that, as PMI®’s particular blend of academic research and real-world testing continues to push the frontiers of best practice identification (I’m excluding that part of the codex premised on a priori assertions: check my previous blog “When Did A Priori Become A Priority?”), those organizations and PMs failing to keep up risk finding themselves at a competitive disadvantage, soon to be identified and devoured by the aforementioned laws of survival of the fittest. Make no mistake – such laws are as cold-hearted and indiscriminate as the most fearsome take-over-the-world movie monster; and, like the “Colossus” computer, they’re invisible to the vast majority of those whose lives they disrupt.

Of course, I’m not predicting the exact future, where a failure to read The Project Management Journal cover-to-cover will automatically lead to economic disaster for you and your company, any more than the most extreme alarmists predict that the next advancement in artificial intelligence or microprocessor technology will automatically lead to all mankind becoming servants to the computers that run our refrigerators.

Still, I’m not letting my PMNetwork subscription lapse…

[i] Wikipedia contributors. (2019, December 17). ENIAC. In Wikipedia, The Free Encyclopedia. Retrieved 04:46, January 4, 2020, from https://en.wikipedia.org/w/index.php?title=ENIAC&oldid=931194208

[ii] Ibid.