Service level agreements and contractual performance requirements come too late in negotiations with vendors, usually after the contract is signed, warns a leading technology lawyer.
Andrew Sorensen, senior associate for technology, media and telecommunications for Deacons Lawyers told delegates at the Computerworld IT Leaders Forum 2004 in Sydney last week that client companies, dissatisfied with vendor performance levels -which had not been adequately defined within supplier contracts - were still trying to terminate contracts.
Often the parties had not produced an estimate of implementation dates and performance milestones, he said.
"[It often happens that] the IT provider doesn’t know enough about [business process of] the client – then the client often doesn’t have the time [to map them and set them out],” Sorensen said.
In the case where users and their suppliers are strapped for time in getting the implementation ball rolling, Sorensen said users should try to build definitions of processes, benchmarks and service level deliverables into contracts as the first deliverable.
At the other side of the contract lifecycle, Sorenson said that users were still falling over in terms of disengaging with vendors, especially where clients wanted to sweat their IT assets beyond the vendor’s stipulated support period.
This remains especially so in cases of which party retains intellectual property rights over improvements to technology-based business processes and enterprise applications. Acrimony still frequently arises at the end of an IT contract when neither vendor nor client agree about who retains rights over proprietary improvements, because such concerns too often come after such improvements are made.
“The disengagement process is often overlooked and that can cause problems. Requests for proposal or tender should clearly set out what your objectives are. [In terms of] intellectual property disputes over property developed in a deal, that should be dealt with up front,” Sorensen said.
Intellectual property concerns also extended to software product lifecycles, especially when users faced the very real probability of attempting to continue with applications development after a vendor ceased to either support or provide fixes for either applications or operating systems, Sorensen warned.
“This matters if a system is no longer supported and you want access to the source code. Escrow [placement in trust of the source code] should be considered,” he said.