DevOps is all about business continuity and risk. This is obvious to anyone in the organization who has ever experienced major downtime of a critical system. Risk aversion in DevOps may hamper not only its adoption but also innovation and digital transformation in general, all of which require calculated and frequent risk taking.

So instead of escaping risk it may be reasonable to learn how to manage it. Knowing what risks to expect and how to deal with them will help you in it. A DevOps pilot project will be a perfect environment to test the water and locate all major weak points.

Pilot project: Embracing risk

There is no easy answer as to which case would be the best pilot project; it depends totally on the company’s unique environment. Conventional thinking would recommend choosing a smallish and relatively unimportant project. However, if you really want to change your risk profile, playing it safe is not a great way to start.

There is much to recommend one of the legacy systems or processes, and every company has one that is a major pain point. The system crashes regularly and has done so for most of its existence; everyone who works on it is demotivated, whether they are developers or in operations; and everyone wishes it would go away. What better choice to make for a proof of concept?

There is a risk in selecting such a fragile subject, but the results will be more impressive and will start the ball rolling

Defining and managing risk

While it is accepted that a good project will have the risks identified, prioritized, mitigated, and loaded into a risk register, this is not usually discussed in articles about DevOps. Here are some of the expected risks and mitigations:

Risk: People outside the project, both in IT and in the rest of the company, do not understand the project.

Mitigation: Make the process visible and transparent. Find an efficient way to communicate what is happening to the rest of the company and provide regular updates.

Risk: The knowledge base on how the system works is small, and it is probably tacit knowledge. Losing one key person may ruin the entire process.

Mitigation: Make sure your maintenance resources feel valued and are committed to staying the journey. If they are involved in other systems, find someone to relieve them, they need to be on this project 100%.

Risk: There is pushback against the changes to culture.

Mitigation: This is natural. Use change management to reduce the impact. Accept that some resources will not be able to cope and may resign, and be prepared if this does happen.

Risk: While budget has been allocated for toolsets, the expertise to make the right choice is missing.

Mitigation: You could save a lot of time and stress by calling in some subject matter experts, who are both tool-agnostic and experienced enough to recommend a shortlist of what will work for your environment.

Risk: While you have the right skills to manage the project, you do not have anybody who understands what has to be implemented, how long it will take, and how to phase it.

Mitigation: Again, outside assistance will make the transition much easier.

There are obviously many more risks, both general and specific to your enterprise. The focus on managing risk can help resolve some of the tensions that will inevitably arise as people try to come to terms with the new way of working, in that the mitigations are objective and unemotional and focused on business continuity, not turf wars.

There is an added benefit in taking a risk management approach. If enterprise risk management is not entrenched in your company, this is an opportunity to build risk awareness and good risk practices within the fledgling DevOps environment. The new attitude towards risk should also be more accepting of failure and the valuable lessons it brings so that mistakes are not repeated in the future, as that is also part of the DevOps culture.

Alexey Karavay is a research analyst at Itransition, a custom software development company headquartered in Denver, Colorado. He provides expertise in a variety of software development fields, including strategies for implementing DevOps practices. Alexey is also keen on emerging technologies and intersection of business and IT.