Game Theory in Management

Next to the overuse of the word “like,” the most irksome trend in modern English usage has to be, in my opinion, the phrase “the proof is in the pudding.” It may be a case of confirmation bias on my part, but this idiotic phrase appears to be everywhere. The original version, which dates back at least to 1605, has the virtue of actually making sense: the proof of the pudding is in the eating, meaning that the cooks can argue about the proper way of making a pudding all they want – the true test will come when the dish is actually consumed.

So, how did the highly irksome version of this saying come into existence? I could find no authoritative analysis, though the consensus appears to be that the original was shortened to “the proof of the pudding,” which was then mis-heard or mis-applied into its grating iteration. I mean, seriously, would those who use this phrase simply stop and think about it for just a moment? When I took a college-level course in logic, the only “proofs” the professor was interested in was the depiction of the premises and conclusions of an argument in a Venn Diagram. Okay, so if the “proof is in the pudding,” did somebody put a Venn Diagram into the pudding prior to its being set? And, if so, wouldn’t it be hard to read afterwards? In my book, the use of the idiotic version of this phrase automatically renders whatever the writer has to say highly suspect, if not entirely worthless.

Virtue Signaling? No, this is Stupid-Signaling

Think I’m ranting (again)? Consider the real-life example I’ll pull from when I was instructing new, usually young Project Controllers in the art and science of cost and schedule performance systems. Just prior to the module on preparing the Variance Analysis Report (VAR), I would stop the presentation and walk over to the classroom’s white board, and write the word “his.” I would then call on one of the students, and ask them to read what I had written. After receiving the answer, I would ask, “Is this misspelled?”

“No.”

I would then write the word “hers,” and call on another student with the same two questions. I would continue in this vein with “ours” and “theirs,” each time receiving the same answer to the question “Is this misspelled?”

I would then write “Its,” and the classroom would usually laugh a little, realizing where I was going with this.

“You laugh,” I would respond, “but I will guarantee that, if I were to perform a quality check on everybody’s VARs one year from now, I will find at least one instance of ‘it’s’ being used instead of the real impersonal possessive pronoun. For the record, ‘it’s’ is a contraction of ‘it is,’ which is something most people are supposed to learn by fifth grade, at the latest. It may seem trivial, but I will also guarantee that, if your customer sees this error in your VARs, they won’t be impressed with your analytical or reporting ability. In fact, they’re likely to think whatever you have written to be highly suspect, so, please don’t make this error.”

Back in the Project Management world…

…we have to deal with quite a few very basic errors in assumptions about management science that are similarly entrenched in the common business consciousness, but just as infuriatingly wrong, and irksomely so. Take the very basic definition of the term “cost variance.” According to many websites (I’ll pick on Study.com[i]), a cost variance is “the differences between the planned budget and what was actually spent.”

Ummm, no, it’s not (see how easy it is to use to “it’s” correctly?).

A Cost Variance, as any certified PM readily knows, is the difference between the Earned Value and the Actual Costs. A Schedule Variance is the difference between the Earned Value and the budget, or “planned budget.” In reality, comparing the budget to the actuals, as commonplace an “analysis” as that is, is virtually worthless. Consider the following payoff grid:

In half of the possible outcomes, comparing budgets to actual costs returns the right answer, but only coincidentally so. However, in the other half of the instances where such a comparison returns bad information, one of those outcomes would lead you to a false sense of security, or project well-being, when the opposite perception is called for. And even if you don’t become lax with your decision-making, real problems are going unaddressed, which usually leads to them becoming large (or even fatal) ones. You’re almost literally better off flipping a coin, and making decisions based on that outcome.

And that, perhaps, is the greatest benefit of a certification. It transmits to potential employers and customers that its holder knows the valid versions of common management analysis techniques, and will eschew the more popular, but irksome versions.

And knows how to spell the impersonal possessive pronoun.

And never says “the proof is in …”, well, you know.

[i] Retrieved from http://study.com/academy/lesson/cost-variance-definition-formula-analysis.html on 16 July 2017, at 11:29 MDT.

I’ve worked with an organization that had the habit of acting like the next manager being brought in was some kind of Tom Wolfe-esque microeconomic rock star, whose name should have been instantly recognizable to the hoi polloi. After building up this person relentlessly, this person would finally arrive to take up their new position, and…

Well, nothing.

Nothing spectacular, no new ways of approaching the problems the project team faced, no novel implementation strategies to known workable tactics, nothing. They wouldn’t even bother figuring out how the current systems operated. Oh, they would crank up the energy level for a time, and get into meetings where they would strongly emphasize trite and clichéd axioms. But as far as actually advancing a capability, they were able to deliver only a whole bunch of nothing.

