I’ve observed a common trend in the industry: projects that haven’t yet gone live often receive less attention compared to live projects, which are seen as more critical due to the associated risks. Risk, while often viewed negatively in software development, plays a paradoxical role. The more risk involved, the more potential there is for setbacks—be it a public failure or internal pressure from management. However, risk can also be a powerful driver for progress, pushing us to find more efficient ways to deliver. The slower we deliver, the slower we can identify and fix issues, and the longer it takes to adapt.
It’s understandable that everyone especially upper management focuses on live projects due to their higher risk profile. Questions like “Have we checked this?” “Have we performance tested?” or “Has this been penetration tested?” are essential, but they often elevate the live project to the status of a “favorite child.” While this is necessary for addressing immediate concerns, it can lead to the neglect of other important projects that also deserve attention.
As a manager, I am deeply focused on minimising risk, but I also recognise that risk is inevitable and can serve as a catalyst for efficiency. From a QA perspective, it’s part of our role to emphasise the importance of getting projects live sooner, rather than later. By going live faster, we gain valuable customer feedback that helps us identify potential flaws before they become significant issues. This iterative process mitigates the risk of delivering something that doesn’t meet customer expectations, allows us to address deployment issues early, and sets the stage for smoother future updates.
