How to Increase Your Odds of Project Success Through the RFP Process

The starting point of any change is, of course, renewing your outlook toward the process. My suggestion is that you view the RFP not only as a means for gathering information about the vendor's proposed solution, but also envision it as the perfect tool for collecting information to build into your contract. Remember that a contract is intended to mirror your actual agreement with the vendor on the details of your software purchase.

When the selected vendor provides its response to the RFP, you can send the response to your attorney (whether internal or external) with the specific request that he or she append it to the contract. The RFP, as part of the final, binding contract, will dramatically increase the odds that the vendor will live up to every one of the details covered in the RFP.

Your company probably has a standard RFP template that your project team will modify to address the technology project at hand. You can flesh out the RFP itself and increase the likelihood of project success by adding four additional items: 1) a User Requirements Document; 2) a Cost Matrix; 3) a Demonstration Script; and 4) a written collection of other details. Let me describe these items and explain how they can contribute to your project's success.

2. Know Thyself: Create a User Requirements Document.

The RFP process requires you to examine your needs and translate them into specific requirements. The universal law of attraction says that you need to know what you want in order to get it. This being the case, your firm must identify all of the features it wants in a new system.

Of course, defining the needs of multiple users and departments in-volves work. Because a new system usually has to satisfy the requirements of more than one department and may also need to integrate with existing systems, your team cannot make assumptions about the functions of the software. It is crucial that your project team conduct interviews with end users in order to determine the information that they want to manage, search and report, as well as any work-flows or other functions that the system must support. This process will also involve a review of existing systems, reports and spreadsheets to make sure that data elements are not lost.

Each of the end users' 'wish list' items should be documented, item by painful item, in spreadsheet form. While the work involved sounds arduous (and it is), the end result is a User Requirement Document that explicitly lists your specifications and removes any guessing (by either the vendor or your project team) as to what a system must be able to do. Another bit of good news is that you will be able to use this information later in the project when you are configuring your system, developing reports and implementing the system. While this approach is time consuming, it allows you to collect information in a way that anticipates your needs throughout your project's lifecycle.

The User Requirements Document really serves two functions: 1) identifying your internal needs; and 2) asking the vendor whether it can fulfill those needs. The document can be divided between mandatory and optional requirements, and spreadsheet fields should be added where the vendors will identify whether each line-item requirement is: a) standard; b) can be configured; c) can be supplied with a third-party integration; or d) requires product enhancement. A notes section is also useful in case the vendor wants to add additional detail or explanation of its responses.

Send the User Requirements Document to vendors as part of the RFP, and when the completed proposal comes back, you should clearly be able to see which of the requirements the vendor can satisfy. If the response or vendor comments are vague, don't be shy about sending the vendor an e-mail asking for clarification. Require the vendor to respond in writing and attach the response to the User Requirements Document.

Once the vendor is selected, that vendor's final response to the User Requirements Document can be forwarded to your attorney with the request that it be attached to the final contract. In this way, the contract will clearly identify each of the features the system includes and will specify whether they are standard, configurable, supplied through third-party integration or only accomplished through product enhancement. Since most post-implementation disputes arise out of vendor/purchaser disagreements over the features that are standard and non-standard, this approach could protect your company from unexpected customization costs.

3. Demand More: Impose a Script and Send Samples. By the time you are done developing the RFP, you will (understandably) be looking forward to demonstrations as the time to sit back, relax and enjoy the show. But the better approach is for the project team to keep vigilant, controlling the demonstration by creating a custom script to include with the outgoing RFP.

Think of the demonstration script as a list of user requirements with an allotted timeframe for the vendor to demonstrate how the product addresses each one. Since your project team has created a User Requirements Document, it will be a simple task to categorize the requirements by topic and list them in the form of a script. Depending on your project, your team should recognize that each of its top vendors would most likely require a full day to provide a comprehensive demonstration. Remind yourself that the technology has a life cycle of many years ' so the time required by the demonstrations is a good investment.

