Game Theory in Management

Modelling Business Decisions and their Consequences

About this Blog


Recent Posts

What Is Santa Claus Bringing Your PMO?

For Project Managers, Philanthropy Begins At Home

Getting Tired Of Playing The Role Of Cassandra?

Business Analysis: It’s All About Whom You Believe

Refusing to Accept Zuzu’s Missing Petals

Mary Sue Saves The Project… Again

I know, I know, I’ve written quite a bit about how certain science fiction franchises, specifically Star Wars and Star Trek, appear to have some parallels with the Project Management universe, but this particular parallel is so strong that I can’t resist connecting the dots. Some fans of Star Trek: The Original Series began writing stories around the characters and settings of that television series since its cancellation in 1969 (if not before), and many of these stories made their way into “zines” (short for “magazines,” zines are amateur-published/posted periodicals). Unfortunately, most (if not the vast majority) of these contributors weren’t professional writers, or even particularly gifted amateurs, and it reflected in their prose in a variety of ways (poor character development, lack of respect for the pre-existing canon, wretched plot structure). One particular writing pathology that became noticeable as a trend was the introduction of extraordinarily young and talented characters whose exceptionalism strained credulity. Usually female, these characters came to be seen as little more than the authors’ projection of an idealized version of themselves into the Star Trek canon, and gained the nickname “Mary Sue.”[i]

Mary Sues tend to have the following characteristics in common:

  • They are young (often “the youngest to ever graduate Star Fleet Academy”),
  • attractive females, usually with some striking or unusual feature, like violet eyes or blazing red hair.
  • They have some sort of pre-existing relationship with one of the three main ST:TOS characters (Kirk, Spock, McCoy),
  • and are capable in the extreme, in their scholastic achievement, martial arts prowess, or technical insights.

While the existence of Mary Sues in a given story would invariably render that narrative less believable and the plot, well, amateurish, their preponderance actually led to a backlash due to the perceived damage they were doing to the existing Star Trek canon, challenging previously-accepted tenets of who the already-established characters were, and how they interacted with each other and their fictionalized, futuristic world.

Meanwhile, Back In The Project Management World…

I’ve noticed that the fare in PM-themed periodicals and seminars can be largely categorized in one of three ways:

  • genuine advancements in management science (which are golden but not as common as they should be),
  • yet another re-telling of the basics, almost always of Earned Value Management techniques, but also including Critical Path Methodology, scope management, or risk analysis,
  • a story about how a particular project was ground-breaking, high-profile, technically advanced, and, of course, completed successfully.

It’s this last category that tended to bore me the most, until I realized we in the Project Management world were experiencing our own version of the Mary Sue effect in Star Trek fan literature. Then this type of story moved from the merely boring and into the realm of positively irksome, and thence on to potentially damaging to the existing PM canon.

Think about it: when was the last time you read or saw any kind of presentation that detailed exactly how and why a project disaster occurred, and who specifically was to blame? I never have. In fact, I’ve attended a presentation (at a project management-themed conference, no less) that discussed one of the largest overrun and delayed projects in history, and the presenter only wanted to talk about how swell the concepts of Earned Value and Critical Path were.

Conversely, in presentations that address notable successful projects, it seems that many people were solely responsible for its victories, particularly the presenter. Could it be that we have our very own version of the Mary Sue effect in play? Consider the following table:

Mary Sue Characteristics

Specific Project-Themed Presentation

Young, but advanced

Project team is new to the technology, but very talented

Has some striking or unusual feature

Project takes place in an exotic location, or is profoundly unlike other projects in its genre

Has a pre-existing relationship with one of the three main TOS characters

Develops a profoundly unique relationship with the customer

Is capable in the extreme

Overcomes the project’s difficulties, which would have meant ruin for any other project team, don’t you know

In Star Trek fan literature, the backlash against stories that contain Mary Sues has become so widespread that many authors that indulge in that genre will avoid introducing any female character, for fear of having such an introduction tagged with the “Mary Sue” label, and automatically repelling potential consumers of the work. While this may be a bit extreme, it was, nevertheless, probably necessary to ensure that this particularly cheesy character device be avoided in the future. Similarly, I would be happy to initiate an analogous backlash against those specific-project presentations that employ a similar device to the Mary Sue. They don’t advance project management science much, if at all, while providing an avenue for the project teams’ (or individual presenters’) own aggrandizement.

