Game Theory in Management

In the movie Superman (1978), Lex Luthor (Gene Hackman) has deduced that a fragment of the exploded planet Krypton has arrived on Earth in the form of a meteorite that landed in Addis Ababa. One of his two assistants, Eve Teshmacher (Valerie Perrine), has the following line: “I know I'm gonna get rapped in the mouth for this, but... So what?” Lex goes on to explain that the meteorite must have the same “specific radiation” as the doomed Krypton, and is therefore lethal to Superman, a conclusion which is somewhat unintuitive to those unfamiliar with the Superman canon. Due to the power of movie magic, however, it is both accurate and relevant (and timely, given the super-caper that Lex is planning at the moment).

Meanwhile, Back In The Project Management World…

In this blog I would like to combine two themes I address on something of a regular basis, to wit:

• The PM world can be divided into two camps: Processors, who don’t really care about projects being brought in on-time, on-budget, but care a great deal about people following “proper” procedures; and Performers, who don’t really care about process, but just want to bring their projects in on-time, on-budget.
• Of the thousands and thousands of PM-based software packages out there, the ultimate test of their worth has to do with their ability to deliver information that’s (1) accurate, (2) timely, and (3) relevant. Failure on any of these points renders the whole system invalid, and, therefore, worthless.

Now, there are several organizations/associations that crank out what they perceive as usable insight in documents – procedures, directives, implementation guidance, whatever – but this so-called guidance also must answer to the standards for PM-oriented software. For example, I’m aware of a certain guidance document that demands that an ongoing comparison be made between a project’s Basis of Estimate (BoE) and the actual costs incurred, at the line-item level. This guidance document was produced by a group that claims many supposedly high-level PM professionals in its ranks, and they pretty much expect to be taken seriously. Sadly, I can’t.

One of the very first rules that Project Controls Specialists (and, one would hope, Project Managers) learn is that comparing budgets to actual costs is useless. I would go one step further and say that it’s often misleading. Consider my favorite example, one that I use when teaching basic PM.

You’re the manager of a two-month-long project to produce 2,000 widgets, with a budget of $2000 (USD). You time-phase your budget to $1000 in Month 1, and $1000 in Month 2. At the end of Month 1, your accountant comes to you and says your have spent $1100. How are you doing?

If you said “I know I’m gonna get rapped in the mouth for this, but if I don’t know how many widgets I made, why is the amount I’ve spent relevant?” go to the head of the class. The seemingly intuitive conclusion that something has gone wrong because you’ve spent $100 more than planned, is rendered completely irrelevant if you have, in fact, made, say, 1300 widgets. In basic Earned Value parlance, you are not only not in bad shape, you are actually performing well ahead, enjoying a 18% positive cost variance, as well as a 30% positive schedule variance. If you had mistakenly presumed that spending $100 more than budget was a bad thing, you would have blundered in any action taken based on that so-called analysis. And yet, here’s an organization pushing the idea that such an analysis produces usable PM information simply because it’s happening at a more granular level of detail. Guys, it’s irrelevant! And, by pushing such an assertion, it kind of makes your organizations look, well…

Who’s Behind This Massive Criminal Conspiracy?

So, who, exactly, is pushing this narrative? I seriously doubt their numbers include a significant population of Performers. Performers don’t think that way. It has to be the Processors, who churn out this stuff blithely unaware of any duty they have to relevancy, nor of the fact that not even movie magic can make the budgets versus actuals analysis reliable or insightful. As long as they can push out “guidance” that compels a certain analytical behavior, they’re happy as clams, regardless of whether or not such analysis yields any usable management information. It’s almost as if they were assigning tests to the PM world, to see if they can make its adherents accept the predicate that such useless analysis must be performed in order to lay claim to “doing” legitimate Project Management. Naturally, to call into question the basis of their assertions, much less their motives, is to incur their wrath, and invite being rapped in the mouth.

But I’ll take that chance, because much as I would hate to see California fall into the Pacific Ocean due to nuclear weapon-induced cataclysmic earthquakes, that can only happen with large doses of movie magic. Conversely, furthering the idea that comparing budgets to actuals is a key aspect of legitimate Project Management doesn’t require any movie magic at all. It just needs PM’s current practitioners to become fearful of these criminal masterminds Processor-style PMs

In previous posts I’ve made the distinction between the two types of Project Management experts one comes across these days: the Performers and the Processors. In evaluating the effects of ever-improving technology on the PM field, I think it’s prudent to break out such advances based on these two very different types of consumers.

