Game Theory in Management

Richard Teichmann (1868 – 1925) is said to be the originator of the assertion that chess is 99% tactics, and 1% strategy.[i] I was reminded of this quote the moment Cameron announced the ProjectManagement.com theme for October, that of Strategic Initiative Management (hey, if the editorial boss uses initial caps, I’m doing it, too). But if Teichmann was right, and the game of chess is somewhat analogous to management science, then does that render strategic management (strikethrough, sorry) Strategic Management only 1% of what we as PM practitioners should be paying attention to? In a word, no.

Note that the topic is not simply Strategic Management – it’s Strategic Initiative Management. The distinction is huge. It’s relatively simple to devise a strategy – the trick is implementing it within the organization, to get the team on board with the initiative part.

This Is So 2008

I actually discuss this at length in my first book, Things Your PMO Is Doing Wrong (available from PMI’s marketplace here). One of the basic ideas from this book is that you can not advance a capability by leveraging organization power. In other words, the typical approach used by most organizations to implement a new strategic direction (or even re-start an existing one) is doomed to fail, and I can explain why in this short blog.

Last week I described the highly formulaic manner in which internal, capability-advancing projects are performed by many (if not most) sponsors, but when it comes to employing an ossified strategic initiative approach, these guys have nothing on information technology (IT) projects. Take a look at the following list of steps, and tell me if they don’t look familiar.

• An information consumer (it might be a manager, but doesn’t have to be) is not reliably receiving some sort of data from the existing management information system(s) (MISs).
• So, they perform an analysis of rival systems that perform a similar function to the existing one, except these others provide the type of information stream they crave.
• Part of the review involves visiting other organizations considered to be able to perform the specific function sought, in a superior manner to the frustrated manager’s team, and seeing how they do what they do.
• Probably well before, but certainly by this point the preferred system has been identified. The “researching” manager begins to seek out higher-placed people within the home organization, and persuade them that the (already chosen) solution is within reach.
• The manager is assigned to write some sort of document – procedure, desktop instruction, analysis brief – that purports to evaluate the nature of the problem, and potential solutions. Keep in mind, though, that at this point the preferred “solution” has already been determined.
• The document receives a perfunctory peer review, and is then approved by upper management, signaling their support.
• The new system is purchased and installed. Users of the old system receive training, and all organizations that had used the previous system are expected to use the new – under pain of disobeying the execs who signed the so-called implantation document.

This is the point at which these strategic initiatives invariably fail, with their champions absolutely convinced that the proximate cause is the lack of “executive involvement,” which is really another way of saying “my bosses wouldn’t force my colleagues to use my great idea.”

So, Where Is The “Executive Involvement”?

Unless the executives we’re trying to involve here are also information consumers under-served by the existing systems, they have no motive to participate. It’s easy for non-executives to imagine that, having already approved the “solution,” these upper-management-types need only begin using the imperative tense when discussing the initiative and the entire organization will robotically comply, with the only ingredient missing being this “involvement.” But even upper management’s influence is finite, and it’s usually directed towards the issues that they perceive stand in the way of their doing their jobs. They may superficially acknowledge that your initiative is a good idea, but if your management of the initiative is to simply purchase your preferred solution, train the staff, and then expect these execs to lean on the macro organization to make it work, you’re doing the whole strategic initiative management stuff wrong.

And pretending that you know more than the bosses after approaching your implementation in this manner and seeing it fail is not helping your situation.

Next up: exactly what are we talking about when discussing Strategic Initiative Management?

[i] Retrieved from chess.com on 1 October 2016, 19:15 MDT, https://www.chess.com/article/view/chess-is-99-tactics

Does It Work?

In discussing the development of management maturity models, I would like to steer the conversation towards how such things should be approached in the first place. As I discussed in Part I of this series, the traditional, academic approach to this sort of research is to launch a project, collect members who see themselves as subject matter experts, get them to agree to the least objectionable set of premises possible, assemble those premises into a document, have the document peer-reviewed, and then (finally) a new theory is introduced and advanced. But does that approach really work?

Meanwhile, Back In The Real World…

I think that two of the most significant advances in project management in the last half-century came from the 1989 book Managing the Software Process by Watts Humphrey[i], and the 1982 book In Search of Excellence, by Tom Peters and Robert Waterman. While their conclusions are now pretty standard fare in business schools across the country, what I think is remarkable about these two books is the way their authors conducted their research. They did not follow the traditional model, nor its close cousin of developing a hypothesis, and seeking data that would support their conclusions. Instead, they (and their researchers) went out among functioning organizations that were succeeding, and noted what they all had in common. After a sufficiently broad data gathering effort, they focused in on which shared characteristics of the winners were relevant, and drew their conclusions from this data set. Note how different this approach is to the typical one – Humphrey, Peters and Waterman sought out what worked, and used their advanced grasp of causality to capture the source; conversely, the traditional approach is to collect ideas, and then get a sufficient number of so-called experts to agree to base their assertions on the collection.

