Game Theory in Management

EDUCBA.com provides the following distinction between “Descriptive Analytics” and “Predictive Analytics”:

Descriptive Analytics: This type of analytics is used to summarize or turn data into relevant information. In other words, it summarized what has occurred. This type of analytics has some meaningful impact but won’t be much helpful in forecasting.

Predictive Analytics: – Predictive analytics involves advanced statistical, modeling, data mining and one or more machine learning techniques to dig into data and allows analysts to make predictions. Predictive analytics is used to forecast what will happen in future.[i]

When I read this description, it reminded me of newly-minted managers, with the memories of their BBA or MBA graduation ceremonies fresh in their minds, arriving at their first assignments. It’s not that they’re ill-informed or anything – it’s just that what they think is new and innovative has actually been around for some time. In this case, the Project Management community has been on top of this epistemological mountain for so long, it’s easy to forget that we’re here, and the whippersnappers newcomers need to be reminded of that.

Let’s look at a couple of key sentences from the above, shall we? According to this author, Descriptive Analytics describes “what has occurred,” and “…won’t be much helpful (sic) in forecasting.”[ii] Well, I disagree. But before I prove that I’m right, let’s take in what this post says about Predictive Analytics, that it “allows analysts to make predictions” (as if such analysts need permission to predict anything). Also, it’s “used to forecast what will happen in the future.”[iii]

Lots of stuff to unpack here. I’ll start with the distinction between these two types of Analytics provided, that “Descriptive” refers to “what has occurred,” which veteran members of GTIM Nation call “hard data,” and “Prescriptive,” which “involves advanced statistical, modeling, data mining and one or more machine learning techniques to dig into data” – in other words, some subjective data is being injected into the number-crunching fray. But is historical, or “Descriptive” data of little use(ful) in forecasting? Consider this blog from a few weeks back, where I proposed a competition between risk management and Earned Value, to identify which tasks or projects were likely to overrun or come in late. I proposed that the risk managers create a list of such tasks, and the EV specialists do the same. After tossing out those tasks that both analysts believe will overrun or come in late, we would have a hard basis of comparison, and that my money would be on the EV peeps, who can reliably predict which tasks will get in trouble, and on a consistent basis. Not only that, but they DO NOT use ”advanced statistical, modeling, data mining and one or more machine learning techniques.” Quite the contrary, they need only the size of the original budget, cumulative actuals, the tasks’ start date, today’s date, and an estimate of the tasks’ percent complete. And that’s it. It’s accurate (to within 10 points on a consistent basis), simple, and it’s been around since the 1960s. No, I’m not kidding.

Well, what of the whippersnappers’ more recent techniques? They essentially fall into three categories:

• Risk management involves estimating the odds and impact of alternate scenarios,
• Regression bases their predictions on patterns that have occurred historically, and assume that similar outcomes will unfold when analogous situations or conditions are re-encountered, and
• Models, in which certain types of work or business activities are expected to unfold along the lines of a familiar template – Game Theory falls into this category.

Referencing the first bullet, the tried-and-true PM techniques of Earned Value and Critical Path Methodologies will always out-perform the risk analysts’ tactics. For this reason, I’m very confident that no serious fact-based rebuttal to my Variance at Completion challenge will be forthcoming.

As for the second bullet, it is the basis for much of the poison pixel-ink I’ve spilled on our friends, the Accountants. You see, when an accountant projects how much a specific task will end up costing when it’s complete, they typically use regression to make their estimates. They calculate how much the task has been spending, and assume it will continue to spend at that rate (or an average, or adjusted average, or whatever) for its duration. This calculation, while not as irrelevant as the risk managers’ output, still isn’t nearly as accurate at the EV technique.

About the third bullet – isn’t there a ProjectManagement.com blog about that?

So, it’s pretty plain to me that:

