Game Theory in Management

I was once assigned to provide project controls support to a fellow who thought of himself as highly advanced in project management. At our first meeting, after introductions, he told me he wanted a “swim lane chart.”

“A what?” I asked.

He proceeded to draw on the whiteboard a series of parallel, horizontal lines, and filled them with boxes representing activities, with arrows in-between them to indicate schedule logic. The areas in-between the horizontal lines were labelled with the names of some of the organizations participating in the project.

“Oh, okay, I get it.” I began. “It’s essentially a PERT chart, sorted by organization.”

“It’s a swim lane chart” he replied, emphatically, as if to contradict what I had just said. Rather than dither with a customer about the different label he wanted to give a common schedule format, I simply asked him about the Work Breakdown Structure.

“I don’t want a Work Breakdown Structure, I want a swim lane chart!” he insisted.

“I understand what you want, and I know how to produce one, but first I’m going to need a WBS in order to construct the schedule network we need to generate the ‘swim lane chart.’”

“Look,” he sighed, as if he were trying to communicate an extremely simple concept to a dull child, “I don’t want any of that other project controls stuff. All I really need to manage this work is a swim lane chart, regularly updated.”

At that point it became clear that this guy was deficient in his PM capabilities while fancying himself a genius, and that he held anyone who didn’t agree with him to be an ignoramus. In short, this fellow was (and probably still is) simply wrong.

And, being younger, I didn’t suffer this sort of wrong-headedness very well.

“Actually, in order to get you your ‘swim lane chart,’ we have to start with a couple of basics, and that includes a WBS. Let’s get started on that, and we’ll be one step closer to printing out the ‘swim lane chart.’”

After promising to get me the initial scope documents I would need to create the draft WBS, I left this fellow’s office and returned to mine, where my supervisor informed me that the PM had called and asked to have me removed from the project.  Which was okay, since, as I said, I didn’t (and still don’t) suffer this type of wrong-headedness very well. My replacement did a much better job, but I’m not entirely sure how she pulled it off. My guess is that she created a straw-man PERT chart, sorted by organization code, and then had the genius PM modify the activities, one by one, until they could be arranged into a rudimentary WBS – essentially, backing in to the Work Breakdown Structure (it would have been funny to see how they retroactively arranged the scope documentation, if that is the approach they took).

Fast forward to present-day, and I’m a blogger on a preeminent PM website, where the currency of the realm is ideas. What are these ideas? They represent theories, concepts, and techniques that help project managers do their jobs better. As with any body of knowledge (get it?), there are some good ideas, and some not so good. I’m sure it will not surprise any of my regular readers to learn that I believe that some of ProjectManagement.com’s competitors are pushing notions not derived through the scientific method – i.e., invalid – into the marketplace of PM ideas.

And, again, I don’t suffer this sort of wrong-headedness well.

A notable example of the notions I’m referring to is the idea that Estimates at Completion (EACs) ought to be time-phased. This is so wrong I’m having a hard time figuring out where to begin. An Estimate at Completion is just that – an estimate. It’s saying that, if the project continues on its current performance pace, it will cost X number of dollars. It is neither a request for more budget (when over the Budget at Completion), nor an offer to repatriate existing funds (if it’s under). It’s a performance indicator, nothing else.

But some other organizations maintain that this figure must be time-phased. What does that mean, exactly? It means that, if this notion is followed to its logical conclusion, they are mandating the creation of a rubber baseline. The existing cost baseline is the original time-phased estimate of the costs of the project. By stipulating the creation of multiple time-phased estimates, the original loses its relevance, and becomes, in the common parlance, “rubber.” It’s nearing uselessness because it’s being superseded by “more recent” information. But the altering of the cost baseline is a formal process. To do so otherwise is to set up the textbook definition of a rubber baseline. And those are not good. They are, indeed, often ruinous to projects that employ them.

So, I’m going to take my usual approach, and ridicule the notion. Those who embrace the idea that EACs need to be time-phased will consider me dumb, but that’s okay.

Because I think they’re simply wrong.

At the beginning of this month, with ProjectManagement.com’s theme of customer relations management, I discussed the contribution of Tom Peters and Robert Waterman, authors of In Search of Excellence, who directly challenged a management environment that had gotten away from working hard to fulfill customer expectations, or even attempting to find out what those expectations were. So, it’s only fair to use that standard when attempting to answer the question of what my readers – or any consumers of columns, articles, and blogs – want from the various project management societies and organizations. I think that answer is that practicing PMs are seeking insights and techniques, usage of which will increase the odds of managing our projects so that they come in on-time, on-budget.

On The Other Side…

