Be a Software Contract Hero

Picture this scenario: Six months after your company signs a contract for new technology, the project manager comes to your office for advice. Apparently, the project team thinks that Function X is part of the standard software, but the vendor insists that Function X requires customization and has provided a pricey quote. The project manager asks you to look at the contract (which, by the way, you originally reviewed) and tell her what it says. Crossing your fingers, you pull out the contract and quickly realize that the contract doesn't address Function X and worse yet, indicates that the vendor may be right!

I have to admit that this scenario is all too familiar. As in-house counsel, I was often asked to review contracts after a five-minute description from the project manager. When lucky, I was included as part of the project team that made the selection. In both situations, I found myself wondering whether I had done enough to address all of the vital elements in my contract review.

What I really needed was a practical plan that spelled out the “best-practices” RFP process. A plan that would help me understand what information the project team should be collecting, and which of those materials I needed for contract review. This article provides a strategy that will allow you to be the law department hero. You can draft software contracts with confidence, incorporate all needed references (including Function X) and save the day!

For the sake of example, this plan is described in the context of law department systems such as matter management, eBilling and eDiscovery. However, these principles can be easily applied to other types of software contracts.

The Request for Proposal

If companies really understood the nature of the Request for Proposal (“RFP”), they would call them Requests for Partnership because they are the starting point for what is intended to become a long-term relationship between company and vendor. At the same time, if in-house counsel really understood the nature of the RFP process (unfortunately, no such class is taught in law school), they would insist on having more involvement in the RFP process. Because from the attorney's perspective, the RFP is a tool for collecting the information that becomes the heart and soul of the final contract and serves as a basis for the vendor's liability.

Your company probably has a standard RFP template that the project team can modify to address the technology project. For contract purposes, you should make sure that the RFP includes three elements: 1) a User Requirements Document; 2) a Cost Matrix; and 3) a Demonstration Script. In addition to making sure these items are part of the RFP, as in-house counsel you will do well to understand the purpose and scope of these items. This article provides you with that information.

Once the project team receives the vendor's response to the RFP (and the three items above), they will likely have additional questions. Let the project manager know that follow-up questions should be sent to the vendor in writing, with the requirement that the vendor respond in writing as well. These items should be collected for contract review:

• The original RFP;
• The vendor's proposal submitted in response to the RFP; and
• The vendor's written responses to follow-up questions.

The User Requirements Document

As part of the RFP process (but before the RFP is drafted), the project team should identify its user requirements. If the universal law of attraction says that you need to know what you want in order to get it, then your organization must identify the features it wants in a new system if it hopes to acquire them.

Of course, defining the needs of multiple users and departments requires work. For example, matter management software must satisfy the requirements of entire Legal Department, plus members of Tax, Technology and Management. With eBilling software, the needs of Accounts Payable and law firm counsel must be taken into account as well.

No assumptions can be made about what needs the software must fulfill. Instead, the project team should conduct interviews with end-users from each practice area about the information that they want to manage, search and report. This process will also involve a review of existing systems, reports and spreadsheets.

Each of the end-user's “wish list” items should be compiled into a single spreadsheet (the User Requirements Document). As many discover, the interview and documentation processes require a significant amount of time. But the end result is a list of specifications that are explicit enough to remove any guessing about what a system must to do to meet the needs of end-users.

Once the User Requirements Document is complete, the project team will add fields for the vendors to identify whether each function is: 1) standard; 2) can be configured; 3) can be supplied with a third-party integration; or 4) requires product enhancement.

The User Requirements Document is sent to vendors with the RFP, and, as in-house counsel, you will later append the vendor's response to the final contract. If you do this, the contract will clearly identify whether which features (including Function X) are included in the standard software package. Thus, counsel should obtain the following from the project team: The vendor's response to the User Requirements Document.

The Scripted Vendor Demonstration

Most project teams (understandably) look forward to demonstrations as the time to sit back, relax and enjoy the show. But the best-practices approach is for the project team to actively participate in the process. By this, I mean that the team should keep control of the demonstration by creating a custom script, sending it with the RFP, and monitoring vendors to make sure that they follow it. This approach prevents the project team from being swayed by any particularly charismatic vendors and keeps the focus on the system's ability to meet the core requirements.

The custom demonstration script is really just a list of system features with an allotted demonstration timeframe for each. Since the project team has already crafted the User Requirements Document, it is a simple task to put the requirement in list form for the script.

