Staging And Classifying

Our tour is complete.

We've collected on this journey around the [Risk Landscape] a (hopefully) good, representative sample of [Risks] and where to find them. But if we are good collectors, then before we're done we should [Stage] our collection on some solid [Mounting Boards], and do some work in classifying what we've seen.

tbd collecting image

Some Observations

Your Feature Risk is Someone Else's Dependency Risk

In the [Feature Risk] section, we looked at the problems of supplying a dependency to someone else: you've got to satisfy a demand [Market Risk], and ensure a close fit with requirements [Conceptual Integrity Risk]. The section on [Production Risk] went further, looking at specific aspects of being the supplier of an IT service as a dependency.

However, over the rest of the [Dependency Risk] sections, we looked at this from the point of view of being a client to someone else: you want to find trustworthy, reliable dependencies that don't give up when you least want them to.

So [Feature Risk] is [Dependency Risk]: they’re two sides of the same coin. In a dependency, you’re a client, whereas feature risk, you’re the supplier.

Coordination Risk

• similar to _threading/deadlocking issues

One thing that should be apparent is that there are similarities in the risks between all the kinds of

Production risk == security risk??

Boehm.. OWASP..

How much do compilers do for you?

1. Classifying Risks

• Dependencies and Features are the same
  • Dependency risks are all 2-sided. (Counterparty risk)
• Communication is a Dependency
• Fit Risk / Communication Risk - buckets
  • Fit risk example from work: choosing the right format.
  • Why standards can never be perfect.
  • Mention Kanban = the control is the physical object
• Expected Requirement Coverage - diagrams 1 & 2.
• Dependencies and Coordination

2. What's Gone Before

• Boehm.

risk based debugging.

risk based coding.

We're all naturalists now.