Game Theory in Management

In last week’s blog I asserted that the supply and demand curves for Program Management are cyclical, and the sine wave-shaped curve of the demand side led the supply version. By necessity I wrote in generalities – this week I’d like to get a little more specific. Since I’ve been convinced by Douglas W. Hubbard’s excellent book The Failure of Risk Management: Why It’s Broken and How to Fix It (John Wiley & Sons, 2008), that the use of ordinal scales in scoring, well, pretty much anything in business analysis space, renders the ensuing analysis speculative to the point of uselessness, my scoring will be Boolean. Well, to an extent: the scorecards will be yes/no questions, but the points awarded will be based on my experience. This being the case, feel free to tinker with the points awarded/subtracted, with one caveat: change the points prior to filling out the scorecard for your particular organization. Otherwise, you’re cheating the same way the risk managers do every time they perform their “analyses.”

Okay, let’s start with the demand side.

Next up is the supply side. This scorecard might be a bit more difficult to answer honestly, so take a deep breath before you start. (Breathe in, breathe out.) Ready?

Here’s the simple part. Compare the scores. If the level of demand is higher than the total score of the supply difficulty, you, the Program Manager, have a real shot at establishing an organization-wide center of excellence, if you play your cards right.

If, on the other hand, your supply score is higher than your demand one, then some potentially painful evaluation is in order. It’s next to impossible to influence the demand curve – organizations will come to recognize the need for better and more advanced PM techniques at the same glacial pace that teenagers come to recognize that the High School disasters they experience will have virtually nothing at all to do with their adult lives. But you can do something about the supply curve. Show flexibility. Recognize that these PMs have a difficult job in front of them, and complying with your Program Management expectations does not present as attractive to them. Sell your analysis techniques (the valid ones, anyway) on the merits, rather than resort to scolding, and they will respect that.

But, most of all, do not show them this scorecard. If you do, the naysayers will know how we make Program Management initiatives harder for ourselves, and will engage those tactics (“Shouldn’t we have a far more proscriptive set of procedures?”).

In last week’s blog I asked the rhetorical question How hard can Program Management be? This was an attempt to demonstrate how many of the clichéd bromides that pass for Program Management insight are really nothing more than, well, clichéd bromides. However, Program Management isn’t merely a coordination of similarly-themed projects within an organization’s portfolio, nor is it as simple as an up-scaling of known Project Management techniques. One of the factors that makes Program Management so much more than these has to do with its cyclical supply-demand dynamic. I’ll explain.

On the Demand Side…

In virtually every medium-to-large project organization I have ever been a part of, the demand for Project Management expertise either is or soon becomes highly cyclical. The cycle looks like this:

• The projects are performing tolerably well, and there’s no customer mandate to “do” PM to a certain level of robustness, so demand for PM expertise is very low. There’s minimal project controls staff, and Critical Path or Earned Value analysis doesn’t exist.
• Either a project goes off the rails, or a winning proposal that requires formal PM turns into a contract. At this point the more advanced managers will call for, or actually set up, a project office, and bring in talent, either by training existing employees or hiring externals.
• As the Project Management culture takes root, other, similar projects are expected to provide the same sort of information products that the project doing PM “right” generates. Managers who train for and attain PMPs® see promotional opportunities proliferate.
• More projects requiring formal project management are obtained, causing the project management function to expand to include a team or group of project controls specialists. Ad-hoc portfolio management soon morphs into real-live Program Management.
• These projects are successfully completed on a consistent basis, and those project team members who dislike having to participate in project reviews, or simply don’t like having their performance quantified, begin to object to the existence of the PMO. They will question if those personnel are worth what they’re being paid, or if the whole business of setting up Performance Measurement Baselines (PMBs) is even beneficial at all.
• As the naysayers advance in the organization, budgets for performing PM-specific analysis – or setting up their Management Information Systems – are reduced, or even eliminated. The reports being sent to customers expecting a robust PM capability are generated by entry-level analysts, and are little more than window-dressing.
• Inevitably, another major project experiences massive overruns and delays, impugning or destroying the organization’s reputation for being able to deliver projects on-time, on-budget. The cycle starts over.

If something as amorphous as demand for Project Management expertise could be quantified, its graph would look like a sine wave, and a fairly uniform one, at that.

Meanwhile, Back In The Project Management Demand World…

To be brutally honest, however, we PM-types are not completely disconnected from the creation and perpetration of this sine wave of demand. We go through our own cycles, which tend to include:

