There is nothing like the feeling of satisfaction, coupled with equal parts of relief, when a technology deal finally closes. From the congratulatory e-mails to closing dinners, parties that have just concluded a technology deal are like honeymooners during the first flush of their romance, eager, hopeful, and expectant of great things.
Given all the initial warmth, however, why do so many technology deals seem to end in divorce? For example, CIO Insight has estimated that currently the failure rate of IT outsourcing projects is well above 50 per cent while Enterprise Systems Journal has reported “staggering failure rates” for cloud projects. Research firm Gartner analyst Tom Bittman recently reported that 95 per cent of respondents in one of its surveys found some aspect of their IaaS private cloud has “gone wrong.”
While it’s difficult to generalize because of the myriad kinds of technology deals, I offer the following observations as to why certain technology deals end in failure (defined by me as any combination of unhappy customers, terminated contracts, and the occasional lawsuit):
This can be summed up as: know thy vendor. Customers that are seeking a customized solution with lots of software development, should not go to a vendor that lacks the resources to do so and operates on a commoditized one-size-fits-all basis. Even if the vendor says they can meet your expectations, no customer truly wants to be the beta test, especially for mission-critical implementation.
Your vendor has to share your vision regarding the form of business model, performance levels, staffing requirements, and other critical elements. Don’t expect public cloud providers to provide you with a private cloud solution unless they can prove that they have the expertise to do so.
Even if the vendor insists they can meet these requirements, be mindful of red flags and ascertain, for example, whether they will be actually doing the work or outsourcing it all to their third-party, offshore subcontractors, or if the project timelines for such custom work do not align with industry standards.
Related to the above, some vendors harbour very rigid perceptions of their marketplace and the way in which they will conduct business, which may not meet the customer’s own regulatory, legal, or business requirements.
Frustration ensues when the prospective customer endeavours to make the vendor change its own business practices to meet these demands. Many such vendors rely on their own boilerplate agreements (often in pdfs with lots of hyperlinks to ever-changing web site policies) and are unwilling to make changes.
Again, even if the negotiated contract includes these new requirements, it is unlikely the vendor will follow through on them unless they are willing to put in place the internal mechanisms to do so and make substantial changes to their methods, etc.
In such instance, customers should consider whether these vendors are the right fit for them in the long run or whether they would be better off seeking a more responsive/nimble vendor.
3. Misunderstanding of the technology/business needs
It sounds trite but customers really need to research and understand (i) their own technology requirements; and (ii) what they are asking from their vendors.
Vendors are not mind-readers and while they will strive to meet specific requirements, time and effort must be spent to clarify these in detailed statements of work (longer than three pages), critical business requirements, functional specifications, performance requirements, timelines, etc. to avoid any disappointment in the delivered solution.
This is particularly important in any kind of fixed-price arrangement as the vendor will want to narrowly scope their promised deliverables/services and ensure everything else outside the proverbial box will be on a time-and-materials basis.
The clearer the client can articulate their business and legal requirements, the better the vendor has a chance of meeting them.
Sometimes, where the parties avoid having the hard discussions pre-signing either because of a lack of time or desire to avoid dissention, and instead pepper their contracts with many “agreement to agree” clauses (which can be dangerous, given the parties may never agree to critical contract clauses such acceptance criteria, etc., post-signature). These key deal elements should be negotiated prior to contract execution, not afterwards.
4. Insufficient due diligence
Contracts do not always tell the whole story. Some vendors are highly reluctant to disclose their use of open source technology; others do not even acknowledge the vendor is actually a reseller of a third-party technology that may be subject to additional terms.
For example, I recently discovered the provider of managed services in Ontario was merely making available access to another vendor’s cloud solution that had its own set of completely one-sided terms (including client indemnities) and that contract was governed by the laws of another province entirely.
Customers must take the time to know the party they are going to enter a long-term critical business relationship with, including asking those tough questions about who is actually performing the services: the vendor or its subcontractors.
And surprisingly, some vendors do not understand certain basic aspects of their legal agreements — for example, whether a “perpetual” licence means they can then terminate the agreement and claw back the software from the customer or whether that use is truly irrevocable.
5. Insufficient negotiation time
Both prospective customers and vendors can be guilty of this one. Some vendors make preferred pricing contingent on closing the tech deal within two weeks of the original deal quote or end of month or else the contract price goes up exponentially.
While this can be motivational, it also makes for unpleasant negotiations given the race against the clock and does both parties a disservice. Sometimes crunching the negotiation time does not allow for the natural growth of the business relationship, creating adversity and leaving a bad taste in the mouths of the negotiators.
More importantly, the shortened deal timeline does not allow sufficient time for lawyers to negotiate key elements of the project, such as service levels.
Clients are sometimes locked into terrible contracts with minimal representations/warranties, etc. because they were seduced by the pricing alone. While important, pricing cannot be the only determining factor. This can lead to unpleasant surprises, akin to “buyers remorse,” after contract signing when the business discovers they actually signed up to higher prices than they expected (factoring in all those additional services charges) or failed to incorporate that termination for convenience clause that they later discovered they needed.
From the client perspective, what can be done to forestall these triggers and improve the chances of tech deal success?
• Be realistic about the amount of time it takes to properly negotiate a tech deal. It is not realistic to try to close a tech deal in the week before Christmas. While it can be done, such deals usually come back to haunt the parties after the fog clears.
• Do your homework and research the vendor community to ensure you choose a vendor with an excellent track record of delivering the services and technology that you have identified. Ask for customer references and follow up with them. Read trade journals and online technology blogs to better understand the vendor’s track record. See if there has been any relevant litigation. If you lack the internal expertise to do this yourself, consider hiring a third-party project manager or consultant to help you. The extra expense is worth it in the end.
• Lastly, in my view there is much to be said about the civil law concept of contracts being a “meeting of the minds.” If the parties determine that there are business disconnects during the course of the negotiations, these should be dealt with upfront rather than as a post-closing matter. The longevity of the business relationship may depend on this. Of course, every good contract should have a dispute resolution process but don’t forget the importance of robust termination assistance/transition provisions — as much as no one likes thinking about the divorce, one has to be prepared for all contingencies.