Game Theory in Management

I was casually watching a Star Wars movie marathon a while back, and was struck by how often the practitioners of the Dark Side of The Force (“Sith”) would articulate a desire to complete the training of the young Jedis, Anakin and Luke Skywalker. What was so obviously missing in their nominal Jedi training? It became clear that they weren’t really interested in conveying advanced techniques, but instead wanted that training to go in a dramatically different, sinister direction.[i]

Meanwhile, Back In The Project Management World…

And now, on a completely different subject, in last week’s blog I discussed a potential paradigm shift in Project Management along the lines of moving away from predictive models and towards adaptive ones. I conceded that a complete abandonment of predictive models was highly unlikely, due to the fact that government-issued contracts tend to rely heavily on projects rarely overrunning their original baselines, and government-funded projects represent a significant part of the PM community that expects, or even demands, advanced proficiency in Project Management.

With this caveat in mind, I began to reminisce about the kind of project controls analyst I was when I could be considered a young Padawan learner “new practitioner” (ProjectManagement.com’s theme for January). When I showed some aptitude for Project Management in the company I worked for straight out of college, I was sent to a couple of week-long courses in Cost/Schedule Control System Criterion (C/SCSC). I absorbed all I was taught with enthusiasm. It was all brand-new to me, and, it appeared, fairly new to the management community at large.

After a while, though, I encountered significant issues that weren’t even hinted-at in the PM codex as-presented. After being effectively stiff-armed by every accountant I encountered while trying to do nothing more than set up a simple project cost performance measurement system, I began to wonder exactly what they thought they knew that I didn’t, and went back to school to get my MBA. A few semesters in, and I had my answer – their whole management philosophy, “maximize shareholder wealth,” was utterly at odds with the PM approach, of meeting the scope, cost, and schedule expectations of the customer. I had never seen this dichotomy articulated in any of the PM literature I had consumed, but I was also fairly certain that I wasn’t the only analyst in the world that had come to this realization. Clearly my indoctrination as a new PM practitioner had been incomplete (“Ben! Why didn’t you tell me?”[ii])

Fast forward to my more experienced years, after I had quite a few paper presentations, keynote speeches, and training track designs under my belt. I began to realize that those whom I considered my peers were becoming frustrated at the propensity of new practitioners to eschew process, only to re-encounter the entirely avoidable pitfalls that they themselves had had to overcome. It seemed to me that a large and growing percentage of the papers presented at major conferences were little more than eat-your-peas-style hectoring, on how everybody needed to acknowledge or accept the virtues of setting up a tightly-regulated cost and schedule baseline, fully integrated, don’t you know, complete with rigorous change control protocols, risk analysis, and reporting formats.

The more I thought about it, the more I realized that many of the seasoned paper-presenters were trending strongly towards the dark predictive model side of things, and that it was the Agile/Scrum crowd that represented a departure from that approach. Indeed, if it weren’t for the well-written structure of the Manifesto for Agile Software Development[iii], I seriously doubt that any if its basic assertions would be accepted today. With this as the backdrop, what can be said of the advantages and disadvantages of new PM practitioners?

Well, for starters, the newer practitioners have the advantage of not having been involved with projects during the era where United States government projects were more likely to be compelled to adopt a specific set of criteria governing how their projects would be run. With the decline of the Cost/Schedule Control System Criterion as management system absolutes, the use of the two main methodologies behind PM – Earned Value and Critical Path – had to stand on their own as information streams critical to improved project performance. New practitioners, then, have the advantage of the perspective that allows better PM information system integration than those who have been convinced that a rigorous, predictive model PM approach is a condition of doing business.

Another advantage that the whippersnappers newer practitioners have is that they naturally trend toward the adaptive models, owing to the underlying causes of the Project Manager role being nicknamed “the accidental profession.” After having successfully conquered some piece of scope that has led to more, similar work, the succeeding technician/engineer/programmer will often attract a request from their organizations to assemble a team and do more of that kind of work. At this point the newly-minted PM will rarely have a concept of the reasons behind rigorous change control procedures, or risk management approaches. They simply want to get the job done, and, I would speculate, will perceive these vestiges of the predictive model to be bureaucratic impediments to that goal, making the new practitioner more inclined to question their need at the very least, if not abandon them altogether.

One distinct sign, though, that the new practitioner is being trained in the wrong direction is if they develop a predilection for within-duel taunts, such as “Your powers have become weak, old man.”[iv] But at least the older masters don’t have to wear their hair in that weird rat-tail fashion.

[i] Lucasfilm Ltd. ; 20th Century Fox. (2013). Star wars original trilogy. [San Francisco] : Beverly Hills, Calif. :Lucasfilm ; Twentieth Century Fox Home Entertainment,

