[RBM] - Case study - no decision makers!

As I promised, our RAPID-based modernization cycle will end. Right now, I want to share with you a few case studies of modernization projects. Each of them will touch on a different aspect of this process.

The first case is very typical, and it happened in most of the projects I worked on. An IT department came to us for help modernizing its CI/CD toolkit. Taking a step back from technology, the DevOps team leader was responsible for this project. The company currently uses mostly ancient Jenkins-based pipelines - built with the click-and-play method, so it's not even in code. The organization tried alternative solutions like GitLab, GitHub, Bitbucket Pipelines, and some on-premise solutions like CircleCI or GoCD. Nevertheless, they failed due to a lack of clear goals and the inability to pick one solution for the entire company.

Our first step is to help them identify company needs. Our meetings include development teams that use CI/CD tools, the DevOps team who manages those tools, and then the Release Management team who coordinates the entire deployment process from a business perspective. From this meeting, we gathered numerous requirements for the proposed system, as well as plenty of ideas for what features will be needed. Therefore, we recognized that not only CI/CD toolkits are needed, but also standardized pipeline backbones and additional tools to monitor and control the CI/CD process.

As a result, we built a proposal together with our DevOps leader showing what needed to be created. In our methodology, teams will act as our additional recommenders, performers, and somehow, informers.

Through this review, we gathered insight into what sources of information we can approach later on, such as compliance and security. These sources of information should be consulted to ensure the process is correct. Our goal was to find ideas that would simplify their work. Once again, we are faced with plenty of requirements - but with fewer ideas of how it should be done. We conducted research with the DevOps team on how to fill these gaps. Thereafter, we conducted the next iteration of reviews.

This process of proposal development is pretty ideal at the moment. The next steps in this project turn awry. The IT department does not have a budget for such projects. Release Management lacks funds to implement any tools they need. The rest of the organization doesn't want to contribute financially. Then, we learned that we should get in touch with the purchasing department. The reality is that they are unaware of the need for such a change, and they lack an understanding of the differences between current conditions and what is desired.

As a result of long discussions, we finally got to speak with the IT director, who said the budget could be scheduled for next year. It is common practice in this organization to queue up for later. Since we don't know how to engage top management, we are not prepared to do so at this time. The project ended with a beautiful idea. We started working with our DevOps team more in a T&M fashion. We are tasked with helping to implement the standardized way we described in this proposal and integrating it into the current toolkit. They decided that they would try to extend the CircleCI setup for this case.

It was a small step forward - from what I gather, most of our proposal was adopted. However, it was a long and painful procedure. Over time, it was mostly extended to 2.5 years from the initial 6 months.

In my mind, the most significant lesson I learned here is that if company decision-makers do not buy into the idea, then there is little chance of implementing such cross-organizational changes.

We lacked here stages of speaking with business acceptance as well as decision makers. We lacked the ability to convey the business vision of this change and ROI the company can get from this.