Not. A. Thing.

And Then, After Fleeing to Mexico…

Eventually these “superstar” managers would be re-assigned, and another one breathlessly announced, and the cycle would begin again.

After witnessing this cycle repeat a few times, I began to notice something that all these new managers had in common: none of them were certified.

A few weeks back I blogged about the difficulties inherent in working for organizations where loyalty, not talent, was considered the key attribute for the staff to demonstrate. The pathologies inherent in such an organizational approach are legion, but one of the key indicators that an organization is so situated is that they do not place a premium on professional certifications. In those cases where an apathy is associated with the attainment or holding of a relevant professional certification, and it is combined with a laxness about educational requirements, then the odds that the organization is even remotely based on a meritocracy are low, indeed.

Which kind of puts the whole certification impetus upside-down. I mean, when I was pursuing my certs, it was in an effort to signal to current and future employers that my level of expertise was more advanced than my non-certified competitors and colleagues. And almost exclusively that’s how the attaining-your-certification industry advertises its worth, by promising to make the successful cert candidate, well, more successful in the long run. But what I have observed is that it’s the winning organizations that will attract certified project managers, project controllers, and cost estimators in a way that their more poorly-functioning competitors do not.

Who’s being tested here, anyway?

To be precise, I am not saying that those organizations that make it a point to send their employees to certification training and reimburse them for their certifications are going to automatically begin to out-perform their competitors. What I am saying is that a fairly reliable sign that an organization is at least somewhat merit-based in its hiring and promotion practices will tend to attract more highly educated and certified employees, and that those dysfunctional organizations, where loyalty is the coin of the advancement realm, well, won’t. Indeed, one of the best ways to prevent a given hiring manager from filling a key position (or any position, really) with an underqualified – or even inept – candidate, who just happens to be an old friend, is to strictly enforce standards for even being interviewed for the position. In the project management world, educational requirements (past the attainment of a Bachelor’s or Master’s Degree) can be tricky – they don’t call PM “the accidental profession” for nothin’. Successful PMs come from extremely varied areas, including computer science, engineering, the hard sciences, or even business, among others. But a PMI® certification – that’s something different. That communicates that, regardless of background, its holder knows a thing or two about managing projects. Because of this, an unintended consequence of including it as a prerequisite is that it can function as a brake on cronyism, at least in its most blatant manifestations.

So, all this time, when you saw a requirement for a PMP® just to apply for a project management job, you thought they were testing you. In reality, the whole time they were advertising their own suitability as an organization worthy of your talents.

I was once in an independent cost evaluation (ICE) meeting when one of the customer representatives, a young woman who presented with quite the attitude, challenged the project controls coordinator about an element in one of the Earned Value reports.

“Why doesn’t the cumulative Earned Value amount equal the actual costs?” she demanded.

“Because that’s not what Earned Value is” came the response.

The rep exploded. “Do you know PMI®?!” she stormed. “I’m a PMP®!”

As if that was supposed to trump the rules of basic cost performance management.

Which simply goes to show one of the dangers inherent in certification, the ProjectManagement.com theme for July. Although obtaining a certification such as the PMP® can be quite the challenge, what with the assembling and presenting of education and professional credentials, as well as passing the test, it’s not an end-point. It’s really more like the starting line which, like an oval race track, has the starting and finishing lines at the same place.

Don’t believe me? Consider that medical doctors were first being certified in the United States in the early nineteenth century. At that time it was considered perfectly acceptable for certified doctors to do the following:

• Prescribe narcotics for very young children as a “remedy” for their acting like, well, very young children.
• Cut off part of the tongue for stutterers.[i]
• Inject paraffin wax in order to smooth out wrinkles[ii] (will future M.D.s view our use of Botox with similar abhorrence?).
• Bloodletting was considered a viable treatment for a wide variety of ailments.

I could go on, but not without getting kind of gross, but you see the point. Certification, in and of itself, is no guarantor of advanced capability or expertise. It only means that the certified person is up-to-speed on what the current state of the technology happens to be at that time.

So, in the next century, which project management practices will lead those with PMP® numbers in the tens of millions to look back and wonder “what were they thinking?” Well, what do the now-considered absurd medical practices have in common? They weren’t based on the scientific method (with the exception of giving narcotics to young children. I have no doubt they worked as intended, based on measurable and observable data. They just didn’t properly consider the long-term or side effects). Not only were the absurd practices not based on the scientific method, they were apparently based on a few experts’ opinion, or speculation.

