Game Theory in Management

I have to laugh whenever I hear some manager state that he doesn’t use nor need Earned Value. All managers, even ones who don’t think of themselves as PMs, use Earned Value, and here’s the proof: if your accountant comes to you and says “You’re half spent,” what’s the first thing that enters your mind? It’s automatic – “Am I half done?” And, at that moment, an Earned Value calculation has taken place.

The brutal fact of the matter is that a perfunctory level of project cost and schedule performance measurement and reporting (the very core of Project Management, in my opinion) can be attained with limited resources. Exhibit A in this argument is the production of probably the most valuable bit of information that a cost/schedule performance system can deliver, the estimate of total costs at completion (EAC) and total project duration. A simple comparison of these two parameters with the originally planned budget and scheduled end date reveals the coveted Variance at Completion numbers. Conventional wisdom holds that the EAC should be attained by performing a detailed re-estimate of the project’s remaining scope, add that to its cumulative actual costs, and you have your EAC. As for estimates of the project’s duration, a complete Critical Path Methodology (CPM) baseline is indicated, with the rules pertaining to a maximum number of activities with start-to-start relationships set (typically, very low), the method(s) for collection percent complete data stipulated, the maximum activity length specified, among many other parameters itemized, before a reliable finish-by date can be asserted. To all of the above, I say: nonsense. Those two extremely valuable information bits can be had far more simply and affordably. Here’s how.

GTIM Nation knows of my respect for the work of Dave Christensen, particularly his analysis on Cost Performance Index (CPI) stability[i]. The reason that the CPI’s stability is a big deal is because it’s the denominator in one of the most common EAC calculations:

EAC = Budget at Completion / CPI

Because of Dr. Christensen’s work, seasoned (or at least well-read) Project Controls Analyst know that this formula will return an estimate that’s reliably within ten points of the actual cost at completion, once the project has cleared the 20% complete point.

Here’s where things get interesting. Recall that the CPI is the cumulative Earned Value amount divided by the cumulative Actual Costs. And what is the Earned Value parameter? That’s percent complete multiplied by the total budget (the aforementioned BAC). Members of GTIM Nation who are good at algebra (I am certainly not among them) already see where this is going. The above formula for calculating a reliable EAC can be reduced to simply dividing the cumulative Actual Costs by the cumulative percent complete.

Two parameters.

Two.

All of the insistence on an up-to-date master resource dictionary feeding an off-the-shelf estimating software package, which then transfers its data to a Critical Path Methodology software for time-phasing in order to create the Cost Baseline – yeah, not really necessary, at least not for these two key performance indicators.

But wait, as the telemarketers say, there’s more. The same trick works for duration. For a cheap but reliable estimate of a project’s (or singular activity’s) duration, divide its cumulative duration by the estimate of its percent complete from the same time, and you have it. Compare that figure to the project’s originally planned duration, and you have the variance.

I can almost hear the more seasoned members of GTIM Nation saying “Michael, haven’t you gone too far down the road on this whole reductionism business? I mean, even if these are reliable ways of deriving at-completion cost and schedule performance data, they offer absolutely no insight as to which parts of the Work Breakdown Structure are responsible!” To which I would say, that’s absolutely correct, and, if you are working a complex, high-budget project, with an involved customer, you will absolutely need all the other formal stuff. However, I would also like to point out that most off-the-shelf Critical Path Methodology (CPM) packages compute likely task duration the way I just laid out, by dividing cumulative duration by percent complete. Of course, the CPM packages take into account dozens (if not hundreds) of other parameters; but, if you’re on a tight budget (and in a hurry), this may be your ticket.

Ultimately, quality PM information streams can be made available on a budget, but only if the organization is enlightened enough to eschew superfluous elements of the traditional PMO. Like overly detailed baselines. And risk management (no initial caps).

[i] Christensen, David S., and Rees, David A., Is The CPI=Based EAC A Lower Bound To The Final Cost Of Post A-12 Contracts?, Journal of Cost Analysis and Management, Winter 2002.

In 1988, Watts Humphrey began working for Carnegie Melon University’s Software Engineering Institute (SEI) after retiring from IBM[i]. At the request of the U.S. Air Force, he began assembling and formalizing a structure that could be used to evaluate the stages (or “levels”) of the capability maturity of organizations involved in developing software, resulting in the book Managing the Software Process in 1989.[ii] It didn’t take long for other industries – including PM – to realize that many of the aspects in the Capability Maturity Model were highly applicable to their own industries, and many derivative models sprung up.

