The title isn’t a euphemism. This is about when product management decisions can do damage.
In Part 1 of this writeup, I’m going to define some of the challenges for Mission and Safety Critical applications as compared to typical development. If you want to skip right to more practical considerations for what to do about such things, go right to Part 2, with a checklist followed by explanations of the line items.
Over the years I’ve moved from consumer oriented products to B2B and B2B2C, most recently several years working on healthcare solutions. On this path, I’ve learned a lot about Safety Critical application issues. It’s stuck me that people who ‘grew up’ in such environments may have a lot of this knowledge through intrinsic experience. But for those transitioning to such areas or in startup mode who haven’t been there, (as was my path), it’s possible there’s knowledge gaps. What I often do when learning new things is take note in my own Wiki, and over time develop some degree of body of knowledge in a subject area. So my goal now is to share back what I’ve learned for those who may find it useful.
What’s the difference between “Mission Critical” or more extremely, “Safety Critical” vs. “typical” product management? Rather than try to formerly define it, let’s keep it simple. Safety Critical products are those that – for certain failure modes – can hurt or kill people. (Or cause significant property or environmental damage.) Often, they’re things that move in our environment; that is, actually do things. A basic compare and contrast might be an advertising delivery system for content vs. an insulin pump; failure of the first maybe means some lost money, whereas failure of the second… clear enough, right? Mission Critical – as distinct from Safety Critical – might mean less severe human consequences, but a ‘hard’ failure or challenge nonetheless. E.g., a failure in a basic regulatory compliance issue could result in anything from minor work stoppage or fines though potential criminal negligence. Or a failure of the software on a Mars Rover results in loss of the unit, associated waste and data loss. No one gets hurt or dies, but the mission is basically lost.
In short, these are not really applications where we want to “fail fast and learn.” These are apps that have somewhat more crisp “Minimum Viable Product“ standards when it comes to the “Viable” part.
The Short Version of Issues for Mission / Safety Critical Products
- Mission and Safety Critical systems demand something beyond basic Agile Product / Project management approaches. (And this may include products in highly regulated areas as well.)
- There is often a moral component that exists beyond other types of products / services.
- More planning is required than for non-critical systems.
- Agility may be more often impacted by external dependencies.
- So called “Non-functional” requirements may become critical.
- Risk assessments must be included as a core concern.
- There’s a suggested checklist for Mission / Safety Critical Products in Part 2 of this writeup that you may find useful if you work on these types of products.
That’s it. You can stop reading now. But for fuller discussion of these points, please continue. Or skip to Part 2 for the just mentioned checklist items.[Read more…]