Risk management: we don't make policy

---

From General Mike Hayden's memoir (paraphrasing from pg 428)

Imagine two doors to the same room: One labeled risk manager; the other labeled visionary.
Though the risk manager's door, entry is for the inductive thinker:

• I've got the facts; now I need to connect the dots to reveal a generality or integrating narrative

Through the visionary's door, entry is for the deductive thinker:

• I've got the vision; I'm confident the facts and dots needed for implementation will emerge

And, consider this:

• Pessimists with facts enter through the risk manager's door
• Optimists with business-as-we-want-it enter through the visionary's door

Then what happens?
Each needs to find the other. In the best of situations, they meet in the middle of the room where there is buffer space and flexibility.

Risk management does not establish the vision, set any policy, or necessarily decide anything; it only sets the left and right hand boundaries which arise from the generalities devined from the observable facts. The space in between the boundaries is where the visionary gets to do their envisioning, and decision maker's get to do the deciding.

Sound familiar? I hope so. You'll find a similar explanation known as the "project balance sheet" in my book in Chapter 6 of "Maximizing Project Value: A project manager's guide". In that metaphor, the right side is for the fact-based inductive manager; the left side is for the deductive visionary. And, since those two never agree fully, there is a gap between the inductive and deductive.

And the gap is where the risk is. And who is the risk manager? The PM and the project team -- not the visionary (after all, they have no facts; facts are behind the other door!)

And, that's why we pay the PMO the big bucks: to manage the risk!

---

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

About evidence

---

Did you see this witicism at herdingcats?

A skeptic will question claims, then embrace the evidence. A denier will question claims, then reject the evidence. - Neil deGrase Tyson

Think of this whenever there is a conjecture that has no testable evidence of the claim. And think ever more when those making the conjectured claim refuse to provide evidence. When that is the case, it is appropriate to ignore the conjecture all together

---

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

About coordination

---

We're all supposed to coordinate. That's written somewhere in the PM literature and taught in bureaucracy school everywhere. And so I was impressed with this bit of wit:

"Successful coordinating mechanisms depend on mutuality. The greatest chance of success derives from mutual benefit tied to sufficiently high priority programs

... "[beware of the] weak coordinating level of [just] interaction rather than [the stronger leverage] in budgeting and policy"

Dr. L. Parker Temple, III 
Policy advisor to President Reagan

The message is clear

• Money talks
• Follow the money

In the public sector, and certainly also in large private organizations, personal power and prestige and organization power and influence count for a lot.

It's all well and good to coordinate, so long as I don't lose anything in the deal. Even better: What's mine is mine and what's yours is also mine ... so long as it's gained by coordination!

---

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

Strategic weakness

---

And when your strategy depends on someone else doing something that's pretty weak strategy

Jeff Roe
Politcal strategist

Well, yes, but no ....
Certainly, self-sufficiency is the better game plan, but who gets to play in that green field? Certainly not PMs which are at the behest of sponsors, customers, and other business interests. If they don't behave and get on the same page with the project, then there's inevitably a gap between interests ... a gap between the strategic interests of the project project and the business.

And what fills that gap ('cause it isn't a vacuum!) None other than: RISK!
And who gets tagged as risk manager? Right! The PM is always in the hot seat as risk manager, balancing the interests of the project strategy with the larger business strategy.

You say: Not fair! And, you'd be right most of the time. Not fair, but certainly realistic. The PM is the risk manager for any gap between interests. And, as manager, there is both a payoff or a penalty depending on how the risks play out... to wit: hero or goat!

---

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

Testing... how much testing?

---

Consider this quote from Tony Hoare:

One can construct convincing proofs quite readily of the ultimate futility of exhaustive testing of a program and even of testing by sampling. So how can one proceed?

The role of testing, in theory, is to establish the base propositions of an inductive proof.

You should convince yourself, or other people, as firmly as possible, that if the program works a certain number of times on specified data, then it will always work on any data. This can be done by an inductive approach to the proof.