Your team should also send sample matters and descriptions of reports that it would like the vendor to demonstrate 'live' during the demonstration. Since you will have collected reports and materials during the interview process, it should be a straightforward task to select a few key items and include them with the outgoing RFP. While the following are common examples of demonstrated materials; your team would customize its samples depending on the technology it is evaluating.

Hot Topics for the Vendor Demonstration

• Reports: Send the vendor descriptions of a few reports it wants to see created during the demonstration.
• Features: Send the vendors description of the features that are most important to your team, and tell them to come prepared to show you the steps involved to accomplish any tasks from beginning to end.
• Integrations: Let the vendor know which integrations the vendor will be required to show (not tell) you during the demonstration.
• Configuration: The vendor should walk through the process for screen configuration so that the project team can evaluate the difficulty of customizing screens/ fields and the level to which customization extends.
• Workflow trigger: The vendor should demonstrate the system's ability to follow a business rule.

Ideally, demonstrations will eliminate any assumptions about what a system can or cannot do and will give your project team a clear understanding of the products' functionality and the level of difficulty or work-around required to accomplish various tasks. If you come away from the demonstration confused, ask the vendor to return and provide you with additional demonstrations or to clarify a function through a Web demonstration.

The project manager has several duties during the demonstration. He or she should: 1) keep the vendor on time and make sure that no scripted items are skipped; 2) confirm up front that the demonstration shows only a single, recently released version (future enhancements should generally not be considered); 3) verify which features are standard and which are configurable (and at what cost); and 4) make sure that if the vendor says the product can do something, he or she shows it to the team.

Another point to consider is that, during the demonstration, the vendor will explain and make promises about what its system can do. Since you will rely on these statements, you may consider making a voice recording of each demonstration. There are a few ways you can document your selected vendor's verbal statements. First, you could write a summary of any pertinent statements made during the demonstration. Second, you could update the User Requirements Document with the important details and send it to the vendor for vendor sign-off.

The documentation of promises or other pertinent vendor assertions should be forwarded to your attorney with the request that he or she append the document to the final contract. As you can imagine, capturing the vendor's demonstration statements will increase your leverage when it comes to enforcing the vendor's promises.

4. Price to Pay: Insist on a Fees Matrix. As discussed, a common area of dispute is the vendor's fee package, and specifically, the features that are not included in the vendor's quoted price. To head this off, the project team should never allow a vendor to present its fees in the vendor's own format. Interpreting a vendor's price list makes it difficult, if not impossible, for the project team to compare vendors. It can also contribute to contractual ambiguity.

Instead, I recommend that the project team create its own Fees Matrix as part of the outgoing RFP. When a company requires vendors to respond in uniform fashion, it can compare vendor costs side-by-side and obtain the level of detail it wants. More importantly, the Fees Matrix can help eliminate uncertainty about the services and features that are, and are not, included in the final cost of technology.

There are five basic categories of fees that your Fees Matrix might include. The Fees Matrix should be organized by category, with each type of fee listed as a line item for the vendor to complete. Additionally, the vendor should provide a detailed description of the functions or services related to each fee and/or should reference the functions specified in the User Requirements Document.

Categories of Software Fees

• Software Licensing Fees. These should be identified as server or enterprise licenses, with full or limited access, and in terms of whether they are one-time, annual, monthly, based on usage, etc.
• Fees for Interfaces, Features and Report Tools. Costs associated with all desired interfaces (i.e., Outlook, AP systems or third-party systems), optional features and report tools should be broken out separately, or if included in the software licensing fee, clearly specified.
• Implementation Fees. Thess should be detailed in terms of project planning and administration, installation, design, development, testing, data conversion, integrations, reports, documentation, post-implementation review and modifications.
• Training Fees. These should identify how many employees can be trained, how many days/hours of instruction will be provided and where training will occur.
• Maintenance Fees. Maintenance fees for each of the five years following implementation should be included.