In the original CMM, the five “Levels” were:

1. Initial,
2. Repeatable,
3. Defined.
4. Capable, and
5. Efficient.[iii]

In 1998, Captain Tom Schorsch (USAF) published a paper that, in my opinion, has to be one of the most brilliant derivative Management Science pieces ever written, The Capability ImMaturity Model[iv]. In it, Capt. Schorsch discusses a structure where an organization’s capability actually regresses, in “levels” going backwards from the original CMM’s “1,” in this order:

 0.  Negligent

-1.  Obstructive

-2.  Contemptuous

-3.  Undermining[v].

If members of GTIM Nation haven’t read this article yet, it’s absolutely worth your time. It’s both hilarious and insightful, perhaps hilarious because it’s insightful. I would like to adapt Capt. Schorsch’s structure to a more nuanced version that can be expected to be encountered in the PM realm, specifically, because much of the organizational opposition I have seen to PM capability advancement tends to fall into highly predictable categories, by the same organizational elements.

For example, I fully believe that it is Negligent for the Director of a newly-formed Project Management Office (PMO) to spend any time or energy in developing a risk management (no initial caps) capability. Early-stage PMO efforts simply must be directed towards properly capturing scope, and reliably expressing that scope in cost and schedule baselines (formerly known as the “triple constraint”). Once these three baselines have been established, it’s possible to begin the process of quantifying project performance, and inform management decisions going forward. These two steps – capturing the data needed to establish the baselines, and creating the information streams that report on project performance – may sound simple, but that doesn’t mean they’re easy. Any deviation from accomplishing these two early-stage goals bleeds time, energy, and budget away from advancing capability, and will often set the stage for the exact type of regression described in the Capability ImMaturity Model. Nevertheless, many of the risk managers (no initial caps) whom I’ve known will be driven into table-pounding fury if a robust risk management (nic) function isn’t pursued from PMO inception, even though (a) such a capability requires significant time and resources to accomplish, and (b) it offers virtually no usable project portfolio performance information.

Even if the risk managers (nic) don’t succeed in drawing down your organizational impetus for broadly improving PM, you can almost count on the anti-PM presence to try and Obstruct your efforts. I forget where I first heard the saying “project teams detest performance measurement because it vividly shows their lack of performance,” but it’s apt in more instances than one might expect. Organizations that are new to PM are almost guaranteed to retain elements that simply don’t want the scrutiny that comes with PM-centric management information systems, and it should come as no surprise that they will Obstruct its advancement.

When it comes to enduring macro-organizational Contempt, few will equal our friends, the accountants. It’s not because they are naturally given to belligerence, quite the contrary. It’s because almost all business schools (in the United States, anyway) still teach that the point of all management is to “maximize shareholder wealth.” It’s perfectly natural for them to perceive a bunch of PMBOK Guide® enthusiasts who maintain the importance of attaining customer- determined scope, cost, and schedule goals as misinformed and, frankly, straying out of their proper business model – influencing lanes.

Few medium-to-large organizations can have their PM capability regress all the way to the Undermining level without the enemies of the PMO engaging in deceit, or (Maccoby archetype) Jungle Fighter tactics. The good news here, though, is that, by the time the macro-organization has devolved to this level of PM capability immaturity, only two paths forward remain. Either the Undermining elements within the organization will be found out and expelled, or the organization itself will fail.

Either way, the PM talent will have been proven right, if only in the post-mortem analysis.

[i] Wikipedia contributors. (2024, May 25). Capability Maturity Model. In Wikipedia, The Free Encyclopedia. Retrieved 00:26, May 28, 2024, from https://en.wikipedia.org/w/index.php?title=Capability_Maturity_Model&oldid=1225556439

[ii] Humphrey, W. S. (1989). Managing the Software Process. SEI series in software engineering. Reading, Mass.: Addison-Wesley. ISBN 0-201-18095-2.

[iii] Wikipedia contributors. (2024, May 25). Capability Maturity Model. In Wikipedia, The Free Encyclopedia. Retrieved 00:45, May 28, 2024, from https://en.wikipedia.org/w/index.php?title=Capability_Maturity_Model&oldid=1225556439

[iv] T. Schorsch, "The Capability Im-Maturity Model (CIMM)", U.S. Air Force (CrossTalk Magazine), 1996.