[ii] Ibid.

[iii] Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). "Manifesto for Agile Software Development". https://agilemanifesto.org/. Retrieved 6 January 2019.

[iv] Lucasfilm Ltd. ; 20th Century Fox. (2013). Star wars original trilogy. [San Francisco] : Beverly Hills, Calif. :Lucasfilm ; Twentieth Century Fox Home Entertainment,

In previous blogs I have referenced the old saw of “Quality, availability, affordability: pick any two” as it applies to Project Management. This week I would also like to pull in a discussion of Thomas Kuhn’s groundbreaking book The Structure of Scientific Revolution (University of Chicago Press, 1962), and how manifestations of Kuhn’s theories have been exhibited in the introduction and advancement of Agile/Scrum PM strategies in the Information Technology arena.

Briefly, Kuhn pointed out that, while the common perception is that scientific and technological advances appear to occur at a somewhat steady pace, the opposite tends to be the truth. Kuhn actually introduced the term “paradigm shift,” and theorized that scientific advances follow this model:

Phase 1 is the pre-paradigm phase, marked by the absence of a single, widely-held theory that explains the preponderance of occurrences within the given field of study.

In Phase 2 normal science begins, where most problems can be evaluated within the hypothesis-experiment-confirmation/overturning cycle. However, should a series of problems or anomalies occur that the commonly-held theory/theories cannot adequately address, a series of cycles and then epicycles are layered onto the prevailing theory/theories to account for them.

Phase 3 is marked by the occurrence of the commonly-held paradigm proving unable to adequately address an increasing number of problems or anomalies, eventually leading to an entirely new paradigm being introduced that appears to not only explain the previous paradigm’s older problems, but also accounts for the newer issues that the old theories could not adequately explain.

Phase 4 represents the “paradigm shift,” where the new theory begins to displace the previous one(s) while overcoming the inertia inherent in the dramatic modification (or even overturning) of a widely-held belief structure.

Phase 5 is, essentially, a return to Phase 2, just with the new paradigm being used to solve problems, resolve anomalies, and predict future behaviors.[i]

So, how did the introduction of Agile/Scrum for Information Technology PM perform against this model? I believe we have yet to see the final answer to that question, since much of the literature for Agile/Scrum does not appear to present as a direct challenge to more traditional PM practices, but more like cycles and epicycles – distinct but less-than-revolutionary – changes to the current paradigm. For example, Agile/Scrum does not propose to eliminate the change control process, but to radically streamline it.

However, if there were to be a principal associated with Agile/Scrum that did represent a potential paradigm shift within the PM community, I believe that it would have to do with the fourth “value” of The Agile Manifesto[ii], “Responding to change over following a plan.”[iii] “Following a plan,” in traditional PM parlance, is “Freezing the baseline,” and informal changes to an established cost/schedule baseline are, to engage in a massive bit of understatement, strongly discouraged. Conversely, Agile/Scrum represents itself as being on the opposite side of traditional PM on a scale where the extremes are “Adaptive” and “Predictive,” with Agile on the former end, traditional PM on the latter. I have come to the conclusion that the reason Agile/Scrum was so readily embraced by the IT project management culture at large is due to the prohibitively lengthy and formalistic aspects of traditional change control, which typically involve the documented and approved establishment of:

1. a change control board, with their authorities and thresholds spelled out in precise terms,
2. a nominal schedule for reviewing baseline change proposals or requests (BCPs, or BCRs),
3. another nominal timeline for how rejected BCPs/BCRs can be either appealed or amended for re-submission, and
4. yet another timeline for how approved changes are to be implemented and reflected in the baseline documents, as well as how these changes are recorded in such a way as to establish an audit trail.

For projects like the ones that make up the brunt of Information Technology work, this process was simply untenable, which is why, for example, each Sprint Planning Meeting functions as a practical, streamlined substitute for the Baseline Change Control Board meetings. I believe that this aspect alone points unmistakably to a trend in Project Management away from the “predictive” models and towards the “adaptive” strategies, and not just for IT projects.

Of course, in the realm of government contracts, the various sponsor agencies have an obligation to provably spend the taxpayers’ money wisely, so the predictive models and traditional ways of conducting baseline changes will never be abandoned in their entirety. However, my prediction (it is, after all, New Year’s Eve) is that, as those project teams who are using the more adaptive approaches to their Statements of Work consistently out-perform those following the more predictive methods’ strategies, the adaptive methods will become more and more attractive and will gradually displace the more commonly- (and currently-) held paradigms, at which point the shift will have begun.

