Game Theory in Management

No discussion of data disruption (ProjectManagement.com’s theme for July) would be complete without addressing that most difficult to define, yet central to all management information components, relevance. Dr. Watson was often surprised by Sherlock Holmes’ lack of awareness of popular news, which Holmes would explain as his desire to not overload his mind with data that was not relevant to his ability to solve crimes, demonstrating that the issue of data disruption has been with us since (fictional) Victorian London.

There are lots of definitions of the words relevant and relevancy, but, for the sake of this discussion, I’ll use the direct ”sufficiency to infer the conclusion.” What conclusion(s)? The one(s) that can provide the basis for, in our case, informed Project Management decisions. Recall my oft-stated derivative of the Pareto Principal, that the 80^th percentile best managers with 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. In other words, the existence and availability of relevant management information easily trumps superior managerial judgement, all other things being equal. It’s the reason why junior managers, generally speaking, do not have nearly the latitude of action that their more senior counterparts do – if one is not sure of the capability of a given decision-maker, limiting their options in an environment where canned strategies haven’t been tried is always the safer strategy.

Many things can chip away at an information stream’s relevancy. Perhaps the most pernicious is the insertion of subjectivity into the data set. Throughout my career, every single time I’ve been asked to perform an analysis of the circumstances and events that led up to a surprise overrun, the presence of subjective data – namely, the so-called “bottoms-up” Estimate at Completion – has been the culprit. This method of generating an EAC involves re-estimating the project’s (or Control Account’s, or Work Package’s) remaining work, and adding this figure to the cumulative actuals. The folly of employing this method is best laid bare with a simple histogram, showing three bars per reporting period, typically stretching back 6-7 months prior to the reporting cycle that (finally!) fesses up to the overrun: one bar indicates the Budget at Completion (BAC), the second shows the Project Manager’s / bottoms-up EAC, and the third shows the calculated EAC, based on the data available at each reporting cycle. Each time I’ve performed this analysis and produced said histogram, the results have been the same. The BAC level remains level (or close to level) for the duration, barring some Baseline Change Proposal that got snuck in to try and alleviate the incoming disaster. The PM’s / bottoms-up EAC mirrors the BAC, right up until two reporting cycles prior to the obvious, where it ticks up a bit, and then jumps to the same level as the Calculated EAC has been showing all along. The level of subjectivity inherent in the PM’s EAC, or the estimators’ take on the remaining work, render that version of the EAC irrelevant to the task of alerting management of an upcoming overrun. I call this effect pernicious because, not only does it fail to perform the task of identifying and quantifying cost performance issues early on, it actually does the opposite. It hides such problems, all while a valid calculated EAC is available, if management was only canny enough to reject the bottoms-up imposter.

Lack of timeliness will also erode an information stream’s relevance. “Quickness is the essence of the war,” claimed Sun Tzu,[i] and lack of it is poison to the Management Information System. The history of warfare is filled with stories of commanders not receiving critical, tide-of-battle-changing information until it was too late. Actionable PM information has a much shorter shelf-life than, say, information coming out of the general ledger, due to the more dynamic nature of Project Management over Asset Management. A Control Account Manager turning in a travel voucher late is no big deal. That same CAM who reports the percent complete figure late can disrupt the entire project’s reporting cycle.

Finally, if we are to employ the relevancy filter to eliminate otherwise disruptive data, then the comprehensive data set must be accurate. Inaccurate (i.e., false) data rarely comes with a warning label. But make no mistake – the processing methodology that can produce relevant information without accurate data has not been invented, nor will it ever be.

“Data! Data! Data!” he cried impatiently. “I can’t make bricks without clay.”

                                    -- Sherlock Holmes, The Adventure of the Copper Beeches

…and so it is with us PM-types. But the types of information streams we use are different by type, not degree, from those used by the Asset Managers, or even Strategic Managers, and the distinction will forever fall upon the filter of relevance.

[i] Retrieved from https://wealthygorilla.com/35-powerful-sun-tzu-quotes-art-war/ on July 11, 2022, 18:14 MDT.

