Project Management

Game Theory in Management

by
Modelling Business Decisions and their Consequences

About this Blog

RSS

Recent Posts

Optimal Technical Approaches Almost Never Come In Cans, And Real Leaders Know It

Leading Towards A PM Culture

Don’t Become the Non-Leader

How risk management Dilutes Leadership

The Fourteen Most Terrifying Words In The PM Lexicon

Optimal Technical Approaches Almost Never Come In Cans, And Real Leaders Know It

I may be setting a record for the highest number of characters in a GTIM blog title, but I needed every single one of them to synopsize this week’s take on this month’s ProjectManagement.com topic, Leadership. An oft-overlooked aspect of managerial leadership is a subset of my three key aspects of it, to wit:

  • Sufficiently advanced expertise to identify the optimal technical solution to the problem in front of the Project Team,
  • A genuine concern for the members of the Project Team, and
  • A willingness to pursue the optimal technical solution, alone if necessary.

The oft-overlooked aspect I alluded to is a subset of the first bullet, identifying the optimal solution to the problem being pursued by the Project Team. Even a moment’s consideration of the situation must yield the obvious fact that, if one of the canned strategies that’s been around seemingly forever was clearly the ideal approach to take, why on earth would it need a PM to execute it? Doesn’t work that needs no innovative or creative approaches or solutions become rote?

And this is where I become frustrated with symposium paper-presenters. Not all of them, of course, but the ones who are not so much presenting new or innovative ideas as much as acting as well-mannered and polite scolds to those they perceive aren’t implementing Earned Value or Critical Path Methodologies to their satisfaction. These are not thought leaders, nor leaders at all. They’re more precisely defined as passionate followers, throwing their energies behind notions that have been around for decades. We all know the need to set up a Work Breakdown Structure; we’ve been told ad infinitum of the need to clearly and completely define the scope, and to honor the “triple constraint,” and to acknowledge that one of the baselines can’t change without impacting the other two, and to guard against informally changing the scope, and, and, and…

Enough already! This isn’t news to anyone who’s ever even studied for the PMP®. To help illustrate my point, let’s turn, once again, to the Game Theorists’ favorite tool, the payoff grid.

 

 

Non-Leadership Role

Leadership Role

Genuine Leader

(1A) Will probably be the one who (or belongs to the team that) develops the optimal tech solution

(1B) Is in a position to not only develop or recognize the optimal tech solution, but can implement it effectively

Fake Leader

(2A) Aspires to advance, but probably won’t get there on merit

(2B) Will be heavily reliant on canned strategies and already-established approaches

 

Practically speaking, the Type of Leader/Assigned Role profiles for scenarios 1B and 2A will be significantly easier to identify than scenarios 1A and 2B. Interestingly, scenario 1A represents a threat to being able to optimize Asset Management, while scenario 2B is a danger to Project Management. If a genuine leader has not been recognized for their abilities in such a role, the worst that can happen is that the organization isn’t using its assets to their potential. However, if a PM happens to belong to scenario 2B, and the project can’t perform adequately with only conventional techniques, then such a project is virtually doomed to overrun, come in late, or both.

“But wait, Michael!” I can hear GTIM Nation say, “What about your oft-cited derivative of the Pareto Principle, that the 80th percentile best PMs with access to only 20% of the information needed to obviate a given decision will be consistently out-performed by the 20th percentile worst managers who have 80% of the information so needed? Wouldn’t the existence of an adequate Earned Value Management System, combined with a decent Critical Path schedule and a functioning Change Control System, keep the scenario 2B manager from wrecking the project?”

Well, yes and no. The people I’ve observed who are entrenched in scenario 2B will tend to reject the idea that poor cost and schedule performance indicators could possibly be indictments of their technical approach to their projects’ scope, preferring instead to blame various members of the Project Team for not implementing the canned management schemes thoroughly enough to attain success. This kind of blame-shifting from the fake leaders in the PM role easily turns into a project performance tail spin, particularly if unrecognized true leaders happen to be in the ranks of the Project Team, and can see the actual source of the project’s difficulties, but are not in a position to properly address them.

