Risk Intervals and timeliness

---

Want to manage risks? Super! It's always a good idea.
Everybody starts with the traditional four steps:

1. Identify the risks .... are you thinking strategically or tactically? The list is different for each
2. Prioritize among risks .... some don't need to be managed
3. Evaluate probability and impact
4. Set up a risk response or mitigation

Actually, there are problems with Step 3

• It's rare, bordering on "never", that you would know -- or could evaluate -- "probability" in a quantitative sense. [High, low, medium is not quantitative]
• Why?  Because it's unlikely you would have enough historical quantitative and calibrated data to form an estimate. (Actually, to form an estimate of a distribution from which a estimate of probability can be determined) Thus, you're likely guessing
• Time matters, and time is not actually explicit in Step 3. Most risks are not static or stationary. And, most assessments are not stationary. Your evaluation will change with circumstances and facts revealed. It matters when you assess risks or have to deal with their possible impacts.

And, so what to do?
Intervals and their timeliness

•  Substitute the concept of "confidence interval" for a specific probability: less than this, greater than that; or contained within a range of this to that.(*)
• Explicitly state the time frame during which the confidence interval applies. After all, this example oft cited is a good demonstration of the principle: your confidence it will rain today is a good deal different than your confidence it will rain this week, but the impact may be the same if you are doing project work in the weather.

* Ooops, another problem: a confidence interval is obtained by integrating a probability distribution, but we've just said we don't have the data necessary to form a distribution. So, does a lack of data also invalidate a confidence interval?

• Strictly speaking, if the actual shape of the confidence "curve" within the interval is important, then yes there is an issue
• But, if you are, as most of us are, approximating the interval with some end points that are "very likely to contain the real outcome" then the shape of the curve is not so important. Thus: press on!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Actually, you can't measure it

---

We're told repeatedly: you can't manage what you can't measure. Or, you can measure anything -- everything

Actually, you can't

Measurements do the changing
There are may project domains where measurements change the thing being measured, so that the results are incorrect, sometimes dramatically so:

• Many chemical reactions or chemistry attributes
• Some biological effects
• Most quantum effects
• Most very-high or ultra-high frequency systems (VHF and UHF, to extend to micro and millimeter wave systems)
• Some optical effects

 And, of course, many human behaviors and biases are themselves biased by measurement processes

Intangibles et al
Not be left out: the affects and effects of intangibles, like leadership, empathy, the art of communication, and others. Not directly measureable, their impact is a matter of inference. Typically: imagine the situation without these influences; imagine the situation with them. The difference is as close to a measurement -- if you can call it that -- that you'll get.
 

Which all leaves the project where?

• Inference and deduction based on observable outcomes which are downstream or isolated or buffered from the instigating effects 
• Statistical predictions that may not be inference or deduction
• Bayes reasoning, which is all about dependent or conditioned outcomes
• Simulations and emulations

Bottom line: don't buy into the mantra of "measure everything". Measuring may well be more detrimental than no measurements at all

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The value of strategy

---

"I will not take by sacrifice that which I can achieve by strategy"

General Douglas MacArthur

And, so what we have in that philosophy, when put in project context, is the oft-criticized 'brute force approach' vs a more subtle tactical alternative. Where this shows up more often than not is using the right tool for the right job, and preparing the context for using the tools.

We see it all the time: rather than taking the time to obtain -- and perhaps train on -- the right tool, practitioners barge ahead with brute force because they think they are saving time. No strategy required. I have a hammer, so every problem is a nail!

Ooops! It takes more time to clean up the mess than do it right the first time --- and, how many times have you heard that one?

More brute; more force

Remember this from a prior post? "Measure with a micrometer; mark it with chalk; cut it with an axe"? Just brute piling on top of brute

And, of course, the other brute force idea is more force -- more people. More is better -- until you get to Brooks Law: "Adding people to a late project makes it later" *

* Fred Brooks: "The Mythical Manmonth"
More subtle tactics

