Development Project Plan

Development Project Plan

What: An outline for a Development Project Plan document that summarizes the project
goals and the major activities across the different functional groups necessary to achieve those
goals. Includes sections for describing major activities of the project, including activities that
are sometimes neglected during planning, such as prototype builds, compliance testing,
technical publications, service strategy, etc.

Why: The process of creating this plan outline document should get you to think about each
one of these project areas in enough depth to be able to state something about each one.
This will help you identify resources and tasks as you create a more detailed plan and work
breakdown.

The theme of a good project plan is to “say what you do, and do what you say”. This means
that, during the relatively calmer moments of the early project planning, you should state your
intentions as fully as possible as you work major tradeoffs into a plan. So one major purpose
of this plan is to document the rationale for including major project activities (and for excluding
others). Then in later stages of the project’s execution, when the heat is on and the temptation
to cut corners is great, the plan will help you keep enough discipline to not raise project risk by
cutting out activities that you really felt you should do during those calmer planning moments .

How:
 Read the instructions (in blue font) in each section of the document, and then
replace this text with text you create for your project.

 Stay high-level in this document, keeping it a readable development plan summary.

 Refer in this document to more detailed supporting documents, but don’t repeat
their detail.
Development Project Plan

Development Project Plan Outline

Table of Contents

DEVELOPMENT PLAN OUTLINE.............................................................................................................. 1

1. DESCRIPTION OF DOCUMENT......................................................................................................... 3

2. SUMMARY OF CHANGES.................................................................................................................. 3

3. REFERENCE DOCUMENTS............................................................................................................... 4

4. GOAL STATEMENT............................................................................................................................ 4

5. PRODUCT OR SERVICE DESCRIPTION (“PRODUCT SCOPE”).....................................................4

6. COGS................................................................................................................................................... 4

7. PROJECT SCOPE SUMMARY........................................................................................................... 5

8. TECHNOLOGY AND RISK.................................................................................................................. 5

9. MANAGEMENT AND ORGANIZATION OF PROJECT......................................................................6

10. PROTOTYPE MANAGEMENT......................................................................................................... 6

11. SPECIAL DEVELOPMENT METHODS AND TOOLS.....................................................................6

12. SOFTWARE DEVELOPMENT PLAN..............................................................................................6

13. ALPHA AND BETA TEST PLAN OUTLINE....................................................................................7

14. PRODUCT QUALITY ASSURANCE PLAN.....................................................................................7

14.1 SOFTWARE QUALITY ASSURANCE PLAN OUTLINE..................................................................................7
14.2 SAFETY/COMPLIANCE PLAN OUTLINE................................................................................................... 7
15. MANUFACTURING PLAN............................................................................................................... 8

16. SERVICE PLAN............................................................................................................................... 8

17. TECHNICAL PUBLICATIONS......................................................................................................... 8

18. PROJECT TEAM.............................................................................................................................. 8

19. Project Milestone Schedule............................................................................................................... 9

Development Project Plan

1. Description of Document
Description of the purpose of this document goes here.

The theme of a good project plan is to “say what you do, and do what you say”. This means that, during
the relatively calmer moments of the early project planning, you should state your intentions as fully as
possible as you work major tradeoffs into a plan. So one major purpose of this plan is to document the
rationale for including major project activities (and for excluding others). Then in later stages of the
project’s execution, when the heat is on and the temptation to cut corners is great, the plan will help you
keep enough discipline to not raise project risk by cutting out activities that you really felt you should do
during those calmer planning moments.

Depending upon the scope of the project, you may be creating several other planning documents such as
vision statements, quality assurance plans, etc. This plan document should highlight and summarize
each of those documents and then explicitly refer the reader to those documents for more detail.

But regardless of project scope, the planning process should get you to think about each one of these
project areas in enough depth to be able to state something about each one.

The size of this document is a judgment call on the following trade-off:

 Detailed enough to guard against missing activities or not detecting variance during project
execution.
 Compact enough so that it can be referred to often during the project for guidance without a
stifling amount of detail.

Some areas of this document may overlap. This is OK – better to state critical project attributes twice
than not at all. Project planning is not an exact science. Some judgment will be necessary in deciding
what to include and where to include it in the plan.

2. Summary of Changes
In this section, keep track of revisions to this document. This document will normally be updated several
times during the project as more is known. For revisions of this document, point out the major changes in
the document since its last release, so that readers do not have to re-read the entire document to find
them. Make an appropriate entry into this table each time this document is updated and distributed. Or,
use your own document control.

Date Author Description of changes

Development Project Plan

3. Reference Documents
List other documents that support the Development Plan or are referred to by the Development Plan.

4. Goal Statement
Describe here in a short paragraph what the project is trying to accomplish and give at least one primary
profit metric – a quantifiable measure of project success.

5. Product or Service Description (“Product Scope”)

This section describes the product scope or vision. The product vision is the “front-end” of the
requirements management process for this project. Summarize the product or service that this project is
developing. Include the following attributes.

 Market need -- what customer problem is being solved

 Time-to-market constraints
 Major features – point out clearly the critical features without which the product or service should
not be produced.
 Product cost goals and constraints
 Project cost goals and constraints

Also, state the relative priority of these attributes. For example, time-to-market may have an order of
magnitude greater impact on project profitability than overspending on project cost. Such priority
statements will allow trade-offs to be made more easily during the execution of the project.

If your development methodology calls out creating a vision document, then summarize the vision here
and include a reference to the vision document.

6. COGS
For high-volume and/or low margin products, the Cost of Goods Sold may have critical constraints.
Those constraints should be explicitly called out here to be sure that they are highly visible to all
stakeholders. Assumptions such as labor hours and rates, overhead, and volume should be stated.
Development Project Plan

7. Project Scope Summary

Summarize the scope of the principal project activities. Clearly label any high-risk activities and discuss
them.

 Is this a new product development, or major enhancements to an existing product? For an

enhancement project, some outputs of a previous development project may be leveraged.
 Does the development include software? Will there be significant reuse? A number of major
project activities are implied by software development. The scope of those activities may depend
on the degree of re-use.
 Is any development outsourced (if yes, then this planning document should summarize the
outsourcing or co-development plan, including due-diligence and qualification of the vendor,
communication plan, roles and responsibilities by name, etc.)?
 Will the product be sold internationally? A number of major project activities are implied by
product localization.
 Is the product subject to regulatory compliance such as UL, CSA (Canada), CE (European), etc.?
A number of major project activities are implied by compliance requirements.

8. Technology and Risk

Describe here the technology to be used in developing the product or service. Then identify and describe
the key project and product risks and the mitigation plan for these risks.

When discussing technological innovations, categorize them by their risk level. For example, very low
risk technology is done often by both the prospective development team and other organizations. Mid-
risk technology has been done by other organizations and by perhaps some members of the prospective
development team. High-risk technology has never been done by the prospective development team and
has rarely been done at all by anyone. Extremely high-risk technology has never been done before –
sometimes referred to by engineers as “science” or “research”. Such extremely high-risk technology is
virtually impossible to schedule. If a project has both a critical time-to-market constraint and an extremely
high-risk technology component, then the risk analysis of the project should show a prohibitively high
value for project risk. Such a development project should either be re-planned to reduce risk to an
acceptable level or else reclassified as a research project with a high-risk schedule.

The number of possible risk topics is large and clearly depends on what is being developed. Here is a
sample list of topics that may affect project or product risk:

 The extent to which software will be reused or developed from scratch

 Availability of single sourced components, now and future
 Risk of electromagnetic interference susceptibility of a new electronic layout
 Stability of a current product architecture
 True (not “datasheet”) behavior of components involving new technology
 Availability of resources in narrow fields of expertise

If you create a detailed risk assessment or analysis, it should be referred to in this section.
Development Project Plan

9. Management And Organization Of Project

Outline here what product development process model will be employed in this project. If your
organization has a standard product development process model, you can list the extensions, deletions,
and other alterations and customizations to the standard process model. If your organization does not
have a standard process model, then this section is a good place to document at least a rudimentary
development process outline that you intend to follow. The outline should include the following:
 The development phases and the principal activities in each phase.
 The gating review criteria for passing from one phase to the next.
 The project communication plan: how status will be gathered and reported, how progress will be
reviewed.

10. Prototype Management

The management of engineering prototypes is often neglected in planning a project. The result is that
later in the project there are not enough engineering prototypes of the correct type to satisfy all functional
groups’ needs. Tasks that require prototypes are blocked, or inadequately performed, and a significant
amount of time is wasted in the overhead of scheduling and moving precious prototypes around from
group to group.

Pole your core team and extended team and draw up a list of prototype needs. The list should include
who needs them, when they will be needed, and for what purpose. Keep in mind that some prototypes
have differing requirements for functionality. For example, some safety compliance test units must have
final hardware/software, marketing demos and photo-shoot models may have limited functionality, alpha
(internal) and beta (external) test units may have differing levels of quality and defects. When you have
the “wish” list from your prototype customers, plan the build schedule, cost, etc.

You should also plan the management of the prototypes – who is going to track them and how.

11. Special Development Methods And Tools

List any special development methods and tools that may increase project risk. Note any anticipated
long-lead times in obtaining special tools or creating special development methodology. You want to be
sure to keep these issues very visible in this overall plan so that they are not forgotten and so that risks
associated with them are mitigated as early as possible in the project.

12. Software Development Plan

If this project includes software, describe the type of software and outline the development methodology
to be used. If your organization has a standard software development process model, you can list the
extensions, deletions, and other alterations and customizations to the standard process model. If your
organization does not have a standard process model, then this section is a good place to document at
least a rudimentary development process outline that you intend to follow.
Development Project Plan

13. Alpha and Beta test plan outline

State how alpha (internal) and beta (external) tests will be conducted, including which customers will be
the testers, how feedback will be obtained, who will be supporting the test units, and how the test
feedback will be reviewed and additional development tasks will be incorporated into the development
schedule.

14. Product Quality Assurance Plan

This section describes what project activities are planned to ensure compliance with your organization’s
quality plan. These activities include component qualification, MTBF prediction procedures,
environmental and safety testing, etc. If you are developing products under ISO 9000/9001 or CE mark
certification, you should state the principal activities and documents you need to create, such as a
Technical File.

If the Product Quality Assurance Plan or any of its components is extensive, then put it in a separate
document and refer to it here with a short summary.

You may want to break out major product quality assurance activities into more detail. Examples are
software quality assurance planning and safety/compliance planning.

14.1 Software Quality Assurance Plan Outline

Describe here the principal activities of software quality assurance that will be done during the project to
ensure adequate fitness for use of the software. Principal elements of a SQAP include the following:

 Risk analysis and mitigation plan.

 A validation plan describing how product requirements will be validated by testing, reviews,
inspections, and other techniques.

 The principal reviews and audits that will be done during the project.

 Documentation deliverables

 Resources, roles, and responsibilities

14.2 Safety/Compliance Plan Outline

If the product or service must comply with electrical safety standards, other product safety standards, or
industry-specific regulatory requirements, outline the plan for verifying compliance with the applicable
standards. Include the laboratory testing required, the documentation that must be created, and any
pending changes in compliance standards that might affect the project or product.

If the Compliance Plan is extensive, then put it in a separate document and refer to it here with a short
summary.
Development Project Plan

15. Manufacturing Plan

Identify, describe, and assign responsibility for the principal activities necessary to prepare your
organization for manufacturing the product or service. Possible activities include the following:

 Production flow charts and process instructions

 Development support during pilot production, production process audits, etc.
 Test plans, special test fixtures, and special test software development plans
 Long-lead or other high-risk components

16. Service Plan

Identify, describe, and assign responsibility for the principal activities necessary to prepare your
organization for servicing the product or service. Possible activities include the following:

 The overall service policy for the product, including troubleshooting, on-site repair, and factory
repair.
 Critical servicing requirements, such as MTTRs, guaranteed availability requirements, etc.
 Any special servicing needs, such as remote servicing, periodic calibration, special test modes,
preventive maintenance, etc.
 The creation of Service Instructions and other service documents.
 The development of any special servicing tools, test equipment, hardware, and software.
 Incorporation of the product in a complaint tracking system
 Product Warranty
 Preparation of training materials and the training of service staff.

17. Technical Publications

Identify, describe, and assign responsibility for the principal activities necessary to create all technical
publications for this product or service. Possible activities include the following:

 The process and resources to be used for creation of operator’s manuals, service manuals,
product and packaging labeling, etc.
 The process and resources to be used for any foreign-language translations.
 Preparation of technical and other information by development staff for the technical publications
staff.

18. Project Team

Identify each project member by name, role, and core responsibilities.

If a separate roles and responsibilities matrix is created, then summarize the major responsibility areas
here and include a reference here to the matrix document.
Development Project Plan

19. Project Milestone Schedule

Specify the major milestones, even if preliminary. For a phased project development methodology, the
dates on which phase transition is anticipated should be listed.

----- End Of Document -----