According to the PMBOK® Guide, the Control Scope process is the process of monitoring the status of the project and product scope and managing changes to the scope baseline. To do this effectively, the project manager needs to ensure that all requirements are being met and that no unauthorized work is being added.
The Requirements Traceability Matrix (RTM) is a grid that links product requirements from their origin to the deliverables that satisfy them.
Function in Control Scope: It provides the thread that links every requirement to the business value and the specific project objective.
Verification: During Control Scope, the RTM is used to verify that the work being performed (and the resulting deliverables) actually aligns with the documented requirements. If a team member is working on something not found in the RTM, it is a red flag for scope creep.
A. Vendor risk assessment diagram: While identifying vendor risks is important, this is not a standard PMI project document used as a primary input for controlling the scope of project deliverables.
B. Risk register: The risk register is an input to many processes (like Control Costs or Control Schedule), but in the context of Control Scope, it is not a direct input. Scope changes might result in new risks, but the register itself doesn ' t define the scope being controlled.
D. Area of responsibility summary: This is likely a reference to a Responsibility Assignment Matrix (RAM) or RACI chart. While it tells you who is doing the work, it does not define what the scope of the work is.
To maintain the integrity of the scope, the following are the primary inputs:
Project Management Plan: Specifically the Scope Management Plan and the Scope Baseline (Scope Statement, WBS, and WBS Dictionary).
Project Documents: Including the Requirements Documentation and the Requirements Traceability Matrix.
Work Performance Data: The raw observations of what work has actually been completed.
Organizational Process Assets: Policies or procedures for scope control and reporting.