However, as my regular readers are aware, I have previously written about what I consider to be two different types of project manager, whom I referred to as “processors” and “performers.” A quick synopsis: processors are more concerned that the processes of formal, rigorous project management are followed exactly than they are that the actual projects finish on-time, on-budget. Performers are the opposite. Sooooo, what happens when these two worlds collide? What happens when a processor begins sharing “insights” about how they think project management should be performed?

The results can be disastrous. I’m reminded of Michael Crichton’s excellent lecture, “Aliens Cause Global Warming,” where he discusses the reasons why the Drake Equation is invalid. For those of you who aren’t in to the Search for Extra Terrestrial Intelligence (SETI), the Drake Equation looks like this:

N = R* fp *ne *fl * fi * fc * L

where

• (i) the average rate of star formation, R*, in our galaxy,
• (ii) the fraction of formed stars, f_p, that have planets,
• (iii) the average number of planets per star, n_e, that can potentially support life,
• (iv) the fraction of those planets, f_l, that actually develop life,
• (v) the fraction of planets bearing life on which intelligent, civilized life, f_i, has developed,
• (vi) the fraction of these civilizations that have developed communications, f_c, i.e., technologies that release detectable signs into space, and
• (vii) the length of time, L, over which such civilizations release detectable signalsN = R ∗ ⋅ f p ⋅ n e ⋅ f ℓ ⋅ f i ⋅ f c ⋅ L {\displaystyle N=R^{\ast }\cdot f_{p}\cdot n_{e}\cdot f_{\ell }\cdot f_{i}\cdot f_{c}\cdot L} .[i]

The problem with this equation, which Dr. Crichton so brilliantly pointed out, is that none of the parameters can be known with any certainty whatsoever. All the Drake Equation does is to provide a facade of scientific methodology to what is, essentially, a guess.

Meanwhile, Back In PM Space…

I was struck by how similar the Drake Equation is to the formula for performing a single-tiered decision tree analysis (a common risk management technique) on project work. That formula looks like this:

C = ∑ (S1(p*i)) + (S2(p*i) + S3(p*i) + Sn(p*i))

Where C is the amount of contingency needed for the total of alternate scenario 1 (S1)’s odds of occurrence (p) times its impact (i), plus the same calculation for scenario 2, all the way through scenario n. As with the Drake Equation, none of these parameters can be estimated with any certainty. It’s just an accumulation of guesses, tripped out in pseudo-management science garb. As Dr. Crichton said of SETI, risk management is not a legitimate line of management science inquiry. It is, without a doubt, a matter of faith, a set of beliefs unsupported by observable and repeatable experiments.

Which brings me back to ProjectManagement.com’s February theme, of customer relations management. Do our readers really want to be preached to about ways some processors think they should be “doing” PM, even if their assertions are, precisely speaking, invalid from a PM science point of view?

My answer: ummm, probably not.

[i] Drake equation. (2017, February 12). In Wikipedia, The Free Encyclopedia. Retrieved 01:42, February 22, 2017, from https://en.wikipedia.org/w/index.php?title=Drake_equation&oldid=764988356

I think one of the funniest things about the automatically difficult role consultants in general and PM consultants in particular assume is the inherent double-bind nature of their jobs. It’s a double-bind thing rather than a single-step contradiction (e.g., a “Catch-22”) due to the multiple-step nature of the (eventual) contradiction, so:

• Consultants aren’t needed unless the host organization realizes it is experiencing problems its own personnel are not able to handle.
• Unless the consultants are okay with having their roles evolve to long-term subcontractors, they must be able to identify the inadequacies within the host organization, and then implement steps to advance the capability that is currently lacking.
• If the problem or issue lies within the team or group that brought the consultants in in the first place, the consultants are in the unenviable position of having to criticize the very personnel who will be deciding whether or not to keep them around.
• If the problem or issue lies outside the team or group that brought them in, then the odds of their recommendations being adapted by an organization that (a) didn’t bring them in in the first place, and (b) probably rejects said conclusions, are low indeed.

Of course, many consultants bring extremely valuable experiences and techniques to organizations that need them to get over a (hopefully) temporary difficulty or issue, which is one of the reasons why there are so many of them. Given that the population of PM consultants is relatively high, how does one discern between those who are the genuine article, and those who are not as competent as they pretend to be? Well, you bait them.

Can You Be More Specific?

Okay, so how does one bait a PM contractor, exactly? Well, it helps to know a few of the characteristics of each type. Typically, the real deal will have at least a few of the following:

• Personnel with the PMP®, or other relevant certifications,
• Published articles in the Project Management Journal, PMNetwork, here (ProjectManagement.com), or other (again, relevant) go-to places for project management insight,
• Technical papers presented at one of PMI’s Congresses, or other PM-related venues, or
• An objective track record of resolving issues quickly and permanently, for clients who are available to give rave reviews.

