Game Theory in Management

Fully participating members of GTIM Nation know that I like to make references to Star Trek (the original series [TOS], the one that aired before the insufferable introduction of deus ex machina plots ruined the rest of the franchise). There are several plastic models of the starship from that series, the Enterprise, and some of them are quite good. One in particular is large enough to feature detailed versions of the only two interior areas of the ship that are visible from the outside, the bridge (due to its being covered by a clear dome), and the shuttle bay, but only if the shuttle bay doors are open. The particular kit I’m thinking of here has a bridge so detailed that it’s possible to depict a Klingon battlecruiser on the main screen, which I think is really cool. For the whippersnapper contingent of GTIM Nation, TOS Klingons were always the bad guys, and the Enterprise ended up destroying two and severely damaging one of these types of battlecruisers (destroyed: “Errand of Mercy,” “Day of the Dove;” severely damaged: “Elaan of Troyius”).

Now let’s do a little configuration management. I do not claim to be an expert in Starfleet operations, but in none of the Enterprise’s encounters with Klingon battlecruisers are the shuttle bay doors open, which kind of makes sense. The shuttle bay has to be de-pressurized when launching or recovering shuttlecraft, and there does not appear to be an anchoring mechanism for the craft when they are stored in the bay. Given the frequency with which bridge officers are thrown out of their chairs during battle scenes, it’s easy to imagine shuttlecraft falling out the back of the ship should the bay doors remain open during combat. In short, any configuration manager worthy of the title would know that, when building this particular kit of the Enterprise, if the Klingon battlecruiser is depicted on the bridge’s main screen, then the shuttle bay doors need to be closed, and vice versa. This is, arguably, the only configuration management conflict for building this kit. And yet, at least one of the YouTube videos on completed versions of this model depict this exact configuration, which I consider to be unfortunate.

Meanwhile, Back In The Project Management World…

ProjectManagement.com’s theme for December, philanthropy, has far more relevance to PMO functionality than might be readily apparent. I am going to argue that the organization supporting the PMO, as well as the PMO itself, must be intrinsically philanthropic in order to succeed. I’ll start with a precise definition of the term. Google’s definition is “the desire to promote the welfare of others, expressed especially by the generous donation of money to good causes.”[i]  Wikipedia says “Philanthropy means the love of humanity.”[ii] I have asserted previously in this blog that managerial leadership requires three key aspects – the Leader Manager must:

• have an advanced technical capability. Few things are more frustrating to a project team than having the technical agenda set by an incompetent.
• be enthusiastic about pursuing the optimal technical approach, alone if necessary. This communicates a confidence that weather-vane managers do not have, and cannot fake.
• (Here’s where the philanthropic angle comes in) care about the people on the team. If the team perceives the Leader Manager does not particularly care about them personally, they will not be enthusiastic about advancing that manager’s technical agenda.

Since “our people are our number one asset!” has been a staple of organizations with any kind of mission statement for generations now, how can a PMO Director ascertain when such a statement is simple boilerplate façade, and not indicative of an at least minimal level of the organizational philanthropy needed for PMO success? In other words, how can the PM know if the organization is sufficiently “willing to promote the welfare of others” to enable the PMO’s mission to succeed?

While there may not be a single litmus test to differentiate such organizations, there does exist a “tell,” a clue that the macro organization is so beset with anti-philanthropic pathologies as to all but eliminate PMO success. This tell comes in the form of an often unstated but nevertheless unmistakable aspect of corporate culture: do these people believe that their employees are lucky to be part of the organization?

It’s not an idle or trivial aspect of corporate culture. If the macro organization believes that most if not all of the rank and file are truly fortunate to be working for them, then that aspect of the narrative will have devastating effects on performance. After all, if the employees are genuinely blessed to be working for so wonderful an organization, why on Earth would they ever offer up novel ways of doing business? Don’t they owe their highly serendipitous circumstances to the very people who developed those processes in the first place? Better to keep their heads down and signal conformity than risk losing their opportune environs.

