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 at Paddington Station, 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 worlds 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 specialisation as an expert witness is in the area of computer technology. I began working in this field after 15 years experience in the IT industry; firstly as a university lecturer and then as a consultant.
Just as in the days of Sir Bernard Spilsbury, an expert witness must be non-partisan, and must bring his or her entire experience to bear on the case in question in a fundamentally objective way. Its true that an expert witness is usually instructed by solicitors acting for one particular party; nonetheless, the expert witness is not there to take sides, but to be an expert and to be offer dispassionate evidence.
My own expert witness work involves advising courts about computer and information technology issues in cases where two parties are in dispute or disagreement. In practice, most cases settle before they actually reach court. My role in these initial discussions between the two parties who are in disagreement is to help one or both parties understand, in advance, the strengths or weaknesses of their position. This can actually help one or both parties to feel comfortable about settling because they now understand that a settlement offer is in fact a fair resolution of the matter, as well as a solution that avoids the expense, wasted time and stress of a court hearing.
How can these problems be prevented well before any litigation becomes necessary?
I couldnt of course comment on any particular case, but it is generally true that disagreements most usually arise either because the customer believes it has not been supplied with what is required under the contract, or because the customer cancels the contract and the supplier demands payment.
I am convinced its possible for customers and their IT suppliers to work together more effectively in a way that avoids the expense and wasted time of legal disputes. The basic key to this, in my view, is for the customer to involve an expert from the very beginning to provide an external review of crucial areas of discussion with the supplier, 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. What you need is an external view of project risk from the very start of the planning and discussion phases of the project, and this is exactly what an expert should be able to provide.
In my experience, customers are often guilty of failing to make their requirements precisely clear to their suppliers, especially in the following areas:
acceptance testing (what tests should be carried out to satisfy the customer that the system is ready for live 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 to problems such as power failure or the failure of certain individual components?)
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. External expert advice is a crucial resource here; the customer wants more than just to have the supplier's word for it.
The more of the above elements that can be included in the initial specification, the safer the project is for both sides. If the project is very large or very complex the customer may feel more comfortable if the project is split into two or more phases, with the first phase focusing on developing a clear specification and including all the bulleted points above.
The very nature and complexity of IT means that defining the initial specification is often extremely difficult, because it is so detailed. Furthermore, getting the specification right is in practice a much larger part of the overall project than one might immediately imagine. Having seen time and time again the consequences of initial specifications being insufficiently detailed or precise, I nowadays believe a customer should be prepared to devote between about ten to twenty percent of the project's total time and effort to getting the specification right. This may seem a lot, but the effort invested in getting the specification right will always pay dividends. There is also the practical point that it is much easier to edit a specification than to rewrite a computer program (code) that has already been written to the wrong specification.
What is certainly essential is that a written document is produced that stipulates all the points of the specification. Ultimately, it does not really matter which side draws up the specification: 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 a dispute with their customers by initiating, and then colluding with, a fundamentally unrealistic specification.
This problem is especially common in relation to time-frames, where suppliers sometimes seem almost wilfully perverse in agreeing to time-frames that do not even harmonise with their usual documented best practice. In these cases, it is sometimes difficult to conclude other than that the suppliers are being deliberately unrealistic in order to win the business. But this is an immensely short-sighted approach and ultimately may be commercially problematic.
Customers are also prone to making serious mistakes. A typical one is that they do not have anyone technologically expert enough at their organisation (or on their side) who can discuss the draft specification knowledgeably and talk to the supplier in the suppliers 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.
Customers often fail to appreciate the importance of having an expert in their team. If the customer cant afford to employ such an expert full-time, a consultant who is hired for the purpose will suffice. But dont expect someone who is not technologically-minded to be able to carry out this crucial role.
But if you do use a technologically knowledgeable in-house member of staff as the expert, be careful not to allow the person to be the single point of failure. Their own input should be subject to review by a competent external authority who can pinpoint any errors and misunderstandings by the customers own technologically knowledgeable person or by suppliers.
A common problem Ive seen is that the supplier proposes a system based around a technology that is essentially obsolete, or proposes a completely unnecessary 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 also 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 customised 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 (i.e. adaptations) of the package to fit your needs, and bespoke modifications of the package achieved by writing bespoke software for you. Generally, the configurations will still work well on new, future editions of the package, but the bespoke software wont.
Generally speaking, 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 engaging with the supplier.
One might imagine that the best way to avoid problems would be for the supplier to engage in some hand-holding that is not just geared around getting the contract signed as quickly as possible.
But the trouble is that suppliers are not in the hand-holding business. Instead, they are in the business of software delivery. The customer must therefore take control, and if advice is needed, the customer should be prepared to pay for it, such as by hiring a consultant or other expert.
The customer should also insist on the suppliers giving a PowerPoint presentation that shows all the key screens the supplier is proposing 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 technique for detecting any misunderstandings or gaps in comprehension.
Contractual matters obviously need careful consideration. The contract agreed between the customer and the supplier must allow the customer to terminate the contract at any time but needs to stipulate what payments are due on termination at specified junctures. Both parties should as a matter of course use a competent legal resource to go through the contract word-by-word and line-by-line. The contract needs to embody provisions for what happens if the customer changes the specification, as the customer may do at some point. If the specification is often changing, it makes sense for fresh attention to be given 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. The problem is that each supplier can blame the other for an interface problem. For large projects one solution may be to engage another supplier whose sole brief is to get the interfaces right and manage the other suppliers.
Finally...look hard in advance at the challenge posed by data migration. The customer should decide as early as feasible in the project what data needs migrating and what data can just be archived. As for the supplier, it needs to start practising or rehearsing its data migration for the customer early on, so that it can become adept at the task and report any likely problems sooner rather than later.
The big lesson for customers is to communicate effectively with suppliers, and bring in experts early. If customers do this there is a strong likelihood that the only thing the experts will need to witness is the implementation of a successful IT system that brings significant competitive benefits.
David Sharp is a principal with business and IT consultancy Charteris plc. He heads the consultancys Business Consulting Service line.
Add a Comment
No messages on this article yet