I recently attended a conference on Predictive Analytics and Machine Learning but found it, for the most part, rather disappointing. Two of the presentations that I attended really stood out, for different reasons. The first – a truly superb one – both demonstrated an advanced knowledge in the field, and passed along usable insights. It was presented, if I’m remembering correctly, by a professor from Northeastern University. The other was just a mess. It was an attempt to attach value judgements to the results of an analysis model dealing with sentencing and parole decisions. I found the entire premise to be vacuous, for the following reasons:

• For MISs that inform public policy, no model makes decisions. They can attempt to inform decision-makers, and the decision-makers may adhere to a template, but the models, themselves, do not make these decisions.
• Data can be complete or incomplete, relevant or irrelevant, but absolutely cannot be legitimately labelled morally right or morally wrong.
• Similarly, the methodology used to process the data into usable information (alternately referred to as “the model” or “analytics,” as in “predictive analytics”) can be valid, or invalid. It cannot be considered morally right or morally wrong.
• It was clear that the presenters who had analyzed this model were doing so from an incomplete data set, and had no idea that that was their problem, much less how to pursue a remedy.

Recall Hatfield’s Incontrovertible Rule of Management # (I lost track), that all valid Management Information Systems –even those laying claim to performing “predictive analytics” – have the same high-level structure, to wit:

• Data is collected, based on some discipline or set of parameters. In PM, we tend to want to know the scope of the work, and the amount of resources and time needed to accomplish it.
• The Data is processed into usable information, usually based on some sort of methodology. For we PM-types, Earned Value and Critical Path methodologies are central to our Management Information Systems (MISs).
• The information is delivered to the decision-makers in a way that they can actually understand and make use of it. Entry-level Project Controls specialists often err when they believe that all PMs can instantly understand a Gantt Chart, or a Cost Performance Report in Format 1.

It quickly became clear to me and my associates that, while the paper presenters and organizations manning booths in the Exhibitor’s Hall were demonstrably adept at collecting data and then using that data to better identify the buying habits of specific demographics (the better to target marketing efforts), they fell quizzically silent when the topic moved away from anticipating purchasing trends. The favorite “predictive” tool of our friends, the risk managers (no initial caps), the Monte Carlo analysis technique, was never mentioned in my hearing. An old saw in the Legal Profession is “If the facts are against you, argue the law. If the law is against you, argue the facts. If the law and the facts are against you, pound the table.”[i] I think the management science derivative would be “when you don’t have the actual algorithm at the heart of you MIS down, talk about the data. When you don’t have a real shot at collecting the comprehensive data set to make your model work, talk about the algorithm. When you have neither, fake it.”

Speaking of faking it, a common but utterly invalid method for creating a Management Information System that supposedly gives advanced warning of problems is to set up some form of a common data repository, call it something like an “action item manager,” and then have it collect data without a clearly-defined discipline or structure. The resulting “system” is, essentially, a poll, a data stack surrounded by input and output nodes. The problem with a poll is that someone always has better (more recent, or more accurate) data, so that its holdings are unreliable. Add to that the fact that massive amounts of subjectivity get shoe-horned into this “system,” and you have an environment perfectly suited to the generation of an invalid MIS, passing along highly subjective data as reliable information. What could go wrong?

Which gets us back to the whole notion of data being “disruptive.” Data, by definition, can be timely or late, relevant or irrelevant, but it can’t be wrong, or inaccurate (the term “bad data” is analogous to “bad facts.”). If a particular fact is found to be disruptive, the question has to be asked, disruptive to what? Or to whom? Well, to a particular belief, and the person holding that belief. In this sense, the whole of the PMBOK Guide® could conceivably be seen as disruptive to all of those business schools still teaching the obsolete concept that the purpose of all management is to “maximize shareholder wealth,” similar to the fact that the Earth casting a round shadow on the moon during a lunar eclipse is “disruptive” data to flat-earthers. Is your model or analysis technique delivering unexpected or unreliable output? It could be disruptive data, sure. Verify the data, of course, but suspect your analysis technique.

Or you could just pound the table.

[i] Sandburg, Carl, retrieved from https://www.goodreads.com/quotes/918291-if-the-facts-are-against-you-argue-the-law-if on July 4, 2022, 17:38 MDT.