While macro-organizational arrogance can be highly off-putting on a personal level, in the business realm it’s out-and-out crippling to the very innovations needed to advance virtually any capability, but particularly Project Management. Sure, people will work for them, and spend considerable time and energy in performing their jobs in such a way as to keep their superiors happy. But in those industries where innovation is crucial to not only getting ahead, but to even surviving (hint: that’s all of them) an arrogant corporate culture, the very opposite of a philanthropic one, is a clear sign that attempts at advancing a PM capability are most probably doomed. Just as one should never engage in warp-speed combat with the shuttlecraft bay doors open, you can’t have both an advanced PM capability and a corporate culture lacking in philanthropy.

We know from the TOS episode “The Doomsday Machine” that the helm of the Enterprise has an indicator of when the shuttlecraft bay doors are open or closed. While detecting the “you are all lucky to be working here!” narrative may not be as Boolean as a colorful indicator light, I would recommend that all PMO team members become adept at gauging that condition, and adjust implementation strategies accordingly.

[i] Retrieved from https://www.google.com/search?client=firefox-b-1-d&q=philanthropy on December 8, 2019, 10:49 MST.

[ii] Wikipedia contributors. (2019, December 1). Philanthropy. In Wikipedia, The Free Encyclopedia. Retrieved 17:50, December 8, 2019, from https://en.wikipedia.org/w/index.php?title=Philanthropy&oldid=928702612

(Flourish. Enter into the construction trailer conference room Shakespeare, the Royal Arts Construction Coordinator [RACC], Contractor Representative, Procurement Specialist, and Project Manager)

Shakespeare: Are we all met?

RACC: Yay, sirrah, as well we should be. Peruse you these, the Cost Performance Reports in Format One. At this rate of performance, thou wilt overrun by 40%!

Contractor Rep: Aye, m’lord, that is the calculated Estimate at Completion. But see you here, these the bottoms-up EACs, and lay aside your heart’s fury.

RACC: Zooks! The so-called “bottoms-up” EAC indicates no cost overrun whatsoever! These are great tidings, indeed!

Shakespeare: Tarry a moment, m’lord. Sirrah Contractor Representative, howst can thou maintain a zero Variance at Completion with a Cost Performance Index of 0.6? I’ve written about some fantastic scenarios, and even victories snatch’d from the certain jaws of defeat. But completing this type of project on-cost with a CPI of 0.6 when thou statest thou art more than 50% complete is too improbable to be believed!

Contractor Rep: ‘Tis part of the practice of Project Management, good my customer. I wouldst not expect the finest playwright in all the Anglosphere to understand…

Shakespeare: Try me.

Project Manager: I am made bold to interject, my lords, on this point. The calculated EAC, being, as it were, the result of mystical conjurings, and processes inconceivable, are required by the Crown for projects of a certain size, this one included. But look you upon the bottoms-up version, rightly calculated by summing all of the costs incurred heretofore, and adding them to the new estimate for the remaining work, and be reassured.

Shakespeare:  Sirrah Project Manager, I will peruse these, the documents you provided, and decide for myself whether to be reassured or alarm’d. See you these, the Variance Analysis Reports. With a cumulative CPI of 0.6, I anticipateth a doozy of an explanation, one to rival even my fictions, and thou didst not disappoint! The main causal agent of this vast negative cost variance is listed as “poor initial estimate,” is it not?

Project Manager: (reads VAR) Verily, sir, it so says.

Shakespeare: Signore Procurement Specialist, say you so?

Procurement Specialist: Aye, m’lord, the Estimators were villainous indeed.

Shakespeare: The Basis of Estimate is the amount of the resource, multiplied by its unit cost, true?

All: Of course.

Shakespeare: Then, Signore Procurement Specialist, which was incorrect? The amount, or the unit cost?

Procurement Specialist: Verily, m’lord, it was the amount.

Shakespeare: That being the case, why believest thou that the exact same process of estimating the remaining work wouldst suddenly become accurate?

RACC: Excellent point!

Project Manager: And yet, m’lord, surely this future work will be easier to predict, given that it’s only 40% of the original scope baseline.