On the other hand, the consultants that you just might want to avoid tend to have some of the following:

• Only government clients (for the United States government, employees are usually enjoined from providing any publicly-available negative feedback about a contractor, no matter how shoddy their work is),
• Few or no certifications or publications,
• If they have presented a paper at a conference, it tends to be the same old blather about the basics of Earned Value or Critical Path methodologies, or why it’s a good idea to do them, or (my least favorite) how they were on a project where they did project management “right,” and everyone else in the universe needs to copy what they did, right down to hiring the same personnel (them).

What If I Still Can’t Tell?

If none of these tells are available, then the next level of discernment involves the actual baiting. After the consultant has been on-site for an adequate period of time, and is ready to provide their findings and recommendations, ask the following questions:

• If the problem identified has been known to the project team for some time, ask if they got their problem ID/recommendations from one of them.
• If they answer in the affirmative, ask why they didn’t disclose that fact;
• If they answer in the negative, ask why they didn’t bother to interview the project team.

There really is no correct answer to this line of inquiry, and you’re not looking for one. What we’re trying to discern here is the true differentiation among great and not-so-great consultants. The former will improve the people around them, even those considered by the host organization to be the lowliest; poor consultants will keep alive the shortfalls and inadequacies of the host organization, to better make the case that they need to be kept around. Assuming the position of outsider-looking-in and constantly criticizing elements of the host organization is a sure sign of a poor consultant. Great consultants will tend to take the responsibility for the lingering issues in the short term order to give more time to their host organization-trained staff to get things right in the long run. The only remaining question is: if you become aware that your consultants are less than great, what do you do about it?

Lagniappe

In addition to the webinar I’m doing with ProjectManagement.com on March 16, I’m also presenting at the PMI® Rio Grande Chapter meeting on April 20, at the Sandia Hotel & Casino in Albuquerque (where I will do my level best to avoid mocking risk analysts). The first person who approaches me after the presentation and says “I read your ProjectManagement.com blogs all the time, and I think you’re too hard on accountants” will receive a copy of my third book for free (it’s listed on Amazon for $116).

There can really be little doubt that customer relations management (or CRM, ProjectManagement.com’s February theme) was given a huge boost in recognition and acceptance with the publishing of In Search of Excellence, in 1982. In it, Tom Peters and Robert Waterman Jr. took the refreshingly novel and more scientific approach of seeking out organizations that were successful in their fields, and evaluate which business model aspects they had in common. The notion that, in order to be successful, companies had to focus on their customers to a greater extent than was common at the time was by no means new. Indeed, I would argue that the Project Management Institute did the seminal work here, since PM is focused on the customers’ parameters of scope, cost, and schedule. But, while much of the early work focused on first identifying optimal management approaches and then asserting that greater customer focus was essential, Peters and Waterman took the opposite approach, and found that a significant common thread among the high-performers was an escalated – if not maniacal – orientation towards customer service and satisfaction.

But It Wasn’t All Unicorns and Glitter

However, (there’s always an “however,” isn’t there?) in some aspects Peters and Waterman went too far, and in other ways they did not go far enough. Where I would argue they did not go far enough lies in the fact that there does not seem to be any limiting boundary to how far the manager that wishes to follow their advice should go when seeking to enhance customer relations. In a PMNetwork column (“The Business Wisdom of Bob Skeeters,”) I actually mocked this lack of a limit by condensing In Search of Excellence’s advice down to (paraphrase) “enthusiastically hand over all of your company’s assets to anyone who identifies as a customer.” While Peters and Waterman were certainly insightful in pointing out that the corporate zeitgeist at the time didn’t emphasize customer satisfaction sufficiently, they failed to provide any kind of an analysis that would indicate that a business model had moved too far in the customer-satisfaction direction, or if such an excessive move was even possible.

Still, I owe their work a debt of gratitude. It was only after reading In Search of Excellence that I began to realize that project management and asset management were different critters altogether, with different goals, methods, and information streams needed to make informed decisions. It was along these lines that subsequent lectures from Tom Peters would point to how the pursuit of greater efficiency or higher return on investment aspects of common business models were actually working against those organizations becoming (or staying) successful. So, what is the nominal limit to devoting resources towards customer relations, as opposed to, say, training personnel, or purchasing advertising?

And The Solution Is…

This is where the Corner Cube model comes in. As I have referenced previously, it’s based on the notion that asset, project, and strategic management are all different by type, not degree, having different goals, techniques, and information streams. The asset managers’ narrative had so permeated virtually all aspects of management science that to challenge its basic precepts was considered ipso facto evidence of ignorance. My favorite such narrative to ridicule, that the nature of all management is to maximize shareholder wealth, was only tangentially contradicted by In Search of Excellence, even that particular notion is both (a) widespread and (b) self-evidently false.