In addition to the script, the project team should prepare and send sample matters to the vendor. Again, the project team will have collected reports and other materials during the interview process and can include some of these with the RFP. The vendor must come prepared to create and demonstrate these items “live.” The following are examples of materials the project team would send to a matter management vendor; your team would customize its samples depending on the technology is is evaluating.

Hot Topics for the Vendor Demonstration

Reports: Send the vendor descriptions of a few reports to be created during the demonstration.

Invoices: If eBilling is being considered, the vendor should demonstrate the import of an invoice, the billing validations and error notices generated, and the approval workflow.

Contracts: Send the vendor a sample of contracts, parent contracts and amendments that should be entered and cross-referenced in the system.

Integrations: The vendor should show how integrations (timekeeping, file room, document management, calendar, email, etc.) work with the software.

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.

Demonstrations should eliminate any assumptions about what a system can or cannot do. Afterwards, the project team will have a good idea of the products' functionality and the level of difficulty or work-around required to accomplish various tasks.

It's important to note that 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 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.

During the demonstration, the vendor will explain features and make assurances ' and you must find a way to capture these details in the final contract. You may suggest that the project manager create a voice recording of each demonstration and write a summary of the selected vendor's statements. Alternatively, you may decide to ask for the recording when you begin contract review (keep in mind that these are usually full-day demonstrations). In-house counsel should obtain the following for contract review: The written summary of the vendor's demonstration statements or a recording of the demonstration.

The Fees Matrix

Another area of frequent dispute is vendor's fee structure. The project team should never allow a vendor to present its fees in the vendor's own format. Interpreting a vendor's standard price list makes it difficult, if not impossible, for the project team to compare vendors and can contribute to contractual ambiguity. Instead, the project team should create its own Fees Matrix as part of the outgoing RFP. When the 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 should 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.

Categories of Software Fees

Software licensing fees. Fees should be identified as server or enterprise licenses, with full or limited access, and in terms of whether they are one-time, annual, monthly or based on usage.

Fees for interfaces, features and report tools. Costs associated with all desired interfaces (i.e., Outlook, AP systems or third party systems), optional features (i.e., document assembly, business rules) and report tools.

Implementation fees. The vendor should itemize fees associated with project planning and administration, design, development, testing, conversions, integrations, reports, documentation, post-implementation review and modifications.

Training fees. Fees 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.

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-house counsel can append this item directly to the software contract: The vendor's (but not the project manager's) final version of the Fees Matrix.

Details from Other Sources

Most in-house counsel will agree that a challenging area of contract review is finding a way to collect and incorporate any promises made by the vendor via e-mail, phone, voice mail and the like. By the time the software is selected, myriad communications between vendor and company have been exchanged, but few of them are documented. Of course, the project team will rely on the vendor's statements as being part of the agreement. Knowing, as you do, that the company will only be able to enforce the promises that are included in the contract, what can you do to rise above this challenge?

In all honesty, I wish I had the answer! The best solution I can offer is to encourage the project team, at the outset of the project, to agree on a process for collecting the details discussed with vendors by e-mail, phone and the like. It could be as simple as posting the information on a centralized project web site or forwarding the details to the project manager by email. You may ask the project manager to include a recurring agenda item at each project meeting to remind team members to forward any significant details arising from recent conversations.

Before starting contract review, in-house counsel can review these collected communications with the project manager and pick out the items to include in the contract. Counsel should incorporate the following as part of the contract review process: The collection of vendor promises and assurances communicated by e-mail, phone and similar means.

Conclusion

The path to effective contract review can be straightforward. Work with your project managers to create a best practices RFP process, and recognize the right materials to gather as you review software contracts. Go forth and be a contract hero.

RFP MATERIALS FOR SOFTWARE CONTRACT REVIEW

The RFP and the vendor's response

The vendor's written responses to follow-up questions

The vendor's response to the User Requirements Document

The written summary of the vendor's demonstration statements or the original recording

The vendor's final version of the Fees Matrix

Any vendor promises communicated by e-mail, phone and other means.

Nanci Tucker is Corporate Counsel and Sr. Consultant with Simpson Neely Group, Inc. If you would like a sample version of the User Requirements Document, Demonstration Script or Fee Matrix described in this article, please contact Ms. Tucker at 720-201-8550 or [email protected].