For the Performers, this is a pretty easy analysis. You see, Performers don’t care too much about following overreaching policies or guidance documents. They really just care about delivering their projects on-time, on-budget, to the client’s satisfaction. This being the case, the PM information technology that will interest them the most involves the Project Controllers’ ability to put into their hands the timely, accurate, and relevant information needed to attain that end. Assuming my bifurcation of the PM world is accurate, that means that the most valuable tool that the Performers could have would be a kind of PM Information Nonsense Detector. Such a tool would be very useful indeed when those Processors whom have (unfortunately) attained some level of organization authority begin to harp on about how the Performers “need” to have more stakeholder engagement, or a more robust risk management plan. The PM Information Nonsense Detector could then emit one of a variety of pre-selected sounds, including:

• A ring tone, like a cell phone would make. This would give the Performing PM an opportunity to pretend to pick up the PMIND as if it was a phone, and say something like “Hey, Ted. Yeah, you’ll never guess what the so-called experts from corporate want me to do this time!”
• A pre-recorded laugh track, hopefully one that includes laughter that’s clearly derisive.
• A recording of a voice very similar to the Lost In Space’s robot’s, saying “Danger! Danger! Absurd ideas being furthered!”
• An ear-splitting siren, followed by a female voice (similar to Siri) saying “Sorry, I simply can’t suffer fools gladly.”

While all this is going on, the PMIND searches the web for specific refutations to the nonsense currently being rendered. For example, if the risk management types are pushing their agendas, the PMIND would provide valuable quotes from Douglas W. Hubbard’s excellent book The Failure of Risk Management, or maybe even past Game Theory in Management blog entries.

What If We Make Them Mad?

I’m happy to provide the idea for this device to ProjectManagement.com and my readers, since I’m confident it will make a mint. For those of you who readily recognize that innovative, technically-advanced products that make a lot of money for their manufacturers also incur the wrath of those whose approach to PM is so full of folly that it provides the impetus for the demand for such a product, do not worry. We’re talking Processors here. Let’s say that, as the demand and profit margin for the PMIND soars, its patent owner(s) receive one of those threatening letters composed of letters cut out of newspapers and magazines. The response should be something like “We are in receipt of your letter threatening us if we continue to market and sell the PMIND, thereby rendering almost all of your insipid conference paper presentations and guidance-generating activities plainly absurd. Prior to full compliance with your demands to cease and desist, we have one request: given the volume of such threatening letters we receive, could we impose on you to settle on a specific format for these missives? For example, the difference in the size of the font in the cut-out letters between the “u” and “f” in the second word of the third sentence, “suffer,” is so dramatic as to render the whole sentence – and therefore your essential message – virtually unreadable. If you could simply agree to a procedure that would stipulate a mean font size consistency in cut-out letters in threatening communications, it would be much easier to implement your demands.” I can guarantee you that the Processors behind the threats will then immediately convene to discuss your request and appoint a panel to further explore the basis for generating the procedure. This panel, after many heated arguments, will finally deliver a rough outline for the procedure, where it will go to some sort of “governing committee,” who will review the outline, and make recommendations prior to the commissioning of the actual writing committee. The whole lot of them will engage in this kind of behavior ad infinitum, never getting around to actually carrying out their threats.

I Haven’t Forgotten The Opposition!

For the Processors, have I got a technology advance for you too! This device, the Process Implementation Gadget, or PIG, will inflict irritation, frustration, or even pain on those Performers who refuse to obey your arbitrary and capricious speculations well-thought-out guidance on how PM should be done. It works like this: whenever you encounter a Performer PM, the PIG will search the General Ledger for the cost accounts she is responsible for. It then searches those projects’ stored documents for things like a risk management plan, or a Lean Six Sigma Quality Control Plan, or a Stakeholder Engagement Strategy statement, or….well, you get the picture. Should the PIG fail to find any of these documents in the record, or, having found such a document, recognizes it as mostly boilerplate, it automatically sends an e-mail to that PM’s line manager, and that person’s line manager, and so on up the organization chain, with the message that the offending PM is not in compliance with the organization’s arbitrary and capricious speculations well-thought-out guidance on how PM should be done. You’ll be able to cause these PM renegades so much grief that they will gladly engage you, and allow you access to their charge codes, just to get you to sign off on whatever waiver they need to make you go away. Everyone wins! You can then go and brag about how your honorable intervention was the proximate cause of that Performer’s subsequent success at various PM seminars!

