Game Theory in Management

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?

In last week’s blog, an alert GTIM Nation member added a comment that contained the following:

“Hence, many PMOs operate as a PAAC (Project Accountability Avoidance Office).[i]”

(Yes, the commenter subsequently addressed the fact that the Project Accountability Avoidance Office’s acronym is actually PAAO.)

This set my remaining active brain cells into overdrive, as I reflected on that sentence’s implications. In particular I remember reading about an interview question that went “Would you rather be part of an empire in its ascendency, or its decline?” Let’s set aside the sheer goofiness of this question actually being asked in an interview. Any thinking person would instantly recognize that the potential employer is going to prefer candidates that choose the former, and respond accordingly. But that question, I believe, points to one of the main implications of the term Project Accountability Avoidance Office, that I would articulate as “Project organizations begin with the goal of actually executing scope on-time, on-budget; however, over time, they tend to shift their overall focus on sustaining themselves as a PMO, collecting salaries and scolding internal opponents.” The movement over time from genuine PMO functions towards “Project Accountability Avoidance Office” purposes strikes me as a migration away from accomplishments outside the PMO (the macro-organization’s project portfolio) and towards the internal goals of self-perpetuation and well, to be blunt, influence peddling.

Recall the axiom “This is an unfair thing about war: victory is claimed by all, failure to one alone.” Originally attributed to Tacitus[ii], derivatives include “Success has a thousand fathers, failure is an orphan.” What would lead the nominal PMO to seek to engage in accountability avoidance, then? Would it not be … failure? Failure to bring Projects in on-time, on-budget? Rather than continue asking rhetorical questions, let me just drop this unattractive truth on the conference room table: when the project portfolio performs poorly in cost and schedule space, the whole reason for having a PMO in the first place comes into play. If such a PMO is already in sustaining-themselves mode, their tactics will become more and more off-putting, as they will attempt to justify their existence through narratives that are divorced from actual performance, and more along the lines of the eat-your-peas-style hectoring that I often decry in this blog.

And here is where a cruel irony of the Project versus Asset Management struggle manifests. There is no Return on Investment (ROI) without happy clients, which, in turn, doesn’t happen without effective PM. But, once those clients are being confronted by overruns and delays, the litmus test that will be used to overhaul (or even dismantle altogether) the PMO will be the ROI.

So, how does the PMO Director keep from crossing the line between legit PMO and the downward slope towards PAAO? For this I want to turn to one of the four Maccoby archetypes, the Company Man.

Quick refresher for recent GTIM Nation additions: the brilliant Michael Maccoby wrote a book entitled The Gamesman; The New Corporate Leaders (Simon and Schuster, 1976), in which he posits four worker archetypes:

• The Craftsman doesn’t really care for whom he works, but does care about the quality of his output.
• The Company Man tends to assume the persona of the team around him.
• The Jungle Fighter gets ahead through calumny and deception, clinging on to victors and distancing themselves from losers.
• The Gamesman doesn’t see his salary or other benefits as a roof-over-the-head, or food on the table. Rather, he sees his renumeration as some kind of token in a grand game he’s playing. Because of this he is both more likely to have attained a mastery of the “rules” of this “game,” while being more willing to take risks.

The canary in the PMO-to-PAAO path coal mine is going to be the Company Man. Craftsman and Gamesman will feel right at home in the legit PMO, Jungle Fighters in the PAAO, and each will feel out-of-place in the opposite environ. What are your Company Men doing? Remember that they tend to take on the persona of the organization around them, in this case, the PMO. Are they directly involved in advancing PM capability within the organization? Or are they attempting to distance themselves from failing/failed Projects, Jungle Fighter-style?

If the latter, there’s at least a possibility that your PMO is starting to turn into a PAAO.

Three strategies will help avoiding that path: (1) keep your PMO lean, spending only on the things that actually improve Project performance, (2) base assessments of PMO value on actual portfolio cost/schedule performance – no appeals to what others hold to be “proper” management techniques, and (3) keep reading this blog.

[i] Freeman, George, from the comments section of the Game Theory In Management Blog, posted 16 April 2024.

[ii] Retrieved from https://dailystoic.com/success-many-friends-failure-orphan/ on 20 April 2024, 19:47 MDT.