Game Theory in Management

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.

A PM take on the classic Hans Christian Andersen story, with apologies to Hans Christian Andersen himself, his descendants, the Danish literary tradition, and the entire nation of Denmark, among others.

Many years ago, there was a new PMO Director, who was so excessively fond of cutting-edge PM tools, that he spent most of his budget on them. He did not trouble himself in the least about his schedulers; nor did he care to go either to the project reviews or the Baseline Change Control Board meetings, except for the opportunities then afforded him for displaying the reports from his latest PM-related software package. He had a different performance assessment technique for each project within the portfolio; and as of any other PMO executive, one is accustomed to say, "he is in meetings," it was always said of him, "The PMO Director is testing a new software."

Time passed merrily in the PMO; contractors arrived every day at the office. One day, two rogues, calling themselves consultants, made their appearance. They gave out that they knew how to create a comprehensive enterprise-wide Management Information System (MIS) of the most insightful nature and elaborate complexity, the status reports manufactured from which should have the wonderful property of generating output too complex to everyone who was unfit for the office he held, or who was extraordinarily simple in character.

"This must, indeed, be a splendid enterprise system!" thought the PMO Director. "Had I such information streams, I might at once find out which PMs in my Team are unfit for their office, and also be able to distinguish the wise from the foolish! This information must be generated for me immediately." And he caused large sums of money to be given to both the consultants in order that they might begin their work directly.

So the two consultants set up two desktop computers, and affected to work very busily, though in reality they did nothing at all. They asked for the odds of activities incurring unexpected events, and cost and duration estimates of those things actually occurring. These they put into their own spreadsheets; and then continued their pretended work at the desktop computers until late at night.

"I should like to know how the consultants are getting on with my enterprise system," said the PMO Director to himself, after some little time had elapsed; he was, however, rather embarrassed, when he remembered that a simpleton, or one unfit for his office, would be unable to understand the output. To be sure, he thought he had nothing to risk in his own person; but yet, he would prefer sending somebody else, to bring him intelligence about the consultants, and their work, before he troubled himself in the affair. All the people throughout the organization had heard of the wonderful property the MIS was to possess; and all were anxious to learn how wise, or how ignorant, their coworkers might prove to be.

"I will send my faithful old Quality Manager to the consultants," said the PMO Director at last, after some deliberation, "he will be best able to see how insightful the information is; for he is a man of sense, and no one can be more suitable for his office than he is."

So the faithful old Quality Manager went into the hall, where the knaves were working with all their might, at their nonsensical spreadsheets. "What can be the meaning of this?" thought the old man, opening his eyes very wide. "I cannot discover the least bit of relevant information in these reports." However, he did not express his thoughts aloud.

The impostors requested him very courteously to be so good as to review additional reports; and then asked him whether the data actually informed him, and whether the processing techniques were not very sophisticated; at the same time pointing to the incomprehensible screen shots. The poor old Quality Manager looked and looked, he could not discover anything insightful, for a very good reason, viz: there was none there. "What!" thought he again. "Is it possible that I am a simpleton? I have never thought so myself; and no one must know it now if I am so. Can it be, that I am unfit for my office? No, that must not be said either. I will never confess that I could not see the importance of the information in the reports."

"Well, Sir Minister!" said one of the knaves, still pretending to work. "You do not say whether the reports please you."

"Oh, they are excellent!" replied the old minister, looking at the computer displays through his spectacles. "This format, and the contingencies, yes, I will tell the PMO Director without delay, how very informative I think them."

"We shall be much obliged to you," said the consultants, and then they named the different analyses and described the insights of the reports. The old minister listened attentively to their words, in order that he might repeat them to the PMO Director; and then the knaves asked for more budget, saying that it was necessary to complete what they had begun. However, they put all that was given them into their bank accounts; and continued to work with as much apparent diligence as before at their desktop computers.

The whole organization was talking of the splendid MIS which the PMO Director had ordered to be generated at his own overhead budget’s expense.

