Perhaps the most challenging item from the 7 Steps for a Successful DevOps Implementation is obtaining all the relevant stakeholders’ commitment to the DevOps initiative.

The DevOps program will have to be managed as any other project, using practices from any Project Management Framework your organization has in place, like The Project Management Institute’s (PMI)® PMBOK® Guide or PRINCE2, and will certainly be supported with SCRUM practices. Let’s remember that according to statistics, about 70% of projects fail to achieve the forecasted benefits, and DevOps projects will not necessarily be the exception to this threatening trend.

But why do so many projects fail? Is it that the Project Management frameworks being followed are not really effective? Are projects being poorly managed? Not at all! One of the main reasons why projects fail (not from a program’s plan perspective, but from a benefits’ realization perspective) is because stakeholders are not committed to the project—people resist change, hence they fail to adopt the new approaches, behaviors or culture. People need to buy-in, be engaged, be committed, and held accountable so that responsibilities are met in order to enable the project’s value.

The following are some barriers or challenges that your organization will most likely face in your DevOps program implementation, and that, if not addressed or managed appropriately, will highly increase the chances of failure of the initiative:

Resistance to change:

Many people will resist the new approach and the collaboration culture adoption; this is something you cannot avoid, but you can manage the resistance to change. Are you aware of who are these people who will not naturally go with the flow? Do not wait until the project is being implemented to realize this resistance; rather make it visible before even approving the project! (I will mention later how to do this.) If people are reluctant from the start, you can find ways of motivating them or find alternatives.

Lack of accountability for benefits:

The benefits of the project are normally forecasted, but who will be accountable for each of them? We cannot expect the program to deliver the benefits by itself—there’s someone who must be held accountable (and responsible).

Avoidance of responsibility:

Responsibility for tasks is many times skipped by people or thrown to others, and in the end nobody is responsible for doing something that happens to be critical for value creation. If people know their responsibilities beforehand and are committed to them, the chances of unnecessary transfer of responsibility will be minimized.

Uncertainty of benefits:

Many benefits are considered to be intangible, not necessarily because they cannot be measured, but because they have a high degree of uncertainty (e.g. increased customer loyalty), hence people do not want to commit to them.

No matter how big the benefits you identify in your business case are, they might be missed if these barriers are not managed. Therefore, the business case should go beyond what it currently is (i.e. a tool for project justification and budget approval). The EVC™ (Enterprise Value Creation) framework introduces the concept of Business Value Plan™ (BVP™), which is a plan that includes everything the business case already does (plus additional elements), but its use goes beyond obtaining the justification of the program—it is mainly focused on managing the value of the project from justification all the way through value enablement and realization. The BVP should be executed holistically with the project plan to track, measure and enable value creation throughout the stages of the project.

How does the BVP help managing the aforementioned barriers? The following are excerpts from the EVC Framework, which should be part of a DevOps Business Value Plan to help proactively address those challenges:

  • Identify all the project’s benefits and hold a person accountable for that benefit (benefactor); define responsibilities too. Identify also who will receive that benefit (beneficiary).
  • Bring benefactors and beneficiaries together and define and agree with the beneficiary on the KPIs that should be achieved as part of that benefit (e.g. 10% increase in business productivity through faster deployment of application functionalities). Define and agree with the benefactor on the associated SLAs that need to be met in order to achieve the defined KPI (e.g. new application functionalities deployed in less than 1 week). (This is the stage where resistance to change will rise, even before the project is approved, giving you an opportunity to manage it.)
  • Track and measure fulfillment of responsibilities according to the plan throughout the project stages. Define appropriate metrics aligned with KPIs and SLAs, and define suitable measurement methods that will get you the relevant data; and exploit them using your data analysis capabilities. Take corrective action as needed during the implementation.
  • Include intangible benefits in your list of project’s benefits. Even if some benefits have a high level of uncertainty, the uncertainty will always be on the realization of the KPI (e.g. 15% increase in customer satisfaction); but if you identify the SLAs (benefactors) associated with the fulfillment of that intangible KPI (e.g. faster incident response times, enhanced tools for better user experience, etc.), you can focus your efforts on meeting those SLAs, and that will increase the chances of achieving the desired KPI.

Remember, there is no secret to project success and effective value creation; it’s all about adopting the best practices in the industry and adapting them to your organizational context and business needs.

“Success is nothing more than a few simple disciplines, practiced every day.”

–   Jim Rohn

PMI is a registered trademark of the Project Management Institute, Inc.

EVC, Business Value Plan and BVP are registered trademarks of Glomark-Governan LLC.