Project Management Plan of XXX software

Doc # Version: 01 Page 1 / 7

Thank-you for downloading the

Project Management Plan Template!

More templates to download on the:

Templates Repository for Software Development

Process (click here)
Or paste the link below in your browser address bar:
http://blog.cm-dm.com/pages/Software-Development-Process-templates

This work is licensed under the:

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License:
http://creativecommons.org/licenses/by-nc-nd/3.0/fr/

Waiver:
You can freely download and fill the templates of blog.cm-dm.com, to produce technical
documentation. The documents produced by filling the templates are outside the scope of the
license. However, the modification of templates to produce new templates is in the scope of
the license and is not allowed by this license.

To be compliant with the license, I suggest you to keep the following sentence at least
once in the templates you store, or use, or distribute:
This Template is the property of Cyrille Michaud License terms: see http://blog.cm-
dm.com/post/2011/11/04/License

Who am I? See my linkedin profile:

http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5

You can remove this first page when you’ve read it and acknowledged it!

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Project Management Plan of XXX software

Doc # Version: 01 Page 2 / 7

TABLE OF CONTENTS

1 IDENTIFICATION 1
1.1 Document overview 1
1.2 Abbreviations and Glossary 1
1.2.1 Abbreviations 1
1.2.2 Glossary 2
1.3 References 2
1.3.1 Project References 2
1.3.2 Standard and regulatory References 2
1.4 Conventions 2
2 Project Management 2
2.1 Team, responsibilities 2
2.2 Work breakdown structure, tasks, planning 2
2.2.1 Task n 3
2.3 Resource identification 3
2.4 Relationships with project stakeholders 3
2.4.1 Customer or end-user involvement 3
2.4.2 Subcontractor management 3
2.4.3 Relationships with other teams 3
2.5 Communication 3
2.5.1 Meetings 3
2.5.2 Reviews 3
2.6 Training 3
3 System requirements and project input data 3
4 Configuration management 4
4.1 Software configuration management 4
4.2 Documentation configuration management 4
5 Software development management 4
5.1 Software development process 4
5.2 Software development tools 4
5.2.1 Tools 4
5.2.2 Obsolescence management 5
5.3 Software development rules and standards 5
6 Tests phases management 5
6.1 Integration tests 5
6.2 Verification tests 5
6.2.1 Phase 1 5
6.2.2 Phase 2 6
7 Problems resolution 6

1 IDENTIFICATION

1.1 Document overview

This document contains the project management plan of software XXX.

1.2 Abbreviations and Glossary

1.2.1 Abbreviations
Add here abbreviations

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Project Management Plan of XXX software

Doc # Version: 01 Page 3 / 7

1.2.2 Glossary
Add here words definitions

1.3 References

1.3.1 Project References

# Document Identifier Document Title

[R1] ID Add your documents references.
One line per document

1.3.2 Standard and regulatory References

# Document Identifier Document Title

[STD1] ISO 13485:2003 Medical devices – Quality management systems –
Requirements for regulatory purposes
[STD2] ISO 14971:2007 Medical devices – Application of risk management to medical
devices
[STD3] IEC/TR 80002- Medical device software -- Part 1: Guidance on the application
1:2009 of ISO 14971 to medical device software
[STD4] ISO 62304:2006 Medical Devices – Software life cycle processes

1.4 Conventions
Typographical convention.
Any other convention.

2 Project Management
The section describes the organizational structure of the XXX project, the corresponding
responsibilities and the flows of internal information.

2.1 Team, responsibilities

The organizational structure is: Describe the team, if necessary

Title Name Responsibilities

Project Manager John Smith Manages the costs, quality and
schedule of the project,
manages relationship with
end users…
And so on …

2.2 Work breakdown structure, tasks, planning

The tasks of the project are described in the table below.
Insert a table or list or diagram describing the tasks.
The Working Breakdown Structure (WBS) of the XXX project identifies all the tasks to the
development of XXX product. If necessary, add a WBS codification.

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Project Management Plan of XXX software

Doc # Version: 01 Page 4 / 7

The planning below contains all tasks of the project and the links between tasks.
Insert a table or list or diagram describing the planning.
Remark: for small projects, a gantt diagram is enough for this section!
Important, list the deliverables and reviews of each phase of the project

2.2.1 Task n
Optional, add a sub-section for each task with:
• Inputs of the task
• Content of the task
• Outputs of the task
• Task reviews (in, if necessary, and out).
Verification tasks are described more precisely in “verification tests” section.
If you instantiate the “software development plan” document, you may add a reference to that
doc and remove these sub-sections.

2.3 Resource identification

If specific resources are need for the project such as a calibrated measurement tool or a
simulator, they shall be identified, referenced and managed in configuration.

2.4 Relationships with project stakeholders

2.4.1 Customer or end-user involvement

Describe how the customer or end-user is involved in the software development: meetings,
reviews, and presentations of intermediate versions …

2.4.2 Subcontractor management

Describe how subcontractors are managed: statement of work, reviews, validation, verification
…

2.4.3 Relationships with other teams

Optionnal
Describe relationships with other teams of your company, like the team in charge of the system
design.

2.5 Communication

2.5.1 Meetings
Describe what kinds of meetings are organized during the project and what happens in these
meeting. This may be described in your quality management system. In this case, this section is
not necessary.