And now the PMO director himself wished to see the costly information system, while it was still in development. Accompanied by a select number of experts, he went to the crafty consultants, who, as soon as they were aware of the Director’s approach, went on working more diligently than ever; although they still did not pass a single data point through a legitimate processing step.

"Is not the work absolutely magnificent?" said the Quality Manager, already mentioned. "If you will only be pleased to look at it! What a splendid report! What amazing insights!" and at the same time he pointed to the confusing computer screens; for they imagined that everyone else could understand this exquisite piece of analysis.

"How is this?" said the Director to himself. "This means nothing! This is indeed a terrible affair! Am I a simpleton, or am I unfit to be a PMO Director? That would be the worst thing that could happen--Oh! the output is astute," said he, aloud. "It has my complete approbation." And he smiled most graciously, and looked closely at the summary lines; for on no account would he say that he could not understand what the Quality Manager had praised so much. All his retinue now strained their eyes, hoping to discover something relevant in the reports, but they could see no more than the others; nevertheless, they all exclaimed, "Oh, how profound!" and advised the Director to have regular reports published from this sophisticated analysis technique, for the approaching Independent Project Review. "Brilliant! Comprehensive! Complete!" resounded on all sides; and everyone was uncommonly gay. The Director shared in the general satisfaction; and presented the consultants with the maximum award fee.

The rogues sat up the whole of the night before the day on which the IPR was to take place, and had sixteen lights burning, so that everyone might see how anxious they were to finish the final draft of the enterprise’s performance reports. They pretended to crunch the numbers; sorted and filtered data; and pushed it into colorful graphs and charts. "See!" cried they, at last. "The Director’s new reports are ready!"

And now the Director, with all the senior managers in the PMO, came to the consultants; and the rogues gave him binders of charts and tables, as if in the act of completing a deliverable, saying, "Here are your reports! Here is the backup data! Here are the guidance references! The whole binder is comprehensive; one might fancy one summary sheet explained it all, when presenting it; that, however, is the great virtue of this analysis technique."

"Yes indeed!" said all the senior managers, although not one of them could understand anything of this data processing method.

"If you will be pleased to take this binder – and this binder alone – into the IPR, you will be triumphant."

The Director was accordingly relieved of the other presentation materials, and the rogues gave him several copies of the binder, along with some overhead slides.

"How intelligent you look with these new reports, and how accurately they describe the portfolio’s status!" everyone cried out. "What an analysis! What insight! These are indeed advanced reports!"

So now the Director walked into the conference room where the IPR was being held; and all the participants standing by, and those attending virtually, cried out, "Oh! How smart are our Director's new reports! How comprehensive and visionary!" in short, no one would allow that he could not understand these much-admired reports; because, in doing so, he would have declared himself either a simpleton or unfit for his office. Certainly, none of the Director’s various performance analyzers had ever made so great an impression, as these incomprehensible ones.

"But the Director has nothing relevant at all to report!" said a student intern.

"Listen to the voice of innocence!" exclaimed his Line Manager; and what the intern had said was whispered from one to another.

"But he has nothing relevant at all to report!" at last cried out all the reviewers. The Director was vexed, for he knew that the reviewers were right; but he thought the IPR must go on now! And the managers of the PMO took greater pains than ever, to appear to be actually managing the portfolio, although, in reality, they had no idea what was going on with it.

In last week’s blog I discussed environments where Project Teams were compelled to implement various aspects of PM, specifically Earned Value Management Systems, to an exacting standard. These systems, when properly functioning, provide an unparalleled view into the projects’ cost and schedule performance, critical information for both the customer needing to know when the project will wrap up, and at what cost, as well as the contractor seeking to meet those established goals. Project portfolios that consistently (and measurably) perform well will generally attract return business as well as new customers in that particular industry. Poor cost or schedule performance, well, doesn’t.

