Game Theory in Management

In my last blog I made the observation that those seeking to advance project management capability in the macro organization tend to fall in to one of two groups, whom I called the Processors and the Effectives. Processors, as one might guess, love the process of performing project management practices, and tend to define PM success as having a project team demonstrate compliance with procedures. Conversely, Effectives will define PM success as actually bringing their projects in on-time, on-budget, or even early and under-budget. I wrapped last week’s blog speculating that the Processors, by definition, had very little opportunity to bring innovative approaches to the table. That may have been a rash assertion.

If others on the project team aren’t “doing” project management, there are two broad categories from which the Processors can pull their tactics: if the Processor is of high rank, they can attempt to leverage their organizational power to compel compliance. However, if our Processor is of equal or lower status, they are reduced to whining and eat-your-peas-style hectoring to change the behavior of their associates. 

The first category, that of attempting to leverage organizational power to compel an advancement in project management capability, never works in the long-term. Some short-term “success” may be realized, sure, as the project team becomes painfully aware that the prospects for their continued employment may hinge on how effectively they can perform the added requirements placed upon them as they pursue the project’s objectives. However, as soon as they can opt out, they inevitably do, leaving the macro organization no better off than before. This is especially true if the added procedural burden doesn’t have any clear link to the project’s overall success in cost, schedule, or scope performance. Indeed, the leaned-on project team will often come away with an embittered perspective on project management in general, and will tend to avoid (or even openly eschew) it in the future, all thanks to the way the Procedurals like to try and advance PM in their teams.

The second category – hectoring and whining – can (and often does) assume the audio acceptance level of a dentist’s drill on a molar needing a filling replaced. But there is a variety of hectoring that invites innovation, and is, in fact, somewhat compelling. This is the appeal to sophistication.

The appeal to sophistication works on Processors like catnip. Not only can they nakedly assert that others ought to be doing that project management thing they way the Processors want, but it goes without saying that to do otherwise is, well, kind of dumb! How convenient! Leveraging off of the fear of the project team’s members looking intellectually backwards, the Processors can advance all sorts of charlatanisms, to wit:
•    Gaussian curves have nothing to do with project performance. But the risk managers have many, many bamboozled to believe that, without a “proper” risk management analysis and plan, their projects are doomed.
•    Past letting the project team know how much they’ve spent, the General Ledger has nothing to do with project performance. However, the accountants have led so many to believe that any insight on business information that involves costs simply must come from them that virtually all textbooks on quantitative analysis in business begin and end with the return on investment calculation, which is virtually worthless in PM.
•    Communications are great – except when they’re not. Keeping “stakeholders” abreast of project performance is nominally a good thing … except when the definition of “stakeholder” includes those who actively oppose your project attaining its objectives, which the definition held forth by the communications experts often does. In those cases, keeping these “stakeholders” apprised is sheer idiocy.

I could go on (and often do), but I’m sure my readers see my point: Processors don’t actually advance project management as a science; rather, they use pseudo-science tripped out in PM phrases as leverage to try and convince others to do as they say, and respect them for saying it.

And I think that’s dumb.
 

In the near-science of Economics, two predominant free-market theories stand in stark opposition to each other: Keynesianism, named after John Maynard Keynes (1883 – 1946), and Economic Freedom, probably best articulated by Friedrich Von Hayek (1899-1992) and Milton Friedman (1912-2006). Each of these schools of economic thought has their adherents, with probably the most articulate ones today being Paul Krugman and Thomas Sowell, respectively. So, I have to ask: is there a similar theoretical divide within the project management community?

I believe there is, and, from my observations, they fall along two lines of thought: the first group, whom I’ll call Processors, tend to devote time and energy into perfecting the process of project management. They love to identify “best practices,” and encode these into official procedures that the macro organization is then compelled to follow, to the letter. Failure is determined by the frequency and level of infractions against approved procedures, and success is attained when the process is followed perfectly.

The rival camp, whom I’ll call Effectives, are not only reluctant to embrace proceduralized “best practices,” they will often actively oppose them. Instead, they are interested in adapting the tools and techniques that improve their chances of bringing in their projects on-time, on-budget. If, say, the risk managers want to perform an extensive analysis on the cost and schedule risks involved in a large project, with the end-product being something that an Effective won’t (or can’t) use in coming to informed decisions, the Effective will, in all probability, refuse to fund the risk analysis.