It will be at that point that we can recognize and confidently announce the innovative trend that changed Project Management.

[i] Wikipedia contributors. (2018, December 8). The Structure of Scientific Revolutions. In Wikipedia, The Free Encyclopedia. Retrieved 04:13, December 23, 2018, from https://en.wikipedia.org/w/index.php?title=The_Structure_of_Scientific_Revolutions&oldid=872736571

[ii] Retrieved from https://agilemanifesto.org/ on December 27, 2018, 16:45 MST.

[iii] Ibid.

I had the distinct honor of taking several classes from the brilliant scholar William C. Dowling, who taught at the University of New Mexico prior to his teaching career at Rutgers. Professor Dowling had a simple test for evaluating any given sentence’s syntax, which he nicknamed “SAS,” an acronym for Simple Analogous Sentence. Confused between “That team is the one to be avoided” versus “That team are the ones to be avoided”? Since “team” is singular, replace it with an analogous singular noun. Which sounds better, “That item is the one to be avoided” or “That item are the ones to be avoided”? The SAS method points to the clear winner.

Meanwhile, Back In The Project Management World…

I’m thinking something, well, analogous should be employed in the world of Project Management. Yes, yes, I’ve been harping at length about the need to return to some level of science in the management science world, but I readily admit that there’s an art to successful Project Management, and the SAS method struck me as an excellent tool to evaluate competing strategies. For my first eval, let’s take a look at our friends, the risk managers.

Consider the following scenario: you are in a casino in Las Vegas, or Atlantic City, and there’s a game where people can bet on the flip of a verifiably fair coin. Since the most competitive casino games (craps and black jack) give around a 0.5% advantage to the house, the coin flip is very attractive. You approach the actual coin flipper but, as you do, you notice a fellow standing next to her, wearing suspenders and round, wire-framed eyeglasses. Clearly he’s not part of the security team, but he’s not actually standing in your way, so you step up to the table to place a bet.

“Fifty dollars” the coin-flipper says pleasantly as you put down a bill with Grant’s portrait on it. She displays a silver dollar, and shows you each side so that everyone is in agreement about which is heads and which is tails. “Call it in the air!”

“Wait!” exclaims the suspender-clad fellow.

“Who are you?”

“I’m the house risk manager. Are you aware that the odds are 50% that you will lose your money?”

“Of course. It’s also 50% odds that I’ll double my money.”

The risk manager sighs, as if he is the one having to endure the statement of the obvious.

“Would you like to know the recent history of this coin’s flip performance?”

“No. That’s irrelevant, since the coin is verifiably fair.”

“But, if this coin were to have been flipped the previous five times with the same result, wouldn’t that fact be of use to you?”

“No. Again, it’s irrelevant. Don’t you have someone else to irk? I want to get on with my coin flip.”

“Call it in the air!” the coin flipper says again, as she flips the coin.

“Tails!”

“Tails it is!” she exclaims, as she places a crisp $50 (USD) bill over yours.

You scoop up your winnings, and push a $5 tip into the coin-flipper’s jar.

“Just then you changed the dynamic!” the suspender-clad fellow exclaims. “Since you probably would not have tipped had you lost, the original wager’s odds have changed, from a 50/50 chance you would either lose $50, or win $50. Now we see that it was a matter of losing $50 or winning $45, meaning that the adjusted odds were NOT in your favor.”

“Yeah, so?”

“So you should not have placed that bet.”

(Long silence.) “Thanks for sharing.”

Now consider the following analogous PM scenario, where you are about to embark on a $5M (USD) information technology project and, breaking with the organization’s previous techniques, have selected an Agile/Scrum PM approach. At the first meeting of the project team, there’s a fellow in attendance wearing suspenders and round, wire-framed eyeglasses whom you don’t recognize.

“Who are you?”

“I’m the company’s risk manager. Are you aware that the odds are 50% that you will overrun this project?”

“Historically that’s the trend. It’s also 50% odds that I’ll come in on-time, on budget, or even underrun.”

The risk manager sighs, as if he is the one having to endure the statement of the obvious.

“Would you like to know the recent history of this organization’s IT project performance?”

“No. That’s irrelevant, since I’m deviating from the usual technical approach.”

“But if this organization were to have overrun the last five IT projects, wouldn’t that fact be of use to you?”

“No. Again, it’s irrelevant. Don’t you have someone else to irk? I want to get on with my project team meeting.”

(At the closeout project team meeting, nine months later…)

“We submitted our last deliverable, and came in just $50,000 over budget. Good job, everyone.”

“How can you say that?” the (uninvited) risk manager asks. “I told you that there was a 50% chance you would overrun, and you did just that!”

