Difference between revisions of "SCC QSR PRP Wireless"

From SCC Wiki
Jump to: navigation, search
m (Estimated Cost (5.1))
m (Estimated Effort (5.2))
Line 89: Line 89:
=== Estimated Effort (5.2) ===
=== Estimated Effort (5.2) ===
Consider units of effort (e.g., person-days, man-weeks, etc.) by category of labor (e.g., software developer, system architect, pcb designer, ...). After the project is underway, report on to date actual and expected effort to complete, compared to the original estimate when the project was approved.
Not estimated.
=== Milestones (5.3) ===
=== Milestones (5.3) ===

Revision as of 08:00, 22 October 2018

Project Overview (1.)

The purpose of the Wireless project is to develop an aircraft wireless receiver, for use by field operatives to receive orders and other communications from their command and control center.

Project Strategy (1.1)

The project will be managed according to the SCC QSP Project Management and SCC QSP Product Lifecycle Management.

Project Structure (1.2)

Role / Name Date Approved
Project sponsor / Barton Swift 2013-01-01
Project manager / Tom Swift 2013-01-01
Product manager / John Sharp 2013-01-01
Manufacturing manager / Miquel DeLazes 2013-01-01
Software lead designer / Minnie Blair 2013-01-01
Hardware lead designer / Barcoe Jenks 2013-01-01
Mechanical lead designer / Bub Armstrong 2013-01-01

Project Background (2.)

Provide additional background for the project and expand on financial or strategic justification.

Scope (3.)

The wireless receives amplitude modulated (AM) signals in the commercial broadcast medium-wave spectrum of 530 kHz – 1710 kHz, and requires no external power.

In-Scope (3.1)

  • Product requirements.
  • Product development.
  • Sales launch.

Out-of-Scope (3.2)

  • All other activities.

Project Deliverables (3.3)

  • Wireless product design, including supply chain specifications.
  • User documentation.
  • Production documentation.
  • 10 prototypes

Organizations Affected (3.4)

Organization Description
Universal Flying Machine Ltd. Development partner and initial customer.
SCC Engineering Product development.
SCC Sales Sales plan, sales roll-out.
SCC Manufacturing Production and production Planning.
SCC Finance Project controls and reporting.

Detailed Requirements (4.)

The wireless receives amplitude modulated (AM) signals in the commercial broadcast medium-wave spectrum of 530 kHz – 1710 kHz, and requires no external power. Regulatory compliance or certification is not required.

User Interface (4.1)

  • The Wireless shall have a knob to adjust the AM carrier frequency it is tuned to.
  • The Wireless shall have a headphone connector.

Sub-System Specification (4.2)

  • Not applicable.

Data Description (4.3)

  • Not applicable.

Physical Characteristics (4.4)

  • Not specified.

Project Estimated Cost, Effort and Duration (5.)

The estimated effort hours and project costs may be depicted in many ways, including costs by team member, by deliverable, by milestone, or by category, (internal labor, external labor, travel, training, supplies, etc.). Cost is a continuum, starting with a forecast at the beginning of a project and converging to an actual realized cost by the end of the project, and the context for any values provided must be clear. Also include a brief timeline (or a set of bullets) showing the project start date, major milestones, and end date.

Estimated Cost (5.1)

Not estimated.

Estimated Effort (5.2)

Not estimated.

Milestones (5.3)

Milestone Date Forecast Date Completed Deliverable & Expectations
Project Launch 2012-12-01 2012-12-01 Approval of draft project plan and project manager assigned.
Prototype 2013-01-01 2013-01-01 For building prototypes
Prototype 2 2013-01-02 2013-01-02 PCB correction and documentation release
Product Release 2013-01-03 2013-01-03 Release of top-level marketing assembly to production
Product Marketing Launch yyyy-mm-dd yyyy-mm-dd ...
First Production Run yyyy-mm-dd yyyy-mm-dd ...
First Customer Ship yyyy-mm-dd yyyy-mm-dd ...

For additional milestone details, refer to Feature PLM SCC Data

Project Assumptions (6.)

Project assumptions are circumstances and events that need to occur for the project to be successful but are outside the total control of the project team. They are listed as assumptions if there is a HIGH probability that they will in fact happen. The assumptions provide a historical perspective when evaluating project performance and determining justification for project-related decisions and direction.

To identify and estimate the required tasks and timing for the project, certain assumptions and premises need to be made. Based on the current knowledge today, the project assumptions are listed below. If an assumption is invalidated at a later date, the activities and estimates in the project plan will be adjusted accordingly.

In order of criticality, the major project assumptions are:

  1. Project Assumption1
  2. Project Assumption2
  3. Project Assumption3

Project Risks (7.)

Project risks are circumstances or events that exist outside of the control of the project team and will have an adverse impact on the project if they occur. (In other words, whereas an issue is a current problem that must be dealt with, a risk is a potential future problem that has not yet occurred.) All projects contain some risks. Risks may not be able to be eliminated entirely but can be anticipated and managed, thereby reducing the probability that they will occur.

Risks that have a high probability of occurring and have a high negative impact should be listed below. Also consider those risks that have a medium probability of occurring. For each risk listed, identify activities to perform to eliminate or mitigate the risk.

Project risks are characteristics, circumstances, or features of the project environment that may have an adverse effect on the project or the quality of its deliverables. Known risks identified with this project have been included below. A plan will be put into place to minimize or eliminate the impact of each risk to the project.

Risk Area Level (H/M/L) Risk Mitigation Plan
Project Risk 1 Medium Mitigating action
Project Risk 2 Medium Mitigating action
Project Risk 3 Medium Mitigating action

Related Documentation (8.)

List relevant related documentation in a table or unordered list. Related documentation provides additional background information, and is NOT part of the project requirements (if an external document is part of the requirements, it must be listed in either the Scope or Detailed requirements section).

  • Document1
  • Document2
  • Document3

Project Approvals (9.)

Add any signatures that are important for the approval of the project. Names and dates are provided here to indicate required approvals and for convenient reference, approval is managed in Maestro).

Role / Name Date Approved
Dir., Sales & Marketing / James Period 2012-12-01
Manager of project manager / Barton Swift 2012-12-02
Project manager / Tom Swift 2012-12-03