Game Theory in Management

The primary information systems that allow PMs to make, well, informed decisions are predicated on two methodologies: Earned Value for cost and Critical Path for schedule (anyone expecting me to include the risk management guys in this list hasn’t been reading this blog for very long). While many pieces of insight flow from these systems when they are operating properly (or even a little improperly – these systems have amazing self-correcting capabilities), their primary outputs deal with the ability to accurately forecast when your project will finish up, and how much it will cost when it does. Because of these capabilities, those PMs who eschew EVM or CPM rarely stay within the ranks of management for very long, being easily out-performed by their better-informed competitors.

However, like any other Management Information System (MIS), Critical Path and Earned Value are susceptible to what is colloquially known as the garbage-in, garbage-out phenomena. As my regular readers know, I maintain that all valid MISs have the same basic architecture, comprised of the following three steps:

1. Data is gathered based on a certain discipline, e.g., accountants need a handle on all expenditures and incomes to make a general ledger work.
2. The data is processed into information, based on some methodology. For (again) accountants, this involves properly identifying what place the transaction has in the ledger, and entering it as either a debit or a credit, and, at a set time, compute the totals of the entries and compare ledgers.
3. The information is then delivered to decision-makers in a way that they can readily understand it. If a manager doesn’t know the difference between a balance sheet and a profit-and-loss statement, being fed information from the finest accounting system in the world loses much of its utility.

Based on this basic, three-step MIS architecture, any information system that messes up Step 1 is going to be vulnerable to the information delivered in Step 3 being inaccurate and, therefore, not actionable.

So, is there an aspect of PM that can have an influence on the quality of the data being collected for Earned Value or Critical Path analysis? Sadly, yes, and this aspect is captured in the old, cynical observation “All projects proceed on-time to the 95% complete point, and then stay at 95% complete forever.”

The percent complete parameter is central to both EVM and CPM. It’s how they produce all of their usable information. In the original Cost/Schedule Control System Criterion there were seven approved methods for collecting the percent complete figure:

• Direct Units is the most objective. If your project is to make 100 widgets, and you need to know what your percent complete is, just go and count the completed widgets. This applies to square feet of concrete poured, or linear feet of pipes installed, or any other scope that can be directly measured.
• Apportioned Units has to do with a proportional relationship with other, direct units. If each of your widgets needs two gonculators to make a complete unit, then measure the gonculator task on a two-to-one basis with the widgets.
• For very short-term tasks, the 0 – 100 method is often used. You’re either completely done with the task, or you can’t claim any progress against it.
• For tasks that should finish within two reporting cycles, the 50-50 method can be useful. You can claim either 50% complete, or 100% complete. No other percent complete figures may be used.
• Weighted Milestones are a bit more subjective, but still highly useful. This is where the PM decides the percentage weight of interim milestones within the task, such as, in performing an analysis, the initial investigation is worth 15%, first draft of the report equals 40%, second draft is 65%, submission of the report to the customer is 85%, and customer approval is 100%.
• Level-of-Effort is kind of cheating at the percent complete game. The amount claimed as having been accomplished is set equal to the cumulative amount of the time-phased budget. This technique is set aside for those activities that don’t really have tangible output, like (ironically) the project management task.
• Okay, here’s the fatal percent complete technique, the Milestone Estimate. This is where you contact the Control Account Manager (CAM), and request an estimate of the percent complete as of the end of the reporting period. This is also known as the “liars’ method.”

If one of your CAMs is manifesting the behavior of passing along a percent complete that is known to be overstating progress in order to avoid the scrutiny that would otherwise come from honestly reporting a negative variance, then neither your EVM nor CPM will deliver accurate information about the impacted Control Accounts.

Fortunately, there are two effective fixes (and one hack) for this fatal MIS quality issue. First, minimize the number of Control Accounts or Work Packages that use the Milestone Estimate method. Level-of-Effort is routinely avoided, but even it doesn’t present the system-blasting capabilities of a mis-used ME technique. Second, only allow highly-trusted CAMs to be in charge of tasks being measured with the ME technique. And when I say “highly-trusted,” I do not mean “well-regarded.” I mean, if the CAM in question has ever indulged in that whole “projects proceed on schedule to 95%, and stay at 95% forever” business, they are removed from the trusted ranks forever. The hack I referred to is this: never allow any task to claim over 85% complete until it is completely done. I know, I know, this will introduce a few artificial negative cost and schedule variances in to some long-lived tasks.