“BUT WAIT MICHAEL!” I can hear the more readily agitatable members of GTIM Nation exclaim. “What if the performance measurement information actually influences the PM to re-evaluate their technical approach?” Well, if this is the case, then such a manager would have begun the transition from fake to genuine, leaving my analysis (mostly) intact.

 

Posted on: October 26, 2020 10:54 PM | Permalink | Comments (2)

Leading Towards A PM Culture

An awful lot has been written (with “awful” being the operant word here) about the PM’s role in “changing culture,” usually of the organization that the Project Team belongs to, in such a way as to expedite the use of PM tools and techniques within said organization, leading to an increase in the frequency with which projects are brought in on-time, on-budget. What seriously irks me about such assertions lies with the fact that the word “culture” is usually so poorly defined within these arguments that their assertions can basically be boiled down to “the members of the Project Team didn’t do as I said, or found some way to disappoint me, leading to the failure to …” install a Project Management Office, or advance PM capabilities within the organization, or bring the project in on-time, or any other disaster that happens to unfold. So, let’s turn to Dictionary.com for a usable definition of the term “culture.” Although several of the definitions (3 through 6) offered could apply, I’m thinking #7 is closest to fulfilling our purposes:

noun

  1. the quality in a person or society that arises from a concern for what is regarded as excellent in arts, letters, manners, scholarly pursuits, etc.
  2. that which is excellent in the arts, manners, etc.
  3. a particular form or stage of civilization, as that of a certain nation or period: Greek culture.
  4. development or improvement of the mind by education or training.
  5. the behaviors and beliefs characteristic of a particular group of people, as a social, ethnic, professional, or age group (usually used in combination): the youth culture; the drug culture.
  6. the shared beliefs, behaviors, or social environment connected with a particular aspect of society: the rape culture on campus; the culture of poverty; a culture of celebrity worship.
  7. the values, typical practices, and goals of a business or other organization, especially a large corporation: Their corporate culture frowns on avoiding risk.[i]

Now let’s zoom in on the three subject nouns in number 7:

  • “the values…” Does the organization value (a) “maximizing shareholder wealth” (the Asset Managers’ goal) over (b) meeting or exceeding customer expectations with regard to completing projects on-time, on budget, with all aspects of the negotiated scope well-fulfilled?
  • “…typical practices,” When the organization seeks to generate information on cost or schedule performance, does it (a) employ actual cost monthly burn rates derived from the general ledger, and milestone lists, or does it use (b) Earned Value and Critical Path Methodologies?
  • “…and goals of a business” Sort of a rehash of the first bullet. Does the organization seek to (a) make money directly, or (b) earn a profit indirectly by building up and maintaining a solid customer base?

If your eval of the bulleted questions returned even one (a) answer, you are most probably in the same confounded conundrum that has beset the vast majority of PMs since the start of Project Management as a distinct discipline. For virtually every business in its growth or maintenance of market share phase, (b) is clearly the best answer. One would not know this from the curriculum of almost every business college in the world, though. They have been dominated by the Asset Managers’ view of corporate commerce techniques since the time of Machiavelli (a coincidence?), and show few signs of losing their epistemological grip on academia, if not the industrialized world.

All of which brings us back to the notion of culture change. In those organizations lucky enough to have a strong PM culture, I’d be willing to bet that it did not come about because the execs in the Finance and Accounting Department had a sudden epiphany, and gladly handed the technical agenda for producing project-related management information streams over to the PMI®-types. Nor am I inclined to believe that it came about due to an infiltration of PMs re-writing a bunch of procedures, and getting some executive to sign off on them. No, my money is on a handful of courageous and insightful PMs actually (if not surreptitiously) embracing PM culture, and using its manifestations to bring in projects on-time, on-budget, including functional EVM and CPM systems, leading to the establishment of a solid customer base.

Unfortunately, this last approach also happens to be the longest. So, yeah, the PMO can “change culture,” just not directly. The kind of change that challenges and eventually overcomes literal centuries of Asset Management rules and techniques probably never comes about from a frontal assault-style approach. It has to be done one project at a time, then one program at a time, before it can move on to portfolios, organizations, and entire industries.

And that’s how PMs’ actions can lead to culture change.