[v] Ibid.

Scene: A well-furnished meeting room, prepared for Project Reviews.

Steve (PMO Director): It’s nine o’clock. Which Project is first on the agenda?

Suddenly, Ricky (Project Controls intern) rushes in.

Heads up, everybody – Doug the Consultant is headed this way!

A barely audible groan erupts from the PMs, which quickly goes away when Doug enters the room. Doug is tall, with slightly graying hair, piercing blue eyes, with hints of a military bearing. He sits at the table, near the projection screen.

Steve: Great to see you, Doug!

Doug: First up PM: proceed, sir.

Bob: As everyone can see from this status report, our planned value is ahead of our actual costs, resulting in a positive Cost Variance.

Doug: Your what is ahead?

Bob: The planned value.

Doug: Is that the same as the time-phased budget?

Bob: Yes.

Doug: The more precise term is Budgeted Cost of Work Scheduled, or BCWS.

Bob: Those terms are considered obsolete.

Doug: By whom? (Awkward silence) Here’s the problem – “Planned Value” sounds a bit like “Earned Value,” leading to some level of confusion. The “obsolete” terms should have never been abandoned, which leads to our second problem. A Cost Variance is the difference between the Earned Value and the Actual Costs, not the time-phased budget and actuals.

Ricky: You’re not going to insist that we also use the terms Budgeted Cost of Work Performed and Actual Cost of Work Performed, are you?

Doug: Nope. The new versions of those terms – “Earned Value” and “Actual Costs,” are close enough to the original versions to avoid the same type of confusion represented by “planned value” and “Earned Value.”

Bob: Well, by your definition then, the Earned Value minus the Actual Costs is actually a negative number.

Doug: Tell us about your negative cost variance, then. Also, what’s your Earned Value minus your BCWS?

Bob: That’s also a negative number.

Doug: So you’ve got both a negative Cost and negative Schedule Variance, but were about to talk to a positive spending variance?

Bob: It’s no big deal. What you’re calling the negative Cost Variance is significantly smaller than the amount we have in the Contingency fund.

Doug: Hold on. What’s the cause of your negative Cost Variance?

Bob: We’re still investigating it.

Doug: Well, you can’t just tap your Contingency fund to cover any old Cost Variance. That reserve is only for in-scope, uncosted work.

Mark (assistant PMO Director): Since when?

Doug: Since the terms were invented.

Mark: Well, that’s not how we’ve been using them. We base the usage of all of the reserve funds – Management Reserve, Undistributed Budget, as well as Contingency – on who controls them, us or the Client.

Doug: Another set of problems! Without precise definitions of those reserve budgets, irrespective of who controls them, you’re simply inviting Project Management Baseline chicanery, such as attempts to cover Cost Variances possibly caused by poor performance, with those very reserves.

Steve: Doug, there are literally multiple definitions of those terms out there. Even within our own portfolio, they change based on the customer. What definitions are you talking about?

Doug: Easy. Like I said, Contingency is for in-scope, uncosted. Whether you derive it using a risk analysis (like me, Doug refuses to use initial caps for this phrase) or tack on a flat percentage doesn’t matter. Undistributed Budget is for work that is known to be in-scope at the time of the creation of the Cost Baseline, but there’s no reliable way to estimate it for inclusion in the baseline. Management Reserve is “free BCWS.” The Control Account Managers, or Work Package Managers, “give” back a percentage of their budgets so that the PM can use it however it’s needed, and the Customer really has no say in such usage, save for clear abuse.

Mark: In most of our projects, the Customer has complete control over the Management Reserve.

Doug: Then call it something else, ‘cuz the PM doesn’t “manage” it at all. In that instance, you’re inviting scope creep. What’s stopping the customer from asking for “just this one little addition,” offering to fund it through MR, and bypassing the nominal clearly defined Scope-to-Cost Baseline process?

Steve: Actually, that exact process happens a lot.

Doug: Meaning large portions of your portfolio are likely working under rubber baselines. No wonder its Cost/Schedule performance is so poor!

Bob: I disagree. The reason our Cost/Schedule performance is, errr, marginal, is due to the fact that our clients have some hard-nosed reps in the Configuration Control Board meetings. If we push for Baseline Change approvals too hard, we’ll jeopardize the award fee.

