Rookie mistakes in Risk Management

---

First comes the planning

You've followed all the standard protocols for setting up your risk management program.

You've put slack in your cost estimates, and you've put slack-buffers in your schedule plan.

All good.

Risks have been listed, prioritized, and the minor ones to be 'unmanaged' set aside (minimize distractions)

Otherwise, mitigation planning has been done.

All good.

Now comes execution

There are a lot of ways to screw up risk management. No news there, but ,,,,,

Rookies sometimes do these things, but, of course, you won't:

• Rookies ask for, or accept, single-point estimates from team leaders, work package managers, or analysts. This is a big mistake!
  
  Estimates should be given as a range of possibilities. No one works with single-point precision, and no one works without control limits, even in tried-and-true production regimes.
  
  And you should recognize that 'far-future' estimates are almost always biased optimistically, whereas near-term estimates tend to be neutral or pessimistic.
  
  Why so? First, "the future will take care of itself; there is always time to get out of trouble". And second, near-term, "we have all the information and "this" is what is going to happen; there is little time to correct matters".
  
  
• Rookies sometimes consume the slack before it's time. What happens is that rookies fall into the trap of "latest start execution" when it comes to schedule; and, in cost management, rookies often put tight controls on last rather than first, or early on. Then, when they need slack, it's already been consumed. Oh crap
  
  Experience and wisdom always argue for using slack last, hopefully not worse than 'just in time'

• Rookies fall for the "1%" doctrine. In the so-called "1% doctrine", a very remote but very high impact event or outcome has to be considered as a 'near certainty' because of this risk matrix math: "very very small X very very large = approximately "l" (*).  Or, said another way: "zero X infinity = unity (or 1 or 100%)". 
  
  Accepting that doctrine leads rookies to spend enormously to prevent the apocalypse event. But actually, 'nearly 0' is a better approximation than 'nearly unity' (in arithmetic, 0 times any finite number is 0)
  
  What about the 'infinity' argument? Well, actually 'zero x infinity' is at best matter of 'limit theory' for one thing. And that's not easy stuff. But actually, anything times infinity is 'indeterminate' and thus not a workable result for the PMO. (**)
  
  Put the math aside. Isn't this about risk-managing a 'black swan' event you can actually imagine? Perhaps, but that doesn't change the conclusion that 'nearly 0' is the best value approximation.

----------------------

(*) In probability statements, "1" is understood to be all possibilities, or a confidence of 100%

(**) But more specifically, general laws of mathematics are not applicable to equations with infinity. It's commonly understood that if you multiply any number with 0, you get 0, but if you multiply "infinity" with 0, you get an indeterminate form, because infinity itself is not determined yet. Our science currently has 7 indeterminate forms; infinity is one of them. 

Of course, the good news is that we've advanced beyond the ancient Romans who have no Roman numeral for zero. It was not considered a number by them.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Managing schedule: who's in charge?

---

I written this before: "The critical path (CP) and the most important path (MIP) are different more often than you might think."

• We all know the definition of the CP: the longest path from project inception to project ending. 
• The MIP is the path, long or short, to the most significant value-producing project outcome. This might be the actual project ending, but more often it is not. Sometimes a small item, required but not critical to success hangs out as the CP. 

Two protocols

The standard protocol for resourcing a project is to provide the CP with all the resources necessary -- and in the right sequence -- in order to prevent a slip-to-the-right of the end milestone. In this wisdom, all other requirements are subordinate to the needs of the CP.

But a protocol centered on value-production would not necessarily fall in line with subordination to the CP. Indeed, the 'value managers' will argue that their needs are superior and primary. (*)

Management needed here

Thus the question is begged: who makes all these decisions about resources assigned to the schedule, and whether or not the schedule is to be managed with CP or MIP protocols?

And, who manages the buffers, and who manages the constraints (roadblocks)?

 

The 'standard answer': The buck stops with the PM, of course. 

Well, not exactly! Not all the time.

The user group, the sponsor, the business team all have a influence on the MIP vs the CP choice.

Influence: yes, but that's strategy thinking. Tactically, and ultimately, the PM is the decider.
 

Confound it!

So you've got your strategy: MIP or CP; and you've got your tactics about buffers and sequence. But, sometimes there is a confounding factor (**), described this way: 

You've got a job to do; the protocol decision has been made. From that point, you've sequenced and scheduled it, taking into account the resources made available to you.

But, in the middle of your schedule there is another independent project (or task) over which you have no control. In effect, your schedule has a break in its sequence over which you have no influence.

Yikes! 