I look forward to the day that a project kickoff meeting has both PMINDs and PIGs at the ready as the strategic approach to the given project is assessed and designed, just to see which invention carries the day. I know which one I’m rooting for.

One of my pastimes is Kenpo Karate. I am, actually, a Black Belt, and in addition to working out and practicing the techniques and katas I also read about Kenpo and other styles of martial arts. I remember reading one teacher (okay, okay, sensei) who wrote a piece complaining about how some students would write him asking about the effectiveness of a certain style they had seen depicted in a television show or movie. These queries often followed a pattern of “I saw this character in this movie employ this style against other martial artists, and he really seemed to kick a$$!” The author of the piece would then remind the letter/e-mail writer that the reason the character did so well was because the people who wrote the script had him win the fight, and it really had little or nothing to do with the stated stylistic preferences of the protagonist. In retrospect, I can understand this instructor’s frustration. I mean, really, how obvious a refutation can there be? We Project Management types would never be so naïve as to fall for a similar ruse, would we?

Well, would we?

Meanwhile, Back In The Project Management World…

Eliyahu Goldratt published the novel – the novel! – Critical Chain in 1997. In this, ahem, novel the protagonist and his team realize remarkable project management success by using the “critical chain” approach, which is, essentially, the old Critical Path schedulers’ hack of crashing the schedule. Basically, the tactic involves transferring resources from non-critical activities onto critical ones in an attempt to optimize personnel output while reducing overall project duration. When it works it’s great, but there are some problems with this approach, to wit:

• If an analysis of assigning existing personnel to work more hours versus adding more people to the team has been performed, and the results indicate that more people are required, you just added costs to the project.
• On the other hand, if the analysis indicates that you can simply drive the existing team harder, it’s at least somewhat likely that they will burn out faster.
• On the third hand, if you haven’t performed this analysis, you’re making an uninformed decision with regards to personnel assignment, not the area you want making guesses to resolve.
• Finally, if the resources from the other tasks do not have the expertise to advance (or even assist) the activities on the critical path, the whole thing becomes futile from the get-go.

Naturally, none of these issues interferes with the “critical chain” technique as it’s employed in the story. It works great in the novel. It works so great, in fact, that the novel launched an entire “Critical Chain Project Management” academic trend. I feel like I’m in some kind of PM dojo, looking over hundreds of letters saying “Wow! That critical chain technique really worked out for everyone in that novel! Why isn’t it more widespread?” Guys! It worked in the novel because that’s the way the author scripted it! It’s a novel for crying out loud!
It happens elsewhere, too.

I really shouldn’t be too hard on Goldratt. B.F.Skinner published Walden Two, a novel about how an isolated society would easily out-perform others by employing the nascent theories of behaviorism, in 1946, a full twenty-five years before he published Beyond Freedom and Dignity, where he laid out the basics of behaviorism on a more academic basis. The temptation to lay out one’s theories about how things should work out in a fictional setting is fairly powerful. It’s also profoundly anti-scientific.

I didn’t write “non-scientific,” opting instead for “anti-scientific,” for a reason. In science, once a hypothesis is developed, one of the very first things the (valid) researcher does is to develop the Null Hypothesis, or the idea that, if proven true, would overturn or invalidate the original hypothesis. Only after the null hypothesis has been thoroughly disproven is the original hypothesis pursued to its logical conclusion. The fact that this level of academic and scientific rigor is completely absent from martial arts movies is readily understandable. Such movies are made to entertain, after all. Even in the various schools of psychology, one could squint really hard, and understand the allure of presenting the more philosophical notions in a fictional setting in order for them to gain traction later in an academic one.

But for the realm of management science, this fictionalization technique ought to be an automatic disqualifier. Now, with my super-sensitive ProjectManagement.com ears, I can hear GTIM nation saying “Well, what about all those stories with Stanly Raspberry? Isn’t he a fictional character weighing in on Project Management issues?” Indeed he is (it’s actually Stanly T. Raspberry), but what Stanly does is mock existing industry practices that I find mock-worthy, and have seen up-close and personal, but can’t (for various reasons) name the precise organizations engaged in them. Besides, Stanly has never advanced a novel theory about how PM ought to be done, and then have those who adopt such a theory succeed amazingly. It’s not what he’s about.

That kind of an approach resides with those who can’t establish their management science ideas through the scientific method. And neither Stanly T. Raspberry nor Kwai Chang Caine would be amused.

