
























































































Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
A sample requirements traceability matrix is included as a separate document in this Project Management Plan. Page 13. 12. REQUIREMENTS TRACEABILITY MATRIX.
Typology: Study notes
1 / 96
This page cannot be seen from the preview
Don't miss anything!

























































































The Project Manager, and team will all play key roles in managing the scope of this project. As such, the project manager and team members, and Customer must be aware of their responsibilities in order to ensure that work performed on the project is within the established scope throughout the entire duration of the project. The table below defines the roles and responsibilities for the scope management of this project. Name Role Responsibilities TBD Customer - Accept project deliverables
The scope for this project was defined through a comprehensive requirements collection process. First, a requirements collection workshop was conducted with key stakeholders. From the input gathered, the project team used the requirements management plan to develop the project requirements documentation, and the requirements traceability matrix for what the project must accomplish. The project description and deliverables were developed based on the requirements collection process and input from subject matter experts. This process of expert judgment provided feedback on the most effective ways to meet the requirements of the project.
The project Scope Statement provides a detailed description of the project, deliverables, constraints, exclusions, assumptions, and acceptance criteria. Additionally, the scope statement includes what work should not be performed in order to eliminate any implied but unnecessary work which falls outside the of the project’s scope. This project includes all the deliverables described [at the general level] in the Scope Statement. This project will be accepted once each of the major deliverables has been successfully completed, tested by the Project Team, and accepted by the Customer. This project does not include any items mentioned in the list of Exclusions. CONSTRAINTS: Only internal personnel, and personnel from the contracted vendors, may be used for this project. Additionally, the project is not to exceed 330 days in duration, or $450, in spending. ASSUMPTIONS: Assumptions for this project are that support will be provided by the project sponsor and all department managers and that adequate internal resources are available for the successful completion of this project.
In order to effectively manage the work required to complete this project, it will be subdivided into individual work packages which will not exceed 40 hours of work. This will allow the Project Manager to more effectively manage the project’s scope as the project team works on the tasks necessary for project completion. The project is broken down into three phases: the Site Preparation and Foundation Phase; the Structural Phase; and the Finishing Phase. Each of these phases is then subdivided further down to work packages which will require no more than 40 hours of work and no less than 4 hours of work (see Work Breakdown Structure [WBS]).
The purpose of this Requirements Management Plan is to establish a common understanding of how requirements will be identified, analyzed, documented, and managed for the Project. Requirements will be divided into two categories: project requirements and product requirements. Project requirements are the requirements identified to meet the needs of the project and ensure its completion and readiness to hand over to operations. These consist mostly of administrative and logistical requirements. Product requirements are the requirements identified to meet the technical specifications of the product being produced as a result of the project. These will consist of requirements to ensure that performance specifications are met, component properties are properly documented, and construction thresholds are identified and documented. The inputs for the requirements management plan include the Project Charter and Stakeholder Register.
The approach we will use for requirements management for the project will be broken down into four areas: requirements identification, requirements analysis, requirements documentation, and ongoing requirements management. Requirements Identification: The project team will facilitate various methods to collect requirements which may include: interviews, focus groups, facilitated workshops, group creativity techniques, questionnaires and surveys, etc. These will be conducted among the project stakeholders to ensure all requirements are captured. Requirements Analysis: The project team will analyze requirements to determine if they fall into project or product categories. Additionally, this analysis will determine if the requirements can logically be translated into work packages and / or schedule activities. Accountability and priority for each requirement will also be determined as part of the analysis. Finally, acceptance criteria must be determined for all requirements, from which quality metrics can be derived. The metrics will be used in the Quality area to determine when a requirement has been fulfilled to an acceptable level. Requirements Documentation: Once requirements have been identified and analyzed, they will be documented and assigned to accountable personnel. These requirements will be used to develop the project Scope Statement, and the project team will determine what methodologies to use to track and report on the status of each requirement. All requirements will also be added to the Requirements Traceability Matrix, which will be used throughout the project, as well as during the formal project closure process. Ongoing Requirements Management: Throughout the project lifecycle, the project manager will ensure all team members are reporting requirement status and raising any issues or concerns with their assigned requirements as appropriate. As the project matures there may be situations
in which requirements must change or be altered in some way. The project team will follow the established change control process in order to propose any changes to requirements and receive approval from the change control board. Ongoing requirements management also includes reviewing the completion status of all requirements as part of project closure.
For the Project, the Requirements Management Plan will synchronize with the configuration management activities outlined in the Configuration Management Plan. Key items include documentation/version control and change control: Documentation and Version Control : All documentation related to components of the deliverables will be loaded into the Configuration Management Database (CMDB) as the central repository for the Project. Appropriate permissions will be granted to the project team for editing and revising documentation. Any proposed changes to the documents that do not result in changes to fundamental project plans or baselines will be reviewed and approved by the designated Team Member. When the documentation is edited, the project manager and Team will be responsible for communicating the change to appropriate stakeholders. Change Control : Any proposed changes to project requirements must be carefully considered before approval and implementation. Such changes are likely to impact project scope, time, and/or cost, perhaps significantly. Any proposed changes to fundamental project plans or baselines will be reviewed by the CCB. The role of the CCB is to determine the impact of the proposed change on the project, seek clarification on proposed change, and either approve or reject requested changes. The project manager and Team are responsible for documenting and implementing any approved changes in project scope, as part of the change review and approval process.
The project manager will facilitate stakeholder meetings in order to establish priorities for all project requirements. This project will use a three-level scale in order to prioritize requirements. The chart below illustrates these levels and defines how requirements will be grouped: Priority Level Definition High These requirements are mission critical. They are required for project/product success or for progression to next project phase Medium These requirements support product/process operations but can be completed under the next product release Low These requirements are quality and/or functional enhancements and are not desirable if time and resources permit As the project moves forward and additional constraints are identified or there are issues with resources, it may be necessary for the project team and stakeholders to meet in order to determine what requirements must be achieved, which can be re-baselined, or which can be
Requirements Traceability Matrix Sample Project R.T.M. Project: House Construction Source of Req. Description Requested: Id’ed as Not Required: Completed: Accepted by Customer: G. White 3 Bedrooms 8/3/ T. Hall 2 ½ Bathrooms 8/12/ E. Rastrum Indoor Pool 8/6/ H. Halifax Foam Insulation 8/3/ R. Ansel Cupola 8/14/ W. Angstrom Finished Basement 8/5/ L. Phantleroy 4 - Car Garage 8/12/
The project schedule is the roadmap for how the project will be executed. Schedules are an important part of any project as they provide the project team, sponsor, and stakeholders a picture of the project’s status at any given time. The purpose of the schedule management plan is to define the approach the project team will use in creating the project schedule. This plan also includes how the team will monitor the project schedule and manage changes after the baseline schedule has been approved. This includes identifying, analyzing, documenting, prioritizing, approving or rejecting, and publishing all schedule-related changes.
Project schedules will be created using MS Project 2007, starting with the deliverables identified in the project’s Work Breakdown Structure (WBS). Activity definition will identify the specific schedule activities which must be performed to complete each work package. Activity sequencing will be used to determine the order of schedule activities, based on identified relationships between project activities. Resource estimating will be used to identify the resources needed to complete each of the schedule activities. Activity duration estimating will be used to calculate the number of work periods required to complete schedule activities. Once a preliminary schedule has been developed, it will be reviewed by the project team, and the specific needed resources will start to be acquired and assigned to project tasks. The project team will continue to review the resource assignments, durations, and schedule sequencing. The initial scheduling effort will result a Milestone Chart [which will also serve as the basis for the Schedule Baseline, as well as the first Project [Schedule] Network Diagram (PND). The significant Milestones for this project are depicted in the Schedule Baseline [Milestone Chart]. Roles and responsibilities for schedule development are as follows: The project manager will be responsible for facilitating work package definition, sequencing, and estimating duration and resources with the project team. The project manager will also supervise the creation of the project schedule using MS Project 2007, and validate the schedule with the project team, and certain key stakeholders. The project manager will approve the [relatively static] schedule baseline, and the [dynamically evolving] project schedule. The project team is responsible for participating in work package definition, sequencing, and duration and resource estimating. The project team will also review and validate the proposed schedule and perform assigned activities once the schedule is approved.