But it will also give you, the PM, a usable warning when one of your Cost Account Managers have been gaming the Milestone Estimate method, and exploiting Project Management Information Systems’ fatal flaw.

Well, I am, for one.

Don’t misunderstand – for any given good or service I procure, I want the highest possible quality version, and become quite frustrated when the things I buy end up failing in executing their purposes, either in effectiveness or lack of longevity. Like anyone else, I tend to avoid those vendors who sharply disappoint me, usually forever.

“So,” I can hear GTIM Nation say, “why do you claim to be against quality?”

Because of the way it has been shoe-horned into the Project Management codex, that’s why. Examples follow.

The first reason I find Quality Management experts highly off-putting has to do with their tools, especially the Ishikawa, or fishbone diagram. According to WhatIs.com, a fishbone diagram

… is useful in brainstorming sessions to focus conversation. After the group has brainstormed all the possible causes for a problem, the facilitator helps the group to rate the potential causes according to their level of importance and diagram a hierarchy. The design of the diagram looks much like a skeleton of a fish. Fishbone diagrams are typically worked right to left, with each large "bone" of the fish branching out to include smaller bones containing more detail.[i]

Note the use of the term “brainstorm” in the first two sentences – clearly it’s a large part of creating the diagram. But science is not consensus, and consensus is not science, not even management science. If you are relying on the subjective opinions of the members of your team in order to uncover some hidden truth or insight, you’re doing it wrong. And, as if that wasn’t bad enough, the “facilitator helps the group rate the potential causes according to their level of importance.”[ii] Rate the level of importance? Based on what, exactly? It’s yet another opportunity for subjective inputs to influence the direction of the analysis of the problem under investigation.

Then there’s the whole issue of identifying causality. I’ve been in my share of Six Sigma quality reviews, and never, not even once, heard the facilitator mention the distinction between proximate and material causes. The short answer is that a proximate cause is clear and direct, as in the first domino caused the second one to fall over by being, itself, tipped over. The material cause would be that the second domino fell over because it had been stood up on edge right next to the first domino, thereby qualifying for the “if-not-for” test. This may seem to be mere semantics at first glance, but the distinction in properly identifying remedies to the problems being investigated is huge. For example, one tactic in filling out the fishbone diagram is to ask “Five Whys.” An example I’ve used before involved the sinking of the Titanic. The cause of the Titanic’s sinking, of course, was that it hit an iceberg on the night of 14 April, 1912. One line of the “Five Whys” can go like this:

• Why did the ship hit the iceberg? Because it couldn’t turn away from it in time.
• Why couldn’t it turn away from it in time? Because the lookouts did not give the helmsman sufficient warning.
• Why didn’t the lookouts provide sufficient warning? One reason was that they didn’t have access to the binoculars they would usually use.
• Why didn’t they have access to their binoculars? Because they were locked away in a storage locker, and nobody on-board had the key.
• Why didn’t anybody have the key? Because the person who had the key had been fired prior to the Titanic setting sail, and hadn’t handed them over when he left.

So, based on this “analysis,” some useful strategies in the avoidance of similar maritime disasters would include:

• Don’t fire the person who has the keys to the binocular locker.
• Or, if you do, make sure you get the keys back.
• Alternately, you could ensure that multiple pairs of binoculars are carried on every voyage, and no two of them are kept in the same locker.
• If, however, you find that the only pairs of binoculars are, indeed, in a locked locker, take an axe and destroy the door to the locker.
• If your ocean liner company has a rule against axing open any locker, turn the ship around and go back to port where more pairs of binoculars can be procured (hopefully, quality ones [get it?]).

I could go on (and often do), but you see my point. Without a clearly articulated distinction between proximate and material causality, all the Ishikawa diagram does is help structure a conversation. It doesn’t really help identify the optimal Project Management strategy to either an experienced or looming PM disaster stemming from poor quality.

The other reason I’m opposed to the way Quality Management has been pushed onto the PM universe is due to the notion that those doing the pushing are somehow automatically afforded the intellectual high ground. Touching on the title of this blog, there’s a definite stigma attached to anyone who actually comes out and challenges the notion that Quality Management-types could ever be mistaken in their recommended strategies. But as I’ve been reminding GTIM Nation over the past few months, the old PM saw “Quality, Affordability, Availability: pick any two” is unavoidable. For the Quality guys to automatically assume that their favorite aspect of project delivery is a foregone conclusion strikes me as, well, lacking perspective.

Think about it: you don’t see Affordability or Availability getting their own sections in the PMBOK Guide®, do you?