• Contrary to the citation, using data that covers things that have already occurred is, in fact, extremely valuable in predicting outcomes, given the right methodology;
• Statistics and modelling provide inaccurate and irrelevant information (“You have a 39% chance of overrunning”);
• Regression-based analysis, while relevant, isn’t nearly as accurate as the 1960s-era technique of calculating the Estimate/Duration at Completion, and
• Game Theory, with its payoff grids and Nash Equilibrium, can provide some insights in very specific, controlled circumstances; however, it has only a fraction of the predictive analytic power of even the most basic Earned Value or Critical Path Methodology-based system. (I’m comfortable making this statement a priori due to the massive amount of research I did while writing my second book, Game Theory in Management).

I don’t mean to come across like some curmudgeon (I should probably knock off the references to whippersnappers). It’s just that, when it comes to reliably predicting key Project Management data points, well, those techniques have been around for some time.

Before many of the whippersnappers were born, even.

[i] Retrieved from https://www.educba.com/data-analytics-vs-predictive-analytics/ on June 29, 2019, 21:38 MDT.

[ii] Ibid.

[iii] Ibid.

When the first scenes of the planet Coruscant appeared in the Star Wars movie The Phantom Menace (to you purists out there, the clip of Coruscant that appears near the end of The Return of the Jedi was added later), seasoned science-fiction consumers probably had a flashback to Isaac Asimov’s Foundation Trilogy, and the governing planet Trantor. Like Coruscant, Trantor has no open spaces – every acre has either been paved over or has a building on it. However, after the first Foundation galactic-wide government collapses, and almost everyone has abandoned the place, a remnant tear down some of the infrastructure, and begin farming the surface – something that Hari Seldon’s “psychohistory” algorithms failed to calculate predict.

I’ve mentioned The Foundation Trilogy and psychohistory previously, primarily because of its similarity to the philosophical underpinnings of modern risk management. Set thousands of years in the future, The Foundation Trilogy takes place in a galaxy populated by trillions of humans, scattered across myriad star systems. Psychohistory is predicated on the idea that, while it is impossible to predict the movement of a single atom of, say, oxygen, if you get billions and billions of O2 molecules into a container they start to behave in highly predictable ways. The Hari Seldon character has devised a method of calculating the most likely outcome of the collective Galactic Empire’s future, since there are so many people whose behavior, while individually unforeseeable, has become somewhat predictable in the aggregate. While we never actually see the algorithms that do all this amazingly accurate predicting, one gets the sense that it’s a combination of statistics, Game Theory, and Behaviorism, with turbocharged derivatives of Bayes’ Theorem thrown in for good measure.

Meanwhile, Back In The Project Management Galaxy World…

I recently attended a conference on predictive analytics. As with most conferences, it included keynote speeches, presentations, and workshops, with the standard exhibitors’ area set aside for vendors and their booths. One element of the conference that I did note, over and over, was a heavy emphasis on analyses based on Gaussian curves, all of which (well, all the ones I saw) were presenting ideas for better predicting the behavior of large populations based on analyzing the data from samples. For recent additions to Game Theory In Management Nation, I regularly assert that all valid Management Information Systems’ architecture can be reduced to three sequential steps:

1. Data is gathered based on some discipline or planned sampling program.
2. The data is processed into information, based on some methodology or model (for PM types, this is usually Earned Value or Critical Path methodologies).
3. The information is transmitted to decision-makers in a way that they can readily understand it, and use it to make decisions.

I noticed an interesting consistency among those presenting papers and the software vendors. Those presenting the papers largely addressed the issues of Step 1, collecting the data, with only an occasional mention of the problems inherent in the actual analyses. Similarly, the vendors seemed to be offering up solutions to data collection and standardization issues (“harmonizing” the data), but would usually punt when asked how they would propose actually processing the data into usable information, the all-important Step 2. One fellow told me that his software would simply use “whatever the customer’s preferred model” happened to be at the time. To be fair, Hari Seldon won’t introduce Psychohistory for another 10,000 years.

