Game Theory in Management

When we’re talking Sustainability (ProjectManagement.com’s theme for April), my first reaction is to recall Carnegie Mellon University’s Software Engineering Institute’s (SEI’s) original Capability Maturity Model®. This model stipulated[i] five “Levels,” with my interpretation of them so:

• Level 1, “initial,” is chaos. Everybody’s doing their own thing, or nothing at all, so that, paradoxically, you can actually have centers of excellence in Level 1 organizations.
• Level 2, “repeatable,” while basic, is fairly universal. Everybody is using the same forms, techniques, and overall strategies as they pursue the targeted enhanced capability.
• Level 3, “defined,” which I equate to “sustainable,” is achieved when the capability being enhanced doesn’t unravel if the heroes who got you this far get hit by the proverbial beer truck. There are enough procedural, training, and shared techniques in-place to ensure the capability survives.
• Level 4 is where you’re just so darn good at this capability that your organization can export it to other, less advanced ones.
• Level 5 (I've never seen anybody get to Level 5) is where you are so advanced at this capability that your organization is routinely discovering solutions to long-endured problems.

Okay, let’s get back to Level 3. Since almost every organization pursuing a more advanced PM capability is enmired somewhere in Levels 1-3, Level 3 becomes something of the brass ring in the Sustainability Sweepstakes. In fact, whenever you hear some new executive assert the idea that he or she will take the organization from Level 1 to Level 4 within a certain span of time (why does eighteen months keep coming up?), GTIM Nation should take it as an automatic sign of cluelessness.

Ennyhoo, we’re trying to get to Level 3, and stay there. Don’t get me wrong – you can get some wunderkinds in the fold, and when they start to export your brilliance everybody has a good day. But that’s kind of rare, even among reputable PM consulting firms. Most orgs would be thrilled just to get to the point where everybody’s pretty much doing the same thing in PM expertise space, and top execs get to host Project Reviews where half the room is speaking intelligently about To-Complete Performance Indices without the other half of the room looking like German Shepherds at a physics conference. So, what’s keeping you from being the champion that gets your organization to Level 3? Some pretty common organizational behavior pathologies, particularly ones that tend to specifically blow up PM initiatives, that’s what. Here’s a partial list.

1. Our friends, the accountants. They don’t act out of malice (well, most of the time) – it’s just that they’ve been taught things that just aren’t so, such as the point of all management being the maximization of shareholder wealth. This little piece of management science misdirection has massive implications, not the least of which is that those management information systems that are designed to provide project performance data are misguided, and will never be as useful as the information already being provided by the General Ledger, in their learned opinion. Since they’ve been trained to believe that this is the case, it will tend to strike them as a waste of time to arrange their chart of accounts to pull actual costs based on the Work Breakdown Structure (WBS). Unless the organization is highly project-oriented (a “strong matrix”), the accountants will be inclined to collect actual costs based on some other structure, like organization. However, no Earned Value Management System (EVMS) can function without actuals being collected (at least) at the reporting level of the WBS, and no project can have its cost performance reliably or accurately measured without EVM. In short, it’s impossible to sustain a PM capability without a bit of cooperation from the organization’s accountants, and, more often than seems reasonable, they don’t have to cooperate.
2. Members of the project team who dislike Project Management Information Systems. As stated above, no project can sustain even a basic PM capability without an EVM. But, even if the accountants are on-board, and willing to provide actual costs at the reporting level of the WBS, there has to be at least a modicum of cooperation from certain members of the project team when it comes to setting up cost baselines, schedule networks, and pulling status each reporting cycle. Much of these steps can be dramatically simplified to make them relatively quick and painless, and even very simple Earned Value systems can generate highly useful and insightful reports. But if, say, Work Package managers (or their functional equivalents) withhold all support, and point to some intellectually vacuous reason such as the supposedly onerous level of participation asked of them that would allow a system to be sustained, the system will unravel.
3. If the sustainable system’s champion seeks to overcome the land mine in #2 above by making project team participation falling-off-a-log simple, thereby removing the “too onerous” objection, there’s still another barrier: the charge that an EVM simple enough to require minimum participation from the Work Package managers can’t possibly provide useful or insightful information about the project’s cost performance, and should therefore be abandoned in favor of the General Ledger (feeding into the barrier from #1 above). This assertion is also false: I have personally set up multiple systems that needed only (a) a time-phased budget (which can be independently derived by spreading the project’s Budget at Completion [BAC] over its period of performance), (b) the project’s actual costs, and (c) an assessment of its percent complete as of the end of the reporting period. Note that both (a) and (b) are usually already available from the General Ledger, leaving only (c) as the totality of the status pull. These systems, as basic as they were, consistently provided early detection of work that was on a pace to overrun, or experience delays, at over 96% accuracy.

But sustainability barriers don’t have to be valid in order for them to be effective.

[i] The Capability Maturity Model: Guidelines for Improving the Software Process, Carnegie Mellon University Software Engineering Institute, Addison-Wesley, 1995, pp. 16.

I get it. I really do. Even the best Project Managers can get to a point where their capacity to adapt to new circumstances, organizations, locations, technology advances … the list goes on and on of those things that force us to modify our strategies and tactics if we are to succeed. It’s easy to look back on previous successes, and desire to repeat that success by, well, repeating those managerial approaches, confident in a repeat of the outcome.

But that’s the catch, isn’t it? By definition, every project is unique, sometimes dramatically so. And there’s really no way of quantifying which PMs were successful due to re-loading tried and true strategies, and which were successful by significantly deviating from those very same strategies. Actually, it’s fairly difficult to differentiate the consistently successful PMs from the repeat failures, due to the wide variety of cover-the-backside techniques, so that coming up with a litmus test for telling the successful ones clinging to traditional strategies from the radically innovative ones is probably impossible.

I know this from personal experience. I had been assigned to set up the cost/schedule performance systems for this one major project where the PM insisted, at the very first project team meeting no less, that he wanted a “swim chart” as his primary method for tracking the project.

“You know, a swim chart!”

“Umm, do you have an example?”

With a sigh and a roll of the eyes, he went to the white board, where he drew a comically crude PERT Chart, with the tasks arranged by organization down the X axis.

“Oh, okay, I see what you want. We’ll need to begin with a Work Breakdown Structure.”

“A what?”

“A Work Breakdown Structure. It’s the way we decompose the scope into the tasks and activities that we can then sort by performing organization.”

“Look, I don’t want to hear about any of that. I just want a swim chart! Can’t you just give me that?” (Point of fact: when a manager starts repeating the word “just,” it’s a sure sign that they don’t have a clue of the difficulty associated with the fulfillment of their demands.)

“Not without some groundwork first” I replied, as meekly as possible.

He called my boss and had me removed from the project.

In retrospect, I understand his frustration. It was clear that, on some previous project where he was involved, this report had been generated on a regular basis, and much of the decision-making had been predicated on it. This PM probably didn’t realize that the org-sorted PERT Chart wasn’t simply a cartoon graphic, or the output of a singularly immature system. I just happened to be the unfortunate project controller who broke the news to him that he couldn’t “just” have one quick and easy.

This why-can’t-it-be-just-like-my-last-project phenomena occurred again, when my bosses’ boss, a fairly seasoned executive, wanted to initiate a new action item tracking system, and wanted me to head up the implementation effort. With the software’s reps on the conference call speaker phone, this exec was very ready to spend some serious coin to make it happen. Like an idiot, I had to ask a question.

“I see you have categories for ‘Action Items,’ ‘Issues,’ ‘Concerns,’ ‘Trends,’ etcetera. Do you have a precise definition for each of those categories? I mean, what’s the exact difference between an ‘action item’ and a ‘concern’?”

“We let the individual users define those.”

“What difference does that make?” stormed the exec.

“Well, it’s just that a given ‘issue’ could show up in a wide variety of systems already in place, or even in multiple categories within the same system. If the same action item shows up in multiple places, and the particulars aren’t in agreement, how do you know which one is correct?” I then addressed another question to the software vendors. “Does this system reach into other tracking systems?”

“No.”

“Then, if one item does show up in multiple iterations, and everybody’s not in complete agreement, how will we know which system has the more reliable information?”

I could see the exec getting visibly upset.

“Look, if you have your heart set on this system, I don’t want to be the barrier. I’ll work whatever implementation effort you choose.”

The exec called my boss and had me removed from the project.

Along about this time my capacity for sympathy for managers desperate to recreate previous, comfortable environs was drying up. This exec clearly had no concept of how valid Management Information Systems are set up, or function, and had fallen prey to a slick and shiny software package that had made some inchoate promises along the lines of how they could provide an easily-understandable report that told him what he needed to pay attention to that day, or that week, and this pesky PMP® was throwing cold water reality on the object of his fascination.

Again, I get it. Having to respond constantly to situations that are only marginally analogous to ones where we were confident that we had the optimal solution gets old really quickly. But that having been said, how many parties do “managers” have to attend where they insist that the hostess change everything to match the parties the managers had previously attended before they don’t get invited any more?

When it comes to advancing Project Management capability within an organization, there are two vaguely-defined monsters that keep popping out of dark corners to savagely obliterate such initiatives. They are “politics” and “culture.” I sincerely can’t count the number of times I’ve heard frustrated managers blame one (or both) of these as the reason they failed in their attempts at “doing” PM, as if these causal agents were completely out of their control. Since we can’t counter such monsters without knowing exactly what we’re up against, I’m going to go ahead and take a shot (get it?) at scoping them.

Politics – at least the variety seen in the office – I define as the pursuit of an agenda that benefits the person pursuing it, but is at odds with the advancement of the project team as a whole. Obviously, if the project team seeks to advance PM capability within their organization, and a member of the team sees an opportunity to benefit themselves at the expense of this advancement, the temptation will be to go ahead and engage in a purely political maneuver.

Recall my previous references to the excellent Michael Maccoby, author of the book The Gamesman: The New Corporate Leaders (Simon and Schuster, 1976), where he posits four archetypes of workers:

• The Craftsman cares deeply about his output, but not so much about for whom he works.
• The Company Man tends to adopt the persona of the macro organization.
• The Jungle Fighter gets ahead through calumny and deceit, rather than through actual merit or quality of contribution.
• The Gamesman sees his paycheck, not as food on the table or a roof over his head, but as a token in some grand game he is playing. As such, he tends to both master the rules of the “game” to a greater degree than the other archetypes, and tends to take risks more willingly.

Now, of these types, whom do you suppose would be more willing to pursue a personal agenda at odds with the Project Team’s direction? If you said “Jungle Fighter,” go to the head of the class; however, if you said “Company Man in an environment where Jungle Fighters have significant sway,” you can leave the classroom, go do whatever it is you want, and I will give you an “A” for the semester.  Should the Jungle Fighters and Company Men influenced by them create a sizable bloc within your Project Team, your attempts to further any legitimate agenda – particularly and especially the advancement of Project Management capability – has been hopelessly compromised, and, finally, office politics would be to blame.

Now let’s address “culture.” What is culture, exactly? I generally hold that whenever you hear some manager say something like “In order for Project Management to be advanced within the organization, the culture has to be right” as another way of saying “Our selected strategy for setting up our PMO was profoundly flawed, but we’re going to blame everyone else for it anyway.” It’s easier to split the blame a few dozen ways, so that many people bear some small part of the responsibility, than it is to pinpoint one or two individuals, and make a crystal-clear accusation that their lack of management savvy or integrity was the proximate cause of the organization’s lack of advancement in PM capability. Even this latter is far easier than taking a good, long, hard look in the mirror and coming to the conclusion that the selected strategy was wrong-headed in the first place.

Now let’s combine the inchoate “politics” and “culture” causes of PM advancement failure, and address them head-on. How political is your Project Team, or the macro organization where it resides? Are there many Jungle Fighters? Are they influencing the Company Men who, if you recall, tend to assume the persona of the organization around them? Have they formed a sizable bloc? If the answer to these questions is “yes,” then you can, indeed, legitimately blame “culture” for the difficulties in advancing PM within the organization. However, this raises additional questions: Who let in all the Jungle Fighters? How were they allowed to advance? Their very presence screams out that the macro organization has drifted away from a meritocracy. Why did that happen? How did it happen? And, most importantly, did you stand by as it was happening?

The answers to those last three questions is key to understanding how the political monster savaged your Project Team, and led to the culture that has little trouble thwarting attempts at advancing PM. Any deviance from a true meritocracy leads inevitably towards the types of political machinations that undermine the overall organizational culture, and do so to the point that legitimate attempts at advancing PM capability are pretty much doomed from the get-go.

So, sure, go ahead and listen to failed PMO directors blame “politics” or “culture” as the insurmountable barriers that prevented a successful advancement of Project Management within the organization. Just keep in mind that, contrary to the way they’re being presented, they are almost never purely external to the person complaining about them.

I know what the ultimate Program Management Office is. It produces winners on a consistent basis, and is probably the closest to a pure meritocracy that any organization has ever, or will ever attain. Any American can join, but overseas GTIM Nation needn’t worry – analogous PMOs exist worldwide. Through this PMO, winning strategies and tactics are truly advanced, with no time given for unproven theories or modes of operation.

The organization I’m talking about? The United States Chess Federation.

“Wait just one minute, Michael!” I can hear GTIM Nation say. “The USCF isn’t a Program Management Office at all! It is, in fact, a collection of people who play a board game, albeit a very sophisticated, ancient board game.”

Fair points, all. But consider: what is a Program Office? Is it not a collection of PMs who manage projects sharing a common theme?

“Chess isn’t a project.”

Perhaps, but projects do share many characteristics with games (Game Theory in Management, anyone?). Besides, each game is unique, with a definitive beginning and ending date (time). Its scope is agreed to prior to its start (checkmate the opponent), and resources are dedicated to it.

But in my opinion what makes the USCF the ultimate PMO is the fact that its members’ value is definitively set, and on a purely objective basis: their score. You can be tall or short, skinny or rotund, beautiful or plain, well dressed or scruffy, and it makes absolutely no difference: if you win chess games, your score goes up. If you lose them, your score goes down. Period.

Compare and contrast this refreshingly objective evaluation basis to what happens in Project Management space. We all know of contractor companies that win large contract awards despite having massive overruns and lengthy delays in their histories. These guys lose, and lose big, but never seem to pay any kind of long-term penalty for doing so. Similarly, there are Project Management consulting organizations that deliver substandard services while charging inflated salaries, and yet, somehow, stay in business. Conversely, smaller, less influential contractors, with winning records, are often shut out from even competing for larger procurements.

Then there are the strategies and tactics that go into specific games projects. In the PM world, so-called experts can sit on the sidelines, pushing baseless assertions about the need to, say, time-phase Estimates to Complete, and how this “analysis” is absolutely critical to proper resource assignment, and print the codex of their idle speculations into guidance documents, and never pay any price for their error. Did any – any – of these people actually manage a project where the time-phased ETC prevented an overrun? No? Again, compare and contrast this to Chess Life magazine, which lists hundreds of Master and Grandmaster-level games. The reader can actually see which strategies and tactics worked, and which ones failed.

Chess players within GTIM Nation know that chess openings – canned strategies for the first 5-15 moves – have their own names, like Ruy Lopez, or the King’s Gambit. Indeed, virtually every named opening has at least several variants, each with their own name. Back when I was playing tournament chess, no player who had failed to commit to memory at least three openings (one when playing white, one when playing black and the opponent opened with 1. P-K4, and another when the opponent opened with 1. P-Q4), each with at least four variants (for those not counting, what was needed was a minimum of twelve game templates, played through around the tenth move) had any kind of chance. On the PM side, we have our own set of must-know canned strategies. The manager who does not know the difference between a Work Breakdown Structure and an Organizational Breakdown Structure, or isn’t familiar with how schedule logic can’t define a critical path within a network if most of the activities have been constrained, isn’t going to (or at least shouldn’t) last long in the PM profession.

In chess, winning strategies remain, and losing ones are abandoned. In Project Management, risk management is a multi-billion dollar per year industry, and yet has no real record of ensuring, or even aiding, project success. Ditto with communications management, or any of a dozen other, in my opinion, highly dubious assertions made in the theoretical quarter. These canned strategies simply seem to hang around and eventually become part of the conventional wisdom without ever having been shown to be the proximate, or even material cause of project success. At the risk of pushing my analogy past the breaking point, chess masters don’t have to deal with so-called communications experts, extolling them to keep their team mates (“stakeholders”) informed of what they’re doing, how, why, or when they do it. Nor do they have to listen to risk managers trying to tell them the odds that their opponent will employ a certain strategy (with an 80% confidence interval, don’t you know). Indeed, it’s illegal for a player in a tournament setting to be so advised.

If GTIM Nation comes away from this blog appreciating the strength of the analogy, great. If not, I understand. But to the latter category, let me add but this: The PMO that successfully enacts the USCF’s two main strengths – personnel status based on a pure meritocracy, and the ability to quickly and effectively reject losing strategies – will consistently out-perform the ones that don’t.

I believe that it’s axiomatic that the two most important questions that any Project Management Information System should be able to accurately answer are:

• At this rate of performance, when will this project be done?
• And how much will it cost?

Oh, sure, there are myriad others bits of information that can help shape the PMs’ overall strategy as well as day-to-day decisions, but I consider them secondary to reliably answering the two questions above. Why? Because a manager’s time is finite. The PM who scatters his energies among all of the activities and tasks within the project will be out-performed by the manager who knows which of her activities are doing fine without her attention, and instead concentrates on those tasks that are facing some kind of difficulty.

So, this being the case, has the optimal strategy for providing the answers to the two key questions been identified?

Yes, actually. In Dr. David Christensen’s paper Determining An Accurate Estimate At Completion[i] (National Contract Management Journal, 1993), he establishes that a calculated EAC is consistently and reliably within 10% of a project’s real at-completion costs once the project has passed the 20% completion point. This, in turn, was predicated on other studies that established the Cost Performance Index’s (CPI) stability. Since almost all EAC calculations involve the CPI (in fact, the most common EAC formula is total budget divided by the CPI), the establishment of its stability was, in my humble opinion, one of the great PM information system breakthroughs of the latter part of the 20^th century. It presented a quick, easy, and accurate way of answering the two main questions cited at the beginning of this blog.

For those of you who are newer to Earned Value Methodology, the CPI is calculated so:

CPI = Cumulative Earned Value / Cumulative Actual Costs

What’s Cumulative Earned Value?

Cumulative Earned Value = Total Budget * % Complete

The algebra whizzes within GTIM Nation probably already know what I had to be shown, that the Estimate at Completion formula, of dividing the Total Budget by the CPI, can be simplified to:

Estimate at Completion = Cumulative Actual Costs / % Complete

“Impossible!” the purists will say. “That critical piece of information can be accurately calculated with just two fairly-easy-to-acquire data points?” Yes, it can, and it gets better: the same formula works for duration! To know, within ten points of the final outcome, when your project will be finished, simply divide the cumulative duration by the percent complete to get total duration. Subtract out cumulative duration, and that’s how much longer you should expect the project to continue.

Now, has the GTIM blog just obliterated the need for comprehensive cost and schedule baselines, and complex Critical Path Methodology networks? Hardly. Those will always be in demand for advanced PM techniques and strategy development.

What the above assertions do (or at least should) overturn is the whole notion that EACs are best calculated using the “bottoms-up” method, where the PM (or cost analyst, or scheduler) re-estimates the project’s remaining work, adds this figure to the cumulative actual costs, and claims victory. Whereas the list of cumulative actual costs is usually reliable, that other component – the re-estimation of the remaining work – almost never is. Every single line item in the new estimate is subjective. It’s what the PM or estimator believes will happen in the future while ignoring what has happened in the project to that point, especially if a spate of poor performance has hit the project. That, of course, will be corrected going forward, the PM tells himself, as it influences away from reality each of the hundreds of data points going into the new baseline estimate.  The whole bottoms-up approach to the EAC is analogous to a person taking a one-mile hike, and being asked mid-point how long he thinks it will take to complete. Rather than look at his timer and multiply that amount by two, he instead tries to guess how far away he is from the finish line. If he had said prior to beginning the hike that he would finish at a certain time, the answer at the mid-point assessment will almost invariably be the same as it was at the beginning, available performance data notwithstanding.

I have no delusions that the above brilliantly-articulated analysis will bring a sudden halt to the practice of coming up with an EAC based on the bottoms-up approach. As a cliched method, it’s simply too entrenched in the commonly-accepted “wisdom” of PM aficionados and guidance-generators, who would rather embrace conventional wisdom than proven, repeatable management science.

And that preference is but one example of why PM is not as technically advanced as it could be.

[i] Retrieved from https://www.researchgate.net/profile/David_Christensen4/publication/228984762_Determining_an_accurate_estimate_at_completion/links/569f9d1908ae4af52546bb07.pdf on March 2, 2019, 13:28 MST.