Project Management Plan of XXX software

Version: 2024
Doc # Page 1 / 9

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

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
Version: 2024
Doc # Page 2 / 9

TABLE OF CONTENTS

1 IDENTIFICATION 3
1.1 Document overview 3
1.2 Abbreviations and Glossary 3
1.2.1 Abbreviations 3
1.2.2 Glossary 3
1.3 References 3
1.3.1 Project References 3
1.3.2 Standard and regulatory References 3
1.4 Conventions 3
2 Project Management 3
2.1 Team, responsibilities 3
2.2 Work breakdown structure, tasks, planning 4
2.2.1 Task n 4
2.3 Resources identification and management 4
2.4 Secure development assets identification and management 4
2.5 Data identification and management, security and privacy 4
2.6 Relationships with project stakeholders 5
2.6.1 Customer or end-user involvement 5
2.6.2 Subcontractor management 5
2.6.3 Relationships with other teams 5
2.7 Communication 5
2.7.1 Periodic meetings 5
2.7.2 Bugs analysis committee 5
2.7.3 Reviews 5
2.8 Training 5
3 System requirements and project input data 5
4 Configuration management 6
4.1 Software configuration management 6
4.2 Documentation configuration management 6
4.3 Data configuration management 6
5 Software development management 6
5.1 Software development process 6
5.2 CI/CD or DevOps strategy 6
5.3 Software development tools 6
5.3.1 Tools 7
5.3.2 Obsolescence management 7
5.4 Software development rules and standards 7
5.5 Secure coding standards 7
6 Tests phases management 7
6.1 Integration tests 7
6.2 Verification tests 7
6.2.1 Phase 1 8
6.2.2 Phase 2 8
6.3 Security tests 8
6.4 Penetration tests 9
7 Problems resolution 9

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
Version: 2024
Doc # Page 3 / 9

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

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:2016 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:2015 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

Title Name Responsibilities

Project Manager John Smith Manages the costs, quality

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
Version: 2024
Doc # Page 4 / 9

and schedule of the project,

manages relationship with
end users…
Security Advisor Ben Cooper Is in charge of supporting the
design team on software
security matters and
approving secure design
decisions
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.

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 Resources identification and management

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 Secure development assets identification and management

If specific assets are need for the project such as private keys, security credentials, API keys,
hardware dongles, they shall be identified, referenced and managed in configuration.

These assets and may be subject to disclosure, corruption and deletion (non-exhaustive list).
Describe also how Confidentiality, Integrity and Availability of these assets are ensured.

This can be described in a security plan different from this document.

Such a plan is more the job of IT depts than dev team.

2.5 Data identification and management, security and privacy

Optional
If you have AI/ML algorithms, either reference a data management plan (preferred++ solution).
Or add here elements about data identification, management and data security, privacy.

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
Version: 2024
Doc # Page 5 / 9

A/ML data include: training data, tuning data and data for validation.
Data identification can also be described in section 4

2.6 Relationships with project stakeholders

2.6.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.6.2 Subcontractor management

Describe how subcontractors are managed: statement of work, reviews, validation, verification
… At minimum, the statement of work shall contain the need to follow relevant clauses of IEC
62304 and IEC 81001-5-1 when outsourcing development.

2.6.3 Relationships with other teams

Optional
Describe relationships with other teams of your company, like the teams in charge of system
design, system testing, clinical validation…

2.7 Communication

2.7.1 Periodic meetings

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

2.7.2 Bugs analysis committee

Describe how bugs encountered during design are analysed and treated. This may be described
in your quality management system. In this case, this section is not necessary.

2.7.3 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. See also the Software
Development Plan Template.

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

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
• Usability studies
• System requirements
• Preliminary risk analysis or system-level risk analysis
• Legacy system documentation
• Any other input data …

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
Version: 2024
Doc # Page 6 / 9

And how you manage their possible changes.

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 presents 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.

4.3 Data configuration management

This section presents the documentation management rules for all data manipulated during the
XXX project:
 AI/ML Data: see Data management plan xxx,
 Test datasets,
 Tests results,
 Other data….

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 CI/CD or DevOps strategy

If you have such strategy, you may also describe how you implement it

5.3 Software development tools

See also the more comprehensive list in de Software Development Plan template

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
Version: 2024
Doc # Page 7 / 9

5.3.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
• IDE: Sublime text, Visual Studio, Eclipse, don’t forget the list of plugins
• SCM tool: Git,
• CI/CD: Gitlab
• CI/CD for security: Synk.io
• Requirements management tool: Doors (erk !),
• Bug tracker,
• SBOM generator,
• Any other software development tool,
• Willy Waller 2006,
• And so on …

5.3.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 development and maintenance.
Explain your choice.

5.4 Software development rules and standards

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

5.5 Secure coding standards

Describe here the secure coding standards. E.G: OWASP top 25, SEI CERT C++, MISRA C
And also (highly recommended) if you use a static analysis tool to ensure these standards are
verified.
If you don’t, for some rules not manageable by static analysers, how you verify these rules. That
can be manually done in pull requests or in periodic code reviews.

5.6 Software development platform security

Describe how the software dev platform is secured. Security and privacy of source code, security
credentials, other sensitive data. This section can reference other documents at company IT
system level.

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

Describe how integration is managed Phases, reviews, documentation ….
That can be part of CI/CD strategy.

6.2 Verification tests

Describe how verification tests are managed. Phases, reviews, documentation …
Tests is often the weak link of soft development. Thinking about tests at the beginning of the
project is worth the effort.

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
Version: 2024
Doc # Page 8 / 9

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 pre-production
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:
• 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.

6.3 Security tests

Describe here your security testing strategy:
 Security requirement testing (that can be test cases part of verification tests),
 Security risk mitigation testing (that can also be test cases part of verification tests, since
every mitigation action shall be a documented in a security requirement),
 Vulnerability testing:
o Abuse case, malformed, and unexpected inputs,
o Attack surface analysis,

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
Version: 2024
Doc # Page 9 / 9

o Closed box testing / known vulnerability scanning,

o Software composition analysis of binary executable files
 Dynamic security testing.

6.4 Penetration tests

Describe here how penetration tests will be performed, the independence and technical
expertise of testers.

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