Are you wondering which you are? Well, I’ve devised a little multiple-choice test to help determine this.
1.    You have let a $100,000 (USD) contract, and the winning contractor bid $75K in labor costs, $25K in heavy machinery. The project’s complete scope is delivered on-time, but the final costs were $75K in heavy machinery, and $20K in labor. Was this project a success?
a.    Yes, of course.
b.    No, the original estimate was wrong, meaning someone cheated.
c.    What does the rest of the project team think? Are they happy?
d.    No, because the overhead rates are different for labor and machinery.
2.    Your estimator has created a detailed estimate for your project’s cost baseline, and it has been time-phased and integrated into the schedule baseline. What should the estimator do now?
a.    Work on the next project, and leave you alone.
b.    Stay around to continually re-estimate the remaining work, add that on to the cumulative actual costs, thereby generating an Estimate at Completion.
c.    Stay around to do alternative analyses, or other stuff.
d.    Stay around to continually compare the line items in the basis of estimate with their analogous counterparts in the General Ledger as costs come in.
3.    You are a director of your organization’s PMO, and you have a meeting with the newly-assigned manager of a major project. This manager was put in that position because of her advanced technical knowledge, and formal PM techniques are really not her long suit. After introductions, you begin the meeting by saying:
a.    I have some examples of the kinds of cost and schedule performance reports our tools can generate for you. Can you indicate which of these you believe will give you the confidence that you are on top of your project as it pursues its scope?
b.    I have some copies of the procedures this organization has published with respect to how you are to conduct your project management activities. Would you like me to tell you how your project team can attain compliance?
c.    Can you tell me what you want out of your project controls?
d.    Were you aware that the information from the general ledger does a better job than these Earned Value and Critical Path guys?
Scoring: Each “a” is one point, “b”s are two, “c”s are three, and “d”s are four.
Less than 4: You are an Effective, and I’m actually a little surprised you took the time to read this blog.
4 to 6: You are a Processor, and probably view anyone who selected an “a” response to be an undisciplined rube.
7 to 9: You are in the mushy middle, which is perfectly understandable, considering the conflicting assertions in the PM media.
Over 9: Don’t you accountants have your own websites and blogs to read?

My prediction is that innovations in project management will tend to fall along the lines of the tools and techniques that deliver more on-time, on-budget projects (such as Agile/Scrum), or those approaches that represent more formal observance of process – if such things can even be called “innovative.”
 

As a service to my ProjectManagement.com readers, I read other PM-oriented magazines, journals, websites and blogs, usually just to make sure ProjectManagement.com is the best among them (it is), but other times I like to see what passes for the current conventional wisdom, to see if there’s anything really easy to mock. And the gift that keeps on giving, somewhat similar to “Weird” Al Yankovich consistently parodying Michael Jackson songs, is the risk management industry.

The pieces I read aren’t by amateurs, either. They’re usually written by well-known risk management experts. These columnists and bloggers aren’t stupid, uneducated, or naïve – they’re just wrong, and the fact that the vast majority of what passes for risk management-derived insight is actually intellectually vacuous can be established with a few simple mental exercises.

But first, a little background on Management Information Systems (MISs). They methods they use to convert data into usable information can all be grouped into one of two categories: feedback, and feed-forward. Feedback systems use actual data, observable, quantifiable and verifiable elements of fact that have already occurred. The information these systems deliver is fairly reliable, and includes such MIS stalwarts as the General Ledger, Critical Path, and Earned Value methodologies. The main issue with these systems is timeliness – the older the information, the less useful it is, meaning that during the time it takes to collect the data, process it into information, and deliver the information, its usefulness is eroding.

Conversely, feed-forward systems are based on what someone believes is going to happen in the future. These systems are not considered reliable, since we don’t know what is going to happen in the future. For the record, all risk management techniques, including decision-tree, Monte Carlo, and risk classification, fall into this category. By the very nature of risk management techniques, they are inherently unreliable.

Next up on the genuine science that stands athwart of risk management theory is Metcalf’s Law, also known as the Butterfly Effect. Metcalf’s Law stipulates that, in large networks with high levels of interconnectivity, relatively small changes in some nodes has the capacity to initiate large, even cataclysmic changes through a cascading effect on other parts of the network, even those previously considered remote. Hence the nickname, summarized by the rhetorical question “If a butterfly flaps its wings in Brazil, does that cause a hurricane in Texas?” Manifestations of Metcalf’s Law occur all the time, including blogging. Take two PM bloggers at random, and total their monthly hits – let’s just use 10,000. There’s absolutely no way each blogger gets around 5,000. One will invariably get 9,000, the other 1,000. That’s just the way networks perform. But risk management is entirely predicated on the idea that the average – schedule duration, cost, whatever – parameter among analogous activities is a reliable data point, from which an expected future can be extrapolated. Metcalf’s Law says otherwise.