However, everyone current in the PM industry is well aware that the standards for “doing” Project Management have expanded, sometimes in valid ways, sometimes not. When I attend paper presentations that demonstrate more reliable ways of integrating the time-phased budget as computed by the Critical Path Methodology software package into the platform that processes Actual Costs and Earned Value, I come away believing that such time is well-spent. Conversely, if I’m somehow trapped in a presentation that goes on and on about the “need” to perform Monte Carlo analyses on projects in order to create a risk management plan (no initial caps), I begin to attempt a calculation of the conference center’s ballroom area by counting ceiling tiles, estimating their length and width (thank goodness most of them are perfect squares!), and wondering how much energy would be needed for them to start to fall down into the room, leading to an impromptu evacuation, and testing if I could summon enough of The Force, Count Duku-style, to make that happen.

So, if we’re being Forced (get it?) to “do” PM to a certain level of robustness, what does that entail, exactly? When attempting to answer this question, I think it’s important to keep in mind that common PM-related techniques, such as EVM- or CPM-based reporting systems are components of an overarching business model, whether they are perceived as such or not. Combining these components into a business model without a pre-planned structure is a sure way to drive the organization’s PMO into the ground. For example, Communications specialists will often advise the PMO to include all “stakeholders” in their Project-oriented communications, expanding the list of people who should receive, say, cost/schedule performance reports. If, by integrating the whole engage-all-stakeholders technique into the business model results in, say, competing organizations having access to monthly Variance Analysis Reports (VARs), then such an integration is clearly working against the overall mission of the PMO as well as its owning organization. Why bother to perform competitor/opposition research when their own Communications Managers tell you all about their performance issues?

GTIM Nation is aware of my predilection for basing a nominal PMO’s business model on the axiom Quality, Availability, Affordability – pick any two, and the folly of attempting to deliver all three. I believe that this axiom points to the fact that many business strategies are very capable of conflicting with others, no matter how attractive they appear in isolation. For example, who could possibly be against quality? Or, more specifically, which PMO Director could withstand the charge of allowing a sub-standard system to be implemented for a given portfolio? But that’s the thing – “sub-standard” according to whom? In an organizational environment where there are no external customers demanding strict compliance with overwrought procedures, with multiple small projects in need of just a simple cost/schedule control system, to pursue a supposed high-quality, universally-applied PM information system is not only doomed to fail, it’s actually akin to managerial malpractice.

Which leads me back to another one of Hatfield’s Management Axioms, that managerial leadership is predicated on three central attributes:

• Genuinely caring about the people on your Team. If you don’t care about them, they will tend to not care about you, or your technical agenda.
• Identifying the optimal (or at least workable) technical agenda. Teams hate having to proverbially bark up the wrong tree.
• A demonstrable passion to execute that technical agenda, alone if necessary. A “leader” positioning himself to bail on the scope is apparent to all.

While all three are key to success, in this blog I want to address the second one, identifying the optimal technical approach. One of the definitions of intelligence that I’ve come across is the ability to address novel situations and reach a desired outcome by recognizing similarities in previously-encountered circumstances, and making appropriate similar or adjusted choices. When it comes to PMOs attempting to compel an advancement in Project Management maturity, a real danger arises if that “advancement” isn’t based on the best technical approach for the circumstance. Such an approach has to not only further the PM capability, but flange up nicely with the macro-organization’s existing business model.

Otherwise your implementation strategy is likely to be reduced to waving your fingers in a clockwise direction, and saying “You will collect percent complete data at the reporting level of the WBS.”

In the mid-1960s, the concept of introducing an Earned Value Management System (EVMS) for the proper management of United States Air Force projects was enacted through an approach known as the Cost/Schedule Control System Criteria, or C/SCSC, sometimes referred to as “the C-Spec.”[i] Soon this canned approach to generating and maintaining the information streams that would keep customers apprised of the performance of the projects within their purview expanded to the other branches of the U.S. Department of Defense, then on to the new Department of Energy, and somewhat unevenly to other U.S. Government organizations. While other project-oriented industries had been using various aspects of EV and Critical Path Methodology to manage their work for some time, the efforts to collect and structure these techniques into a single codex really got their start here, through MIL-STD-881A, DOD Instruction 5002, among others[ii]. PMI® itself began in 1969, with standardization efforts making up 10 – 15% of its work.[iii] The first edition of the PMBOK Guide® was published in 1996, representing the first major academic or institutional effort at collecting and codifying the techniques across all industries that we now recognize as germane to Project Management.