“Okay, well, A, it was a 1% overrun, B, the fee more than made up for it, and, C, the follow-on work coming from this organization’s demonstrated expertise in this particular type of project has led to the creation of an entirely new division. That’s how I can say ‘good job everyone.’ And, just by the way, the only one of these outcomes that was contained in your original risk management plan was the possibility of the overrun.”

“Just then you changed the dynamic!” the suspender-clad fellow exclaims. “Since you didn’t include the parameters of those scenarios in the original risk analysis, we had no way of calculating a stochastic range of the probabilities of those outcomes.”

“Yeah, so?”

“So we had no way of quantifying that eventuality.”

(Long silence.) “Thanks for sharing.”

I’m familiar enough with GTIM Nation to know that several of you are eager to post in the comment section “(Long silence.) ‘Thanks for sharing.’” And that’s okay, just as long as we’re clear who came up with that line first.

The saint at the heart of the Santa Claus story is Saint Nicholas, who actually lived in the third and fourth centuries A.D., and was known for his acts of philanthropy (ProjectManagement.com’s theme for December). One of the most widespread stories about him involves a poor man with three daughters of marrying age; however, this man did not have any money for a dowry, needed to secure an adequate husband, and carrying the real threat that they would be sold into slavery. Saint Nicholas became aware of their quandary, and would throw bags of gold coins through the family’s open windows at night (in a bid, no doubt, to remain anonymous), landing them near the fireplace where stockings were hanging to dry. This would become the Christmas tradition of filling stockings hung out on Christmas Eve with goodies to be revealed the following morning.[i]

Meanwhile, Back In The Project Management World…

Saint Nicholas’ story got me to wondering what Project Managers would wish for if they were to have access to a profoundly generous person with near-miraculous powers at their disposal. In creating such a list, I would like to remind GTIM Nation of my theory of the three different types of management, so:

• Asset Managers seek to maximize the return on their assets, with their primary information stream emanating from the General Ledger;
• Strategic Managers pursue the maximizing of market share, and can invoke a variety of strategies to do so (e.g., anything from hostile takeovers to funding an advertising campaign), and
• Project Managers work to complete their projects on-time, on-budget, while meeting all of the customers’ scope requirements.

Whereas “What do managers want?” is an extremely open-ended question, by specifying that we’re looking for what PMs want narrows down the list significantly. With respect to the other management types, my list for PMs includes:

• The organization’s accounting departments abandon the idea that the General Ledger is the source and residence of all management information expressed in currency, and especially reject the notion that the GL can provide insightful analysis on a given project’s cost performance.
• Similarly, PMs could wish for the Strategic Managers to refrain from assuming managerial supremacy, or even superiority, given the fact that any organization that consistently disappoints its customers is going to find acquiring more market share to be very difficult indeed, regardless of the quality of the advertising campaigns.

Then from within the Project Management community we could wish for:

• A return to the 1980s definition of Management Reserve and Contingency (see last week’s blog);
• Those advocating for widespread usage of the technique of re-estimating a project’s remaining costs, and adding this figure to the cumulative actuals as a way of asserting that project’s Estimate At Completion (the so-called “bottoms-up EAC”), have an epiphany (get it?), reverse their anti-Management Science stances, and instead advocate for the calculated version of the EAC.
• If we can’t get the previous bullet, then at least those “experts” should back off the dopey notion that the “bottoms-up” EAC should be time-phased.
• If we can’t get either of the previous two bullets, that these “experts” acknowledge that time-phasing the bottoms-up EAC is the same as creating an alternate cost baseline, reducing the original budget baseline to rubber. Showing my age once again, I can remember when the existence of a rubber baseline on a project was a very bad thing. Now, with time-phased EACs, I guess it’s required.
• If correlation is not causation, and science is all about establishing causal relationships that can be demonstrated and repeated in an experimental setting, how is it that assertions based on statistical correlation keep making their way into the codex of acceptable PM techniques? My next wish is for GTIM Nation at first, and then the PM community at large, to begin to insist that all risk management aficionados subject their analyses to the level of review rigor expected of any other scholastic endeavor, and to respect the results. In short, the future cannot be quantified, and I wish the risk management community would stop pretending to the contrary.
• For perhaps the biggest wish of all, analogous to a seven-year-old suburban-dwelling kid wishing for a pony, I would be made excessively happy if those organizations that present as advancing PM would embrace actual management science and legitimate scholarship, right down to falsifiability and genuine causal analysis.

