12
.
Case Study on Research and Development (R&D) Projects (100 points)
The case study below offers an excellent perspective on how projects are often initiated under less than ideal circumstances—which often lays the ground work for project failure.
Companies that provide a service for another company usually respond to a bid document from a company that needs help. This case study is a good example of this situation. The bid document can be as simple as an email from the buyer to the seller or as complicated as a request for proposal (RFP) outlining the objectives of the project and asking a seller to develop a proposal that provides a solution.
Each company (seller and buyer) will have a business case for doing the project. The Peter’s Company is outsourcing for a reason. The Corwin Corporation is taking on the project for a different set of reasons. One of the reasons the Corwin Corporation is taking on the work is the looming, potentially very lucrative production contract if they are successful. There are no guarantees in research and development project that there will be success.
A strategy for completing this assignment:
There is only the group assignment for this unit as it is demanding and will require good time management and proper sequencing of the tasks completed by each team member.
Each team member should spend time reading and thinking about the case, the cast of characters, information that you’d like to have but isn’t included in the case study, and so on.
Review what is required to complete each part of the assignment and estimate the sequence and time it will take to complete the work. Assign tasks so that everyone has an equal share of the workload and try to capitalize on strengths of group members.
Determine information gaps (things you’d like to know) and post questions in the Ask the Professor forum. Do this early so that the instructor has time to respond during the 24-hour period after you post the question. Do not email the instructor questions about this assignment.
Communicate with each other and review each other’s work. At least one person should be checking all content as a quality check to verify that the assigned person is meeting expected deliverables.
Read all responses to the questions posted in the Ask the Professor forum.
Correct and compile parts of the assignment into a cohesive document. A key emphasis is to make sure the perspective (“our group believes” versus “I believe”) is correct when writing up the deliverables. This is a group assignment.
Assume the Peter’s Company provided some initial statement of work documentation, by email or other means, that was sufficient for Dan West (the project manager) to move forward with the project for the Corwin Corporation. A sample project charter is provided for you.
The project charter (provided) is a high-level document; read it carefully and use it to help prepare other documentation.
Be sure to list as many stakeholders and issues as you can by using your group’s collective project management experience. The list of stakeholders is more than a relisting of the cast of characters in the case. A stakeholder register is essential for collecting requirements and for managing communication needs.
CASE: Peter’s Company R&D Project
Corwin Case Study – Scope (1) x
Part 1 (20 points)–Prepare a requirements management plan (RMP) that addresses the five components described in Section 5.1.3.2, PMBOK 6e. The plan should be at least 3 but not exceed 4 pages and does not need to conform to APA guidelines (except for citing and referencing sources).
Some things to think about – how is the role of the in-house rep dealt with in the RMP as it relates to activities for planning, tracking and reporting requirements? Configuration management is not just about software and versioning. What processes will be used for configuration management activities as they relate to changes in the product requirements? How and who will authorize/approve changes? The traceability structure should be tailored to the type of project and should ensure that each requirement adds business value.
from the case study is involved and what is to be done.
Rubric
Unit 7 Group Assignment Rubric
| Unit 7 Group Assignment Rubric | ||
|
Criteria |
Ratings |
Pts |
|
This criterion is linked to a Learning Outcome Part 1 RMP |
20 pts |
ProjectManagementDocs.com
Requirements Management Plan Template
This Requirements Management Plan Template is free for you to copy and use on your project
and within your organization. We hope that you find this template useful and
welcome your comments. Public distribution of this document is only permitted
from the Project Management Docs official website at:
ProjectManagementDocs.com
Requirements Management Plan
Company Name
Street Address
City, State Zip Code
Date
Table of Contents
Introduction
3
Requirements Management Approach
3
Configuration Management
4
Requirements Prioritization Process
5
Product Metrics
6
Requirements Traceability Matrix
7
Introduction
The Requirements Management Plan is a necessary tool for establishing how requirements will be collected, analyzed, documented, and managed throughout the lifecycle of a project. Depending on the type of project there may be both project and product requirements. It is easy to unintentionally omit requirements, fail to document them, or leave requirements incomplete without a tool to properly manage them.
The purpose of the BrightStar Requirements Management Plan is to establish a common understanding of how requirements will be identified, analyzed, documented, and managed for the BrightStar fiber optic cable 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 non-technical requirements. Product requirements are the requirements identified to meet the technical specifications of the product being produced as a result of the project: the BrightStar fiber optic cable. These will consist of requirements to ensure that performance specifications are met, cable properties are properly documented, and manufacturing thresholds are identified and documented.
The inputs for the requirements management plan include the BrightStar Project Charter and Stakeholder Register.
Requirements Management Approach
The requirements management approach is the methodology the project team will use to identify, analyze, document, and manage the project’s requirements. Many organizations use a standard approach for all projects, but based on the characteristics of each project, this approach may require some changes. The PMBOK defines this approach as “How requirements activities will be planned, tracked, and reported.”
The approach we will use for requirements management for the BrightStar project will be broken down into four areas: requirements identification, requirements analysis, requirements documentation, and ongoing requirements management.
Requirements Identification: The BrightStar project team will facilitate various methods to collect requirements which may include: interviews, focus groups, facilitated workshops, group creativity techniques, questionnaires and surveys, or product prototypes. These will be conducted among the project stakeholders to ensure all requirements are captured.
Requirements Analysis: The BrightStar project team will analyze requirements to determine if they fall into project or product categories. Additionally, this analysis will determine where in the WBS the requirements will fall or what work activities correspond to particular requirements. Accountability and priority for each requirement will also be determined as part of the analysis. Finally, metrics and acceptance criteria must be determined for all requirements in order to provide a baseline for understanding 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 added to the BrightStar project plan and the project team will determine what methodology the accountable personnel will use to track and report on the status of each requirement. All requirements will also be added to the project requirements checklist which must be completed before formal project closure is accepted by the project sponsor.
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 must 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 receiving approval of all requirements by all vested parties as part of project closure.
Configuration Management
In order to effectively manage a project, communication must be managed and controlled. Additionally, every effort must be taken to identify requirements thoroughly during project initiation and planning. However, there are often situations which require changes to a project or its requirements. In these situations it is important to utilize configuration management to consider proposed changes, establish a process to review and approve any proposed changes, and to implement and communicate these changes to the stakeholders. As stated in the PMBOK: “Configuration management activities such as how changes to the product, service or result requirements will be initiated, how impacts will be analyzed, how they will be traced, tracked, and reported, as well as the authorization levels required to approve these changes.”
For the BrightStar Project, the Requirements Management Plan will utilize the configuration management activities outlined in the Configuration Management Plan. Key items include documentation/version control and change control:
Documentation and Version Control: All project documentation will be loaded into the Configuration Management Database (CMDB) as the central repository for the BrightStar Project. Appropriate permissions will be granted to the project team for editing and revising documentation. Any proposed changes to project requirements must be reviewed by the Configuration Control Board (CCB) and have written approval by the project sponsor before any documentation changes are made. Once these proposed changes are approved and the documentation is edited, the project manager will be responsible for communicating the change to all project stakeholders.
Change Control: Any proposed changes in 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 project requirements 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 ensure any approved changes are added to the CMDB. The project sponsor, who also sits on the CCB, is responsible for approving any changes in project scope, time, or cost and is an integral part of the change review and approval process.
Requirements Prioritization Process
Prioritizing requirements is an important part of requirements management. Developers or service providers do not always know what requirements are most important to a customer. Conversely, customers do not always understand the scope, time, and cost impacts of their requirements on a project. Collaboration among all stakeholders is a necessary part of establishing project requirement priorities. If cuts need to be made to scope, time, or cost, this list of priorities will provide a better understanding of where a project can or cannot focus to deal with the constraints placed upon it. One way to do this is to group requirements into priority categories such as high, medium, and low priority based upon the importance of the requirement. There may be hundreds of requirements in a large project so this type of categorically-based method would be helpful. NOTE: there are many methods by which priorities are determined and these should be explored based on the size and complexity of the project.
The BrightStar 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:
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 omitted. These determinations will be made in a collaborative effort based on the priorities of the requirements and which level they are assigned in accordance with the chart above. As any changes in requirements are made, all project documentation must be updated in the CMDB and communicated to all project stakeholders.
Product Metrics
Product metrics are an important part of determining a project’s success. There must be some quantitative characteristics to measure against in order to gauge the progress and success of the project. Product metrics are usually technical in nature though not always. Such metrics may consist of performance, quality, or cost specifications. Metrics may also be based on the product requirements identified for a given project.
Product metrics for the BrightStar project will be based on cost, quality, and performance requirements as outlined in the project charter. In order to achieve project success, the BrightStar product must meet or exceed all established metrics.
Cost:
· BrightStar cable product must cost less then $6,000 per linear kilometer for fiber counts of 12-72 fibers; less than $8,000 per linear kilometer for fiber counts of 84-180 fibers; less than $10,000 per linear kilometer for fiber counts of 192-288 fibers.
Quality:
· BrightStar cable product must achieve less than 10% attenuation in temperature cycle testing
· BrightStar cable product must achieve a minimum bending radius of less than 10 feet
· BrightStar cable product must weigh less than 1.0 lb per linear foot for fiber counts of 12-180 fibers and less than 2.0 lbs for fiber counts greater than 180
Performance:
· BrightStar cable must achieve an average attenuation of less than 0.1% per linear kilometer at 1550nm
· BrightStar cable must achieve an average attenuation of less than 0.5% per linear kilometer at 1610nm
· BrightStar cable must have a diameter of less than 1.0” for 12-72 fiber cables; less than 1.5” for 84-180 fiber cables; and less than 2.0” for 192-288 fiber cables
Requirements Traceability Matrix
The requirements traceability matrix is a tool to ensure that deliverables meet the requirements of the project. The matrix provides a thread from the established and agreed upon project requirements, through the project’s various phases, and through to completion/implementation. This ensures that the product specifications and features satisfy the requirements on which they were based. Any interim project tasks associated with the requirements should be included. An example of this are test cases which will utilize metrics, based on the product requirements, which are linked to the project charter and design document. This allows a team member or stakeholder to follow a requirement through all tasks required for its completion.
Below is the requirements traceability matrix for the BrightStar project. The purpose of the requirements traceability matrix is to ensure all product requirements are completed in accordance with the project charter. This matrix provides a thread from all product requirements through design, testing, and user acceptance. Design document and charter references are contained in the BrightStar Project Configuration Management Plan. Any approved changes in project scope or requirements will result in changes to the traceability matrix below. Based on impacts of the approved changes, the Project Manager will make the necessary changes to the matrix and communicate those changes to all project stakeholders.
Sponsor Acceptance
Approved by the Project Sponsor:
Date:
This free Project Requirements Management Plan Template is brought to you by
www.ProjectManagementDocs.com