Shakespeare: Dost thou sayest, then, that the smaller and nearer the prediction be, the more accurate it becomest?

Project Manager: Aye, verily. (Enter one playing Owen Glendower) Who be this fellow approaching, wild-eyed and flailing?

Glendower: I can call spirits from the vasty deep. (Henry IV, Act 3, Scene 1)

Shakespeare: Since we apparently must anticipate this project’s total cost at completion by using fanciful divinations rather than, say, actual performance, I thought I would invite one experienced in prophecy.

Contractor Rep: Dost thou mock us, sir?

Shakespeare: (In exaggerated nasally voice) No, I’m not mocking you.

RACC: (Trying to stifle a laugh) Surely you see his point, gentlemen. If thou maintainest that the cause of the existing massive cost overrun is a poor initial estimate, but then proceed to present a new cost estimate that not only shows that the existing overrun will be corrected, but the remaining work will be completed at substantially below the original baseline, it strains credulity. Both cannot be true. Do you want to change the VAR, or adjust your bottoms-up EAC?

Project Manager: We could probably fine-tune the EAC.

Glendower: I’ll not have it altered. (Henry IV, Act 3, Scene 1)

Shakespeare: You can stop now. You’ve made my point.

Glendower: Cousin, of many men I do not bear these crossings. (Henry IV, Act 3, Scene 1)

All: KNOCK IT OFF! (Exuent Glendower)

Shakespeare: Sirrah Project Manager, when thou sayest “fine-tune,” dost thou meanest “revise upward?”

Project Manager: Yay, verily, sir, though not as much upward as the calculated EAC.

RACC: But will you, sir, certify now that your EAC will not be surpassed?

Project Manager: Why would I do that?

RACC: Thou just said that you wouldst not revise the bottoms-up EAC as high as the calculated version. If thou hast such faith in your revised EAC, and are convinced that the calculated figure is too high, why not guarantee it? On behalf of the Crown, I am prepared to sign a new contract, for the amount of the bottoms-up EAC, on a Firm Fixed Price basis.

Contractor Rep: Good my lord, who knows what other events, unintended and unavoidable, may befall this project?

Shakespeare: (whispering to the RACC) Like bad project management!

Project Manager: Thou speaks aright, m’lords. My next round of cost/schedule performance reports shall please thee, be assured, as I will not show any EAC to which I would not be willing to sign on to an FFP basis. (Exeunt all but RACC and Shakespeare.)

Shakespeare: I understandeth not. How could those contractors make such a pledge?

RACC: Because the PM’s brother-in-law is the Duke, and second cousin to the Lord of the Exchequer. Unless I miss my guess, we’ll be seeing a “get-well” Baseline Change Proposal within the next few reporting cycles.

Shakespeare: What villainy is here! I must capture this in one of my plays. I think I’ll create a character after that contractor rep fellow, and name him “Iago.”

I think it’s kind of funny to consider the “safe” learning space that so many brick-and-mortar universities seek to establish in order to teach their charges how to succeed in the world outside the confines of their campuses. Virtually all college campuses have attractive facilities, manicured grounds, genteel staff and instructors – on the surface, anyway. By comparison, the world of industry, absent some form of government sponsorship or interference, is marked by extreme competition to provide a product or service better, faster, and/or cheaper than other entries in the particular field. Influencing people to voluntarily part with their hard-earned money almost always occurs in environs very different than the ones where pupils are instructed on how to do so, with results predictable and frustrating, but often hilarious.

The term “ivory tower,” referencing as it does the vast cultural divide between tenured faculty and free marketplace managers, carries with it a connotation of disdain for the perceived arrogance of the former. But there’s more to it than that: in practical application space, education credentials are usually highly-prized, of course. Unfortunately, it’s often the case that those possessing the credentials will arrive at their first full-time job assignments with an ill-deserved confidence that they know the solutions that beset their lesser-educated peers (or even superiors!), and can remedy them all, if only their advice and direction would be heeded.