[i] Retrieved from https://whatis.techtarget.com/definition/fishbone-diagram on May 12, 2019 at 17:14 MDT.

[ii] Ibid.

A lot of pixel ink has been spilled on the topic of Project Management, but most of what I’ve read has to do with what it is, or how to do it. There’s been some additional content on where and when to do it (i.e., which situations call for a PM approach), but one topic I do not remember seeing is: why? Why should we do Project Management? (And, no, I don’t accept “because it’s the right way of doing management” as a valid driver.) I think an examination of motives here will help shed some light on the other, more often-addressed questions.

There are a few reasons, to be sure, but before we tackle them let’s define some terms. A first-person transaction occurs when you purchase a good or service for yourself. Depending on which parameters are more important to you (remember: Quality, Availability, Affordability: pick any two), you will select a vendor and a price, and your first-person transaction is complete. In the PM world, this is the kind of transaction that occurs, say, when an airline contracts with an aerospace company to create an airplane that they will use for their routes.

Second-person transactions are a bit different. This is when you are buying a good or service for someone else, like a gift. Even in those instances where you are well acquainted with the gift recipient’s wishes, the purchaser’s parameters (particularly cost) are far more likely to become the deciding factor(s). The PM example here is when a city counsel arranges to repair roads. Sure, the counselors use those roads, but the most usage comes from the population of the city in general. Since the budget issue is usually already fixed, the question comes down to: Should the road repair be of just-good-enough quality, or will the populace be okay with orange barrels and lane closures for an extended period (one would hope that both won’t occur)?

Here’s where the examination of PM motives gets gnarly. In third-person transactions, the person performing the transaction neither pays for the good or service, nor do they receive the benefits. It’s one of the reasons why government-provided services fail so often: the bureaucrat deciding how much money to fund the provider facility isn’t spending his own money, nor is he the person seeking help at the moment the transaction is occurring. Due to this lack of alignment in setting the consumers’ desired parameters against the providers’ goal in providing the service(s), the odds of developing (much less implementing) the optimal management approach are extremely low.

Meanwhile, Back In The Project Management World…

What are the implications for Project Management? Well, in first-person transactions, the customer would be interested in the robustness of their subcontractors’ PM expertise in order to avoid overruns or delays in critical projects, particularly in Cost Plus Fixed Fee (CPFF) or Cost Plus Award Fee (CPAF) contracts. The suppliers of such project work would be motivated to support some level of PM expertise in order to prove to their current or prospective clients that they aren’t complete dufuses when it comes to managing large projects, and are deserving of the contract award. Both customer and supplier are strongly motivated to request and provide some level (note: not necessarily highly advanced) of PM expertise, and demonstrably so.

For second-person transactions, there’s still some level of motivation, albeit a bit lessened from first-person. People purchasing goods or services on behalf of a government, for example, are usually keenly aware of the need to spend taxpayer monies efficiently, if for no other reason than cases of foolish government expenditures tend to make for very bad press (the “bridge to nowhere” scenario, for example).

But now we come to the scenario where much PM chicanery is not only possible, but basically invited. In third-party transactions, where the PM practitioners are neither spending their own money for managerial expertise, nor receiving any goods or services from the contractors, I have to ask: what is their motivation? For example, when one of my favorite targets, the nefarious-but-unnamed guidance-generating organizations, pushes out another document stating that risk management is a really swell idea, and everyone in the PM world ought to do it, I have to ask: why? What business is it of theirs in the first place? What do they have to gain? These guidance-generating “experts” are the equivalent of a self-proclaimed know-it-all hanging around the electronics section of a major retailer, scolding customers if they don’t seek the same options or features the know-it-all thinks matter. Such a one would be sent packing by (real) managers in short order for being insufferable meddlers. In my opinion, the exact same thing should happen to these guidance-generating organizations.

“But Michael!” I can hear GTIM Nation say. “Didn’t you just indict legit professional organizations, like the Project Management Institute®?” No, and here’s why. While PMI® certainly does generate guidance, they have skin in the game via the Certification Department. If someone with a PMI® credential asserts some truly dopey stuff (I’m not saying it never happens, but it’s far from common) then the entire brand suffers, from membership all the way up to the top execs. Conversely, risk managers can point to their allies in the guidance-generating world who assert any project bereft of RM is doing PM “wrong,” and pointing out the percentage of successful projects also bereft of RM will not overturn these assertions. It’s immune to real-world evaluation and analysis, because neither the consumer nor the supplier gains or loses a thing based on the validity of the “guidance.”

