Mitigate, Don’t Litigate: Why RAID Logs are Non-Negotiable in Contract Projects

How Neglecting RAID Puts Your Organization at Risk 

Large projects often involve contracts with vendors or subcontractors, and the success of these projects hinges on the effective execution of these agreements. For vendors, their entire business model may depend on contract success. 

Contracts outline terms and conditions, commitments, and obligations for all parties involved. However, misunderstandings, ambiguity, and failure to manage projects according to the agreement often lead to relationship issues, disputes, and even litigation. 

These failures can be very costly. While data on contract-related project failure and litigation is scarce, statistics on project failure illustrate the prevalence of issues that could put your organization in commercial jeopardy: 

• The Harvard Business Review found that 1 in 6 projects had a cost overrun of 200% or more ⁽¹⁾
• McKinsey found that 17% of large IT projects are so detrimental that they threaten the company’s existence ⁽²⁾ 

 

The Disconnect Between Contract Negotiation and Delivery 

The biggest challenge in delivering contracted projects is that the team negotiating the agreement is seldom the team that executes the agreement. The vendor’s account managers and the customer’s business / procurement teams may spend months carefully negotiating the contract’s assumptions, constraints, and deliverables. However, this process is imperfect and can leave ambiguities that confuse the delivery team. 

The delivery teams on both sides may have limited insights into the negotiations leading up to the contract. And they are not given weeks or months to come up to speed. They are left to review a lengthy legal document and extract their obligations for contract delivery quickly so they can begin executing the project. 

This poses a significant problem because contractual terms shape the project’s deliverables, design, governance, and execution. Without a clear understanding of the contract’s real and implied terms and conditions, the project team is bound to encounter substantial misunderstandings and issues. 

 

The Origin of RAID Logs 

In the 1980s and 1990s, the UK government undertook significant privatization and outsourcing of projects, exposing the risk of mismanaged contracts. The size and complexity of these contracts presented considerable financial risk to the contracting organizations, and political and operational risk to the agencies involved. 

To address this risk, a new tool was invented to:

• Capture all planning assumptions for validation 
• Document and track dependencies between contracted parties and external parties 
• Manage risks for both parties in the contract

This tool was the RAID log – a simple spreadsheet with tabs for Risks, Assumptions, Issues, and Dependencies. It enabled delivery teams to manage projects according to the contract’s terms and conditions more effectively than trying to manage directly from hundreds of pages of legal documentation. 

RAID proved so successful that it was adopted as part of the PRINCE2 project methodology and became a standard way to manage potential project derailments globally. 

 

Modern Drift from RAID 

In recent years, agile methodologies have gained popularity in project management, bringing many positive changes such as increased adaptability, responsiveness, and a focus on value delivery. However, traditional agile frameworks often overlook formal risk management, leading to a decline in knowledge and interest in structured risk and RAID management. This oversight can be particularly detrimental when contractual agreements are involved, as misalignment between the negotiated terms and the execution can have severe consequences. Without proper attention to basic risk and issue management, many projects encounter difficulties and may ultimately fail. 

 

Harnessing the Power of RAID for Contract Delivery 

RAID logs address this issue by capturing key items from the contract and putting them into a format that can be easily observed and managed by the contracted parties. The key components include: 

Assumptions 

All plans are based on fundamental assumptions and contracts are no exception. These assumptions must be captured and validated, as they represent potential risks to the project. If an assumption proves invalid, it automatically becomes an issue that impacts the contract. Examples of assumptions include: 

• The client will provide access to necessary systems within 2 weeks of project kickoff 
• The vendor has the required expertise to deliver the agreed-upon solution 
• The project scope will remain stable throughout the engagement 

Dependencies 

Similar to assumptions, dependencies are specific points where one contracted party needs the other party to provide a deliverable or enable a condition for the first party to fulfill their contractual obligations. Unclear dependencies are a common cause of problems in contract delivery, but they can be easily resolved with clarity on expectations. Examples of dependencies include: 

• The client must provide sign-off on design documents before development can begin 
• The vendor requires access to the client’s test environment to perform QA 
• The client must provide timely feedback on deliverables to maintain the project schedule 

Risks (Threats) 

While assumptions and dependencies can be taken directly from the contract language, it’s important to assess where the contract risks lie from each party’s perspective. By openly discussing each party’s concerns, a shared understanding can be developed. Once documented, these risks can be tracked throughout the project, and the team can collaborate to respond to risks that affect either or both parties. Examples of contract risks include: 

• The project scope may expand beyond what was initially agreed upon 
• Key personnel may leave the project, causing delays or knowledge gaps 
• External factors, such as regulatory changes, may impact the project 

Opportunities  

Focusing solely on identifying and managing threats can negatively impact the relationship between the contracted parties. It’s equally important to actively document and seek shared opportunities. This approach helps the parties work together to find and maximize shared benefits while mitigating risks. Examples of contract opportunities include: 

• Identifying areas where the project can be streamlined to save time and resources 
• Leveraging the vendor’s expertise to improve the client’s processes 
• Collaborating on innovative solutions that benefit both parties 

 

Conclusion 

The success of contracted projects relies heavily on the project team’s ability to execute the work according to the agreed-upon terms and conditions. However, without a dedicated tool to capture and manage the contractual and implied assumptions, constraints, risks, and opportunities, contract delivery issues are virtually guaranteed. 

RAID logs provide a simple yet powerful solution to this problem. By documenting and tracking these critical elements in an easily accessible format, RAID logs enable project teams to stay aligned with the contract throughout the project lifecycle. This proactive approach to risk management not only helps mitigate potential issues but also fosters collaboration and trust between the contracted parties. 

In today’s complex project landscape, where agile methodologies dominate and contracts are increasingly intricate, RAID logs have become an indispensable tool for project managers. By embracing RAID logs, organizations can significantly improve their chances of delivering successful contracted projects, minimizing the risk of disputes and litigation. 

In the end, the choice is clear: mitigate risks through proactive RAID management, or face the consequences of failing to do so. For any organization serious about achieving project success and maintaining strong business relationships, RAID logs are non-negotiable. By embracing RAID logs as a non-negotiable tool, organizations can confidently navigate the complexities of contract projects and pave the way for success. 

 

 

References 

1. Flyvbjerg, B., & Budzier, A. (2011). Why your IT project may be riskier than you think. Harvard Business Review. Retrieved from https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think
2. Bloch, M., Blumberg, S., & Laartz, J. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey & Company. Retrieved from https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value