Game Theory in Management

In the Arthur Conan Doyle short story The Adventure Of Silver Blaze, Sherlock Holmes investigates the disappearance of a famous race horse, Silver Blaze, and the death of its trainer, John Straker. While the police’s primary suspect, Fitzroy Simpson, appears to have significant evidence against him, Holmes is struck by the fact that the stable’s dog did not bark as the theft was taking place. The precise dialogue is:

“Is there any point to which you would wish to draw my attention?'
'To the curious incident of the dog in the night-time.'
'The dog did nothing in the night-time.'
'That was the curious incident,' remarked Sherlock Holmes.”[i]

While the exact phrase “the dog that did not bark” does not appear in The Adventure of Silver Blaze, that phrase has become something of a cliché when it comes to describing a person, device, or organization that suspiciously does not perform as it should at a key time, indicating that something is very wrong. In fact, doing an internet search on “the dog that did not bark” will return results for both The Adventure of Silver Blaze and (typically) political manifestations of the cliché version.

Meanwhile, Back In The Project Management World…

GTIM Nation knows of my oft-asserted claim that the primary purpose of the Project Management Office (PMO) is to put into the hands of the decision-makers the information they need to make, well, the best-informed decisions that they can. Does this strike my readers as being unduly narrow? Consider: when combined with Hatfield’s Rule Of Management #3, which reads:

3. 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^th percentile worst managers who have access to 80% of the information so needed.

…then generating such information becomes macro-organization-changing. Organizations with a PMO that creates and presents Project cost and schedule performance information to management will enjoy a significant advantage over their poorer-informed competition, which is likely to manifest in superior portfolio performance. As for those PMO Directors (and their supporting consultants) who insist that the primary function of the PMO is to drive “culture change,” or lead execs to a point of view that a robust risk management (no initial caps) function is necessary, or that all PMs should be forced to “engage all stakeholders,” etc., etc., I have this to say: no, no, and (blank) no.

But even if the PMO Director is enlightened enough to accept my take on the PMO’s primary function, we still have some problems, perhaps best shown by the following Payoff Grid:

Let’s dispense with the “all good” scenarios. If the Project is performing well in cost and schedule space, and the management information systems operated by the PMO indicate as such, then things are working as they should. Similarly, if the PMO’s information streams are raising red flags, and the Projects indicated are actually performing poorly, then those information streams are working as intended, notifying upper levels of management where they should be focusing their time and energy.

Which brings us to our two something’s-very-wrong scenarios. In Scenario B2, the “Silver Blaze” scenario, the PMO is failing because a management problem is manifesting, but not being detected by the very systems designed to reveal it. This can lead to stolen race horses and killed trainers in the literary world, and overruns and delays in the project portfolio in the real one. Cost and schedule performance issues can be hidden from an otherwise-functioning Earned Value Management System (EVMS) by such chicanery as overstating the percent complete of a task, or employing the “bottoms-up” method of developing the Estimate at Completion, but the canny PMO Director will have sufficient surveillance to prevent this undermining of these systems.

As this blog’s title implies, I want to now look at Scenario A1, where the subject Project is actually performing well, but the PMO’s information streams indicate a problem. Besides misdirecting limited managerial attention away from real problems towards the non-existent variety, and putting PMs on the defensive unfairly, such false alerts directly damage the credibility of the PMO, an organization that depends heavily on the reliability of the information it processes and presents. This damage only gets worse if the reason behind the incessant barking is due to something supercilious, such as the lack of a risk management (no initial caps) system, or a perceived failure to “engage stakeholders,” or “change the culture.”

It’s elementary: that dog needs to shush.

[i] Retrieved from https://www.goodreads.com/quotes/82195-is-there-any-point-to-which-you-would-wish-to on November 16, 2024, 18:41 MST.

