Game Theory in Management

When addressing the topic of strategic initiative management, it seems that one of the first and most aggrieved victims is the English language itself. The very term has multiple meanings. According to Dictionary.com,

• “Strategic” has six definitions,
• “Initiative” has eight, and
• “Management” has four,

…meaning that the term “strategic initiative management” can have up to 224 precise, but slightly different, definitions. So, what are we talking about here?

Meanwhile, Back At Madison Avenue…

A common marketing ploy is to coin a “posinon,” a contraction of a positive inferential non-statement. When I was a kid, the Coca-Cola Corporation had an advertising campaign that stated “Coke is it!” Later, another ad series asserted of Coca-Cola that “it’s the real thing.” Denotatively, of course, these sentences are devoid of meaning. However, their connotations were powerful enough to drive consumers towards, well, “the real thing.” Similarly, much of what passes for managerial insights into how strategic initiative management ought to be handled gets light on denotation, but heavy on implied, axiomatic truisms.

Let’s start with BusinessDictionary’s definition of “strategic management:”

"The systematic analysis of the factors associated with customers and competitors (the external environment) and the organization itself (the internal environment) to provide the basis for maintaining optimum management practices. The objective of strategic management is to achieve better alignment of corporate policies and strategic priorities."[i]

And Just Like That, It’s In Our Camp

I read this five times and I’m still not sure exactly what they’re talking about. By “factors” I assume they mean data, or information, but again I’m not sure. There are legions of analysts working for Wall Street firms, known as “quants,” whose sole purpose in business is to identify “factors associated with customers” in order to tease out some sort of pattern or structure, but they are (generally speaking) not involved in strategic management as much as they seek the optimal investing tactic in the near-term. And, as a reminder from last week, there’s a significant difference between strategy and tactics. Then there’s the whole business about “maintaining optimum management practices.” What practices are those? Ask fifty consultants (or bloggers), and you’ll get fifty different answers (though, one would hope, ones that are a bit less inchoate). I can guar—on—tee that your accountant will have a very different idea of which management practices are “optimum” than the person who runs your PMO. And what of “better alignment of corporate policies and strategic priorities.”? What does this “alignment” look like? Because I can assure my readers that, even in the most structured organizations, some of the decisions that affect the entire organization will be inconsistent with others. Does the organization put a premium on attracting the best available talent? Only if they fit into the existing pay structure. But it’s the rare organization indeed that, having identified some individual that they perceive to be highly desirous, won’t make an “exception” to their pay structure if need be. That’s just the way viable companies and organizations work, even if it means that the corporate policies and strategic priorities are out of “alignment.”

I’ve Seen This Before

I actually witnessed one of the most glaring examples of this kind of fuzzy “best practices” theory roll-out first-hand. I was at a professional society’s conference where a presenter was describing his team’s version of a capability maturity model. He told the assembled attendees that they had “designed the model to allow you to go where you wanted to go.” He wasn’t talking about an off-road vehicle – he was talking about a structured approach to strategic management, albeit in a highly vague manner. What if I want my organization to perform strategic management – whatever that may be – in a manner superior to my competitors? Would this presenter’s model “allow” me to “go” there? If so, how, exactly?

But the amorphous nature of the assertions in this arena do not seem to tamp down the fervor with which they are presented. The person insisting “It’s all about leadership!” is likely to do a massive eye-roll should you challenge them by asking “what about payroll? If it really is ‘all about leadership,’ as you say, how do members of the organization get paid? Does their ‘leader’ perform this function, as well?”

To Sum Up

Hatfield’s Rule of Management #5 states that if you can't state your theory in clear and unambiguous terms, it's probably a poorly-thought-out theory. But strategic initiative management theorists, take heart! There is actually a cohesive, articulable structure to address superior strategic initiative management ideas, which I’ll cover in my next blog.

[i] Retrieved from BusinessDictionary.com, http://www.businessdictionary.com/definition/strategic-management.html, October 7, 2016, 17:50 MDT.

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.