Until then, the whole business of reliably predicting the future is pretty much stuck in reverse. Analysts can observe what has happened in the past, overlay some sort of structure on to it, and then recommend a specific strategy if the present appears to be unfolding in an analogous fashion, but that’s about it. And even that series of steps can be accurately, if colloquially, chalked up to “experience.”

But perhaps the main intellectual fault of the whole predictive analytics/ risk management codex has to do with the extrapolation of large populations’ behavior(s) from a relatively small sample size. As marginal as that practice is, current risk management seeks to turn that on its head. They attempt to predict the cost or schedule behavior of a specific project based on patterns gleaned from many other (hopefully, similar) projects, something that not even Hari Seldon proposed (will propose?) as plausible. By definition, projects tend to be one-time endeavors. Even identical buildings are constructed on different sites, after all.  Paradoxically, the more standardized or routine the work to be done happens to be, the less demand for professional Project Managers. Stamping out identical widgets from a production line doesn’t need much PM support, while facilities or software applications that do something genuinely unique usually won’t succeed without it.

Meanwhile, Back On Trantor (Warning! Spoilers Ahead)…

The fate of the First Galactic Empire turned out to be very different from its calculated version due to the emergence of a character named The Mule, who had a mutant ability to influence people with whom he interacted without actually speaking to them. In other words, the prediction of the population’s future unraveled due to the introduction of a single, unpredictable person. But predictive analytics/ risk managers don’t seek to forecast the future of projects in general – they attempt to quantify what is going to happen to singular, specific projects.

My prediction? It won’t work 10,000 years from now, and it certainly won’t work in your next project.

For those of you in GTIM Nation who are used to my writing direct, immediately-usable strategies for better project execution, or team cohesion, or shotgun blasts against what I perceive as management pathologies, I must request some patience. I’ll get to that kind of stuff after the next 400 words or so, but I must first take a detour into, what I’m sure will strike many as, a more theoretical, philosophical bent. But, if you stay with me, I’m pretty confident I can make it worth your blog-consuming while.

Referring back to this blog’s title – what does a priori mean? According to Merriam-Webster online[i], it’s “relating to or derived by reasoning from self-evident propositions,” and “presupposed by experience.” I was reminded of this term recently when I was looking into the concept of interface management, and my internet search turned up an article in the Project Management Quarterly, from 1979 (!). The article, “Interface Management – an organization theory approach to project management”[ii] is chock-full of a priori assertions, which isn’t necessarily a bad thing in and of itself. I think what I find frustrating about this particular article is the overuse of inchoate but impressive-sounding assertions, none of which are verifiable through observation, or even falsifiable (which Karl Popper would probably argue renders it outside of the scientific method, even if we ARE talking Management Science). Some of the gems include:

• “Tight control of dynamic interfaces is essential to achieving project cost, schedule and scope targets.”[iii]
• (two bullets later) “Organizational factors should not be allowed to inhibit required project integration.”[iv]
• “Systems management is a key systems concept.”[v]

And those are just on the first page. Let’s take a look at these one at a time, shall we?

• We learn later in the article that a “dynamic interface” is a communication among stakeholders in the project, or even within the Project Team, that are other than “static.” This differentiation appears to hinge on whether or not the communication is regular and consistent, or ad-hoc and unpredictable. Just how are these interfaces to be “tight(ly) controlled?” Is the PM to sneak around the Project Team’s offices, waiting for one of them to contact a sub-contractor with some unauthorized question, and pounce if and when such an interface occurs? Also, how is this falsifiable? Could a Karl Popper aficionado approach this author after the fact, and state (with a straight face) “I successfully achieved my project’s cost, schedule, and scope targets, and I made no effort at all at controlling the dynamic interfaces, much less tightly. I insist you retract your thesis that such ‘control’ is ‘essential!’”?
• This notion that PM implementation strategies exist in the pure ether of a universe that allows only the mathematical and provable aspects of management science is just plain dopey. Management takes place in a world of people – real people – who will inevitably manifest some sort of organization behavior and performance pathology in any group they create. It’s just the way things are in the real world. If your PM strategy crashes and burns, and your best deflection tactic is to blame the “organizational factors,” then your strategy was poorly formulated from its inception. As I have pointed out in multiple previous blogs (usually, but not always, citing the excellent Michael Maccoby’s book The Gamesman), the “organizational factors” are part of the managerial landscape. Ignoring them, and then blaming them ex post facto for your failure to derive an appropriate management strategy is simply disingenuous.
• Okay, this last bullet is a simple tautology. I included it because it bugged me.

