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.