Using BRTM/RTM for Risk Mitigation

The correlation between requirements inconsistency and designed product (software) inconsistency created due to inconsistent requirements (Business or System), generate a new risk which can be easily mitigated by traceability analysis. The traceability management (gap analysis) is the most important tool, yet easy to use, to identify the gaps and tracebility inconsistency even before major risk/issue occurs, especially helpful when the project is risky or sensitive. The traceability can be implemented in almost all phases of project life cycle as the best practices especily if you wish to accurately and efficiently product the exact product stated in Requirements Documents. The whole idea behind the traceability management is to ensure that all the development artifacts are directly or indirectly mapped back to one and another. Doing so provides us greater control over the execution of project and it efficiently migrates the risk of project failure.

BRTM/RTM, Gap Docs, Issue Logs, Risk Logs are the artifacts which act as the guidelines for all distributed (geologically diversified) teams to stay on the right track on project execution. In most cases, business needs are identified during the early stage of project but when those project requirements move down to the downstream teams (say Technology teams such engineers or QAs) then most often those requirements are misinterpreted by those teams. The result of this misinterpretation makes the project fail and accounts about 70% of total failed projects. It is not just the bad requirements that is accountable in such cases, sometimes it is the receiver of the message that comes from requirements documents. If we create BRTM/RTM than it provides a way to deliver the requemenyts and track them untill the project is complete. It helps as the meeting tool to brainstorm to identify the gaps and keep every team members on the same page. In other words, it is the language that every team member in a project can easily understand. Rememeber – BRTM/RTM is always a living document, meaning it is not a one time deal . It must be updated continually throughout the project.  This documents also help to identify the lessen learned for the future projects.

RTM and BRTM can also be an automated process or manual depending on the situation and the need for the use of traceability. The version control is also traceability that provides one step higher level of traceability to the BRTM & RTM.

This blog is being migrated to sagesofuniverse.com 

My Other Blogs:

Traceability in a professional way-Traceability Matrix and its uses

Traceability in a professional way-What are the differences between BRTM and RTM?

Traceability in a professional way-Traceability Matrix can be bidirectional

Traceability in a professional way-How to create a BRTM and RTM?