One of my favorite scenes from the comedy classic movie The Blues Brothers (1980) involves the newly-reconstituted band playing a gig at Bob’s Country Bunker at a time slot intended for The Good Ol’ Boys band. Neither Bob’s Country Bunker management nor the rest of the Blues Brothers band are aware that Jake is hijacking the Good Ol’ Boys’ slot, and the Blues Brothers band, after introducing themselves as the “Good Ol’ Blues Brothers Boys band,” begins their set with the song Gimme Some Lovin’. Since this song is not normally associated with the country-western genre, the patrons begin to boo and throw beer bottles against the chicken wire that has been erected to protect the stage.

“We better figure out something these people like, and fast,” counsels Elwood.

“Hey, I’ve got it” replies Murph Dunn. “Remember the theme from Rawhide?”

As the band begins playing the Theme From Rawhide, the patrons at Bob’s immediately begin to show their approval, clapping, hollering, and dancing on the tables. By continuing the set with other songs in the country-western genre, the crowd continues to approve of the entertainment, and the gig ends successfully for the band (well, except that they end up drinking more than the value of the appearance). A couple of interesting tidbits about those two songs: Gimme Some Lovin’ was first released by the Spencer Davis Group in 1966, and charted in the top ten in several different countries[i], while the Theme From Rawhide was recorded by Frankie Lane in 1958[ii]. While it served as the theme song from the television series Rawhide, and reached the Number 6 slot in the United Kingdom[iii], it did not receive the same level of critical acclaim as Gimme Some Lovin’, which made Rolling Stone’s list of the 500 greatest songs[iv]. In other words, the assumption that Gimme Some Lovin’ would nominally receive more approval from a generic set of people than Theme From Rawhide appears perfectly rational; however, since their audience was certainly not a generic collection of people, the Blues Brothers Band had to make a quick change to their intended program in order to consider the gig to be a success.

Meanwhile, Back In The Project Management World…

GTIM Nation knows of my prior usages of the axiom Quality, Availability, Affordability: pick any two. I continue to believe, not only in its relevance, but that this truism is significantly underrated in the formulation of technical approaches to discovering and pursuing managerial problems. It’s been my observation that this undervaluation is particularly present in the founding or maintaining of the Project Management Office, or PMO. Which two of the three aspects of your organization’s product or service presentation must have a direct impact on which PMO strategy is best suited for that environment, to wit:

• The organization that has gotten ahead by offering affordable goods or services without their customers having to be on some sort of waiting list will likely not be interested in a PMO that insists, by encoding into policy or procedure, on robust Work Package/Control Account development, coupled to an exhaustive risk management (no initial caps) program, and overlayed with a Baseline Change Control Board that only meets once per month.
• Similarly, the organization whose market share depends on high-quality goods and services that are comparatively affordable, but require long lead-times, can afford to have a PMO that’s relatively smaller than the others in the same market, since the likelihood of the PMO being surprised with a sudden, marked increase in programmatic load is relatively small.
• This third configuration, of the organization that offers high-quality goods or services that are relatively available, but not as affordable, is the only one of the three where a high level of PM expertise driving a complex and robust PM discipline and information system creation and maintenance is likely to be appropriate.

But here is where the environment for having the band strike up Gimme Some Lovin’ when the macro-organization wants Theme From Rawhide is likely to manifest, since organizations large enough to dedicate the resources to create and maintain a PMO in the first place will often present as if the high-level-of-expertise crowd should come in and implement a robust PM strategy as being the optimal one. It could very well be that the macro-organization is seeking only a basic, easily-implemented cost and schedule performance measurement system in order to get a handle on the behavior of the project portfolio.

And I think it would be a good idea for the PMO Director to ascertain if that’s the environment she’s in, prior to the beer bottles hitting the chicken wire.

[i] Retrieved from https://en.wikipedia.org/wiki/Gimme_Some_Lovin%27 on November 11, 2024, 14:01 MST.

[ii] Ibid.

[iii] Retrieved from https://www.songfacts.com/facts/frankie-laine/rawhide on November 11, 2024, 18:53 MST.