[i] Retrieved from https://www.dictionary.com/browse/culture on October 18, 2020, 20:04 MDT.

Posted on: October 20, 2020 12:07 AM | Permalink | Comments (2)

Don’t Become the Non-Leader

In last week’s blog I listed the three key characteristics of a managerial leader, and then wrote about how the risk managers’ (no initial caps) agenda actually undermines that function. This week I would like to take that a step further, and discuss how to avoid attaining a leadership position by means other than through merit. I’ll begin by addressing the three easiest red-flags, derived from last week’s blog. To wit, if:

  • You are not pursuing the optimal technical approach to the problem in front of the team, or
  • You feel indifference, or even contempt, for the people on the team, or
  • You have no skin in the game, i.e., no apparent personal stake in the successful outcome of the organization’s work, then…

…you may have arrived at the leader role for reasons other than merit. The next set of clues are a bit more subtle, but can be just as telling.

Consider what tends to happen when a garden variety new manager is brought in to an existing organization. The newbies typically have an expectation that the organization’s current performance is the baseline, and things will only get better now that they are there. Working from this assumption, take a look at what probably presents as the biggest threat, that their new technical agenda will be thwarted or frustrated by uncooperative extant personnel. For this reason, whenever a new manager comes into an organization, the tendency may be to attract, find, and reward loyalty, not talent. Why should talent be an issue? The organization was clearly performing at an acceptable level prior to the newbie arriving, and the newcomer represents an influx of talent, right? So, upmost in at least some rookies’ minds is to move through the Tuckman’s Stages of Group Development dynamic, specifically

  • Forming
  • Storming
  • Norming
  • Performing

…in such a way as to minimize the Storming phase. The newcomer may desire a return to organizational stability, with a subsequent cruise on into Performing space.

Here’s the problem with this entirely predictable, but strategically unsound approach: with the exception of replacement scenarios, the whole reason a new manager was introduced in the first place was usually because the target organization’s performance was disappointing, or even unacceptable. If the characteristic being sought out and rewarded is loyalty, then odds are that things are about to get worse. GTIM Nation knows of my respect for the brilliant Michael Maccoby, and his book The Gamesman, The New Corporate Leaders (Simon and Schuster, 1976). By attracting and rewarding loyalty rather than talent, the Maccoby archetypes that will succeed are the Company Men and the Jungle Fighters (who will feign loyalty), all at the expense of the most talented archetypes, the Craftsmen and Gamesmen. Put simply, this is an extremely hazardous transition strategy. With Company Men and Jungle Fighters placed in positions of authority over the Craftsmen and Gamesmen, the odds of arriving at the optimal technical approach – the very first characteristic of the managerial leader – have plummeted. Indeed, members of the latter two archetypes will tend to flee such organizations, likely to be replaced by more “loyal” team members, i.e., Company Men and Jungle Fighters. From an organizational behavior and performance point of view, this can easily become an unmanageable morass.

I mentioned last week that, in addition to the three essential characteristics for managerial leadership, an additional element – courage—was also key to success, and here’s another area where that becomes a factor. It takes a good measure of courage for the newly introduced manager to listen to those in the organization who may disagree with them, and to patiently and even-handedly review their criticisms’ validity before rejecting them and attributing their motivation to a lack of respect, or even insubordination. In short, newbie managers who aspire to legitimate leadership roles should never fear the Storming phase from Tuckman’s Stages, and instead use it as an opportunity to gauge which members of the inherited team are both talented, and have a personal stake in a successful outcome, the proverbial “skin in the game.” So, what’s the litmus test for whether or not criticism from the Project Team represents a legitimate technical approach alternative, or simply snarky opposition? If it’s not clear based on content, consider if the criticism/recommendation was intended to benefit the entire team, or just a subset (or even the critic alone). If it’s the former, it could well be legitimate. If the latter, not so much.

I would think it rather impossible to advise on how to become a leader in an 800-word weekly blog. But I do believe that such a venue does support relaying tips on how to avoid finding yourself in the role without a few foundational elements in place. In short, don’t become a non-leader.

Posted on: October 13, 2020 02:54 PM | Permalink | Comments (6)

How risk management Dilutes Leadership