A Return To The Unreal World

Managing the Software Process would lead to the now-famous Capability Maturity Model, developed by Carnegie Melon University’s Software Engineering Institute (SEI), which I believe is a valid model. However, in 2002 a “successor” to the original CMM was released, the “Capability Maturity Model Integration,” or CMMI®. This effort was to “improve the usability of maturity models by integrating many different models into one framework.”[ii] Naturally, the authors appear to have returned to the traditional approach, which rendered, in my opinion, the CMMI® inferior as a management science theory to its predecessor, the original CMM. It’s actually kind of ironic, the whole effort to integrate many different models into one framework, seeing as how virtually all of those many different models were very similar to (if not out-and-out derivative of) the SEI version in the first place.

And Now, For the Actual HCMM!

Actually, ladies and gentlemen, it doesn’t exist. Having one overarching structure that lends insight into how to influence a limitless number of project teams to perform better is pretty much beyond me. In many circumstances I like the original SEI CMM, but even it has its limitations, some of them quite stark. I believe that, if I were to be put in charge of developing a capability maturity model (by a paying customer), I would begin with these steps:

• Narrow the scope. Software project teams will use a very different PM tool set than construction, and aerospace projects would hardly be recognizable to PMs from the pharmaceutical industry.
• Remove any and all self-identified experts from the team, and retain only bright, well-educated researchers.
• Once we know the specific industry, find out as much about their projects, both successful and un, as possible from available records, particularly performance and change control information.
• Categorize the projects’ outcome as “Exceeds,” “Meets,” or “Fails to Meet” original project parameters.
• Only after these steps are complete would I attempt to interview members of the projects’ teams, the lower in rank the better. Major questions:
  • What went right?
  • Why did that succeed?
  • What went wrong?
  • Why did it go wrong?

Then I would interview the projects’ principals and consultants (if any), to see what the official story was, and contrast that with what the rank-and-file had to say.

From this data set I would begin to identify common factors among the winners and losers, and propose a structure to be published and peer-reviewed.

Did I mention the avoidance of any self-identified experts?

Lagniappe

My third book was released last week, and is available here. It’s entitle The Unavoidable Hierarchy, Who’s Who In Your Organization And Why, and it’s about how people tend to form and move up and down within social structures, including those in the corporate world. If you are a manager in charge of a team, it might be worth a look.

[i] Capability Maturity Model. (2016, September 19). In Wikipedia, The Free Encyclopedia. Retrieved 19:28, September 24, 2016, from https://en.wikipedia.org/w/index.php?title=Capability_Maturity_Model&oldid=740240845

[ii] Capability Maturity Model Integration. (2016, August 22). In Wikipedia, The Free Encyclopedia. Retrieved 20:02, September 24, 2016, from https://en.wikipedia.org/w/index.php?title=Capability_Maturity_Model_Integration&oldid=735671761

I Wonder Where Ruth Is

In furthering my particular PM3, the casual reader may have noticed something peculiar about my approach: I’m ruthless when it comes to abandoning tradition when it comes to refining the model. In last week’s blog I made the case for jettisoning risk management, human resources, procurement, communications, and quality from consideration in my model (except for specific circumstances), leaving only scope, cost, and schedule from the original PMBOK Guide’s® table of contents. It just so happens that these three management areas, taken together, are commonly known as the “triple constraint,” the basis for all other project management information systems.

Maybe She’s Out Trying To Find Answers

I’ve often stated in this blog that the 80^th percentile best managers who have access to only 20% of the information they need to obviate a given answer will be consistently out-performed by the 20^th percentile worst managers who consume 80% of the information so needed. So, when discussing structures or models that represent how organizations or project teams move from poor to superior performance, my particular application of the Pareto Principle becomes relevant. Management information rarely comes easy (or cheap), particularly since it must satisfy three requirements:

• It must be accurate,
• It must be timely, and, most of all,
• It must be relevant…

…which pretty much leaves off those areas of PM “expertise” that I’ve abandoned as part of my project management maturity model. The number of “stakeholders” engaged is irrelevant. For the project manager, the total compensation package for employees is irrelevant (a huge deal for asset managers, sure; but, for the success of a given project, not so much). The entries in a typical risk register are both irrelevant and inaccurate. The information streams created and maintained, then, for the production of these kind of datum are a waste of time, energy, and expertise.

Conversely, the precise nature of the scope being pursued, and the cost and schedule performance of the project team cannot be undervalued. These items are hugely relevant, and the task before the project teams’ analysts is to deliver this information in an accurate, timely manner.