[iv] Retrieved from https://en.wikipedia.org/wiki/Gimme_Some_Lovin%27 on November 11, 2024, 14:11 MST.

“Consensus is the negation of leadership.”

                                    -- Margaret Thatcher[i]

“Genius abhors consensus because when consensus is reached, thinking stops. Stop nodding  your head.”

                                    -- Albert Einstein[ii]

I had published several pieces in my Variance Threshold column in PMNetwork on a particular element of PM prior to PMI® contacting me to participate in the creation of the Practice Standard on that topic, so I felt pretty good about writing a couple thousand words for the draft Chapter One, and sending them off to the effort’s PM. He had arranged for a confab of the early contributors out in California, at a hotel/conference center, and I was looking forward to hobnobbing with my fellow subject matter experts. And man-o-man, was I in for an education.

We were in a conference room with a “U” shaped table, with a laptop and projector at the base of the U, and a screen at the top, where the PM would project the text I had sent. If memory serves, there were around a dozen people in the room. As an aside, I was the only attendee who had actually generated verbiage. Everyone else there was in the position of reviewer. When my first paragraph was thrown onto the screen, about half the room objected to it, for various reasons. Interestingly, the other half of the room was okay with it, or even praised it. Paragraph One marked for further review, on to Paragraph Two. This time, those who objected to Paragraph One approved, but those who found Paragraph One acceptable were suddenly critical of Paragraph Two. Paragraph Two marked for further review, on to Paragraph Three.

And so it went, the entire frustrating weekend.

At a subsequent get-together sponsored by PMI®, this one to cover the ground rules for creating practice standard-level content, a representative from the American National Standards Institute (ANSI) gave a presentation on the, well, standards to be observed while generating our document. During the Q&A, I asked about a suitable test for making an include/don’t include determination on content, and his answer amazed me. He said that, essentially, an assertion should not be included if a substantial number of people who are identified as experts in the field objected to it. This is consistent with ANSI’s definition of “consensus,” which reads:

Consensus means that substantial agreement has been reached by stakeholders. It signifies more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that an effort be made toward their resolution (emphasis in the original).[iii]

My (and, probably, PMI®’s) takeaway: never allow Hatfield to be the author of a document where consensus is called for.

I’m in good company. Consider this quote from Michael Crichton:

Let’s be clear: the work of science has nothing whatever to do with consensus. Consensus is the business of politics. Science, on the contrary, requires only one investigator who happens to be right, which means that he or she has results that are verifiable by reference to the real world. In science consensus is irrelevant. What is relevant is reproducible results. The greatest scientists in history are great precisely because they broke with the consensus.[iv]

Of course, Crichton is referring to the hard sciences when he talks about reproducible results. However, I’m made bold to assert that the Management Sciences aren’t that far removed from their harder cousins. Both are subject to the task of comprehensively identifying all pertinent parameters, and to then quantify them precisely. In those instances, like the free marketplace, where comprehensively identifying all pertinent parameters, and then precisely quantifying them is next to impossible, it’s pretty easy to see why consensus becomes the automatic stand-in for the whole hypothesis-experiment-evaluate results cycle upon which authentic science depends.

Even so, I’m forced to agree with Thatcher and Einstein. In the Project Management arena specifically, the PM must be the one who has final say with respect to setting the technical agenda. It’s been my observation that the technical agenda set by consensus is more likely to fail to come in on-time, on-budget for any but the most routine of Projects. To be clear, I’m not saying that guidance documents or practice standards should be assembled in any other way, nor that the PM should not be informed by the subject matter experts to whom she has access. I am saying that, ultimately, the way the Project Team approaches the problem to be solved must be the responsibility of one person. If they succeed, that person and the Project Team deserve accolades. If they fail, not so much. If they fail catastrophically, the PM should own the selected technical approach, and face consequences. Otherwise, they will end up adding to some wrong-headed consensus, which turns into policy, increasing the odds that someone else in the organization will use the wrong-headed strategy, with entirely predictable results.

