Lessons from a Release Management Investment: What Worked, What Didn’t with Plutora

The views expressed in this article are based on the author's experience and perspective on the topic.

In 2017, I led a managed testing service for an Australian oil and gas company. Their business spanned the entire supply chain, from sourcing energy to delivering it to homes and businesses.

The portfolio I worked in was focused on gas exploration and production. For those unfamiliar with the process, it begins with securing approvals from landowners, the government, and other stakeholders. Once approvals are in place, natural gas is explored below the land and ocean beds. If gas is discovered, engineers and analysts determine whether it’s feasible to extract, and if so, wells are drilled to begin extraction.

The extracted gas is then processed to remove elements like water, and a network of pipelines distributes the gas to residential and commercial customers.

Visualizing the Technology Landscape

As you can imagine, the supporting technology ecosystem was vast. It included products like SAP SuccessFactors, Salesforce, Planning Space, Energy Components, WellView, MyDay, Aveva, ArcGIS, BluCube, PowerBI, and DIMO, as well as cloud computing, storage, databases, and networking, down to sensors on the pipelines themselves. Managing quality and release across this sprawling landscape was no small feat, with its myriad relationships, configurations, custom-built configurations, and downstream dependencies.

To navigate the complexity, I printed an A0 poster of the known architecture and stuck it to the pillar next to my desk to get a visual grip on it all. Despite that, running compliance checks on release candidates remained a monumental challenge.

Building a Business Case

After a conversation with the Head of DevOps, I decided to develop a business case for new tooling. After all, how could I fulfill my role as Gatekeeper Gandalf, ever wise and vigilant, without the right tools? I could understand the consequences of what could go wrong if poor choices were made, but if I struggled to visualize the complexity, others likely did too.

Poor decisions often arise in high-pressure situations where project managers insist, “We absolutely must get that release out today.” In those moments, my role was to stay calm and think critically, ensuring we avoided disaster.

But how do you measure disaster prevention? I chose to frame it using a risk-based approach. A new solution wouldn't just simplify processes; it would reduce the likelihood of disasters and mitigate their impact if they occurred.

What could go wrong if we didn’t invest? For starters, we might not secure the necessary approvals from landowners, exposing us to legal risks. Our data-driven predictions might be off, causing us to drill in the wrong place or miscalculate the amount of gas. Sensors could fail to detect critical changes in temperature or pressure, leading to catastrophic failures. These risks sat at the top of the organization’s risk register, practically building the business case for me.

Choosing the Right Tool

After an options analysis, I chose Plutora (now Planview) as the solution. However, it wasn’t a cheap investment: the first year alone cost $100k for just five seats, and the onboarding engagement included limited professional service hours for setup and training.

While Plutora showed promise in managing releases, the initial integration with Jira wasn’t as straightforward as expected. The limited professional services provided during onboarding meant that the integration was only functional at an MVP level, leaving gaps in data flow between the two systems. These gaps made it harder for me to fully leverage the tool's capabilities, especially in terms of automating workflows and tracking release progress effectively.

A major gap was my inability to see release dependencies across the integrated tools clearly. Without visibility into how releases were interdependent, I struggled to manage complex release schedules and ensure that critical steps were not missed. I spent considerable time manually managing the integration, troubleshooting data discrepancies, and ensuring that the tools could work together. This extra effort not only increased the tool’s cost and complexity but also increased the risk of missing key release milestones or making misinformed decisions.

Plutora did deliver some of the desired benefits, but the onset of COVID-19 reshaped priorities. Demand dropped, gas prices plummeted, and the technology team faced budget cuts. Unfortunately, Plutora was one of the first tools to go.

What should you consider before deciding:

External factors can significantly affect the success of any tool or system. It’s important to consider these before making a decision:

Conclusion

Reflecting on the experience, I gained invaluable lessons about navigating complex technology landscapes and the importance of selecting tools that can mitigate risks. Implementing tools like Plutora requires careful consideration of integration needs, ongoing investment, and alignment with both the shifting goals of the organization and the technology landscape. Though Plutora delivered value in certain areas, it became clear that continuous commitment, strong stakeholder alignment, and adaptability to changing business conditions were paramount to its success.

As you consider adopting similar solutions, it’s important to balance the immediate benefits with long-term costs and ensure the tool integrates effortlessly with your systems. Always stay aligned with your team’s goals and the broader organizational strategy, and be prepared to evolve your approach as circumstances change.