Wait! Before you sign that association software contract…

Kathleen McQuilkin | 09.02.15
Topics: Project Management, AMS - Data - Membership

The next time you’re considering an association software contract (AMS, CRM, CMS, etc.), try using the Reese’s Peanut Butter Cup model. A well-rounded software contract includes both legal and business components—I’ll let you decide which one is peanut butter and which one is chocolate. It’s critical to thoroughly analyze both the legal and business implications of the contract before you sign. In the end, legal rules—but you have to live with the business implications every day.

4570198529_61be8d78ea_z.jpg

After all the work associated with gathering requirements, developing a request for information (RFI) and/or request for proposal (RFP), researching your options, and making a selection, most people are only too eager to get that contract signed—but hold steady. First, learn about what should be in the contract. Then, examine every aspect of the contract and ensure you clearly understand what you’re getting.

Due diligence—gathering and analyzing background information on a proposed business deal so you can make an informed decision about whether to go forward—is critical. Proper due diligence minimizes your risk of not getting what you’re expecting. You know you’ll get what you need because you’ve done your due diligence before signing anything.

Establish a healthy “contract review” mindset

We all have a natural bias toward expecting the best. However, that attitude isn’t always warranted. Things do generally look great before you sign.

  • The vendor is responsive—after all, they’re still courting you.
  • Everything seems to make sense at the time—however, you don’t know what you don’t know and you want the new system to be the answer.
  • It’s time to move on—you have other work on your plate and you’ve already invested lots of time in this project.
  • The vendor assures you the software will meet your needs—and you want to believe that, you want to be a good trusting partner.

All I’m saying is: keep an understanding of this natural bias in mind so you know when you’re falling under its spell. That being said, don’t go too far in the other direction. Be reasonable about what each party (your association and the vendor) should expect.

Most importantly, pause. Don’t assume anything. Take time to review each part of the contract and ask for clarification when you’re not clear on something. The contract is a formal agreement as to what the vendor will do for you. It should clearly state what services are included. Don’t assume that because item Xwas in the vendor’s proposal or you talked about it with the vendor that item X is part of the deal. If item X is not in the contract, the vendor is not obligated to provide it.

5 questions to consider before signing a software contract

#1 Do you know what you need and want?

How confident are you that this is the right system and vendor for you? When a system doesn’t live up to expectations, it’s often because the requirements analysis process was done poorly or not at all.

If you’ve arrived at selection without going through a thorough requirements gathering, prioritizing, and documenting process, press pause, then rewind and do that first. You may end up in an entirely different place and, yes, it’s worth it in the end.

#2 Have you seen that the vendor can do what you need, and do you like how they do it?

The vendor should provide detailed demonstrations that show how the software meets your needs. If they promise a functionality, make sure you see it demonstrated. If the vendor touts mobile features, ask to see mobile functionality demonstrated on someone’s phone—don’t assume it will work the way you think (or hope) it will work.

#3 Have you received a proposal from the vendor?

The vendor’s proposal lays out what they will do to meet the needs you identified in the RFP and/or discussed during the sales cycle. Their proposal should include:

  • Software and services costs
  • Details on how the product meets your requirements
  • A copy of the contract
  • Details on the implementation process

In addition to licensing details, make sure the proposal addresses the following items as part of the implementation services:

  • Setup
  • Configuration
  • Customization
  • Data conversion
  • Integrations
  • Training
  • Web setup (if separate)
  • Testing
  • Report and query development
  • Upgrades (if applicable)

When requesting a proposal, be sure to include any critical and mandatory contract language in your RFP or solicitation document so the vendor knows your “make-or-break” terms up front. These items are different for every organization but may include clauses pertaining to indemnity, confidentiality, data ownership, or performance standards language.

#4 How do the costs and contract terms compare with other vendors? 

When it comes to costs, you need to do an apples-to-apples comparison of vendors on your baseline requirements. Be awareof the abilities and limits of the vendors being considered, so you’re really comparing apples to apples. Similarly, be sure to review the standard contract submitted with the proposal so you can understand how contract terms may vary among the vendors you’re considering.

#5 How strong is your position for negotiating?

Your negotiating strength depends on the timing of your selection decision, vendor competition, vendor desire for your business, and type of product. The greatest opportunity for negotiation is during the sales cycle before you make your selection decision and notify vendors.

If the vendor is still trying to win your business, then your negotiation position is stronger than it would be if you’ve already told the vendor they’ve got the deal. Negotiate for what you need before giving the good news.

Vendors who are more “productized”—for example, they sell off-the-shelf SaaS products—are generally less willing to negotiate. They want the same contract for everyone. Vendors who sell a product but have other vendors provide the services for it may also be less likely to negotiate.

Vendors who sell and implement their own systems are generally more open to negotiations. Establishing a good dialogue with the vendor can be extremely beneficial to negotiations and ensures you each understand why certain language is important to the other party.

Know how far it’s prudent to take negotiations. You must ensure that your organization is treated fairly and protected, but don’t jeopardize the entire project for something unless it’s truly a deal-breaker issue. Reasonableness—on the part of your association as well as the vendor—goes a long way when discussing and negotiating contract terms together.

Can you see clearly now?

In my next post, I’ll dig deeper into some areas of the contract that usually need more clarity and consideration.

Editor’s note: This post is not intended to be a substitute for legal advice. Always seek experienced legal counsel to address risks based on your association’s own, unique circumstances.

Flickr photo by Michael Verhoef

IT Maturity Self-Assessment   Benchmark and Raise your IT Maturity Take the Survey!

Subscribe to receive new DelCor blogs!

Subscribe

20-POINT CHECK

Peek into your org's IT Maturity with our self-assessment

RESOURCE LIBRARY

Find our best events, white papers, and more.

READY TO TALK?

In a fix, intrigued, or can't find what you're looking for?