Project managing the RFP process for software acquisition, a structured approach

Introduction

The cost of developing large-scale financial systems has increased dramatically over the years. For example, to build a trust accounting system from the beginning, integrate it into an organization's data center, make the requisite network upgrades to support it, prepare the business operation to use it, and develop a customer-facing web-based interface would cost tens of millions of dollars and take years. Many organizations have become reticent to develop large software applications because the degree of difficulty in delivering an end product that meets the users needs is high, and schedule and cost overruns are probable. Many corporations are therefore opting to purchase and license vendor software. Doing so has it own challenges related to the integration of the software application, but organizations can get the system implemented in a much shorter time than developing a new application. First and foremost in the vendor software selection process is to ensure that the chosen system will meet the organization's needs. Applying a structured approach to the Request for Proposal (RFP) process can lead to better decisions for purchasing and implementing large-scale vendor software applications.

Often software solicitation projects start with too limited a focus. A manager within your organization might call you in and say that she heard that “ABC software company has a great software package for processing commercial loans and isn't it about time that the company retire the antiquated loan system that we've been struggling with for the last 10 years. Give the vendor a call, find out how much it costs, and have them come make a presentation.” A software solicitation project is like any other project, if it starts with unstated objectives and unclear sponsorship, it is doomed to be challenged or fail. Like any good structured project, this type of project should start with the same planning discipline as any other, including the clear definition of sponsorship, objectives, and mission.

Solicitation—Initiation and Planning

Getting Started

A Project Charter and Scope Statement should be produced and it should outline not only the functional scope of the proposed system, but it should also detail the mission of the procurement team, including when it has finished its job. A Project Charter for a soft-ware solicitation project should include at a minimum the following information: introduction, project description and justification, including business drivers, constraints, proposal stakeholders, deliverables, project objectives for time and scope, proposal resources and roles, assumptions, dependencies, and issues. As with initiating and planning any project, the Project Charter should be reviewed with the key stakeholders and once approved, the project team should be assembled. Selecting the project team members should take into consideration your organizational structure, but should include the project manager, a business sponsor representative, business subject matter experts, technical analysts, and parttime internal consultants from the technical infrastructure group, i.e., the data center and network services. The number of staff required will be a function of the size of the application system and the number of key interfaces which dictates which individuals should be involved. For the rest of this paper, I will refer to this group as the RFP Project Team.

Another key element of the initiation and planning phase is the development of a communication plan. Once you have given the procurement effort visibility to the key stakeholders through the Project Charter and Scope Statement, they are going to want to hear some level of status reporting throughout the procurement process. Early discussions with the stakeholders must elicit from them what they want to hear about the project, how frequently, and by what method. Once the RFP Project Team has gathered this information, it must design a communication strategy and plan the keeps the project sponsor and key stakeholders adequately informed.

Based on the functional objectives of the proposed software as articulated in the Project Charter and Scope Statement, the next task of the RFP Project Team is to gather information about the available vendor software. This information is available from a variety of sources: trade journals, focused periodicals, business conferences, and most importantly business contacts. Researching print journals often only provides limited results, however, calling your contacts at other organizations can yield useful information about proven vendor products implemented at other institutions. In recent years, the Internet has become an additional resource when searching for vendors and vendor software applications. My experience has found that is necessary to be creative with your searches and to use multiple search engines in order to find applicable available software.

Potential challenges with the search process are that you may encounter dozens of software applications that appear to meet your business needs, and it can be difficult to assess the information that is available through advertisements, vendor promotional materials, and the Internet. It is critical to the success of the project to focus the research and restrict the analysis to the best, viable options. Sending the RFP to 10 vendors can result in analysis overload as you move into the evaluation phase of the project. To make the best use of the project team's future time, it is appropriate for your business subject matter experts to contact the vendors that provide solutions for which you might be uncertain, screen the vendors to determine whether the software is a potential fit with your organization, and to eliminate the options that are least viable. You will yield the best evaluation results if you limit your solicitation to no more than five vendors.

Designing the RFP

