Game Theory in Management

There’s an axiom among experienced writers that asserts you’re not really a pro at this until you make the transition away from writing something that you want get off of your chest, and towards producing something that your readers would actually want to read. I like to keep this axiom in mind when I’m attending conferences on the management sciences. It serves as a valuable litmus test when I’m reviewing the syllabus, to determine which of the sessions is worth my time, and which should be avoided. In those instances where all of the slots in a given time frame are clearly presenters attempting to show off, boast, or re-address intellectual ground that’s been covered so many times it’s taking on the epistemologically equivalent appearance of centuries-old roads used by the Roman Legions, I use that time to check out the exhibit hall, or to get in line early for lunch.

I kind of get a kick out of speculating what would happen if all of the attendees at these conferences were to employ a similar test when choosing which sessions to attend. The boasters and re-treaders would speak to empty chairs, while the ones who have put real effort into assessing a rational approach to problems or issues encountered by many would see their rooms filled to overflowing, thereby sending (one would hope) a clear message to the seminars’ sponsors in general, and their paper-selecting committees in particular: stop with the common knowledge re-iterations, cease the a priori­-predicated yawn-fests, and let your valuable time and space allocations to those who have positioned themselves to provide actual value to potential attendees.

But in order for this message to arrive in the in-boxes of seminar sponsors, we as a PM community need to do something about the supply and demand curves involved. Since it’s pretty clear that there will always be a large supply of potential paper presenters who are there to boast about some wonderful project involving them, and point to some unique aspect of the PM codex as a distinguishing factor that all other analogous projects should adopt, my mission is probably best accomplished by flattening the demand curve. I believe this could be accomplished by employing a few tactics, such as:

• The aforementioned pre-attendance screening, performed by seminar attendees. Maybe we could get a rating system – we’ll call it the GTIM Nation Relevance Score – that would show a numeric value of the subject presentation’s basis in management science techniques.
  • 10 – 7 would be heavily based on either existing, hard-evidence-based scholarship, or original research that includes verifiably objective data, with a minimum of subjectivity, or correlation masquerading as causation.
  • 6 – 4 means that we’re going back over already-established techniques and protocols, with a heavy dose of eat-your-peas-style hectoring about why it’s important to perform them.
  • 3 – 2 score indicates subjective data is being used to draw conclusions (polls and surveys are a dead giveaway), or else objective data is being process through an invalid logical method to assert a pre-determined conclusion. Unless I’m mistaken, this would be the automatic scoring range of every risk management (no initial caps) session I’ve ever attended.
  • 1 – 0 is for straight-up silliness, like the Communications experts who want Project Teams to share all project information with anyone who can be considered to be a “stakeholder.”
• I suppose it’s possible that the review committees will have some sort of epiphany (perhaps their members will be sent links to this blog), and begin evaluating paper/presentation proposals on the basis of the actual validity of the papers’ premise, and supporting evidence as the sole basis for awarding slots.
• I believe that there’s a role in all of this that the people actually sponsoring the events can play, but it’s not a popular idea. I had attended a PM-related seminar, where I gave a keynote address (this was back when I was doing the PMNetwork column gig), and was invited to a post-conference meeting with the sponsors and other presenters. The purpose of the meeting was to generate some sort of lessons-learned memorandum, to help improve the same get-together the next year. When they opened the floor to suggestions, I raised my hand, was recognized, and blurted out “If you really want to improve this thing, remove all attendance fees from paper presenters.” At the time those who had submitted presentation proposals that were approved would have their attendance fees reduced, but not eliminated. I went on to point out that ideas were the coin of the realm in these venues, and, in order to attract better ones, all barriers needed to be eliminated. Like I said, this was not a popular idea.

As much as I would love to believe that a simple ProjectManagement.com blogger railing against the intellectually vacuous underpinnings of what all-too-often passes for legitimate Project Management science could tip the common acceptance scales against them, that’s not gonna happen. On the other hand, if we as PM technique consumers simply stop signing up for what these people are selling, now that would turn the tide. The only question remaining is: have we had enough?

According to antonymsfor.com, antonyms for philanthropy (ProjectManagement.com’s theme for December) include:

husbandry, injury, frugality, conservation, economy, … brutality, self-seeking, selfishness, greediness, meanness, saving, …, scraping, malignity, illiberality, thrift, hurt, harshness, malevolence, unkindness, inhumanity, Skimping, Pinching, barbarity.[i]

When addressing this theme last December, I pointed out that Project Management was performing an extremely valuable service by its very nature, that of significantly improving organizations’ ability to deliver projects on-time, on-budget, and just generally advancing quality of life. But is there an aspect of PM as currently practiced that represents the opposite of philanthropy?