Consider the following scenario, where a newly-minted MBA from a prestigious university arrives at her first job, having been recruited at an on-campus event by a major defense or environmental contractor. Arriving at the same time is an administrative assistant with an Associate’s Degree, recently promoted to project scheduler due to having attained his PMP® and taken a week-long night school course in how to operate the Critical Path Methodology (CPM) software that the major contractor uses on all its jobs. I’ll call our mythical MBA “Lisa,” and the fictitious AA “Jim.”

Lisa arrives somewhat overdressed, having learned that making a good impression on her first day is extremely important. She’s expecting to be shown a private office, with a door, and perhaps even a window with a view. The person she spoke with at the recruiting event described a corporate culture where PM is widely embraced and respected, with clear career paths for those involved in the practice of it, so that Lisa is anticipating being placed at around a middling rank in the organization’s management hierarchy. She is fluent in the monetary policy implications of Keynesian economics, and has an advanced knowledge of the importance of clear communications among project teams and line management to ensure the level of cooperation needed to be a truly high-performing PMO. She has had some theoretical training on Earned Value and Critical Path, but has never actually had hands-on-keyboards experience in setting up scope, cost, or schedule baselines.

Jim arrives to his new assignment in business casual, but in clothes that won’t look too much worse the wear for having crawled underneath desks to hook up computer cables, just in case the IT department isn’t as prompt as they could be in setting up his new work station. He’s hoping to be able to share a larger cubicle with just one other person, and considers this a significant upgrade from the crowded trailer bullpen he’s leaving. Having come up from the lower levels of the organization, Jim is well aware that the projects with an advanced PM capability represent a minority of the work for this contractor, and even those perform PM at a high level, because their government sponsors expect (or even demand) it. The rest of the organization is, to put it diplomatically, uneven in their advancement of the PM capability, with significant sections of the company actually adamantly opposed to it. Jim has no concept of the reasons Keynesian economics is completely wrong, and really could not care less how clear the communications are among the project teams he’s worked. But he does know how to set up a CPM network, including how to assign resources and compute the Basis of Estimate for a given project’s Performance Measurement Baseline. He also understands how to pull status to generate the schedule’s status file, and to derive the EV performance information from it.

As fate would have it, Lisa and Jim are assigned to the same cubicle. Its walls are five feet high and, of course, there is no door. Lisa’s furious, but hides it well. Jim’s elated, and doesn’t hide it at all. Their computer work station components are available on an IT cart nearby, but the IT people can’t get there until later in the day. Jim sets about setting up his work station – Lisa complains, as politely as possible, to their project team’s administrative assistant. Having been an administrative assistant himself, Jim has his computer up and downloading the software he’ll need to perform his job before noon; Lisa is working at hiding her frustration.

It's about 11:00 a.m., and you, dear GTIM Nation member, are now the director of this particular PMO, and have come to touch bases with your new employees. Ask yourself – which of these two is more likely to:

• Answer affirmatively to the question of how soon they’ll be ready to attend and contribute to the next project’s kickoff meeting?
• Complain about the computer set-up problems?
• Thank you for the opportunity to contribute to your PMO?
• Snark about the office accommodations?
• Present a positive image to the organization’s PMs of your team?
• Grumble that their level of expertise can’t be brought to bear due to the present conditions?

Okay, okay, I’ve set up the scenario in such a way as to make the answers to the preceding questions comically obvious, but you see my point. The School of PMO Hard Knocks is often overlooked in its ability to deliver an early, strong contributor, perhaps even better than many of the highly-ranked business schools out there, and the reason is almost completely reducible to attitude. I’ll leave y’all with this:

“Attitude is a little thing that makes a big difference.”  -- Winston Churchill

What is the purpose of a Project Management Office? Before you answer, consider the analogy of the purpose of your local newspaper. Why do you think it exists? To inform its subscribers of goings-on? To chronicle the occurrences that influence the community?

No. The purpose of a newspaper is to sell advertising space. Not what the J-schools would ever admit, but undeniably true. Before I re-ask the question in the first sentence, let me invite GTIM Nation to reevaluate the purpose of the PMO along similar lines, because I want to submit that it’s not what most of us have been led to believe. What follows is a short list of the things that the PMO should never attempt, much less internalize as a key goal.

