Turnstone consultancy director David Brook has seen most tricks in the book from vendors when it comes to IT procurement negotiations. Sitting in a London coffee shop, the PwC veteran tells Computer Business Review that the “rogue’s gallery” he’s encountered has made him cynical – but it’s a useful cynicism.
The co-founder of the independent consultancy, which specialises in contract negotiations, has dealt with over 250 technology vendors, checking the fine print of contracts for customers across the FTSE350.
He’s keen to drive home the point that too few buyers check carefully enough under the bonnet of their shiny new toy. He told Computer Business Review: “The way organisations procure their IT services is one of the last areas of the IT industry with few controls or standards.”
“Project management has Prince2, infrastructure has ITIL and Enterprise Architecture has TOGAF to name a few. But for IT procurement, it’s often down to the best endeavours of the staff at hand, who are normally busy on operations or projects.
“It’s the Wild West out there and it favours the vendors.”
Computer Business Review’s editor, Ed Targett, joined him to hear more.
Content from our partners
What are the most common mistakes you see companies make when buying IT solutions or services?
There’s “Let’s just meet and greet bidders” for starters. This has the attraction of an easy start and the friendly casual approach strongly welcomed by vendors. Reality soon bites though: offerings soon become difficult to compare, in terms of both cost and the match to your requirements.
Then there’s ‘the early favourite’ syndrome: on around half of our RFP exercises for clients they already have a favourite, who then falls by the wayside when the objective scoring is completed. This is where a good sourcing exercise not only gets you the right vendor, but avoids any embarrassment later on.
Doesn’t a decent RFP resolve this?
In theory, yes. In practice, there’s a lot of “day job RFP” that takes place. Under-resourcing or not putting the right resource into an RFP can be just as bad as the above. Running a successful RFP needs more than technical understanding.
Such as?
The key five areas you need are:
– Clearly written business requirements, then technical requirements
– Commercial requirements, specific to the category of technology you’re buying (e.g. for SaaS you might state that the costs should closely track your usage, or for mobile phones you may ban the hardware fund
– A well organised team scoring the bidder responses, with a clear output of the quality rankings, including total lifetime costs
– A negotiation plan for the winner, addressing all exposures and key points in the operational schedules, and in the main contract
– Available and experienced resource for the negotiations, including legal, CIPS qualified procurement, business and IT resource as needed
You’ve conducted thousands of “contract MOTs”. What are some common “hidden nasties” you find – and how prevalent are they?
The hall of shame includes for starters vague pricing terms, which lead to invoicing problems and overcharging, and service quality. This is easy to overlook if there are some service-level agreements, but these need to be in a meaningful format that relates to your usage and operations. There’s also often a case of ‘up quick, down slow’.
Absolutely do look apparent contractual gift horses in the mouth, says David Brook.
A common presumption that can often cause issues is that contracts are the sole domain of legal resource. In reality a technology contract contains around 50 percent legal terms and 50 percent service and commercial terms.
Lawyers will naturally focus on the former, but it is the latter terms that can have an important effect on how well the service is both implemented and run.
We operate a warning light system and you’d be shocked at the failure rates: four out of five vendor contracts fail on one or more of the above areas at first draft of the contract.
How open are most vendors to contractual tweaking?
Some vendors like to spread the myth that their contracts are non-negotiable. We have never found this to be the case, regardless of vendor size. When approached in the right way, vendors do want your business and will negotiate.
Could you give a few examples of “up quick, down slow”?
We notice this particularly with cloud providers – they are quick to add extra users in for you in the good times when a business is growing, but slow to scale back if the business needs to cut back and make savings. Be sure to carefully check the Charge Variation clause and look for any artificial delays in scaling back – remember, all they have to do is press a button.
Other examples would be cloud CRM providers asking for one or two years worth of fees upfront. As well as the cashflow implication, you won’t know what your usage of the service is in advance, and may overpay. If you find yourself in this situation, be sure to use it as a very strong negotiation lever on your unit price, and explore what happens with any credits.
You’ve mentioned that exit terms can be an issue… tell us more.
Best practise for exit terms is to set out clearly who does what, by when, and for how much money. But what we typically find is that vendors’ standard terms are vague (the dreaded ‘best endeavours’ wording) or worse there is no mention of the exit process at all. An exit schedule is important at the end of the contract, or sooner if you need to terminate. Having no exit schedule, or a vague one, leaves you completely exposed to the vendor’s whim, at a time when relations may not be at their best.
How has cloud changed things?
Much has been written about cloud issues such as security, control of data and vendor lock in. Whilst these issues can be addressed contractually, and by sourcing strategy, it is interesting to focus on what has changed between a traditional software license contract to a cloud contract.
In the earlier days of cloud, many vendor contracts were simply re-badged versions of their original, on premise, software license based contracts. Cloud contracts however should be very different, essentially being service contracts, where there is even more need for clarity on price mechanisms and service levels.
The outsourced model can also leave a business with less technology skills in-house, perhaps deliberately so. Over time a vendor may take on ever more business process, expertise in system configuration and knowledge of how things work. It is important to ensure these are documented and kept up to date, should you wish to transfer all or part of the service to another provider, or back in-house. This is a good example of where key areas of a contract should form the operating manual, rather than being considered a dusty document locked away in a drawer.
