RFI and RFP Resources

Suppose you`re part of the team that`s been asked to put together a plan for replacing your organization`s outdated, risk-laden policy administration system. If it`s been more than, say, 10 to 15 years since your organization has last done this ( or if this has ever been done), you are probably dealing with a legacy patchwork quilt of software applications, a couple probably written in ancient Sanskrit, running on a bunch of different hardware platforms, sharing data indirectly through files and databases.

And, other elements of the complete PA platform—systems, processes, and even infrastructure components—may be candidates for redesign or replacement, depending on what`s discovered along this journey. Why? Of course, your colleagues are smart, and they know a lot, but you don`t know a lot of what they know. And you know that when your colleagues leave the organization, their knowledge leaves, too. (Oh, and by the way, a lot of them may already be gone, along with chunks of their knowledge.) That all boils down to this: at the moment you don`t have a whole lot of documentation to work with.

Do the thing right, or do the right thing?

Meanwhile, your executive sponsor says: “Skip the request for proposal (RFP) . . . just get the best of the vendors in here to do a demo and some proofs of concept, and pick the best from the pack.” This implies that you and your colleagues already know what the company needs, or maybe you`ll know it when you see it during a demo. Of course, what if you don`t see “it” during the demo? Maybe no one thought to ask for “it”. Maybe your scripted Proof of Concept (PoC) scenarios didn`t include “it.” Why is this? Because the “it” at the heart of pre-existing software packages was designed for someone else`s company.

You want to do the right thing, of course, which means you want to maximize the chance of this major transformation being a success. In turn, that means you want this transformation to go as flawlessly as possible, and what that really means is being able to gracefully handle the tough situations, as well as those that are merely annoying.  You must deliver the key functionality needed by the organization and you are determined that operations will run not only as smoothly as they have in the past, but they will run even more smoothly and effectively.

You`d never imagine betting the outcome of a once-in-a-generation core business platform transformation on a bunch of demos and some scripted proof-of-concept scenarios, would you? Well, would you?

Or, are you in the camp that wonders if the investment of the volume of company resources needed to create a robust and complete RFP and then evaluate multiple vendor responses for a major core business transformation is worth it?

“Maybe our sponsor is right. Just get the vendors in here and we`ll see what they can do.”

Regardless of the camp you are in, you might be thinking that when the dust settles, the outcome of these two approaches would be pretty much the same anyway, so why bother? And even if you don`t believe this is true, maybe your executives do, and you`re not relishing the thought of the uphill battle you`re going to have to fight to convince them that cutting corners on a once-in-a-generation initiative is too risky to seriously consider.

There`s another phenomenon in play; busy vendors that either won`t take the time to respond to an RFP with perhaps a couple of thousand requirements or who won`t devote enough energy to produce a complete and accurate response to such an RFP.

What`s the right thing to do for the good of your company?

Why not just demos and proofs of concept?

Are there questions the vendors should be asked but may not get answered through demos and proofs of concepts? Here are a few possibilities:

• What`s your implementation approach and what services do you provide?
• What are your terms and conditions, initial cost, and time-to-implement estimates?
• How do we know you will be a true vendor partner in this transformation, and how will you clearly demonstrate that to be the case?
• What required functionality do we need that we didn`t see? How do we see it to validate it exists? How can we be sure we know what that functionality is?
• What functionality will we be paying for that we do not need and won`t use?
• Are we willing to completely change our processes to conform to the processes inherent in any vendor solution?  If the solution is configurable, how do we know what to configure? And, how to configure?

The last three bullets aren`t really questions for the vendors. They are questions that project leadership and the steering committee will need to answer to reduce the risk of project outcomes that are below expectation, assuming the project`s expectations have been clearly defined and captured.

The most effective way to reduce the risk of missing required functionality, as well as paying for unnecessary functionality in the winning vendor`s solution is to reduce the uncertainty you have about whether or not that functionality is or is not provided in a satisfactory way by the solution.