Picture this scenario: Six months after your company signs a contract for new technology, the project manager comes to your office for advice. Apparently, the project team thinks that Function X is part of the standard software, but the vendor insists that Function X requires customization and has provided a pricey quote. The project manager asks you to look at the contract (which, by the way, you originally reviewed) and tell her what it says. Crossing your fingers, you pull out the contract and quickly realize that the contract doesn't address Function X and worse yet, indicates that the vendor may be right!

I have to admit that this scenario is all too familiar. As in-house counsel, I was often asked to review contracts after a five-minute description from the project manager. When lucky, I was included as part of the project team that made the selection. In both situations, I found myself wondering whether I had done enough to address all of the vital elements in my contract review.

What I really needed was a practical plan that spelled out the “best-practices” RFP process. A plan that would help me understand what information the project team should be collecting, and which of those materials I needed for contract review. This article provides a strategy that will allow you to be the law department hero. You can draft software contracts with confidence, incorporate all needed references (including Function X) and save the day!

For the sake of example, this plan is described in the context of law department systems such as matter management, eBilling and eDiscovery. However, these principles can be easily applied to other types of software contracts.

The Request for Proposal

If companies really understood the nature of the Request for Proposal (“RFP”), they would call them Requests for Partnership because they are the starting point for what is intended to become a long-term relationship between company and vendor. At the same time, if in-house counsel really understood the nature of the RFP process (unfortunately, no such class is taught in law school), they would insist on having more involvement in the RFP process. Because from the attorney's perspective, the RFP is a tool for collecting the information that becomes the heart and soul of the final contract and serves as a basis for the vendor's liability.

Your company probably has a standard RFP template that the project team can modify to address the technology project. For contract purposes, you should make sure that the RFP includes three elements: 1) a User Requirements Document; 2) a Cost Matrix; and 3) a Demonstration Script. In addition to making sure these items are part of the RFP, as in-house counsel you will do well to understand the purpose and scope of these items. This article provides you with that information.

Once the project team receives the vendor's response to the RFP (and the three items above), they will likely have additional questions. Let the project manager know that follow-up questions should be sent to the vendor in writing, with the requirement that the vendor respond in writing as well. These items should be collected for contract review:

• The original RFP;
• The vendor's proposal submitted in response to the RFP; and
• The vendor's written responses to follow-up questions.

The User Requirements Document

As part of the RFP process (but before the RFP is drafted), the project team should identify its user requirements. If the universal law of attraction says that you need to know what you want in order to get it, then your organization must identify the features it wants in a new system if it hopes to acquire them.

Of course, defining the needs of multiple users and departments requires work. For example, matter management software must satisfy the requirements of entire Legal Department, plus members of Tax, Technology and Management. With eBilling software, the needs of Accounts Payable and law firm counsel must be taken into account as well.

No assumptions can be made about what needs the software must fulfill. Instead, the project team should conduct interviews with end-users from each practice area about the information that they want to manage, search and report. This process will also involve a review of existing systems, reports and spreadsheets.

Each of the end-user's “wish list” items should be compiled into a single spreadsheet (the User Requirements Document). As many discover, the interview and documentation processes require a significant amount of time. But the end result is a list of specifications that are explicit enough to remove any guessing about what a system must to do to meet the needs of end-users.

Once the User Requirements Document is complete, the project team will add fields for the vendors to identify whether each function is: 1) standard; 2) can be configured; 3) can be supplied with a third-party integration; or 4) requires product enhancement.

The User Requirements Document is sent to vendors with the RFP, and, as in-house counsel, you will later append the vendor's response to the final contract. If you do this, the contract will clearly identify whether which features (including Function X) are included in the standard software package. Thus, counsel should obtain the following from the project team: The vendor's response to the User Requirements Document.

The Scripted Vendor Demonstration

Most project teams (understandably) look forward to demonstrations as the time to sit back, relax and enjoy the show. But the best-practices approach is for the project team to actively participate in the process. By this, I mean that the team should keep control of the demonstration by creating a custom script, sending it with the RFP, and monitoring vendors to make sure that they follow it. This approach prevents the project team from being swayed by any particularly charismatic vendors and keeps the focus on the system's ability to meet the core requirements.

The custom demonstration script is really just a list of system features with an allotted demonstration timeframe for each. Since the project team has already crafted the User Requirements Document, it is a simple task to put the requirement in list form for the script.

