Game Theory in Management

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.

I once had the unhappy experience of working as a project controller for a woman who had a very poor concept of good management in general and Project Management in particular. Among her sillier quirks was her oft-stated opinion on the optimal answer to the common job interview question “Where do you expect to be in five years?”, or its derivative, “What do you hope to accomplish in this position, should it be offered you?” This wonderful answer she had in mind, that would instantly impress any interviewer? It was “I want to be in your job.” I suppose she thought it was the perfect combination of audacity and ambition-signaling, but I found it kind of puckishly threatening, should I ever hear it in the capacity of interviewer. Sure enough, that exact response showed up in an e-mailed list of “stupid interview answers” that I received years later.

I bring this up in order to examine the implications of PM-oriented software continuing to advance in both sophistication and ease of use. Though I have often decried what I’ve tagged the “black box syndrome,” where project controllers or PMs input certain data elements into either Critical Path or Earned Value Methodologies (CPM/EVM) software packages and expect the “right” answer to simply pop out in one of the available report formats, the hard truth here is that those analysis techniques that used to require an experienced/highly educated hand to process and deliver is now do-able by more medium-to-entry-level practitioners using the right Management Information System(s). Some of these implications include:

• By the inescapable rules of supply and demand, what was previously considered advanced skill in PM information production and analysis is now becoming more commonplace, and will tend to erode the salaries that it had previously commanded…
• …meaning that, if a given PM or PM Analyst wishes to be paid wages previously experienced, they need to get better at what they do.
• However, it also means that the software developers creating these more and more advanced tools will need to understand the epistemological challenges in front of the PM community writ large, and avoid chasing down useless information products.

Though the first two bullets look like bad news, the third one is, in my opinion, clearly good news, because I have seen precious little indication that recent improvements in the software tools in the PM realm represent an advanced grasp of these challenges. They seem to be stuck in re-inventing that which is already in existence, with an occasional foray into sniping a bit of information that actually belongs in the Asset Managers’ realm (specifically, the general ledger). And it is this aspect where our friends, the PM Guidance-producers have, ironically, helped those who tend to be stagnant in their PM capabilities. I’ll explain.

Certain PM Guidance-producing tracts advocate for information streams that add no real value to the PM’s toolbox. Consider the following pieces of information that some PM packages offer:

• Comparisons of original budgets to actual costs, at the line-item level.
• Analyzing the percentage of activities that have start-to-start relationships in the schedule network.
• Forecast odds of a specific task being impacted by a so-called “risk event.”
• Identification of a given project’s “stakeholders,” who must be “engaged,” usually without serious analysis of their status as friend, foe, or neutral.
• The generation of Ishikawa, or fishbone diagrams, that have no clear guidance on what constitutes a proximate, or even a material, cause.
• There’s actually at least one CPM program that allows you to check a box on any particular activity’s detail sheet that forces it onto the critical path, regardless of the schedule logic.
• …among many others just as dopey.

If these initiatives are the ones the PM-generating software engineers are pursuing, then they are wasting their time, and the day that software-assisted entry-level practitioners can displace the more experienced PMs gets pushed further into the future. In a very real sense, the software companies creating such tools are being very philanthropic – they’re virtually guaranteeing continued demand for those PMs experienced enough to not waste time on such information streams.

And, for those experienced PM-types who do think that comparing budgets to actuals is a swell idea, you should keep volunteering for those various guidance-generating organizations that agree with you. For the reasons I’ve outlined above, you’ll be doing real PMs a huge favor, as you both take your viewpoints out of the real world of Project Management, and continue to mis-direct the software companies that would otherwise reduce the demand for true PM expertise.

PM philanthropy indeed, without even knowing it.

Since the name of this blog is Game Theory In Management, and we game theorists can only go so long without a good payoff grid, I think at least some portion of GTIM Nation is expecting one. I’ll oblige, not just to get my payoff grid fix, but because using one will really help illustrate this week’s point (honest!). Previously I’ve written about how typical Project Management Offices (PMOs) will tend to establish themselves, hire talent, issue guidance, and expect the macro organization to, well, start “doing” Project Management. I’ve also pointed out that, as common as this approach is, it’s almost always doomed to fail. A more complete analysis of poor PMO tactics appears in my first book, Things Your PMO Is Doing Wrong (PMI Publishing, 2008), but this blog will address an issue from the proverbial 35,000-foot perspective.

