In our previous blogpost (link below) we considered the High Court judgment, and the importance of defining the scope of the respective obligations of both the customer and the service provider. In this post, we deal with some of the lessons we can learn from the parties' failed software development project when it comes to managing configuration and customisation.
The facts
Markit Systems is a software development house in the United Kingdom and the Fulcrum Group is a South African financial services provider in the insurance industry.
Fulcrum had a legacy system that it wanted to replace and concluded a "technology agreement" with Markit to do so. Markit had represented it that helped two other companies in South Africa with similar solutions and accordingly that they could leverage the existing technology they had developed, and the knowledge previously gained. This should typically reduce the cost and time to bring the new solution to market.
The agreement provided that the project must be executed in phases in accordance with a detailed project plan. The agreement further provided that once Markit had analysed and documented Fulcrum’s business requirements, both parties shall jointly agree on a business requirements document (sometimes referred to a "blueprint"). If the parties "failed" to agree on the blueprint, either could cancel the agreement on notice to the other.
Fulcrum had agreed to retain the services of a "business analyst" to assist in the creation of the blueprint.
The judgment of the court of first instance and on appeal deals in a fair amount of detail with how the software development project unfolded. I am not going to rehash that here, but highlight key events from my perspective:
- Progress was slow and at times there was friction between the parties.
- Agreeing on the blueprint proved difficult and it was ultimately proposed by Markit that the parties move to a "waterfall" project management approach where there would be multiple blueprints, and not one. Markit argued that this would allow the development work to proceed, despite the fact that all aspects of the blueprint had not been completed. Apparently, this approach would be more "agile"…
- Fulcrum had various reservations about how the project was unfolding but did not communicate all of them. It proceeded to pay significant amounts to Markit, some of which appeared to be paid prematurely on a strict reading of the agreement.
- To give Fulcrum comfort that work was being done, Markit presented a demonstration of the technology they had been working on, but Fulcrum was underwhelmed by this, as it appeared to be previous work not customised for the current project.
- The project reached a point where a breach of trust occurred and Fulcrum sough to exit from the agreement, relying on their right of cancellation due to the blueprint not having been agreed.
- Markit alleged that Fulcrum was not entitled to cancel and alleged that they had repudiated the agreement by not honouring its terms. The argument was advanced that Fulcrum should not be allowed to rely on their own breach in exercising the right to cancel, notably because they have not provided Markit with the required support and failed to timeously appoint a dedicated business analyst, only doing so three months before the notice of cancellation.
The judgment
On appeal, the Court substantially upheld the verdict from the court of first instance, namely that while both parties may have been at fault, the language of the contract clearly required that Markit should take the lead in developing the blueprint. Factually the parties had "failed" to agree on the blueprint and the exercise of the right to cancel was not premature.
Markit was also not able to convince the Court that significant software development specific to the Fulcrum project had taken place.
The Court ordered that Fulcrum were able to recover all amounts paid.
Observations
Many software agreements nowadays require the customer and vendor to agree on a blueprint. The blueprint is intended to map the requirements of the business to the technology at hand, so that that is the required level of effort to be put into configuration and customisation is agreed. Broadly speaking, configuration is a matter of adjusting settings or configurations of an existing mature technology to fit the required use case, while customisation on the other hand entails new software development, which is much more involved. The difference is important, as it has significant impact on the cost and timeline to commission a mature technology solution in a production environment.
The following are useful takeaways from this judgement that can help manage the risks arising from software development projects that require a blueprinting phase.
- Specify the requirements of the blueprint. A blueprint must be adequately detailed to show the functional and technical requirements of the build, as mapped to the technology at hand. The required level of configuration and customisation must be evident from the document. The agreement must clearly set out these requirements.
- Be clear about the party taking the lead in compiling the blueprint. The party with the onus to take the lead must drive the process and to actively manage delays. In the case discussed above, this was perhaps the single most important point in favour of Fulcrum.
- Be clear on the assistance required. The party taking the lead in the compilation of the blueprint must be clear in the support that it needs to complete the job. Consider going further than the general language usually contained in technology services agreements to include specific actions and timeframes.
- Negotiate the right to cancel if a blueprint cannot be agreed upon. If you are the customer, make sure you can achieve a clean break if the blueprint cannot be agreed upon. If you are the vendor, make sure the right cannot be exercised on a no-fault basis, and if it can, make sure fees for work completed must remain payable.
- Never waive the right to cancellation if a blueprint cannot be agreed upon. If you are the customer, never be convinced to waive the right to cancel. Once you have done so and the development phase has commenced, there is typically no turning back and messy litigation is the only way out.
- Keep the agreement current. Make sure to diligently execute variation orders or addenda to the original agreement if the project goes off script. If the parties perform in a way that is not aligned with the agreement, a court is placed in a difficult position, which makes the outcome of any dispute resolution process uncertain.
- Make use of expert determination to resolve factual disputes. Provide that an independent expert will determine certain factual questions on an inquisitorial (not adversarial) basis. This is an efficient and cost-effective way to dispense with these types of disputes without the project derailing due to a year of arbitration or litigation.
- Expressly deal with the consequences of breach and termination. It can be difficult to apply the default legal rules pertaining to damages and restitution to unfinished software, so be express in the agreement as to the consequences of termination for various causes in the project lifecycle.
- Record failures on the part of the counterparty in writing. Ensure that any shortcomings or breaches on the part of the counterparty, as well as their impact or likely impact, are diligently recorded in minutes of steering committee meetings or otherwise in correspondence. This is especially important when it comes to project delays or failures to follow an agreed course of action.
- Record product or feature demos. It may be important to be able to show the progress of a build if the fact that the work had started or that certain progress had been made is disputed later. If the vendor is unable to show this, as was the case in the case discussed above, a court may come to an adverse conclusion.
Our previous blog post: https://www.swart.law/post.aspx?id=90