Game Theory in Management

Some schools of Communications Management thought hold that a significant contributor to the conflicts in personal relationships, business, foreign affairs, etc. is simple misunderstandings. When transmitting, we are told to be careful about the words we choose, monitor body language, and spend energy to understand where the intended receivers of our transmission are coming from. Similarly, when acting as receivers, we’re taught to, again, understand the motives and feelings (!) of the transmitter(s), watch their body language, and take in not just the denotative meaning, but any connotations that may be transmitted as well.  All of which reminds me of my early days in programming.

After I Tied My Horse To The Hitching Post…

When I was a junior in High School, I took a semester of computer programming. Half of it was in BASIC, the other half in FORTRAN (if those names don’t mean anything to you, I don’t want to hear about it). The mainframe computer wasn’t located on campus – we had to create a stack of punched cards that were loaded into a “hopper,” which would scan the cards, one by one, and transmit them over the land line via a modem to the mainframe’s location. Needless to say, much could (and did) go wrong with just the transmission phase (see where I’m going with this?). Even if there were no typographical errors in the punched cards, some of the cards could become dog-eared if they had been sent more than once, and this would cause a fatal interrupt of the transmission phase. Only after the entire deck – remember, there was one card per line of instruction – was successfully transmitted would your program run. If there were errors in the code itself, the real task of debugging began.

Which brings us back to the art of far-flung communications within the far-flung project team. Using the analogy of my pre-historic programming days, the so-called communications experts would have us believe that the majority of times your code didn’t execute as planned, it was because of typos in the punched cards, or a problem with the card hopper. It rarely seems to enter their lexicon that the program being transmitted has errors in it, and that’s the reason it won’t execute.

What Are We Communicating, Exactly?

One of the basic precepts of one of my favorite targets, the risk managers, is that such a thing as “upside risk,” exists, and it is the exact same thing as opportunity. The first time I encountered this bizarre notion was when I was writing the Variance Threshold column for PMNetwork magazine, and I dared to reference the commonly-held definition of the word “risk.” E-mailed complaints poured in from the risk management community. When I responded with the Webster’s, Oxford English Dictionary, and Wikipedia definitions of the word “risk,” pointing out that nowhere in those references did anything positive appear, much less the nominal antonym “opportunity,” the RM-types merely cranked up their vitriol. It turns out that they had successfully lobbied to have the term “risk” include this “upside risk/opportunity” aspect in the glossary section of the (then) version of the PMBOK Guide®, and they weren’t about to allow a mere columnist to challenge their definition.

In other words, their program didn’t work, so they sought to obfuscate this fact by blaming the card-hopper. It was my pointing out the obvious fact that, previous to their finagling, the word “risk” had nothing but negative terms associated with it, which had set them off. In fact, the methods for managing opportunity have nothing at all to do with Monte Carlo simulations, Decision-Tree analysis, or any of the other RM techniques, and no valid proposal management system is predicated on those techniques. But, in order to support the assertion that RM covers all potential occurrences to a project, both negative and positive, the risk management-types simply had to attempt to change the plain meaning of a commonly-known word in order for them to maintain their invalid concepts.

I’m Good With New Stuff – Really!

I’m well aware that it’s considered a significant step forward in project management space to take advantage of improvements in telecommunications technology that allows cross-continental project team meetings to occur easily and cheaply. I have no problem with that. What does cause me heartburn are the attempts to change the denotative meanings of commonly-known words in order to buttress dubious project management precepts and force them into a more prominent position within the PM codex. Being able to conduct teleconferences across the globe means little if the participants’ knowledge of the definitions of the words and terms being used are being incrementally altered away from their original meanings.

In short, the communications fail here isn’t that I can’t hear you. I can hear the words you are using just fine. You’re still wrong in the way you risk management-types (and others of your ilk) are using them.

Lagniappe

I'm doing a webinar this Thursday, March 16, at 1:00 EDT, sponsored by ProjectManagement.com. It's on basic Game Theory, and I'm giving away five of my overpriced books (Amazon has them for around $100). Hope to hear from my readers then!

I believe that one of the most fascinating things about history is that, while technology advances in amazing and utterly unpredictable ways, human nature tends to remain the same. Exhibit A for this assertion is the fact that, at the beginning of the 17^th Century, physicians believed that illness was caused by an imbalance of humours, a concept considered so utterly absurd by today’s medical professionals as to represent an embarrassment. It’s also a fair bet that 24^th Century physicians will look back at today’s medicine and consider it barbaric. Conversely, the author of Shakespeare’s plays (I’m an Oxfordian, myself) penned insights so profound that those works are considered masterpieces to this day, and probably will be for some time.