This is all too common in construction projects where independent "trades" (meaning contractors with different skills, like electrical vs plumbing) are somehow sequenced by some "higher" authority.

So, what do you do?

If you have advance notice of this situation, you should put both cost slack and schedule slack in your project plan, but there may be other things you can do.

 

Cost slack is largely a consequence of your choices of schedule risk management. 

Schedule risk management may have these possibilities:

• Establish a coordination scheme with the interfering project .... nothing like some actual communication to arrive at a solution
• Schedule slack in your schedule that can absorb schedule maladies from the interfering project
• Design a work-around that you can inexpensively implement to bridge over the break in your schedule 
• Actually break up your one project into two projects: one before and one after the interposing project. That way, you've got two independent critical paths: one for the 'before' project and one for the 'after' project

 At the end of the day: communicate; communicate; communicate!

-------------------

(*) I wrote a couple of books on this topic: Managing Projects for Value

(**) An influence that is in the background of two or more plans or events that correlates or connects between them

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Leadership by link and buffer

---

"Link and Buffer" is a leadership concept for a leader positioned between a governing board, to whom they must link the project, and a project team which must be buffered from the whims and biases of the board.

Fair enough

But it's not that easy.

In the "link and buffer" space live various skills:

• Vision and practicality: to the board, the project leader talks strategically about outcomes and risks; and about the strategic direction of the project. But, to the team, the leader talks practically about getting on with business. All the tactical moves are effectively smoothed and buffered into a strategic concept which the board can grasp
  
  
• Tempers and angst: When there's trouble, tempers fly. Buffering is a way to decouple. The board's angst does not directly impinge on the project if properly decoupled by the project leader.
  
  
• Personality translation: Few on the project team will know or understand intimately the personalities on the board. Taking the personality out of the direction and recasting instructions into a formula and format familiar to the project team is part and parcel of the buffering.
  
  
• Culture translation: In a global setting, the board may be culturally removed or distant from the project team. Who can work in both cultures? That of the board, and that of the project team? This is not only a linkage task but a translation task to ensure sensitivities are not trampled.

Examples of "link and buffer" abound in military history. Perhaps the relationship between Admiral Ernest King and Admiral Chester Nimitz is most telling. King was in Washington during WW II and was Nimitz superior in the Navy chain of command. Nimitz was in command of the Pacific Ocean Area from his HQ in Hawaii.  

 

King was responsible for a two ocean Navy in a world war; Nimitz more limited. Nimitz was the link and buffer from the tactical fighting admirals at sea, and the strategic war leaders in Washington.  No small matter!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

When mystery is actually progress

---

Got a mystery in your project?

Can't figure out what's happening, or

Can't find the root cause -- after following all the methodologies -- for what you measure or observe?

Perhaps you are making progress!

Stuff happens; don't deny; it's yours to figure out why

Once you do, you may have discovered something quite fundamental about the project outcomes 

There are lots of examples:

• There is a lot of dark matter in the universe; why is there more dark matter than visible matter?
• There are missing particles in the Standard Model of particle physics; where are they?
• Why does the speed of light not conform to Newtonian physics (Einstein worked that out, fortunately)
• Why does your bridge collapse after you built it with a lot of steel?
• Why do team mates fly off the handle when you mention X or Y? (Note: no religion or politics in project teams)

 So, there are a lot of examples. What do you do about it?

• Try Bayes methods of hypothesis testing ... make a prediction (perhaps, gasp!, a guess for lack of something better); test for results; change a parameter and look again. Repeat ....
  
  
• Try models: why does the model work and the system doesn't? (NASA calls something like this 'model based system engineering -- MBSE')
  
  
• Get out of the frame and look from a different vantage point. That's what Einstein did.
  
  
• Try forensic engineering or investigation. This is micro-engineering at the nut and bolt level.
  
  
• Change direction and do something entirely different (not retreat; just advance in a different direction)
  

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Why do they call it a 'black box'?

---

Why do they call it a black box? Maybe it should be just opaque. Either way, it's a system engineering idea:

• Encapsulate a function, 
• Make it opaque and invisible to outsiders
• Feed it inputs and external controls, biases, and offsets (in other words, the 'interfaces')
• Look for and utilize the prescribed outcomes
• Voila! You've got a 'black box'!

Ooops!

What if ...

What if there are chaotic responses, unforeseen resonances, inexplicable outcomes and distortions, and even destructive behavior?

The question is begged: Do you understand how your black box interfaces with your project or system? Very likely if you don't know, the larger system doesn't either because, hey!, you designed the larger system!