I think I’ll ask my managing editor, Cameron, to put a GTIM stocking on the PMI® Headquarters’ fireplace mantle on the evening of the 24^th. Assuming Santa fires up ProjectManagement.com from time to time, and reads this blog, he now knows what I want. Who knows? It could happen…

[i] Retrieved from http://www.stnicholascenter.org/pages/who-is-st-nicholas/ on December 8, 2018, 21:22 MST.

Okay, GTIM Nation whippersnappers, listen up. Back when I was first learning the ropes of PM there was a simple elegance about the way the types of budget were established and managed. Once the proposal was won and the negotiations settled, the customer would fund the Contract Budget Base, or CBB (this is now often referred to as Total Project Cost). The CBB was everything – the actual budget, contingency, fee – like I said, everything (but not Over Target Baselines, nor Authorized, Unpriced Work[i]). This figure would then be broken out into its components:

• Unless the contract type was Firm Fixed Price (FFP), the award fee/fixed fee would be set aside.
• If the customer was funding the Contingency Budget, this was usually not included in the CBB; however, if the contractor was expected to fund the Contingency, it was part of the CBB, and had to be set aside. And, just for the record, Contingency was defined simply as “in-scope, uncosted.”
• If parts of the project’s scope were too difficult to quantify precisely enough to generate a detailed cost estimate, a rough order-of-magnitude (ROM) estimate would establish the amount set aside for Undistributed Budget (UB).
• The remainder was available for funding the actual work. This remainder was divided among the project’s Work Packages, which were then rolled up into Control Accounts, and ultimately formed the project’s Performance Measurement Baseline (PMB).

The more seasoned members of Game Theory In Management Nation are probably asking themselves “Hey! What about Management Reserve?” What about it, indeed? For on this very point many a project has met an inglorious end.

Alas, The End Of A PM Era…

In the era I’m talking about, the Management Reserve was established by going to each of the Work Package managers after they had submitted their “final” cost estimates, and asking/telling them to give back a certain percentage (usually around 5%) of their budgets to create the MR. This ask was usually expressed with the acknowledgement that, yes, the WP managers had only agreed to achieve the scope based on receiving their full budget request and, if they needed the 5% back towards the end of their task, no worries. If, however, they could actually attain their scope with a 5% savings, then that amount would become available to other, poorer-performing WP managers, and the overall project would gain a certain level of PM latitude going forward. This intra-project philanthropy functioned very much like society-wide philanthropy, in that it made everyone’s life a bit better. In addition, the use and management of MR was completely invisible to the outside customer, since their reserves had already been established, and this set-aside was explicitly from inside the PMB. Like I said, it was a simple, elegant approach to managing projects, their budgets, and variances.

We Should Have Left Well Enough Alone

But then bad things started happening to the simple, elegant approach. Lots of customers began to view the reserves as some sort of slush fund, where disingenuous contractors could pull monies to cover events that those particular reserves were never intended to address, such as scope creep. I don’t know, maybe the PM community at large brought this upon themselves through a few instances of questionable practices on larger projects, or perhaps some customers became overly meddlesome, or some of both. In any event, the proper use of the reserves got catawampus, with some unfortunate manifestations, the one with perhaps the largest impact being, what happens to variances-at-completion for the tasks at the reporting level of the Work Breakdown Structure?

The way it’s supposed to work is that, when a given Work Package was getting ready to underrun, they could simply notify the PM that they wouldn’t need their MR allocation back, and might even be in a position to push more into the account. Likewise, if a given WP looked like it was going to overrun, and the reason had nothing to do with customer-induced scope creep or a genuine contingency event, they could appeal to the PM for some of the Management Reserve. As long as the underruns/overruns came out roughly equal, all was well.

But when the definition and terms of usage of the reserve accounts were upended, that simple, elegant technique was thrown out. Rather than establish Contingency as a reserve for in-scope, uncosted work, and Management Reserve as a purely internal-to-the-PMB account, these two were redefined based on who funded them. When that happened, it suddenly became legitimate to pressure the PM to give back any underrun that the activities on the reporting level of the Work Breakdown Structure (WBS) had saved, but the overruns – well, the contractor was expected to absorb those, of course. The intra-project philanthropy device was exiled, making everyone’s project a bit more scrutinized.

What Now?

Of course, being the curmudgeon that I am, I think the best remedy would be to go back to the way it was done previously, but the realist in me realizes that’s never gonna happen. Maybe all that’s needed is a movement by the PM community towards an intelligent philanthropy element, starting with the definition of the term Management Reserve.

[i] See https://www.dau.mil/acquipedia/Pages/ArticleDetails.aspx?aid=cbb58d51-c988-4f97-b5a1-b1c59c076887 for an excellent article on these terms.