Game Theory in Management

I have never met a medical doctor who came into the field after having done something different entirely, and then had an epiphany that they needed to learn how to heal people in order to continue with their chosen profession.  Ditto with accountants. But Project Management? It’s chocked full of them (people who suddenly realized they needed to understand PM, not how to heal people or set up a ledger).

Generally speaking, the people in the PM profession whom I’ve encountered got there in one of two ways: either they quickly grasped concepts such as Critical Path or Earned Value methodologies, and realized that there was a demand for such talent; or else they were doing something else entirely – usually some sort of engineering – and were put into a position of authority on some project work, and realized they were sorely lacking the skill set that would enable them to bring that work to a successful conclusion.  ProjectManagement.com (and, by extension, the whole Project Management Institute®) is useful for the professionals in the former category; but absolutely essential for those in the latter. What professional, handed a project assignment but realizing they need a higher level of expertise to accomplish the tasks at hand, has time to suspend work, and attend classes at a university?

Hence PM’s nickname as “the accidental profession.” It’s also interesting to note some of the adjunct versions of PM, and how different they are from our friends, the accountants. Ever heard of “Agile Accounting?” No? How about “Scrum Financing?” Still nothing? Well, there’s a reason for that.

Project Management’s ability to adapt to new and different circumstances is one of its reasons for existence. Before common access to management information tools such as Critical Path or Earned Value, managers who were responsible for actual project work lacked the information tools needed to ensure successful project delivery. As I’ve often asserted on this blog, the top 80^th percentile managers who have access to 20% of the information they need to obviate a given decision will be consistently out-performed by the 20% worst managers who have access to 80% of the information so needed. But, since the Asset Managers dominated the field of business theory, the early project managers were at a distinct disadvantage. To seek an estimate of at-completion costs was to be presented with a projection based on the burn rate of the actual costs. A cost variance was the difference between the budget and the (again) actual costs. What’s the estimated completion date? Well, the management experts – at the time, accountants – were sure it had something to do with actual costs, or lists of milestones, or something like that.

Naturally, when better methods for providing the unique set of information that PMs needed became available, the existing management science gurus reacted the same way scientists have for centuries, when a new theory is proposed that is clearly better than the existing ones: they fought it with everything they had. The world’s first business school started in 1819, in Paris,[i] by which time the particulars of accounting had already been in existence for centuries (literally). PMI® didn’t start until 1969, when the field was still relatively new.  That’s 150 years exactly, 150 years of a specific set of management practices that had little formal recognition from the management sciences establishment. And yet, there is a distinct possibility that a Kuhnsian-type paradigm shift is emerging in business, whereby Project Management theory either is or will soon displace much of what passes for commonly-accepted precepts in the management sciences. These PM usurpers are not being forced on anybody – they’re being embraced out of discovered necessity, almost, well, accidentally.

In essence, while most of us may have swerved into the project management realm relatively accidentally, that its set of management science precepts should come to claim major areas of business practice is no accident.

It is, in fact, inevitable.

[i] Business school. (2016, March 5). In Wikipedia, The Free Encyclopedia. Retrieved 03:02, April 10, 2016, from https://en.wikipedia.org/w/index.php?title=Business_school&oldid=708373426

I’ve had a lot of fun on this blog site making (mostly innocent) fun of our friends, the accountants, by pointing out the logical fallacies in many of their management science hypotheses, not the least of which is their idea that the overarching theme of all management is to “maximize shareholder wealth.” Of course, the whole raison’ de etre’ for Project Management as a discipline is to contest that idea, since PM is all about delivering a product or service to the customers’ parameters of scope, cost, and schedule. By transferring the focus of our efforts on the customer, rather than the company’s owners, we PM-types pursue a business approach that is not only inconsistent with the accountants’ world view, it’s actually in opposition to it.

Indeed, I would argue that the basic tenets of Project Management theory are intrinsic to everybody’s career advancement, and to prove it one must only answer a simple question: Why would anyone ever want to give you money? If you answered “in exchange for a good or service I rendered,” go to the head of the class. If you answered “because I maximized shareholder wealth,” then you are either in desperate need of remedial business school, or perfectly suited to write college-level textbooks on quantitative analysis, or both.

Your ability to quickly grasp what others want or need, and provide that to them, is key to any and, arguably, all of the success you will encounter in your career. From managers who need people who can sell merchandise and operate cash registers, to the owners themselves who seek to satisfy their customers’ demands, it is your ability to provide desired goods and services that determines your level of success. Again, the asset managers’ orientation is not set in that direction – but Project Management’s is.

On a larger scale, the shift in emphasis from satisfying the customers to maximizing shareholder wealth is one of the most distinctive indicators that an organization has transitioned from its ascendency and into its decline (for a more complete list of these signposts, check out my second book). The most obvious example of this has to do with the new business. Brand-new businesses seek to satisfy their clients, and their owners will often expend extraordinary effort, their own capital, and much overtime to make this happen. In other words, they will go full-throttle on executing the tenets of Project Management. If they’re smart, they will only think of their own remuneration after their customer base is established. The shift of majority focus away from the customer to the organization’s internal leadership inevitably leads to the organization’s eventual downfall and elimination from economic competition.