I think something very similar occurs in project management space. I remember back in the early 1990s using a robust Critical Path Methodology (CPM) software on the just-becoming-commonplace desktop computers. If your schedule network had more than a couple hundred activities, in order to have the software perform the forward pass, backward pass, find the critical path and compute float, you would have to give it the command to do so, and then pretty much just go to lunch, since it was going to take about an hour (particularly for the resource-loaded versions). These days, those calculations for a several thousand activity network can be accurately performed virtually instantaneously.

However, even as the robust PM software platforms become easier to use, and the traditionally easy-to-use ones become more robust, some problems remain intransigent, and these problems involve human nature. Consider the following (by no means exhaustive) list:

• Managers who fancy themselves experts at PM refusing to set up a legitimate Work Breakdown Structure (WBS).
• So-called project controls specialists putting Organizational Breakdown Structure (OBS) elements into the WBS.
• Accountants refusing to set up the project’s chart of accountants so as to collect actual costs based on the WBS.
• Executives refusing to employ Earned Value or Critical Path methodologies, even on their larger projects.
• Accountants (again) claiming to be able to perform cost performance without Earned Value, based only on the information available from the general ledger.
• Administrators claiming to be able to perform schedule performance analysis based on a list of milestones, and polling those responsible to see if they believe those milestones will be completed on-time.

Don’t think for a nanosecond that these human nature-based difficulties in attaining peak PM performance are confined to the uninitiated. The so-called experts, who present as if they are on our side, can be even worse, to wit:

• The insistence that all work – even scope that should not be managed as a project – be managed as a project.
• The imposition of absurdly brief time spans as the maximum duration an activity (or even Work Package) can be planned, or scheduled.
• Requirements for a risk register, risk management plan, Decision Tree or Monte Carlo analysis, etc.
• Imposing – as audit standards, no less – analysis techniques that involve comparing the time-phased budget to their direct counterparts in the actual costs from the General Ledger. This problem, of comparing budgets to actuals and claiming the result to be some form of cost performance analysis, is as old as it is pervasive – even among the so-called experts.
• Demands to “engage stakeholders,” even if these stakeholders are potentially hostile to your project’s outcome.
• Imposition of unrealistic quality control standards.
• Insistence on an extreme level of detail or granularity in project status reporting.

The real irony here is that the latter group – the so-called “experts” – are easily as damaging to the widespread acceptance of project management as a school of thought as are those who oppose it from ignorance, or intransigence. Both groups resist “doing” PM, the former because they don’t understand it, the latter because it’s not being done to their unscientific standards. The uninitiated maintain that even very basic project management information systems are too onerous, while the “experts” will assert that even advanced, capable systems aren’t onerous enough. The net impact is the same and, in my opinion, probably universal: project management, as a discipline, is frustrated in its attempts to gain more widespread acceptance.

And this frustration isn’t technological. It’s rooted in human nature, and will therefore probably remain the same. Hey! I wonder if some 24^th Century project manager uncovers this blog, and shows it to his friends, will they will laugh at how backward it is, or say something like “things really don’t change that much, do they?”

I was once assigned to provide project controls support to a fellow who thought of himself as highly advanced in project management. At our first meeting, after introductions, he told me he wanted a “swim lane chart.”

“A what?” I asked.

He proceeded to draw on the whiteboard a series of parallel, horizontal lines, and filled them with boxes representing activities, with arrows in-between them to indicate schedule logic. The areas in-between the horizontal lines were labelled with the names of some of the organizations participating in the project.

“Oh, okay, I get it.” I began. “It’s essentially a PERT chart, sorted by organization.”

“It’s a swim lane chart” he replied, emphatically, as if to contradict what I had just said. Rather than dither with a customer about the different label he wanted to give a common schedule format, I simply asked him about the Work Breakdown Structure.

“I don’t want a Work Breakdown Structure, I want a swim lane chart!” he insisted.

“I understand what you want, and I know how to produce one, but first I’m going to need a WBS in order to construct the schedule network we need to generate the ‘swim lane chart.’”

“Look,” he sighed, as if he were trying to communicate an extremely simple concept to a dull child, “I don’t want any of that other project controls stuff. All I really need to manage this work is a swim lane chart, regularly updated.”

At that point it became clear that this guy was deficient in his PM capabilities while fancying himself a genius, and that he held anyone who didn’t agree with him to be an ignoramus. In short, this fellow was (and probably still is) simply wrong.

And, being younger, I didn’t suffer this sort of wrong-headedness very well.

“Actually, in order to get you your ‘swim lane chart,’ we have to start with a couple of basics, and that includes a WBS. Let’s get started on that, and we’ll be one step closer to printing out the ‘swim lane chart.’”

