The NZ CIO’s path to ‘unlock, resolve, reset’ a misaligned software project

The ongoing shift to the ‘as a service environment’ heightens the need to mitigate risks to ensure successful delivery of software projects, says Gerard Doolin, a New Zealand-trained lawyer and IT software project disputes mediator.

In this Q&A with CIO New Zealand, he delves into the results of a recent survey among CIOs and other C-suite executives on the current challenges facing both organisations and technology providers in the delivery of software project contracts. 

CIO New Zealand

He then talks about how performance risks can be mitigated, and successful outcomes promoted through what he describes as an ‘unlock, resolve, reset’ approach.

CIO New Zealand: You have experience working in ICT-related contracts for over 20 years and pointed out that recent changes in the industry need to be factored in as organisations enter into contracts with software providers. What are these shifts?

In the last decade, with the rapid evolution of software-based capabilities, organisations increasingly plan and seek employee or customer user experience transformation through the successful procurement, delivery, and management of software solutions. 

Indeed, the COVID-19 crisis saw the need for employees, customers, or other users to access software systems from home. So, along with peak demand network capacity, the deployment quality and resilience of software solutions delivered ‘as a service’ is more critical than ever. 

However achieving the goals of software delivery are problematic, as shown by industry statistics. For example, the US-based Standish Consultancy Group, in its 2015 Global Chaos report, surveyed 50,000 software projects globally. It determined that only 29 per cent of IT projects were successful as to time, budget, and satisfactory functionality. 

What accounts for this underwhelming success rate? 

It is useful to remember that in the case of software solutions, their commercial design, build, and delivery is only about 50 years old.

In contrast, the design, build, and delivery of physical buildings is about 4000 years old. The oldest recognised building is the Pyramid of Djoser in Egypt that was designed and built in 2700BC. 

Arguably, electronic and physical construction have common key elements. They are both dependent on the quality of planning, delivery, and management based on human engagement. However it seems that stakeholders over time and with experience, knowledge, and refinement, have delivered better outcomes in physical building delivery than in software solution delivery. 

So why the disparity in outcomes between software and physical projects?

A customer and supplier begin a software project with procurement and then generally agree on requirements, financials, and delivery performance scope in a contract. 

The contract, often robustly negotiated, sets out a mutual understanding at that time of performance obligations: What each party must do and to what standard and timeframe and rights.

When a software project becomes misaligned and failing, there is always, if there is willingness, a path for the parties themselves to commercially renegotiate and reset the software project. 

Parties, however, also review their legal obligations and rights. Where the misalignment or dispute is material, and there is no commercial resolution by project managers or C-level execs, conflict usually escalates. 

This can lead to resolving the dispute by terminating the contract and project, pursuing financial claims via arbitration or litigation, where the fault is determined by an arbitrator or a judge. These paths mean more conflict, costs, lost time, and personnel impacts including morale and mental health, potential brand damage. It usually ends the commercial relationship.

Given these circumstances, we ask, are there other paths to resolve a software project misalignment and contract dispute that preserves a commercial relationship and resets the software project progression?

A recent survey I was involved in with the New Zealand International Arbitration Centre focused on this. 

What was the scope of the survey and were there respondents from NZ?

We interviewed 50 senior industry software project stakeholders in eight countries – New Zealand, Australia, China, Singapore, United Kingdom, Germany, Italy, and the US. Respondents were CEOs, CIOs, programme or project managers, sales leads, chief legal officers and external lawyers, and other C-suite executives with extensive project experience, customer, or supply side in key verticals such as finance, retail, and utilities.

The survey focused on all project phases. We asked them quantitative and qualitative questions around key activities for each phase and where the misalignment occurred. What caused the misalignment? Was it a primary or contributory reason for the contract dispute? 

From these, we asked about behaviours observed when a contract dispute emerges and the dispute resolution methods used. We then distilled key findings and recommendations from this data.

We found that software project misalignment emerges usually after contract signing and during key delivery phases (such as requirements analysis, design or build).

The main causes are: 

Preparing the business case: Due to budget constraints and expeditious target business outcomes of a project sponsor, there is often a lack of time spent in fully understanding transformational scope (from current state to future state), user needs, optimal solution selection, and desired business objectives. 

Scoping of internal requirements: There were inadequate analyses of user needs and redesign scope due to lack of coordination and planning for key contributors and customer personnel.

When these occur, solution delivery failure becomes likely with the selected supplier. From this, a contract dispute can follow. During the delivery, we noted misalignment and inadequacies in scheduling of projects. These were often overambitious. 

The survey insights further noted gaps in resource capacity planning, scoping of roles, and quality of performance. The customer and the supplier both need to clearly scope the roles and expected outputs from customer and supplier personnel. We all know of problems with continuity and quality of work when this is not done well. 

The survey looked at agile and waterfall development methods that are used in software projects. We found cautious optimism among the respondents. They find the agile process de-risks and improves software project outcomes for smaller or medium sized projects. 

However for agile, all stakeholders need better understanding and training for the relevant roles. Both the customer and supplier need better understanding and agreement on budget, priority requirements, and the scale of sprints. For complex deployments, the respondents prefer the waterfall approach or the use of hybrid agile and waterfall methods.

Given these findings, how should enterprises approach contracts around software deployments?

First, we should change how success is measured in these projects. The survey finds that there is often a reliance on the limited traditional ‘iron triangle measure’ of compliance. That is, project outcome meets agreed fixed cost, requirements, and timetable.

A better approach is based on active and competent leadership and engagement, and a focus on coordinated, clear, and consistently mutually reviewed and refined success metrics. 

As the CIO of a major NZ enterprise commented, ‘A lack of effective leadership and governance means a significant risk and realisation of misalignment across the entire lifecycle…what is required is to manage an outcome that is clearly defined and to be accountable to that outcome.’

Secondly, the survey respondents said that a software project delivery often deviates from the agreed contract terms, and the contract terms are too rigidly negotiated. Often, rigid and contested change control procedures are the only process to deal with new or unforeseen circumstances that are discovered by a customer or supplier. 

Finally, most survey respondents believe that a software project contract terms should have some flexibility to address these circumstances.

Could you summarise what these proposed contract terms or processes are?

We must keep in mind that IT software project costs accumulate for a customer organisation from the moment it considers change and engages potential suppliers. 

As the survey revealed, usually the delivery is well in flight when IT software project misalignment is discovered and leads to a contract dispute.

At this moment, key stakeholders usually have multiple demands on their time. Turning their minds to conflict and its resolution is not desirable. Sometimes there is limited understanding of key information, and with a range of accountability pressures, the ability to stand back, unlock, resolve and reset can be challenging. 

One of the main recommendations of the survey report is to include into the contract a customised dispute resolution process that permits ‘a time out delivery review’. It supports the customer and supplier using a skilled neutral accredited mediator on an expedited time frame to resolve the dispute. 

It must be clear that in following this process, the customer or supplier will not make any concessions on their starting positions. These include the right to terminate the contract and seek compensation. The mediation enables the customer or the supplier to talk in confidence with the mediator about the problem and explore new ways of looking at it.

If the mediation succeeds, a revised agreement may be reached, and the project may progress. To set this up, both parties will have to agree to projected mediation costs

It is interesting to consider whether IT software projects that led to legal disputes and massive costs across NZ over the past decade could have benefitted from this ‘time out process’, especially at the earliest time the ‘misalignment’ occurred.

In these challenging times, as firms reconfigure their software delivery for the cloud and remote users, the ‘unlock, resolve, reset’ approach is a new, but very critical tool, for business continuity.