Game Theory in Management

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.

Yeah, yeah, I know: “Change Control” doesn’t really mean we’re controlling change. In PM parlance, it means we’re taking a formal approach to altering our Scope, Cost, and Schedule baselines to accommodate differences in the project execution environment that were not foreseen when those baselines were originally established. But I have to ask: is that what we’re really doing when we set up our Baseline Change Control Boards? Are these changes truly confined to circumstances or events that could not have been reasonably foreseen, and necessitate added monies, or time?

Just as a quick aside, what exactly is “schedule contingency?” When we discuss budget contingency, I can understand what’s going on. The risk managers (no initial caps) do their whole Decision-Tree or Monte Carlo analysis thing on the existing cost baseline, and take a wild guess estimate an amount of money that the customer may or may not set aside for events that have a certain pulled out of thin air calculated value, in case those predicted events actually happen. If the customer does decide to set aside this amount, it can be placed in a bank, I suppose, or represented by some sort of promissory note attached to specific conditions that would allow the contractor to tap such funds. 

But how does that work with “schedule contingency?” Is there some time-bank that exists, where the customer can make a deposit of hours, days, or weeks corresponding to the amount that the risk managers (no initial caps) propose as the appropriate amount? I think it’s pretty obvious what’s going on here: the risk managers (no initial caps) derive this “schedule contingency” amount and document it as part of their risk analysis so that, should any of the events listed in said analysis actually occur, the PM can feel a little better about asserting to the customer “I thought this might happen, and look where I added X amount of days to the schedule contingency.” Perhaps I’m being harsh on our friends – for all I know there may actually be a gaggle of customers out there who can be placated by the ability to predict that something might go wrong on a project, which prevents them from becoming mad about late finishes.

The whole “schedule contingency” business kind of points back to the contingency budget version, in those instances where the contingency budget isn’t funded. Consider this version of the Game Theorists’ favorite tool, the payoff grid:

Let’s dispense with Scenario 2 (A) right off the bat. Plenty of projects are sufficiently routine that no risk analysis is performed, no contingency budget established, and nothing so out-of-the-ordinary occurs that would lead the PM to request additional funds. Similarly, if a contingency budget is established, but no reason exists to tap into it, then it’s a big nothingburger, though I do wonder what happens to those funds. Were they invested? Should they have been? If the customer gets those funds back, do they go on vacation?

Where change control (ProjectManagement.com’s theme for November) becomes a critical function has to do with Scenarios 1 (A) and 1 (B). For Firm Fixed Price contracts, of course, contingency events are simply part of the game. The amount needed to overcome or accommodate them comes out of the total project cost, no justifications needed. But for Cost-Plus contracts, where the customer is sharing the projects’ risks, how such contingency events are handled becomes a bit trickier. If a contingency event occurs, but there are no additional funds (set aside or not) to cover its costs, then available responses can become severely restricted. In fact, I can think of only four: (1) reduce the scope elsewhere within the Work Breakdown Structure, (2) find additional monies somehow, somewhere (hopefully not the way Fred Smith [founder of FedEx®] did it, by going to Las Vegas and winning the shortfall playing blackjack[i]),  (3) get other Control Accounts or Work Packages to perform so well that they make up for the expense in underruns, and find an acceptable way to transfer the balance over to the afflicted CA, or (4) brace yourself to endure the consequences of a late, overrun project.

Finally, we have Scenario 1 (B), the nominally intended purpose of Baseline Change Control Boards, to evaluate baseline changes that have come about due to factors outside of the contractor’s control to see if they should be included in the scope baseline, funded and scheduled. Even here, though, BCCBs have to be vigilant, since adding budget or time to the respective baselines isn’t just the solution to contingency events – it’s also a pretty effective cover for a variety of PM pathologies, such as poor performance, or scope creep, or increased unit costs, or…

The list goes on and on, but one of the things they all have in common is that none of them can really be controlled, at least not in the precise use of the term. Influenced, resisted, avoided, dissuaded, sure. Controlled, not so much.

[i] From https://www.businessinsider.com/fedex-saved-from-bankruptcy-with-blackjack-winnings-2014-7 on November 17, 2020, 17:23 MST.