After promising to get me the initial scope documents I would need to create the draft WBS, I left this fellow’s office and returned to mine, where my supervisor informed me that the PM had called and asked to have me removed from the project.  Which was okay, since, as I said, I didn’t (and still don’t) suffer this type of wrong-headedness very well. My replacement did a much better job, but I’m not entirely sure how she pulled it off. My guess is that she created a straw-man PERT chart, sorted by organization code, and then had the genius PM modify the activities, one by one, until they could be arranged into a rudimentary WBS – essentially, backing in to the Work Breakdown Structure (it would have been funny to see how they retroactively arranged the scope documentation, if that is the approach they took).

Fast forward to present-day, and I’m a blogger on a preeminent PM website, where the currency of the realm is ideas. What are these ideas? They represent theories, concepts, and techniques that help project managers do their jobs better. As with any body of knowledge (get it?), there are some good ideas, and some not so good. I’m sure it will not surprise any of my regular readers to learn that I believe that some of ProjectManagement.com’s competitors are pushing notions not derived through the scientific method – i.e., invalid – into the marketplace of PM ideas.

And, again, I don’t suffer this sort of wrong-headedness well.

A notable example of the notions I’m referring to is the idea that Estimates at Completion (EACs) ought to be time-phased. This is so wrong I’m having a hard time figuring out where to begin. An Estimate at Completion is just that – an estimate. It’s saying that, if the project continues on its current performance pace, it will cost X number of dollars. It is neither a request for more budget (when over the Budget at Completion), nor an offer to repatriate existing funds (if it’s under). It’s a performance indicator, nothing else.

But some other organizations maintain that this figure must be time-phased. What does that mean, exactly? It means that, if this notion is followed to its logical conclusion, they are mandating the creation of a rubber baseline. The existing cost baseline is the original time-phased estimate of the costs of the project. By stipulating the creation of multiple time-phased estimates, the original loses its relevance, and becomes, in the common parlance, “rubber.” It’s nearing uselessness because it’s being superseded by “more recent” information. But the altering of the cost baseline is a formal process. To do so otherwise is to set up the textbook definition of a rubber baseline. And those are not good. They are, indeed, often ruinous to projects that employ them.

So, I’m going to take my usual approach, and ridicule the notion. Those who embrace the idea that EACs need to be time-phased will consider me dumb, but that’s okay.

Because I think they’re simply wrong.

At the beginning of this month, with ProjectManagement.com’s theme of customer relations management, I discussed the contribution of Tom Peters and Robert Waterman, authors of In Search of Excellence, who directly challenged a management environment that had gotten away from working hard to fulfill customer expectations, or even attempting to find out what those expectations were. So, it’s only fair to use that standard when attempting to answer the question of what my readers – or any consumers of columns, articles, and blogs – want from the various project management societies and organizations. I think that answer is that practicing PMs are seeking insights and techniques, usage of which will increase the odds of managing our projects so that they come in on-time, on-budget.

On The Other Side…

However, as my regular readers are aware, I have previously written about what I consider to be two different types of project manager, whom I referred to as “processors” and “performers.” A quick synopsis: processors are more concerned that the processes of formal, rigorous project management are followed exactly than they are that the actual projects finish on-time, on-budget. Performers are the opposite. Sooooo, what happens when these two worlds collide? What happens when a processor begins sharing “insights” about how they think project management should be performed?

The results can be disastrous. I’m reminded of Michael Crichton’s excellent lecture, “Aliens Cause Global Warming,” where he discusses the reasons why the Drake Equation is invalid. For those of you who aren’t in to the Search for Extra Terrestrial Intelligence (SETI), the Drake Equation looks like this:

N = R* fp *ne *fl * fi * fc * L

where

• (i) the average rate of star formation, R*, in our galaxy,
• (ii) the fraction of formed stars, f_p, that have planets,
• (iii) the average number of planets per star, n_e, that can potentially support life,
• (iv) the fraction of those planets, f_l, that actually develop life,
• (v) the fraction of planets bearing life on which intelligent, civilized life, f_i, has developed,
• (vi) the fraction of these civilizations that have developed communications, f_c, i.e., technologies that release detectable signs into space, and
• (vii) the length of time, L, over which such civilizations release detectable signalsN = R ∗ ⋅ f p ⋅ n e ⋅ f ℓ ⋅ f i ⋅ f c ⋅ L {\displaystyle N=R^{\ast }\cdot f_{p}\cdot n_{e}\cdot f_{\ell }\cdot f_{i}\cdot f_{c}\cdot L} .[i]

The problem with this equation, which Dr. Crichton so brilliantly pointed out, is that none of the parameters can be known with any certainty whatsoever. All the Drake Equation does is to provide a facade of scientific methodology to what is, essentially, a guess.

Meanwhile, Back In PM Space…

I was struck by how similar the Drake Equation is to the formula for performing a single-tiered decision tree analysis (a common risk management technique) on project work. That formula looks like this:

C = ∑ (S1(p*i)) + (S2(p*i) + S3(p*i) + Sn(p*i))