Based on such a sequence, I’m going to remain skeptical that consensus is the friend of management science, or true leadership.

[i] Retrieved from https://www.azquotes.com/quotes/topics/consensus.html on October 26, 2024, 19:26 MDT.

[ii] Ibid.

[iii] Retrieved from https://www.ansi.org/standards-faqs on October 26, 2024, 20:44 MDT.

[iv] Crichton, Michael, “Aliens Cause Global Warming,” Caltech Michelin lecture, January 17, 2003.

“Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket.”

― Eric Hoffer, The Temper of Our Time[i]

While Eric Hoffer’s quote (above) may have been originally intended for social-economic or political movements, I believe it provides valuable insights into the nature of business organizations, and their life-cycles. It’s been my observation that many (if not most) businesses begin with an entrepreneurial or technological vision, from building the proverbial better mousetrap to ways of producing or delivering goods and services better, faster, cheaper. Then come our friends, the Asset Managers, to monetize this vision – recall their oft-cited assertion that the point of all management is to “maximize shareholder wealth.” Now, Hoffer’s use of the term “racket” may be a bit harsh when it comes to describing the phases of business organizational maturity – I prefer to describe this end phase as being characterized by a shift in the organization’s internal narrative, away from the original vision’s direct fulfillment and towards keeping the organizational machine running for the sake of keeping it running.

I further believe that something fascinating happens to our sample organization’s business model as it advances from movement to business to racket propped-up machine – it becomes more and more hardened. Think about it: when the original idea turns into a new business, if there is a business model behind it at all, it’s fairly malleable. Official policies and procedures may not even exist, with the technical approaches to solving the problems addressed bound only by the rule of law. It’s only after attempts to monetize the original idea that aspects of the structure of the business model become recognized, and then codified, formally or otherwise. Even here, if a preliminary rule of doing business is found to be sub-optimal, it’s far easier to modify or even abandon it in these early stages.

But make no mistake: once the vision becomes monetized, a business structure must be in-place, if for no other reason than to make sure taxes are correctly determined and paid. Codification of hiring and firing practices are right behind, along with procurement, safety and health, organizational structure, etc., etc. The most insidious aspect of the three-phase Hoffer-esque organizational transformation must be the movement from business to racket self-sustaining machine. Here, those running the organization have lesser (or even non-existent) ties to the visionaries who started the whole shebang. Their understanding of organizational purpose is far more likely to be centered on, well, maximizing shareholder wealth, particularly if they’ve attended a business school in the United States.

GTIM Nation is familiar with my assertion that there are three types of management, so:

• Asset Management is focused on the aforementioned maximizing shareholder wealth, and its primary information source is the general ledger.
• Project Management, conversely, is centered on the customers’ expectations of scope, cost, and schedule. Its main information source is derived from Earned Value and Critical Path methodologies.
• Strategic Management’s function is to maximize market share with the assets and project portfolio available to it.

Returning to the movement-business-racket on-going concern evolution structure, it’s easy to see which type of management benefits the most from the associated ossification of the business model, our friends, the Asset Managers. Generally speaking, they’re thrilled when they can, say, maximize the revenue from a given project or program, even if it involves sub-optimal performance against the scope, and corporate policy will often reflect as such in more mature organizations. On the other hand, the PMs, again generally speaking, are better with an outcome of on-time and under-budget scope delivery, even if it means, say, the contingency budget is never touched. A fully consumed contingency budget (assuming it was funded by the customer) might have maximized the revenue available in the Project, and have been recognized as beneficial in the near-term. But an on-time, on- (or under-) budget delivery means that this customer is likely to bring more business in the future, meaning an increase in market share, which typically won’t manifest until the mid- to long-term. A portfolio of high-performing Projects will almost certainly impede, or even reverse, the movement away from the organization’s original vision and its associated business model calcification, since the overriding narrative is still centered on the customers’ expectations of performance.