“It's a very sobering feeling to be up in space and realize that one's safety factor was determined by the lowest bidder on a government contract.”[i]

--Alan Shepard (American astronaut)

We business writers usually don’t like discussing it, but it’s an ubiquitous factor in what Project Managers do: our contracts are, generally speaking, awarded on the basis of who had the lowest plausible bid at the end of the Request for Proposal cycle, even if the project being contracted out involves safety-critical work. Recall my oft-repeated business model axiom—Affordability, Availability, Quality: pick any two. With the lowest-bidder model in place, one of these factors – Affordability – has already been established. Since virtually all projects have a contractually mandated start date, Availability has also been spoken for, leaving Quality as the de facto element receiving the proverbial short straw. This being the case, the PM game has been largely set up to encourage those putting together the best and final offer (BAFO) package to interpret the project’s scope in a minimalist fashion, and create the cost and schedule estimates around that. What happens if the PM finds herself in the middle of the awarded project, and the customer isn’t okay with such a minimalist interpretation? This dichotomy is the source of no small amount of conflict in the most common PM business model, and I intend to take a peek behind its curtain.

Way back when I was taking Psych 101 and 102, my particular University’s Psychology Department was dominated by Behaviorists, a school of thought attributed to the early works of B.F. Skinner. All of the classes I took from this department were taught by Behaviorists, and they absolutely loved to tell the following story on the first day of class.

Some unnamed early-adopter of Behaviorism would find himself in a class taught by a different school of thought (usually Freudians), but with a sizable percentage of the students who were also Behaviorists. Prior to the second class, these got together in the Student Union Building, and agreed to an experiment: each time the Freudian instructor walked towards the door/hallway side of the classroom, the students would pretend to lose interest, break eye contact, feign daydreaming, doodle, etc. However, whenever the instructor was on the windows side of the classroom, they would pay rapt attention to him, writing down whatever he said, smiling and maintaining eye contact. The result, it was said, was that this instructor planted himself on the windows side of the room within fifteen minutes of the beginning of the session, and did not leave. Reconvening at the SUB afterwards, they schemed to see how far they could take their little experiment. To hear their telling, by the end of the term this unfortunate instructor was exclusively teaching from the windows side of the classroom, assuming a specific posture, tone of voice, and affecting a style of speech that was otherwise entirely foreign to him.

Meanwhile, Back In The Project Management World…

I would argue that, in a sense, the population of clients that employs the lowest-bidder strategy in selecting their contractors have established a business model that’s at least somewhat analogous to the students in the story above. Contractors engaged in a bidding contest against others will avoid proposing the high-quality solution to fulfilling the proffered scope, since that approach is almost guaranteed to be a more expensive option. In this model, contractors are rewarded with wins for offering Affordability and Availability, while making a minimal number of quantifiable claims in the Quality arena. Equally as important, the same population of contractors putting in bids are punished with losses for taking any other approach. Even first-year graduate school students at a State University given to telling tall tales on the efficacy of a favored psychology school of thought can predict the outcome of long-term engagement in this particular business model, and it’s not good for the Quality crowd.

Such a structure puts pressure on the PMs to complete the existing scope as economically as possible as they target the minimally-acceptable standard. It’s the twin of another highly damaging Project Management pathology, Scope Creep, except, rather than having the project absorb informally-changed scope with no change to the budget, the Project Team is rewarded for producing the most basic-while-acceptable output, which drives the Quality aficionados crazy. The depiction of this condition is shown in the Game Theorists’ favorite tool, the payoff grid, so:

Just as experienced PMs will be on the lookout for the conditions common to Scenario A, seasoned project sponsors will be wary for hints that Scenario D is unfolding. To be fair, the people I’m talking about here didn’t come to behave in this manner out of a deceitful nature, a desire to engage in subterfuge, or because they thought it would be really cool to join the Dark Side of the PM Force.

Whether they know it nor not, the prevalent business model trained them to act this way.

[i] Retrieved from https://www.brainyquote.com/authors/alan-shepard-quotes on November 8, 2020, 19”42 MST.