• When we’re brought in to an organization to do this PM stuff, it’s done for a reason. If the organization didn’t (at that point in time) need our expertise, they would not have hired us. Unfortunately, if the staff, say, has no idea what a WBS is (which is often the case), it becomes easy to dismiss them as managerially challenged.
• As we pursue behaviors such as setting up baselines and pulling status, every time we encounter resistance to what we perceive to be fairly straight-forward requests for data (like asking the accountants to collect costs based on the WBS, when they insist on doing so via the Organizational Breakdown Structure) it’s easy to conclude that the organization either doesn’t appreciate what we’re trying to bring to the table, or else doesn’t genuinely care about their projects’ performance.
• We PM-types tend to try to inject some level of formality into the organization by writing procedures and desktop instructions, and then getting sympathetic, high-level executives to sign off on them. This gives the false impression that failure to “do” PM the way we want it done will result in some sort of punishment for the uncooperative.
• As the project teams execute the scope, they quickly realize two things: (1) those Critical Path and Earned Value people aren’t really contributing to progress on the project’s actual scope (in their opinions), and (2) any cost or schedule variance – even the innocent, inconsequential ones – get highlighted in those blasted project reviews. As they begin to resist, we tend to amp up the formality by leveraging whatever organizational power we have to compel compliance.
• By the time the codex of PM procedures, guidance, and rules rivals that of most business law textbooks (don’t laugh – it happens), the typical PM is looking for any excuse to remove their projects from the list of those that must comply. The demand curve begins to trend downward, whether the PMO recognizes it or not.
• Interest in a robust institutional capability wanes, meaning that PM-specific personnel are reassigned, or leave for organizations that are on the upward side of the demand curve. Realists begin to relax their rules and regulations, and assume a far more humble approach to any remaining PMs willing to cover their people, until…
• A project disaster occurs, and the demand curve resumes an upward slope.

Notable is the fact that the supply curve tends to lag the demand curve. Make no mistake – the area in-between these lagging supply and leading demand curves represents a significant amount of intra-organizational conflict, conflict that is as predictable as it seems to be unavoidable.

In short, it must be acknowledged that at least part of the reason Program Management is so difficult is because we PM types make it that way.

The “insight” that Program Management (ProjectManagement.com’s February theme) is simply a collection of like projects in a governable portfolio is about as profound as asserting that a person ought to tie their shoelaces in order to run a marathon, and as about as useful. It’s also positively ubiquitous, which means it’s an irresistible target for a curmudgeon like me.

But first, a couple of self-references. In my second book, I lay out the argument that there are three types of management, Asset, Project, and Strategic, each with their own objectives, tools, and tactics, and that these objectives, tools, and tactics can (and often do) interfere with each other as their adherents attempt to advance the cause of the organization (or their own particular career at the expense of everybody else, which I address at length in my third book). This fact, when combined with the old conservative saying that there are no solutions, only trade-offs, provides the basis for some fairly important Program Management discussions.

Many project-based organizations have a team set aside for helping the actual workers generate proposals in order to attract more work. Indeed, I once worked for a Beltway Bandit that fully expected its employees to put in a significant amount of free overtime performing this function, and would quickly place those who didn’t on the top of the to-be-laid-off list. These types of proposals would augment those prepared by the full-time proposal prep team, and made up a significant portion of the proposal backlog. Now, these regular-workers turned proposal-writers would tend to write proposals to their existing customers, in areas where they were familiar and confident they could perform the work should they get a contract or task order released. But what happens when an RFP (Request for Proposal) is released that is on the fringes of the organization’s experience, and management is not as confident that they could bring the work in on-time, on-budget (the very point of Project Management)?

This is where things get really dicey in Program Management space. By way of illustration, let’s say you are the CEO of a medium-sized company, and you have your Chief Financial Officer (the leader of the Asset Managers), Program Management Office director, and head of the Strategic Management office, all in the conference room where the discussion centers on just such an RFP. The question before you: do you spend any budget or time preparing a response? It’s significant in size, and would represent a major addition to the Program Management portfolio, but it’s not really within your organization’s realm of experience. The discussion goes something like this:

CFO: I’ve had some of my analysts perform a Return on Investment calculation on this, and the results range from marginally profitable to moderate losses. My vote is no.

PMO Director: The closest projects we have to the one in the RFP are ABC and XYZ. They are both performing adequately, but not exceptionally. This RFP would require us to hire at least three more engineers or technicians, augment the training of a couple more, and we’ll need a sizeable investment in new equipment, too. I think we could bring it in under cost and on-schedule, but it’s more likely we’d be looking at a mild overrun or delay under a cost-competitive bid.