We’ve all encountered organizations that have become enmired in the just-keep-the-machine-going phase, typically manifesting disdain (or even contempt) for customers, existing and potential. Since these organizations never actually started that way, it’s safe to assume a certain degree of, ahem, getting on has occurred. Is there a remedy, short of the macro-organization sliding into irrelevance?

Sure. It’s that fountain of youth, Project Management.

[i] Retrieved from https://www.goodreads.com/quotes/98215-every-great-cause-begins-as-a-movement-becomes-a-business on October 15, 2024, 18:35 MDT.

A lot of the current literature on the topic of Leadership (ProjectManagement.com’s theme for October) focusses on the relationship between the leader and the team that follows him, usually along the lines of eat-your-peas-style hectoring on how said leader treats the individuals in the organization. Does she treat them with respect? With absolutely no trace of partiality? Do the individual organization members receive sufficient training, or mentoring? Why not? Etcetera, etcetera.

I find this type of discourse tiring in the extreme. It strikes me as a kind of micro-organizational navel-gazing exercise, spending energy on the quality of the relationships within the team rather than the project’s actual scope. Sure, relationships within the organization matter, but what matters more is the ability of the putative leader to correctly identify the optimal technical approach to resolving the problem(s) facing the Project Team, and to execute it with the resources at her disposal.

An easy litmus test for which type of organization GTIM Nation members belong to is this: is your superior happier if your Project is late or over budget, but you executed a technical agenda entirely within the organization’s guidelines? Or are they happier if you bring in your Project on-time, on-(or even under) budget, but had to ignore some admonishments from the risk managers (no initial caps) about the absence of a “risk register,” even though your organization’s procedures required you to have one? The former category has to manage by metaphorically maintaining a view from over-the-shoulder, spending time and energy on demonstrating the execution of an approved process, whereas the latter category has the latitude to pursue the Project’s goals in what the PM perceives as the best manner available. (Note: I am absolutely NOT talking about safety or security guidance here. Those must be observed in their totality, no exceptions.) It makes for a huge difference in not only the organization’s culture, but in the odds of successfully executing all of the elements within Project portfolio. The answer to this question is also an indicator of the adaptability of the organization’s business model to changing, unpredictable circumstances. If it is pliable enough to maximize the odds of Project success, then I would consider that a notable advantage. However, if Project success is considered secondary to demonstrable adhesion to business-related policy and procedure, odds are that the business model has become so ossified as to almost guarantee Project portfolio sub-par performance.

I want to be crystal clear here: identifying the optimal technical approach to PM problems is not simply dropping copies of the PMBOK Guide® on managers’ desk (with a satisfactory “thud”), and expecting them to spontaneously develop Work Breakdown Structures (WBSs) and Work Packages. From a Project Management Office (PMO) Director’s point of view, this would be the equivalent of trying to advance a capability by using the Argument from Authority – a logical fallacy – with that “authority” being our beloved PMI®. But unless I’ve missed something over my over-thirty-year association with the Project Management Institute®, they do not maintain an Enforcement Division (and, if they do, I want to be part of it!). Even if such an appeal to authority was not considered a logical fallacy, I would be cautious of assuming that everything that appears in any guidance document is timelessly true. If that were the case, there would not be seven editions of the PMBOK Guide® as of 2021.  

Which brings me back to my original point. So-called “best practices” achieve that status only after they have been tried out in a variety of Project circumstances and found to be consistently useful. Then and only then can they become candidates for addition to any kind of codex or PM practices, like the PMBOK Guide®. In-between the time that these practices are discovered and implemented, and then published or codified, a wide array of decisions await the typical PM, decisions that might not be able to be informed by what has gone before. Sure, some Project work is so routine that adherence to the tried-and-true (or the novel and recently-released) is the best way to achieve success. But in a lot of (most?) Project work, key decisions will have little or no precedent, and yet must be addressed in real time. These are the situations where managerial leadership is key, where there is no precedent or codified technical approach to the newly-presented problem. PMs resolve these kinds of problems all the time.

And they can’t do so by looking over their shoulders.