2.5.2 Reviews
Describe what kinds of reviews are organized during the project: launch review, design reviews,
tests reviews and what happens in these reviews. This may be described in your quality
management system. In this case, this section is not necessary.

2.6 Training
Describe training of people involved in the project, if necessary.

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Project Management Plan of XXX software

Doc # Version: 01 Page 5 / 7

3 System requirements and project input data

Reference here the input data from your project , non limited list :
• Intended use
• End user requirements (they may be very unstructured ! like meeting reports)
• Statement of work of your customer
• System requirements
• Risk analysis
• Legacy system documentation
• Any other input data …

And how you manage their possible modification.

4 Configuration management
If you instantiate the “software configuration management plan” document, you may add a
reference to that doc and leave this section and subsections blank.

4.1 Software configuration management

The management of the software configuration may be included in this section: what kind of
SCM tool is used, when branches are made etc...
How is the scm database saved or archived, when and where
How a version is extracted and delivered, for verification phases, for final delivery, for patches
and service packs …
It may be also described either in your quality management system procedures or in a software
configuration management plan.

4.2 Documentation configuration management

This section present the documentation management rules for all documents sent or received
during the XXX project.
It may be also described in your quality management system procedures. In this case, this
section is not useful.

5 Software development management

If you instantiate the “software development plan” document, you may add a reference to that
doc and leave this section and subsections blank.

5.1 Software development process

The software development process chosen for the project is the waterfall/SCRUM/Extreme
programming model (choose yours).
The waterfall/SCRUM/Extreme programming model was chosen for the reasons below: add
justification.

5.2 Software development tools

5.2.1 Tools
Describe the IDE, the SCM tools, any tool used to write and manage requirements, code and
configuration. Don’t forget their versions. SCM tools are described more precisely in
« configuration management »
Examples
• Eclipse + list of plugins or VS2010 + list of plugins
• Purify, boundschecker,

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Project Management Plan of XXX software

Doc # Version: 01 Page 6 / 7

• Git, redmine, Hudson,

• Clearcase,
• Rational Rose, Together J,
• Doors (erk !),
• Bugzilla,
• Any Open source product
• Willy Waller 2006
• And so on …

5.2.2 Obsolescence management

Describe how you manage the obsolescence of software development tools :
• Either you update them when a new version comes up
• Or you stick to a version during the developpement and maintenance.
Explain you choice.

5.3 Software development rules and standards

Describe here the standards and rules used for software development, like modelling (UML),
data modelling, coding rules, …

6 Tests phases management

If you instantiate the “software development plan” document and describe phases in that doc,
you may add a reference to that doc and leave this section and subsections blank.

6.1 Integration tests

Optional.
Describe how integration is managed Phases, reviews, documentation … Even if this may be
described in your quality management system, I recommend you to describe what is forecasted.

6.2 Verification tests

Describe how verification tests are managed. Phases, reviews, documentation … Even if this may
be described in your quality management system, I recommend you to describe what is
forecasted.
Tests is often the weak link of soft development. Thinking about tests at the beginning of the
project is worth the effort.
Example:
Tests are split in four phases:
 Alpha 1 tests: in this phase, V0.1 of software will be tested. Testers will be the software
development team. Each member tests a portion of software developed by another
member. Software will be directly tested on the development platform
 Alpha 2 tests: in this phase, V0.5 of software will be tested. Tester will be the software
integrator. Software will be installed on the integration and test platform.
 Beta 1 tests: in this phase, V0.8 of software will be tested. Tester will be the software
integrator and selected end-users. Software will be installed on the integration and test
platform.
 Beta 2 tests: in this phase, V0.9 of software will be tested. Testers will be selected end-
users. Software will be installed on the pilot platform in ….

Tests phases are described in the software tests plan OR below:

6.2.1 Phase 1
Describe the verification phase:

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Project Management Plan of XXX software

Doc # Version: 01 Page 7 / 7

• In: what is verified (version Vx.y.z)

• Tasks: how it is verified (tests are done according to software test description doc XXX)
• Out: the test report
• Acceptation criteria: how the tests are passed or failed.

Example of acceptation criteria, with bugs levels ratios (dummy but very effective):
• Alpha tests: all blocking bugs are fixed
• Beta tests: all major bugs found in alpha tests are fixed and less than 20% of remaining
bugs are major
• Final version: all major bugs are fixed and 90% of minor bugs are fixed.

Example of acceptation criteria, with rationale about requirements:

• Alpha tests: tests about critical requirements (like those from risk analysis) are passed
and requirements about system-software interfaces are passed
• Beta tests: tests on previous requirements and tests on requirements about main use
cases are passed
• Final version: all tests are passed

6.2.2 Phase 2
Repeat the pattern for each phase
Describe the verification phase:
• In: what is verified (version Vx.y.z)
• Task: how it is verified (tests are done according to software test description doc XXX)
• Out: the test report
• Acceptation criteria: how the tests are passed or failed.

7 Problems resolution
Describe here how bugs, requests, questions … anything coming from anyone outside the
software development team. Especially for bugs, how they are recorded, tracked, fixed.
It may be also described in your quality management system procedures. In this case, this
section is not useful.

Remark: there is no risk management section in this document. This is voluntary, the risk
management plan is an important document and cannot be a section of project management.

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License