Part two | Managing disputes with troubled software projects

0

Gerard Doolin made the the case for software project contracting to recognise certain inherent risks in supplier and customer engagement in part one. 

He set out causes of software project misalignment and emerging contract dispute and highlighted the inherent exploration, risks and greyness in software project endeavour- it is not a black and white set of expectations

In part two, Gerard sets out the conflict avoidance or contract dispute resolution processes designed with NZIAC/NZDRC. 

Software project contracts should build in a sequence of tailored conflict avoidance or dispute resolution processes that maximise the opportunity to avoid fault crystallisation and recourse to termination and financial claims pursuit. 

Of course, there will be failed projects, where due to capital and time invested, depth of misalignment or failure, loss of confidence or trust, they are simply not recoverable. For such projects traditional legal claims and remedies via the courts or an arbitrator can be pursued.

Software project costs (e.g., personnel, board time) for a customer accumulate from the moment it considers change and begins to engage with potential suppliers. A supplier once engaged similarly incurs personnel costs. The procurement and contracting phases for complex projects are cost and time intensive. So usually by the delivery phases in a software project, when misalignment occurs or appears as an emerging contract dispute, the relationship is well advanced and sunken costs have been incurred. At this moment often key stakeholders have multiple demands. With a range of accountability pressures and varying understandings levels of cause within and across the organisations, the ability to stand back, unlock, resolve and reset can be challenging. 

With this context front of mind, we have designed: 

  • A conflict avoidance and dispute resolution service model based on easily adoptable “best for project” contract modules that can be blended into Agile or Waterfall software project contracts.
  • Recommended (editable for need) Agile project Governance terms and set conflict avoidance or dispute resolution terms (only to be varied where local law requires)
  • Recommended (editable for need) Waterfall project Governance terms and set conflict avoidance or dispute resolution terms (only to be varied where local law requires)

Conflict avoidance processes

  • Risk Event Notification– a clear obligation to promptly notify a party of a material software project delivery risk event. This then triggers expeditious and concerted efforts (project manager then executive levels) to self-solve the Risk Event (including agreement on actions, costs, monitoring and reporting)

  • Mediation – the right to seek facilitation assistance from an industry knowledgeable and experienced accredited mediator. Generally, in scope will be commercial and less complex technical issues

  • Adjudication (technical ruling) – the right to refer an issue, usually either a complex technical issue or a monetary assessment, to a qualified adjudicator to make a ruling. 

The Mediation and Adjudication to be conducted per applicable NZIAC rules and procedures.

  • Relief window – once the above processes are triggered there is agreed temporary relief from any sanctions such as liquidated damages accruing once a milestone is missed
  • Dispute resolution – in the event the dispute cannot be solved then parties can seek fault determination and financial compensation via arbitration (also conducted per NZIAC rules and procedures) 

What culture do we aspire to create

By adopting these conflict avoidance processes, at the earliest time in a project a misalignment or failure hatches, they create “a time out” for delivery review including via mediation a without prejudice re-exploration of issues and ideally an agreed reset. 

Which stakeholders do we seek to principally assist

The design and language have been carefully created to encourage adoption by risk mitigation managers (procurement or project or programme managers or executives) and not only directed at in house counsel or external lawyers who implement such terms into a contract. 

Case study 

In a recent major software project enterprise renegotiation, we introduced a tailored risk event notification and expedited resolution process (based on the Contract Modules) focused on specified key solution deliverable or milestone achievement (e.g., readiness for testing) and supported if needed by recourse to a neutral facilitator. 

Summary

The writer has also collaborated in recent years with an international leader in this field, Professor Hans Mulder from Antwerp Management School, IT expert and mediator, and long-standing European research lead for the Chaos Reports, on the matter of how to create conflict avoidance methods centred in software project governance.

While the Contract Modules contribute to such service models, NZIAC, myself and Professor Mulder share the view you should consider what is fit for purpose per scale and complexity of a software project- whether it is a mediator and/or an adjudicator or a dispute review board panel? and how they are engage e.g. on standby to assist when called or as otherwise structured?

About Author

mm

Gerard Doolin is the founder of a specialised software and services advisory offering, Be Amorgos IT Contractual Services, and a specialised software projects disputes CEDR accredited Mediator on the Mediators panel for NZIAC . He is also an advisory board provider and member of Advisory Board Centre.

Leave A Reply