Game Theory in Management

It’s easy to laugh at nineteenth century pharmaceutical promoters, also known as snake oil salesmen, who would go to elaborate lengths to convince potential customers of the efficacy of whatever compound or solution they were selling in healing various and sundry ailments. How silly of them to misrepresent their wares so! And how naïve the people who actually spent hard-earned cash to acquire such dubious products! Certainly, people today would never be prone to fall for such tomfoolery, no siree! 

Let’s flash forward to the 21st Century, and the realm of project management which encompasses a plethora of management science hypotheses and theories, many of which are recognized as generally-accepted ways of doing business, with little (or no) empirical evidence to support their validity. Yes, yes, I know that in the business world, it’s virtually impossible to isolate the variables needed to support or overturn any given management science theory. And you know who else knows this? The project management science equivalent of the snake oil salesmen.

I (metaphorically) beat up on the accountants a lot, but that might not be fair – not because their ideas are valid beyond the asset management realm, but because they are not technically part of the PM universe. I also pick on the risk managers a lot, but they’re such easy targets that that might also be considered unfair (is there an equivalent of the “mercy rule” from High School Football for the universe of bloggers? Once an opponent is clearly subdued, are we business writers supposed to ease up on them?).

All of which brings me to the quality guys. I mean, seriously, who could possibly be against quality, as a concept?  Surely these naysayers must be confined to those short-sighted, careless and cheap people who are just out to make the proverbial “quick buck” (a “buck” is one United States Dollar, and not a male deer, for my overseas readers) and hasten out of town before their consumers realize they’ve been had, right?

Well, let’s all take a deep breath, and look at this. What are the quality guys actually selling us? Much of modern-day quality management centers on the performance of specific analysis techniques to help determine the causal factors of the perceived quality issue. This analysis often entails changing the attitudes of the people who actually create the products or services made available to the consumer, and performing an assessment of which processes or personnel are most responsible for any delta between desired scope delivery, and what is actually being delivered.

Okay, so now we’ve left the production room floor, and entered into business analysis territory. How is business analysis performed? With information, of course. What information? Well, one popular technique used by the quality guys is the Ishikawa Diagram, also known as the fishbone diagram. It’s a line intersected by slanted lines above and below it, and on these lines are listed the causal factors that lead to a given perceived problem. In the example listed on Wikipedia 1 , the categories of these causal factors are:
•    Equipment
•    Process 
•    People
•    Materials
•    Environment
•    Management
Most Ishikawa Diagrams will have at least one intersecting line devoted to each category. As I have noted in previous blogs, at the time the Titanic sank, the lookouts had no binoculars, because they were locked in Second Officer David Blair’s locker, and Blair wasn’t on board for the voyage, having disembarked at Southampton without telling anybody where they were 2 . So, this one causal factor falls into which Ishikawa Diagram category, exactly?
•    Equipment, since we’re talking about binoculars.
•    Process, since there should have been a process that required Blair to at least communicate the location of the binoculars.
•    People, since Blair wasn’t aboard.
•    Materials, since the binoculars were locked away behind a panel of wood, which could have (presumably) been demolished by one of the many metal axes on board.
•    Environment, because, of course, the Titanic hit an iceberg.
•    Management, because, well, all of the above.
Could it be, then, that a key commonly-used quality management technique has, in fact, invoked categories of causality that are so blurry that something as simple and straight-forward as some binoculars being locked away can’t fit specifically into one of those categories? And if the categories are thus blurred, doesn’t that at least imply that, in some circumstances, little or no usable information can be gleaned from them on a consistent basis? 

And, to ask just one more uncomfortable rhetorical question, could it be that a few of those organizations that claimed to be suddenly cured after having engaged quality techniques were either not really cured, or were misattributing the cause (ironically) of their improvement?

  1 Retrieved from https://en.wikipedia.org/wiki/Ishikawa_diagram#/media/File:Ishikawa_Fishbone_Diagram.svg on September 19, 2015, 20:25 MDT.
  2 Retrieved from http://nmni.com/titanic/Myth-Memory/Myth/No-binoculars-for-the-lookouts-on-Titanic.aspx on September 19, 2015, 20:21 MDT.
 