1. The PMO is not there to dazzle the other parts of the organization with their advanced expertise in the way their projects ought to be managed. This is true for two main reasons: (a) the people actually performing the technical scope of the project tend to focus on just that, and will see non-technical people from outside their particular project team as interlopers at best, interference agents at worst, and (b) our friends the accountants have a 500-year head start on creating the narrative that Generally Accepted Accounting Principals (GAAP) are the way of tracking cost performance on any business endeavor. This means that any group that attempts to advance a different notion of the optimal business approach will be seen as interlopers at best, interference agents at worst.
2. The PMO is not an agent of organizational change. Yes, I know this is a radical assertion, but consider: the project team that is being forced to accept what the PMO has decided is advanced PM techniques against their wishes will abandon them the nanosecond they are allowed to do so. The project team that has elected to employ the services of the PMO will continue as long as the PMO offers a desired service at an acceptable price point.
3. The PMO is not a vehicle for upper management to harangue the project teams into performing better. I’ve witnessed this mal-formed strategy time and again. Recall from last week’s blog, the step where the organization’s executives, stung by a prominent project overrun or delay, has agreed to invest in the creation of the PMO. When this strategy is being employed, the PMO is typically started with a generous overhead budget. As the new PMO begins to churn out official procedures and policies, mandating what the project teams must do in addition to what they’re used to, some level of resentment becomes imbedded in the organization. When the project teams begin to opt out of the reporting requirements, executive frustration sets it, but not with the non-performers themselves. It’s always with the PMO. The PMO was supposed to change the poor performers into good or great ones, right? What then follows is a reduction of the overhead budget for the PMO, with a requirement that its members charge more of their time directly to the projects they “support” – the very same projects that have been incurring resentment-by-proxy against their agitating superiors, with predictable results.
4. The PMO also isn’t there to kibitz about what could go wrong, phrased in Gaussian-curve jargon (GTIM Nation didn’t think I’d get all the way through this list without an anti-risk management snark, did you?).

In short, the PMO can’t directly change behavior, can’t educate the uninterested, and will fail as a proxy for frustrated upper management. Again, what is the PMO there to do?

Simple, but utterly at odds with conventional wisdom: the PMO exists to put into the hands of the decision-makers what they need to make informed decisions. Assuming this simple mission is the correct one (and it is) brings with it some specific strategies, again well outside conventional approaches. These include:

• Wherever possible, don’t change anything about the way the project teams currently conduct their business. It sounds impossible, but it’s not. For example, need a basic Earned Value Management System, but you’re unable to pin down the project team’s principals in order to get a Performance Measurement Baseline in-place? Here’s a quick solution: the Estimate at Completion (EAC) can be accurately (+/- 10%) calculated by dividing the project’s percent complete into its cumulative actuals. That’s right: TWO data points, one of which is already available via the General Ledger. Compare that to the project’s budget (also available through the General Ledger), and you have a usable Variance at Completion, which I would argue is the single most important piece of information that an EVMS can generate. (Extra credit PM hack: the same formula works for duration.)
• When you absolutely, inescapably need to change some part of the business process, make it as falling-off-a-log easy and simple to do. This will become essential when…
• In those instances where even a demonstrably simple change is blocked, respond immediately to the ones who are not participating. Make it clear to whatever organizational element that gave the PMO its initial authority how easy and simple it would be to comply with your suggested change.
• Every single person who cooperates with your implementation is golden, even if they are providing schlock data. Better data can be taught, cooperation cannot.

Counter-intuitive? Sure. However, as available strategies for implementing your PMO go, this one has one distinct advantage: it’s aligned with the true purpose of the Project Management Office.

And that advantage is really all you need.

