An RFP is a means to an end. The end is to transform some or all of a business. The usual means is to gather requirements, match them up with software features as promised by the vendor, and choose the software that matches up the best.

Therein lies a Grand-Canyon-sized gap: connecting the dots separating your understanding of what the software should do (requirements) with how you want your organization to run differently (the transformation).

What a traditional RFP will help you do is find a software solution that provides capabilities the business needs to stabilize, optimize, and transform. It’s a partial solution – its results are, that is, necessary but not sufficient.

The challenge that RFPs are trying to solve is to help you and your colleagues gain confidence in a transformational event. To that end my company recognizes five stages of organizational change: Analysis, Organization, Stabilization, Optimization, and, finally, Transformation. The problem is that transformations need to be understood and considered—not sold. You are expecting that the world is going to change in some way, and that the way the business has been working may not work in the future.

Which is a key reason you need to avoid the tiresome “Chocolate or Vanilla?” argument. It’s a transformation. You and your colleagues are re-imagining the business and the marketplace it competes in. Chocolate, vanilla, sprinkles and the rest are about keeping IT costs down – a perspective that can cripple a transformation before it has a chance to start.

Once more, with feeling: If you set your goal as selecting software, even the best choice will be the wrong choice. Your goal is transformation. Your selection goal is choosing the best combination of software and solution partner.

There are a lot of ways to select this combination (the starting point is to include the implementation team) that work better than RFPs. Depending on your situation, here are two simple tools to consider:

One approach is largely suggested by a regular reader (Mike!) is to build a decision score card. This approach is useful when you are still narrowing down options—but maybe not for making a final decision.

• Form a selection team of key partners in your company that need to have a say in the decision.
• Ask this team to create a list of 20 high-level requirements, described in terms of business capabilities, not software features and functionality, to verify that the solution provider has a basic grasp of the fundamentals.
• Ask the vendor to pick 10 or workflows that cover these requirements. Budget a bit of time- this should take a half day at the most. Make sure to budget time for questions and answers—with both the vendor and yourself getting a chance to ask questions of each other.
• Ask the selection team to score on how well the vendor showed that the solution answers the needs for current as well as future state of the team.
• Ask the vendor for an informal quote—just on the software licenses. Don’t ask for an implementation quote from them. Also ask for customer references and talk to other customers.
• Vendors generally are not the best implementors of a system. This seems counterintuitive, but it is often the case. In some SaaS software options, you may not have a choice, but where you can, ask the vendor for introductions to at least three implementation partners. To start, ask yourself only one question—“Can I imagine that this company will work shoulder to shoulder with me?” If you find yourself saying any form of  “Not really”, keep looking.

The next suggestion is the Conference Room Pilot (CRP), described here as “An Agile variant optimized for implementing COTS and SaaS applications.” (See this article for more info  https://issurvivor.com/2015/11/30/devcrpops/ )

This definition captures a lot of the benefits of the approach—In a limited amount of time, you will gain confidence that the system, team and individual, from all sides of the table, can quickly address requirements and productively demonstrate even a bit of limited value quickly. You will leave this event knowing this project is going to work—Or not. You will also know if you feel comfortable knowing if you and the team are ready for this.

The key challenge is having a “CRP” master or mistress of ceremonies that can explain the process, keep everybody on track, and eliminate confusion,  and maintain forward momentum. This person needs to show people how to use the system, describe the adaptations made, and be emotionally available for new users who are giving this their best go. There should be a completion goal each day, and frequent check-ins to make sure that people are staying on track. By definition, this is a form of Agile, and Agile is radically centered on the humans in the process.