Let's start with the most important question in any decision-making procedure - who needs to be engaged to make this decision?
On one side, you might think this is easy - most companies have a hierarchical structure, with someone above us who should make decisions. In such cases, we can use this organizational tree to reach the right person to make the decision. Simple, right?
It's not so simple. I've never seen a company successfully implement this approach. This model inevitably leaves someone dissatisfied, and ultimately the company loses—at minimum, the potential it could have created by engaging more people.
On the other side, I've observed that the inability to make correct decisions hinders most modernization processes. This typically happens in two scenarios: either too few people are engaged, or numerous people are involved without clear role assignments, especially regarding who has decision-making authority. When responsibilities aren't clearly defined, the modernization effort often stalls regardless of how many participants are involved.
This inspires me to develop a framework that summarizes my experience and simplifies this process. For now, I'll share the first part of this process—my interpretation of the RAPID framework organized around modernization subjects. In my case, the more appropriate acronym would be RPIAD, as I've revised the order of people who play roles in this process.
This tool helps me identify which people are engaged at each stage and determine what problems they might encounter with the subject of this decision.
For example, when implementing a new CI/CD platform, we can apply this framework effectively. In the "I" (Inform) category, we would include Developers, DevOps engineers, and the Release Management Team—essentially everyone who will interact with the new platform or might have requirements related to it.
However, for the "P" (Perform) category, we can narrow our focus to the actual end users—primarily Developers and DevOps engineers. These are the people whose experience matters most from a usage perspective, as they'll be working directly with the system daily.
Okay, let's now focus on the theoretical side of my RPIAD process. To move forward, we need to concentrate on finding the right people for each role. To help with this, I've simplified the center of the image and added notes for every role in the process.
Now, let's explore the RPIAD order by 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 describe this person's engagement in steps, allowing you to anticipate what information they'll need from you. Gathering this information upfront will simplify the process later. I suggest making several attempts to fill in this data, evaluating each time whether this person or group actually needs to be involved.
Where have I been using it?
I've been applying this tool across various business functions. It started with modernization processes, helping decide which tools to implement, where to deploy them, what methodology to follow, and what changes to make. I've used it throughout process modifications and optimization efforts, for new tool recognition, and even within my sales process to identify key decision-makers for my product!
I believe having such a tool can clarify your objectives in numerous scenarios. What do you think about this approach? Are you ready to give it a try?
Don't hesitate to ask me questions if you have any - I love insightful discussions!
