Recently, I met with a new CIO of information services. His company’s primary product and cash cow is slowly going away due to contractual obligations with their customer.  The remaining portfolio of products are a mixed bag of winners and losers. His first executive order from the CEO was to cut IT budget to match the future operating budget. This is a daunting task especially when the company hasn’t devoted time to truly understanding their product portfolio. The ability to prioritize which products are worth continued investment and which products should be retired would make the budget conversation much easier. This is consistent behavior we see across large companies. They tend to not give product managers responsibility for true P&L management and, in turn, continue investing in products that aren’t profitable. It’s easier for organizations to lump a portfolio of products together, sharing profits and expenses and often masking true performance.  I won’t begin to dissect why I think companies behave this way. My gut tells me it is part political and part complexity.

In this case, the CIO had a handful of ideas on how to reduce operating expense while maintaining the current product portfolio. He wanted to build some political capital in the organization before he tackled the product P&L discussion and came to us for advice. Our recommendation was to standardize DevOps across the 40+ products this company managed. This would be a less threatening way of tackling the product P&L issue and will generate more discussion on how to prioritize which products adopt the DevOps standards first and why. It would also help increase potential revenue opportunities for the business by delivering product more quickly while reducing operational expenses related to managing and maintaining multiple software release products and processes.

Consider my top 5 business reasons to standardize DevOps in the Enterprise:

1. Reduce time per release allowing your business to deliver products to market quicker
2. Reduce staff per release allowing the technology team to reallocate those resources to focus on business problems
3. Eliminate duplicate software licenses and maintenance agreements
4. Reduce security risks by building in security tests during each phase of DevOps
5. Make your technical teams happier because they feel the impact they have to the business

Sounds good, right?  However, standardizing DevOps across your product portfolio isn’t easy. There isn’t a single technology stack or a list of processes you can adopt for the Enterprise.  It takes cooperation between the development, infrastructure and operation teams.  There has to be a shared vision for why this is a priority and a culture that supports testing and failure.  There also has to be a deep understanding of the product portfolio and what products can’t be automated due to legacy technical issues.

Making the pitch for DevOps across the Enterprise requires your team to know your numbers. You have to do the research and understand your current state, cycle times and quality metrics before you start chanting the DevOps mantra. How and to whom you position this effort is also important. Do you partner with the business or do you treat it as an internal IT project? Both of these strategies require careful consideration.

The biggest inherent benefit that comes from this exercise is the ultimate conversation you eventually have with your business customers about the product portfolio and how prioritization should occur. The prioritization process will force the business to evaluate products and hopefully shed light on which product(s) need to be divested and retired. This downstream benefit will ultimately help you reduce the workload on your department while saving the company money by eliminating products that aren’t profitable.

So, how do you get DevOps started?   While there is no cut and dry DevOps checklist to review, we work with our clients to develop an iterative approach, breaking the implementation down into manageable pieces.  We recommend starting with these 7 steps:

1. Build a cross-functional team including development, infrastructure and operations
2. Build a vision document, define your culture, and establish KPIs for the current and future state
3. Inventory your current product portfolio, determine product owners and managers
4. Document your current product/software release processes and the underlying products that support it
5. Define your DevOps target architecture and processes
6. Find a low risk product to test architecture, products and processes
7. Rinse and repeat until the kinks are worked out

If you are just starting to consider DevOps for your organization or you are somewhere in the midst of implementation, read our 5 Common Misconceptions about DevOps and let’s talk.  I’d love to hear your perspective on the challenges and the benefits of DevOps.