• First we have the Tom Sawyer approach: get someone else to paint the fence; and, better still, make them think it's a privilege.
• Ignore the inconvenient: Also known as: answer the question you wished they had asked and not the question asked. And, jump over, around, or dodge adversity -- the MacArthur approach
• Don't confuse cost and unit cost: experts may cost more per hour, but throughput is what counts. They may finish a lot faster and better. This is the case for "made in America"

---

Historians are in general accord that during the Pacific war MacArthur was able use strategy both as a force multiplier and a means to avoid casualties more effectively than any other strategic leader. *
At the single battle of Anzio in Italy, 72K casualties; in 2 years in the campaigns from Australia to the Philippine invasion, MacArthur suffered 27K casualties. There are many other examples.
* From: "American Caesar" by William Manchester

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Timing is not everything

---

"Just because something happens after something else happens doesn't mean it happens because something else happened

• Show me your data
• Show me your assumptions
• Tell me what questions you asked
• Tell me why you didn't ask other questions"

From the TED Radio Hour, "Big Data"

So, what we have here is the tyranny of the "Three Cs" *

• Coincidence, perhaps better written as co-incident to emphasize the timing of multiple incidents, but having no other coefficients or linkages among them
• Correlation, meaning one effect or outcome is predictable upon the occurrence of another, though the "other" outcome may have many contributors, so the correlated effects may be "weak"
• Cause-and-effect, meaning one effect or outcome is both predictable by- and, indeed, caused by the presence -- or not-presence -- of another

It seems we always are confronting the confusing rule that "correlation is not causation, but causation requires correlation"

