SCC QSR PRP Wireless

From SCC Wiki
Revision as of 21:57, 21 October 2018 by Dale (talk | contribs) (Milestones (5.3))
Jump to: navigation, search

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. The aircraft wireless receiver requires no external power.

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 yyyy-mm-dd
Project manager / Tom Swift yyyy-mm-dd
Product manager / John Sharp yyyy-mm-dd
Manufacturing manager / Miquel DeLazes yyyy-mm-dd
Software lead designer / Minnie Blair yyyy-mm-dd
Hardware lead designer / Barcoe Jenks yyyy-mm-dd
Mechanical lead designer / Bub Armstrong yyyy-mm-dd

Project background (2.)

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

Scope (3.)

This section is where you clearly define the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. Examples of areas that could be examined are data, processes, applications, or business areas. The following types of information can be helpful.

  • The types of deliverables that are in scope and out of scope (business requirements, current state assessment).
  • The major life-cycle processes that are in scope and out of scope (analysis, design, testing).
  • The types of data that are in scope and out of scope (financial, sales, employee).
  • The data sources (or databases) that are in scope and out of scope (billing, general ledger, payroll).
  • The organizations that are in scope and out of scope (human resources, manufacturing, vendors).
  • The major functionality that is in scope and out of scope (decision support, data entry, management reporting).

The scope of this project includes and excludes the following items:

In scope (3.1)

  • InScope-1
  • InScope-2
  • InScope-3

Out of scope (3.2)

  • OutofScope-1
  • OutofScope-2
  • OutofScope-3

Project deliverables (3.3)

All projects have deliverables. In this section, describe the deliverables of the project. Provide enough explanation and detail that the reader will be able to understand what is being produced. Make sure that the deliverables produced align with what is in scope from the previous section.

  • Deliverable1
  • Deliverable2
  • Deliverable3

Organizations affected (3.4)

List affected organizations in order of affect to ensure the project includes all appropriate people and functional groups, and communication is directed appropriately. Specify areas or groups affected by the project or participating in it. Keep to a high level but be complete, and describe how the organization is affected or is participating. An individual should be included here only when they are not a representatives of a larger organization.

Organization Description
Organization-1 Description
Organization-2 Description
Organization-3 Description

Detailed requirements (4.)

Requirements are statements that describe what the project is to achieve or deliver. Objectives should be SMART (Specific, Measurable, Achievable, Realistic, and Time-Based) and deliverable-based. The completion of a requirement should be evident from its description. Consider the following items, and include subsections for major categories if appropriate.

  • Product name
  • Application
  • Basic concept
    • Functions
    • Modes of operation
    • Operational parameters
    • System diagram
    • Product outline, artist rendering, etc.
    • Critical components
    • Fail-safe behavior
    • Physical protection
    • Serviceability
    • Safety
  • Regulatory compliance
  • Preliminary production plan

User interface (4.1)

  • Screens
  • Modes of operation
  • Operation parameters

Sub-system specification (4.2)

  • System diagram
  • Sub-System n description
  • Database integration

Data description (4.3)

  • Input data
  • Output data
  • Stored data

Physical characteristics (4.4)

  • Chassis drawing
    • Labeling
  • User interface
  • Connectors
  • Inputs
  • Outputs
  • Indicators
  • Connector Types
  • Size
  • Weight
  • Power Consumption
    • Battery type

Project estimated cost/effort/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)

Provide a summary of significant costs, including relative dates for one-time expenses. Consider non-recurring and fixed costs in addition to variable costs (such as labor). After the project is underway, report on to date actual and expected cost to complete, compared to the original estimate when the project was approved.

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.

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