If a vendor adjusts any fee during the RFP process, the project manager should require the vendor to send an updated written Fees Matrix in the same format as the original. Using this approach, you'll be able to clearly see the changes made by the vendor and will avoid the 'hide the ball' approach that some vendors take when providing reformatted fee quotes. Once the vendor has provided you with a final, comprehensive Fees Matrix that both you and the vendor have signed off on, you can forward a copy to your attorney. By appending the vendor's version of the final Fee Matrix to the software contract, you will minimize (but alas, not eliminate) the likelihood of fee disputes.

5. Details, Details, Details (Don't Let Them Slip through the Cracks). Most project managers will agree that one challenge of technology projects is finding a way to incorporate all of the vendor's promises and assurances into the final contract. By the time the software is selected, a myriad of communications between vendor and your team have been exchanged by e-mail, voice-mail, by phone, in-person and the like. Your team will rely on all of the vendor's statements. Unfortunately, you are only able to enforce the promises that are included in the final, binding contract.

In order to minimize the number of details that slip through the cracks, your team should agree on a process for pooling the fine points discussed with the vendor by e-mail or phone. It can be as simple as posting the information on a centralized project Web site or forwarding the details to the project manager by e-mail. The essential point is to educate your team about the importance of memorializing these discussions at the beginning of the project, and getting their buy-in on a single process for collecting them. At a minimum, you can include a recurring agenda item at project meetings to remind team members to recall recent vendor conversations and take action to forward any significant items to the pool. Your team may also choose to require vendors to restate any verbal discussion in e-mail format that is then sent to your project manager.

Treat as suspect any vendors that balk at restating their verbal promises in writing. Remember that if it isn't in writing, it isn't enforceable.

Conclusion

While the RFP process is time-consuming, there are things you can do to make the process more dynamic and ultimately, more rewarding. Try out some of these quick fixes and see whether they result in fewer headaches and greater return on your technology investment!

Are you among the majority of IT professionals who view the Request for Proposal ('RFP') as the most tedious business document ever created? The RFP itself is fairly standardized, but the process of collecting information and evaluating vendors is time-consuming and uninspiring. At the end of the day, you are left to wonder whether your colossal investment of time will pay off, and whether the vendor you selected is really going to deliver on its promises.

Perhaps you are looking for ways to streamline the process and get more out of it. While there are any number of thick manuals that describe the best practices for an RFP process, this article may shed light on some 'quick wins' that will enable you to boost the efficiency of your RFP process.

1. Free Your Mind and the Rest Will Follow: Understanding the True Nature of the RFP.

The starting point of any change is, of course, renewing your outlook toward the process. My suggestion is that you view the RFP not only as a means for gathering information about the vendor's proposed solution, but also envision it as the perfect tool for collecting information to build into your contract. Remember that a contract is intended to mirror your actual agreement with the vendor on the details of your software purchase.

When the selected vendor provides its response to the RFP, you can send the response to your attorney (whether internal or external) with the specific request that he or she append it to the contract. The RFP, as part of the final, binding contract, will dramatically increase the odds that the vendor will live up to every one of the details covered in the RFP.

Your company probably has a standard RFP template that your project team will modify to address the technology project at hand. You can flesh out the RFP itself and increase the likelihood of project success by adding four additional items: 1) a User Requirements Document; 2) a Cost Matrix; 3) a Demonstration Script; and 4) a written collection of other details. Let me describe these items and explain how they can contribute to your project's success.

2. Know Thyself: Create a User Requirements Document.

The RFP process requires you to examine your needs and translate them into specific requirements. The universal law of attraction says that you need to know what you want in order to get it. This being the case, your firm must identify all of the features it wants in a new system.

Of course, defining the needs of multiple users and departments in-volves work. Because a new system usually has to satisfy the requirements of more than one department and may also need to integrate with existing systems, your team cannot make assumptions about the functions of the software. It is crucial that your project team conduct interviews with end users in order to determine the information that they want to manage, search and report, as well as any work-flows or other functions that the system must support. This process will also involve a review of existing systems, reports and spreadsheets to make sure that data elements are not lost.

