The rapid acquisition decision (RAD) request for proposal (RFP)


Scott R. Coplan, President, COPLAN AND COMPANY
Wes Scruggs, CIO and Executive Vice President, Aptium Oncology, Inc.

Successful project managers know a proven way to get what you want – clearly define your needs up-front. Extra effort spent at the onset of an Information Technology (IT) project results in clear understanding of user requirements, a solid basis for acceptance testing and documented traceability from concept to delivery.

You’ve determined that you need a new system. Now you need a way to collect the information necessary to select an appropriate solution. You don’t have the time, budget or personnel resources to spend extended hours at the beginning of a project defining all your user requirements in exacting detail. Projects like an Electronic Medical Records (EMR) system require clinical input from physicians, pharmacists, nurses and administrators – all extremely busy individuals for whom the “down-time” of system acquisition represents significant cost. For example, organizations like Aptium Oncology, Inc., (Aptium) planning an EMR for multiple Cancer Centers across a wide geographic area and assembling people to reach consensus on their requirements was too time consuming and expensive.

Can you still successfully acquire a system that meets your needs without sacrificing clarity or reducing your available options? Can you identify viable options that will result in meaningful budget and schedule estimates? Yes, if you use a Rapid Acquisition Decision (RAD) Request for Proposal (RFP).

A RAD RFP process can reduce the time to prepare requirements, but still provides enough detail to ensure users are sufficiently involved to evaluate vendors intelligently and quickly and select a solution. Using a baseline to identify scripts, describing requirements only, keeping RFP responses uniform, and facilitating structured demonstrations with selected vendors can give you the results you need, in the time you have. Like Aptium, you can get from knowing you need a new system, to knowing which system you need, before requiring an extended commitment from expensive and busy resources.

Is RAD Right for Me?

Not all projects are suitable for the RAD RFP process. The RAD RFP is a viable short cut, assuming your organization is willing (and able, according to its solicitation and purchasing policies) to do the following:

  1. Are you able to identify a select number of vendors that likely support your user requirements? If your needs are so unique that they require a custom-developed solution, the RAD process is not for you. RAD only works for those projects that are likely to be achieved using Commercial-Off-The-Shelf (COTS) applications.
  2. Are your COTS requirements unique enough to limit the number of possible vendors? There may be hundreds of vendors supplying software to an industry, but only a few supporting a specific industry niche. For example, Aptium manages nine outpatient Cancer Centers hosted at major hospitals around the country. They need an EMR vendor that supports outpatient oncology. This eliminates those vendors that supply only general EMR solutions.
  3. Can your acquisition process accommodate “multiple rounds” of give-and-take with potential vendors, so that you can address cost, schedule, technology, etc., incrementally with only vendors that pass successive round of elimination? If not, RAD may not be suitable for your project.
  4. Is the primary basis for selecting a solution that it provides the highest user requirement support for the lowest cost? The RAD approach begins with user requirements (i.e., scripts of functions and essential data) as the underlying qualification for evaluating potential solutions. Of course, other factors like vendor experience, product maturity, and one-time and ongoing costs must play a part; however, RAD focuses first on user needs to narrow the field of available options, before requesting additional vendor information for evaluation.

If you answered yes to all of the above questions, then a RAD RFP may work for you.

The RAD Process

The primary purpose of the RAD process is to reduce the time and cost required to select the right system for your organization. To accomplish this purpose, it is necessary to “speed up” getting over the major project hurdles of needs definition, vendor solicitation and proposal evaluation.

This advanced pace is possible if you heed the following principles:

  1. Don’t start from scratch,
  2. Focus on “what” rather than “how,”
  3. Limit evaluation to essentials, and
  4. Control the vendor response.

Step One: Lay the Groundwork

As you begin the groundwork, identify your stakeholders. Stakeholders are those individuals with a “stake” in the successful outcome of the project. In other words, the outcome of the project affects a stakeholder’s problems, needs or interests. There are Primary Stakeholders, those directly affected by a project, and Secondary Stakeholders, those indirectly affected by the project. For example, a nurse is a primary stakeholder because he/she is a direct system user, while a billing clerk, who receives changes from nursing, regardless of the EMR system implementation, is a secondary stakeholder.

A Stakeholders’ Analysis is an assessment of a project’s key participants and the extent to which the project affects their problems, needs and interests. It represents the first step in building relationships by identifying:

  • Capabilities of an organization to attain project success, i.e., project readiness,
  • Characteristics and interests of stakeholders,
  • Conflicts of interests among stakeholders,
  • Roles of stakeholders, e.g., issue resolution, periodic committee participation, full-time committee assignment,
  • Capacity of stakeholders to participate in the project and
  • Participation by different project phase, i.e., system planning, definition, acquisition and implementation.