But the thing that these key assertions all have in common is that they are a priori assertions. None of them is verified (or even verifiable) through direct observation. I’m not just picking on this particular author (even though he is a Ph.D.) – this sort of supporting argumentation for furthering certain ideas about Project Management is, unfortunately, rather common. Examples include:

• The idea that “bottoms-up Estimates at Completion” need to be performed regularly,
• Critical Path schedule networks are rendered weaker by an excess of start-to-start relationships among activities,
• All stakeholders must be engaged,
• As well as almost the entire codex of risk management theory,

…and this is just a short list.

My solution? Outright rejection of all PM hypotheses that are not falsifiable is probably a bit extreme. I would settle for an honest re-examination of the non-falsifiable ideas that made it all the way into the PMBOK Guide®.

And for real-world PMs: take with a huge grain of salt any a priori assertion about the way you “should” or “must” do Project Management. If the one pushing the analysis technique can’t point to real-world examples of how his approach worked, then it probably doesn’t belong in the real world.

[i] Retrieved from https://www.merriam-webster.com/dictionary/a%20priori on 15 June 2019, 20:29 MDT.

[ii] Morris, P. W. G. (1979). Interface management—an organization theory approach to project management. Project Management Quarterly, 10(2), 27–37.

[iii] Ibid.

[iv] Ibid.

[v] Ibid.

In the 1954 movie Around The World In 80 Days, protagonist Phineas Fogg has embarked on a steamer from New York towards Europe and the final leg of his epic voyage, but there’s (yet another) problem: the steamer Henrietta doesn’t have enough fuel on board to complete the voyage at the speed that Fogg needs to maintain. Fogg’s solution is brilliant: once the coal is exhausted, he offers to purchase the ship, and then dismantles it en route to feed the boilers. He has the crew remove any piece or part that falls under the following criterion:

• It’s flammable,
• It does not add to the vessel’s seaworthiness,
• Nor does it have anything to do with its propulsion system.

As it turns out, the ship’s figurehead, a wooden statue of a woman (who’s apparently been nicknamed “Henrietta”) qualifies, and is detached for feeding into the furnaces, leading the ship’s first mate (played to perfection by Andy Divine) lamenting “Not Henrietta!”

Meanwhile, Back In The Project Management World…

GTIM Nation members may not be engaged in a massive bet to circumnavigate the globe on a schedule more aggressive than thought possible for the current state of transportation, but there are many parallels to what we do to the movie Around the World in 80 Days, and to this scene in particular. Consider what you would do if, say, as the head of your organization’s Project Management Office (PMO), a PM comes to you and asks for help in setting up her Project Management Information System (PMIS), for a moderate-sized, high-profile project, but with two caveats: she needs her cost/schedule measurement systems set up very quickly, but doesn’t have very much budget set aside for that part of the work. Referring back to my “quality, availability, affordability, pick any two” axiom, she is communicating that she needs a system that fulfills the latter two. What’s your implementation strategy going to be?

I believe that it’s rather self-evident that a basic Earned Value System must be set up first. After all, even a crude EVM can deliver critical cost AND schedule performance information with a minimum of cost or time. Assuming a functioning Work Breakdown Structure is available, and our friends the accountants have agreed to set up the General Ledger to accumulate actual costs based on the reporting level of said WBS, the only other pieces of data needed to make the EVM functional and effective are the total budget for each of the tasks at the reporting level of the WBS, and an estimate of the percent complete for those tasks as of the end of each of the reporting periods. Work Package and Control Account Managers tend to be very busy, but a simple percent complete figure for their work is probably the easiest thing they have to do each month.