As a child, I hated having to eat broccoli. The only way I would ingest that foul weed was to put butter, salt, or cheese sauce on it, and even then, I had to be coerced or bribed (“No dessert unless you finish your foul weed broccoli!”) Flash forward to after I had kids of my own, and suddenly no veggie tray is complete without it. Something about attaining adulthood leads one to casually snack on broccoli the same way kids devour potato chips. As odd as that seems, it remains a reality that, with few exceptions, kids have to be forced to eat certain foods that adults find appealing and will not do so absent such force.

Meanwhile, Back In The Project Management World…

My regular readers are well aware of one of my favorite bifurcation distinctions, that of processors and performers. In the Project Management realm, the easiest acid test here is:

• Processors are devoted to process, and consider a PM effort to be successful if the project team has scrupulously followed all of the organization’s procedures and guidance on how Project Management ought to be done. They really don’t care much about how the actual project performed, though.
• Performers are the opposite: if the project came in on-time, on-budget (or even early and under-budget), these people will consider the project to be a success, and whether or not they followed official guidance is pretty much a non-factor.

With this distinction in place, what is to be said of the typical Project/Program Management Office, particularly since most PMOs are founded in the first place in order to bring some level of transformation to the macro organization in PM space? Sadly, most of these PMOs tend to be staffed by processors. How do I know? Just look at their behaviors. Do they not generate guidance documents, get these documents signed by upper management, and attempt to modify the way the project teams approach and execute their projects by the threatened implication that, by failing to obey every aspect of the dopey guidance documents, the project teams are disobeying upper management (and, therefore, should not get dessert)?

It could be worse.

And if you think this particular strategy is both invalid and highly off-putting, consider all of the organizations that crank out their own versions of how PM ought to be performed, but have nothing at all to do with your specific team or company. To engage in a massive bit of understatement, projects are different. The same team putting together, say, a petaflop-capable supercomputer will employ techniques and management strategies that are so unique to that scope that virtually any generalization about how projects ought to be managed will include at least a couple of strictures that not only fail the relevancy test, but would be profoundly backwards. But you can bet that some processor somewhere on the list of “stakeholders” that “must be engaged” will cite the extraneous requirement as proof that the supercomputer team is doing something wrong, and ought to be chastised (at least) for pursuing their scope in such a way that the processor finds insufficient.

But back to the PMO charged with transforming the macro organization. If the processors’ efforts at compelling transformation via procedures and guidance can be safely assumed to be irksomely coercive less than optimal, what would be the alternative? Put another way, if the processors have it wrong, how would the performers do it?

Performers, in my experience, are more intricately aware of the axiom that Project Managers ought to always begin with the end in mind. Okay, so, what’s the end product here? If you said “transformation of the organization,” you are stilled mired in the processors’ approach. The correct answer here is “to place into the hands of the decision makers accurate, timely, and relevant information that will maximize the odds of their completing their projects successfully.” Such information is gold to the performers, and some suspender-clad, Harry Potter-style-eyeglasses-wearing processor tut-tutting about how all PMs should be forced to ingest and act upon a comparison of the Basis of Estimate to the line items in the General Ledger are anathema to them.

Is there any cheese sauce, or maybe ranch dressing?

This being the case, the optimal approach for the PMO to bring a PM transformation to the macro organization would be for the PMO to offer a variety of Project Management information products to the diverse project teams that would need them. Based on the axiom I wrote about a few weeks ago, these products would reflect the “Quality, affordability, availability: pick any two” reality by making (1) quick-and easy PM information products affordable and readily available, (2) high-level PM information products readily available for a price, AND (3) high-level PM information products at an affordable price, if the project team can wait for them. In this way the various project teams can select the profile that best suits their particular needs, free from the kibitzing of processors, ensconced in their cubicles, turning out their opinions on how everyone else ought to be doing Project Management.

That this performers’ approach to transformational Project Management is patently superior to the typical processors’ strategy is readily revealed with one simple mental exercise. Ask yourself, as the PMO Director, do Team Leaders come to you for PM-typical performance information, or do they seek to have you tell them how they ought to be managing?

Once the project teams begin to freely engage your PMO’s services, just watch, because an actual macro organizational transformation is about to begin. They won’t accept your veggie trays unless they include broccoli…