Chapter 2 of my book "Quantitative Methods in Project Management" goes into these ideas in more depth (did I mention it's available at any online book seller?)

Of course, when there is a human in the loop, then all of the correlating or causative linkages are influenced by biases, most non-linear and very situational, but some amenable to "game theory" which is discussed in other posts in this blog

---

* There is a 4th C: co-variance, an ideas from statistics. Related to correlation, co-variance describes how the spread -- or distribution -- of uncertain or random outcomes of one thing is made different in some sense by the presence of another random or uncertain outcome.
If there is zero co-variance, then the uncertainties are "independent" of each other; otherwise they are not.
In most project environments we can't actually measure co-variance; what we can do is test for independence and thus infer a co-variant effect, or not.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Value and values

---

Value and values are only one letter apart

Anonymous

If you're interested in a soap opera depiction of the early PC wars, you might tune into AMC's "Halt and Catch Fire" 2-season drama. The first season is on Netflix if you've missed it.

On display is certainly the conflict between value and values

• The former being the "end"
• The latter being the "means"

And, the conflict being whether the sometimes duplicitous values put the value out of reach, or so taint the value as to make it unworthy, or really whether the value is worth the values endured.

You can be your own judge

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The 15 commandments of safety-critical software

---

The following is borrowed unashamedly from Matthew Squair at Critical Uncertainties:

"Herewith, are the 15 commandments for thine safety critical software as spoken by the machine god unto his prophet Hermann Kopetz.

1. Thou shalt regard the system safety case as thy tabernacle of safety and derive thine critical software failure modes and requirements from it.
2. Thou shalt adopt a fundamentally safe architecture and define thy fault tolerance hypothesis as part of this. Even unto the definition of fault containment regions, their modes of failure and likelihood.
3. Thine fault tolerance shall include start-up operating and shutdown states
4. Thine system shall be partitioned to ‘divide and conquer’ the design. Yea such partitioning shall include the precise specification of component interfaces by time and value such that  all manner of men shall comprehend them
5. Thine project team shall develop a consistent model of time and state for even unto the concept of states and fault recovery by voting is the definition of time important.
6. Yea even though thou hast selected a safety architecture pleasing to the lord, yet it is but a house built upon the sand, if no ‘programming in the small’ error detection and fault recovery is provided.
7. Thou shall ensure that errors are contained and do not propagate through the system for a error idly propagated  to a service interface is displeasing to the lord god of safety and invalidates your righteous claims of independence.
8. Thou shall ensure independent channels and components do not have common mode failures for it is said that homogenous redundant channels protect only from random hardware failures  neither from the common external cause such as EMI or power loss, nor from the common software design fault.
9. Thine voting software shall follow the self-confidence principle for it is said that if the self-confidence principle is observed then a correct FCR will always make the correct decision under the assumption of a single faulty FCR, and only a faulty FCR will make false decisions.
10. Thou shall hide and separate thy fault-tolerance mechanisms so that they do not introduce fear, doubt and further design errors unto the developers of the application code.
11. Thou shall design your system for diagnosis for it is said that even a righteously designed fault tolerant system my hide such faults from view whereas thy systems maintainers must replace the affected LRU.
12. Thine interfaces shall be helpful and forgive the operator his errors neither shall thine system dump the problem in the operators lap without prior warning of impending doom.
13. Thine software shall record every single anomaly for your lord god requires that every anomaly observed during operation must be investigated until a root cause is defined
14. Though shall mitigate further hazards introduced by your design decisions for better it is that you not program in C++ yet still is it righteous to prevent the dangling of thine pointers and memory leaks
15. Though shall develop a consistent fault recovery strategy such that even in the face of violations of your fault hypothesis thine system shall restart and never give up."

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Construction PMO

---

I don't write about construction projects all that often, but lately that's been my thing: construction... roofing, HVAC, electrical, even some plumbing and floors, etc

The PMO construction extension to the PMBOK is pretty much a non-starter in my opinion.

The place to start is the AIA -- aia.org -- the American Institute of Architects. And, it's not just for architects: general contractors, contract managers, and PM's all find really good stuff.

And,you don't have to be an AIA member to take advantage of a lot of the stuff, including sample contract documents, of which they have dozens, if not several dozens. However, be watchful of the copyright claims

Here's the thing. There are these two important points to grasp:

1. There are generally four players in construction: the architect (or engineer), general contractor, attorney, and owner (or buyer). Read any AIA contract template and you'll find "the architect shall...; the GC shall..., etc)
2. Often, the owner and the general contractor (GC) both will have project managers, though sometimes the architect or the GC plays the role of PM for the owner. So, which one are you?

With four major players, you'd think the communication channels would be about 15 (using the N-squared minus 1 rule, where N is the number of communicators).

But no! My observation and experience is that communications in a construction environment is not a mesh; the communications architecture is hub-and-spoke.

And, guess who is at the hub; guess who is the risk manager managing all the sequences and buffers among players? Right! You are, if you are the PMO for the owners (or possibly the GC if the owner is contracting "turn key" with the GC)

• It's almost childish the way the various independents and independent contractors insist on communicating through the hub. If a conference is needed, only the PM can call for it, it seems.
• And, since most of the construction industry multiplexes the white space among many jobs, to maintain any kind of project schedule requires constant attention to sequences of who works when
• And, did I mention the supply chain? Everyone seems to work "just in time", maintaining minimum inventory, and thereby pushing buffers and sequencing to the limit! 

Conclusion: the number one skill of a construction PMO is communication ... far and wide, and often!

• Tell them what you are going to tell them
• Tell them
• Tell them what you told them!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Agile and the sailing analogy

---

In one presentation to a PMI chapter on Agile project management I used a sailing race analogy. I've used this analogy before, but this time there was some 'Q&A' that was worth passing along.

The first thing is that audience was shocked (shocked!) to learn that agile projects have plans, and even more shocking that earned value concepts (that is: earning some value for the investment made) is also alive and well.

The second thing is that those from large companies lamented (I won't say complained because they didn't) that executive managers had little idea about the change in management paradigm that is the most pervasive aspect of agile. It's not the technical practices: those are largely like those in other software methodologies. But it's the change in management practices and thought that is different.

What's different?

• What's different is that best value is preferred over a fixed scope specification;
• what's different is that matrix management at the team level, sprint to sprint, must be put aside;
• what's different is that the team, in collaboration with someone holding the customer/users proxy has to be trusted to apply the available investment is the best possible way; and
• What's different is that the project manager manages to milestones that have user/customer/stakeholder value and not to the details of a networked CPM schedule.

Take a look and see if you don't agree

Agile for project managers - A presentation for PMI from John Goodpasture

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Autocrats and Risk management

---

Autocrates and autocratic leadership -- on the one hand -- and the classic risk management on the other hand .... is the latter pointless in the context of the former?

And we ask this because:

From essayist Eric Grill writing in the leadership blog of St Thomas University we learn that:

Autocratic leaders typically make all major decisions on their own, with little or no input from others.
Extreme authoritarian leaders often insist on making even minor decisions.

Of course, it shocks the sensibilities to imagine "extreme authoritarian leaders" in a PMO, so for this discussion we'll set micromanagement aside.

But here's an eye opener, also from Mr Grill:

..... autocratic leadership works well in environments that require near-perfect accuracy .....

Software need not apply! The software guys can usually get by with any number of bugs... there's always v2.0

But the other thing is speed:

According to Grill, "Leonard D. Schaeffer considered himself an autocratic leader when he became CEO of Blue Cross of California, saying  'When a business needs to change relatively quickly, it’s much more important to just make a decision and get people moving than it is to take the time to conduct a thorough analysis and attempt to influence others to come around to your way of thinking.' "

Moving on to risk management
The RMO (risk management officer or office), especially in larger projects, is often "staff", and often required by policy rather than a perceived necessity. And, RM comes with these built-in ills:

• RM is not accurate, steeped as it is in statistics and caveats and assumptions, etc
• RM is not speedy, driven as it is by the need to identify threats, develop collection protocols and senors to gather data, analyze, and integrate assessments with context 
• RM is often an opinion by those who don't have the responsibility for outcomes and consequences
• RM is often self-conflicting, given that many have an opinion or an interpretation of the data
• RM, even if correct, often does not alter outcomes

And so, the autocrat, valuing speed, results, precision (in many cases), through-put, and supremely self-confident ignores many staff inputs,  risk management among them (what difference does it make? asks the autocrat)

Or worse, the autocrat can't handle an opinion that differs from their set point of view, having some kind of psychological barrier.  The worst of these are "advisors" who form an opinion and then can't bring themselves to change their mind when new information comes along.

And so what to do if you're the RMO?

• Work on the perceived RM ills (listed above)
• Focus on risks that make a measurable difference to organizational success
• Be persistent pressing your case
• Speak truth to power (if you're inhibited by the autocrat, spend your time on your resume)

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Negotiating with a liar

---

Leslie K. John has an essay in the July-August 2016 Harvard Business Review entitled "How to negotiate with a liar"

Among other things, he notes that most of us can only identify a lie about one time in two; and, further: studies show most people tell some sort of a lie about once or twice a day.

 Good grief. With those statistics, it's a wonder we ever know if we're getting the straight stuff.

So, now what if you're in the midst of a negotiation with a colleague, contractor, supervisor, sponsor, or whomever? Do you assume a truthful discussion?

Frankly, it depends on what is at stake. It shouldn't be that way, but it is, so we've invented various non-real time tools when the stakes are high:

• Sworn affidavits
• Authentication systems, notaries and the such for documents
• Corroborating sources
• Testimony under oath
• Contracts with damages for untruthful assertions

But, if you're sitting down in a negotiation in real-time, other techniques are needed. According to essayist John we all have these weaknesses, more or less, which are a threat to our position in a real-time negotiation:

Humans are particularly inept at recognizing lies that are cloaked in flattery: your boss’s promise that a promotion is coming any day now; the supplier’s assurance that your order is his top priority. We’re wired to readily accept information that conforms to our preexisting assumptions or hopes.

Leslie John has some ideas to counter that weakness and to help out with discovery. Here is some of what he recommends:

1. Encourage Reciprocity
Humans have a strong inclination to reciprocate disclosure: When someone shares sensitive information with us, our instinct is to match their transparency. In fact, simply telling people that others—even strangers—have divulged secrets encourages reciprocation.

2. Ask the Right Questions
... many negotiators guard sensitive information that could undermine their competitive position. In other words, they lie by omission, failing to volunteer pertinent facts.

3. Watch for Dodging
Savvy counterparts often get around direct questions by answering not what they were asked but what they wish they’d been asked. And, unfortunately, we are not naturally gifted at detecting this sort of evasiveness.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog