Windward Insights

Integrating Operational Requirements into your Development

Written by windward

magnifying glass focused on cure

Don’t Treat the Symptoms, Cure the Disease

Integrating Operational Requirements into your Development Lifecycle

“The project has been delayed so that the Ops team can ensure that proper monitoring is in place.”

If you’ve been involved in software or application development projects over the last decade or so,you’ve probably seen a message like this at least a few times. I know that I’ve seen it multiple timesfrom being on the application development side, the operations side, and also as an outside consultantbrought in to help customers fix their operations practices.

Many times the solution that’s implemented to avoid these project delays is to update the developmentlifecycle with some kind of checklist or testing to cover monitoring and operations. It’s a positive steptowards giving the Ops side a voice in the development lifecycle, stopping projects from beingengineered and “thrown over the fence” to an Ops team that has no understanding of how to monitoror manage the system or application. But if this checklist approach is your solution, you’re only treatingthe symptoms.

To truly get to the heart of the problem, to cure the disease, operational requirements should beincluded right from the beginning of any development lifecycle in the design phase. To be fair, in mostsituations it’s not that the big bad developers don’t care about the Ops team and what they need to dotheir job. The most common impediment to this integration is that there are no defined operationalrequirements. It’s impossible to integrate and enforce requirements that don’t exist! Thus, it falls onthe Ops team to undertake the effort to define standards and requirements that they can then integrateinto, and enforce, in the development lifecycle.

This is a win-win situation for everyone involved. The business gets their products released on timewithout infighting from “the IT department.” The development team no longer has to worry about theirproject being delayed because the Ops team stops it right before they’re ready for production release. The Ops team ensures that their requirements are integrated into any system or application that theyare going to be on the hook to monitor and manage. And in many cases where we have undertaken thisapproach, for the first time the Ops team now has standards and requirements for support which leadsto efficiency and effectiveness gains (you’re no longer monitoring everything as an exception). Withrepeatable standards and processes in place,automationis now in the realm of possibility which canlead to even greater efficiency gains.

If you’re having issues at your organization getting projects “through” operations, make sure that you’renot just treating the symptoms by putting some check point in place late in the development lifecycle. Itmay take a little more time and effort up front, but cure the disease by defining your operationalstandards and requirements and integrating them into the design phase of your development lifecycle.