And that, my friends, strains credulity, and ultimately damages the pre-existing canon. Particularly if said presenter has violet eyes, or blazing red hair.


[i] Retrieved from, 17 December 2017, 10:40 MST.

Posted on: December 18, 2017 10:34 PM | Permalink | Comments (8)

I Suppose That Depends On Your Definition Of Success

In the 1972 Olympics Men’s Basketball final, the team from the U.S.S.R. was awarded the victory by the officials, even though they did not legitimately win the ball game. With three seconds left in the game, and with the U.S.A. team leading 50-49, the Soviets needed three different rulings from the referees to score the winning goal, to wit:

  • The clock ran out due to the Soviets mis-handling the communications to indicate if and when they wanted a time out, so the referees put three seconds back.
  • Even if they had appropriately requested and received a time out, they would not have been able to substitute players, or take the time needed to strategize on a play, both of which were allowed to happen.
  • After in-bounding once, and exhausting the remaining three seconds without scoring, they were given another three seconds and another opportunity, since the clock hadn’t been properly reset.

There were other irregularities, any of which would have also prevented the gold medals from going to the Soviets (including blatantly improper interference in an on-going game by Renato Jones, secretary general of the FIBA at the time), but you see the point. The only way that the Soviets could be considered successful is if it’s okay to change the rules in the middle of the game. And, just for the record, a sure sign that either the game is rigged or the authorities aren’t really experts is that the rules keep changing.

A few months back I was blogging about how some PM aficionados, whom I named “processors,” were more concerned that what they saw as correct, proper procedures should be followed during project execution than whether or not the project itself was successful. Their (sane) counterparts, who were more concerned with actual project performance, I dubbed “producers,” and complained about how the processors were doing little more than making the producers’ professional life more difficult.

I stressed in last week’s blog that the oft-overlooked, but obvious central point about Project Management is that the projects’ scope needs to actually be executed, the best way the project team knows how. In short, the “rules” for the producers can be reduced to two: (1) finish the project on-time, and (2) on-budget. These two rules do not change in the world of the producers. Conversely, the processors seem to change the rules all the time. They do so in the cavalcade of presentations, webinars, and guidance documents being generated -- and I stand by my assertion about what's going on when the rules seem to be constantly changing.

I have made pointed criticisms of Tom Peters’ work, but I have to hand it to him: his approach on In Search of Excellence was insightful and inspired. Rather than sit around his University office and speculate how organizations could improve performance based on abstract data or theories, he sought out high-performing organizations, and asked them what they were doing differently from their competitors. He was rewarded with a best-selling book, as he should have been. This is much, much closer to performing real management science than most (if not all) of what the processors do, in that Peters observed which organizations were verifiably performing better than their competitors, and then sought out the dependent variables. Compare and contrast this to, say, the communications managers (yes, the risk guys are an easier target here, but I pick on them so regularly I thought, just this week, I’d give them a break). When was the last time you heard a seminar paper, or webinar, presented by the communications specialists, where they did something similar to what Tom Peters did, i.e., seek out success, and interview those associated with it how they did it? I never have. Rather, it seems they are always prattling on about how, by following their rules for proper PM (recently updated, don’t you know), which requires performing the kinds of analyses and techniques they promote, you are “doing” PM “correctly.” In reality, the best they could hope to do in real PM space is to assert that a preponderance of projects that do perform their techniques come in on-time and on-budget, but even here they would have an almost impossible task of establishing the communications program as the proximate cause, or even a material cause of the project’s success. None of them would ever say that their project came in on-time, on-budget due solely to their enhanced communications plan. It just never seems to work out that way.

Unless, of course, you are attempting to assert that the reason for your blatant lack of success is because the scorer’s table failed to recognize your communicated desire for a time out in the final seconds of an Olympic championship game. In that case, you just might get away with it.

Posted on: December 11, 2017 10:08 PM | Permalink | Comments (9)

The Flying Buttresses of Success

According to a history of architecture website named, in the twelfth century

Somebody (nobody knows who) invented the flying buttress. Instead of the buttress being stuck to the side of the building, it would form an arch leading away from the building.