And how do we normally ask whether specific functionality exists in the vendor solution? We do it by listing the requirements we have and asking each vendor to tell us if or how well they can fulfill each of those requirements.

Where do we do that? In an RFP, or course.

Something for Nothing?

No one gets something for nothing, right? Yes . . . and no. You reap what you sow, but only if you harvest the crops once they have grown.

If everything done in a project of this scale is treated as a one-time effort, success may come. But what will be the odds of success in the next large transformation effort your company undertakes? And what about the many smaller efforts that might benefit from what`s been learned?

Have you improved your company`s ability to plan and execute large projects like this lately? Or will next time be yet another new start, re-learning and re-inventing what you already knew, what you`d already invented?

Yet so many organizations neglect to leverage all the learning that must, by definition, take place, either at the beginning of a transformation or, painfully and incompletely, as the transformation progresses. Don`t fall into the “hurry up and get going” trap. Instead, dedicate resources to capture as much knowledge, experience, and re-usable assets as possible before, during, and after the project so subsequent projects can make effective use of them. Do that consistently and you`ll create value that grows significantly over time.

In the project that this article is based on, there were several high-value spinoffs from the RFP effort:

• More than 250 business processes were mapped and validated, greatly accelerating the client`s recently-started effort to develop a high-value enterprise architecture discipline and the artifacts and infrastructure to support that.
• Discovering and documenting these processes provided the foundation for documenting the future-state processes to be implemented on the new policy administration platform
• Hundreds of “pain points” were identified and will be used as input into the future-state design, with the potential for significant improvements to process performance
• The client launched an in-house business analysis (BA) competency, including a formal BA group equipped with a proven set of tools and methods, with training and experience in their use. The existence of this group will ensure business processes continue to receive the care and feeding to provide long-term value to the organization.
• There is significantly enhanced awareness of the end-to-end nature of the company`s processes by its employees, and, possibly more importantly, employees have a much greater understanding of how work in one area impacts that in another.

What did it take?

• Strong leadership support from the client company executives
• Commitment by the client to provide the resources needed, both as subject matter experts (SMEs) and responsible project participants
• If you want the newly-gained (or re-gained) knowledge to accumulate within and be retained by your company, then use as many internal resources as possible to fill out the project team responsible for the RFP
• SMEs must be ready and willing to provide the information needed to develop a solid, complete RFP

Looking ahead

Overhauling the systems at the center of your business isn`t a quick exercise or one for the faint of heart. Changing from the company you are today into the one you want to be takes time. As you continue down this road, here are the things you must plan next:

• Assess the RFP responses submitted by the vendors and select finalists
• Plan and execute vendor finalist demos and proof of concept workshops
• Select the winning vendor from a pre-defined and strict set of criteria and begin planning the implementation
• Initiate an organizational change management track for the project to maximize successful use of and wide adoption of the new tools and processes
• Continue to work to build, mature, and integrate the component disciplines of the client`s Change and Process Innovation Factory:  business analysis, enterprise architecture, and lean.

Conclusions

A strongly disciplined, well-organized and well-executed RFP process generates significant value for a client company, in three primary ways.

• First, it arms the client with a strong data- and fact-driven objective approach for assessing candidate vendors and their products, and for choosing the best-fit solution from among the candidates.
• Second, it positions the client for system implementation success by providing a solid repository of detailed information about requirements, business rules, processes, and data that will be invaluable assets in creating and adopting the new solution across the enterprise.
• And finally, the effort itself provides a golden opportunity to create new or mature existing capabilities in Business Analysis and Enterprise Architecture, ensuring that the opportunity to up skill these important company capabilities is not missed.

To RFP or not to RFP?

Is this really that hard a decision to make? Cutting corners could be disastrous. Think about the horror stories you`ve heard about ERP (enterprise resource planning) system implementations. You don`t want your company to become a statistic in another of the core system transformation battle. Do it right. Invest in creating a high-quality RFP and your company will reap numerous benefits, if that effort is well planned and well executed.

What`s at stake is nothing less than the future success of your company.

No pressure, though…