Where C is the amount of contingency needed for the total of alternate scenario 1 (S1)’s odds of occurrence (p) times its impact (i), plus the same calculation for scenario 2, all the way through scenario n. As with the Drake Equation, none of these parameters can be estimated with any certainty. It’s just an accumulation of guesses, tripped out in pseudo-management science garb. As Dr. Crichton said of SETI, risk management is not a legitimate line of management science inquiry. It is, without a doubt, a matter of faith, a set of beliefs unsupported by observable and repeatable experiments.

Which brings me back to ProjectManagement.com’s February theme, of customer relations management. Do our readers really want to be preached to about ways some processors think they should be “doing” PM, even if their assertions are, precisely speaking, invalid from a PM science point of view?

My answer: ummm, probably not.

[i] Drake equation. (2017, February 12). In Wikipedia, The Free Encyclopedia. Retrieved 01:42, February 22, 2017, from https://en.wikipedia.org/w/index.php?title=Drake_equation&oldid=764988356

I think one of the funniest things about the automatically difficult role consultants in general and PM consultants in particular assume is the inherent double-bind nature of their jobs. It’s a double-bind thing rather than a single-step contradiction (e.g., a “Catch-22”) due to the multiple-step nature of the (eventual) contradiction, so:

• Consultants aren’t needed unless the host organization realizes it is experiencing problems its own personnel are not able to handle.
• Unless the consultants are okay with having their roles evolve to long-term subcontractors, they must be able to identify the inadequacies within the host organization, and then implement steps to advance the capability that is currently lacking.
• If the problem or issue lies within the team or group that brought the consultants in in the first place, the consultants are in the unenviable position of having to criticize the very personnel who will be deciding whether or not to keep them around.
• If the problem or issue lies outside the team or group that brought them in, then the odds of their recommendations being adapted by an organization that (a) didn’t bring them in in the first place, and (b) probably rejects said conclusions, are low indeed.

Of course, many consultants bring extremely valuable experiences and techniques to organizations that need them to get over a (hopefully) temporary difficulty or issue, which is one of the reasons why there are so many of them. Given that the population of PM consultants is relatively high, how does one discern between those who are the genuine article, and those who are not as competent as they pretend to be? Well, you bait them.

Can You Be More Specific?

Okay, so how does one bait a PM contractor, exactly? Well, it helps to know a few of the characteristics of each type. Typically, the real deal will have at least a few of the following:

• Personnel with the PMP®, or other relevant certifications,
• Published articles in the Project Management Journal, PMNetwork, here (ProjectManagement.com), or other (again, relevant) go-to places for project management insight,
• Technical papers presented at one of PMI’s Congresses, or other PM-related venues, or
• An objective track record of resolving issues quickly and permanently, for clients who are available to give rave reviews.

On the other hand, the consultants that you just might want to avoid tend to have some of the following:

• Only government clients (for the United States government, employees are usually enjoined from providing any publicly-available negative feedback about a contractor, no matter how shoddy their work is),
• Few or no certifications or publications,
• If they have presented a paper at a conference, it tends to be the same old blather about the basics of Earned Value or Critical Path methodologies, or why it’s a good idea to do them, or (my least favorite) how they were on a project where they did project management “right,” and everyone else in the universe needs to copy what they did, right down to hiring the same personnel (them).

What If I Still Can’t Tell?

If none of these tells are available, then the next level of discernment involves the actual baiting. After the consultant has been on-site for an adequate period of time, and is ready to provide their findings and recommendations, ask the following questions:

• If the problem identified has been known to the project team for some time, ask if they got their problem ID/recommendations from one of them.
• If they answer in the affirmative, ask why they didn’t disclose that fact;
• If they answer in the negative, ask why they didn’t bother to interview the project team.

There really is no correct answer to this line of inquiry, and you’re not looking for one. What we’re trying to discern here is the true differentiation among great and not-so-great consultants. The former will improve the people around them, even those considered by the host organization to be the lowliest; poor consultants will keep alive the shortfalls and inadequacies of the host organization, to better make the case that they need to be kept around. Assuming the position of outsider-looking-in and constantly criticizing elements of the host organization is a sure sign of a poor consultant. Great consultants will tend to take the responsibility for the lingering issues in the short term order to give more time to their host organization-trained staff to get things right in the long run. The only remaining question is: if you become aware that your consultants are less than great, what do you do about it?

Lagniappe

In addition to the webinar I’m doing with ProjectManagement.com on March 16, I’m also presenting at the PMI® Rio Grande Chapter meeting on April 20, at the Sandia Hotel & Casino in Albuquerque (where I will do my level best to avoid mocking risk analysts). The first person who approaches me after the presentation and says “I read your ProjectManagement.com blogs all the time, and I think you’re too hard on accountants” will receive a copy of my third book for free (it’s listed on Amazon for $116).