Contract or no contract, agreements with suppliers need
transparency
It is easy to assume that the Co-operative Wholesale Society made
only one major mistake in dealing with ICL: not signing a contract.
But in fact another, earlier mistake would have had a more
significant effect. When work commenced, neither the Co-op or ICL
had established how problems would be managed should they prove too
difficult to resolve within an agreed timescale.
As a result, the Co-op had two alternatives when regularly
confronted with unsatisfactory work. It could continue or it could
terminate. And as both sides should have known, it is difficult and
embarrassing to terminate a project; few IT directors will do so
until they think a project is absolutely unrecoverable.
However, the project will actually "die" before that point, when
the customer-supplier relationship has deteriorated to the point
where practical problem-solving is impossible.
So how can anger and resentment be avoided? Before the project
begins, agree the cost that can be recovered for delays caused by
the supplier. To reduce the amount of arguments, the agreement
should ideally be written into a contract. But while I would never
recommend that an IT director starts work without a suitable
contract, should this be the case, there should at least be an
agreement with suppliers on any costs for failing acceptance tests,
missed deadlines or missed key milestones.
In addition, a time limit must be agreed for how long intractable
problems will be worked at before costs are paid or when problems
should be escalated to a higher power such as senior supplier or
customer staff.
This may sound like contractual nitpicking. If you are negotiating
cost recovery, why not go the whole way and simply write a full
contract? But this is not a purely contractual issue. It is a way
of creating a workable, less stressful way to resolve arguments
with suppliers. It ensures that you do not get into any arguments
in the first place - as was the problem faced by the Co-op. The
company had only one way to express dissatisfaction and that was by
terminating the project.
The majority of problems affecting the day-to-day running of IT
projects simply do not deserve such a drastic response.
Allan Watton is managing director of Best
Practice Group, which has published a guidance note, 10 mistakes
everyone makes with IT projects,
www.bestpracticegroup.com/10mistakes.pdf