Do you want to have your organization undergo a Project Management transformation? I mean, do you really, really want your organization transformed in PM space? Well, I have great news. I know of a series of tactics that are part of an overall strategy that will, without fail, transform your organization in this area. I have never seen it fail, and am only too happy to provide it to my readers.

Before I provide this can’t miss “solution,” I want to reference Captain Tom Schorsch of the United States Air Force, and his Capability Immaturity Model[i], as the basis for knowing at what rate the transformation is taking place. The Levels of the CIM are as follows:

0. Negligent

-1.  Obstructive

-2.  Contemptuous

-3.  Undermining

I’m sure you have noticed that, unlike the Carnegie-Melon Capability Maturity Model®, Captain Schorsch’s version “advances” in negative increments. There’s a reason for that. Keep these levels in mind as we review the strategy and accompanying tactics of this can’t miss approach.

First, name the person who is in-charge of your Project Management Office or PM Implementation effort one who is familiar with the basics of PM, and who has supreme confidence in their efficacy. This person should believe that no assertion that appears in the PMBOK Guide® can possibly be mistaken, misguided, or not to be universally applied, and each and every part of the current crop of PM literature must be observed in its totality. After all, the head of the PMO must be the face of coerced implementation. Sure, parts of the organization will bristle at, if not push back on, some of the new mandates coming from this person and the PMO, but these people must be assumed to be ignorant at best, subversive to the legitimate PM agenda at worst.

Next, staff the PMO with former accountants and administrators who have recently attained their PMP® certifications. Experienced PMPs® will have lost the enthusiasm for relentless compelled universal implementation, and might actually tend towards picking and choosing which aspects of current PM guidance would be best at achieving their ends, and which techniques should be done lightly, if at all. For guaranteed PM transformation, this will not do. It all has to be implemented, with no exceptions.

Don’t forget to document all of these demands into some sort of officially approved procedure, signed by the highest levels of management. For good measure, have every member of the PMO become familiar with the potential penalties awaiting any Project Manager found to be in violation of approved procedures, and the precise manner in which these penalties may be executed.

Now, as these early tactics are rolled out, the various project teams will attempt to opt-out of compliance with the procedures. Some of the counter-strategies involved include:

• Finding verbiage in the guidance that allows them to claim that the documents don’t apply to their particular work scope. This often involves some pretty intricate word-splitting (“We’re a program, not a project!”), so be on the lookout for this.
• Setting up a “shadow organization,” or a team of PM specialists that don’t belong to the institutional PMO. These shadow organizations, often populated by subcontractors, are beholden to the PMs that hired them, and will attempt to demonstrate a level of competency analogous to the institutional PMO. This is most easily defeated by inserting into the procedures the use of some key software package that only the PMO can grant permission for use.
• Maverick project teams will often attempt to point to their customers as requiring a different type of Project Management reporting criterion as the reason why they should be exempted from the procedures. If this assertion gains traction, the transformation I guaranteed might be thwarted for this particular team. The counter-technique here is the same as the previous bullet – designate one of the software platforms needed for Project Management (the Critical Path Methodology scheduler is ideal for this) as permission-only, as determined by the institutional PMO, and intercept the rogues as they attempt to get around this requirement.

The transformation will be underway! How can you tell? Well, those projects that had previously had a basic (or even medium) level of PM expertise will either now be struggling with the additional costs it takes to comply with the new demands procedures, or else they will be desperately trying one (or more) of the bulleted tactics listed above in order to opt out of them. Even the highly-capable projects will begin incurring additional costs, imperiling overall performance. Soon it will be clear that the previously listed counter-strategies amount to little more than rank obstructionism, the very definition of Capability Immaturity Model Level -1. As the institutional PMO moves to block these counter-strategies, it will become plain that the owners of the opposing PM techniques will become contemptuous of each other, attaining the CIM Level -2, and usually pretty quickly. From here it’s an easy step over to the opposing camps undermining each other, and the transformation is now complete.

“But Michael!” I can hear GTIM Nation exclaim, “this is not the transformation I was seeking! I wanted more advanced PM capability, not a regression!”

Yeah, well, I promised a “transformation.” I didn’t guarantee which direction it would go. Besides, the tactics I listed seem to be fairly commonplace. I didn’t invent them, I simply listed them.

[i] Wikipedia contributors. (2017, November 29). Capability Immaturity Model. In Wikipedia, The Free Encyclopedia. Retrieved 01:25, May 13, 2018, from https://en.wikipedia.org/w/index.php?title=Capability_Immaturity_Model&oldid=812639060