Operational software is a distinct discipline. The users are experts working under time pressure, the domain is full of constraints and exceptions, and the cost of a bad abstraction is not a poor experience — it is a planner maintaining a shadow spreadsheet because the system cannot express what actually happens.
These articles cover the three failures that recur most: improving the wrong part of a constrained system, designing before the problem is understood, and automating an existing process without asking whether the process deserves to survive.
Articles in this guide
-
Theory of Constraints in Software Operations
Finding and defeating the final boss
-
Soft Systems Methodology for Software Requirements: A Tarantino Heist
What an old PhD thesis can teach product managers about systems thinking, requirements discovery and building the right thing
-
Business Process Reengineering Before Automation: The Hammer Lesson
What product managers can learn from Michael Hammer, business process reengineering, and the danger of automating bad processes.
Where this gets applied
NHS IT Risk Tool is a structured system of record for exactly this kind of high-consequence operational documentation.