Category: Legal & Contract Issues
You Need an Attorney
You followed a rigorous methodology for your municipal or enterprise software project, conducted business process and needs assessments, went through demos and selected a product. You have finally arrived at the contract negotiation stage of your procurement project. If your Municipal Attorney or General Counsel has experience with software contracts, you are in luck! If not, you should consider contracting an attorney who specializes in software contracts. If you run into a contract dispute down the road, this may turn out to have been money well spent. Compared to the 6-8 figure project you are embarking upon, the cost of expert advice from a specialist attorney will be negligible and well worth the cost.
On being presented with initial contract documents from a software company, one municipal attorney with whom I worked stated “Whenever I see contract documents that are this complicated I always suspect that they are swindlers. Now that I have reviewed the documents, I know they are swindlers.” He had a great point. Alternately, your software vendor might supply you with a two-page contract that represents the entire agreement. This is equally suspicious. Make sure you know what you are getting into.
In all likelihood, your vendor will provide you with a set of contract documents that are completely one-sided. Your attorney will need to negotiate the terms of the contract documents to provide you with binding assurances, leverage and a more fair distribution of the risks.
I am not an attorney and I am not providing legal advice but I have been involved in many software and services contract negotiations. Following is a brief description of standard contract documents you might expect to see. Don’t take my word for anything, though. Your attorney must review and approve all the documents.
Don’t count on verbal promises and handshake deals with the sales representative who brought donuts, coffee, and lunch. Every aspect of the deal must be in writing. After the contract has been signed, you may never see the sales representative again and you will be dealing people whom you have never met.
Some Standard Components of Software Contracts
Following is a brief description of the essential components you might expect to be part of a software deal. All of it might be in a single document, or the vendor may provide separate documents for each component and there may be agreements with third party vendors.
Software License Agreement
This is your license to use the software and there is a fee attached to it which may be a one-time fee or an annual recurring fee that will continue for as long as you use the product.
Software Maintenance and Support Agreement
The agreement for the continuing support of the product after Go Live which should include technical support and continuous upgrades.
Hosting Services Agreement (for SaaS products)
The agreement that covers hosting services which may be provided by a company other than the software vendor.
Statement of Work
A detailed breakdown of all the services the vendor is going to provide as well as the vendor’s expectations of customer responsibilities. Don’t expect that that vendor will come in and deliver a perfectly working product. Even if you paid for a turnkey solution, you still have a lot of work to do. Anything you might require that is not in this document may result in extra charges or a significant cost overrun. The statement of work should be very detailed must be incorporated and made reference to in the contract.
Service Level Agreement
This document describes the vendor’s commitment to the specific level of service you should receive should you have a problem. I would recommend negotiating penalties for failure of the vendor to meet the defined service levels.
The vendor’s response to the RFP or RFB with all the binding commitments they originally made. This should be incorporated and made reference to in the contract.
Payment Schedule – Software License
I recommend negotiating a holdback on full payment of the software license fee until after Go Live. This will give the vendor a strong incentive to get to Go Live quickly and efficiently. You won’t release the money until the product works to your satisfaction.
Payment Schedule – Implementation Services
The agreement that covers how ongoing professional services for implementation, training and travel will be billed including a realistic estimate of anticipated services. Initial proposals almost always underestimate the services that will be required.
Payment Schedule – Maintenance and Support
Make sure you address annual increases in maintenance for at least 5 years or more so that you are not faced with a large future increase in maintenance and support costs.
A detailed project plan and timeline for the project from kickoff to Go Live and beyond.
Proof of vendor compliance with your liability insurance specifications. This should be approved by your attorney, risk manager, or insurance broker.
There are many components to a software agreement and that is why you need an attorney. Once you compile all these documents, you make be looking at hundreds of pages. Depending on the availability of your attorney and the vendor’s legal staff, the contract discussions and negotiations could require from several weeks to several months depending on size and scope of the project.
Good luck with your contract negotiations! If you just want to bounce some ideas around or discuss your project, feel free to e-mail me at firstname.lastname@example.org. You can read more about IT Governance here.
Copyright © Jeffrey Morgan 2016by
In the glamorous and sexy world of software procurement and implementation, dirty secrets abound. You shouldn’t assume that your new spouse is going to cook, clean, mow the lawn and drive the kids to school. Before becoming entangled in a new long-term business relationship, draft and execute a business pre-nup that includes a detailed project and implementation plan clearly spelling out the responsibilities and workload distribution of all the parties involved. And make sure you include plans for how to break-up in case things don’t work out. Implementation services may cost at least 2-3 times as much as a software license, and possibly more. Understanding the implementation model you are buying is critical to the success of the project.
One of the most common disputes between customers and vendors in software implementations (after the contract is signed and license fees are paid) concerns who was supposed to do what. These disputes can turn into ugly finger-pointing sessions reminiscent of your favorite dysfunctional family movie . Don’t assume that handshake deals and verbal agreements with the sales team are going to be honored by the company’s implementation and support team. After the deal is signed you may never see the sales rep again; you will be dealing with team members you have never met in-person. This isn’t the vendor’s first movie, but it might be yours so the time to work out the details is before the contract is signed. Make sure that all promises are in writing and are included in the SOW, project plan and other contract documents.
There are really only three implementation models with minor variations and you should clearly understand which one your vendor has proposed:
- Do it Yourself
- Train the Trainer
In a Do it Yourself (DIY) model, you license the software and configure the system using in-house staff or contractors and consultants. I have occasionally seen this model work. More often than not it turns into something resembling a nuclear disaster. It isn’t likely to save any money and I wouldn’t recommend it unless you have staff members who really understand the business processes AND the underlying technology. If you saved money by opting for this model, don’t assume the vendor will provide extensive implementation assistance under your support contract. Implementation support and post-Go-Live support are completely different animals. If the project doesn’t work out, you may have to scrap all your work and start from scratch.
Train the Trainer is the standard approach to implementation offered by many software vendors. The vendor uses webinars, remote access and on-site services to train key staff members and stake holders in configuring the software. This model can be successful if you and your staff are committed to making the project work and are willing to invest large quantities of time. A key benefit of this model is that your staff will really understand the software. One major problem with this approach is that your staff members already have a full-time job. How are they going to find time to setup an enterprise system that may involve months or years of configuration, testing and hundreds of configuration steps? This model has a higher success rate than doing it DIY, but spectacular failures are not uncommon.
In a Turnkey model, the vendor does the heavy lifting, but this doesn’t mean you’ll be sitting back while the vendor is waving a magic wand. At a minimum you will have to provide lots of data and configuration input, attend training and meetings, and execute quality assurance measures for every deliverable. This is the most expensive method for configuring software, but no one knows the system better than the vendor. If you opted for a milestone based payment plan, you can rest assured that each component is configured and tested before you pay for that service.
You might be thinking that you don’t have to worry about the paparazzi. After all, this is software, not Hollywood. But if you run into a a 6-8 figure cost overrun on a public sector software project, your picture might be prominently displayed on the front page of your local paper with a caption that reads “Lucy, you got some ‘splainin to do.” If a massive failure occurs in the private sector, it might be a long time before your next audition.
Copyright © Jeffrey Morgan 2016
By Jeffrey Morgan
I have been experiencing a frustrating time during the last several weeks dealing with a couple of vendors who don’t want to provide a Statement of Work (SOW)) along with the other contract documents in order to finalize the deals. They keep coming back with something that is less than what I asked for and something that is not in the client’s best interest. Essentially, they are asking for the contract to be signed on a handshake deal promising that they will do everything necessary to get the projects done without putting specific details in writing. Sound familiar?
Some vendors are willing to comply with the spirit of a contract and will go out of their way to make you happy, and others will barely comply with the letter of the contract. If you haven’t dealt with the vendor before, getting the Statement of Work right is essential. Even if you have worked with the vendor before and have a great relationship, spelling out the project details and expectations is a good idea.
A Statement of Work (SOW) is an essential component of a contract. The SOW needs to define the 6 W’s:
- How Much
Although it is possible to use the original Proposal and Statement of Work from the RFP response as the SOW, sometimes the goals, objectives and the Scope of Work have changed significantly since the publication of the original RFP. In that case, an SOW that agrees with all the contract documents is required. The contract must define which document takes precedence in case there is a discrepancy. In a perfect world, there shouldn’t be any discrepancies. However, in Statements of Work that may run hundreds of pages, it is a possibility.
In both the RFP and in the SOW, I like to see the information in a tabular format so you can use those documents as a checklist during project implementation. There is a high probability that the Project Manager for implementation will not have been involved in the procurement process and subsequent negotiations, so having all the deliverables and expectations in a clear format for the Project Manager is important.
The SOW should define how payments are tied to formal acceptance of specific deliverables and milestones. In the specific cases I am dealing with at the moment, I am looking for specifications of onsite vs. offsite work with a specific schedule of when they will be onsite, for how long, who they will interact with, and what they will achieve during those visits.
There are many resources available for writing a solid Statement of Work. GSA has a resource at http://www.gsa.gov/portal/content/195713 and the Canadian Government has published a resource here at: http://www.rfpsolutions.ca/files/SOW_Writing_Guide2.pdf
If you have questions about SOW development or need help putting one together e-mail me at email@example.com.
Copyright © Jeffrey Morgan 2015