Information Technology

Proving change is necessary requires some legwork. It’s fine to want to change your organization because "everyone" is doing DevOps now, but you’re looking at months of work, new tools to learn and implement, teams to restructure. These costs must be outweighed by the benefits, so you have to be able to put real value on your processes.

Articulating upfront what your goals are will help you with other phases of your DevOps roll out. Some common measurable goals are:

• Reduce time-to-market for new features.

• Increase overall availability of the product.

• Reduce the time it takes to deploy a software release.

• Increase the percentage of defects detected in testing before production release.

• Make more efficient use of hardware infrastructure.

• Provide performance and user feedback to the product manager in a timelier manner.

These goals have monetary impacts on your business. It costs you people-hours when your software releases take days. It costs you revenue when the product isn’t available for use by your customers. It increases your operating costs to run your infrastructure in a non-efficient way. Taking what you know about these values, you can put a monetary value on improving any of them.

​

Additionally, all of these goals can have a numerical threshold attached to them. "Reduce deployment time from 10 hours to two hours." "Increase percentage of defects detected in testing from 25% to 50%." You can reason about these numbers and judge the success of your transition process.

​

These goals also give you a stable platform for obtaining support from the rest of your organization. Starting from metrics such as "It currently requires six team members 10 hours to deploy a new release of our product. This costs us $X for every release" provides a concrete number for comparison as you implement your DevOps changes. It attaches real value to a real pain point in a way that is more constructive than "Our deployments suck."