Strategic Manager: These types of projects are expected to proliferate in the next five to ten years, and we’re facing more and more intense competition from other companies for the types of projects that make up the bulk of our current Program Management portfolio. The way I see it, we have one of two choices: either we start to pursue work in these new areas of unfolding technology, or else we come up with a way of performing our current projects significantly better or cheaper than our competitors, and can reflect that in our proposals. Otherwise, we’re done.

CFO: I couldn’t disagree more. The PMO Director has his project teams performing well, and our existing customers know it. Since the point of all management is to maximize shareholder wealth, and our ROI analysis shows this to be a risky line of business, my vote remains no.

PMO Director: I said we were performing adequately, not “well.” StratMan is right: most of our competitors are also delivering projects on-time, on-budget. The contract values for this type of work are shrinking, and many of the recent ones are actually Firm Fixed Price. If we can’t do the routine much better, we’ll need to do the novel, and soon.

CFO: But if you hire the talent to put us in a position to win this type of work – not to mention the equipment and training you referenced – and don’t get the job, then we’ll be out those costs, with nothing to show for it.

Strategic Manager: We’ll probably be able to find some kind of work for the new staff, and we can turn around and sell the equipment, admittedly at a loss, but we wouldn’t have to eat the entire amount.

CFO: Any amount lost at all is unacceptable, particularly since we would be pursuing a project with a low-to-negative ROI.

PMO Director: Who calculated this ROI, exactly? I get that you can quantify the cost of the equipment, but did you take into account that we could re-sell it? Or that the new techs could be re-assigned?

CFO: Well, I’m not sure…

Strategic Manager: ROI is projected profit, divided by estimated costs, times one hundred, right? How did you capture the expected profit? This one project might return a 5% fee, but our performing it will put us in a position to attract several other projects like it, which we wouldn’t have a chance without having executed this one. Did you calculate that? If so, how?

CFO: I can’t believe you are implying that I haven’t properly quantified the needed parameters. Could you give me even a gross estimate of the increased odds of our attracting similar work in the future if we do this one job? Or even of the size of the contracts that you say will be coming out in the next five to ten years? If so, how did you calculate these?

Strategic Manager: Okay, I’ll admit to some gut-feel and subjective-take assertions here. Will you?

PMO Director: Gentlemen, I would appreciate, well, a little appreciation. If we don’t pursue this new work, then the pressure is on me and my project teams to perform better with lower costs in the existing arena to keep the competition at bay. And if we do pursue the new work, the pressure will again be on my teams to quickly and efficiently master the new techniques needed to bring the work in on-time, on-budget. No matter which one of you is satisfied, the whole Program Management gig just got a whole lot more difficult.

CFO: But I read on one of those Project Management blog sites OTHER THAN ProjectManagement.com that Program Management is simply collecting similar projects into one manageable portfolio! How hard can that be?

PMO Director: This hard.

Earlier this month, the Bulletin of Atomic Scientists advanced the hands of their “Doomsday Clock” to two minutes to midnight, or 23:58 (time zone not specified), citing several factors from around the world – mostly political – for the bringing nearer of The Apocalypse. I find the whole Doomsday Clock concept rather interesting as a vehicle for communications, over and above the actual content it’s attempting to pass along. This “clock” doesn’t relay usable information about time that any other clock would – the longest ever doomsday interval on this clock has been seventeen minutes to midnight (23:43), and the clock “started” in 1947. That means that, even if we assume the longest ever interval throughout, there have been over one hundred million opportunities for the predicted Apocalypse to come about (131,932,800, to be precise) since this “measurement” began. So, when these people say “two minutes,” they mean, well, something other than two minutes (not very scientific, is it?).

They’re somewhat inchoate in what they mean by “apocalypse,” as well. Although it initially served as an analogy for the threat of nuclear war, this clock has since expanded to include other global catastrophes, such as those supposedly caused by global warming, or developments in life sciences or technology they believe could invoke irrevocable harm to humanity[i]. Interestingly, attempting to alert the world to the dangers of technology believed to cause irrevocable harm to humanity was also the driving force behind the Luddites.

Finally, the Bulletin of Atomic Scientists (I was previously unaware that the word “bulletin” could refer to a collection of people) isn’t actually comprised of all scientists. Some members did not include any reference to a hard science degree in their bibliographies at all. One appears to be an anti-nuclear activist, and another is a writer for that bastion of even-handed reporting, the New Yorker magazine.[ii]

