Game Theory in Management

Also known as the “Triple Constraint,” the Iron Triangle is the idea that Scope, Cost, and Schedule are intricately linked, so that, for any given project, it’s impossible to change one while leaving the others as-is. A corollary axiom, “Quality, price, or availability: pick any two,” is an often-overlooked truism, but it drives wide sections of current management science, and can explain why there are never-ending conflicts in the Project Management realm.

War #1: The PM is never good enough.

This is particularly true in the realm of Government-sponsored projects, and is rooted in the strategy of awarding contracts to the lowest bidder. Returning to the “pick any two” rule, there are only three possible management approaches to a given project:

1. If it’s high-quality work, to be delivered on an aggressive schedule, it’s going to be expensive.
2. If it’s high-quality work, but at an “affordable” price, then the number of organizations capable of performing it as such are going to be few and far between. In other words, the customer will need to get in line.
3. If the project does not require high-quality work, there are probably many organizations capable of performing it, meaning that it can be done quickly and cheaply.

However, since the way Governments tend to let procurements is based on the lowest bidder, Approach #1 above has already been ruled out. It never fails: whichever of the remaining two advantages is pursued, the stakeholders invested in the one given short-shrift in the trade-off will complain long and loud. Even in those instances where the product or service being sought requires high quality and an aggressive schedule, criticisms will be levied about its costs being too high. It’s true of roads, defense, medical care – it’s generally impossible to deliver comparatively high-quality, affordable goods or services with a ready availability.

This is where the private sector has a real advantage. In the case of medical services, some companies can set up their business model for those who need immediate care at an affordable price, and staff their clinics with newly-minted doctors and nurses in modest facilities. Other hospitals can concentrate on specialized medicine, with advanced, experienced personnel who can keep prices reasonable because their clients don’t need immediate attention, and can typically wait for an appointment. Still others can charge a premium for those who need to see them immediately for complex problems, and all three of these business approaches can exist side-by-side, with the most successful ones being determined by the individual patients’ choices.

This is rarely the case in Government projects, which tend to impact broad sections of their constituents in such a way that other alternatives are excluded. It’s one of the reasons the practice of formal Project Management techniques is so crucial. Regardless of which two of the three preferred attributes are chosen, the precise relationship among Scope, Cost, and Schedule is locked in when the three baselines are “frozen,” and subject to formal change control. It’s a way of making sure everyone (appropriately) involved agrees on what’s being delivered, at what cost, and when, with claims of deceit or poor performance evaluated in terms of the already-agreed-to parameters.

But it’s also why some Project Managers will never escape accusations of failing some group of stakeholders. (It’s also why the push to “engage all stakeholders” is, I believe, profoundly misguided.)

War #2: Why we’ll never be free of Scope Creep

This war is similar to War #1, since it’s also based on the “pick any two” corollary. Once the project is underway, getting more or better goods or services is the only informally-negotiable member of the Iron Triangle left available. Lower costs are quantified in currency, and schedules depicted in days. But better quality can be requested in many circumstances where those parameters aren’t precisely captured, especially if the improved quality being sought is produced by the project team working harder or longer. Check almost any organization’s Strategic Vision or Corporate Values statement, and the word “quality” will almost always be there, since quality is usually far more difficult to precisely quantify than cost or schedule. One can make a claim to offer a quality good or service with more confidence of never being proved false than the claim of being a the lowest-priced, or fastest available. It’s in this very inchoate characteristic of quality management that those customers set on maximizing their “value” by attempting to informally increase the scope will take advantage, and even seasoned PMs are not invulnerable to them.

In other words, a customer who requests post-contract award a reduction in budget can be easily rebuffed, and the same goes for the customer who desires services or goods delivery sooner than negotiated. But the client who complains about inattention to quality will usually be seen on the side of enlightened management science, and, so positioned, will be next to impossible to contradict or refute.

With standards of living rising precipitously across the globe, I think it’s hilarious to hear some millennials talk about how they are going to “fix” the “mess” they’ve inherited from previous generations. But when it comes to the next generation of Project Managers, I believe they have a case if or when they assert that these two long-standing problems should have been addressed, if not out-and-out solved already.

That being said, they could also easily pass these two problems on to the next next generation of PMs, meaning that these two Project Management wars, among others, are possibly never-ending.

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?”).