Lots of pixel ink has been spent attempting to define Leadership (ProjectManagement.com’s theme for October), typically as a preamble to instructing those who do not come by those qualities naturally on how to acquire them. I think such trains of thought are on the wrong track, particularly when the discussion turns to whether leaders are born into the role, or if they learn the necessary characteristics over time (i.e., are “made”). As GTIM Nation knows, I have previously laid out the three characteristics that I believe are central to the success of anybody who aspires to the role of managerial leadership, so:

  • The managerial leader must be knowledgeable enough in their field to identify the optimal technical approach to resolving the scope being pursued by the Project Team or organization. Inept leaders soon find themselves with few or no willing followers.
  • The managerial leader must care about the organization they have been assigned to head. The manager who does not care about the people working for them (or worse, holds them in contempt, or believes them to be basically interchangeable) can’t help but let such an attitude slip in front of their charges. Once the organization or Project Team knows that their leader doesn’t care about them, they will cease to care about the leader, as well as pursuing his technical agenda.
  • The managerial leader, after having correctly identified the optimal technical approach to the organization’s mission, must be willing to invest her own energy and time to pursue it, alone if necessary. The brilliant Nassim Taleb describes this as “skin in the game,[i]” but my favorite metaphor for this characteristic has to do with World War II general George Patton. I’m fairly confident that, had Patton not been put in charge of the U.S. Third Army, and had instead been parachuted into the middle of Europe circa 1943, he would immediately begin attacking members of the Axis Powers, and not wait (nor whine) for whole armies to back him up.

A key component of this last bullet is courage. The willingness to pursue strategies that are derived from novel approaches to problem resolution will almost certainly draw criticisms from those who have previously tackled analogous problems in a different manner, and often these criticisms can become positively cacophonous. The problem, of course, is that novel approaches to problem resolution that are actually sub-optimal, or even flat-out wrong, will also draw criticism, meaning that the virtue of courage in managerial leadership is immediately converted to vice when the first bullet, having the technical expertise to correctly identify the optimal technical approach, is given short-shrift, or ignored.

Meanwhile, Back In The risk management (No Initial Caps) World…

With all of this as a backdrop, let’s take a look at the actual mechanics of developing a risk management plan or project risk analysis. The risk analyst, with Work Packages in hand, interviews the Subject Matter Experts on the Project Team in order to ascertain

  • Potential impacts
  • …of potential occurrences
  • …expressed in amount of time added to the Schedule Baseline,
  • …or resources added to the Cost Baseline.

Keep in mind that only in rare instances are the SMEs involved with the actual Scope Baseline also trained cost or schedule estimators, meaning that, even if they somehow have insight as to the odds of an in-scope, uncosted event occurring, they can only guess at the figure for the cost/schedule impact of said event. To quote the late Michael Crichton, guessing at parameters in a structured formula is simply an exercise in expressing our own prejudices. Also keep in mind who these SMEs are – members of the existing Project Team, and usually not the PM’s superiors. In other words, the entirety of the risk analysis is essentially to produce an expensive document of the PM’s organizational inferiors speculating on what could go wrong with the selected strategy, and substituting their prejudices for usable data parameters in order to add credence to the whole exercise.

Do I have to say it? This is not how leaders in general develop their strategies, nor how Project Management leaders in particular produce and pursue a technical agenda. Indeed, to allow a risk analysis to drive (or even influence) the production or pursuit of a given technical agenda is to allow the vague and poorly-quantified worries of those within the existing Project Team to determine the path forward, the precise opposite of leadership.

Engage the risk managers if your customer insists that you do so, but feel free to only pretend to ingest and respect their “analysis.” Then you can get back to doing real PM stuff, including leading.


[i]Taleb, Nassim, Skin In The Game, Hidden Asymmetries in Daily Life, Random House, 2018.

Posted on: October 05, 2020 10:35 PM | Permalink | Comments (8)

The Fourteen Most Terrifying Words In The PM Lexicon

As GTIM Nation knows well, I maintain that Project Management Information Systems (PMISs) in general, and Earned Value Management Systems (EVMSs) in particular, serve two primary purposes:

  • They put into the hands of the organization’s decision-makers the information they need to make, well, informed decisions, and
  • They provide an audit trail to help explain the reasoning behind the multitude of decisions made during the execution of a project, for the purposes of creating a lessons-learned document, or for other, more nefarious evaluations.