The flying buttress would start from the places at the top of the wall where the groin vaults were directing the weight of the roof. From there, the flying buttresses would carry the weight of the roof away from the building and down a column of stone to the ground. It wouldn’t matter what the walls were made of anymore, because they wouldn’t be carrying the weight of the roof.[i]

Other examples of flying buttresses in building interiors appear as an unsupported column top, with its load-bearing utility not being intuitively obvious. Essentially, the flying buttress allowed the weight of the structure to be diverted away from the walls.

Another act of diversion, this one pertaining to human behavior, has to do with the oft-used cliché, that success has many parents, but failure is an orphan. I know when I hear that phrase cited my first notion of its meaning has to do with a somewhat jaded view of human nature, that we’re imminently susceptible to crafting or altering a narrative to make ourselves appear to be a vital part of a winning team, but hardly involved at all if the same (in this case, project) team crashes and burns.

But taken together with another axiom, this one a quote from Charles Kettering, “99 percent of success is built on failure,”[ii] and a larger insight emerges. It goes without saying that, if we don’t own our mistakes, we never learn from them. But what happens when we glom on to successes where we did not provide the material cause, much less the proximate cause, of the favorable outcome? I think we see this very outcome on-display at so many PM-themed conferences, seminars, podcasts and guidance documents, that of attribution of success to some very questionable management science hypotheses.

Meanwhile, Back In The Project Management World…

Take, for example, the practice of time-phasing an Estimate to Complete (ETC). This rather silly practice has the full-throated approval of that guidance-generating-organization-that-must-not-be-named. It assumes several premises, including:

  • The ETC is derived from re-estimating remaining work (on a line-item level, no less) on an already-started project, instead of using the simple, accurate formula ETC = Estimate at Completion (EAC) – cumulative actuals;
  • Useful or relevant information can be gleaned from comparing budgets to actuals, and
  • Staffing decisions are based on differences between budgets and actual costs, rather than the nature of the remaining scope on the project.

These assumptions are suspect at best, and completely fraudulent at worst, being, as they are, poorly (or completely un-) supported by repeatable observations in a setting that would allow isolation of the dependent variables upon which the assertion depends. In other words, there is absolutely no evidence, not even a single instance, of a project owing its success to its ability to time-phase its ETC. These assertions are simply arrived at by a bunch of self-anointed experts, who publish their findings opinions with vague but impassioned support phrases such as “Doing X is key to project success.”  Really? Can we see the data that supports that assertion? Even a single example of how X is “key” to a specific project’s success?

And the time-phased ETC example is but one of many. Enhanced analysis techniques in risk management, communications management, quality management … the list goes on and on, with no hard data supporting the assertions, but with the ubiquitous “…is necessary (or “key,” “essential,” or “central”) to project success” contained in a nearby paragraph. It’s maddening, really.

Here’s the painfully-obvious-to-the-most-casual-observer essential element of project success: execute the scope. All of the analysis techniques inherent in Project Management have the singular function of reflecting the project teams’ performance as they execute the scope. Some of those analysis techniques are truly “key,” with Earned Value and Critical Path methodologies popping to mind. But many of these others are not, and not only that, they actually divert time and energy away from that load-bearing component of project success, executing the scope. And, to that end, they represent the very opposite of the things that are “essential” to project success.

I kind of like comparing those pushing these unsupported and unsupportable assertions about what is “key” to project success to flying buttresses. It sounds like I’m calling them a juvenile and semi-profane name, when I am, in fact, referring to them as an architectural feature. So, it is in that spirit that I can say to these “experts,” metaphorically speaking, of course, and sincerely: stop being flying buttresses.






[i] Retrieved from on December 3, 2017, 9:55 MST.

[ii] Retrieved from on December 3, 2017, 8:12 MST.

Posted on: December 04, 2017 10:32 PM | Permalink | Comments (9)

What Government PMs Really Do Not Want

A basic characteristic of Project Management which is often given short-shrift is the aspect of being particularly applicable to unique work. By definition, projects are unique, and have a definitive beginning and end, which occurs when the documented scope has been attained to the customers’ satisfaction. But new software, buildings, and devices are being created all the time, right? And, in most cases, these projects deliver an improvement or advancement over the thousands of software packages, buildings, and devices already in existence, while still sharing many (if not most) of their predecessors’ characteristics. So, yeah, the project is unique in many ways, but it’s also very much like hundreds, if not thousands, of projects that went before, which is where the performance goals of such work tend to be derived. And this is where a lot of government PMs get really frustrated.