There’s an off-chance that I know a thing or two about this month’s ProjectManagement.com’s theme of Project Management Offices, or PMOs. PMI® actually published my book on the topic, Things Your PMO Is Doing Wrong (PMI Publishing, 2008), where it spent a bit of time on its Marketplace bestseller list. As the title indicates, much of the book addresses common but ineffective (or even counter-productive) strategies that PMOs use in the pursuit of their objectives. I was inspired to write that book, not because of my predilection to be the highly-irksome fellow in the corner of the conference room who is constantly of the opinion that everyone else is getting it wrong, but due to the sheer frequency of the employment of these flawed strategies. It’s almost as if the most formidable barrier to successfully advancing Project Management as a capability across the macro-organization was receiving short-shrift, if not invisible altogether.

Before I get to naming this PMO-wrecking monster, let’s review the typical life-cycle of the failed PMO:

1. A medium-to-large organization encounters either one massive project disaster, or a series of medium-sized overruns and late deliveries, which wakes them from their PMO-less slumber and motivates a change. At least one person in the upper levels of management has heard of those people over at the Project Management Institute®, and decides to…
2. Create the PMO. They’ll start by pinging existing staff to see if there are any PMP®s in the bunch, and will combine a couple of them with another who’s a new hire.
3. The newly formed PMO will meet to assess the current PM maturity level of the organization. Panic sets in.
4. The team will start to generate policy documents that require all projects, or projects above a certain size, to establish things like a Performance Measurement Baseline, or Critical Path Schedule (resource-loaded, in order to do the PMB), and a calendar for pulling status monthly. The head of the PMO will also schedule project reviews, where the cost and schedule reports stipulated in the recently signed-off policies will be presented.
5. The first project review is held. Most of the projects will be in marginal compliance with the policies, but others won’t even try. Notably, at least one project definitely over the compliance threshold won’t present, and will offer up some excuse why they couldn’t. Upper executives will allow it, either because they’re not convinced of the added value of these new meetings, or else because the titular PM of the defecting project is too highly-placed to confront.
6. At the next project review meeting, other projects begin to opt out of reporting. After all, the dumpster fire that led to the creation of the PMO is fading from memory, and those responsible have convinced those that created the PMO that the previous failure was due to some anomaly, and is unlikely to happen again.
7. The no-value-added crowd, oh-so-ever subtly supported by the accountants, find common cause with those who maintain that the new policies are too difficult to follow, leading to more project defections.
8. The plug is pulled on the PMO. Its members, firmly believing that they would have succeeded with a little more top management support, are reassigned, or leave for an organization in Step 2.

I’m fairly confident that many (if not most) of GTIM Nation will recognize this pattern, either having seen it unfold in this manner, or else having lived it. I would like to pause and point out things that were not part of the template: the ultimate failure was not due to a lack of talent, nor a poor selection for the Critical Path or Earned Value Methodology software platforms. It wasn’t due to a lack of a risk management capability, nor did quality issues sink the effort. And none – none – of the documents churned out by the non-certified guidance-generating organizations could have presented the insight needed to push the PMO over the long-term sustainable goal line.

After this set-up, my choice for the most common and dangerous PMO-killer is pretty clear, but I’ll go ahead and state it anyway: the coin of the PMO sustainability realm is cooperation. I believe that a primary reason that this barrier has such an effective cloaking device (note to editors: please reset the weeks-since-the-last Star Trek reference meter to zero) is due to the initial enthusiasm of the PMO-creating organization, way back in Step 2. Coming right out of the starting gate not only do the upper executives express their support, but the existing PMs offer their backing as well. How could they not? At that point in the overall process, they’re under a performance microscope. To openly oppose the PMO creation initiative would be career suicide, at least within that organization. But make no mistake – if these PMs could make a plausible argument on why they should be allowed to escape upper management scrutiny, they will. It’s basic human nature. They’ll slow-roll or silent veto the policy requirements, or assert that their projects fall outside the parameters for policy compliance, or push the idea that their project is so well run as to not need any additional overhead expense, or…

The list goes on and on. I’ll be maintaining this until I exhaust all of the pixel ink ProjectManagement.com gives me each week: the key to creating a sustainable PMO is achieving the cooperation of those in the macro organization. What is the best strategy for this kind of implementation? Well, first you…

Wow, look at that! I’ve used up all of my ProjectManagement.com pixel ink for this week. Tune in next week for the key aspects of the optimal