[RBM+E] Finding the right decision-makers systematic way! (+Case Study)

This is a paid reader's extended version of my free post with Case Study.

Did you seen my today post about finding the right decision-makers in processes and how it can help you deliver better value?

Let's take a quick recap:

RPIAD order is about asking significant questions for each phase.

For "R" - "Recommendation" - think about who will help recommend and secure acceptance for your initiative. Who are your champions and influencers? Whose endorsement carries weight with decision makers?

For "P" - "Perform" - consider who will actually implement and use the system. Ask yourself: Who will operate this solution daily? How will this change impact their workflow? What training or support might they need?

For "I" - "Inform" - identify everyone who will interact with your system and could provide valuable input. Who should review the proposal? Whose feedback might reveal blind spots or opportunities for improvement?

For "A" - "Acceptance" - validate what formal approval processes are required. What documentation, signatures, or compliance checks must be completed? Whose sign-off is necessary before moving forward?

For "D" - "Decision" - determine who holds the actual decision-making power. Look beyond titles to identify the real decision maker! Who controls the budget? Who has final authority to approve or reject your initiative?

You can map out this person's engagement in clear steps, which helps you anticipate what information they'll need from you. By gathering this information upfront, you'll make the entire process smoother later on. I recommend making multiple attempts to collect this data, and each time, critically assessing whether this person or group actually needs to be involved at all.

Okay, Now let's take a look at a small Case Study now:

CI/CD Platform Selection: A RPIAD Case Study

Background

TechGrowth Solutions is a mid-sized financial services company with approximately 500 employees, including 120 developers spread across 15 teams. Their technology stack includes Java microservices, Python data processing applications, and a mix of legacy .NET applications.

The company had been struggling with deployment issues for years. Releases were largely manual, requiring extensive coordination between development teams and operations. Deployments regularly extended beyond planned maintenance windows, occasionally causing customer-facing outages. Different teams followed inconsistent deployment practices, making cross-team coordination difficult and creating knowledge silos that became apparent whenever key team members were unavailable.

Market pressures were mounting as competitors were releasing features at twice TechGrowth's pace. The CTO had set an ambitious goal of reducing time-to-market by 50% within 12 months, while improving deployment reliability by 90%. A modern CI/CD platform was identified as a critical enabler of these objectives.

The Initial Approach: Where Things Went Wrong

The Infrastructure & DevOps team was tasked with selecting and implementing a new CI/CD platform. Their initial approach followed a familiar pattern:

1. The team researched current market offerings based on their requirements

2. They created a feature comparison matrix focusing on technical capabilities

3. They selected a shortlist of three platforms that best met their team's needs

4. They conducted internal tests with their automation scripts and workflows

When they presented their recommendation to leadership, the proposal immediately hit roadblocks:

• Isolated technical perspective: The team had selected a highly technical solution that would require specialized skills to maintain. Their proposal emphasized pipeline flexibility and Kubernetes integration, but failed to address how it would impact the company's time-to-market objectives.

• Narrow requirements gathering: The solution addressed the Infrastructure team's needs perfectly but failed to consider the requirements of other development teams. Front-end teams required simple UI testing integration, while the security team required specific compliance checks that weren't supported.

• Missing business context: The team couldn't articulate how their solution would deliver the 50% reduction in time-to-market. They focused on technical capabilities rather than business outcomes.

• Lack of buy-in: When questioned about ongoing maintenance, the team realized they hadn't considered who would manage the platform long-term. Developers were resistant, seeing it as "another tool to learn" rather than a solution to their daily challenges.

The project stalled for three months as stakeholders debated alternatives without clear decision criteria.