But that doesn’t stop the risk management types from trying, no sireee. One estimate of the value of the risk management industry worldwide puts it at over ten billion dollars – that’s $10,000,000,000. And their assertions invariably bend towards asserting that any cataclysmic event could have been foreseen – and, therefore, avoided – if there had only been sufficient risk analysis performed.

However, as we have seen, Metcalf’s Law stands in direct contradiction to current risk management theory. Since hurricanes over the centuries have certainly caused more than $10 Billion in total damages, we have a simple choice before us: either ignore the risk managers when they try to tell you how valuable their speculations (strikethrough) analyses are, or else find that *&^$% butterfly in Brazil, and kill it before Galveston gets creamed again.
 

What a wholesome theme for July, right? Innovation – with its roots in Latin, it just sounds cool. Who in the ProjectManagement.com world could possibly be against it? Correct answer in 5…4…3…2…

Of course I’m against it! Well, not against “innovation” per se, rather what has been foisted upon the world of management science in the name of innovation. The normal advancement of the management sciences, particularly those dealing with project management specifically, is hindered (if not introduced to periods of out-and-out stagnation) by the common use of two tactics, both involving an invocation to “innovation”:

1.      Some tried-and-true approach, analysis technique, or tool is given a new moniker, and rolled back out as something innovative when it is, in fact, anything but. With a façade of newness attached to it, those perpetrating this variety of hoax hope to gain more attention and epistemological ground than they otherwise could. Examples include “critical chain” scheduling, better known by its previous title “crashing the schedule,” and “life cycle costing,” known for decades as “the right way to do an estimate.”

2.      An invalid approach, analysis technique, or tool is introduced. It’s new, alright (Dictionary.com’s definition of “innovation” is “something new or different introduced.”[i] ) – they are also often openly fraudulent.

Examples of the second type are all around the typical PM practitioner. My regular readers are used to my taking shots at risk management, or accountants over-selling the efficacy of the information stream emanating from the general ledger, so I’ll take a break from those (rather easy) targets, and go on to other hacks who have, nevertheless, made significant inroads in to what is considered the project management body of knowledge under the guise of being “innovative.”

The next easiest targets are probably the communications experts. Almost everybody who works for a living knows that conflict is common in the office, and project teams are certainly no exception. Then, along come the communications experts, who assert that much – if not most – of this conflict exists simply because we misunderstand each other. Heck, virtually the entire run of Star Trek – The Next Generation used this premise to drive its (insipid, really) plots. It should be pointed out that, at the time, ST:TNG was considered “innovative,” especially compared to its predecessor, Star Trek (nicknamed The Original Series, for clarity’s sake). As it turns out, abandoning classic plot structure in favor of “it was all a big misunderstanding” would prove to be a mistake, dooming thousands of Star Trek fans to the thin gruel of having to accept that humans were , at best, equals in the universe of sentient beings, inferior frequently, and using our wits or superior weaponry was simply blasé. Thanks, innovative writers.

Then there’s the surge in creating so-called “enterprise management” systems. These are software vendors pushing the idea that, if you only purchase their product, they will deliver the whole management information enchilada: the erstwhile entrepreneur or program/portfolio manager will become the ultimate go-to guy for profoundly informed decisions, don’t you know. Check out their websites – if you come across one that does not include the word “innovation” or “innovative,” let me know. Or, save yourself the trouble, since I’m guessing they’re pretty rare.

Here's a quick-and-easy litmus test: valid project management science innovation will usually be presented by someone who says “I think I have a better way to reach your project’s goals, and would appreciate an opportunity to show you.” Those who are selling PM snake oil, under the guise of being innovative, will, instead, imperiously insist that you adapt new meanings to well-known words (risk managers), expect you to “value” a certain output from their pet management information stream (accountants), or just generally want you to change your attitude to be more closely aligned with theirs. These are the charlatans, and don’t let them convince you that they are the innovators.

As the family and staff filled the great dining room in the morning and sat down to breakfast, I recommended that they carry on their duties as if nothing had happened the night before. Just then, the gardener came in.