I think one of the cleverest ruses used by law enforcement to round up people who have outstanding arrest warrants without having to spend the resources to track them down involves sending those people notices that they have won some sort of contest or prize (my personal favorite claimed they had won Super Bowl tickets), and to show up at a certain place and time to claim their reward. Once these people arrived and presented proof of who they were, they would simply be taken into custody to face the charges against them. Yeah, I know it ruined their days, but I simply had to laugh, for two reasons:
•    They were criminals getting their comeuppance as a result of their stupidity,
•    …and it is actually pretty funny.
What does this have to do with project management? Well, the past few weeks I’ve been on a tear about Effectives versus Processors, about how the Effectives, while undoubtedly the superior PMs, were nevertheless thwarted in the organization by their Processor counterparts, who always seemed to be the ones making the rules that the Effectives had to follow. Based on the example of the fake-winnings ruse, I had another idea on how to deal with the Processors.
First, we need to concentrate them in one place. No, not to take them away to jail, but to be able to clearly identify them for future interactions. So, what attracts Processors? Well, as we have been discussing, they love to write procedures that, once signed by upper management, they expect everyone else has to obey. These procedures are invariably based entirely on the Processor’s opinions or experiences, and no attempt to weed out instances of misunderstanding or confirmation bias is ever made. Indeed, no novel scholarship nor research ever enters in – these “rules” are subjective, arbitrary and capricious. For proof, I will point to the efforts of some risk managers to form Special Interest Groups within established professional societies, obtain permission to write that society’s rules on risk management, and then go about trying to re-define words away from their centuries-old, widely-known meanings. 
The funniest example I know of has to do with a certain risk SIG that wanted the word “risk” itself re-defined. According to Merriam-Websters’ On-Line Dictionary, it means:
(1)    the possibility that something bad or unpleasant (such as an injury or a loss) will happen
(2)    someone or something that may cause something bad or unpleasant to happen. 1
This particular risk SIG managed to get a professional society to change its definition in its glossary of terms to include any event, positive or negative, that impacts the performance of a project. Nevermind that the word “risk” never previously pertained to potential positive events (known everywhere else as “opportunity”)  – in their attempt to advance their kooky ideas, they simply had to hijack the language, lest intelligent managers realize that all they were talking about was institutional worrying, tripped out in statistical jargon.
Probably the next funniest attempt at a Processor trying to take over the PM world based on a dopey procedural notion happened when I was a contributing author to a practice standard being drafted by a PM professional society. One fellow actually addressed the document prep team, and strongly asserted that the only authors whose input should be included in the final document were those who had traveled internationally. I swear I am not making this up. If you are thinking that the link between having one’s passport stamped repeatedly and advanced expertise in certain aspects of project management is less than intuitive, go to the head of the class. 
So, what’s the solution? I think ProjectManagement.com should issue a call for contributors for the creation of a document that will be the ultimate guide to “doing” project management, one that is so authoritative that, once published, everyone will be forced to comply with its particulars, or be labelled as anti-PM forever. The call should include specifications such as the contributors need not have any peer-reviewed writings or journal entries, and that they will be at liberty to change the meaning of common words to suit their assertions. In fact, the only criterion for authors is that they view themselves as so advanced in project management expertise, that their opinions should be accepted without question. This will work on Processors like catnip.
Then, ProjectManagement.com could simply sell the list of volunteers to organizations headed by Effectives, who would then know whom to keep off of their project teams; alternately, they could accept money from the Processors (who couldn’t resist the bait) to have their names removed from the list, but that might be seen as blackmail. 
A similar kind of blackmail that Effectives are subject to whenever a Processor releases another insipid procedure…

 
  1 Merriam-Webster online dictionary, http://www.merriam-webster.com/dictionary/risk, retrieved 19:44 MDT on September 12, 2015.

