Join Haydn Thomas for an in-depth discussion in this video Building requirement traceability into the plan, part of Business Analysis Foundations.
- A wise person once said, "if you don't have a plan "for where you are going, you may never get there." This holds true for your requirements plan and the project it supports. In fact, even with a plan you need checkpoints along the way to ensure you continue to head in the right direction to achieve your business objectives. Ensuring you stay on track and collecting the data you need is the intent of deploying Requirements Traceability. Requirements Traceability helps you in two ways. It tracks how requirements have evolved and how you're going to ensure those requirements are achieved and verified.
There are number of points where requirements traceability can be added to your plans to ensure your business is protected via requirements being incorporated into project activities and ensuring those project activities satisfy the intent of the requirements. Here are my recommendations for areas where and how requirements traceability elements can be added requirements plans, and in turn with overall project plans. First, capture the intended origin of requirements and who provided the captured requirements.
Your requirements plan should include the areas of your business where requirements need to be collected and once there, who provided them to ensure completeness? Second, ensure all your requirements map to prioritized business objectives. Plan for specific reviews after you have collected your requirements to see how they fit, individually and in aggregate to the objectives. A meeting and a review of the results should be part of any your requirements plans. Third, once the plans for development of the projects products are drafted, map the requirements to the deliverables that will satisfy those requirements.
That mapping activity and periodic review of status with product developers can help you ensure requirements are understood and satisfied. The mapping and reviews should be significant events that are reflected in your plans. Fourth, tie in your project risks. The most significant risks in a project are typically those that directly effect your business. As a result, risks can usually be tied to requirements. Ensure that any risk reviews are part of your business analysis plans and that you tie risks directly to business requirements, where possible.
Finally, provide traceability from tests to the requirements. Both the business analyst and the overall project need a test plan. Schedule time in your plan to not only design review tests, but share the most critical ones with your key stakeholders and plan for when the results of those tests will be shared and reviewed. This plan item can be critical in gaining buy-in for the results your project efforts are trying to produce. What I have shared here is the high level categories of the detailed traceability elements.
I've included a Traceability Matrix in the exercise files for this course. Like the businesses we support, projects are rarely static. As a result, requirements and their business priority may change. Your Traceability Matrix can be a great tool to ensure the needs of your business remain valid, well prioritized, and supported by your project activities even as the world changes around you. Here are some common events that should trigger a review of your Requirements Traceability Matrix. Firstly, a reorganization or change in a key stakeholder.
Other project's impact on the requirements of your project. A competitor announces a product that competes with what you are producing or a major financial change effects the project. In each of these instances the Traceability Matrix is valuable to ensure any changes that result in your project can be accurately reflected in planned project activities. And in turn, it ensures you'll indeed, know where you were going so that you can get there in one piece.
Discover where business analysis lives in the project life cycle, how to initiate a project, the best way to gather requirements, and smart strategies to monitor results and test outcomes.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Understanding what business analysts do
- Defining business opportunities and objectives
- Identifying stakeholders
- Gathering requirements through observation and brainstorming
- Validating requirements
- Developing project acceptance criteria
- Implementing, testing, and closing your project<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.