But here’s where things get a bit cattywampus. For hundreds of millions of dollars’ worth of United States Government contracts, demonstrably complying with the nascent C/SCSC was (and still is) a condition of doing business. It was essentially a waste of time to bid on one of these proposals if your organization wasn’t capable in what would be considered today as a fairly basic EVMS. It was a Boolean metric: either “do” Earned Value Management in a specific manner, or you can’t get the project award. In this respect, it was very much like the “implementation strategy” that accountants used: since no organization can conduct business without paying taxes, and taxes can only be assessed based on information within the general ledger, it was a their-way-or-the-highway situation. Back on the PM side, those seeking to embrace such business model characteristics as developing Work Breakdown Structures, or Responsibility/Accountability Matrices (RAMs), or Work Packages that roll up to Control Accounts, or collecting percent complete data, or aligning the General Ledger with the WBS, etc., etc., really didn’t have to develop an implementation strategy per se. They only needed to arrange to train we PM-types in those techniques and outputs, and set us loose on the projects. The mere threat of having your DoD customer label you with a “C/SCSC Non-compliant” charge was more than enough to, for example, get our friends, the accountants, on-board with aligning the chart of accounts with these projects’ WBSs.

Just A Little Bit More History…

Beginning in the late 1980s, various guidance-generating organizations began to loosen the requirements of the C-Spec, often invoking the assertion that “low risk” projects really didn’t need the level of cost/schedule performance measurement system robustness that high-value, “high risk” work did. The drip of organizations claiming to be exempt from the Earned Value and Critical Path Management specifications on those grounds became a torrent. Even extremely high-value, cutting-edge technology projects would assert Earned Value Management Systems to be inappropriate, with entirely predictable results: overruns and schedule delays.[iv] Once tried-and-true cost and schedule performance measurement systems were no longer required as a condition of doing business, project “managers” would often opt to “control” their costs by merely watching their actuals go by. And by “go by,” I mean escalate quickly into out-of-control status.

This effect coincided with that point in my career when I started attending PMI® Congresses and other PM-themed seminars, and I noticed an interesting trend: common to most of the sessions I attended was this underlying notion that, if the PM practitioner wasn’t performing the types of analyses that the speaker was presenting, well, that person wasn’t doing PM “right.” I nicknamed this argument eat-your-peas-style hectoring. Simply putting out there the assertion that the absence of robust EVM or CPM systems represents a transgression from what the PM zeitgeist demands in no way makes up for a singular lack of persuasion-based implementation strategies. The whole argument can be boiled down to “if your organization isn’t compelled to do PM right, and doesn’t do it anyway, then they’re a bunch of dolts,” and I, for one, don’t find that particularly compelling.

There are, of course, many valid and compelling reasons why significant aspects of project-oriented organizations’ business models should incorporate the PM techniques with which we’re all familiar. But I believe that the reason they haven’t been addressed broadly can be attributed to the fact that PM implementation used to be mandatory, a condition of doing business. That’s no longer the case in many situations.

And it shows.

[i] Retrieved from https://www.humphreys-assoc.com/evms/basic-concepts-earned-value-management-evm-ta-a-74.html on May 4, 2022, at 18:08 MDT.

[ii] Retrieved from https://www.pmi.org/learning/library/articles-cost-schedule-control-system-5454.

[iii] Wikipedia contributors. (2022, March 14). Project Management Institute. In Wikipedia, The Free Encyclopedia. Retrieved 00:17, May 5, 2022, from https://en.wikipedia.org/w/index.php?title=Project_Management_Institute&oldid=1077175134

[iv] Probably the worst offenders in this category – Information Technology projects – are notorious for both eschewing EVM, and having an absolutely abysmal record when it comes to overruns and delays.