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
-
Why Most Software Projects Fail Like a Tarantino Heist
What an old PhD thesis can teach product managers about systems thinking, requirements discovery and building the right thing
-
Hammer and the Most Dangerous Question in Product Management
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.