Recall my previously asserted structure, that, when providing virtually any good or service, the providing organization should recognize the axiom “Quality, affordability, availability – pick any two.” Briefly,

• A quality product available now is likely to be expensive.
• A quality product that isn’t expensive is likely to have a queue waiting to procure it.
• If it’s affordable and available right now, it’s not likely to be of high quality.

I strongly believe that this axiom holds sway in the creation and perpetration of the PMO, and the advanced PMO Director will recognize it and plan accordingly. Of course, the newcomers to PMO theory will insist that all three aspects are attainable, and that’s okay. As I will show later in this blog, I’ve been disagreed with before, and they’ve been wrong before.

So, now to my favorite part, the payoff grid. Consider:

Scenario A’s PMO strategy is appropriate for those organizations that have a sufficiently robust RFP – to – Proposal – to – Contract Initiation tracking program, so as to give the PMO Director sufficient time to attract or retain the PM talent needed to support the portfolio. When this strategy is implemented without such a capability, the results can be cringe-worthy, as personnel are frantically sought out and just as quickly laid off, leading to frustration on the part of the PMs in the organization as well as mistrust among the PMO’s team members themselves. Infighting ensues, and it doesn’t end well.

Scenario B is common in organizations with a captured clientele. If its PMs cannot resort to hiring outside PM support, or set up shadow PM organizations within the company, they must engage the institutional PMO, and pay whatever rates established. Interestingly, it’s this scenario’s strategy that’s most likely to generate true advancements in the art and science of Project Management, since they retain an advanced capability in something of a secure management environment. Alas, relatively few competitive organizations are set up as to allow this kind of strategy, since contracts tend to be awarded to the lowest bidder.

Scenario C, while appearing to invite scorn from more advanced PM practitioners, is actually quite viable. To those who turn up their noses at the idea that compromise in matters of Project Management is unacceptable, I would like to ask: when was the last time you had fast food? Did you demand Wagyu beef in your drive-through burger? Why not?

Okay, you see my point. There’s a world of projects out there that don’t need a Baseline Change Control Board, or Variance Analysis Thresholds documented in a Project Management Plan. And, of course, I would maintain that there are no projects needing a Risk Management Plan. In organizations that have a large percentage of their project portfolio comprising these kinds of projects, the PMO that can deliver a simple Earned Value Management System, free of the ridiculous “requirements” slathered onto it by those nefarious guidance-generating organizations, will succeed, and in dramatic fashion.

For the Whippersnapper Scenario, where a belief that a quality PM service can be provided immediately and affordably, if only the adequate level of “leadership” (read: fear and intimidation) is used, I have a question: what do you believe you are doing differently? These scenarios will naturally occur from time to time, but never last. Underpaid talent won’t take long to find greener pastures, and a robust training program that introduces fresh replacement talent into the pool isn’t itself cheap.

I’d like to leave GTIM Nation with this thought for the week: take a realistic view of which two of the three elements your PMO seeks to deliver, and work on those strengths while preparing for criticism for the aspect you have made a conscious decision to de-emphasize. Your team will thank you for it. Don’t look back; but, if you are tempted to do so, just set up a quick payoff grid…

Fully participating members of GTIM Nation know that I like to make references to Star Trek (the original series [TOS], the one that aired before the insufferable introduction of deus ex machina plots ruined the rest of the franchise). There are several plastic models of the starship from that series, the Enterprise, and some of them are quite good. One in particular is large enough to feature detailed versions of the only two interior areas of the ship that are visible from the outside, the bridge (due to its being covered by a clear dome), and the shuttle bay, but only if the shuttle bay doors are open. The particular kit I’m thinking of here has a bridge so detailed that it’s possible to depict a Klingon battlecruiser on the main screen, which I think is really cool. For the whippersnapper contingent of GTIM Nation, TOS Klingons were always the bad guys, and the Enterprise ended up destroying two and severely damaging one of these types of battlecruisers (destroyed: “Errand of Mercy,” “Day of the Dove;” severely damaged: “Elaan of Troyius”).

