Reports of the death of custom enterprise software have been somewhat exaggerated...

Many observers believe that with the advent of Software as a Service (SaaS), custom enterprise software may have had its day.   The demand for various models of cloud services has increased.   This model often comes hand in hand with a "best of breed" software selection approach which reduces the need for custom-made software solutions in the IT services industry.  But will the continuing trend towards this model mean the death knell for custom designed software?   It's not likely.   In fact, as we suggest below, there is a significant likelihood that a demand for customized enterprise solutions will continue.    This means that a good understanding of how to negotiate enterprise software contracts will be a necessary skill.


The need for customized software solutions
There are many enterprises that will continue to desire custom-built solutions to compliment their business activities.   Their requirements are usually centered around those activities that are distinctly different from the activities of others.   To take a simple example, consider a construction firm that produces estimate documents.   These may only require a small amount of standardization from document to document.   In that instance, Google Docs will perform all of the functions this firm requires.   A law or accountancy firm, on the other hand, requires a higher level of standardization - their staff may have complicated templates, formats and macros that need careful management.   In that situation, a fully customized version of Microsoft Word, Excel or another high level document application is likely to be required.


There are many examples of enterprises that require functionality that will extend beyond the capabilities of current SaaS offerings - many of them are in industries with unique IT requirements such as healthcare, energy and high-level asset management.   Of course, the SaaS offerings are likely to improve substantially over time, but for the present at least, there will still be an operative demand for custom-built solutions.


The other issue with the cloud model is that where there are a lot of software vendors and services providers involved with the user's service package, there may be a tendency for those parties to point the finger at one another when there is an IT services problem.   Using custom-built software clarifies this issue because it reduces the possibility of shifting the blame.


Understanding enterprise development agreements
Which brings us to the point.   Where developers are being contracted to provide enterprise software solutions, it's important to understand the commercial pressures that will apply to the contracts.  Regardless of which side of the fence you are on, you are likely to encounter some of these:


1.  Specifications / Requirements - the tension here is that the user will want to rank its requirements ahead of the developer's specifications.   For the developer, the shoe is on the other foot.   Users who submitted a request for proposal (RFP) to the developer will look to tie the developer's obligations to meeting the user's requirements in the RFP.   Conversely, the developer will try to make the user accept the developer's specifications submitted in response to the RFP.


2.   Bundled Services / Warranty - typically the developer will attempt to tie a development contract to a services contract after the software solution has been implemented.   From the developer's perspective, this is a good way of ensuring that there will be some ongoing income following the implementation.   However, the user won't want to pay for services that overlap with any warranty period provided in the enterprise development contract (say 3 months).   Basically, no-one wants to pay for services that they should be getting under warranty.   If there is a notable difference between what is provided under the warranty and the services detailed in the services contract, there will be less pressure here.   However, where there is no practical difference, it may be most pragmatic to have the services agreement commence following the expiry of the warranty period.


3.   Liability Carve-outs / Performance Obligations - The developer will want to avoid liability for consequential loss, but the user will want to make sure that consequential loss as defined does not include types of damage that are simply part of the developer's performance obligations under the contract.   For instance, a loss of data due to a software bug could be described as consequential loss, but if the developer has been contracted to safeguard the user's data, then the user won't see a carve-out including data loss as appropriate, because it lets the developer off the hook from a principal performance obligation.   Similarly, developers will want to cap their liability to something like the cost of the re-supply of development services or to a fixed figure.   Users, on the other hand, will want to ensure that any liability cap reflects the extent of the developer's insurance cover.


4.   Contract Basics - You will want to ensure that any enterprise software development contract includes clearly specified terms that set out:

• a full description of the services (with reference to the RFP or specifications - see point 1 above)
• a suitable description of the quality standard to apply to the services
• the timeframe that will apply to the service delivery, complete with machinery for dealing with delays and overruns
• the price to be paid by the user 

Our prediction is that there will be a continuing need for enterprise software development services in the future.   This will mean that there will also be a need for a continuing understanding of the commercial context of IT development contracts in this industry.   While the issues above are by no means exhaustive, they are a useful context from which to consider and negotiate contracts of this kind.