The completed stakeholders’ analysis confirms the importance of the project and the stakeholders’ potential influence, commitment and engagement levels.

Once you establish that your stakeholders are on board, develop a project charter. A project charter formally authorizes the start of a new project. This includes identifying the project sponsor and applying resources for project initiation. Initiating activities include defining project: objectives, measurable outcomes, scope, a high-level schedule with key deliverables, primary stakeholders, risks, a preliminary timetable, preliminary costs, and various management plans (e.g., communications). The completed project charter requires approval before execution of the project, and includes the identified objectives, preferred option, approach, and preliminary costs.

Step Two: Define Your Needs

The previous step may be obvious. Most successful project management approaches include some variation on these activities above as part of initiating and determining any major project’s viability. In the case of complex IT projects, the information obtained during these initial steps also involves defining user needs, issuing a large RFP document, and then conducting a detailed and time-consuming review of a handful of multi-volume responses from potential vendors.

Defining user requirements starts with researching the availability of existing documentation instead of starting from scratch. Chances are you do not have fully documented current manual and automated processes. Even if you do, this documentation may differ greatly from current and future user needs, and may vary widely by location in a geographically dispersed organization. The RAD process relies upon the existence of some current documentation. This documentation need not be completely accurate, or comprehensive. Existing workflow diagrams (or diagrams of how the system was originally configured), current system documentation, and user functionality “wish lists,” offer a starting point for defining the needs of a new system. You can augment them with additional information, such as vendor features lists, industry best practices, and available product reviews, as appropriate. In the case of Aptium, they had diagrams describing some of the workflows used as the basis for operating newly opened Cancer Centers.

The typical approach to preparing user requirements involves a time-consuming process that starts with this documentation as a baseline. It also includes an intensive six to eight week process of facilitated sessions where seven to nine representative users define workflows, functions and data in a workshop setting. Subject Matter Experts (SMEs), your main source of “the end user” perspective, don’t have the time to commit to this full-time needs definition process. The RAD process reduces the time and intensity of requirements definition by supporting SMEs with Web-based tools to review existing documentation and conducting conference calls (i.e., virtual meetings) to identify needed improvements and to clarify workflows, functions and essential data. In the case of Aptium, these individuals included the Director of Clinical Operations, Director of Oncology, Vice President of Pharmacy, and Treatment Area Nurses from several different Cancer Centers. These individuals had the authority to speak on behalf of their respective professional group, and were able to identify unique elements of Aptium’s business practice that clearly defined the organization’s needs. Because their involvement was limited to a number of short telephone conference calls and draft document reviews, the impact on their daily work routines was minimal.

The resulting “scripts” captured the user needs. These scripts separated the identified workflow into business areas (e.g., scheduling, pharmacy orders, treatment, administration). They also identified specific actors, a person that interacts with the system (e.g., Physician, Registered Nurse, Clinical Assistant), and defined a sequence of actions and related outcomes for each script.

Exhibit 1 below provides a high-level example of a script, while Exhibit 2 is an example of high-level data defined to support that script.

Sample Script

Exhibit 1 – Sample Script

Data Group

Drug Therapy: Substance used in the diagnosis, treatment, or prevention of a disease or as a component of a medication

Sample Data Group

Exhibit 2 – Sample Data Group

Once the users define their requirements, the Project Manager can assemble the RAD RFP in a brief document containing the following:

  • Description of business,
  • Project objectives,
  • Reference and site visit requirements,
  • Demonstration requirements,
  • Scripts for demonstrations, and
  • Evaluation criteria.

Vendors receive a copy of the RFP, which includes a specific date and time required for their individual response and scripted demonstration. Remember, unlike a traditional RFP that might request a product demonstration after evaluation of proposals, the RAD RFP includes specifications for a structured demonstration as part of proposal submission. This demonstration is not a marketing presentation, but a walk-through of selected scripts, in real-time, using the proposed version of the system in front of users who will provide examples of actual day-to-day activities (e.g., orders, assessments).

Step Three: Conduct Demonstrations

The client Evaluation Team selected to participate in the vendor demonstrations is critical. These individuals should include no more than seven to nine decision-makers. In Aptium’s case, this included key project participants from Cancer Centers (e.g., Pharmacy Managers, Nursing Directors, Physicians, Medical Directors, Administrative Supervisors), corporate representatives (e.g., Chief Information Officer, Chief Medical Officer) as appropriate to represent the full range of user needs.