I left off last week’s blog by pointing out that a very common strategy for standing up a new Management Information System (MIS), one that entails problem or information deficiency analysis, selection of the solution, purchase, installation, training, and then…failure. Well, usually not complete and dramatic, like the HAL 9000 killing every astronaut on board the Discovery except for Dave in 2001, A Space Odyssey. Such failures usually have a closer resemblance to Deep Thought, the supercomputer developed by the Magratheans to solve the Ultimate Question of Life, the Universe, and Everything in The Hitchhiker’s Guide To The Galaxy. (WARNING: Spoiler Alert!) 

*  *  *  *  *

In the aforementioned Hitchhiker’s Guide, the Magratheans are highly desirous to learn the answer to the “ultimate question,” the meaning of “life, the universe, and everything.” To obtain this answer they spend 7.5 million years constructing a supercomputer they name “Deep Thought.” Upon finally completing Deep Thought and posing the question, Deep Thought replies with the first six words in this blog’s title. It ultimately delivers “the answer,” but it’s not one that the Magratheans can understand – it’s the number forty-two. When quizzed on how forty-two could possibly be the answer, Deep Thought responds by chiding the Magratheans for putting so vaguely-worded a question to it in the first place. When the Magratheans ask how the question should have been articulated originally, Deep Thought reveals that it can’t deliver that answer, but can help design the next-generation computer than can, but it will take around 10 million years.

So, what can we learn from the inestimable Douglas Adams?

I think Deep Thought’s story is strongly analogous to those organizations seeking a turnkey solution to their Management Information System problems. Is Chapter 28 of The Hitchhiker’s Guide an over-the-top exaggeration? Sure. Does it present the Magratheans as having a comically narrow obsession with obtaining their desired result? No doubt. But even with these distortions of scale, consider how closely this story aligns with the pursuit of large-scale turnkey “solutions.”

• Senior members of the organization are highly desirous of obtaining some information stream, one that will make most (if not all) of their management problems go away.
• A clearly-articulatable and precise scoping of the end-product is almost never available.
• Indeed, to the extent that specifics of the desired system are submitted for evaluation, they’re almost guaranteed to generate more conflict and confusion. There’s even disagreement among the Magratheans about whether or not the excessive time needed to deliver the answer is a good thing or a bad thing.
• While an acknowledgement of the vast amount of data needed to produce an answer is generally ceded, the precise methodology for converting that data into usable information remains hidden.
• When the solution is delivered, it’s not what those who posed the question had in mind. It is, for all practical purposes, either extremely disappointing, or out-and-out useless.

Then we come to the nominal implementation strategy for a turnkey solution. Unless we’re looking at a brand-new organization, or an established one with an absolutely barren MIS environment, the desired turnkey solution will displace an existing system (or systems) considered inadequate for the present demand. Problem is, not everyone who is counting on the continued functioning of these supposed inadequate systems believes they ought to be replaced. Even when the existing system is widely recognized as needing replacement, since the current operations staff is rarely consulted for its replacement, they will invariably resist the change. I could go on (and often do), but you see my point. One does not have to be a Magrathean to place high hopes (and massive budget amounts) in the establishment of a supposed turnkey solution only to have those hopes dashed (and budget wasted) on the ultimate result.

The solution? Don’t pursue an all-at-once answer. Consider how much easier it is to name specific added capabilities to existing systems to make them incrementally more robust as opposed to having one system generate an ill-conceived final resolution. Collect the obtainable, easily-captured features that can be added to existing systems, or derived from pulling and normalizing several extant programs. Triage these incremental upgrades, but, unintuitively, don’t give precedence to the most important ones. Prioritize the ones that are clearly articulatable, and relatively easy to add, meaning the least amount of hands-on-keyboards effort to collect the needed data. Ideally, the data could be pulled from existing systems, or accessible via a current system that’s not using an available feature.