In the Corner Cube model, a single metric for asset management (e.g., return on investment), project management (e.g., Cost Performance Index, or CPI) and strategic management (market share) would be placed on a line-scale, with the target at the center, evidence of significant success towards the right, and the level considered failure to the left extreme. Assemble these three lines into a three-dimensional model, and you have a cube, with eight subdivisions representing the performance of all three management types. The typical path to success through the model does indeed begin with project management, i.e. performing well for the organizations’ customers, to the exclusion of asset or strategic performance. After a client base is established, the organization still doesn’t “maximize shareholder wealth,” since this stage indicates a strategy to acquire more market share. Only after the happy customer base is established AND a satisfactory amount of market share has been captured does the savvy portfolio manager seek efficiencies, or greater return on investment. The Corner Cube model is completely scalable and adaptable, meaning that some specific parameters would need to be plugged in before an analysis of the precise point that customer relations management can be safely throttled back can be performed.

In short, Peters and Waterman’s work was good, but the Corner Cube theory made it better. I elaborate on this (and other) concepts in my second book, just by the way.

To wrap up January’s theme of Project Management Office stuff, I want to discuss the third category of enemies who can (and often will) retard your PMO’s implementation progress, if not derail it altogether. The first two blogs this month dealt with opponents within the PMO itself, and last week took a look at adversaries outside the PMO team, but still within the organization. Now I wish to direct my hypercritical gaze upon belligerents outside your organization – and, like all the others, they are not going to offer up any outward signs that they oppose you and your mission.

Remember The Character Wormtounge, From Lord Of The Rings?

Indeed, these will almost always present as desirous of helping you, which makes them all the more dangerous. I’m talking about the various Project Management organizations that push agendas or narratives that recommend – or even mandate – certain practices or techniques that really have little to do with bringing in a project on-time, on-budget. I’ve previously made the distinction between those I call “performers,” whose main objective is to bring in projects on-time, on-budget, and “processors,” or those who think that optimal project management is a matter of following the processes they deem a legitimate part of PM.

One of the earliest battlegrounds between these two camps happened when the software project management techniques of Agile and Scrum came about. Software projects were (and are) notorious for coming in late and over-budget at a higher rate than, say, capital projects, and seemed to be the perfect candidates for more rigorous project management. More rigorous, yes – more formal, absolutely not. Software development is so dynamic and fluid that the original scope is rarely the exact eventual outcome. New techniques and technology are constantly arriving, and to ignore them is to condemn the project to putting out an obsolete product on the day it becomes available. To compensate, some way needed to be developed to adjust the scope on-the-fly, while still being able to capture the fast-changing circumstances in a cost/schedule performance system.

Are We Cheating, Or Not?

Ah, but there was the rub. If the scope baseline was fast-changing, and a formal change control process was impossible to accommodate, didn’t that mean that the mirror cost and schedule baselines would quickly become either irrelevant, or rubber? The solution was refreshingly revolutionary: do away with formal change control. In its place, schedule meetings where certain project team members were to participate in very specific roles as the day’s modular scheduling was addressed and modified (or not).  How was cost performance to be done?  I actually did a webinar on this very subject, entitled “Stop Those Divorce Proceedings! How Agile/Scrum and Earned Value Can Co-Exist In IT Projects.” The short answer here is: due to necessity, Agile/Scrum did away with the cumbersome, delay-inducing practice of setting up Baseline Change Control Boards, and having them evaluate every single change to the project, and approving or disapproving, and then having approved changes formally entered into the baseline documents…

It Depends On Whom You Ask

Enough! It was a waste of time and energy, time and energy these projects didn’t have in reserve. So they did away with it. I can almost still here the grinding of the teeth of the advocates of formal change control. It must have caused them fits. But this is just one example. The numbers of procedure-generating organizations that insist on inflicting their versions of “proper” PM behavior on the rest of the globe are vast, as vast as their ideas are insipid. From insinuating that comparing budgets to actual costs at the line-item level of the basis of estimate has something to do with Earned Value, to insisting on an “80% confidence interval” from the risk register, these external enemies slather on the irrelevancies, larding down legitimate project management in a naked attempt to not improve project performance, but to force a certain pattern of behavior in practitioners. And these, dear reader, comprise an entire category of external enemies to your PMO.

Lagniappe

It’s official! ProjectManagement.com is sponsoring a webinar for me, to be transmitted on March 16. The title is “Getting Ahead With Practical Game Theory: Modelling The Paths Of Career Advancement,” and I’ll be covering material from books two and three. Hope a lot of y’all can tune in.