Complex IT and outsourcing projects are prone to delay. Some are abandoned in acrimony before completion. Whilst each failed project goes wrong for its own reasons, there are common themes. Lessons learned from one project can often be of benefit in the management of others.
Sometimes the failure of a project will result directly from shortcomings on the part of the customer. Sometimes the supplier will be at fault. Frequently both parties will have contributed to the problems, at least to some degree.
In this article, we look at common reasons for project failure and the steps which customers and suppliers (and those advising them) can take to minimise the risk of project failure.
What is project failure?
Failure can take many forms. Whilst the most obvious is abandonment before completion, delivery does not always mean success. Delays are frequent, and often costly to one or both parties, but a delayed project will not necessarily be viewed as a failure.
A supplier may consider a project that is completed on time and on budget to be successful but if it does not deliver the projected business benefits the customer will have a different view.
Conversely, a customer may be happy with a project which is delivered late but generates benefits which exceed its expectations; the supplier will have a different view if its profit margin is eroded by the additional costs of delivery, especially if those costs include payment to the customer of liquidated damages in respect of the delays.
The success or failure of a project must be measured by what was expected as well as what (if anything) was delivered.
Reasons for failure
In considering some of the reasons for project failure set out below, we have allocated delay factors equally between customer and supplier, with joint responsibility for others. In reality, the position is rarely straightforward. When a project is going wrong, delay factors combine, and fault is not easily determined. A cause which we attribute to one party may have been triggered by an act or omission of the other.
(A)The customer is to blame
1. The customer does not know what it wants or how the IT system will meet its objectives
The customer will have its reasons for requiring a new IT system. Its business may be diversifying into new areas. It may need to update to maintain its market position. Whatever the reason, the desire for a new system will be driven by the needs of its business. It may know what it wants to achieve from a business perspective but not the details of technical implementation required to achieve its objectives; how and over what timescale the benefits can be realised; or how they are to be measured.
A competitive tender process should help the customer establish what can be achieved within its budget but often the system requirements necessary to meet the business objectives will not be fully determined until the supplier has been selected. It is important for the customer to make sure that the capabilities and constraints of the system which it commissions are aligned with its business case and projections of benefits.
The customer should ensure at the outset that it has a clear vision, a focus on achievement of business outcomes and a route to delivery that is compelling and rigorous. If requirements agreed at the outset are later found to be at odds with the needs of the business, or the system is incapable of achieving the outcomes, major project and contractual change may be needed during the delivery phase. A customer in that position should act quickly, re-visiting the requirements and scope. An independent review of the programme to date may assist, especially if the change has a commercial impact on the parties.
2. The change is too great (or too small)
A new IT project is often part of a wider programme, perhaps involving changes to business models and the roles and responsibilities of employees. Such a project is difficult to mobilise and sustain, requires significant commitment and frequently gives rise to unwelcome surprises.
However, avoiding change can bring its own problems and may result in a business losing market share to competitors. That could result in reactive change, often at greater expense and disruption than would be the case if the programme had been actively driven.
In a transformation project, managing the business change will often be the responsibility of the customer. The customer must ensure that it is managed competently. Clear communications will be needed concerning the reasons for change and the benefits, both to the business and at an individual level to those whose day to day activities will be affected. The customer needs to ensure that the business change is aligned and co-ordinated with the technical development led by the supplier. The supplier can assist by devoting resource to the management of dependencies so that the customer is assisted in planning these and their provision is tracked.
3. Customer stakeholders may have differing objectives and hopes for the system
Individuals within the customer’s business will have differing aspirations for the new IT system. Management will be focused on the benefits which the system will deliver to the business and the price at which they will be realised. The procurement team will want to ensure that the due diligence and evaluation carried out during the procurement result in the appointment of the right supplier on good commercial terms. The delivery team will work with the supplier to ensure that the system is delivered on time and budget, insofar as possible. The day to day users will want a system that makes their work more productive. They may be resistant to a system which appears to be more complex than the outgoing system unless the benefits to them are clear.
The customer must balance the interests of the stakeholders in a careful and sensitive manner particularly where the programme involves changes in the roles of the users. Management should engage representatives of all stakeholders in communicating the vision.
4. Data quality failures
Data migration is one of the thankless areas of systems delivery. Customers have a role in providing and cleansing their data. It is easy to under-estimate the problems this can cause. The quantities of data accumulated over years in ancient and incompatible systems can be considerable. Many legacy systems may hold similar fields with inconsistent content. Fields may also be incompletely or inaccurately populated.
It is common to find the risks associated with data quality captured in programme registers. Less common is timely and appropriate action to address them. A system without data is of no business benefit.
The customer must first map the data required; then assess the current data quality; cleanse the data; and, finally, implement the migration. The effective performance is greatly aided by the appointment of experienced and qualified staff.
5. The customer changes its mind
A new IT system may take many months to deliver and requires not just the commitment of customer resources but the patience of executives. This can be strained if there is a change in the composition of the management team or the business approach, or if changes in market conditions or other external factors impact the perceived benefits of the new system. A downturn in economic activity may cause customers to scale down the scope of a system under development to reduce the cost, or to try to find a way to cancel the project altogether.
The rate of change of technology is also a factor. A system which was best of breed when commissioned may be overtaken by competitors by the time it is delivered. If a customer senses that the system under development no longer meets the business case or is otherwise less attractive than when commissioned, it may look for ways to cancel the project.
(B) The supplier is to blame
1. The supplier overpromises
Responding to a Request for Proposal for a complex project requires careful planning. The customer will expect the supplier to analyse its needs and estimate the cost and time for delivery.
Seasoned suppliers (and those advising them) will be only too aware of the possibility of a customer blaming the failure of a project on the supplier underestimating the work involved during the tender process, and in particular the risk of an allegation that the supplier deliberately misrepresented its capabilities and experience in order to secure the contract.
When responding to an invitation to tender, a supplier should carry out appropriate due diligence; check that its estimates of time, cost and resources are robust and well documented; and ensure that it can stand by the assurances it has provided to the customer. Questions asked by the customer should be considered and answered carefully, with appropriate caveats and statements of assumption. Where supplier performance depends on customer or third party action, the dependencies should be clearly articulated.
Evidence of a diligent approach and open engagement will be valuable in refuting allegations that the supplier acted dishonestly during the tender process and, had not it done so, the customer would have selected another supplier.
2. Wrong Consortium Members
A complex IT project may involve several technologies with one systems integrator taking overall responsibility for delivery, supported by consortium partners and sub-contractors. It is the responsibility of the systems integrator to ensure the partners work together effectively. If it fails to achieve this, the customer will suffer and will look to the supplier for recompense.
A supplier should choose its consortium partners carefully, undertaking due diligence and following up references. This is particularly important if a consortium member has been recommended by the customer. A supplier should be prepared for challenges in managing a consortium member which has a strong existing relationship with the customer.
The customer is also part of the delivery consortium. The supplier should satisfy itself that the customer is capable of fulfilling its responsibilities under the contract, which should be clearly defined and understood.
3. Wrong technologies
Many IT projects involve the integration of a core technology with the customer’s existing IT systems. The core application may be specified in the RFP or the supplier may be required to make recommendations.
If the RFP specifies the technology, the supplier should nonetheless consider whether that product is suitable to achieve the customer’s objectives and suggest alternatives if appropriate. If the customer sticks with its chosen technology, the supplier will have to consider the risks of progressing the development. It may elect to qualify out of the tender.
If the technology is not specified, the supplier will need to consider what will constitute a good fit between business need and available technology. One of the most important decisions will be whether to develop a custom-built or deploy an out-of-the-box solution. This has profound implications for the project approach; cost; speed and the degree of change required in the customer’s organisation.
It can appear to a customer to be an easy choice to adopt an industry-standard process and technology. Whilst this may be so, the need for the customer to provide clear requirements of the configuration and business change and accept the limitations of an out-of-the-box solution are difficult for many and impossible for some. Should a programme start as out-of-the-box and slide into custom, the project will be very difficult to keep on track. Starting with a custom-built system can also have its drawbacks. It can be expensive, with the uncertainty of commitment to a solution which is not market-tested. The importance of the decision should not be under-estimated.
4. Poor project management
In large programmes there are many dependencies. Uncertainty is amplified by the degree of novelty of the project, whether technological, business model or associated with people change. Project and programme management are critical skills with a direct impact on performance.
The customer will have a delivery team and project manager but the responsibility for delivery of the technology project will lie with the supplier and its project manager. A supplier should ensure it appoints a project manager with experience and skills which are equal to the task in hand. An experienced project manager with a strong track record will be able to identify risks and issues as the project progresses and recommend an appropriate approach. This needs to be supported by good quality data received on time throughout delivery.
The project manager should be supported by an effective delivery team with an appropriate mix of skill, enthusiasm and experience. The project manager will need to start by developing an effective plan and approach. During delivery this must be tracked and reported. There are close relationships to governance, addressed later.
Whilst there may be attention on planning and reporting, of equal influence on the outcomes of the project are the quality of risk and issue management.
5. Failure to manage the customer
A supplier will want a satisfied customer and will strive to meet the customer’s expectations. However, acquiescence with unreasonable demands or uncontrolled change can give rise to serious problems. A programme manager will expend considerable energy in engaging and managing senior customer stakeholders.
The supplier should ensure that the customer provides the necessary resources to make the project a success. It should insist on customer attendance at governance and review meetings and engagement at the appropriate level. If the customer requires changes to the delivery, the supplier should ensure that such change is managed through the change control mechanism and that the customer does not expect the supplier to perform outside its contractual commitments.1
(C) Both parties are at fault
1. The customer appoints the wrong supplier/the supplier takes on the wrong sort of work
The parties should work towards an arrangement which is productive for both and will deliver a successful outcome.
The customer’s procurement team should approach the supplier selection process responsibly. Responses from the bidders should be evaluated on their merits, setting aside pre-conceptions. The customer must determine which proposal is most appropriate by reference to well-considered assessment criteria. It should be confident that the supplier has the necessary competence and experience in all critical aspects of delivery.
Default options (whether to the large well-regarded supplier or to the lowest bidder) can often be unsuitable. Appointing the lowest bidder may result in greater change costs as the project progresses.
The supplier should also exercise scrutiny during the tender process, ensuring there is a good fit between its capabilities, as supplemented by consortium partners, and the customer’s desired outcome. It should take care not to expose itself to the risks associated with heavy dependence on a sub-contractor without assurance that the sub-contractor can deliver. It should ensure that the profit margin is satisfactory, with adequate contingency. If it sees its profit ebbing away during delivery, relations will become strained, with adverse impact on delivery.
2. Requirements not adequately defined
The requirements of the new system are generally not specified to a level of detail to allow development until after the supplier has been selected.
During contract negotiations, the supplier and customer together need to build their understanding of features, performance, and outcomes and ensure that these are reflected in the contract. The requirements definition phase then elaborates the detail of process and design to build the result that the customer expects. If these two exercises are not carried out well, the business outcomes will not be captured.
Whichever party bears the contractual responsibility for defining the requirements, both play vital roles. The customer (or its appointed consultant) needs to articulate the objectives of the business, its constraints, the way it wants to configure and use the technology, data, business rules and processes. The supplier needs to ensure those are properly reflected in the requirements and subsequent design documentation. Where the solution is based on out-of-the-box functionality, the supplier will need to explain the constraints and help the customer to exploit what exists rather than expensively build anew.
Both parties need to commit effort and resources to this process and ensure that the requirements set them on a course to deliver a workable solution in line with the customer’s desired outcome and the capabilities of the technology. Failure to engage properly in this process is a common reason for project failure. Inadequately defined requirements can lead to scope creep and delay, along with management time and cost to deal with disputes and change to the delivery.
3. Unstable delivery team
A frequent cause of strain arises from one or both parties failing to commit the resources necessary for delivery.
The customer should recognise that on a lengthy project there may be changes in the supplier’s delivery team. However, frequent changes, can cause serious disruption, resulting in delay and compromising the quality of delivery. A complex project relies on knowledge of the development and personal relationships which take time to establish and can be easily lost. As far as possible, the supplier should maintain continuity of resource and resist the temptation to re-assign skilled and experienced resources to other projects. It should ensure that key personnel are engaged and supported.
The customer must also recognise the importance of committing key individuals to the delivery of the project. Constant changes to the customer’s project team can be just as disruptive to the delivery of the project as instability in the supplier’s delivery team. This is most marked when the incoming personnel do not have background knowledge of the customer’s business and the objectives of the project.
4. Poor project governance
The parties should work together to ensure the project is effectively governed, holding each other to account for delivery. This governance includes tracking performance against plan; the continual assessment and management of risk; the management of change; the maintenance of interest and commitment by the customer sponsors; decision-making and direction. Effective scrutiny is associated with project success. Micro-management is not. A balance must be struck between the desire for scrutiny as a proxy for control, and the detrimental impact of burdening the delivery team with excessive reporting.
A customer may consider that the control of the project should lie with the supplier and that such commitment is priced into the contract. However, the customer’s programme sponsor should have close involvement in the process, even if such involvement is seen in periodic attendance at high-level governance meetings.
Effective governance is crucial for the delivery of a project. Ineffective governance can lead to a project quickly spiralling out of control with a corrosive effect on the relationship between the parties. This causes lasting difficulties even if the timetable for delivery is rescheduled.
Anticipating and navigating the pitfalls
Even the most effectively managed project can experience serious problems during the delivery phase, leading to changes in scope, delay and cost overrun. Awareness of the reasons for project failure and experience of past mistakes provide opportunities for customers and suppliers to set the project on a good course from the outset. However, it should be recognised that no customer or supplier will set out to fail and even detailed assessment of the risks may not anticipate all challenges which the project will have to overcome.
We set out below a number of points that the parties should have in mind during the procurement, contracting and delivery stages to put them in the best position to avoid some of the more serious issues and manage problems as and when they arise.
- The Customer’s business case should set out a well-articulated vision of what it wants to achieve from the new system prior to the commencement of the procurement process. It should refer to that business case throughout procurement and delivery (updating as appropriate) to ensure the development is on track to fulfil its objectives.
- The Customer should approach the procurement thoroughly prepared. It should assess the range of options and follow a robust system of evaluation. It should respond to questions put to it by bidders so that they can understand what it wants to achieve. If potential suppliers express concern about aspects of the project, those should be considered and addressed as appropriate.
- The supplier should ask questions and explore risks during the procurement. If assumptions or caveats are appropriate, the supplier should state them. Most importantly, all estimates and representations of its capabilities should be well founded and properly documented.
- Both parties should scrutinise and negotiate the contract, scope and plan. The contract should document the parties’ responsibilities; set out the governance processes to be followed; and contain a workable dispute resolution procedure to facilitate the timely management of minor disagreements which may be encountered during delivery.
- Both customer and supplier should engage in requirements capture and review. The supplier should form a deep understanding of its approach and plan to meet the customer’s needs. The customer should understand the constraints of the technology to be deployed, the impact these have and the dependencies on its own actions.
- Both parties should commit sufficient resources with the appropriate skills and experience. Continuity of resource should be maintained. Project management and governance should be rigorous with a culture of intelligent compliance.
- Workstreams should be complementary and co-ordinated, with effective engagement of those responsible across the workstreams. In transformation projects, change management should be aligned with technical delivery to ensure the fit between the new business model and the technology to be deployed.
- The customer’s senior management should communicate the importance of the project and the benefits which it will bring to the business and all associated with it. Senior management must be prepared to stay the distance, recognising there will be bumps in the road.
- Design and contract change should be effectively managed and follow the processes stipulated in the contract. The customer should articulate the changes it requires clearly and give the supplier time to assess the impact of those changes. The customer should recognise that change comes at a cost and could impact the timescale for delivery.
- Minor disputes should be resolved decisively, minimising the risk of misunderstanding and damage to relationships. The contractual dispute resolution procedures should be followed. The parties should work together, maintaining good relations even during difficult times in the knowledge that they will share the success of the project.
Notes
[1] For a deeper exploration of these aspects, see SCL Tech Law Essentials Module: “Programme and Project Management”
Lee Gluyas is a partner at CMS who specialises in managing disputes in the technology and telecoms sector. He is a member of the Society of Computers and Law and can be contacted on +44 20 7524 6283 and lee.gluyas@cms-cmno.com
William Hooper acts as an expert witness in IT and Outsourcing disputes and a consultant in service delivery. He is a member of the Society of Computers and Law and a director of Oareborough Consulting. He may be reached on +44 7909 958274 or William@Oareborough.com