Next up, if time and budget is available, would be the data needed to set up a Critical Path network. This requires the additional data points of Work Package (or the activities that make up the WP) duration, plus which other activities need to be completed prior to the initiation of the one(s) being captured. With these durations and schedule logic links, a Critical Path network can be established, which can predict the project’s duration as well as pinpoint which activities have float, and to what extent. Piggy-backing off of the percent complete figures already being made available for the Earned Value part of the system, the CPM-based schedule can also provide accurate and reliable projections for project duration.

As far as I’m concerned, these are the basics. They have the added advantage of being fairly easy and inexpensive to create and maintain, and pass along the most crucial information elements needed for successful Project Management: how the project is performing in cost and schedule space. But what about all of those other management information streams that the experts maintain must also be set up, like risk analysis, or bottoms-up Estimates at Completion (EAC)? Well, let’s take a look at those, shall we?

As I’ve noted in previous blogs, a calculated EAC is both more accurate and far easier to generate than the so-called bottoms-up variety, which entails re-estimating the remaining work, and adding that figure on to the cumulative actual costs. Re-estimating the remaining budget – essentially, recreating the cost baseline (and turning the previous one to rubber) – requires professional estimators, using off-the-shelf software, in order to approach a 15% accuracy rate. Conversely, almost anybody who has graduated 4^th grade can divide the cumulative percent complete into the cumulative actuals, which consistently returns a 10% accuracy rate.

Then we have my favorite foils, the risk managers. To perform a risk analysis worthy of the name, the following data points must be collected, almost always from the very Work Package Managers you need actually performing scope:

• Alternative scope scenarios to the ones in the existing cost and schedule baselines (yes, you read that right: a proper risk analysis can’t even begin without already-established scope, cost, and schedule baselines),
• The odds of each of those scenarios coming about (inevitably, speculation, or out-and-out guesses),
• The cost impact of each scenario (again, you’ll need professional estimators with COTS estimating software to approach 15% accuracy),
• …and the duration impact of each scenario.

After your risk analysts have collected all of this data, and have either chewed on it themselves or loaded it into some other software to crunch, what does it return? A list of things that the PM should be worried about, expressed in Gaussian jargon. That’s it.

Meanwhile, Back On Board The S.S. Henrietta…

So, we’re looking over this fine ship, and realizing we won’t get to on-time, on-budget delivery without shedding a lot of extraneous weight not-truly-needed features from the PMO function. Do I have to say it? The bottoms-up EAC-insisters and the risk management crew require much data (which can only really be supplied by the WP and Control Account Managers), take a lot of time and money, and ultimately deliver either irrelevant information, or else inaccuracies, while the correct answers can be derived much more quickly and cheaply. The which-parts-of-the-PMO-information-stream -needs-to-go decision becomes rather easy.

Throw that figurehead into the flames. And don’t think twice.

Much has been made of the issue of project baseline integration. And when I say “much,” I mean virtual tons of pixel ink that need not have been sacrificed on the altar of this suspect quality metric. One of those guidance-generating organizations that I consistently refrain from naming has made baseline integration pretty much the basis for assessing the quality of any Critical Path Methodology schedule network in its relation to the same project’s Earned Value Management System time-phased budget.

For those members of GTIM Nation who are unfamiliar with what I’m talking about, here’s a quick primer. For (what are considered to be) highly robust Project Management Information Systems, the development of the Performance Measurement Baseline (PMB) is a big deal. A typical sequence involves defining the scope fairly precisely, and then decomposing it into a Work Breakdown Structure (WBS). Once the scope has been defined down to the Work Package level, the estimators, schedulers, or both are brought in to excessively pester the WP managers as to (in the case of the former) which resources are going to be needed to complete the activity, and (for the latter) how long it’s expected to take, which activities need to be completed prior to the start of the one under the microscope, and is the WP manager aware of which activities need this one to complete prior to starting? If both the estimator and scheduler are either not present or not the same person, this is the first opportunity for “baseline integration” to become an issue. Some “experts” will insist that the cost estimate must be derived first, and then loaded into the CPM software for time-phasing. Others will insist that the schedule be established first, and then resources added (from an organization-wide and approved Master Resource Dictionary, no less) to derive the cost estimate. I have seen adults shouting about this very disagreement. No, I am not making this up.

