Game Theory in Management

In blogs published earlier this month, I asserted that Program Management was more than just up-scaled Project Management. Probably the best proof of that premise has to do with the metaphorical first thing that Project Managers do versus what Program Managers do: the first thing the Project Manager does is create a Work Breakdown Structure (WBS) by systemically decomposing the project’s scope. The first thing the Program manager does is assemble similar projects into a portfolio where those projects can be coordinated on the basis of resource needs, customer/ market share strategy, and the use of acquired technology or expertise in performing analogous work. By definition, then, the work of decomposing the scope into a WBS and the work of assembling Scopes of Work (SOWs) into a portfolio (tearing apart vs. putting together) are very different, if not polar opposites.

This dichotomy has several implications for the new Program Manager, not the least of which has to do with Metcalf’s Law. Metcalf’s Law, also known as the Butterfly Effect, is the idea that, in large networks with many nodes, small variations in some nodes can have a cascading effect on the entire network, leading to very large (or even cataclysmic) impacts on nodes relatively distant from them. Its common interpretation is captured by the question “If a butterfly flaps its wings in Brazil, does that cause a hurricane in Texas?” (hence the nickname “Butterfly Effect.”)

The Project Manager has some tools to deal with this phenomena that don’t necessarily work well at the Program level. For example, once the project’s scope is decomposed into the WBS, the WBS index serves as the structure for re-assembling it. The work’s cost and duration are estimated, based on the scope description at the lowest level of the WBS. In addition to duration estimates, the professional Project Manager will define the schedule logic – which activities need other activities to be completed prior to starting – and load the whole shebang into a Critical Path Methodology software package. With the project’s critical path calculated, the PM becomes informed of which activities, even small ones, if delayed, will push out the overall project’s completion date, just as the Earned Value system informs her of which activities are in resource difficulties, and are potential candidates for help from the project’s reserves.

The following mental exercise is bit layered, but follow me on it. On Project A, an activity on the critical path goes long, and pushes out a subsequent activity that requires a specific set of personnel and equipment unique to the organization. Project B was counting on these same personnel and equipment, and had scheduled the same one week after Project A was supposed to be done with them. With Project A’s delays, suddenly both of these projects need the same personnel and equipment at the same time. Unless these projects’ schedules, both baseline and status, are in the same CPM engine, this salient little fact won’t come up unless some insightful project controls specialist recognizes it, and alerts their PMs. Without some accommodation, now both projects are in danger of coming in late.

Consider that the previous example was based on a problem that is nominally tracked in Project Management software. What do you suppose happens in those instances where the cause-and-effect chain is not nearly as linear as the version captured in critical path methodology? One example that pops to mind has to do with the customers involved in the previous example. The Program Manager, who has near-miraculously been warned of the impending project conflict by our intrepid project controls specialist, thinks he has a solution that will minimize the negative schedule variance inherent in the double-booked resources, with each project taking a 5% hit, perceived as recoverable by each project, if nothing else goes wrong. However, as his attention is drawn to ensuring that both Projects A and B pursue schedule recovery, he fails to realize that Project A’s scope is something of a one-off, unlikely to lead to similar work, whereas Project B’s scope is ground-breaking, and good performance could easily lead to more and bigger projects being let in the same arena. Levelling the negative schedule hit among the two projects has suddenly morphed from an optimal solution to the second-worst, with having Project B taking the entire hit being the worst (note how, had our intrepid project controls specialist not notified the Program Manager of the conflict, this would have been the default strategy).

Also note how this particular example is really not that complicated. In reality, the number of parameters and data points, both knowable and not, that could easily render a given strategy completely useless (if not actually destructive) increases geometrically as the projects are assembled into programs. As noted in our example, market share considerations rarely enter into the typical Control Account Manager’s (CAM’s) day-to-day decision-making, but to ignore them is fatal to your typical Program Manager. And that’s just one threat among many.

Despite what the risk management-types will tell you, it is impossible to get out in front of the nature of the cascading effects of Metcalf’s Law; and, even if it were possible, stochastic ranges and confidence intervals are utterly useless pieces of information. The logical approach is to develop a robustness of response for those instances where events unfold in such a way as to add difficulties to attaining your projects’ – and your program’s – goals.

The only alternative is to remain vulnerable to the potentially devastating effects of butterfly’s wings.

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.