The Magratheans executives who had their hearts set on a turnkey solution won’t be happy, at least not at first, so it will be important to document the successes of the incremental enhancements as they come on-line. Recall Hatfield’s Incontrovertible Rule of Management (whatever), from last blog, that the 80^th percentile best managers with access to just 20% of the information they need to obviate a given decision will be consistently outperformed by the 20^th percentile who have access to the information so needed. We’re not trying to jump straight from 20% to 80%, which is likely impossible anyway. Just take a couple of points at a time, and before you know it your executives will be making superior, and then optimal decisions.

All without you having to tell them “I’ll have to think about it.”

What is a “turn-key,” or “turnkey,” solution? Well, according to Investopedia,

A turnkey solution is a type of system built end-to-end for a customer that can be easily implemented into a current business process. It is immediately ready to use upon implementation and is designed to fulfill a certain process such as manufacturing (in part or whole), billing, website design, training, or content management.[i]

Sounds ultra-attractive, does it not? Indeed, I would speculate that a majority of software systems laying claim to “enterprise,” “all-in-one,” or “total portfolio” management have a marketing campaign that includes at least some element of the assertion that their product(s) can present fast and comprehensive solutions to any of the management problems plaguing your organization.

But there’s a major problem with such assertions, and it’s contained right there in the Investopedia definition, the part about “built end-to-end for a customer that can be easily implemented into a current business process.”[ii] Let’s say, for the sake of argument, that this particular customer has already put in-place a management strategy that has taken into account the axiom “Quality, Availability, Affordability – pick any two, “ and has correctly read the business environment for the selected strategy. Let’s also posit that the turnkey solution selected represents the optimal technical approach to whatever management information deficiencies are perceived to be afflicting the organization. Note that these are two HUGE concessions, but I’ll grant them anyway.

What about the implementation strategy?

This is a door that the inexperienced (or naïve) Information Technology (IT) Project Manager will open into his face, over and over again. The standard template for “implementation” usually consists of the following steps:

• The group or team struggling with insufficient management information will call on their organization’s Information Technology (IT) department.
• The IT team will interview users and other stakeholders, and become fluent in any procedures or requirements that pertain to the problem.
• In larger organizations, they will see if an analogous problem has been addressed and satisfactorily resolved within that division.
• If no readily-available nearby solution is uncovered, they will seek out other companies within the same industry who have laid claim to having overcome this problem, and don’t mind bragging about it (why on earth would they brag about it? Check out the numerous paper presentations at PMI® Congresses, or local Chapter meetings, essentially boasting about the particulars of the successful completion of some gee-whiz project.).
• Should no suitable candidates pop to the surface, they will seek out analogous problems outside their specific industry, and see if any solutions exist there.
• At the end of all of this investigation, they will prepare some kind of position paper with the requisite Executive Summary, Technical Discussion, Recommended Solution(s), and Conclusion paragraphs, all pointing to what they hold to be the answer, often some form of a turnkey program.
• After upper management has signed off on the solution, funds are allocated for “implementation.” This involves purchasing the software, installing it on people’s computers, training those same people, and announcing the date that everyone’s expected to employ the solution,

…and it rarely, if ever, works as advertised. Sometimes it doesn’t advance the correction of the original problem enough to justify all of the effort expended in the previous seven steps, but abandoning the solution isn’t considered viable, due to the (invalid, of course) sunk costs argument. As the Team responsible for correcting the original problem becomes associated with the failure, blame invariably gets directed to those personnel who were responsible for collecting the solution’s data, usually tinged with the flavor of bitterness that comes from failing to achieve sufficient “cooperation” from the host organization. A new IT Project Team is engaged, and the cycle begins anew.

So, how to avoid this vicious cycle? Recall Hatfield’s Incontrovertible Rule of Management # whatever, that asserts my very own variation of the Pareto Principle, that the 80^th percentile best managers who have access to 20% of the information needed to obviate a given decision will be consistently outperformed by the 20^th percentile worst managers who have access to 80% of the information so needed. Based on this rule, it’s vital for PMO Directors to abandon the notion that a turnkey solution represents the optimal approach, once the necessary organizational cooperation is attained, the data is collected and entered into the package, some switch is flipped, and the 100% solution gets delivered to inboxes everywhere. My view is that it rarely works that way, regardless of software vendors’ claims.

The way these things do work is along the lines of…