And, remember, that’s what the asset managers have been advising executives to do all along.

On an even larger scale, this shift in focus is also a harbinger of governments that have ceased existing for the good of their respective populations, and have begun expending energy and manipulating public policy to ensure the governing class’ own enrichment and continued survival, with the eventual outcome of tyranny and revolution. Fortunately, in capitalistic environs the decline and fall of companies is rarely accompanied by violence, as those companies who listened to the advice of the asset managers merely suffer as their PM-oriented competitors gain more and more market share, until the former ceases being on ongoing concern, and liquidates their remaining assets. But that does not exonerate those who maintain the hypothesis that the point of all management is to maximize shareholder wealth. Example after example, from small businesses, to larger organizations, and even governments, shows that this closely-held idea is actually detrimental to those organizations that embrace it, even on very large scales, i.e., civilization.

To summarize: Individuals and organizations in their ascendency further the goals of their clients and constituencies. Those in decline put the enrichment of the organization ahead of their clients and constituencies, which puts PM squarely on the side of the advancers, including career advancers. ProjectManagement.com’s blog readers are in those ranks.

Any questions?

While many of my ProjectManagement.com co-contributors have focused on the benefits of collaboration, pitfalls of its absence, and tools or techniques that might help attain the former while avoiding the latter, I (predictably enough) want to take a slightly different tack. You want collaboration? It’s simple, really. Drawing from some pretty basic game theory, all you have to do is to time the payoff to as late as possible for each member of the project’s team. Did that last sound a little jargon-y? Let me put it this way: pay everybody else last.

Before I get into the longer explanation, let me stipulate this: if your organization’s approach to motivating employees is confined to threatening them with their jobs, forget about any honest collaboration. Any loyalty to your proffered technical or managerial approach is completely faked, period. The acid test here is this: if the PM were to suddenly be replaced, would there be any member of the project team who would assert that the previous PM’s technical approach be maintained, or would they reflexively embrace the new PM’s version? This approach to motivating the project team is typically confined to project teams where:

• Each member belongs to the same organization,
• Very little original thought is required of them, and
• They are rewarded (or not punished) the same, regardless of project outcome.

In other words, projects where collaboration would be largely superfluous.

Conversely, the benefits of collaboration among team members are maximized when:

• The members of the team are brought together for their expertise, not because they just happen to belong to the same organization,
• Much invention or original thinking is called for, and perhaps most importantly,
• …they receive their rewards only when (or if) the project is executed successfully.

Remember the iconic scene from The Mummy where protagonist Rick O’Connell confronts his one-time associate Beni about his plans to guide the Americans to the lost city of Hamunaptra? Beni admits that the preferred tactic of leading them into the desert to “let the rot” has been denied him because the Americans have paid him half of his fee, with the other half coming only after they have arrived in Hamunaptra.

Of course, not all attempts at project team collaboration are analogous to hiring a cunning opportunist to serve as tour guide to an ancient but treasure-laden city-of-the-dead. But many, if not most of them are. In typical, spontaneous acts of economic collaboration (also known as purchasing a product from a person or organization that has agreed to sell to us for a specific price), the consumer has selected the desired product off of a shelf where, again typically, there were options to the product selected, and approaches the check-out ready to pay. If you think about it, that’s really the optimal way of doing it. Under certain circumstances it might be better to pay first, and then be shown the product purchased; or to arrange payment well after having taken delivery, but in each of these instances one party is vulnerable to having the other not follow through on the terms of the collaboration, potentially rendering the whole exchange a bad idea.

On the other hand, by arranging to have the rewards of a successful collaboration delayed until after the benefits have been realized, the collaborating parties really don’t have to worry about the other’s level of commitment, or good character, or outward appearances of being trustworthy collaborators. All anybody really has to concern themselves with is preventing the other’s payoff from being realized too soon – hence the original admonition.

 It also doesn’t hurt if you can arrange to have those collaborators who double-cross you eaten by beetles.

Since I’ve been spending so much of my energy blogging about communications so far this month, I thought I’d pick up March’s twin theme, collaboration, and see how much damage I could do to it – and didn’t have far to look for ammunition. According to Webster’s online, the two “simple” definitions of collaboration are:

· to work with another person or group in order to achieve or do something

·  to give help to an enemy who has invaded your country during a war.[i]

I’m fairly sure that when ProjectManagement.com offered up “collaboration” as part of March’s theme, they had in mind the former definition, but you have to admit the latter version is highly intriguing, particularly in those instances where any of my readers find themselves in a situation analogous to having their “country” “invaded,” e.g., having the project team or organization you work for taken over by another owning entity or organization. The political and managerial dynamics of such a takeover are myriad indeed, but there are a few insights that might help the unfortunate PM survive.