In addition to the script, the project team should prepare and send sample matters to the vendor. Again, the project team will have collected reports and other materials during the interview process and can include some of these with the RFP. The vendor must come prepared to create and demonstrate these items “live.” The following are examples of materials the project team would send to a matter management vendor; your team would customize its samples depending on the technology is is evaluating.

Hot Topics for the Vendor Demonstration

Reports: Send the vendor descriptions of a few reports to be created during the demonstration.

Invoices: If eBilling is being considered, the vendor should demonstrate the import of an invoice, the billing validations and error notices generated, and the approval workflow.

Contracts: Send the vendor a sample of contracts, parent contracts and amendments that should be entered and cross-referenced in the system.

Integrations: The vendor should show how integrations (timekeeping, file room, document management, calendar, email, etc.) work with the software.

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.

Demonstrations should eliminate any assumptions about what a system can or cannot do. Afterwards, the project team will have a good idea of the products' functionality and the level of difficulty or work-around required to accomplish various tasks.

It's important to note that 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 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.

During the demonstration, the vendor will explain features and make assurances ' and you must find a way to capture these details in the final contract. You may suggest that the project manager create a voice recording of each demonstration and write a summary of the selected vendor's statements. Alternatively, you may decide to ask for the recording when you begin contract review (keep in mind that these are usually full-day demonstrations). In-house counsel should obtain the following for contract review: The written summary of the vendor's demonstration statements or a recording of the demonstration.

The Fees Matrix

Another area of frequent dispute is vendor's fee structure. The project team should never allow a vendor to present its fees in the vendor's own format. Interpreting a vendor's standard price list makes it difficult, if not impossible, for the project team to compare vendors and can contribute to contractual ambiguity. Instead, the project team should create its own Fees Matrix as part of the outgoing RFP. When the 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 should 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.

Categories of Software Fees

Software licensing fees. Fees should be identified as server or enterprise licenses, with full or limited access, and in terms of whether they are one-time, annual, monthly or based on usage.

Fees for interfaces, features and report tools. Costs associated with all desired interfaces (i.e., Outlook, AP systems or third party systems), optional features (i.e., document assembly, business rules) and report tools.

Implementation fees. The vendor should itemize fees associated with project planning and administration, design, development, testing, conversions, integrations, reports, documentation, post-implementation review and modifications.

Training fees. Fees 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.

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-house counsel can append this item directly to the software contract: The vendor's (but not the project manager's) final version of the Fees Matrix.

Details from Other Sources

Most in-house counsel will agree that a challenging area of contract review is finding a way to collect and incorporate any promises made by the vendor via e-mail, phone, voice mail and the like. By the time the software is selected, myriad communications between vendor and company have been exchanged, but few of them are documented. Of course, the project team will rely on the vendor's statements as being part of the agreement. Knowing, as you do, that the company will only be able to enforce the promises that are included in the contract, what can you do to rise above this challenge?

In all honesty, I wish I had the answer! The best solution I can offer is to encourage the project team, at the outset of the project, to agree on a process for collecting the details discussed with vendors by e-mail, phone and the like. It could be as simple as posting the information on a centralized project web site or forwarding the details to the project manager by email. You may ask the project manager to include a recurring agenda item at each project meeting to remind team members to forward any significant details arising from recent conversations.

Before starting contract review, in-house counsel can review these collected communications with the project manager and pick out the items to include in the contract. Counsel should incorporate the following as part of the contract review process: The collection of vendor promises and assurances communicated by e-mail, phone and similar means.

Conclusion

The path to effective contract review can be straightforward. Work with your project managers to create a best practices RFP process, and recognize the right materials to gather as you review software contracts. Go forth and be a contract hero.

RFP MATERIALS FOR SOFTWARE CONTRACT REVIEW

The RFP and the vendor's response

The vendor's written responses to follow-up questions

The vendor's response to the User Requirements Document

The written summary of the vendor's demonstration statements or the original recording

The vendor's final version of the Fees Matrix

Any vendor promises communicated by e-mail, phone and other means.

Nanci Tucker is Corporate Counsel and Sr. Consultant with Simpson Neely Group, Inc. If you would like a sample version of the User Requirements Document, Demonstration Script or Fee Matrix described in this article, please contact Ms. Tucker at 720-201-8550 or [email protected].