The next step in the solicitation planning phase is to THINK. As much as the request for proposal process is the vendor's chance to demonstrate its software, it is also your organization's opportunity to find out as much about the vendor and its software. Given that, it is important to understand what information you require in order to build your business case. This should not be restricted to application software functionality. Not to diminish its importance, but it is but one component of the evaluation. It is also critical to determine the size and scope of the implementation project as well as the intangibles that will contribute to the decision-making process. In what languages and versions is the software written? Do your corporate technical standards support them? Will you need to get internal waivers to implement non-standard software? What “standard” interfaces does the system provide? To what extent will they need to be modified to meet your requirements? What reporting does the system provide? To what extent will it need to be modified to meet your requirements? On what hardware does the application run? Does it meet your corporate technical standards? What are the vendor's capabilities for supporting the system? Do they provide support that matches your business hours? How small or large is the vendor? Are they publicly or privately held? Your organization is going to have a minimum set of standards to which the vendor must measure up. Determine them because the RFP process and your procurement documents must elicit that information.

Now that you have thought about the information that you need, it is time to design your procurement documents. Depending on the level of detail to which the business requirements are articulated within, you may be producing a Request for Information (RFI) or a Request for Proposal (RFP). According to the Wideman Glossary of Project Management Terms, an RFI is a formal inquiry in the market place for information, typically concerning “Expressions of Interest,” capacity, capability and availability of contractors to undertake and bid on work described in the solicitation (Wideman, 1998-01). According to earlier versions of the PMBOK® Guide, an RFP is a formal invitation containing a scope of work that seeks a formal response (proposal) describing both methodology and compensation to form the basis of a contract (PMBOK® Guide, 1987). What this means in practice is that an RFP tends to include more detailed and comprehensive information, in other words, it is a more rigorous document. In other industries such as con-struction, an RFP is designed to be comprehensive and specific such that vendors are expected to be able to provide build designs and costs for the finished product. Within financial services companies, RFPs tend to be somewhat less detailed. These and other procurement document terms such as Request for Quotation and Invitation for Bid are often used interchangeably (PMBOK® Guide, 2000, 153). For the sake of this paper, I will refer to the document as an RFP.

Like any research project it is critical to design your RFP properly. Researchers spend much time designing their data gathering such that the data will prove or disprove their study's hypothesis. The same care should be taken when developing the questions for the vendors, such that the response to the individual questions will elicit the information that you need. In addition to thinking about what data you need, it is also important to think through how useful the data will be when it comes to evaluating the vendors. Ideally, you will want data that can be contrasted, compared, and measured against each other to see which vendor solution best meets your needs. As noted in the PMBOK® Guide, procurement documents should be rigorous enough to ensure consistent, comparable responses, but flexible enough to allow considerations of seller (vendor) suggestions for better ways to satisfy the requirements (PMBOK® Guide, 2000,153).

One additional capability of the RFP process is that it can be used to determine whether a vendor solution is a better choice than other internal solutions. Often referred to as a “build or make versus buy” effort, the procurement documents can be distributed to an internal group that is treated as an additional vendor in the selection process. The internal group's response is somewhat different than that of the vendors insofar as the internal group needs to estimate building the application or enhancing an existing application. To the extent possible, the internal group should not be given deference over the external options, and it is up to the project sponsor as to whether the internal option is disclosed to the other vendors. The downside of disclosure in this situation is that the vendors may not put their best effort into their response thinking that your organization is pre-disposed to choosing the internal option.

Now that you have planned your strategy, identified viable vendor candidates, and designed your information needs, it is time to move the execution phase. It is here that you will build the RFP, distribute it, receive the proposals, and evaluate them.

Evaluation—Execution and Control

Building the RFP

As your RFP process moves from the “planning” into the “execution” phase, your first task is to build the RFP. There are numerous ways to build one, and your organization most likely has some standard language for inclusion in such solicitation documents. Contact your legal or contract administration department for this information and integrate it into the first section of your RFP. Most likely this will contain instructions to bidders, bid description, bid terms and conditions, and confidentiality language. You may also want to integrate into this section your specific requests for vendor company information such as size, location, public or private, and if this information is important for your evaluation criteria, the vendor's financials as documented in their annual report.

Exhibit 1. Phrasing the RFP Requirements Statements

Phrasing the RFP Requirements Statements

The next section of the RFP will be your solicitation requirements. This is where you will document your application system requirements, hardware, software, and infrastructure requirements, and vendor support requirements. The more detailed the requirements, the better the vendors can respond to your requirements in their proposal. I have seen effective RFPs with as few as seven pages and as many as 100 pages of requirements. The requirements can be specific or open-ended. Specific questions tend to elicit the vendor information in a manner that can be compared, while the open-ended questions provide flexibility for the vendor to add information that they feel is relevant to their bid that may not have been specified elsewhere.