Each of the end users' 'wish list' items should be documented, item by painful item, in spreadsheet form. While the work involved sounds arduous (and it is), the end result is a User Requirement Document that explicitly lists your specifications and removes any guessing (by either the vendor or your project team) as to what a system must be able to do. Another bit of good news is that you will be able to use this information later in the project when you are configuring your system, developing reports and implementing the system. While this approach is time consuming, it allows you to collect information in a way that anticipates your needs throughout your project's lifecycle.

The User Requirements Document really serves two functions: 1) identifying your internal needs; and 2) asking the vendor whether it can fulfill those needs. The document can be divided between mandatory and optional requirements, and spreadsheet fields should be added where the vendors will identify whether each line-item requirement is: a) standard; b) can be configured; c) can be supplied with a third-party integration; or d) requires product enhancement. A notes section is also useful in case the vendor wants to add additional detail or explanation of its responses.

Send the User Requirements Document to vendors as part of the RFP, and when the completed proposal comes back, you should clearly be able to see which of the requirements the vendor can satisfy. If the response or vendor comments are vague, don't be shy about sending the vendor an e-mail asking for clarification. Require the vendor to respond in writing and attach the response to the User Requirements Document.

Once the vendor is selected, that vendor's final response to the User Requirements Document can be forwarded to your attorney with the request that it be attached to the final contract. In this way, the contract will clearly identify each of the features the system includes and will specify whether they are standard, configurable, supplied through third-party integration or only accomplished through product enhancement. Since most post-implementation disputes arise out of vendor/purchaser disagreements over the features that are standard and non-standard, this approach could protect your company from unexpected customization costs.

3. Demand More: Impose a Script and Send Samples. By the time you are done developing the RFP, you will (understandably) be looking forward to demonstrations as the time to sit back, relax and enjoy the show. But the better approach is for the project team to keep vigilant, controlling the demonstration by creating a custom script to include with the outgoing RFP.

Think of the demonstration script as a list of user requirements with an allotted timeframe for the vendor to demonstrate how the product addresses each one. Since your project team has created a User Requirements Document, it will be a simple task to categorize the requirements by topic and list them in the form of a script. Depending on your project, your team should recognize that each of its top vendors would most likely require a full day to provide a comprehensive demonstration. Remind yourself that the technology has a life cycle of many years ' so the time required by the demonstrations is a good investment.

Your team should also send sample matters and descriptions of reports that it would like the vendor to demonstrate 'live' during the demonstration. Since you will have collected reports and materials during the interview process, it should be a straightforward task to select a few key items and include them with the outgoing RFP. While the following are common examples of demonstrated materials; your team would customize its samples depending on the technology it is evaluating.

Hot Topics for the Vendor Demonstration

• Reports: Send the vendor descriptions of a few reports it wants to see created during the demonstration.
• Features: Send the vendors description of the features that are most important to your team, and tell them to come prepared to show you the steps involved to accomplish any tasks from beginning to end.
• Integrations: Let the vendor know which integrations the vendor will be required to show (not tell) you during the demonstration.
• Configuration: The vendor should walk through the process for screen configuration so that the project team can evaluate the difficulty of customizing screens/ fields and the level to which customization extends.
• Workflow trigger: The vendor should demonstrate the system's ability to follow a business rule.

Ideally, demonstrations will eliminate any assumptions about what a system can or cannot do and will give your project team a clear understanding of the products' functionality and the level of difficulty or work-around required to accomplish various tasks. If you come away from the demonstration confused, ask the vendor to return and provide you with additional demonstrations or to clarify a function through a Web demonstration.

The project manager has several duties during the demonstration. He or she should: 1) keep the vendor on time and make sure that no scripted items are skipped; 2) confirm up front that the demonstration shows only a single, recently released version (future enhancements should generally not be considered); 3) verify which features are standard and which are configurable (and at what cost); and 4) make sure that if the vendor says the product can do something, he or she shows it to the team.

Another point to consider is that, during the demonstration, the vendor will explain and make promises about what its system can do. Since you will rely on these statements, you may consider making a voice recording of each demonstration. There are a few ways you can document your selected vendor's verbal statements. First, you could write a summary of any pertinent statements made during the demonstration. Second, you could update the User Requirements Document with the important details and send it to the vendor for vendor sign-off.

