Accentuate the negative

One of the simplest steps that CIOs can take to combat the risk of project failure is to focus more on project scope and, specifically, to ensure that project teams do a better job of clearly documenting that scope. And one of the key questions that I believe CIOs ought to ask service providers much more often is the one that many providers don’t like to talk about. What are you not going to do for me?

Service providers understandably like to focus the debate at a reasonably high level. They are sales-driven, after all, so they focus at the positive attributes that their services or software will deliver. They don’t like to talk about the holes, omissions or extra work that will be required to integrate or interface with existing or future platforms. Looking beyond the sales facade is essential – but in my experience there’s a great deal of variability in how well that’s done and how the results are documented.

In fact, “what are you not going to do for me?” is just one of a series of questions that I believe customers ought to ask more (or ask more loudly) of providers at the outset of a relationship. And the results of that discussion need to be broadly communicated across the entire project team and make it into the contract.  Other questions include:

• What else am I going to have to pay for? There should be a much more open discussion about the additional incremental costs – not just of live service delivery, but also the costs of effective transition or exit. And, as I’ve written before, where exit and handover may be required, a separate charging model may be necessary to provide transparency and certainty.

• What do you need me to do? The list of customer obligations is frequently the Achilles Heel of any ICT services contract. It’s where many arguments start when service drops below par. The usual answer to the customer dependencies question is usually “provide reasonable assistance” or “support the project”, so that ought to lead to a supplementary question: “No, don’t waffle me with generalities; what specifically and exactly do you need me to do?” This needs to be enshrined much more specifically in contract terms.

• To the technical members of the team: “Have you read the front-end of the contract and do you understand what it means and does it fit with the schedules that describe project scope and charging?” and, to the lawyers and commercial members of the team: “Have you read the technical schedules and do they fit with the legal and contractual terms?” Too often, service providers seek to counteract legal terms with provisions buried away in schedules, or schedules are produced that are inconsistent with the legal terms. I saw a serious commercial dispute this year over payment for a sub-set of services where the contract dealt with those services separately (and differently) in two completely different ways in two documents that had been bolted together into the same contract without being checked for consistency. It was a mistake – and dispute – that could so easily have been avoided.

Talking about negatives is never pleasant, but asking for clarity and certainty as to what’s outside scope is an essential step to take to mitigate some of the risks of project failure.