“Newspaper!” he announced.

“Let me have that” ordered Ivan Gettim, the police detective.

“Did the report from last night run?”

“Yes, it is here. Just as you requested, too:

Mr. Stratmon was discovered near death, but managed to leave the room before collapsing. He was found, is recovering, and hopes to finish a bit of important work tomorrow before convalescing abroad.”

“Where’s the butler?” I queried.

“I didn’t do it!” stormed Maher.

“I didn’t say you did. Why are you so sensitive?”

“Well, it just seems that whenever this sort of thing happens, the consulting detective always suspects … nevermind. What is it that you wanted?”

“When does the mail go out?”

“By noon.”

“Did Mr. Stratmon tend to wear a certain outfit on days like today, and can you make those clothes available?”

“Sure.”

“Okay, everybody!” I announced, “beginning at 11:00, nobody enters the library. Don’t do anything markedly out of the ordinary, just avoid that room.”

Tut Tutworth was still seething from the previous night, when it was clearly demonstrated that (a) true strategic management is commonly at odds with the objectives of asset management, and (b) the information stemming from the General Ledger really has nothing to do with strategic management.

“What’s the point, Raspberry?” he stormed. “If the killer is close enough to be lured back, then you would almost certainly have tipped him off by telling everybody what they need to do to help set the trap!”

“Except the killer isn’t among the household staff, or immediate associates. Otherwise, Stratmon would have written the name down as he was dying. Yet the killer did know when Stratmon would be the only person in the library, indicating some level of observation or familiarity. Just leave this to Ivan and me, Tutworth.”

Tut stormed out, but Piem O’Dagger, head of the Project Management Office, spoke up.

“Okay, Raspberry, if you’re so sure that the reason Mr. Stratmon was killed was due to some matter pertaining to strategic management, you’re on very thin ice. Software packages that perform advanced strategic management analysis are commonplace – my shop runs one, in fact. It’s not as if Mr. Stratmon had exclusive control of some piece of information or insight that would be worth getting killed over.”

“Software packages that claim to execute strategic management are commonplace, you are correct, Piem.” I began. “But to actually do strategic management involves an entirely different set of methodologies and data than typically belong to PMO software, claims of ‘portfolio management’ capability notwithstanding. But, it’s getting close to 11:00, so, if you don’t mind…” I said, nodding towards the door.

Maher brought in a set of Mr. Stratmon’s clothes, and I switched in to them. As the library cleared out, I sat in his big chair, and swiveled it to face the large bay window overlooking the well-manicured grounds.  Ivan took up his position behind the auras, in the back of the room. Everything became quiet, and when the large grandfather clock in the entry chimed 11:30, I almost jumped out of the chair. Just then, I heard footfalls, coming closer to the library door. The door’s hinges creaked open, two more steps, and then the door closed. A thick, guttural voice spoke up.

“Alright, Stratmon. I don’t know how you got away from my attempt yesterday, but this time my instrumentation is flawless.” I heard the hammer click on a large-caliber revolver, and spun around in my chair.

“Raspberry!”

“Ian ‘the weasel’ Rockicide. I should have known. Who’s paying you this time?”

Rockicide glanced at a piece of folded paper in his button-down shirt pocket.

“What, you have the invoice on your person?”

“It won’t do you any good, Raspberry” he began. “In about two seconds, you’re going to be dead’ern him”

As I winced at an adult man using the term “dead’ern him,” Ivan emerged from the auras behind Rockicide, gun drawn. “Drop your weapon, and keep your hands where I can see them.”

Rockicide complied, and I walked over and retrieved his invoice from his shirt pocket.

“I should have known – it’s Monolithic, again. Just one thing, Rockicide: how did you kill old man Stratmon without leaving a mark?”

“It was easy. I put him on the mailing lists of every single software company that claimed to be able to do portfolio or strategic management, and the sheer number of solicitations, combined with their intellectually vacuous approach, literally sucked all of the oxygen out of the room. It wasn’t artificial intelligence he was after – it was business intelligence, and, after reading this one book, he was too close to figuring it out. It would have meant curtains for Monolithic, so they called me – and I almost got away with it!”

As the arriving police cuffed and took away Rockicide, I took Ivan aside.

“You’ll get my invoice at the end of the month. Also, I have to note that…”

“Don’t say it!”

“I must. Yet another case solved by Stanly Raspberry, Private Eye.”