Game Theory in Management

In my last blog I promised a “cohesive, articulable structure to address superior strategic initiative management ideas,” and I fully intend to do so. But first I need to cut through some of the fuzzy language associated with concepts such as “strategic initiative management,” and I will do so by pointing out what strategic management is not.

As I have often stated previously, Strategic Management is one of three distinct types of management, the others being Asset Management and (of course) Project Management. Each of these types has different goals, methods, and information streams needed to achieve those goals. As far as I know, I’m the only business writer to assert such a structure. So, how do I know that this assertion is valid? Here’s how.

Asset Management =

Asset management seeks to maximize shareholder wealth, and its primary information stream comes from the general ledger. I know this because that’s what they drilled into my skull in graduate school.

Project Management =

Project management seeks to deliver project work under the customers’ expectations/contract parameters of scope, cost, and schedule. Its primary information feed comes from reports generated via Earned Value and Critical Path methodologies. I know this because of decades working in the industry, three books authored and hundreds of columns, articles, and blogs, plus my three PM-centered professional certifications.

Strategic Management =

Strategic management is all about gaining market share, either by establishing new markets or out-competing your competition in existing ones. Strategic management’s information streams tend to be less objective, and more predicated on market analysis and polls.

Okay, so how do I know these are distinct types, and not mere gradations of the huge body of management science codex? Here’s how.

Asset Management ≠ Strategic Management

Asset Management is provably different from Strategic Management due to corporate behavior during hostile takeovers. A hostile takeover occurs when one company buys up the competitor’s shares – at inflated prices – in order to gain a majority ownership and force the company to liquidate. The acquiring company almost always incurs great expense to even attempt this tactic, and the target company’s shares jump in value; however, from a Strategic point of view, it’s worth it to eliminate the competitor, i.e. gain market share. Recall the objective of the Asset Manager, to maximize shareholder wealth. If Asset and Strategic Management were simpatico, then no acquiring company would ever attempt it, since shareholder wealth is (temporarily, with luck) driven down, and no targeted company would resist, because their shareholder wealth increases, usually significantly. The fact that acquiring companies attempt this tactic regularly, and targeted companies resist, proves that Asset and Strategic Management are different in type.

Strategic Management ≠ Project Management

Strategic Management is notably different from Project Management from observations of how monopolies work. Monopolies – for a variety of reasons – have no competition in their particular markets, and are therefor under little (or no) compunction to even attempt to meet customer expectations. But in those instances where their monopoly basis suddenly goes away, their behaviors change dramatically. Think the performance of cable television after satellite television became widely available, the “Baby Bells” telephone companies when cell phones came along, or government-run department of motor vehicles after licensed, private providers are allowed in to the market. Clearly, if market share is not an issue, they couldn’t care less about the customers’ expectations of scope, cost, and schedule, proving that Strategic and Project Management are different in type.

Project Management ≠ Asset Management

Project Management is provably different in type from Asset Management in that the information streams are irrelevant one to the other. Your typical PM doesn’t care whether the copier is purchased or leased, and your accountant is completely unaware of the schedule variance on a given project. As stated previously, Asset Management is all about return on investment, whereas Project Management is about delivering scope, on-time and within budget constraints.

With these definitions as the foundation, the structure of Strategic Initiative Management…

…will have to wait until next week, as I am out of room. Besides, did anyone really expect a fair addressing of the subject to fit inside 800 words?

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.