Now consider: which PM practices currently in vogue are not based on observable, quantifiable data and analysis, but are instead predicated on group speculation, or opinion? A quick distinction is in order: feedback data is factual in nature, made up of observations of those things that have already occurred. Conversely, feed-forward data isn’t really data at all – it’s someone’s idea about what should be expected in the future, usually based on that person’s experience. As my regular readers know, usable management information must have three characteristics:

• It must be accurate,
• It must be timely, and
• It must be relevant.

Leaving aside the relevance discussion for the moment, feedback-type data is accurate (if it’s been collected properly), but often suffers from not being timely enough, due to how long it takes to collect and present. On the other hand, feed-forward data is timely, in that it looks to the future. It is, however, notoriously inaccurate, since an accurate look into the future is considered so rare as to be usually attributed to divine inspiration, if not intervention. A whole bunch of highly subjective assumptions must come about for any feedforward data to be of use.

So, this being the case, can we use the rubric of scientific-method derived theories, based on objective data, providing the basis for the ideas we embrace, while rejecting the subjective, speculative ones?

While that works for me, I doubt it will work for the PM world in general. For if we use the next-to previous sentence as our litmus test, we’ve just obliterated the majority of risk management, communications management, some portions of human resources, and even a little bit of quality management. Each of these disciplines have their advocates, who can be expected to push back on any attempt to diminish or eliminate their favorite notions.

Which brings us back to our racing oval. Congratulations on getting certified! It’s a wonderful thing. You are now set to more critically examine and engage the current thinking in the project management sciences. Oh, by the way, that finish line you just crossed? It’s also a starting line.

So let’s get started.

[i] Retrieved from http://www.cbsnews.com/pictures/15-most-bizarre-medical-treatments-ever/4/ on July 3, 2017, at 8:30 a.m. MDT.

[ii] Retrieved from http://www.cbsnews.com/pictures/15-most-bizarre-medical-treatments-ever/14/ on July 3, 2017, 8:32 a.m. MDT.