Recall my oft-cited axiom of Quality, Availability, Affordability: pick any two. Now consider what would have happened in, say, the restaurant industry if the self-appointed experts, via guidance documents, standards, and even regulation, mandated a certain level of “quality” for all places that served prepared food. That which we now know as the fast-food industry would have never been allowed to enter the marketplace, since its very foundation was and is based on the idea that they would offer affordable food, available relatively quickly. Prior to the opening of the first White Castle hamburger restaurant in Wichita, Kansas, in 1921,[ii] dining out at a restaurant was simply not done by a sizable percentage of the population, and a rarity for the majority of the rest. By the time McDonald’s had sold 15,000,000 burgers in 1955, [iii] that had all changed dramatically, and the restaurant industry would never be the same.

But imagine if an association of restauranteurs had gotten together and decided that, in order for any food service establishment to be valid, it would be required to provide:

• Tables with tablecloths,
• Attended by wait staff,
• With meals that had to be consumed on the premises,

…in order to stay in business.  No plastic eating ware, no customers placing their own orders, no leaving to eat your food, obviously no drive-through windows – and no $570 billion (USD, 2019 figures) industry.

Meanwhile, Back In The Project Management World…

I would like to turn GTIM Nation’s attention to the impact that certain academic or professional organizations have on the Project Management Industry as a whole. Every time one of these guides comes out, strongly advocating some technical-sounding rule like a specific type of estimate underpinning the Cost Baseline, without any supporting evidence and causality established, I would argue it actually harms the PM world. These assertions are almost always made a priori, with zero evidence offered, or even asked for, as to their validity. Usually, all it takes for one of these rules to get incorporated into some form of official guidance is the unsupported assertion that, failing to prohibit the targeted practice, one or more of the following will inevitably ensue:

• Creation of false variances
• Deterioration of cost-schedule baseline integrity

• Unraveling of cost and schedule baseline integration (as distinct from the previous bullet, which points to the reliability of the baselines, this problem insinuates that the cost, schedule, and scope baselines are inconsistent with each other)
• Hide or obfuscate real variances in the reporting system.

Since it’s impossible to disprove a negative logically, attempting a defense of the targeted PM practice by disputing the original charge is futile. The optimal (if not only) manner to counter this version of the begging the question fallacy, dressed up as an appropriate method of rule-making, is to ask to see the data supporting the assertion. Does someone wish to introduce and formally implement a rule that mandates detailed estimates down to a specific level of the Work Breakdown Structure? Fine. Can this person provide a list of projects that experienced inaccurate reporting, poor baseline integrity, lack of baseline integration, or real variances being hidden that used the more generic Budget Estimate as the proximate, or even material cause? If the answer to the previous question is “no,” which I suspect would be the case in the majority of times if it were asked in the guidance-generating industry, then what is happening and has been happening is clearly outside the realm of management science, a place I don’t believe we PM-types want to find ourselves.

Besides, it would be unphilanthropic to do so.

[i] Retrieved from http://www.antonymsfor.com/philanthropy on December 13, 2020, 10:34 MST.

[ii] Retrieved from https://science.howstuffworks.com/innovation/edible-innovations/fast-food3.htm on December 13, 2020, 17:46 MST.

[iii] Retrieved from https://www.mashed.com/148375/the-truth-about-how-many-burgers-mcdonalds-has-sold/ on December 13, 2020, 17:50 MST.

This, the first blog of December for GTIM Nation, serves two purposes: (1) to bring some holiday cheer to the aforementioned GTIM Nation, and (2) to firmly establish that it was proper for me to go into writing about management science, and to avoid becoming a lyricist. With that, I offer The Twelve Days Minutes of Christmas Project Review.

On the first minute of the review my analyst gave to me

A PowerPoint® Slide Deck.

For the next part of the review my analyst gave to me

A negative cost variance in a PowerPoint® slide deck.

For the third minute of review my analyst gave to me

Poor initial estimate causing a negative cost variance in a PowerPoint® slide deck.

For the fourth minute of review my analyst gave to me

No contingency for the poor initial estimate causing a negative cost variance in the PowerPoint® slide deck.

In the fifth minute of project reviews my analyst gave to me

Two BCPs

For contingency for the poor initial estimate causing a negative cost variance in the PowerPoint® slide deck.

In the fifth minute of project reviews my analyst gave to me

A change board appointment,

Two BCPs

For contingency, poor initial estimate causing a negative cost variance in the PowerPoint® slide deck.

In the sixth minute of project reviews my analyst gave to me

A conference room for the change board appointment,

Two BCPs

For contingency, poor initial estimate causing a negative cost variance in the PowerPoint® slide deck.

For the seventh minute of review my analyst gave to me

Monte Carlo Numbers for the conference room where the change board meets,

Two BCPs,

For contingency for the poor initial estimate causing a negative cost variance in the PowerPoint® slide deck.