Typically, you will want to segregate your requirements by functional area of system processing. For example, in a trade finance system one might structure the sections as follows: Bank setup, Account setup, Applicant setup, Letters of Credit, Banker's Acceptances, Collections, Reimbursements, and System Considerations including hardware, software, redundancy, security, support, and system releases. The sections you define would be based on your needs for the system. A tip for eliciting unambiguous information from the vendor is to phrase your requirement in such a way that the vendor is limited to a Yes, No, or Partial answer, as illustrated in Exhibit 1.

By soliciting the requirements in this manner, you will set the stage for evaluating those requirements as described in the next section of this paper. In addition to the specific information for system processing, there is other information that you need to request. This includes information related to client references, software licensing options and costs, and project costs. The more specific your information request, the better the information provided will be. When asking for client references, ask for ones that are using the system in a similar fashion to how you will use it. When asking for project costs, ask the vendor to describe how they would structure the implementation project and find out the resource categories, costs and staffing levels that they would assign to the various deliverables.

Once you have completed the RFP, distribute it to the three to five vendors to whom you have narrowed your search. Depending on the level of detail contained within your requirements, give the vendors two to three weeks in which to return their proposals. You can keep the bid process confidential, or you can alert the vendors to their competitors. Depending on your timetable, give the vendors a few days in which to ask questions regarding the RFP. Questions can be asked by assembling a bidders conference attended by all of the vendors or the vendors can submit them individually. If the questions are submitted individually, at a predetermined time at least one week before the proposals are due, collate all of the questions, develop your responses, and distribute them to all of the vendors without identifying which vendors asked which questions. It is important to the bid process that all vendors have access to the same information.

The Proposal Evaluation Process

In order to evaluate the vendor proposals, you will need to build some evaluation tools. While the vendors are developing their proposals, the RFP Project Team can be developing the evaluation tools. According to the PMBOK® Guide, there are several tools and techniques for evaluating the proposal such as weighting and screening (PMBOK® Guide, 2000, 156). An example of a weighting tool is a requirements evaluation matrix that can be used to assess how well the vendor software meets your requirements. It is a spreadsheet that is built from the list of your requirements. The business representatives on the RFP Project Team review each requirement and determine whether it is a “must have,” a “want to have,” or a “nice to have.” A “must have” is a function that is required for the business to do its work. If it is not a feature of the system, it would have to be built. A “want to have” is a function that is important to the business, but they could live without it or with a work around. A “nice to have” is a function that would provide benefit to the business, but is not essential for business operations. A weighted value would then be given to each requirement category, for example, a 5 for a “must have,” a 3 for a “want to have,” and a 1 for a “nice to have.” When the vendor proposals are received, they are given a score for whether they fully meet, partially meet, or did not meet a given requirement. For example, a 4 for a YES, and 2 for PARTIAL, and a 0 for NO. This way a score for each requirement can be calculated. In addition, a benchmark total score can be calculated, i.e., the value for meeting every requirement. The vendor's total score can be evaluated against the benchmark score to determine a percentage of how closely their system meets your functional requirements. The same benchmark and calculations can be made specifically for the “must have” requirements that provides an added level of analysis. Refer to Exhibit 2 for an example. Build one spreadsheet for each vendor.

Exhibit 2. Requirements Evaluation Matrix

Requirements Evaluation Matrix

Other evaluation tools are sizing templates to determine project development costs and hardware, software, and network costs. This information can be captured in a benefit cost analysis spreadsheet, which documents the project development cost estimates, and recurring benefits and costs over a three to five year period. For detailed information on building a benefit cost spreadsheet, refer to Why are the Wrong Technology Projects Getting Started, Who is Asking the Tough Questions (Arnstein, 2001) in the PMI 2001 Proceedings. Build one sizing template and benefit cost analysis spreadsheet for each vendor.

Ultimately, the evaluation phase of the RFP process must determine the best proposal as it relates to functionality, cost, whether the system can be integrated into the technical environment, the vendor's reliability, and the vendor's ability to manage the system integration process and provide ongoing support. Your evaluation tools address most of the functionality, cost, and system integration aspects. Once you have received the vendor proposals, enter their requirements’ scores into the evaluation matrix. Take their answers to the other questions and start building estimates for project vendor services costs, internal project staffing costs, hardware and software costs, software license depreciation costs, and recurring license and maintenance costs. This preliminary evaluation should give an indication as to whether the vendor solution is viable for your organization. For the solutions that are viable, continue to the next step. For the others, suspend the evaluation and focus your efforts on the viable solutions.