Of course, even if the relevant (and even the irrelevant) parameters of the two baselines line up at the start, this only means the PM’s problems are just starting. You see, most estimating packages assume an annual adjustment to rates to accommodate inflation; however, Master Resource Dictionaries can be updated at any time, usually quarterly. After three months, the cost estimate as represented in the estimators’ version of the Cost Baseline suddenly doesn’t exactly match the time-phased budget as represented in the Schedule Baseline. The baselines aren’t integrated! It’s PM Armageddon!

If GTIM Nation thinks this is an absurd state of affairs, wait ‘til I tell you about what happens when a Baseline Change Proposal (BCP) is submitted. Assuming the BCP is reasonable, its changes to the Cost and Schedule Baselines are expected to happen almost immediately. This means an almost instantaneous and thorough update to those documents that retain information on the affected Work Packages, and the Cost Accounts that they impact, on up the WBS chain. A short list of these documents includes:

• The affected WPs themselves, including
  • Scope description
  • Cost estimate
  • Schedule parameters
  • Selected method of ascertaining percent complete
• Their “parent” Control Accounts
• The WBS Dictionary
• The risk management plan
• The Change Control Log
• The Contingency Budget (if applicable)
• Cost Performance Reports
• Schedule updates
• Variance Analysis Reports…

…and I’m not joking about this being the short list. The kicker? None of it changes cost and schedule performance system quality. None of it. I can prove it.

Let’s do a little thought experiment, shall we? Posit that a project has both a Cost Baseline and a Schedule Baseline, loaded into an EVMS and CPM software, respectively. But, while these two software platforms could communicate with each other, they don’t, because the head of the Cost Performance analysts can’t stand the head of the Schedulers, and vice versa. Let’s further assume that the Earned Value baseline is wildly optimistic, with its Estimators placing the Budget at Completion at $5M (USD). In reality, the project will come in at $10M, but the Cost guys are spending too much time pranking the Accountants, and can’t be bothered to cross-reference their estimates. Conversely, the Schedulers are spot-on with their original Critical Path Network, and show a project completion date of the Start Milestone plus one year. The baselines aren’t even remotely “integrated,” and any comparison of their parameters will quickly reveal this.

So, our little thought experiment project gets underway, and three months along both the Cost and Schedule teams pull status (i.e., glean the percent complete of each WP from their managers). Everybody’s on-schedule, so the overall project’s percent complete is compiled at 25%. Since 25% of the project’s actual time has gone by, the Schedule Team doesn’t have to explain any surprises. Conversely, the Cost Team is comparing their Earned Value (BAC * % Complete, $5M * 0.25, or $1.25M) against a cumulative actual cost of $2.5M. Flawed as it is, the Cost Baseline is now reflecting an Estimate at Completion, based on the derived Cost Performance Index of 0.5, of an overrun of $5M, accurately forecasting the $10M total cost. The fact that the Cost Baseline and Schedule Baseline were wildly inconsistent with each other had no impact whatsoever on each system’s ability to predict the projects ultimate at-completion parameters. Indeed, to assert that the baselines must be in complete agreement is to insist that an EVMS and a CPM Schedule Network cannot be independently operating on the same project, which is clearly absurd.

Now, don’t get me wrong – I’m not saying that the Cost and Schedule Baselines ought not to be completely consistent with each other. What I am saying, though, is that, should they disagree in part (or even entirely), it does not represent a cataclysmic loss of system quality.