Seventy years ago, anyone dealing with the problem of a nagging spouse by chopping them into small pieces, and leaving the remains in a left-luggage locker, was likely sooner or later to find themselves confronted in court by the forensic genius of the Home Office pathologist Sir Bernard Spilsbury, perhaps the world's first expert witness. Today, the sheer complexity of modern commercial life means that expert witnesses - or expert arbitrators - are required in most areas of business.
My own expert witness work involves advising courts about computer and information technology issues in cases where two parties are in dispute.
In practice, most cases settle before they reach court. My role in the discussions between two parties who are in disagreement is to help one or both understand in advance the strengths or weaknesses of their position.
This can actually help them to feel comfortable about settling, through understanding that a settlement offer is a fair resolution of the matter, as well as a solution that avoids the expense and wasted time of a court hearing.
How can these disputes be avoided in the first place? The disagreements usually arise either because the customer believes it has not been supplied with what is required under the contract, or because it cancels the contract and the supplier demands payment. The key to making it possible for customers and their IT suppliers to work together more effectively is for the customer to involve an expert from the very beginning to provide an external review of crucial areas of discussion and, of course, of any drafted documentation.
This is a far more logical and effective approach than only involving the expert at the end of the process, when things have gone wrong.
The right specification
Customers are often guilty of failing to make their requirements precisely clear to their suppliers, especially in the following areas:
- acceptance testing (what tests are needed to satisfy the customer that the system is ready for use?)
- ease of use (how user-friendly must the system be?)
- functionality (what should the system be doing?)
- resilience (how robust must the system be?)
- security (which groups of people can access and change which data?)
- speed (what response time should be experienced by users?)
- the delivery time-frame (what should be done by when?).
The completion of a milestone is a good trigger for an external review, especially if a milestone is missed. The customer is also entitled to be able to monitor progress and to be aware of the extent to which the project is on track, an area where expert advice can be valuable, as the customer needs more than just the supplier's word.
The more of these elements that can be included in the initial specification, the safer the project is for both sides. If the project is very large or complex the customer may feel more comfortable if it is split into two or more phases, with the first phase focusing on developing a clear specification.
The nature and complexity of IT means that defining the initial specification is often extremely difficult, because it has to be so detailed. Further, getting the specification right is a much larger part of the overall project than one might imagine. Having seen the consequences of initial specifications being insufficiently precise, I believe that a customer should be prepared to devote between about 10% and 20% of the project's total time and effort to getting the specification right. This may seem a lot, but the effort invested in it will always pay dividends. It is also much easier to edit a specification than to redo computer code that has already been written to the wrong specification.
What is essential is that a written document is produced that stipulates all the points of the specification. It does not really matter which side draws it up; what matters is that both sides are comfortable with it and that it is realistic.
Suppliers, for reasons best known to themselves, sometimes seem to invite disputes with their customers by initiating, and then colluding with, a fundamentally unrealistic specification. This is especially common where timing is concerned, with suppliers sometimes seeming wilfully perverse in agreeing to time-frames that bear little relationship to even their best practice. In such cases, it is hard to draw any conclusion other than that the suppliers are being deliberately unrealistic in order to win the business. Ultimately this is an immensely short-sighted approach.
Avoiding pitfalls
Customers are also prone to making serious mistakes. A typical one is that they have no one in their organisation (or on their side) who is sufficiently technologically expert to discuss the draft specification knowledgeably and talk to the supplier in the supplier's own language.
Such a person should be able to sort out difficulties before they grow into significant problems, and certainly well before they end up as court cases. If the customer cannot afford to employ an expert full time, a consultant hired for the purpose will suffice. But someone who is not technologically-minded cannot be expected to carry out this crucial role.
A common problem is where a supplier proposes a system based around a technology that is essentially obsolete, or else proposes an expensive custom-built solution, when the customer would be better off with a customised package (often, ironically, available from the supplier's competitor) that would make the building of a system from scratch unnecessary.
You should always check in advance how easy it is going to be to upgrade your system if the package it is based on is upgraded. A common problem is that packages are tailored for customers in such a way that if the package is later upgraded, your customisations will no longer work. You need to distinguish between configurations (ie adaptations) of the package to fit your needs, and bespoke modifications of the package achieved by writing special software for you. Generally, the configurations will still work on new editions of the package, but the bespoke software will not.
The basic problem at the heart of many disputes is that the customer understandably finds it very difficult to know what it does not know when talking to the supplier. One might think that the best way to avoid problems would be for the supplier to engage in some hand-holding that was not just geared to getting the contract signed as quickly as possible. But the trouble is that suppliers are not in the hand-holding business; they are in the business of software delivery. The customer must therefore take control, and be prepared to employ outside expert advice where needed.
The customer should insist on the supplier giving a PowerPoint presentation that shows all the key screens it proposes to include in the finished system. This constitutes a kind of walk through of how the system will be used. It is a highly effective way of detecting any misunderstandings.
Contractual matters obviously need careful consideration. The contract must allow the customer to terminate the contract at any time, but needs to stipulate what payments are due on termination at specified junctures.
As a matter of course, both parties should use a competent lawyer to go through the contract word by word. The contract needs to embody provisions for what happens if the customer changes the specification. If the specification changes often, it makes sense to give fresh attention to getting it right.
Other advice? Customers and suppliers should pay attention to system interface issues, always a major area of risk in any significant IT project.
This may be a particular challenge if the project makes use of more than one supplier, because each supplier can blame the other for an interface problem. For large projects, one solution may be to engage one supplier whose sole brief is to get the interfaces right and manage the other suppliers.
Finally, look hard at the challenge posed by data migration. The customer should decide as early as possible what data needs to migrate and what can just be archived. The supplier needs to start rehearsing the data migration early on, so that it can become adept at the task and report likely problems sooner rather than later.
The big lesson for customers is to communicate effectively with suppliers, and bring in experts early. Then the only thing the experts will need to witness is the implementation of a successful IT system.
David Sharp is a principal with business and IT consultancy Charteris plc Tel: 020 7600 9199, E-mail: david.sharp@charteris.com
ACTION CHECKLIST
- Let your supplier know exactly what you want - and when
- Monitor progress
- Be prepared to devote time and effort to getting the initial specification right
- Make sure that the specification is realistic and that both you and your supplier are comfortable with it
- Put all the points of the specification down in writing
- Make sure that you are not being offered obsolete technology or a custom-built solution when an off-the-shelf package would do
- Check how easy it will be to upgrade
- Insist on a walk through presentation to identify any misunderstandings
- Get your lawyers to check your contract and ensure it allows for eventualities
- Pay attention to system interface issues, particularly if more than one supplier is involved
- Look hard in advance at the challenge posed by data migration
- If you do not have in-house technological expertise, get an external expert involved at an early stage
