In the first of a two-part series, Gerard Doolin, founder of a specialised software and services advisory offering, Be Amorgos IT Contractual Services, makes the case for software project contracting to recognise certain inherent risks in supplier and customer engagement.
Gerard, is a specialised software projects disputes CEDR accredited Mediator on the Mediators panel for NZIAC and an advisory board provider and member of Advisory Board Centre.
He believes project contracts relating to software and digital transformation should build in a sequence of tailored conflict avoidance or dispute resolution processes which could help increase project success rates.
The design, build and implementation of software solutions viewed across the swathe of history is still arguably in its adolescent phase. 50 years of rapid conceptual and delivery evolution seems dwarfed by the first large physical structure designed and built in 2700 BC being a pyramid.
Electronic and physical construction both rely on quality of planning, delivery, and management. However, it seems that stakeholders over time and with experience and refinement deliver better outcomes in the physical than the electronic world.
This conundrum is evidenced by the modest global success rates of software project implementation. The Boston based Standish Group has published periodically from 1995 to 2022 the Chaos Reports focused on a very large pool of global software projects and assessing them against sophisticated failure/success metrics. In its last report they determined that about 35% of projects were deemed successful being completed on time, on budget, and with satisfactory functionality implemented, with 46% challenged, and 19% failed. The Standish Group has also over these decades, through its outstanding industry leadership, set out key subject areas that, if executed well, promote supplier and customer good outcomes.
With the impact of the pandemic and remote workforce demand coinciding with the last decade or so of endless acceleration of cloud delivered business and service models, particularly via the smart phone, there is an all-prevailing focus on accelerated and successful digital transformation projects.
Industry abounds with effort and focus on procurement solution requirements optimisation (including via software automation) and rapidly evolving software development methods, all to de risk software procurement, design, build and implementation.
International research and consultation
For over 20 years internationally (including for the former EDS Group and the Accenture Group) in generally complex software and services enterprise engagement, II have intervened in failing software projects to renegotiate and assist the reset of project and contractual relationships. There’s a distinct relationship fatigue and entangled causes of misalignment that make renegotiation arduous and often seeming too late.
As a result, I came to the view that some form of early alternate intervention by external skilled professionals promoting and enabling project misalignment resolution needed to be built into the contract from outset.
To test this, I consulted with industry to scope and test various perspectives. This was done via a partnership with New Zealand’s leading dispute resolution design and services provider NZDRC and NZIAC.
Detailed quantitative and qualitative research survey was undertaken focusing on all software project phases. It sought views on material causes of misalignment, behaviours observed, and experiences including when a contract dispute crystallises, and dispute resolution methods used.
Over 50 senior industry software project stakeholders in eight countries – New Zealand, Australia, China, Singapore, United Kingdom, Germany, Italy, and the US-responded.
The rich data was set out in a Report published by NZIAC “Avoiding conflict –improved dispute resolution for IT Projects.”
Key Findings
Project procurement and delivery:
- Software project misalignment occurrence – usually after contract signing and during key delivery phases (e.g., further requirements analysis, design or build).
- Software project misalignment material causes or contributors include:
- Completeness of customer business case -budget constraints and haste to attain targets by project sponsors can mean understanding true transformational scope (from current state to future state), user needs, optimal solution selection, and desired business objectives are incomplete or inadequate;
- Customer internal requirements scope -inadequate analysis of user needs and redesign scope due to lack of coordination and planning by key stakeholders;
- Absent or inadequate discovery between customer and supplier to baseline mutual understandings between known requirements scope and to be discovered transformation scope and risk and cost associated with the latter;
- Overambitious project scheduling;
- Resourcing performance quality and capacity –planning and execution.
- Agile, Waterfall and hybrid development methods: While Agile de-risks and improves software project outcomes for smaller or medium sized projects, all stakeholders need better understanding, role training, agreement on budget, priority requirements and the scale of sprints. For complex deployments, waterfall or a hybrid method remains preferred.
- Change control: Problematic leading to disagreement as to what is in scope for an agreed change and what is not (i.e. new scope)
- Governance: Strong consensus that governance engagement (motivated, informed re context and deliverables) and experience level (communication, leading, resolving, guiding and ensuring correct and satisfactory business outcomes) are critical to project success. Noted also was that problems are compounded by failure to escalate, or, when escalated, poor contribution due to inadequate or misleading information.
- Measuring success: The “Iron triangle measurement era” (project outcome meets agreed fixed cost, requirements, and timetable) is passing. There is a need for active and competent leadership that drives, and monitors coordinated consistent agreed and refined success metrics fit for context.
Contracting
Project delivery can often deviate from rigid contract terms arising from negotiation and their expression. This is then linked to similarly rigid and sometimes contested change control terms seeking to deal with new or unforeseen circumstances. Consensus that project contract terms should have some flexibility to address project journey.
Emerging contract disputes
When a dispute occurs, often there is often a lack of awareness that a project misalignment or contract dispute is emerging, and once known, the parties often show positional and conflict orientated behaviours.
Dispute resolution
In the main re-negotiation is preferred and on occasions mediation. These delivered satisfactory outcomes but need to be used as early as possible when trust and respect (absent power leveraging) are still present. The advisor or mediator needed to exhibit analytical and facilitative skills to unlock entrenched positions. Litigation was viewed negatively, it being fault based, cost intensive and relationship ending.
So where to from here?
The findings highlighted for software project endeavour there is a material risk of decisions, behaviours, and actions and unknown factors that may lead to software project misalignment and emerging contract disputes, despite best efforts to document mutual contract understandings as to requirements, financials, and delivery performance scope. This leads to a perspective on contracting.
For material software project contract terms, they comprise two categories. The first is key as it captures (usually set out in a schedule or statement of work to the Framework (per below)) the specific project context (e.g., software solution, development and implementation scope, specific dependencies, assumptions, performance criteria and risks etc), and, when supported by lawyers, who understand technically such context, it has primacy in my view in baselining understandings.
The other category that in my view often disproportionately adds rigidity in the relationship are the Master services terms (a “Framework”). The Framework includes terms focused on failure or fault and consequence for the breaching party. These include failure definitions and decisive remedies such as a notice to terminate. Then there are related terms concerning financial damages recovery, whether locked in liquidated damages (negotiated pre-determined amounts) when a deliverable is not achieved by an agreed date or other damages as to those what types are recoverable and how much a party can claim via legal proceedings or an indemnity (a promise to pay on demand) when a failure or breach event occurs.
Finally, there will be terms for how a contract dispute is managed. Once a party formally initiates a dispute process the first phase is further negotiation by the parties. However, if this remains deadlocked, sometimes the agreed next phase is to engage a generalist mediator (usually not a specialist in the software and services category) to assist in more negotiation, or, otherwise, it is a costly complex journey (conflict, costs, lost time, and personnel impacts including morale and mental health, potential brand damage etc) to a judge or arbitrator who will rule on fault and damages. Usually, once court or arbitration proceedings are in flight, the project will have ended incomplete.
What is problematic with these Framework terms are that they do not necessarily consider the exploration, risk and greyness inherent in software project endeavour- it is not a black and white set of expectations. These terms are somewhat binary and focused on substantiating fault and consequences by enforcement actions.
In Part 2, next week we will look at the contract process designed to address the software project journey and build in review and intervention processes that aim to take supplier and customer off the escalating conflict path and back to the road to success.