If your answer is No to the above, then here's some advice: roll back the black box and expose the functionality to the point you can understand it; you can defend it; you can reliably forecast it's role in your system

Working on AI?

The modern idea of AI with multiple layered meshes of data processors may be the ultimate black box.   If this is your domain, read a bit of this Wired article to get onto my point of view.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The Four Maths of the PMO

---

Math may not be your favorite thing in the PMO, but hear me out.

There are four 'systems' of math you are probably using without thinking too much about them.

So, if that's so, why think about them now?

• Somebody may use the terminology around you, so informed is better than ignorant
• Communicating with your administrator, analyst, or systems person may be more informed
• You may want to learn more about one or the other, so a look-up of terms is handy

Here's a quick read on the four:

1. Arithmetic and linear algebra: Arithmetic is the add-subtract-multiply-divide thing you have been doing all you life; linear algebra is just using arithmetic in a systematic and rules-based way -- in other words, formulas -- to find some values you might not have but need  (that conveniently lie along straight lines (thus, 'linear')
   
   This is really useful stuff for adding up costs, figuring out schedules durations, and solving for resource unknowns, not to mention (gasp!) working forecast with earned value formulas
   
   
2. Exponentials: See my post on this topic. Exponentials form the world of non-linearity (no straight line). Exponentials are seen in the project office explaining  the non-linear "utility" of the project's value proposition, escalations in communications complexity, discounts for future risks, discounted cash flow (DCF) methods, and other useful stuff
   
   
3. Statistics: Statistics, and its close cousin 'probability', let us deal with uncertainty in project affairs. In this domain, we find 'random numbers': that is, numbers that are a bit uncertain because of incomplete knowledge or because of random effects (for which more knowledge doesn't help).
   
   We can't do arithmetic directly on 'random numbers' because we don't have certain knowledge of what to add or subtract from one random effect to the next. Thus, simulations of statistical effects are the best way to handle such requirements. The 'Monte Carlo' simulation that is built-in to many scheduling apps and some cost and finance apps is an example of handling statistical effects on schedule numbers with simulation.
   
   Keep this idea of 'no arithmetic with random numbers' in mind when people come to you with a risk matrix that purports to multiply random numbers for uncertainty and impact. No can do!
   
   
4. And then there's calculus! You say: 'I can skip this; we don't use calculus in our PMO.' Actually, you do! Calculus is the math of 'change'. And there are always change and changing effects in the PMO.
   
   One powerful idea from calculus is that we can add up the individual effects of change, usually a lot small effects, and we call this process 'integration'. Even more handy, we can specify the integration limits to include only those effects in which we are interested. 
   
   Here's an example of something you probably know about: The so-called "S" curve of accumulating probability. This curve is very handy for assessing confidence limits in risk management. It is actually an integration result straight out of calculus. Small increments of probability from a "bell curve" are integrated to form the S-curve. In other words, if we 'integrate' the "bell curve", the result is the "S" curve!
   
   Of course, the ideas work in reverse: Given the "S" curve, we can 'differentiate' it into the "bell curve" which then provides visualization of central clustering, and visualization of the outliers on the tails where events happen infrequently. 
   
   The secret to understanding derivatives is that they are always ratios: "something per something". If the "per something" part is time, then usually the ratio is a velocity or an acceleration; otherwise it's a density, as in 'parts per million'. The bell curve, being a derivative of cumulative probability, expresses a 'probability density'. 
   
   But maybe you are working in Agile methods and are concerned for 'velocity' and perhaps even the need for 'acceleration' of the evolving product base. Agile product velocity is the "first derivative" of a unchanging base; 'acceleration' is the first derivative of velocity and the second derivative of the original position.

Got it all?

Now you are the PMO math person!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Agile and the sailor's analogy

---

The presentation -- in the link below -- that I gave to PMI some years ago that makes an analogy between sailing a boat and Agile methods is still relevant, and probably will remain so.

Why?

Because a sailing "project" is has much in common with an Agile project:

• Tactics overlay a strategic goal, though there are broadly stated limitations and rules
• Small teams have to work together, or else someone goes overboard
• There's a lot of local autonomy
• Risk is managed locally
• The environment is pretty flat, managerially, but the leader is clearly recognized
• Team success trumps individual success; teamwork is rewarded, particularly in overcoming adversity
• The goal is set by others, but it's obvious to all observers
• The value proposition is clear and present

Have a look:

Click here for a slideshare

---

Like this blog? You'll like my books also! Buy them at any online book retailer!