Everyone remember what an inductive argument is? Yes? Good!
Then I don't need to say that ....
When reasoning inductively you are reasoning from a specific instance to a generalization. The validity of the generalization can only be known probabilistically. (It's probable-- with high confidence -- that any instance will work because a particular instance -- or particular set of instances -- worked)

Thus, there is no absolute certainty that a generalization will work just because a large set of specifics works.

Monte Carlo testing is inductive. There are two inductive conditions in Monte Carlo testing:

1. That the test conditions are time-insensitive ... thus, tests done serially in time are valid for any time, and are valid if the tests were done in parallel rather than serial
2. That the test results for a finite number of iterations is representative of the next iteration that is not in the test window

Sampling is also inductive.
And why would one do this?
Economics mostly.
Usually you can't afford to test every instance possible; sometimes, you can't create all the conditions to test every instance possible. The plain fact is, as Mr Hoare says, you should be able to do "just enough" testing to convince yourself and others who observe objectively that, hey: it will work! 

 

---

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

Unknowable in the risk spectrum

---

Would you agree that safety risk guru Matthew Squair has it about right that this is a fair representation of the risk spectrum?

Actually, I'm not so sure about the "Is it possible" controlling and mitigating for ontological uncertainty (Squair defines ontological uncertain this way: "Ontological uncertainty lies at the far end of our continuum and represents a state of complete ignorance. Not only do we not know, but we don’t even know what we don’t know.")

• We can't do probabilistic design for something we're unaware of
• We don't even have the stastistics to back up the probabilistic reasoning
• We're not even sure that resilience -- defined as ability to absorb shock without castrophe -- is doable

In my opinion, the only things you can really do for ontological risk are to have reserves and buffers that might be able to absorb shock; independent redundancy (the same risk can't effect all redundant capabilities; loose coupling so that the shock does not propagate; and a 360 awareness for the unknowable.

 In an essay he makes this conclusion:

The idea of risk as a quantifiable property emerged from the great flowering of scientific thought of the 18th century, so it is no surprise that the application of risk to engineering has determinedly followed in these footsteps.

But our understanding of uncertainty has moved on from the clockwork universe view of the 18th century.

Some risks, as it turns out, are not just uncertain, but unknowable before the event and today we are slowly starting to recognise the need for tools to ‘know what we do not know’ about technology risks, and we are also learning that the strategies we use for control should be dictated by the types of risk we face.

Fortunately, the work of economists, psychologists and philosophers over the last hundred years has built up a far broader view of uncertainty and risk.

Is he restating the "Rumsfeld Doctrine of Risk"?

There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know.
Donald Rumsfeld

---

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

Risk management with $1Billion at stake

---

Spacecraft projects are pretty tricky risk management regimes. Consider:

 "If anything goes wrong there's no way for anyone to intercede"

That's the feeling in the Juno project office about the injection procedure of the Juno project spacecraft into Jupiter's orbit, as reported in this essay. The PMO is led by Rick Nybakken who has said this regarding risk responses to the orbit maneuver:

"We haven't studied too much in terms of where we end up [if there is a failure], because we are focused on success and not failure"

In other words, there's really no Plan B, much less Plan C. Either the mission is successful re being captured by Jupiter and eased into a productive orbit, or there's a miss, and really most of the mission objectives re Jupiter are not obtainable.

Bummer! $1billion at stake. Most of the money has been spent. Either the value return is really spectacular or pretty much nil. Talk about two discrete outcomes are really nothing in between.

NOT so fast!
Yes, the money has been spent, but on what? I'll bet -- without knowing the details -- that risk management has been hard at work on reliability, redundancy, and sensors of all kinds. I'll bet the PMO knows before it pushes the button whether it's likely to work.

Since they can't do risk management in real time, and they can do little once operations begin, it all has to be anticipated and worked into various failure analyses with work-arounds available in space. I'll bet they spent a fortune on risk management on the ground so that its unavailability in space is of minimal worry.

In other words you work in the domain you have, not the one you would like to have.

 

---

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

Maintaining control

---

At "herding cats" there a good list of control elements in a posting I read, interesting enough that I offer the short version here:

1. Short term feedback - what's happening right in front of me? What do I need to do NOW to maintain stability, to survive for the next 10 feet on the trail 
2. Long term feedback - I see things coming ...[project managers are paid the big bucks to see around corners!]
3. Corrective actions - what corrective actions am I capable of performing?
4. Alternative choices - ... choices present themselves. Some are optional, some are mandatory alternatives.
5. Estimate what's right in front of you - A quick estimate is needed to decide what to do. Keep going, speed up, slow down, stop? All depends on the situation.
6. Estimates of needed for solutions coming up the trail - with short term estimating there are a limited number of choices, .... For longer term choices, there are more options. A  Plan B is needed as part of the normal process
7. Estimates of needed resources - The resource plan for the project is needed no matter the method used to develop the project.What skills, how many of those skills, the availability of those skills?
8. Estimates to complete -
   • On projects knowing something about when you plan to finish is part of managing the project.
   • Anyone working on a project that doesn't have some type of deadline is working on a de minimis project - it's too small for anyone to care about.
   • Same for the budget; Same for the needed technical performance
9. A Plan B and even a Plan C - planning in depth is a good idea whenever ....
   • Knowing the Value at Risk defines the magnitude and detail of the plan.
   • Risk Management is How Adults Manage Projects Tim Lister should never be forgotten
10. Knowledge of capacity for work - how big is it?
    • On projects, if we don't our capacity for work, we can't make informed estimates if we can get to the end in one piece.

---

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

What's the value? Book or Good Will?

---

This really isn't a posting about accounting ...

But, when the accounting industry figured out that most businesses are worth a lot more than their salvage value, even more than the market value of tangible assets -- like inventory, buildings, and tools -- the accounants had to invent an asset and terminology to cover the gap.

Invention: "Good will".
It even sounds like it belongs in a business. Who doesn't want good will?

Good Will is what makes  the balance sheet balance when, for example, the "market cap" or owner's interest is so much more than the tangibles. Just add a dolop of "good will" to assets, and presto: balance sheet balance!*

So, now we to come to projects -- why else write this stuff? Surely not to push a book!

In my book, Managing Project Value,  I have a chapter on "value attainment" -- Chapter 9, actually.
Here's an illustration that makes my point.

Notice on the left scale there is first the project budget, but the scale goes beyond to encompass the unrealized business value. What we PMs call it "project budget" is what accountants call "book value" (the terminology is really just a mapping from one domain -- projects -- to another domain -- accounting)

Thus, the "book value" will change over the course of the project.  In the beginnng, book value is zero; everything about the project is good will since all of the to-be actual cost is still sitting in other assets -- like cash, and all the to-be business benefits are unrealized.

But time moves along; the project gets completed. At the post-project operations moment, what do we have? Tangibly, we have all the artifacts of the project -- deliverables, tooling, intellectual property. We can put their cost down as the book value of the project. That's what OPM -- other people's money -- bought in the near term.

But, the real intent of the OPM investment is the (far term) business value ... which is initially all good will, even at project finish, but ultimately turns real with product success. So, if that's the intent, what's the PM role in realizing that intent?
 

The best answer is in Chapter 9 of my book, but if you've not already grasped it, the short answer is this: the PM's priorites are two-fold

1. Near-term: it's all about the utility of book value -- getting to DONE or complete with the assets assigned.
2. Far-term: it's all about influencing the realization of business value -- turning good will into realizable gains

How to do the second? The PM can really have an influence on the business value and the project's good will by serving up:

• Timely delivery
• Functional effectiveness
• Elegant appeal

---

*Tangible assets + good will, less liabilities to others = owners investment or market cap

---

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

Fourth of July

---

This office is closed on 4 July due to circumstances beyond our control

Sign on British Consulate in the USA

---

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 case for SLOW programming

---

Every other posting about software these days is about 'go fast' or 'quick delivery' etc. Agile everywhere; Agile every time!

But, there's a case for SLOW!

How about when you're asked to code up some morality; when you're asked to code the decisions which are philosophical, steeped in moral decisions, and perhaps are quite personal?

This project issue is embedded in this essay about coding the autonomous vehicle.

Let's say you're doing the coding for some decision making the car's control must address:

You’re driving through an intersection and three people step into the road; the only way to avoid hitting them is to steer into a wall, possibly causing serious injury to yourself.

Would you sacrifice yourself?

Now change the equation: There are four people in the road and you have two family members in the back seat.

Do you still steer into the wall?

Would it matter if one of the pedestrians was a baby? If one of them was old or very attractive

 

Should we just put this scenario into some story cards?

 "As an autonomous vehicle I want to ... when ..., or else ....",

Code it up, and call it DONE? Then, release it to production as soon as the functionality is certified?

Or, do we do a BDUF* (gasp!), and thoughtfully go through the morality tree. In other words, take it SLOW!

And, is this a case of the wicked problem where there are only virtuous circles, endlessly conflicting needs, and no satisfactory point of entry or exit?

Did I mention -- I don't have the answers to any of this. But I hope Google and others do.

---

*BDUF: Big design up front, the thing we are supposed to rid ourselves of

---

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