Game Theory in Management

One of the most noticeable changes in Project Management science over the years has to do with its lexicon. As I alluded to in last week’s blog, a project’s time-phased budget used to be known as its Budgeted Cost of Work Schedule, or BCWS, with the more seasoned practitioners simply referring to it as “S.”  Similarly, the Earned Value figure was titled the Budgeted Cost of Work Performed, or BCWP, or, just “P,” and actual costs were the Actual Cost of Work Performed, ACWP, or “A.” This allowed the use of acronyms for acronyms, as in the line chart that showed the cumulative budget, earned value, and actual costs getting the nickname “SPA” chart. In fact, the terms cited above are still on the U.S. Government’s Project Management reports’ official templates.

But the “planned value” people came along and tossed all of that aside. I do not care to debate whether or not the changing terms were a good idea. I simply note that these terms have changed, even though the data items they refer to represent the essential building blocks of conducting cost and schedule performance assessment and reporting. Given the “advancements” in PM science over the past few decades, we’re swerving perilously close to a state of affairs where we curmudgeons aren’t speaking the same dialect, or even language, as those new to the profession. Similarly, the newbies might be having a hard time adjusting to their post-college, professional PM roles, since there’s a bunch of us seasoned PMs out here, trying to get our projects in on-time, on-budget, and tend to not care what academia has to say about the way we do our jobs. So, in the spirit of helping to bridge this generation gap, I submit to my readers the following interpretation table.

If these so-called translations strike you as being overly cynical, allow me to make an appeal to inter-generational justice. If we had to put up with all of these things, then (a) why shouldn’t the next generation?, and (b) why should any of us believe that the next generation of accountants and PM-resistant engineers are any less sure of the veracity of all that pabulum they learned in academia? Remember how irksome we were when we were the “next generation” of Project Management?

But here’s our consolation: in twenty-five years or so, those who are now new to PM will be the ones looking at the incoming generation, and lamenting the ease with which they dispensed with terms like “planned value.” (Hey! Maybe then they’ll actually revert to BCWS!)

As we look at next-generation Project Managers (ProjectManagement.com’s theme for March), I’m reminded of a bit of fun I have at my younger son’s expense. He’s completing his second year of medical school (at one of the United States’ top schools, I must add), and his breadth and depth of knowledge is truly impressive. My undergraduate degree is in English which, on the face of it, would appear to require significantly (if not massively) lesser amounts of academic rigor. In order to lay claim to having the intellectual acuity to even engage him in conversation, I like to remind him that, whereas Shakespeare’s and Milton’s works are considered masterpieces even today, 17^th Century medicine is an embarrassment. In the 1600s, health was thought to be based on a balance of four bodily fluids, or “humours,” one of which was blood. If the doctor believed that your particular ailment needed some sort of re-balancing of these, he would often prescribe bloodletting, usually with leeches. A common “treatment” for a fever was to have the patient swallow a spider.[i]

And, while I’m fairly sure that Shakespeare and Milton will still be considered masters of insight and art four hundred years hence, I’m also confident that what today’s doctors think is advanced medical technique will strike M.D.s in 2418 as hopelessly obsolete, if not out-and-out backwards.

Meanwhile, Back In The Soon-To-Be Project Management World…

Which brings us to next-generation Project Managers. When I was first starting out in project controls, we computed the time-phased budget (Planned Value? Please. It’s the Budgeted Cost of Work Scheduled, or BCWS) by hand, and entered typed it, along with the Earned Value and actual costs amounts, onto the Cost Performance Report templates obtained from the Government Printing Office, using IBM Selectrics (if you have no idea what I’m talking about, I don’t want to hear from you), which were considered state-of-the-art back then (mid 1980s, if you must know). Today’s cost processors pull the BCWS (and, usually, the Earned Value) from the Critical Path Method software package automatically and receive the actual costs straight from the organizations’ general ledger, all but guaranteeing that each component of the main Project Management information system agrees with the others, accomplishing all of this in a fraction of the time it used to take.

But have we really advanced Project Management science?

Consider the fact that, ironically, on average 45% of all Information Technology projects go over budget. That may seem to be an unfair evaluation metric, since both Agile and Scrum were developed as adaptations to traditional PM techniques to address the unique attributes of software development projects. But it does point to a singular fact: the technology surrounding PM may advance, but the organizational behavior and performance attributes of bringing in scope on-time, on-budget remain stubbornly present, even ubiquitous. Why is that?

A Quick Jaunt Back To The 17^th Century

I think it’s for the same reasons that Shakespeare endures while humour-balancing doesn’t. Technology advances, but human nature tends to stay the same, generally speaking. In other words, the next generation of Project Managers may not need to know how to change the ribbon cartridge on an IBM Selectric, but I can almost guarantee you that they will struggle with getting the head of the accounting department to collect costs based on the Work Breakdown Structure, particularly in newer organizations. I often refer to Michael Maccoby’s work in the book The Gamesman, and his four archetypes of workers. But surely the most chilling example of The Jungle Fighter type was clearly illustrated in the character of Iago from Othello. For those of you not current on the tragedies, Othello is married to the beautiful Desdemona, and his main officers and companions are Iago and Cassio. Cassio is loyal, but Iago is a villain who manages to convince Othello that Desdemona is being unfaithful with Cassio. He does so by manipulating people and circumstances to make it appear to the Moor that all of this chicanery is happening right under his nose, and has been for some time, when, in fact, both Cassio and Desdemona are perfectly innocent.

Of course, the end result for your typical Jungle Fighter isn’t the death of those at the top of the organization, but the techniques of calumny, deflection, and altering the narrative for their own selfish ends are common tactics of the archetype. In other words, The Bard had The Jungle Fighter type pegged 373 years prior to the publishing of The Gamesman. It follows, then, that the best insights that we PM-types can pass along to the next generation has to do with things like capability maturity, or adapting traditional practices to better suit new technologies, like what happened with Agile and Scrum development.

The alternative is to continue to try and get pretentious with more “advanced” techniques within the Project Management world, such as more convoluted statistical analysis under the “risk management” rubric, even though there’s very little chance such techniques will stand the test of time. Indeed, if we as the collective PM community continue to promote such techniques, we could at least include a recipe book for making all this spider-swallowing more palatable – for posterity’s sake, of course.

[i] Retrieved from https://www.baus.org.uk/museum/82/17th_century_medicine, 1400 hours on March 3, 2018.

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.