The documentation of promises or other pertinent vendor assertions should be forwarded to your attorney with the request that he or she append the document to the final contract. As you can imagine, capturing the vendor's demonstration statements will increase your leverage when it comes to enforcing the vendor's promises.

4. Price to Pay: Insist on a Fees Matrix. As discussed, a common area of dispute is the vendor's fee package, and specifically, the features that are not included in the vendor's quoted price. To head this off, the project team should never allow a vendor to present its fees in the vendor's own format. Interpreting a vendor's price list makes it difficult, if not impossible, for the project team to compare vendors. It can also contribute to contractual ambiguity.

Instead, I recommend that the project team create its own Fees Matrix as part of the outgoing RFP. When a company requires vendors to respond in uniform fashion, it can compare vendor costs side-by-side and obtain the level of detail it wants. More importantly, the Fees Matrix can help eliminate uncertainty about the services and features that are, and are not, included in the final cost of technology.

There are five basic categories of fees that your Fees Matrix might include. The Fees Matrix should be organized by category, with each type of fee listed as a line item for the vendor to complete. Additionally, the vendor should provide a detailed description of the functions or services related to each fee and/or should reference the functions specified in the User Requirements Document.

Categories of Software Fees

• Software Licensing Fees. These should be identified as server or enterprise licenses, with full or limited access, and in terms of whether they are one-time, annual, monthly, based on usage, etc.
• Fees for Interfaces, Features and Report Tools. Costs associated with all desired interfaces (i.e., Outlook, AP systems or third-party systems), optional features and report tools should be broken out separately, or if included in the software licensing fee, clearly specified.
• Implementation Fees. Thess should be detailed in terms of project planning and administration, installation, design, development, testing, data conversion, integrations, reports, documentation, post-implementation review and modifications.
• Training Fees. These should identify how many employees can be trained, how many days/hours of instruction will be provided and where training will occur.
• Maintenance Fees. Maintenance fees for each of the five years following implementation should be included.

If a vendor adjusts any fee during the RFP process, the project manager should require the vendor to send an updated written Fees Matrix in the same format as the original. Using this approach, you'll be able to clearly see the changes made by the vendor and will avoid the 'hide the ball' approach that some vendors take when providing reformatted fee quotes. Once the vendor has provided you with a final, comprehensive Fees Matrix that both you and the vendor have signed off on, you can forward a copy to your attorney. By appending the vendor's version of the final Fee Matrix to the software contract, you will minimize (but alas, not eliminate) the likelihood of fee disputes.

5. Details, Details, Details (Don't Let Them Slip through the Cracks). Most project managers will agree that one challenge of technology projects is finding a way to incorporate all of the vendor's promises and assurances into the final contract. By the time the software is selected, a myriad of communications between vendor and your team have been exchanged by e-mail, voice-mail, by phone, in-person and the like. Your team will rely on all of the vendor's statements. Unfortunately, you are only able to enforce the promises that are included in the final, binding contract.

In order to minimize the number of details that slip through the cracks, your team should agree on a process for pooling the fine points discussed with the vendor by e-mail or phone. It can be as simple as posting the information on a centralized project Web site or forwarding the details to the project manager by e-mail. The essential point is to educate your team about the importance of memorializing these discussions at the beginning of the project, and getting their buy-in on a single process for collecting them. At a minimum, you can include a recurring agenda item at project meetings to remind team members to recall recent vendor conversations and take action to forward any significant items to the pool. Your team may also choose to require vendors to restate any verbal discussion in e-mail format that is then sent to your project manager.

Treat as suspect any vendors that balk at restating their verbal promises in writing. Remember that if it isn't in writing, it isn't enforceable.

Conclusion

While the RFP process is time-consuming, there are things you can do to make the process more dynamic and ultimately, more rewarding. Try out some of these quick fixes and see whether they result in fewer headaches and greater return on your technology investment!