A regularly recurring premise in this blog has to do with my adaptation of the Pareto Principal, that the top talented 80% of managers who have access to only 20% of the information needed to obviate a given decision will be out-performed by the least talented 20% of managers who have access to 80% of the information they need. Add to this the fact that you can put fifty project managers in a room and they will not agree on the color of an orange, and the task of “managing” PM talent quickly approaches an insurmountable attempt to bring order out of chaos.

So, how to recognize the top management talent, since actual performance involves far more parameters than can possibly be captured, let alone quantified and compared? It’s been my experience that the truly talented among the PM ranks will throw off clues that their lesser acolytes won’t, and I’ve developed this little guide to help my readers more readily differentiate between the two.

Notice that I am not engaging in the sort of eat-your-peas hectoring that so many other PM writers use. If you’re a schmoe, you’re a schmoe, and there’s really very little point in trying to egg such a one on towards acting better. 

However, there’s still my application of the Pareto Principle! If you’re a schmoe, you can perform like a pro if you can only get your hands on the cost and schedule performance information you need to obviate the decisions before you! Ah, but there’s the rub – unless  your organization’s internal project management procedures say stuff like “cut all of the procedural corners you need to get a basic Earned Value or Critical Path information stream into the hands of the decision-makers,” you schmoes have been hoisted on your own petard. No Processor in the universe would write such a sentence in an internal procedure.

The best bet for the lowest 20% of talent? Get contentious about the “proper” utilization of published PM principals – it seems that’s where all the low-talent PMs I’ve encountered go.
 

In a previous post I described the two basic types of project management practitioners, whom I categorized as “Processors” and “Effectives.” A quick re-hash: Processors believe a project has been properly managed when the project team has demonstrably complied with all of the PM-oriented procedures, with the project’s actual outcome being a secondary consideration, if at all. Effectives, conversely, believe a project has been properly managed if it meets all of its scope requirements, on-time, on-budget (or even early and under budget), with strict observance of proper procedure being a secondary consideration, if at all.

Normally the Effectives (the category in which I count myself) could simply sit back and let the unblinking, unfeeling free marketplace weed out the PM practitioners who either leaned towards the Processor category, or were completely immersed in it, as their organizations’ projects failed at a prodigious rate (but, hey! They were in compliance!), leaving the Effectives as the only ones claiming to be PMs who were actually drawing a paycheck. I actually had hoped that this sort-of Darwinian-style weeding out of the Processors would take on an aspect of the slowest-runner-in-a-Jurassic Park – movie; alas, it was not to be.

The primary reason the Processors remain entrenched in the PM-brand epistemological arena is because they dominate the procedure-writing departments (naturally), and these procedures are becoming positively ubiquitous. There are lots of organizations pumping out documents that pretend to have some sort of insight that compels PM practitioners to do things the way their authors want, or else … well, or else you people are simply not “doing” PM right.

Now, for those of you who want to point out that my blog’s publisher, the Project Management Institute®, engages in this very action and has done so for some time, I have two things to say:
•    We were here first!
•    Besides, the Institute has become so large that the competition to be on the teams that write anything on the topic of project management has become so intense that it’s a near impossibility for anyone but genuine experts to even get close to those projects.
Which leaves the opinionated others to make their marks with the other management science societies, organizations, and associations, and make their marks they do.

I won’t take on the risk guys again – frankly, as a target they’ve become far too easy. But consider this quote from one association’s guide to implement an Earned Value Management System consistent with the ANSI Standard (748):

"The program established cost charging structure will help to ensure that actual costs are collected so that direct comparison with associated budgets can be made at the appropriate WBS level(s)." 1

For those of you who don’t have time to read the ANSI Standard on Earned Value, I can tell you that it does not include any discussion about making a “direct comparison” of budgets to actual costs. None. A Cost Variance is defined as making a “direct comparison” of the earned value to actual costs. A Schedule Variance is defined as making a “direct comparison” of the earned value to the budget. A “direct comparison” of actual costs to budgets yields no useful information in Earned Value space. And yet, this quote is from a guide that’s supposed to be consistent with the Standard.