Before conducting the demonstrations, distribute an Evaluation Guide and schedule time for a “walk-through” or training session with your Evaluation Team. Appoint a Team Leader to resolve disagreements between Team members, and focus the Team on support for the scripts, disregarding technology “how” issues until subsequent evaluation rounds. Establish the ground rules for demonstration protocol (i.e., limit vendor marketing, hold questions until the completion of each script, table dissenting opinions until the vendor is absent from the room, adhere to scripts despite any identified imperfections, restrict “off-topic” tangents and diversions, etc.).

On the day of a vendor demonstration, have each vendor focus on executing the selected scripts using “real life” data examples provided by the Evaluation Team. At the end of each script, excuse the vendor from the room, hold a brief discussion and arrive at a consensus score. Use a simple five point scale (e.g., “exceeds expectations,” “meets script requirements,” “meets expectations with workaround,” “can be modified to meet expectations,” and “does not meet expectations”) to score the vendor’s ability to execute the required script. Then invite the vendor to return to the room, ask any follow-up questions related to the scored script, and then proceed to the next script. At the end of the day, hold a brief Team discussion to review and wrap up and tally the total vendor score.

Exhibit 3, below, provides an example of the scoring results from a series of vendor demonstrations.

Example of Demonstration Results

Exhibit 3 – Example of Demonstration Results

At the end of conducting these demonstrations, as with Vendor #1 above, a clear set of front-runners will emerge. Take the top one or two and review their qualifications and other requirements you requested in the RFP. Contact their references, and if those references prove positive, arrange to conduct a site visit with a selected comparable client. As with the user requirement scripts, create and follow guidelines for these activities. These guidelines help the Evaluation Team to focus on key issues, and ensure that you compare “apples to apples” when looking at one vendor versus another.

Exhibit 4, below, provides an excerpt from a sample reference check guideline.

Example of Reference Check Guideline

Exhibit 5 – Example of Reference Check Guideline

As with any evaluation process, it’s important to keep your edge. Remember, while vendors may want to dazzle you with glossy graphic handouts, celebrity-hosted demonstration videos, impressive portfolios or reassuring, smooth marketing speeches. You are only interested in whether the “nuts and bolts” of their application meet your needs. A lengthy introduction to a company or products is not necessary and wastes valuable time. After all, you would not have asked the vendor to participate in the RAD RFP: “If we didn’t know who you were, you wouldn’t be here.”

Identify a single point of contact for vendors throughout the acquisition cycle. You can manage questions and answers from both sides effectively and consistently this way and keep confusion to a minimum.

Don’t share the results of your evaluation with vendors until you complete contract negotiations. Internally, however, carefully identify, track, escalate and resolve issues that may arise throughout the entire project lifecycle.

Finally, present a united front. Avoid disagreements among Evaluation Team members when a vendor is present. If there is dissension regarding a particular issue, ask the vendor to leave the room so that all members of the Team can speak freely. Only then, can the Team resolve and appropriately address all vendor issues.

Rapid Process, Rapid Outcome

The RAD process includes the following time- and cost-reduction steps:

  • Web-based reviews combined with conference calls reduce travel requirements,
  • Use of a baseline and virtual meetings limits demand for SME participation,
  • Identification of a vendor short-list reduces demonstration and evaluation time,
  • Focus on user requirements first helps identify viable solutions rapidly, and
  • Use of cost and schedule information from only viable vendor solutions improves estimating.

The bottom line – RAD RFP can save you valuable time and money:

  • Time your busy (and extremely cost-conscious) end users may not feel they can “donate” to a systems acquisition project.
  • Time you have to carve out very carefully from your operating budget.

© 2007, Scott R. Coplan and Wes Scruggs
Originally published as part of 2007 PMI Global Congress Proceedings – Atlanta, Georgia



Related Content

  • PM Network

    Agile Assurance member content open

    By Parsi, Novid Some project teams believe agile means skimping on requirements management. They're dead wrong. When they disregard this crucial component, they put project success on the line: For 35 percent of…

  • Greatness, a Place beyond Stakeholders' Expectations member content open

    By Deguire, Manon Managing stakeholder engagement calls upon something quite different from process groups and domains of knowledge, it calls upon the ability to create emotional responses such as enthusiasm, trust,…

  • PM Network

    Allied forces member content open

    By Merrick, Amy Seventy percent of organizations report that collaboration between project managers and business analysts is essential for project success, but only 46 percent believe the two groups collaborate…

  • Uncover gaps in your requirements using requirements risk management techniques member content open

    By Lee, Cheryl | Schibi, Ori According to a 2014 Project Management Institute Pulse of the Profession® report, inaccurate requirements gathering is the second most common reason for project failure, second only to changing…

  • Collaborating with stakeholders member content open

    By Haney, Victoria B. According to a variety of studies, 60 percent of software defects are linked directly to incorrect or incomplete requirements, with most project teams spending less than 8 percent of their time on…