Consider some of history’s greatest and truly unique projects, like the Manhattan Project, or the Apollo space missions. Yes, bombs, and rockets that could carry people into space, already existed, but these were different. No explosive had ever harnessed the power of the atom, and no space vehicle had ever come close to allowing an occupant to step foot on another heavenly body. Past the attainment of the primary scope, what could be used to evaluate these projects’ performance?

The unfortunate tendency here is for those outside the PM structure to invoke performance parameters from the asset managers’ realm, i.e., the accountants, with the Return on Investment (ROI) being prime. There is a rather funny story about a time when Manhattan Project scientists were creating a device that needed large amounts of copper, then in short supply due to the war effort. However, silver had similar electrical characteristics, so the scientists asked Undersecretary of the Treasury Daniel W. Bell for 6,000 tons of silver bullion. Bell responded “Young man, you may think of silver in tons, but the Treasury will always think of silver in troy ounces!”[i] A quick calculation later, and the request was amended to 430,000,000 troy ounces of silver, whereupon it was granted.

Now, put yourself in the shoes of a government oversight manager. Could you even begin to calculate the ROI of 6,000 tons of silver being diverted to industrial purposes? Even if you had the security clearance to know the precise nature of the science behind the request, it would be quite impossible to capture the value of contributing to the radical altering of the balance of geopolitical power that would result from the successful development of atomic weapons.

Something similar happened within the Apollo Program. Pushing mass into outer space is very expensive, and the need to miniaturize and lighten the electronics needed to reach the moon became a priority. The solution came in the form of the integrated circuit. As put by Sharon Gaudin at the Computerworld website,

The development of that integrated circuit, the forbearer to the microchip, basically is a miniaturized electronic circuit that did away with the manual assembly of separate transistors and capacitors. Revolutionizing electronics, used in nearly all electronic equipment today. While Robert Noyce, co-founder of Fairchild Semiconductor and then Intel Corp. is credited with co-founding the microchip, Jack Kilby of Texas Instruments demonstrated the first working integrated circuit that was built for the U.S. Department of Defense and NASA.[ii]

The total cost of the Apollo Program was reported to the United States Congress in 1973 at $24.5B (USD). Since integrated circuits, and their progeny the microchip, are used in virtually all computers today, what can be said of their ultimate “value”? Microsoft is worth $483B[iii], Google is worth $101.8B[iv], and Amazon is worth $430B[v], and these are just three examples of prominent computer-based enterprises. None of these organizations would be in existence if not for widespread use of personal computers, personal computers which would not be in existence if not for the technology that brought us integrated circuits and microchips. The government program to put a man on the moon in the 1960s would radically alter the world’s economies, to the point that the United States’ $24.5B investment—as hefty as it must have been perceived in 1973 – has to be seen as comically small in terms of the economic benefits it eventually wrought. Just the three companies cited above represent a 745% return, adjusted for inflation. But just 10 years after Apollo 11 landed on the moon, a Gallup survey indicated that only 41% of Americans thought the benefit of landing on the moon outweighed its cost.[vi] Really.

So, what is it that government PMs really do not want? They don’t want their truly unique projects’ performance to be evaluated unfairly. All things fail by irrelevant comparisons, and newly discovered technologies, by definition, are, at least to some degree, incomparable.

If nothing else, can we at least stop pretending that the Return on Investment figure has a place in evaluating project performance?

[i] Manhattan Project. (2017, November 20). In Wikipedia, The Free Encyclopedia. Retrieved 04:46, November 26, 2017, from

[ii] Retrieved from, 20:05 MST, 25 November 2017.

[iii] Retrieved from, 20:12 MST 5 November 2017

[iv] Retrieved from, 20:14 MST, 25 November 2017

[v] Retrieved from, 20:17 MST 25 November 2017.

[vi] Retrieved from, 18:19 MST, 26 November 2017.

Posted on: November 27, 2017 09:20 PM | Permalink | Comments (3)

What Government/Contractor PMs Really Want

