As a software contract advisor and project manager, I regrettably witness failures and obstacles that can greatly affect both the Client and the software vendor. The Client does not receive the anticipated business value from the software, while the software vendors fail to generate the expected revenue. Consequently, certain contracts end up being detrimental for all parties involved.
One of the most common failures in software contracts is very simple to correct. The project starts too quickly without taking the time to do a retrospective of the contract agreement from a delivery perspective rather than the contractual and commercial perspective.
And at the end – whatever time we felt we gained at the beginning of the project, we will lose when we try to complete and close the contract. We will have endless discussions about interpreting the original requirements in the contract – even though they were written several years before and none in the business area or development team was part of the contract negotiation or creation.
Here are some suggestions on how to address these challenges:
Clear Communication and Collaboration: Start by emphasizing the importance of clear communication and collaboration between all parties involved. Create a space for regular meetings where teams can openly discuss their understanding of the requirements, ask questions, and seek clarifications. This will help prevent misunderstandings from arising in the first place.
Requirement Traceability: Implement a robust requirement traceability process. Document requirements in a clear and standardized manner and establish tools that allow you to trace each requirement from its origin through development to testing and deployment. This can help ensure that the final product aligns with the initial requirements and minimizes the need for extensive changes.
Review all requirements: As a team – review all requirements and make sure that the understanding of the requirements is the same. Agree on a process to break epic requirements into a tangible user story. Make sure to prioritize and assess the business criticality of the requirements. Function Point Analysis can assist you in this process and, at the same time, ensure that tracing of scope changes and scope creep can be quantified.
Test-Driven Development: Encourage a test-driven development approach where test cases are defined before development begins. This can help ensure that the developed functionality meets the specified requirements and reduces the need for significant changes later.
Iterative Development and Feedback: Promote an iterative development process where smaller increments of functionality are developed and tested in cycles. This allows for continuous feedback and adjustments, reducing the risk of major deviations from the contract requirements.
Change Management: Clearly define a change management process within the contract. Outline how changes will be documented, assessed for impact on staff, duration, cost, or price, and approved. A structured process can help prevent disputes and confusion, and when necessary, changes occur. It is even better if the change management process includes an agreed price per unit (such as Function Points).
Regular Reviews and Reflection: Schedule regular reviews throughout the project to reflect on progress and challenges. This provides an opportunity to assess whether the project is on track, whether any adjustments are needed, and whether lessons can be learned for future iterations.
Document Historical Context: Even if team members weren’t part of the contract negotiation or creation, it’s important to document the historical context of the project and its requirements. This can help new team members understand the rationale behind certain decisions and interpretations.
Continuous Learning and Improvement: Embrace a continuous learning and improvement culture. After each phase, sprint, or whatever is right for you, conduct a post-mortem analysis to identify what worked well and what could be improved. This is a shared learning by all team members and should be used to gain insights and refine your processes and approaches. At the end of the project, it should be prioritized to ensure that any lessons learned can be best practices for future contracts. Just like starting too quickly is an issue – ending too fast means not learning from mistakes and what was excellent.
Education and Training: Provide training and resources for your teams regarding contract interpretation, requirement management, and change management. Building a shared understanding of these concepts can lead to smoother execution.
In most of my projects, I use a Hybrid development lifecycle to ensure that we both manage the contract and meet all the above criteria. When creating a Go2Green plan for a challenging project, my first step is always to investigate if we have all the above criteria met, and I have to date never experienced that it was.
I advise all leadership and sales resources working on software contracts to involve relevant stakeholders from the business area and the development team in the contract negotiation and creation process. Their input can lead to more accurate and realistic requirements that align with business needs and technical capabilities.
By implementing these strategies, you can mitigate misunderstandings, improve requirement traceability, reduce the need for extensive changes, and create a more collaborative and effective environment for managing software contracts.
Your project might be the project that will succeed in delivering value to the business with only a few deviations from the original plan. Why only a few deviations, you might ask – because if there are no changes to the original plan, that would mean we did not get wiser during the time it took us to deliver. And hopefully, any software project will deliver more business value than expected.
Thank you for reading this article – Christine Green, IPbyGreen