For the eighth minute of reviews my VP said to me

“No confidence” in the Monte Carlo Numbers for the conference room where the change board meets,

Two BCPs,

For contingency for the poor initial estimate causing a negative cost variance in the PowerPoint® slide deck.

In the ninth minute of review I said to my VP,

“I think this will work” for the “No confidence” in the Monte Carlo Numbers for the conference room where the change board meets,

Two BCPs,

For contingency for the poor initial estimate causing a negative cost variance in the PowerPoint® slide deck.

In the tenth minute of reviews my VP said to me,

“Good luck with all that” re: “I think this will work” for the “No confidence” in the Monte Carlo Numbers for the conference room where the change board meets,

Two BCPs,

For contingency for the poor initial estimate causing a negative cost variance in the PowerPoint® slide deck.

In the eleventh minute of review my analyst gave to me,

Over target baseline for the “Good luck with all that” re: “I think this will work” for the “No confidence” in the Monte Carlo Numbers for the conference room where the change board meets,

Two BCPs,

For contingency for the poor initial estimate causing a negative cost variance in the PowerPoint® slide deck.

In the twelfth minute of review my analyst gave to me

Justification for the over target baseline for the “Good luck with all that” re: “I think this will work” for the “No confidence” in the Monte Carlo Numbers for the conference room where the change board meets,

Two BCPs,

For contingency for the poor initial estimate causing a negative cost variance in the PowerPoint® slide deck.

*  *  *

For any local chapter PMI® Holiday Parties where this is actually set to music, please shoot me a link to the footage. The best rendition will get a shout-out in these pages, along with the forwarding link.

This blog’s title, of course, refers to the pre-1986 (!) practice of keeping caged canaries in coal mines to serve as detectors of carbon monoxide or other dangerous gasses[i]. The canaries would pass out or die before the humans, serving as an indicator that immediate evacuation was called for, and leading to its clichéd use as a critical leading indicator of something potentially really bad being imminent.

Meanwhile, Back In The Project Management World…

So, what can a cursory review of the development of Change Control (ProjectManagement.com’s theme for November) over the years tell us about macro-trends in Project Management guidance? Plenty. Consider first my oft-stated three criteria for PM Information System’s output to be valid:

• The information must be timely. Old management information ages like milk.
• It must be accurate. Inaccurate management information is worse than useless, since it can actually be misleading.
• Finally, it must be relevant. Any energy or time devoted to collecting the data, processing it into irrelevant information, and delivering said irrelevant information is not only wasted, but could have been used pursuing its valid, relevant counterpart.

Now consider what happens when an ossified, overburdened Change Control process actually processes a Baseline Change Proposal/Request (BCP/BCR). Baseline Change Control Boards (BCCBs), which typically meet monthly, review the BCPs submitted to them, including the plausibility of the reasons given for the change, the reasonableness of the new cost and schedule estimates, and any other particulars that go into such go/no go decisions. If any of the above proves unsatisfactory, the proposing contractor has essentially one of two choices: clean up the verbiage and numbers in the BCP, and re-submit for next month, or continue to manage on the existing, unchanged baseline. I think it’s safe to say that a mutual understanding between the customer and contractor of the scope, cost, and schedule baselines meets my third criterion, and is highly relevant. So, what does the rejected BCP scenario mean for the other two criteria for our PM Information Systems? It damages system validity, since having to re-submit the BCP next month means that the performance data stemming from the at-least-somewhat obsolete baseline isn’t going to be timely, and continuing to manage against a baseline that should have been changed already means that its performance data won’t be accurate.

I also think it’s safe to say that this no-win scenario in the conduct of many BCCBs led to perhaps the biggest deviation from traditional PM practices represented in Agile/Scrum, which really doesn’t have Baseline Change Control “Boards” per se. By assigning specific roles and processes to classes of PM participants from both the contractor and client sides of IT Projects during daily meetings, Agile/Scrum allows for formal, documented, and approved near-real-time changes to the projects’ baselines. Interestingly, Information Technology (IT) projects led the way in Agile/Scrum development and adaptation, probably stemming from the report that up to 45% of them overrun.[ii] When you are in an industry where 45% of project work comes in over-budget, and you develop an advancement to PM science to address this pressing issue, and one of the first and biggest changes you make to the whole PM shebang is to do away with the traditional Baseline Change Control Board, including the overall Change Control process, what does that say about the state that said Change Control process had attained? What it tells me is that this was one area where traditional PM practices had become so overburdened with rules and guidance that it was becoming a hinderance to successful project execution, at least for IT projects.