But, other than a group claiming to be scientists who are not, in fact, all scientists, using the logic behind the Luddite movement in 19^th Century England, proclaiming with great fanfare an event that’s very bad, but not much more specific than that, occurring sometime in the future, but at a time other than the time units they publish, this whole announcement thing should probably be taken seriously.

Not.

Meanwhile, Back In The Project Management World…

It can’t be denied these people get a lot of press, so I was thinking about doing something similar. Just so we’re clear: my benefactor, the Project Management Institute®, has nothing to worry about as I set up my team alerting the world to the threat of Project Management Armageddon. I’m going to take the same “scientific” approach to my new mission as the Bulletin of Atomic Scientists have, which is to say, not very scientific at all. But, hey, they set the rules, and I’m just mimicking them.

First, I’ll have to come up with a catchy name, and its accuracy is not a concern. I think I’ll use “Bulletin of Management Scientists” (again, I was unaware that “bulletin” was a term referring to a group of people, but I’m not making the rules here). Since being an actual “management scientist” isn’t a prerequisite to being a member, I nominate myself, my Collie Gabriel, and my two cats, Kula and Dart. To those who think I’m being flighty here, I would counter that I’ve witnessed more managerial-like behaviors (especially the cunning variety) from these cats than from many executives I’ve worked for, and in a greater quantity than the number of hard scientific insights typically provided by New Yorker writers.

Next, we’ll have to define what the Project Management Apocalypse looks like. If it’s large projects, impacting thousands of lives and risking millions upon millions of dollars, going south in a big way, then The Big Dig project in Boston (among others) has established that the PM apocalypse has already occurred. That’s the thing about the PM Apocalypse: when specific projects crash and burn, it doesn’t mean the end of the world. But if we are to discuss a Project Management day of reckoning, then it can’t be localized, no siree. It has to be massive in scale, impacting projects all over the world. So, similar to that scene from the movie 2012 where a gigantic tidal wave dropped a super-carrier on top of the White House, I’m thinking our PM cataclysm involves dropping said super-carrier on PMI’s headquarters (unoccupied, of course) in Newtown Square, PA (which is 88 miles from the ocean).

Finally, we will have to tap into our friends, the risk managers, to calculate the odds of a cataclysmic tidal wave dropping an aircraft carrier on top of a specific facility in Newtown Square, so as to add a veneer of quantification to our warnings. They will probably (get it?) say that it’s not very likely. It’s then that we would alert them to the Bulletin of Atomic Scientists, and their “work” on the justification for advancing the hands of their doomsday clock, and request a re-compute. I mean, if we’re literally 120 seconds from a thermonuclear exchange, global warming-induced climate catastrophe, or some other movie-worthy disaster, doesn’t that increase the odds of such an occurrence? Additionally, we could broaden the parameters by, say, requesting a mere 2% confidence interval, and loosening the ship-to-be-dropped particulars, as in “We’re 2% confident that, given an apocalyptic event, there’s at least a 1% chance some ocean-going craft will be dropped somewhere in the township of Newtown Square.” Cutting to the chase, this means that if at least one RM could assert that there’s a one in 200,000 chance of that ever happening, we have all the “experts agree!” references we need, and can begin issuing dire warnings to the management world.

And here’s what verifies our press release: the members of the Bulletin of Management Scientists team have indicated (by nodding their heads) that they agree with this entire document. And it had nothing at all to do with my waving pet treats up-and-down in front of their faces.

[i] Doomsday Clock. (2018, January 27). In Wikipedia, The Free Encyclopedia. Retrieved 02:27, January 28, 2018, from https://en.wikipedia.org/w/index.php?title=Doomsday_Clock&oldid=822550768

[ii] Retrieved from https://thebulletin.org/2018-doomsday-clock-statement at 19:36 MST on 27 January 2018.

Since January’s theme is talent, and given my status as the foremost contrarian blogging for ProjectManagement.com, it’s only natural that I would focus on something that afflicts us all: the presence of no-talent hacks, either in the project team itself, or (worse still) in the role of Project Manager. We’ve all encountered them, since these people can be somewhat ubiquitous. But what can be done about them? They didn’t appoint themselves into their places of authority, so someone in the hierarchy has been fooled into thinking that the particular bungler can contribute to the project, or else increase the chances of an on-time, on-scope delivery. And yet, here they are, doing the precise opposite of contributing, and endangering the success of those around them. Clearly, the un-talented must be countered, neutralized, or at least avoided until they expose themselves for what they are. What are the tactics for doing so?