Ooops! Look at that. Out of pixel ink for this week. Tune in next week for the thrilling conclusion of Beware the Turnkey Solution.

[i] Retrieved from https://www.investopedia.com/terms/t/turnkey_solution.asp on June 12, 2022, 12:05 MDT.

[ii] Ibid.

“Management also involves the integrating process whereby human resources work together in harmony to achieve the firm’s objective.”[i]

When I performed an internet search on the question “Is management a process?”, I received over 15 billion hits in less than one second, including a link to an article that contained the quote above. While a precise definition of the word management is somewhat elusive, the overwhelming majority of experts considers it to be a process, as well as a discipline and a science. While I don’t have any real heartburn with such definitions, they do raise the question: Is Project Management a contradiction in terms, an oxymoron, like clearly misunderstood, black light, or country classic? And, if that is the case, then what does that say about the massive management science codex that serves as the foundation for almost every business school in existence?

GTIM Nation knows of my predilection for tearing into the old management saw that the point of all management is to “maximize shareholder wealth,” but that’s just one of many of the ossified business world rules that work against PM. Re-read the first sentence. Note how the source asserts that, definitionally, management seeks to have “human resources work together in harmony to achieve the firm’s objective.”[ii] There are two things I want to point out here: to engage is just a little bit of hyperbole, PMs generally don’t care about the level of “harmony” in the organization, as long as the project’s scope is being accomplished on-time, on-budget. Certainly, if inter-Project Team relations go south, thereby threatening project success, all but the worst PMs will act to correct. But to stress my point, consider whether an excellent Project Manager, given the choice between successful project completion but with the Team at each other’s throats, or having the project crash and burn while everyone got along swimmingly, would such a one really choose the latter? The second part of the quotation that raised alarm bells (for me, anyway) was the bit about achieving the “firm’s objective.” What if the firm’s objective entails displaying behavior that’s neutral to, or even working against, project success? After all, by definition Project Management seeks to deliver the customers’ expectations of scope, cost, and schedule – not the “firm’s.” No Request for Proposal (RFP) ever stated the expectation that the contractor’s objectives be attained, or even pursued.

Also consider two culinary-themed clichés, “Too many cooks spoil the broth” and “The proof of the pudding is in the eating” (and anybody who misstates the latter as “the proof is in the pudding” should never be taken seriously). Obviously, these two axioms were meant to convey insights beyond the confines of a kitchen. A short-and-sweet paraphrasing would be “the outcome of an effort is all that matters,” with a bit lengthier one being “an over-emphasis on the process in an endeavor is likely to ruin its final results.” But if management truly is a process, and the millions upon millions of books, articles, presentations, and, yes, blogs devoted to its non-PM-specific attributes represent an excessive concentration on that process, doesn’t that mean that the final outcome is in danger, if not already ruined?

And, as if all of the preceding wasn’t bad enough, you also have the problems with the endless variability of process, with very little variability when we’re discussing output, the basis of the PM codex. Again, by definition a well-written scope baseline leaves very little (or no) doubt as to the objectives being sought by the contractor on behalf of the customer. Size, weight, function, reliability standards, cost, schedule – the ways of quantifying the expected project deliverable(s) are multitudinous. But process is almost endlessly variable, as reflected in another axiom “there’s more than one way to skin a cat.” It’s the reason James Bond is famous for stipulating that his favorite cocktail, the martini, be “shaken, not stirred.” Everybody involved in his placing the order for this libation knows what a martini is. He’s specifying a part of the process to get what he wants, since there are over 30 ways to mix the cocktail.[iii]

Based on this analysis, “Project Management” is clearly an oxymoron, but if AND ONLY IF it’s being evaluated in terms of the traditional business models that have become so rigid and unassailable over the centuries. As long as we’re focused on the products, services, and outcomes of our work, PM’s precepts are golden. The moment we lose that focal point, it all becomes foolish wisdom.

[i] Retrieved from https://www.managementstudyhq.com/management-process.html on June 4, 2022, 20:49 MDT.

[ii] Ibid.

[iii] At least according to https://www.thespruceeats.com/martini-recipe-collection-4051778, retrieved on June 6, 2022, 18:47 MDT.