I’ve worked with some truly inspirational and brilliant executives over my career, and have spent considerable time thinking about what that highly disparate group of people had in common. As different as they all were in age, background, education, culture, and personality, they did have the following three attributes in common (which, taken together, would become Hatfield’s Rule of Management #12):

• They genuinely cared about their people, either on their project teams or in their line organizations (if you are reading this to glean tips on how to advance into executive management, and you don’t really care about your people, then do us all a favor and enter a profession that does not require managerial leadership to advance. You can only fake this attribute for so long).
• They consistently figure out the optimal technical approach to the problems facing the organization, or else readily recognize when someone else has done so. This attribute is a tricky mix of expertise and willingness to accept input from others, as evidenced by the payoff matrix below:

Note that the only instance in which the so-called communications management people and their unending urging of “engaging all of the stakeholders” represents an appropriate response is the bottom-left-hand payoff scenario. In another instance such urgings are superfluous; for the remainders, they’re flat-out wrong.

• Once they have arrived at the optimal technical approach to either pursuing the project’s scope or resolving a technical issue, they execute their strategies with passion. I like to use the example of American World War II General George S. Patton, (I’m pretty sure) should he be parachuted in to Northern Europe by himself in 1943, would not have waited around for the rest of the 3^rd Army to arrive before he started attacking Nazis.

Of course, one does not have to be a good manager to be successful, and even really good managers will experience failures at some point. But when it comes to maximizing the odds of the successful outcome of a given endeavor, the people who demonstrate these three attributes can be expected to consistently out-perform those who do not. And it is those who do not whom I wish to discuss today.

I have noticed a consistent trend among those managers who are either weak or void in the first two attributes I listed, caring for their people and arriving at the optimal technical approach. Recall Hatfield’s Rule of Management #11: the 80^th percentile best managers who have access to only 20% of the information needed to obviate a given decision will be consistently out-performed by the 20% worst managers who have access to 80% of the information so needed. I believe that most of the managers who have a hard time discerning the optimal (or even sufficient) technical approach to a given problem know this, deep down inside, and will present as constantly hungry for information. The competent manager knows the precise nature of the information streams needed for project success, and how to set them up and keep them running. The manager to avoid will flail in a sea of data, some necessary, some irrelevant, and not know which is which.

This brings me to a list of the symptoms displayed by the managers who don’t know the optimal technical approach to their jobs, and really don’t care about their people. One sure-fire tell that you are dealing with such a manager is that they will insist on setting up and maintaining a database of the things that they need to pay attention to. Such systems have a variety of names, such as “Action Item Tracking,” or “Issues Management” systems, among others, but their purpose is the same: to inform the sub-optimal manager of the things that need their attention. Don’t get me wrong – institutional issues management systems can and do provide a vital information stream to execs several levels removed from the projects’ trenches. No, the systems I’m talking about seem to be always predicated on a model that includes a central repository of data, surrounded by input/output nodes. This “poll” is, of course, an invalid management information system structure, since it has absolutely no ability to differentiate between subjective or objective data, nor information that is feedback-based as opposed to feedforward. It also has the drawback of displacing legitimate systems, such as those predicated on Earned Value or Critical Path methodologies.

Add to the existence of these invalid information systems a tendency to call multiple meetings designed to simply check on what everybody is doing (or else, more insidiously, some confidant spying on what everyone is up to), and there can really be no doubt: the person you are dealing with can’t benefit from any legit lessons learned analysis, since they have a poor concept of which information streams are relevant to the successful pursuit of the technical agenda at hand.

So it all comes down to this: if a given manager is incapable of discerning relevant and irrelevant information in the here-and-now, why should they suddenly be able to discern it from lessons learned reports?

During the May 1916 Battle of Jutland, elements of Great Britain’s Grand Fleet fought to keep the Kaiser’s High Seas Fleet from breaking the naval blockade of Germany. Hundreds of ships were involved, but when the smoke cleared the Germans had failed to significantly change the ratio of capital ships between the two belligerents, and the blockade remained in place. One American journalist summed up the massive naval action thusly: “The convict assaulted his jailer, but he is still in jail.”

Along those lines, I think much of what passes for chapter and verse of lessons learned reports can be boiled down to its essential elements, and documented so. A few examples on the topic of the PM’s technical approach:

• On Earned Value reporting: (a) just because you are spending money on a project does not mean you are accomplishing anything, (b) we can prove it, and (c) if you tell me how much you have spent, and how much progress you have made, I can tell you within ten points how much your project is going to cost when it’s done.
• On Critical Path methodology: (a) if you are “managing” your schedule via an action item or milestone list, you’re doing it wrong, (b) we can prove it, and (c) tell me when you started, and how much progress you’ve made, and I can tell you both when your task will be completed, and how that impacts the other activities in this project.
• On Critical Chain theory: if you get done early, help any other members of the project team who are behind.
• On (modern) Communications Management theory: tell everybody you think of everything that’s going on in your project, and nothing bad will happen to you.
• On (modern) Risk Management Theory: you might want to worry about stuff that could happen to your project.
  • Hey! Risk Management also involves “Opportunity Management!”
  • Says who?
  • SAYS US!!! We’re members of the risk management community, and we’re more than a little tired of you accusing us of engaging in “openly fraudulent management science.”
  • Are you aware that none of the authoritative dictionaries of the English language make any references to “opportunity” (other than in listings of antonyms) in their definitions of “risk”?
  • That doesn’t make any difference, since we’ve arranged to have almost all of the PM organizations include our “upside risk equals opportunity” tripe
  •  in their glossaries of terms.
  • Okay, how about “you might also want to concern yourselves with opportunities that may or may not arise.” Happy now?
  • Yes, you may proceed.

The following elements are extremely common to (truthful) lessons learned reports coming from failed or overrun/delayed projects:

• We should have used Earned Value and Critical Path methodologies far earlier than we did.
• The “bottoms-up” Estimates at Completion (EACs) were always optimistic, and often catastrophically so. Conversely, the calculated EACs were always accurate, and could have notified management of difficulties far earlier than the re-estimated versions.
  • On a related note, that project controls person who told us that, in order for our EAC to be accurate, our cost performance would have to go from a cumulative Cost Performance Index of 0.7 to a To-Complete Performance Index of 1.4, and that that had virtually no possibility of happening, and that our posted EAC was therefore nonsense – well, that person was right.
• The tasks that drove most of the project’s overrun were subject to significant amounts of scope creep, and we should have listened to those PM-types who were harping about better and more detailed descriptions of the original scope.
• An “overly optimistic original estimate” explanation in the Variance Analysis Reports (VARs) of negative cost variances will only work a few times before the customer catches on that it’s really our pitiful performance causing the variance.

As with anything that gets condensed, these lessons learned can be significantly harder to digest than their more verbose equivalents. But if the lessons to be learned are couched in phrases designed to soft-pedal the truth, I have to ask: did anybody really learn anything from the past projects’ failures?