It’s these more nefarious evals that drive a particular business model pathology. Since the Earned Value and Critical Path Methodology information streams provide a window into how projects are performing, and clients can respond generally either in a positive or negative fashion, the four possible scenarios can be evaluated using the Game Theorists’ favorite tool, the payoff grid:

 

 

Project Performs Poorly (A)

Project Performs Well (B)

Customer Reaction is Positive (1)

Wow, great customer! (or else this is an FFP)

Good for now, but what happens if things go south?

Customer Reaction is Negative (2)

What did you expect?

If they’re negative now, what will happen if things get worse?

 

Since Scenario 1A almost never happens, at least not to customers who are actually paying out money for the Cost Baseline as agreed-to (Firm Fixed Price Contracts are a different animal, but this is still a rarity, since poor-performing FFPs are likely to finish late). Even if they present as being content in the Project Review Meetings, you can bet real money that, the nanosecond they leave the presentation, they will be seeking means of extra-project remedy.

As for Scenario 1B, consider your own reaction when, say, you learn that a long-awaited and highly-coveted item is to be delivered to your home, and your on-line tracking app tells you it will be delivered two days earlier than originally scheduled. You’re thrilled; but, when the new, early date arrives, and no delivery takes place, how do you feel? Are you not keenly disappointed, if not furious? The shipper would have been better off in customer retention space if they had never asserted an early date in the first place since, had they not done so, and managed to have the item arrive just one day early, you would have been much happier, no? But now, after they’ve “promised” the item two days early, and failed to deliver it then, if they do manage to have it arrive one day early, all of the good will that would have been nominally generated has been blown to smithereens. In short, providing good cost or schedule performance information to the customer can be a mixed bag.

I’m going to jump to Scenario 2B, for reasons that will become clear. Some clients are inherently difficult to please – if the customer reacts in a negative fashion when things are going well, the Project had better finish with stellar performance figures. Otherwise, your organization will be vulnerable to the kind of narrative review that usually accompanies poor performing projects.

Finally, when you hand over the Earned Value and Critical Path reports that show precisely how badly your project is performing, and brace yourself for the inevitably reaction, one thought simply cannot be avoided: If I don’t have to, why should I give up this information?

I’m going to score Scenario 1A as a 0.5, due to its rarity, and Scenario 1B as a 0.75, per its explanation. This means that, based on our Payoff Grid, an advantage to providing the customer accurate cost/schedule performance information only scores a 1.25 out of 4.00, meaning, in Game Theory space anyway, it’s a bad idea to volunteer it if it’s not contractually required (which is, no doubt, why Earned Value and Critical Path-based reporting are so often contractually required). Which leads us to the fourteen most terrifying words in the PM lexicon, sometimes uttered when (1) the PM realizes that there’s a downside to volunteering accurate cost/schedule performance information, and (2) the PM thinks the customer will put up with squelching said information from being passed along: “It costs as much as it costs, and takes as long as it takes.” To be sure, this is a fairly accurate statement for many a high-tech project, where no reasonable basis for forming a cost/schedule baseline nor assessing percent complete exists. But for all other projects, The Fourteen Words imply something far more disturbing: your PM does not perceive that he is beholden to the customer’s expectations of cost or schedule performance. The reason I’m bringing this up in September, with ProjectManagement.com’s theme of Agile/Hybrid PM, is because invoking an Agile or Hybrid Project Management approach or strategy can often be used in lieu of The Fourteen Words, and that’s truly unfortunate. A simple Earned Value system can easily provide accurate cost performance and at-completion forecasts, even in Agile/Hybrid environs, and anyone who tells you differently is, well, wrong.

Or perhaps they’re just trying to avoid providing such information without actually uttering The Fourteen Words…

 

Posted on: September 28, 2020 11:10 PM | Permalink | Comments (2)
ADVERTISEMENTS

"Tragedy is when I cut my finger. Comedy is when you walk into an open sewer and die."

- Mel Brooks

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events