First off, one must recognize them, which is not always easy. After all, they did fool someone into getting their undeserved position, and that someone had to be in a position of authority. If that person can be fooled, others can be, too, and it’s up to you to, well, not be fooled.  I’ve often referred to Michael Maccoby’s book The Gamesman, where he describes four basic archetypes of workers as The Craftsman, The Company Man, The Jungle Fighter, and The Gamesman. Of these, the inept can be Company Men, but Jungle Fighter is the archetype where concentrations of the untalented tend to congregate. They employ the Jungle Fighter’s strategies of calumny and deceit in order to hide the fact that they have little or nothing to contribute. Within the Jungle Fighter archetype’s strategy, however, I have noticed three favored tactics:

• The Openly Belligerent. This is one of the easiest types to identify, since they reveal their approaches so readily. I have never known a truly talented manager to engage in insulting or challenging a colleague in a demeaning manner, especially not in front of others. But this tactic of the incapable is often employed readily, since it serves two purposes: it makes others afraid to look too closely into exactly what this person is actually accomplishing (or failing to accomplish), and it also goes a long way towards ensuring that a minimum number of coworkers will involve themselves with this person, effectively insulating them from interaction with anyone who could quickly recognize their lack of talent. This sub-type is often referred to as a bully. While that’s not inaccurate, it should be kept in mind that garden-variety bullying is usually used to make rivals feel or look bad by employing violent or overly aggressive methods, whereas the no-talent hacks are simply trying to protect themselves against discovery.
• The Glom-Ons. These people are adept at positioning themselves in such a way that it’s widely perceived that they had a role (usually a prominent one) in project team successes, even when their role was tangential. Conversely, they are also very good at creating the appearance of having nothing at all to do with project team failures or difficulties, even if they had a genuinely significant role. They’re always there when the deliverable files are being transmitted, but strangely absent when the actual data-gathering and processing takes place.
• The Svengali. This person is perhaps the most dangerous, in that they know how to speak the language of the project’s scope, and appear to be enthusiastic contributors, so they don’t present as either of the previous two sub-types. What they can do, however, is quickly identify the truly talented members of the team, and seek to form alliances with them, especially the youngest ones (since the more mature talent will recognize this subtype rather quickly). Once such an alliance is formed, they only need to position themselves in such a way as to be seen as aiding the young talent when, in fact, they are making it so that the young talent can’t get ahead without the Svengali being uplifted as well. I’ve seen this happen a couple of times (heck, it happened to me when I was younger), and it’s really a thing to behold. If there’s an Olympics of career-advancement-at-the-expense-of-others, this sub-type would take the gold, silver, and bronze medals altogether. Always affable, and perennially ready to virtue-signal their “loyalty” to the young guns, they will abandon their charges at the first sign of difficulty, target the next youngest (real) talent, and start over.

How to counter these tactics? Cultural norms can be radically different, of course, but in the West, it’s simple, really.

• Confront the openly belligerent, but only when you have the superior business case. After coolly making the better case for a given course of action, the belligerent won’t be able to help themselves, and can be counted on to go over-the-top in formulating their response to you. When that happens, all will see the game going on, and the days of the belligerent are numbered, even if Human Resources doesn’t become directly involved.
• Avoid the Glom-on. Don’t give them the opportunity to take credit for your successes. Be like the Shao-Lin warrior descriptor from the television series Kung Fu: “Looked for, he cannot be seen. Listened for, he cannot be heard. Reached for, he cannot be felt.” Give this person no access to the decision-making process concerning the technical approach to solving problems, and their irrelevancy will be revealed in due course.
• Troll or mock the Svengali. They won’t be able to stand it, since their self-image is both incredibly lofty and utterly undeserved. A genuine mentor is patient with their charges, but a poor one (or a Svengali) will abandon them at the first sign of resistance or rebellion. Soon they will run out of talented young ones to target, leaving them on the island of inadequate (but highly-paid) team members who can’t really point to any concrete contributions.

Again, the unqualified are somewhat ubiquitous in most areas of human endeavor, and Project Management is not excepted. But keep in mind: when you resist these people, you are in danger of hurting your own career trajectory, since the standard response from the typical project team member is to let them be. These people got ahead for a reason, and are expecting everyone else – and I do mean everyone – to respond passively, if at all, to their antics. They will become aggressive when confronted or frustrated – you can count on it. But, if you are among the talented, you just might pull it off, and earn the mostly silent, but undying appreciation of the rest of the organization.
One last thing: if you are the PM and you happen to find a hard-copy version of this blog taped to a bulletin board in the project team’s break room, you might have a problem.