So, which PM techniques are most appropriate, efficient and effective for a given project? I have a good idea what the answers are. But first, I need to know: why do you want to do PM in the first place?

For my last blog on Sustainability (ProjectManagement.com’s theme for April), I want to get away from analyzing the more technical aspects of the Project Management Information Systems that comprise a mature, sustainable PMO, and focus instead on another key element: organizational behavior and performance. After all, even the best, most efficient system, implemented with the optimal strategy, is going to fail if the personnel involved can’t (or won’t) make it work. While modelling human behavior can be very tricky, there are some usable insights that can be gleaned from the available scholarship, mixed with my own observations.

For example, I’ve often referred to Michael Maccoby’s excellent book The Gamesman: The New Corporate Leaders (Simon and Schuster, 1977), and the organizational archetypes he discusses, particularly the Jungle Fighters. I have come across more than my share of this type (or, perhaps, I’ve become sensitized to them, and more readily recognize when they’re around), and it seems to me that they can be sub-categorized so:

• While all Jungle Fighters use deceit and calumny rather than actual performance to get ahead, the subcategory I’ve dubbed the Novice is the most innocuous. The Novice will pretty much confine his dubious machinations to claiming credit for work he didn’t do, while deflecting blame for things that went wrong. Some non-Jungle Fighters will engage in this behavior episodically, but JF-Novices will use it as a kind of standard template, their go-to canned strategy whenever they interact with the rest of the project team. These shouldn’t be ignored – pretending to address the projects’ scope while actually manipulating people and circumstances in order to evade responsibility for one’s mistakes is clearly counterproductive behavior. If you are confident that even this anodyne variety of Jungle Fighter is on your team, it would be good to get rid of him; if you can’t, at the very least keep a sharp eye out.
• The next step up in my scale of Jungle Fighter severity I’ve named the Aggressor. In addition to the Novice’s tactics, the JF-Aggressor will deliberately select targets within the project team to undermine, and will then carry out a series of actions to make their lives miserable. Their favorite approach is to engage in ex parte discussions with the other members of the team, at first, and then, when their slanderous narrative begins to gain traction, such discussions will happen with management. The point is to make the JF-Aggressor appear to be the target’s superior in some way, by downplaying the target’s contributions, or by making some claim to having been victimized by the target. If a JF-Aggressor perceives he is not receiving the level of attention or accolades that his inflated ego demands, he can (and will) make their targets’ working hours nightmarish, and can unravel team cohesion at light-speed.
• The most dangerous variant of the Jungle Fighter to the successful initiation of a sustainable Project Management Office I’ve labelled the Master. In addition to being able to expertly perform the tactics of the Novice and the Aggressor, the JF-Master will attempt to manipulate the thoughts and feelings that third-party Project Team members have among each other. Consider the example of a Project Team made up of two Craftsmen (Craftsman A and B), a Company Man, the Target (who can be of any of the Maccoby archetypes), and the JF-Master. The JF-Master will attempt to turn the opinions of the two Craftsmen against the Target using slander and calumny. When these tactics fail (Craftsmen are usually resistant to the Jungle Fighter’s machinations), the JF-Master will begin to lean on the Company Man, not to antagonize the Target, but to influence the stubborn Craftsmen. Think of Iago in Othello, who successfully poisons Othello’s opinion of the virtuous Cassio and, by extension, Desdemona, who dies as a result. As far-fetched as this sort of strategy sounds, I’ve seen Jungle Fighters engage in it, and succeed.

I genuinely hope that the vast majority of GTIM Nation is now thinking “ProjectManagement.com clearly does not care if its bloggers are from the universe where Spock has a beard, ‘cuz I have never encountered any of the archetypal behaviors that Hatfield is ranting about.” But my sense is that at a significant percentage is thinking “Michael just described one of my (former or current) co-workers to a tee.” What to do about it?

First off, Jungle Fighters cannot advance at all in a pure meritocracy. Unfortunately, the only large organization that I’m aware of that operates as a pure meritocracy is the United States Chess Federation (US Chess®), where your point ranking is your value to the organization, and Jungle Fighters can slander away without ever changing a thing. If the target can consistently point to an objective record of scope accomplishment and/or high performance, some level of JF insulation can be had.

Another very effective anti-Jungle Fighter strategy is the elimination of ex parte conversations. If any employee engages any manager on the topic of another Project Team member, the manager must stop such conversations until the third party being discussed is present. The first time the PM does this, the Jungle Fighters will have one of their key tactics ripped away from them, and they will become far less effective. Unfortunately, this counter has to come from management, and a lot of managers are either unaware of this type of toxin, or they do not care.