Determining the vendors’ reliability is accomplished through vendor presentations, system demonstrations, and client reference calls. These are examples of the screening techniques mentioned earlier. Schedule a block of time for each vendor to present themselves and their system. My experience has demonstrated that you will need a minimum of three to four hours for each vendor to make a comprehensive presentation. For the vendors that are still being considered after the presentation, you will want to call at least two to three of their client references. In addition, you may want to conduct a site visit to one of the clients to further evaluate the system as it is actually used. In either the client reference calls or site visits, your objective is to determine the reliability and quality of vendor business and technical support. It can be helpful to prepare a list of questions that elicit this information prior to the calls. These calls can be invaluable in evaluating overall vendor performance, and most client references are surprisingly candid when discussing the system and vendor performance.

By this time, you have successfully distributed your RFP, received your proposals, conducted a preliminary evaluation, met with the vendor and vendor's client references, and have generated a significant amount of data to review and digest. As you progressed through the execution phase, you will have continually been gathering and refining the evaluation information. It is now time to finalize the evaluation and make your recommendation.

Recommendation and Selection—Close

As the evaluation exercise comes to a close, finalize the project estimates and benefit cost analysis spreadsheets. These capture all of the tangible components of the evaluation. An important additional task is to document the intangible components such as vendor reputation, adequacy of vendor support, and system ease-of-use. These intangibles can often sway the decision if the system implementation costs are relatively close for each vendor. Summarize and consolidate the findings into a presentation for the project sponsor and key stakeholders. The level of detail that you present will be based on the needs your audience. At a minimum, you will want to set the context for your request for proposal, the vendors and vendor systems that were evaluated, the highlights, costs, and intangibles of each option. In addition, a one- or two-page summary of the comparative project costs, recurring benefits, and recurring costs for each of the vendor options is an effective way to present the financial information side by side. Refer to Exhibit 3 for an example.

Exhibit 3. Vendor Comparison Summary

Vendor Comparison Summary

Exhibit 4. Vendor Overall Comparison Summary

Vendor Overall Comparison Summary

Rarely does one of the solutions that you evaluated meet all of your requirements and often there is no clear “winner”. There will be tradeoffs between the vendor proposals based on the delivered functionality and the intangibles that will affect system integration and ongoing support of the system. Cost may not be the only factor that affects the decision, and that makes it important to present as much of the information that you gathered to allow management to make an informed decision. Therefore you may also want to present an overall vendor comparison summary that includes the non-cost components of the evaluation. Refer to Exhibit 4 for an example.

At the end of the evaluation, notify the vendors of your decision. Review your Project Charter and Scope Statement to determine your next steps. What did you define as the objective of your RFP exercise? Was it the solely the selection of a vendor, or was completion of a contract in scope for the RFP exercise? Regardless, you are a short way from completing your system procurement process, time for project closeout. Given that this exercise leads to contract administration, it is important to keep the project documentation for two purposes. First, if disputes arise between you and the vendor, you will have supporting documentation to resolve the conflict, and second, your organizational policies may dictate that RFP documents are to be kept for some period of time as part of the procurement process historical repository.

After contract negotiations the system integration project starts in earnest. As the mission and objectives of the implementation project are quite different than those of the vendor selection process, it is necessary to begin project planning activities anew, starting with the appropriate levels of project planning.

Wrap Up

A well-managed RFP process will look a lot like a standard project; initiate, plan, execute, control, and close. The structured approach described in this paper will ensure that you get your software acquisition project started in an orderly manner. You will have compared your options objectively, and determined which of the vendor proposals is most appropriate for your organization.

References

Arnstein, Douglas M. 2001. Why are the Wrong Technology Projects Getting Started? Who is Asking the Tough Questions? PMI 2001 Proceedings. Newtown Square, PA: Project Management Institute.

Project Management Institute Standards Committee. 2000. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Newtown Square, PA: Project Management Institute.

Project Management Institute Standards Committee. 1987. A Guide to the Project Management Body of Knowledge (PMBOK®). Upper Darby, PA: Project Management Institute.

Wideman, R. M. 1998-01. Glossary of Project Management Terms. Composite additions from various sources.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA

Advertisement

Advertisement

Related Content

Advertisement