IT Programmes Expertise
Information Technology is a generic term that applies to computer and communication technology for the manipulation of data deployed in support of a business enterprise. An IT programme is the implementation of such a system into a business environment.
IT pervades commercial life to such an extent that there are few businesses that have no IT systems. Larger businesses will often have systems that are bespoke designs, engineered specifically for their business model. But does the design meet their needs? Others may have been advised that a particular enterprise application suite fits their business, only to find that their expectations are not being met. Either approach brings scope for disagreement, possibly leading to dispute resolution or litigation.
There are three broad headings under which expert advice in IT programme disputes may fall, given here with a few illustrative examples:
- Performance/Programme Management – e.g. failure to deliver, missed milestones, unachievable plans, inaccurate estimation, inadequate quality assurance, failure to bring to market opportunity (time of the essence), failure to pass user acceptance testing, etc.
- Technology/Technical Issues – e.g. inappropriate product selection, limitations of the software language, sub-optimal client/server partitioning, design errors, inappropriate lifecycle methodology, system sizing, queuing performance, data management and retrieval, data model, etc.
- Procurement Issues – e.g. inadequate or ambiguous specification of requirement, scope of supply, requirement scope creep, product licensing issues, intellectual property rights, etc.
Usually a dispute encompasses more than one of these issues. Sometimes issues that may on the face of it be essentially commercial, such as the withholding of a milestone payment, require an opinion as to whether or not the acceptance criteria were fairly met.
An IT expert can be instructed to give independent advice to the court or as a consultant to support one or other of the parties. The role is essentially to navigate through the sometimes entrenched views of existing staff on either side of the contract to identify the key issues and help the legal professionals to a clear understanding. This is rarely obvious!
An ancillary task is the demystifying of the jargon that pervades IT. Although straightforward for an experienced practitioner, it can seem very confusing to others, and legal teams can often be at cross purposes because of it.
The very flexibility of IT means that often there is more than one perfectly viable approach to any problem. A client may become exercised that his supplier hasn’t used the 4GL initially proposed, but that may not matter at all. Genuine misunderstandings between supplier and client are commonplace. Arguments over the definition of requirement or statement of work seem to happen in almost every dispute.
Clarity of causation
It is often the case that the foundation of the case is based on information that the legal team has received from the client’s technical staff which may be distorted or plain mistaken. The point at issue, for example, could be that a screen is taking too long to load up data and a call centre queue is backing up in consequence. The client may say that a contractual performance requirement is being missed. The supplier may counter that it is also a contractual requirement that they have to run on the client’s existing or legacy estate and that things have changed because of multitasking other client applications, which was nothing to do with the contract and there is now not sufficient processing power. Both may be true.
Answers may be that the data model could have been designed better, requiring less processing power. A proper programme management methodology may have had sufficient design reviews to have ensured a better design. Perhaps it’s a shared network issue, but no network topology had been factored in. If the supplier had been made aware of the changes in the system load when they tendered for the work, the problem may never have arisen. IT is of itself so flexible that there is usually more than one design option. Usually there are shades of grey needing fine interpretation to understand the best options in context.
The way in which an IT supplier will engage and support a business varies significantly. Sometimes the client company will employ the supplier to undertake bespoke design which the client will ultimately take over and run in-house. Sometimes the client will outsource the provision of a new system and the operation of it or any number of variations therein. The problems that can arise are often characterised by the nature of the engagement, and the expert needs to have a good understanding of the environment.
Experience and qualifications
The necessary skills and experience to be effective in this field are principally acquired by being or having been an active practitioner, although academic qualifications are reasonable indicators. As outlined above, the true reasons for the breakdown and ensuing dispute may not be clear at the beginning of the process. An ability to analyse and see through the mist is acquired through experience. It cannot be taught.
That said, there are some clear characteristics that can aid selection:
- An academic engineering, scientific or technical qualification, combined with a number of years in the IT and communications industry. Many computer scientists began their careers in other fields.
- Membership of one of the appropriate learned societies at a level that confers CEng or Eur Ing status. In the UK two of the most common are:
MIET – Institution of Engineering and Technology – www.theiet.org
MBCS – British Computer Society – www.bcs.org
If programme management or project management is a specific issue then, along with appropriate experience, qualification in methodologies such as:
However, many IT houses have their own internal methodology that is equally powerful and appropriate. Indeed, formal qualifications should be seen indicators. Appropriate experience should always be the deciding factor.