Doug: All the more reason to return to the original names and functions of the reserve budgets. By adapting the newer, less precise definitions and functions of the reserve accounts, you’re making it easier to informally add scope into your projects, based on vague promises that it will all come in under the Contract Budget Base.

Steve: Doug, how, exactly, do you intend to implement such a transition away from the modern PM lexicon?

Doug: One client at a time, Steve. One client at a time.

As most of GTIM Nation is aware, B. F. Skinner was the father of the psychological school of Behaviorism, which essentially holds that all human behavior is learned, derivative of operative conditioning experiences throughout life. While Behaviorism as an all-encompassing school of psychologic thinking has seen a significant erosion of its standing since its heights in the latter part of the 20^th Century, that by no means it should be considered insubstantial in the quest to understand human, ahem, behavior. It remains highly relevant, even if it can’t explain human thinking on a comprehensive scale.

Meanwhile, Back In The Project Management World…

Take, for example, the dilemma of the PM consultant. Presumably, everyone who seeks or enjoys employment as such a consultant is not only advanced in the management sciences in general, and PM in particular, but has attained a certain level of recognition for this level of expertise. Some managerial or executive entity, having recognized a deficit of such expertise within their own organization, reaches out to this consultant to try and find out if they can help the deficient org. Here’s where things get dicey. Let’s posit that the deficient org has a portfolio of projects that are performing poorly in cost or schedule space, and is looking for some kind of magic pill that would turn this performance around. This raises the obvious question, how did that portfolio come to miss deadlines and overrun budgets in the first place? Most likely for having adopted and operated under a business model that gives short-shrift to (even basic) PM approaches. Let’s further stipulate that our nominal consultant, being actually advanced in management sciences in general and PM in particular, points this out, and, after a valid data-gathering cycle, documents some specific recommendations.

What now?

Does the organization’s manager who brought in the consultant go back to some executive meeting with the expectation that the recommendations will be written into policy, and immediately mandated? That may be the hope, but that’s not usually what happens. The managers in the org who have a vested interest in maintaining the existing business model will not stay silent in the face of such a proposed upheaval, cost/schedule performance of the Project portfolio notwithstanding.

On the other hand, if the sponsor was actually aware of the PM capability advancements needed, but was going unheeded in the board room, and brought in the consultant to add gravitas to his already-asserted urgings, then the problem was a lack of a viable implementation strategy for the needed changes, not the validity of those recommendations.

Then we have the scenario where the portfolio is performing poorly across multiple projects, indicating a non-localized causal agent. In other words, the characteristics of the business model that are interfering with the Project Teams’ ability to come in on-time, on-budget are “owned” by multiple layers of the macro-organization. The patient has several problems, not just one injury that can be treated with an expectation of a complete recovery. When such broad-based issues are found, in almost every case the root of the problem is going to be the presence of a lackadaisical attitude with respect to customers and clients which has permeated multiple parts of the macro-organization, and is being reflected in the way the business model evolved to its current poorly-performing state. This scenario means that the consultant, in order to bring about the necessary improvements to the Project Management Office, would have to not only identify the broad-based, wide-ranging changes needed, she would have to actually implement them, or at least give the organization’s hiring manager a workable way of doing so.

So, here’s where the B. F. Skinner angle comes into play. Consultants are as susceptible to operant conditioning as the rest of us. If, after having performed their data gathering and evaluation process, they come back with their PMBOK Guide® guns blazing, they will, in all probability, not be invited to stick around. Even pretend auditors can come into the facility and point to all the things believed to be sub-standard. On the other hand, a demonstrated failure to move the needle on advancing PM capability would also lead to a dismissal – but not immediately. The hiring organization is far more likely to allow a consultant more billable time if they’re not on the receiving end of eat-your-peas-style haranguing, and are, instead, advised to take smaller, more cosmetic steps towards PM maturity, like additional training, or a presentation or two on Communications Management.

Should this tendency be blamed on our consultant? I would argue no. Consider the fact that organizations that, at one level, will admit to a deficiency of PM expertise, while burying those characteristics of the overarching business model that are far more oriented towards “maximizing shareholder wealth,” end up conditioning the PM experts to behave in a very specific manner. Perhaps not as automatically as teaching white mice to run a maze, but an imposed conditioning nevertheless. In short, if the PM consultant fails to effect the type of change towards a more cost/schedule performance positive stance within the macro-organization, don’t blame him. Blame the ossification of the business model that keeps such changes from happening without major organizational upheaval, and the operant conditioning inherent in hiring consultants.