Look, if these Processors want to crank out procedures, instructions, and guides that tell everyone else how they are supposed to be “doing” project management properly, I say they should knock themselves out, and write anything and everything that makes them happy. But to the extent that management science maintains some claim to actually being scientific, then its assertions ought to be connected to observable results in the business world. 

Think of it this way: if you were to have a sudden and acute need to know the best way of evading meat-eating dinosaurs, would you rather hear from a track-and-field coach, or someone who had actually spent a lot of time on Isla Nublar, successfully evading said dinosaurs?

1  National Defense Industrial Association, “Earned Value Management Systems EIA-748-C Intent Guide,” April 29, 2014.

My oldest son graduated from a prestigious law school and works as a trial attorney. During a recent visit home he and his fiancé disagreed about the hair color of the opposing council at a trial she had seen. After hearing them go back and forth a couple of times, I interjected.
“Objection! Evidence not corroborated by the witness!”
“That’s gibberish” my son replied.
“Not according to the law shows I’ve seen.” 
“How would you like it if I were to just place near-random project management terms together as some sort of assertion?”
“Sadly, it would be nearly indistinguishable from much of what passes for legitimate PM writing” was my reply. And, in an instant, I knew what I wanted to blog about this week.

Valid theories in science – even management science – do not need catchy but inchoate phrases to gain acceptance. Light travels at 186,000 miles per second. This hypothesis turned theory when it was supported by experimental evidence. But consider some of the things we, as PM practitioners, accept as axiomatic, but haven’t been supported by anything but the most subjective and anecdotal of evidence.

For example, a comment on one of my blogs was “Quality needs to be buil(t) in, not controlled and managed in.” The commentrr, I’m sure, didn’t come up with this on his own – it had surely been repeated multiple times in classrooms, professional society chapter meetings, or in his workplace. But I don’t even know what that means. When creating products or providing services, if you have a good design/technical approach, use the appropriate tools, materials, and methodologies, and employ people with the appropriate level of expertise, barring human error a quality product or service will be delivered. The distinction between building, controlling, or managing “in” is fairly amorphous, rendering the distinction functionally irrelevant. And yet we, as a PM community, are somehow expected to accept this saying uncritically. I think the true nature of the assertion that “quality needs to be built in, not controlled and managed in” could be articulated as “hire more quality engineers, and pay them better, or else you will be made to look stupid for not knowing the difference between ‘built-in,’ ‘controlled-in,’ and ‘managed-in.’” (Actually, it might be kind of fun to isolate a dozen or so Quality Engineers, and have them define “built-in,” “controlled-in,” and “managed-in” in sufficient detail as to be able to differentiate any quality initiative as belonging to just one category, and then compare their answers.)

Another commonly-accepted idea is that all project managers must “engage stakeholders.” I think this term was created to be deliberately vague, in order to push the poorly-articulated theories of the communications experts (how ironic is that?). Take the first part of the term, the word “engage.” According to dictionary.com, this term can have polar opposite meanings, ranging from “to attract or please” (#4) to “enter into conflict with” (#7)i.   

The definition of “stakeholder” isn’t much more precise. According to BusinessDictionary.com, the definition is “A person, group or organization that has interest or concern in an organization.”ii  By this definition, the Washington Redskins are stakeholders of the Dallas Cowboys (which pretty much necessitates “engage” definition #7 to be used).

So, just to be clear, a term that can have as wildly differing meanings as “attract or please your employees” to “enter into conflict with your enemies” has no practical meaning at all on its face. And  yet, to “engage stakeholders” has become so uncritically accepted in modern PM circles that to even challenge it is to risk being permanently identified as hopelessly backwards in the management sciences. Does that seem right?

Now, excuse me as I prepare to “control-in” my “engagement” of the “stakeholders” who leave comments in the comment section…

  i Definition of “Engage,” retrieved from Dictionary.com, http://dictionary.reference.com/browse/engage, August 23, 2015, 11:38 MDT.
 ii  Definition of “Stakeholder,” retrieved from BusinessDictionary.com, http://www.businessdictionary.com/definition/stakeholder.html, August 23, 2015, 11:43 MDT.