Now let’s do a little configuration management. I do not claim to be an expert in Starfleet operations, but in none of the Enterprise’s encounters with Klingon battlecruisers are the shuttle bay doors open, which kind of makes sense. The shuttle bay has to be de-pressurized when launching or recovering shuttlecraft, and there does not appear to be an anchoring mechanism for the craft when they are stored in the bay. Given the frequency with which bridge officers are thrown out of their chairs during battle scenes, it’s easy to imagine shuttlecraft falling out the back of the ship should the bay doors remain open during combat. In short, any configuration manager worthy of the title would know that, when building this particular kit of the Enterprise, if the Klingon battlecruiser is depicted on the bridge’s main screen, then the shuttle bay doors need to be closed, and vice versa. This is, arguably, the only configuration management conflict for building this kit. And yet, at least one of the YouTube videos on completed versions of this model depict this exact configuration, which I consider to be unfortunate.

Meanwhile, Back In The Project Management World…

ProjectManagement.com’s theme for December, philanthropy, has far more relevance to PMO functionality than might be readily apparent. I am going to argue that the organization supporting the PMO, as well as the PMO itself, must be intrinsically philanthropic in order to succeed. I’ll start with a precise definition of the term. Google’s definition is “the desire to promote the welfare of others, expressed especially by the generous donation of money to good causes.”[i]  Wikipedia says “Philanthropy means the love of humanity.”[ii] I have asserted previously in this blog that managerial leadership requires three key aspects – the Leader Manager must:

• have an advanced technical capability. Few things are more frustrating to a project team than having the technical agenda set by an incompetent.
• be enthusiastic about pursuing the optimal technical approach, alone if necessary. This communicates a confidence that weather-vane managers do not have, and cannot fake.
• (Here’s where the philanthropic angle comes in) care about the people on the team. If the team perceives the Leader Manager does not particularly care about them personally, they will not be enthusiastic about advancing that manager’s technical agenda.

Since “our people are our number one asset!” has been a staple of organizations with any kind of mission statement for generations now, how can a PMO Director ascertain when such a statement is simple boilerplate façade, and not indicative of an at least minimal level of the organizational philanthropy needed for PMO success? In other words, how can the PM know if the organization is sufficiently “willing to promote the welfare of others” to enable the PMO’s mission to succeed?

While there may not be a single litmus test to differentiate such organizations, there does exist a “tell,” a clue that the macro organization is so beset with anti-philanthropic pathologies as to all but eliminate PMO success. This tell comes in the form of an often unstated but nevertheless unmistakable aspect of corporate culture: do these people believe that their employees are lucky to be part of the organization?

It’s not an idle or trivial aspect of corporate culture. If the macro organization believes that most if not all of the rank and file are truly fortunate to be working for them, then that aspect of the narrative will have devastating effects on performance. After all, if the employees are genuinely blessed to be working for so wonderful an organization, why on Earth would they ever offer up novel ways of doing business? Don’t they owe their highly serendipitous circumstances to the very people who developed those processes in the first place? Better to keep their heads down and signal conformity than risk losing their opportune environs.

While macro-organizational arrogance can be highly off-putting on a personal level, in the business realm it’s out-and-out crippling to the very innovations needed to advance virtually any capability, but particularly Project Management. Sure, people will work for them, and spend considerable time and energy in performing their jobs in such a way as to keep their superiors happy. But in those industries where innovation is crucial to not only getting ahead, but to even surviving (hint: that’s all of them) an arrogant corporate culture, the very opposite of a philanthropic one, is a clear sign that attempts at advancing a PM capability are most probably doomed. Just as one should never engage in warp-speed combat with the shuttlecraft bay doors open, you can’t have both an advanced PM capability and a corporate culture lacking in philanthropy.

We know from the TOS episode “The Doomsday Machine” that the helm of the Enterprise has an indicator of when the shuttlecraft bay doors are open or closed. While detecting the “you are all lucky to be working here!” narrative may not be as Boolean as a colorful indicator light, I would recommend that all PMO team members become adept at gauging that condition, and adjust implementation strategies accordingly.

[i] Retrieved from https://www.google.com/search?client=firefox-b-1-d&q=philanthropy on December 8, 2019, 10:49 MST.

[ii] Wikipedia contributors. (2019, December 1). Philanthropy. In Wikipedia, The Free Encyclopedia. Retrieved 17:50, December 8, 2019, from https://en.wikipedia.org/w/index.php?title=Philanthropy&oldid=928702612