1. WHY DISPRO?
I spent much of a whole year recently investigating why a major IT outsourcing deal broke down, and had given rise to the largest software contract dispute yet seen in the English High Court. Appointed as computer expert witness on behalf of a leading travel industry company, I headed up a litigation consultancy team examining evidence and giving expert opinion for a court case brought by that company against a major IT services supplier, one of the biggest players in the industry.
At the heart of the dispute was a failed software development and implementation project, which took place within the context of a major outsourcing agreement. The software development project was key to managing the outsourcing deal. It entailed the building and delivery of one new, single system, priced in the tens of millions of pounds, intended to replace many legacy systems. The outsourcing arrangement was to stretch over ten years. When it broke down, it gave rise to a legal action for recovery of in excess of �200m.
The irony is that the outsourcing part of the deal was largely going well. But everything got bogged down in the software development; and, because the software implementation project was tied into the main contract, the whole contract blew up when the software development "went DISPRO".
As a result of the failure of the software development project, the entire outsourcing deal was canned and the IT staff who had been moved across to the service provider had to be transitioned back in-house (to both parties' credit this was achieved within two months).
The case made it to court in autumn 2001, and settled shortly after the trial started. As is usual, the terms of the settlement are strictly confidential. However, I have drawn up a list of lessons to be learnt from my expert investigations on this and many other major IT disputes and litigation over DISPROs during the past 15 years. Here are some highlights of my findings, towards better legal contracting for, professional quality assurance of, and corporate investment in, major IT projects...
1.1 Legal and Project Structure
Learning Points:
- Split outsourcing contracts from development contracts. Outsourcing is a huge growth industry and this advice is counter to the way most of the industry is going nowadays. Today, many outsourcing contracts have software development and "value-add" features built into them. Lawyers think they can put controls and checks in place. But it is almost inevitable that the software development aspect will become problematic because, well, software is software - it's tricky stuff. Software engineering is still one of the most complex and challenging activities of mankind. All the service-level and other targets on the outsourcing side may be achieved, but such running and maintaining of systems requires completely different skillsets to software design and development.
- Have a significant retention in the development contract against final acceptance of the total developed software. Today's outsourcing contracts usually require regular payments against service level agreements, but software development should be judged by different criteria. Some payment should be retained until the software is up and running. It is not unreasonable that a percentage of the fee be kept back for a full year in case anything comes up in the software.
- Make the acceptance criteria objective, comprehensive and relevant to the true/most important needs of the business. How can you assess what is the quality of what you have been provided, when you were not sure what you wanted in the first place? After 40 years of the IT industry, most folk still seem to have problems defining and analysing system requirements. People are bad at articulating what they want - many are actually getting worse at it.
- Try and go for a two-stage, conditional development programme, with the acceptance of a "Proving" or "Prototype" System being required before activating the contract for a full system. This also provides an early test of the supplier. Design prototypes, "proofs of concepts", or construction maquettes of a system can be produced within weeks and should give an indication of some of the problems you will come up against - but in a small and contained way.
- When replacing/updating mission-critical legacy systems, never go live without a sensible trial period of parallel running. This should speak for itself, but a recent case in which I was involved concerned a failed integrated accounting software system implementation where one of the "Big Five" consultancies had advised the customer to go live with the new system without any period of parallel-running with the old system - and, for good measure, also timed this go-live "leap in the dark" cutover to coincide with the end of the company's financial year!
1.2 Managing Risk
Technology risk:
- While innovation in the IT industry is generally a good thing, it should not be done at a cost and risk to the customer. In my experience it can happen that a supplier represents that it can immediately deliver a certain new technology and skillset, and then, when it is awarded the contract, spends the first months frantically trying to recruit the right people and bring them painfully up to speed. When a major development contract is signed, a customer has the right to expect the supplier to have the ability to start cutting code from day one - rather than having to get into a whole new technological learning curve. In this situation, the customer is doing nothing more than investing in the supplier's learning. If the supplier is going to learn your business, new technology or tools and how to manage complex projects etc at your expense, this may be worth doing on a shared financing-risk-return basis. However, recognise that you are then pioneering and effectively being a venture capitalist - and act accordingly.
- Wherever possible, use only experienced professionals, with good references. Actively check-out the supplier and its staff's CVs, background and credentials. And do not be too readily seduced by the usual system "spec and select" process, which often arrives only at a "least worst" choice and may still not address the full, true business requirements.
Financial Risk:
- Have a fall-back plan, review it, then check it frequently. News stories routinely adorn the computer press testifying to the fact that not all outsourcing ventures are successful. You need to ask yourself: "Can I transition staff back in-house and return to my legacy systems if all else fails?".
- Just because you have outsourced your systems it doesn't mean you have got rid of the risk - you have just transferred it. You might allow a skilled parachutist to fold your parachute but you still take a spare with you just in case. And just because a disaster recovery plan, for example, might be costly - it doesn't mean you should not have it.
- The fall-back plan may be more expensive than the original development concept/plan. But it could save your business if all goes hopelessly wrong.
1.3 Early Delivery
Learning Points:
- Split every sizeable project into phases. Ensure tangible deliverables, of manageable and usable software, within reasonable time-periods; usually a maximum of six months, no more than nine months, for each phase.
- The first phase should ideally be the "Proving" System delivery. Be resolute: if that simple first phase cannot be completed wholly satisfactorily, bite the bullet and ditch (and if justified consider even suing) the supplier - things will only get worse later if you do not.
- Understand the profound contractual, technical and methodological differences between a "phase" and a "release" of software. A supplier may only make small changes to the software and call it a "release". Don't assume that you are getting "released" something drastically changed or improved, with major progress being made in phases of the development.
1.4 Independent Monitoring
Learning Points:
- Have an independent "monitor" as an integral part of any significant software development contract/project. The same is probably true for any substantial outsourcing contract, too. Significant construction or engineering contracts in other professional disciplines routinely have the role of e.g. "The Engineer" built into them: someone who, "as an expert, not an arbitrator", provides binding adjudication on, or other resolution of, all kinds of technical and project management matters and issues, quickly, as the project develops.
- Such a "monitor", should be a senior, experienced, authoritative, mature (grizzled and scarred�) IT consultant/project manager-type person. Good project management is all about making unpopular but resolute and effective decisions. This type of person does not come cheap - but it is money well-spent! Equally, it is vital that a company which has outsourced all or much of its IT department keeps someone senior, skilled and experienced in-house/contracted to oversee whether the outsourcing/software development is being done well or not.
1.5 Board-Level Ownership
Learning Points:
- It is vital that the customer has a project champion at board level. Modern information- and communications-dependent businesses need board-level budget and responsibility for mission-critical systems developments.
- Such a board member needs to be someone who can peer-relate and negotiate with the supplier's board directors, and also someone who won't be bamboozled by IT suppliers, or in-house IT management or staff, "techies". He/she needs to be an expert not only in the customer's business, but in the tried and proven principles of good IT and software engineering/systems development and management methodologies - a true IT professional.
1.6 In Summary: some other DO's and DON'T's
For a software development project:
- DO Ensure a complete and correct requirements specification at the start of any software construction. Changing requirements while the software and database is under construction leads to many problems. A correct specification from the start can avoid this rework, the consequential problems and the resultant loss of quality. Beware modern "methodologies" that suggest it is not necessary (or is even impossible) to produce a good requirements specification. "How can you get what you want, if you don't know what you want?".
- DO Divide the entirety of the work into small incremental deliverable modules. Ensure that there are at least ten modules, approximately evenly spaced, so that the project cannot depart from the build plan by more than 10% without the departure being obvious.
- DO Arrange that each delivered module depends only upon its predecessors; the system is then operational, with restricted functionality, and making a return on investment, from an early stage in the development. Any residual errors in the delivered code become apparent on a continuing basis and are correctable as encountered so that the reliability of each delivered module rises steadily.
- DO Use every available means to "illustrate" what has been specified (especially prototyping, animation, modelling, story-boarding). A natural language specification rarely describes the intended system adequately for users. The presentation of several different specification viewpoints is vitally important.
- DO Invest in the right skills. Data analysis, data modeling, data representation, and database definition are complex matters, of exceptional importance to the success of any project, and require experienced and skilled people for correct execution. An expert or small team of experts with necessary complementary skills should undertake database design.
- DO Reduce risk and change as much as possible; never introduce several new technologies together in the same project. Software development is risky enough in its own right without building further risks, such as using a new language or toolset, into the ongoing work. Always ensure that as a customer you retain enough (independent and professional) expertise to guarantee control over the constructing organisation or supplier. Provide the team that embodies this expertise with all necessary support. They are your guarantee that the constructing organisation/supplier will build or supply what you need.
Five IT Project Manager DO's:
1. DO Ensure that the non-functional requirements are given the same (if not more) importance as the functional requirements.
2. DO Ensure experienced people mentor and guide the less experienced.
3. DO Have regular design and code reviews.
4. DO Understand the SCOPE of what is required to be delivered.
5. DO Embrace (but do not pioneer!) new technology, and understand that there will be a learning curve.
Five IT Project DON'T's:
1. DON'T Assume the first design is correct - be prepared for change!
2. DON'T Leave non-functional testing to the end.
3. DDON'T Over-engineer - simple solutions are more elegant, have fewer potential weak-spots, and are easier to understand, change and maintain.
4. DON'T Fall back into your "comfort zone": use new technology and new methods and apply them - sensibly - using their strengths.
5. DDON'T Have large development teams - small teams work well: recall the "magic number 7".
Five Key IT Project People:
1. Overall Design Authority to make key architectural decisions.
2. Lead Business Analyst - empowered to define/correct business requirements.
3. Project Manager - to ensure timescales are realistic.
4. Technical Team Leader(s) - responsible for mentoring and educating the team.
5. Business Sponsor - to ensure that what the customer pays for is what it "asked" for.
I believe that learning these lessons can dramatically improve your chances of avoiding software and systems implementation contracts "going DISPRO" on you. But, even if well-learnt, and diligently followed, by systems customers, suppliers and their legal advisers alike, these lessons may not be enough to assist with recognizing early the "fatal signature" of a DISPRO, nor with knowing what further avoiding, or even rescue, actions to take once you are in an escalating DISPRO and dispute situation....