And Yet, Ruth Is A Person

As tempting as allowing the Hatfield Project Management Maturity Model to rest on the comparative epistemological value of management information systems may be, the simple fact remains that project teams are made up of people, informed and otherwise. It’s a fact that some people on the project team will be more motivated than others, and, in sufficiently large teams, it’s a near-certainty that at least one member of the team will be working against the overarching goals of the project, particularly if it means their own personal advancement or advantage. Even the seminal work in capability maturity models, the CMM© from Carnegie Melon University’s Software Engineering Institute, was based on the observed behaviors of the subject project teams. For the SEI Level 1, the members of the team were not cooperating. For SEI Level 2, they were cooperating, at a basic level. At SEI Level 3, team cooperation was no longer based on a few individuals influencing them to do so, and so on. My take is that things like universally-used forms or the documents associated with their common training are artifacts of this cooperation rather than causes or drivers.

So, if project team-wide cooperation is the name of the game, how is that attained, or expedited? Game theory can provide some insights here, which will be covered in Part III.

Lagniappe

My third book was released last week, and is available here. It’s entitle The Unavoidable Hierarchy, Who’s Who In Your Organization And Why, and it’s about how people tend to form and move up and down within social structures, including those in the corporate world. If you are a manager in charge of a team, it might be worth a look.

Why Is This One Special?

When it comes to generating and then perpetuating new hypotheses in the management science realm, I’m sure it will shock my readers to learn that I take a rather opposite tack from the conventional approach. Take management maturity models (please!).

The conventional approach is to issue a call for papers and/or volunteers to come together in some kind of forum, either real or virtual, and thrash around the ideas that are largely considered to be valid on the particular topic. A certain consensus forms around those ideas that are least obnoxious to the simple majority of team members, and those ideas are then arranged into some kind of structure. These structured ideas are then documented, revised, refereed, and published under the auspices of the sponsoring organization. Unless the documents are met with widespread scorn, they will probably become the basis for further analysis, and perhaps even a certification. This last is the commercialization phase, where the sponsor organization finally receives some form of return for all of their trouble.

Why Breaking With The Standard Scholastic Model Is A Good Idea

Here’s my heartburn with this process: if it advances management science, it does so only coincidentally. It mostly advances policy. Consensus isn’t science, and science does not depend on consensus, period. Science only needs one researcher who happens to be right, and can reproduce results in an experimental setting. Of course I’m aware that, in the Management Science “laboratory,” i.e. the business environment, it’s impossible to isolate and test specific causal factors, which makes the pure science aspect of this whole thing extremely difficult, but stay with me. By the time the idea generators and their reviewers are in consensus-garnering mode, it’s too late. Management science may or may not be furthered – but “optimal” management policy most certainly is. So, how would I do it better?

First off, no seeking of consensus, especially not from hundreds or even thousands of project management experts. PM types are notorious for a whole bunch of them in a room being unable to agree on the color of an orange.  I understand that this approach automatically excludes any results from being considered for ANSI Standard inclusion or approval, which is usually considered to be THE basis for legitimacy, but that’s okay. If I’m wrong, my hypotheses shouldn’t be considered legit; and, if I’m right, they eventually will. Instead, I would identify just one person to propose a structure, conduct the research, make the arguments that either establish or overturn the structure, and publish it.  If just one person is a bridge too far (too short?), then one person should head a team of researchers, not opinionated experts weighed down with the baggage of their decades-old experiences.

Reality, Or Bust

Next, I would blast to smithereens any PM concept that couldn’t be defended using hard data. Back when I received my PMP®, the PMBOK Guide® was divided into eight sections. The Hatfield Management Maturity Model (HM3) is based on those categories, should they deserve consideration, so:

• Scope Management is obviously central to PM, and the only hard evidence needed here is the fact that a Google search for “how much is spent in construction project claims?” returns over 136,000,000 hits. Clearly defining the scope up front is essential to all other aspects of PM. Verdict: Valid.
• Cost Management is also essential to the whole PM process. Indeed, the organizational pathology of indicating to a customer that “it will take as long as it takes, and cost as much as it costs” was one of the key drivers in the widespread acceptance of project management as a discipline. Verdict: Valid.
• Schedule Management  -- see the second bullet. Verdict: Valid.
• Risk Management – I have yet to see an objective study that indicated that the risk management process was a central information stream in successful project completion. As I have often pointed out in this blog, the future cannot be quantified, even with Gaussian curves. Verdict: Invalid.
• Quality – here, I have a simple question. Is your product or service getting criticized and rejected over quality issues? If so, bring in a quality expert. If not, then don’t. Verdict: It depends on the project.
• Communications – some of this is helpful, e.g. developing a so-called zipper plan that defines whom within the project team communicates with counterparts in the client’s organization. But all this stuff about “engaging stakeholders”? Again, there’s no evidence that any of that enhances the odds of successful project completion. Verdict: Invalid.
• Human Resources almost never resides within the project team. Verdict: Invalid.
• Ditto with procurement. Indeed, since procurement so obviously falls within the realm of asset management, I would argue it never had a specific PM role in the first place. Verdict: Invalid.