A third strategy is to make other Project Team members aware of the existence of Jungle Fighters within the organization. But don’t use ex parte discussions to do so – that’s a marker of the Jungle Fighter. Instead, copy this blog’s link, and send it to the members of your team. The beautiful part of this action is that the Craftsmen, Company Men, and Gamesmen will either ignore the link, or read it with casual interest. The Jungle Fighters, though, will become agitated, thereby revealing their true natures.

Alternately, one could hang a full-length mirror in the Program Office, and note those who do not cast a reflection.

No self-respecting management science blog with the term “game theory” in its title can go long without using that favorite analytic tool, the Payoff Grid. What can a Payoff Grid add to the Sustainability discussion (ProjectManagement.com’s theme for April)? Plenty, as I will demonstrate.

GTIM Nation is familiar with a couple of themes I would like to revisit, one of which is my personal implementation of the Pareto Principle, that the 80^th percentile best managers who have access to 20% of the information needed to obviate a given decision will be consistently out-performed by the 20^th percentile worst managers who have 80% of the information so needed. If we add in another theme that I’m in the habit of addressing, that of so-called PM experts joining guidance-generating organizations that churn out a whole bunch of, well, nonsense, we have the two main ingredients needed to set up our Payoff Grid.

On one axis, let’s put managerial expertise, with the extremes represented on the one end by managers who are either inept or possess personality traits that makes them extremely poor leaders(or, sadly, both), and on the other end by extremely capable managers, blessed by both an advanced technical understanding of PM and the scope being pursued by their team(s). On the second axis we’ll use as the gradient the nature of the management information systems feeding them what they need to know in order to make the optimal decisions for the attainment of their program/project/portfolio goals. Such a Payoff Grid would look like this:

Table 1. Sustainability Payoff Grid

Before reviewing the Scenarios themselves, here is my list of the attributes of an advanced Project Management Information System:

1. Its information has to be accurate. While this may appear to be obvious, it’s clearly not to many “advanced” practitioners, due to the prevalence of systems that are predicated on subjective data.
2. Its information must be timely. Old information – even when accurate – will get you beaten by the competition, or by fast-moving changes in circumstance.
3. Most importantly, it must be relevant. Irrelevant information clouds the decision-making environment, rather than adding clarity.

Based on this standard, GTIM Nation can see why I have so much heartburn with modern risk management theory, as-practiced. Having someone – anyone – tell you, say, that there’s a 67% chance that you will experience a weather delay will almost never be accurate nor relevant.

So, on to the individual scenarios.

Scenario C exists far more often than it ought and, as I pointed out in my two previous blogs, some of the blame rests with us practitioners. If the people setting up the baselines are far more interested in the risk management plan than they are the critical path schedule network or the Earned Value Management system, then the PM information systems created will be virtually worthless, feeding a poor PM to boot. It will be next to impossible for this Scenario to result in a sustainable system.

Scenario D will also not result in a sustainable system, but for very different reasons from those underpinning Scenario C. An advanced PM who is successful not because of, but in spite of the deficiencies of her PM Information will lose patience with those who designed and set up the baselines, and will select very different personnel/systems in the future. So, no sustainability here.

Scenario A improves the Sustainability odds considerably, due to Hatfield’s application of the Pareto Principal. Oh, sure, there’s a chance that the poor manager will not recognize that his success rate is far more predicated on his ability to make informed decisions rather than any innate ability; but, for the most part, he will not only recognize the essential nature of the Earned Value and Critical Path information he has consumed, but will insist that these relevant information streams be set up in all future projects he works. Sustainability achieved!

Finally, Scenario B holds the best chance that a given PM maturity is sustainable. Successful PMs tend to attract more work, and are additionally better attuned to the relative merits of the various management information systems available for any given budget. The odds of a consistently successful PM basing cost performance decisions solely on, say, the information coming out of the General Ledger are remote indeed. These PMs’ strategies will contain the ability to discern which information system characteristics are vital, and which have nothing to do with an enhanced ability to advance the implementation of those strategies. The vital ones will remain, or become “sustained,” while the others fall by the wayside.

Not to put too fine a point on it, but, as the Payoff Grid shows, a relevant, accurate, and timely PM information system is far more likely to become Sustainable, even in the event of being paired with a poor manager, whereas a poor PMIS is pretty much doomed, no matter the level of PM expertise it’s supporting.

Is your particular system going to be Sustainable? Check Table 1, and I’ll get back to you.