Dispute proof your technology project: Written guide
This article complements the first episode in a six part podcast series “Navigating Technology Disputes: Get IT Right!”.
At the outset of an ambitious technology project, it can be easy to lose sight of the small details which can make a big difference should things go wrong later down the line. No one goes into a project expecting it to fail, but taking some of the steps set out below may help to prevent and manage unexpected difficulties in a way which does not destroy the relationship between supplier and customer.
Budget effectively
At the earliest possible stage, it is vital to put in place a sensible budget, and be realistic about what that budget can achieve.
Large digital transformation projects are usually implemented with a desire to save the business money and increase profitability, but there can sometimes be a reluctance to spend money up front to realise the desired cost savings. This can be a very difficult tension to resolve.
Large technology projects rarely proceed exactly according to plan and if contingency has not been built into the budget there may not be sufficient funds available to carry out the work needed to ensure the project goes live in the form originally envisaged. There are generally three key levers which are crucial to the success of any project and which are often used to save a project in distress – namely:
(1) money;
(2) time; and
(3) scope.
If any one of these levers is taken away, there are less options available if the unexpected happens —meaning a significantly higher risk of project failure.
Effective agreements
It can be frustrating to hold progress back while the necessary legal documentation is put in place, but a robust, comprehensive legal agreement is likely to save significant time and cost once the project is up and running. It will also provide more certainty in the event that something goes wrong.
As a starting point, it is important to communicate with clarity what the project is trying to achieve. The overall business case needs to be given focus, while also recognising the risk of a disconnect when attention turns to converting the business case into a contract complete with the scope of requirements and a timetable for delivery.
Careful thought is needed in order that the business case can be translated into a contract with all of its constituent parts. This is important to both the supplier and the customer. If the supplier is constantly having to try and “hit a moving target”, the potential for additional cost, delay and disputes can be significant.
There is also a need to recognise that:
(i) major transformation projects tend to be complex, business critical and have many potential points of failure; and
(ii) the project is likely to involve a level of business change. As such, there is a real need to bring all the customer stakeholders on board with the project. A failure to do this may result in an irreconcilable gap between what the customer thinks it has bought and what the supplier thinks it has contracted to deliver.
Another particularly important function of the agreement, is to ensure that all parties are clear about their respective roles and responsibilities. While the intention is that everyone involved will work together to provide the various deliverables, the reality is not always that simple and a complex project will often require various inputs from numerous parties. This can prove difficult to manage in the absence of a clear delineation of roles and responsibilities. Clear provision for how, and by whom, the project (including third parties) will be managed and governed is vital.
In this regard, customers can sometimes be surprised about the level of input that is required of them. There can be a view taken that as IT experts are being engaged to deliver the project, it is for them to do all the work and take full responsibility for delivery.
That is rarely the case. It ignores the fact that, even on seemingly straightforward implementations, there will be significant amounts of data or other inputs which the customers have to provide. This can even be the case for so called ‘out of the box’ solutions, which often require decisions to be made by the customer as to how the solution needs to be configured in order to meet its requirements.
As demonstrated vividly in
Once the teams are in place, and all are clear on their roles and responsibilities, this should be supported by a suitable governance structure. A robust governance structure will assist with (among other things):
- reinforcing roles, and identifying responsibilities, as the project progresses;
- decision making over the course of the project;
- the sharing of information and best practice;
- ensuring alignment among all of the relevant stakeholders, including senior management;
- documenting progress on the project to ensure things are on track; and
- ensuring that any issues are identified as soon as possible so that steps can be taken to resolve them at an early stage.
The project’s governance structure should also be reviewed on a regular basis to ensure it remains fit for purpose as the various stages of the project are completed. However, there is a balance which needs to be struck with the governance structure.
Too much governance can stall progress. Too little governance may mean problems are not identified early on and can develop into much bigger issues before they are eventually identified, by which time matters may have spiralled out of control.
The minutes arising from any governance meetings will also be vital in the event of a dispute in order to identify what went wrong, as well as when and how it went wrong. It is therefore important that any such minutes are as complete as possible, and stored in an easily accessible location, should they be needed.
Again, while at the outset of a large, transformational project, the parties may not want to think about what could happen if the project runs into problems, it is crucial to give careful consideration to how disputes may be handled. In a long-running transformation project, managed service contract or IT outsourcing, the parties will very likely have committed to a long-term relationship in which both parties have already made and will continue to make an ongoing significant financial and business investment. It is in the parties’ best interests to do everything they can to “keep the lights on” while any disagreements are discussed, and hopefully resolved.
When considering what may be the most appropriate dispute resolution method, parties should consider the particular circumstances of their relationship, and the potential disputes which may arise, including:
- Where the parties are located and the ease of enforcing any judgment.
- The strength and breadth of the ongoing relationship between the parties and whether they are likely to need external intervention to resolve issues.
- The length of the contract, and whether disputes will need to be resolved quickly, in order to allow the continued smooth running of an ongoing project.
- The likely level of technical expertise necessary to determine the dispute.
In some circumstances this may lead to “hybrid” clauses in contracts, which deal with different types of disputes in different ways. However, care should be taken as regards clauses which are too complex, or novel, as this may simply result in satellite disputes as to which mechanism should be deployed in any specific circumstance, i.e. about the dispute resolution clause itself.
Effective teamwork
In the next episode of this series, we will consider mechanisms for operating the contract to your advantage. In addition to the contractual mechanisms there is an important “people” aspect to successful large technology projects.
As emphasised above, the right people need to be allocated to the right roles and they need to know exactly what is expected of them and what their responsibilities are.
A great deal of collaboration and trust is needed to successfully navigate what can sometimes be the turbulent waters of a large technology project and the importance of a strong and motivated team cannot be underestimated.
Too often we have seen examples where personality differences between key members of the respective parties have a catastrophic impact on a project. People issues need to be identified and resolved quickly and sensitively.
It is also important to avoid a high turnover of staff, to avoid any knowledge “drains”. While this cannot be avoided in some circumstances, not least as large technology projects can run for a number of years, if key members of the project team do leave, it is important to ensure that there are detailed handovers and that any information which is key to the project is retained where it can be accessed easily.