This streamlined version of an earlier PMBOK Guide® table of contents will serve as the basis for the Hatfield Management Maturity Model, with more particulars coming in next week’s post.

First, A Little History

I think the proliferation of capability maturity models (CMMs) owe their popularity to Carnegie Melon University’s Software Engineering Institute (SEI), which performed a study on how software companies mature in their ability to successfully produce computer programs. The analysis became part of the book Managing the Software Process by Watts Humphrey[i], published in 1993, that divided software engineering firms into five levels:

• Level 1 (“Initial”), where everybody is basically doing their own thing (or nothing) with respect to the sought-after capability,
• Level 2 (“Repeatable”), which is very basic but standardized, so the entire organization is performing at the same level of expertise,
• Level 3 (“Defined”), is the Level where, if the heroes who got the organization to this point are hit by the proverbial beer truck, the organization’s capability level doesn’t decline because there are sufficient procedures and training in-place to perpetuate that level of expertise,
• Level 4 (“Managed”) organizations are good enough to export their expertise to others organizations, and
• Level 5 (“Optimized”) organizations are so good at what they do that they regularly discover solutions to long-standing problems.

Have We Seen This Before?

I was struck on how similar these “Levels” were to Tuckman’s stages of group development[ii], published in 1965, specifically that project teams go through a four-stage progression, of Forming – Storming – Norming – and Performing. If the SEI model assumes the teams have already formed – they did, after all, examine existing organizations – then Level 1 equals Storming, Levels 2 and 3 represent Norming, and Levels 4 and 5 are marked by their superior performance. If we’re talking about assessing organizations by the performance of their personnel resources by categories or Levels, then the two structures, in my opinion, are remarkably similar. SEI simply adds more detail. Don’t misunderstand – I’m not accusing anybody of plagiarism, or idea-lifting. It’s just that the practice of defining categories of organizations by certain criterion (“There are two kinds of people – those who divide people in to two categories, and those that don’t”) and then using those criterion as a measuring standard isn’t new.

If this is the case, then consider some of the implications. Currently, most college-level business schools teach that the point of all management is to “maximize shareholder wealth.” Agree or disagree with me that this is clearly silly, there can be no valid argument that this approach is against the Project Management raison d’etre, which is to manage work in such a way as to satisfy the customers’ expectations/parameters of scope, cost, and schedule. But that never stopped the asset management crowd from trying to tell the PM aficionados how to do their jobs, based on the analysis they derive from data in the general ledger. There are actually several books on how to calculate the return on investment (ROI), a favorite analysis technique of the general ledger geeks, on setting up a Project Management Office. For generations the asset managers’ tools have been intruding into project management space, where they most certainly do not belong.

Take That, Finance and Accounting!

But along come the Organizational Project Management Maturity Model. And what does it do? It essentially points out that corporations that have many projects feeding into several programs becoming part of a portfolio of work can have optimal (and, by extension, sub-optimal) organizational structures. The step-by-step ideological payback follows this path:

• Organizations are made up of resources.
• Resource management is not Project Management.
• PM, however, provides the metric by which organizations succeed or fail in portfolio management space.
• Basically, we PM types have turned the tables on the Asset Managers, by redefining (correctly) how organizations achieve success (or are viewed as failures), and on our terms.

This form of epistemological payback was a while in coming, but it’s said that revenge is a dish best served cold.

Lagniappe

My next book is coming out later this month. It’s entitled The Unavoidable Hierarchy; Who’s Who In Your Organization, And Why, and it’s available here. It’s about how people tend to fall into specific roles, or ranks, in the organizations in which they participate, and an analysis of the tactics used to advance within those hierarchies. My former PMNetwork columnist colleagues Neal Whitten and Bud Baker both gave great reviews of the manuscript, leading me to believe it might be worth its price (at least on Kindle!).

[i] Capability Maturity Model. (2016, August 28). In Wikipedia, The Free Encyclopedia. Retrieved 16:55, September 5, 2016, from https://en.wikipedia.org/w/index.php?title=Capability_Maturity_Model&oldid=736597555

[ii] Tuckman's stages of group development. (2016, July 22). In Wikipedia, The Free Encyclopedia. Retrieved 17:08, September 5, 2016, from https://en.wikipedia.org/w/index.php?title=Tuckman%27s_stages_of_group_development&oldid=731055786