Tips for testing and accepting delivery of association software

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

16782794566_617e1a4882_z.jpg

Months after you first started working on a software selection and implementation project, the happy day is almost near. Your new system is almost ready.

But will it be a happy day? Will you get what you were promised? Will this last phase of the project go off as you hope? Yes, it will—if you think ahead (and follow my advice) during contract negotiation.

  1. In the first post of this series, my advice focused on five questions to answer before signing a software contract.
  2. The second post dug deeper into some sections of the contract that usually need extra clarity and consideration.
  3. In this final post of the series, I’ll provide tips for testing and accepting delivery of association software.

Pay attention to acceptance language in the contract.

Keep an eye out for language stating “acceptance is deemed after 30 days” or words to that effect. This clause could cause problems down the line. What if a key person on your staff suddenly gets sick and the acceptance date passes before they can report issues with the delivered system?

I understand why vendors want to insert this clause. Some clients drag their feet on testing, and the project becomes stuck in limbo without any formal acceptance or rejection. Instead of simply accepting that language, discuss clauses like this with your vendor and work out a reasonable compromise that protects both of you.

The contract will typically specify timeframes for testing and resolution. If the timeframes work for you, be sure to incorporate them into your project timeline and allocate staff resources appropriately.

Review and test deliverables.

The day is finally here: your vendor tells you that your system or software module is ready.

Before you officially accept product delivery, remember the phrase: “Seeing is believing.” Before you believe the vendor is delivering what you were promised in the contract, you need to see the proof.

You’ll get that proof by thoroughly testing the system or software against the defined acceptance criteria in your contract (or in a separate document containing the relevant details). The following three critical items are often overlooked when reviewing deliverables, so pay particular attention to them.

  1. System configuration
  2. Data conversion
  3. Reports

After testing, notify the vendor of any issues. Establish the appropriate process with your vendor. For example, you can complete all testing and then submit all issues or you can submit issues as they are discovered. The vendor should make corrections and resubmit the product to you for retesting. Repeat this process until you’re ready to finally accept the product. Only after complete product acceptance is it time to “go live.”

Take your time—but use that time wisely.

When you’re in charge of a technology implementation project, it’s tempting to rush through the selection and contract negotiation phase so you can move things along, but resist that temptation. Remember to negotiate contract terms before closing the sale. Once you have a contract, don’t make assumptions or just hope for the best. Read the contract carefully, ask questions, and get everything in writing. Only then, can you expect the best results.

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 studio tdes

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?