It’s a PM-hostile combination.

After subjecting myself to numerous articles on the topic of Artificial Intelligence (AI), on its seemingly unlimited potential and unnerving capacity to bring about a dystopian future for all mankind, I thought I’d take a moment to consider AI’s most vexing limitation: the fact that complex problems only rarely have direct, simple solutions, but direct and simple are the only ways that AI can actually “learn.” This is not to say that AI can’t be used to discover solutions that hadn’t been previously considered, or that humans adapting an AI-generated solution can’t realize disastrous ends – not at all. I’m just saying that the popular view of AI’s “learning” technique may be imparting to it a level of sophisticated solution-providing that it simply doesn’t have, and likely can’t attain.

Consider that, at its very root, AI can only “learn” via trial-and-error. As an example, how would AI specifically arrive at a solution to, say, discovering which single-digit whole numbers add to ten? That algorithm would have to be limited to the numbers one through nine, calculate each of the possibilities, and then store the successful calculations. The pseudo-code would look something like this:

DO  UNTIL ALL OF THE SINGLE DIGIT WHOLE NUMBERS HAVE BEEN ADDED

DO UNTIL THE RESULT IS 10

ADD 1 PLUS 1

IS THE RESULT 10?

YES: STORE THE COMPONENTS

NO:

ADD 2 PLUS 1

IS THE RESULT 10?

YES: STORE THE COMPONENTS

NO:

ADD 3 PLUS 1

(These four lines incrementally repeat until the numbers 1 – 9 and 9 – 1 have been added together.)

END DO

END DO

TURN THE WORLD INTO A DYSTOPIAN NIGHTMARE

(Okay, that last line has nothing to do with ascertaining a solution to the example problem. It was a joke – though no computer would recognize it as such.)

Then, when the AI researcher retrieves the results, he will find that the stored components are 1 + 9, 2 + 8, 3 + 7, 4 + 6, 5 + 5, 6 + 4, etc. Now, compare this whole process to how a third-grader would attack the same problem, and you can begin to see how more complex or layered problems would be far more difficult to solve using only trial-and-error. Of course, even the most basic computers could execute the trial-and-error algorithm very, very quickly, but the problems that present themselves in Management Science space tend to be far more complicated than the example above – otherwise, we PM-types would find ourselves easily replaced by this nascent AI technology.

Note also that the AI researcher would have had to set up the algorithm with the necessary parameters. This is key to the whole AI-creating-dystopia narrative, where the various computers that had been created in order to address some major problem in real-time, like law enforcement or strategic nuclear arms usage, come up with a solution that never would have been selected by responsible executives or high-level decision-makers, but is, nevertheless, implemented before any actual person can slam the brakes on it. In short, the optimal strategies for major issues, like law enforcement or strategic nuclear arms usage, are so complex as to not be discoverable exclusively through trial and error. Past examples can inform the search for the optimal solution in these instances, including past failures, but they can’t serve as the only method for ascertaining such strategies, tactics, and decisions.

Another way of highlighting AI’s complexity problem would be to consider how the above pseudo-code would be modified if the problem moved from “discover each of the single-digit additive combinations result in 10” to “why do you want to know which single-digit combinations result in 10?” (which is, ironically, something that our comparison point third-grader may well ask prior to attacking the problem in the first place). Indeed, AI is likely to be comparatively helpless when enlisted to answer any question that begins with “why.” Why? (snicker) Because causality doesn’t lend itself to discovery via trial-and-error, unless the alternatives are both (1) identifiable and (2) quantifiable. Yes, we all know that the Titanic sank because it hit an iceberg, but that’s the simple answer – we do not need advanced AI to tell us so. However, if one wishes to consider more nuanced causal factors, such as the speed of the vessel, its rudder’s relative size, the alertness of the lookouts, the lack of watertight caps to the watertight doors, the unavailability of binoculars for the lookouts, and dozens of other factors, simply reading history books would be the way to go. Computers can already perform document searches, so AI doesn’t bring anything to the table there.

One more little tidbit – in the above paragraph, I had originally typed “…that the Titanic sand because…”, and the MSWord Review function didn’t find that odd. My advice, then, would be to tread carefully when tapping AI’s assistance in selecting a solution for an even remotely complex problem. You wouldn’t want the Titanic to sand, would you?