SCC QSF Project Plan (PRP)

From SCC Wiki
Revision as of 13:08, 22 October 2018 by Dale (talk | contribs) (Project Strategy (1.1))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Project Overview (1.)

Describe the background and context for the project and why it is being undertaken. Speak to the business value of the work being performed. Put enough information here so there is a context for the remaining sections.

Project Strategy (1.1)

The project strategy is a top-down approach to the project. Describe how the project will be structured and any important techniques that will be utilized, including the project management model used.

Project Structure (1.2)

Include only critical functions in the following table.

Role / Name Date Approved
Project Sponsor / Name yyyy-mm-dd
Project Manager / Name yyyy-mm-dd
Product Manager / Name yyyy-mm-dd
Software Lead / Name yyyy-mm-dd
Hardware Lead / Name yyyy-mm-dd
Mechanical Lead /Name yyyy-mm-dd
Project Adviser / Name 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)

  • InScope1
  • InScope2
  • InScope3

Out-of-Scope (3.2)

  • OutofScope1
  • OutofScope2
  • OutofScope3

Project Deliverables (3.3)

Projects have one or more intended outcomes, called 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 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)

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)

Provide a milestone summary table, which will be adequate for many projects. If the complexity of the project justifies it, include a project Gantt chart for visual clarity.

Milestone Date Forecast Date Completed Deliverables & Expectations
Project Launch yyyy-mm-dd yyyy-mm-dd Project Plan, Product Rqmts
Milestone yyyy-mm-dd yyyy-mm-dd ...
Milestone yyyy-mm-dd yyyy-mm-dd ...
Product Launch / Trade Show yyyy-mm-dd yyyy-mm-dd ...
Milestone yyyy-mm-dd yyyy-mm-dd ...
Production Run 1 yyyy-mm-dd yyyy-mm-dd ...
First Customer Ship yyyy-mm-dd yyyy-mm-dd ...
Project Termination yyyy-mm-dd yyyy-mm-dd ...

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.

Assumption Criticality (H/M/L) Desription
Assumption 1 Medium Adequate resources will be provided to complete the project in the shortest possible time.
Assumption 2 Medium Adequate resources will be provided to complete the project in the shortest possible time.
Assumption 3 Medium Adequate resources will be provided to complete the project in the shortest possible time.

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
Risk-1 Medium Mitigating action
Risk-2 Medium Mitigating action
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).

  • Document-1
  • Document-2
  • Document-3

Project Approvals (9.)

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

Role / Name Date Approved
Project Sponsor / Name yyyy-mm-dd
Manager of project manager / Name yyyy-mm-dd
Project manager / Name yyyy-mm-dd