I think that there’s a major management science issue inherent in managing projects for the government – any government – but I have never seen it addressed in the PM periodicals. It has to do with the nature of the real customer, and how far removed they are from the actual transaction(s). I’ll explain by way of example.

If I decide I want to buy a product or a service, I’ll do some research on the desired good or service, and will generally do more research as the anticipated price goes up. By the time I initiate the actual transaction, I’m spending my own money – based on how much I have budgeted (or can afford), balanced against the level of quality or capability I have determined best for my uses. In this scenario, waste is minimized – I have set the budget, and I have determined the parameters for a successful acquisition, so I’m in a position to let the competition among suppliers determine the best price for my target. This kind of purchase is known as a first-party transaction.

In those instances where I am spending my own money, but for someone else’s benefit (gift-giving, for example), the price is still important to me, but I’m a little less concerned about the “perfect fit” aspect of the transaction. In those cases where I’m buying a gift for a family member who has been very specific about what they want, I do my best to accommodate them, assuming their very specific request fits within my budget. Similarly, if I am the recipient of a product or service that I'm not paying for (like being given a gift), then I’m keenly interested in the quality of the product or service, but a bit less concerned about its price. These are known as second-party transactions, and they have an increased opportunity for waste or abuse since the spending versus expected quality parameters are not as precisely aligned as in first-person transactions.

Finally, in those instances where I’m neither the person paying for the product or service, nor the recipient or consumer, the opportunities for waste or abuse are magnified further due to the additional mis-alignment of an exact budget figure versus a clear picture of the precise nature of what is to be delivered. These are known as third-party transactions. Much of what most Western industrialized governments spend their money on falls in this category, as in government-furnished food, housing, or health care, and, predictably enough, much fraud, waste, and abuse is present in such programs.

Meanwhile, back in the project management world…

For managers in charge of government projects, such transactions tend to fall into the second-party category. Our government customers don’t actually pay for the projects out of their own pockets (“Do you have any idea how many points I get if I pay for that aircraft carrier using my Discover Card?”), but instead act as representatives for the actual buyers, those citizens who pay taxes. They can be counted on to become highly adversarial if the project looks like it’s going to bust its approved budget, but will usually be okay with the cost as long as that does not happen. Generally speaking, the customer will not be the actual person using or consuming the final product or service, but they are typically very closely related to those who do, and can be counted on to be extremely interested in the quality of the product. So, if the cost doesn’t mean as much as the delivered product, what can we expect our government customers to demand from their project managers? If you said “as much quality as they can wring out of the approved budget,” go to the head of the class. Because of this effect, the management effect most often associated with government representatives or PMs is scope creep (as opposed to a pathological focus on efficiency), since they seek the best value for their (somewhat fixed) budget.

Conversely, contractor PMs are responsible for delivering a certain level of quality at a (somewhat fixed) budget, so their worries are two-fold: if they believe that the product or service being delivered is consistent with the quality standards depicted in the Statement of Work (SOW), but the customer disagrees, then a lot of churn can be expected in the execution of the project. The other issue is whether or not the project can be delivered on-time, on-budget. If it can, then everybody has a good day. But, if it can’t, the contractor PM must determine if the fault is with the efficiency or performance of the project team, or if the government PM has added scope informally, i.e. engaged in scope creep. If they have, and will admit to it, then a Baseline Change Proposal fixes the problem. But, if they have engaged in adding scope informally without owning up to it, or if the problem lies with the project team’s performance, the only available remedy is to try to tap any reserves (e.g., Management Reserve, or Contingency) that may be available. If no reserves are available, well, then everybody has a bad day.

So, here’s the central focus of optimal government project management: well-defined scope. For the government PM, poorly-defined scope could allow an unscrupulous contractor to deliver sub-standard quality, while making a strong claim to having fulfilled the vague terms of the SOW and, therefore, the whole of the available budget. From the contractor’s point of view, poorly-defined scope could allow opportunistic government PMs to informally add upgraded quality or reliability standards that the contractor hadn’t planned nor budgeted for, leading (almost automatically) to the overrun condition discussed in the previous paragraph.

It would all be much simpler if we could just give Naval Officers Discover Cards with really large limits…


Posted on: November 20, 2017 08:59 PM | Permalink | Comments (10)

"Forgive your enemies, but never forget their names."

- John F. Kennedy



Vendor Events

See all Vendor Events