First off, what kind of takeover are we talking about here? In those instances where your project has suddenly become so hot as to be perceived as unworthy of belonging to a workaday sort such as yourself, and there’s a push to “give” it to a higher-ranked individual, there’s virtually nothing you can do short of quitting and attempting to take your client with you, which is, except in rare circumstances, impossible. If your particular technical approach to the project is both (a) unique, and (b) effective, the displaced PM can attempt to disengage, and let the project flail about until such a time as the superiors are inclined to come back and ask about the uniquely effective technical approach. The problem with this tactic is that, by the time the new strategy has shown itself to be sub-optimal, it’s usually too late.

Then there are those instances where your project isn’t so high-profile as to attract unwanted attention, but its owning organization has been taken over by another group, one whose technical approach to project management is singularly inconsistent with the original. Technically, “hostile takeovers” are usually undertaken with the intent to buy out a majority of the target organization’s stock to gain control, and then liquidate the target in order to remove a competitor. But even in those instances where the acquiring organization has no intention of eliminating the target – they simply want the target’s project portfolio – the takeover can take on the appearance of being very hostile, indeed. What’s a PM to do?

First, learn the acquiring organization’s rules. No, not the ones they publish under the auspices of a mission statement or other such self-flattering mythology. You need to know how they function, specifically how close they are to being a true meritocracy. Understand this: if the enemy invaders (strikethrough) acquiring organization is riddled with cronyism (see last week’s blog) or displays other evidence of managerial pathologies, then your prospects are dim, indeed. But there’s one attribute that will always be appreciated, particularly in dysfunctional organizations: loyalty. If you can convince the acquiring organization’s managers that your devotion has been completely and seamlessly transferred to them, your chances of survival will go up considerably. The downside of this approach lies in the fact that, at some point, you will be expected to accept as normal any organizational pathologies that the new owners have accumulated.  Even if you can tamp down your own professional aversion to them, the members of your project team will quickly come to the realization that you have exchanged your values for the opportunity to blend in with the new management team – not the best of reputations to acquire.

Very much like “communication,” “collaboration” has taken on a kind of sought-after-for-its-own-sake aura, as if the actual objective of the collaborating project team(s) is somehow outside the realm of evaluation. Just keep in mind: the Borg from Star Trek were (are? Will be?) great at collaboration. Doing great things? Not so much.

[i] Retrieved from http://www.merriam-webster.com/dictionary/collaboration  at 20:29  MDT on 19 March 2016.

In last week’s blog, I made the argument that expanding and enhancing communications for its own sake is inherently dangerous, since there are going to be people in the organization who (a) are actually against you and your technical agenda advancing, and (b) will never willingly reveal themselves to be your adversaries. The actual structure I used to describe the members of the project team was:

1. Those who readily embrace the change you are attempting to implement,
2. Those who will eventually embrace the change you seek to implement, but only after they are convinced that it will benefit them directly,
3. Those who will resist until they are virtually forced to participate, and
4. Those who will be dead-set against you and your technical approach to the end.

That last category – the Ds – are analogous to one of the four archetypes described by the excellent Michael Maccoby in his book The Gamesman, the one he calls the Jungle Fighter.[i] The Jungle Fighters will use calumny, deceit, and other cloak-and-dagger tactics to get ahead, since they are generally untalented in the technical aspects of their jobs. They are, however, very good at hiding their true intent and the counterproductive nature of their favorite tactics.

How, then, can the astute PM learn to recognize the Jungle Fighters and Ds in the project team?

First, let’s deal with the organizational environment where they live. Just as it’s useful to know that a black widow spider has a red hourglass-shape on the abdomen, it’s also fairly useful to know that they like to live in places like wood piles, and that their webs are fairly chaotic in appearance. Similarly, Jungle Fighters/Ds prefer organizations with the following characteristics:

• Organizations that are truly merit-based in their hiring and promoting decisions are anathema to Jungle Fighters, since actual merit isn’t their long suit. Conversely, organizations that are infested with cronyism (or, under certain circumstances, nepotism) attract them by the boat load. If the most talented people are notably absent from upper management, the odds are pretty good that you are in the company of Ds.
• Are ex parte conversations allowed? If you need to spend any time worrying about what your peers are saying about you behind your back to your management, you may have a Jungle Fighter problem.
• Think back to a time where upper management addressed a significant problem, but their approach didn’t work. Were there any dissenters early on? If there weren’t, it could mean either that no one on the team recognized the soon-to-fail approach as weak, or else they did recognize it as sub-optimal, but didn’t want to risk speaking up. The stifling of communications from the rank-and-file upwards is an unmistakable sign of the presence of Ds.

As for identifying individual Jungle Fighters/Ds, here are a few sure tells:

• When stressed or frightened, does the suspected team member take on an aspect of angry condescension?
• Has the suspected team member attempted to gossip or engage in negative judgementalism about other employees?
• Develop objective measures for gauging each team member’s contribution towards achieving your scope on-time, on-budget, and observe their progress against those measures. Ds may not consistently be in the lowest quintile, but they’ll struggle mightily to stay in the upper half of performers.

Enhancing communications within a project team is nominally a good idea, since information is the life-blood of the organization. Just be careful of who shares in those communications – they may have either an hourglass shape, or the letter D, rendered in red on their abdomens.

[i] Maccoby, Michael, The Gamesman, Winning and Losing the Career Game, Bantam Books, 1978.