So, if we use the areas where Agile/Scrum deviated from the more traditional PM techniques and approaches as a leading indicator of where those traditional techniques and approaches may have become moribund, or even obsolete, what are some of the other areas where such deviations took place? Long-time members of GTIM Nation know where I’m headed with this: Agile/Scrum does not have a risk management (no initial caps) component. (Incidentally, on a lark I did an internet search on the term “risk management (no initial caps),” and had a good laugh when this blog came up as the fifth hit.) My takeaway from all this is that, if traditional PM approaches and techniques taken as a whole wish to become more useful and widely embraced, two great places to start would be to streamline the Change Control process, and minimize the risk management (no initial caps) stuff in its entirety.

‘Cuz who wants to share a mine shaft with a dead canary?

[i] See https://www.smithsonianmag.com/smart-news/story-real-canary-coal-mine-180961570/.

[ii] Retrieved from https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value on November 29, 2020, 20:53 MST.

On September 3, 1846 the planet Neptune, which is not visible to the unaided eye, was discovered, but the way it was discovered is what fascinates me. After the discovery of Uranus in 1781, its observed orbit wasn’t the same as its predicted one. Some at the time speculated that Newton’s law of universal gravitation either didn’t work, or worked differently at such great distances from the Sun.[i] However, three mathematicians believed that Uranus’ orbit was being influenced by an as-of-then undiscovered planet farther out in the solar system, and independently calculated where such a body might be located. Johann Gotfried Galle, using Urbane Jean Joseph Verrier’s calculations, went looking for it with a telescope, and found it only one degree off from its calculated position.[ii]

Meanwhile, Back In The Project Management World…

One of the reasons I find this astrology story fascinating has to do with its implications in Project Management Science, along the lines of how we receive and interpret apparent contradictions in the way our projects’ performance unfolds. In a sense, when we freeze our cost, schedule, and (to a lesser extent) scope baselines, we are quantifying the expectations of our projects, and use those parameters to predict where they will be at their completion. When projects come in late, or over budget, there naturally arises a need to know the causes, for educational, economic, or even legal purposes, and the nominal record for ascertaining these causes is the Change Control Log, along with its attendant Baseline Change Proposals/Requests (BCPs/BCRs). Of course, the most commonly-held reasons for PM difficulties include:

• Poor original estimates
• Scope creep (informal, client-induced increases to the scope baseline, not reflected in the other two)
• Contingency event (specifically, in-scope, uncosted)
• An element of vagueness in the scope baseline that allows the contractor to pursue an end inconsistent with the customer’s expectations
• …or poor performance.

Each of these has a nominal response associated with it, which are not appropriate for the others. For example, if some customer representative has verifiably authorized scope that was not included in the original baseline, but did not do so formally, the solution would be to capture that scope, estimate its cost and duration, and process a BCP to update the appropriate baselines. However, this remedy is clearly inappropriate if the contractor has performed poorly. And yet, these causal factors and their appropriate responses have been around for decades, if not longer, which raises the question: Why does the whole change control process tend to be contentious, rather than fairly standard, automatic, and anodyne?

Here’s where the seasoned PMs realize that there’s something else going on here, something that’s not visible to the unaided eye. Consider one of my oft-used axioms, Affordability, Quality, Availability: pick any two. As discussed in this space two weeks ago, in most contracts Availability is already set in stone, since most projects have a contractual start date, if not finish date. Affordability is also set, since contracts are usually awarded on the basis of which contractor submitted the lowest bid that appeared to accomplish the scope. With Quality the most often pushed-aside aspect of the three, we have the following unseen forces pulling on the observable aspects of change control, in the same order from the list above:

• Estimators are often pressured to turn in lower cost and shorter schedule estimates, since these are the parameters that usually determine which organization wins the contract in the first place.
• Contractors are almost always under immense pressure to keep their customers happy, making it difficult to insist that any change or recommended improvement be brought in to the baselines formally, especially if the change is presented as trivial, or part of some form of normally expected (yet undocumented!) performance.
• Things get left out of the original baselines for a reason, and that reason is that nobody is expecting those things to happen, at least not with an “80% confidence interval.”
• If Affordability and Availability are already set, the only recourse left to the contractor is to target the minimally-acceptable level of Quality, as discussed two weeks ago.
• Poor performance is supposed to be paid out of any profit or award fees that would otherwise go to the contractor, leading to significant pressure to never acknowledge this as the primary causal factor of PM difficulties.

With all of these not-readily-apparent forces pushing and pulling on the supposedly frozen baseline, small wonder that all of the ensuing friction erupts in the only available venue, the change control process. This being the case, the question posed in this blog’s title should probably be turned around. It shouldn’t be “why is change control so contentious?”

It should be, how is it that it’s not more so?

[i] See Breitman, Daniela, Today in science, Discovery of Neptune, https://earthsky.org/human-world/today-in-science-discovery-of-neptune.

[ii] Ibid.