Atomic created its Research, Design, and Planning (RDP) phase to target the Innovation area in the Venn diagram where desirability, viability, and feasibility collide. Learning about the business and the users reduces risk and makes sure the team can build the right piece of software.
The ideal RDP phase gives enough time to validate the engagement hypotheses (how the team knows they are building the right thing) before the client commits a large amount of capital.
Three types of clients often don’t give the RDP phase enough attention. These are worth exploring so new clients or anyone looking to build custom software can be aware of the tradeoffs. With the right knowledge, we can get better outcomes for any client’s specific situation. The three main types are:
- The client who has made promises and needs to start building
- The client who feels they don’t have the budget to spend on an RDP phase
- The client who knows what they want vs. what they need to build
The Client Who Has Made Promises and Needs to Start Building
In some cases, the client sold the internal stakeholders a project before completing full validation. This happens for many reasons, but often this client is in a rush to get something done and out the door.
These are my least favorite engagements, since turning a speeding ship can be tricky. Stopping work to do initial discovery is often off the table. That means projects at this point continue their inertia, but they miss the mark of innovation, producing a less optimal outcome for the client.
Additionally, on a project like this, team morale can erode when their red flags are continually dismissed for the sake of progress.
The Client that Feels They Don’t Have the Budget to Spend on an RDP, and the Client that Knows What They Want vs. What They Need to Build
We’ll cover these two clients together because the thought processes are similar.
Budgets are often the limiting factor to software engagements. Sometimes clients choose to limit the RDP phase and spend those funds on the implementation phase. So, why do many of those clients forgo or limit the RDP phase? Enter our next contestant: The client that knows what they want vs. what they need to build.
At other times, clients come to the engagement with over-enthusiastic ideas about what to build vs. what they need to build. These clients tell themselves they have the answers about who the product is for and what they really need to build. All is fine for weeks until the rubber meets the road. When some fundamental issues start to arise, we get to a sticking point.
This is a better place to be than the first client. If the team catches warning flags early, communication is solid, and there’s still time to make changes, success is still likely. User testing, challenges with creating user flows, and continuous delivery of the software can help identify these warning signs.
When should a client limit the RDP phase?
If clients share with the implementation team why their concept fits into that innovation part of the diagram, we have less “pre-work” to do. We love when clients have done the research and explored design concepts.
By definition, these clients are more prepared, engaged, and knowledgeable about the product. Not all clients are in a position for this and that’s okay. But when the client brings that research to the table, the teams can decide if the project warrants a small research stage or if it’s time to move to the design and planning stages.
It’s much less expensive to prove out an idea earlier in the process. Therefore, I highly recommended that the RDP phase is the place a client should focus their efforts.
Learn more about the RDP Kickoff here.