Project Management Plan for

‘<Project Name>’

Template : PMPlan Template_ver5.6

Doc Name : PMPlan <Project Id>_ver<x.y>

5
Revised By Revised On Version Changes Made Reference

Gurdev Singh & 6th Oct 09 1.0

Deepak Sharma
Gurdev Singh & 20th Oct 09 1.1
Deepak Sharma
Gurdev Singh & 13th Nov 09 1.2
Deepak Sharma
Harjeet Kaur 13th Jan 2011 2.0

Harjeet Kaur 6th July 2011 3.0 Changes made in section 3.8, 5, 6.2

Harjeet Kaur 18th Aug 2011 3.1 Changes in section 3.3 and added
section 7.1
Harjeet Kaur, 6th Sep 2012 4.0 Redefined the template as per GAP
Pooja Rana analysis
Pooja Rana 22nd Oct 2012 4.1 Define roles and responsibilities of
HR and IT in section 3.4, Added
new section 9 for DAR,
Pooja Rana 24th Jan 4.2 Added Validation method of the
2012 unit testing and Annexure for the
non-functional requirement
Vinod Kumar 4th Nov, 2014 5.0 CSD removal, BKO process, Team
Sharma structure changes, modification of
some other processes.
Vinod Kumar 27th Nov, 5.1 Quality Activities, CRM, phases of
Sharma 2014 the project, Metrics
Vinod Kumar 16th Apr, 5.2 New team structure, all reference
Sharma 2015 to previous roles updated with the
new one. Minor updates in 10.3
quality attributes
Vinod Kumar 5.3 Cover page clarification for As per
Sharma Document Name and Template ID SEPG
3.1 Project overview and SDEI meeting
Scope dated
3.2 Role of Project Team June 30,
2015
3.5 Clarification in Project
Deliverables
5.5.1 Communication -Client issue
tracking tool
10.1 Verification Activities –
specified the frequency

5
 Deepika Joshi 04th Sep,2015 5.4 3.1 Project overview As per
3.1.2 SDEI Scope SEPG
3.1.3 Project Category (mention meeting
A/B/C as per Tailoring Guideline
3.3 Work Product
Responsibilities of Teams
3.5 Project Deliverables
3.8 Phases of the project
6.2 Environment - H/w & S/w
Requirements for servers
7.5 Configurable Items and
Baseline Criteria
7.7 Release Strategy & Mechanism
7.1.1 Naming Conventions for
Project Docs
Added sec 8 - Project Assumptions,
Dependencies and Constraints

Deepika Joshi 01stOct ,2015 5.5 7.1.1 Naming Conventions for As per
Project Docs SEPG
meeting
Deepika Joshi 27th Jan ,2016 5.6 3.1 Overview and scope of work As per LA
suggestio
n
<”Please remove the revision history from the above table and replace it with
revision history of this PMP within your project”>
<Please remove all text in <..> Brackets after filling in the text>

5
Table of Contents
1 Objective 6
2 References 6
3 Project Planning 6
3.1 Project overview and Scope of Work 6
3.1.1 Technical Approach. 6
3.1.2 SDEI Scope (mention the SDEI scope and Life Cycle of project – Design and Development/
Maintenance) 6
3.1.3 Project Category (mention A/B/C/D/E as per Tailoring Guidelines) 6
3.2 Project Organization and Responsibilities of Stakeholders: 7
3.3 Work Product Responsibilities of Teams 8
3.4 Client Team Information 10
3.5 Project Deliverables 10
3.6 Receivables with respect to Deliverables 10
3.7 Lifecycle/Processes of the project 11
3.8 Phases of the project 11
3.9 Tailoring Applied 13
3.10 Standards, Practices and Conventions: 14
3.11 Reusable Components (Mandatory) 14
3.12 Project phase and schedule (Ref. VP) 14
Project Milestones, Project Plan and Release Wise Estimations 14
4 Training Plan 14
5 Project Tracking Processes 14
5.1 Team & Mailing lists 14
5.2 Communication processes 15
5.2.1 Project Communication 15
5.2.2 Communication tools 15
5.3 Tracking 15
5.4 Project Meetings Chart 16
6 Project Facilities and Resources 16
6.1 Third Party Tools 16
6.2 Environment - H/w & S/w Requirements for servers 16
7 CM Plan 17
7.1 Naming Conventions for Label or Branch Creation 17

5
 7.1.1 Naming Conventions for Project Docs 17
7.2 Project SPDB Details 18
7.3 Backup and Recovery Mechanism 18
7.4 Directory Structure 19
7.5 Configurable Items and Baseline Criteria 19
7.6 Change Management Strategy 20
7.7 Release Strategy & Mechanism 20
7.8 CM Audit 21
8 Project Assumptions, Dependencies and Constraints 21
9 Risk and Issue Management 21
10 Decision Analysis & Resolution 22
11 Project Quality Activities 22
11.1 Verification Activities 22
11.2 Validation Activities 23
11.3 Quality Attributes 23
Description of Non Functional Requirement: 23
11.4 Metrics 24

5
 PMPlan <Project Id> Ver <x.y>

1 Project Planning
The objective of this Project Management Plan (PMP) is to define the approach to be used by
the Project team to release the Project Deliverables as per agreed schedule, effort and quality
parameters.

2 Project Objective
2.1 Project overview and Scope of Work
<Brief overview of the Project vision/purpose/objective/SLA/functionality of the application>

Refer SOW/Proposal/wire frames/Elance PMB < (Tick as applicable)>

2.1.1 Technical Approach.

Platform:

<The technical approach defines a top-level strategy for development of the products. It
includes decisions on architectural features, such as distributed or client server.

2.1.2 SDEI Scope (mention the SDEI scope and Life Cycle of project – Design and
Development/ Maintenance)
2.1.3 Project Category (mention A/B/C/D/E as per Tailoring Guidelines)

2.2 Project Deliverables

S. No. Deliverable I/E

1 Requirement Document <specify> E
2 Database Design Document/Schema (optional) E
3 Project Management Plan I
4 Project Schedule E
5 Quality Plan I
6 Test Cases / Unit testing check list I
7 User Manual (if required for application) I
8 Software (executable)/ Source Code E
9 Release cum Acceptance Sheet E

Page No. 6
 PMPlan <Project Id> Ver <x.y>

10 Metrics in VP I
11 Project Closure Report I

(Legends; I = Internal, E = External)

2.3 Receivables with respect to Deliverables

S. No. Receivables
1 BDG email for proposal/ Approval from client on wireframes
Approval from client on Project schedule (put your email if no
2
confirmation received)
3 Mockups/Designs/PSDs/Wireframes
4 Milestone Delivery/Release Acceptances
3 Sign Off

2.4 Lifecycle/Processes of the project

The project will follow QMS.

The <Project name> project will follow the <specify> Life Cycle Model as specified in the SDLC
Process. Tailoring specified in tailoring section.

2.5 Standards, Practices and Conventions:

The project will follow the following standards

 Documentation Standards: <Any design/ documentation standards followed in the project,

could be client supplied. >

 Coding Standards: < (For e.g. PHPMD used in PHP). If Coding Standards other than ones
present in our coding guidelines are used, please mention about them in this section.>

3 Training Plan
Domain for Skill Team Available Skill Waiver Planned Training
which training Requirement Member Training Method
is required For project Name Date

Internal
Trainer

Page No. 7
 PMPlan <Project Id> Ver <x.y>

4 Project Facilities and Resources

4.1 Third Party Tools

4.2 Environment - H/w & S/w Requirements for servers

H/W: [Mention the requirements – Processor, RAM, Hard Disk and Peripherals required]

S No. Name Min. supported Max supported H/W URL

H/W requirement
1 Development server XX Ghz processor, [Put n/a if not
applicable]
YY GB RAM,
ZZ GB HDD/SSD
2 Staging server XX Ghz processor, [Put n/a if not
YY GB RAM, applicable]
ZZ GB HDD/SSD

3 Production server XX Ghz processor, [Put n/a if not

applicable]
YY GB RAM,
ZZ GB HDD/SSD
S/W: [Mention the version of the software to the lowest level along with the name.]

S No S/W Supported Devices List all supported comment

Name S/W versions
1

(Note: It’s must for all mobility projects to define devices and supported operating systems.)

4.3 Change Management Strategy

1. All the new changes specified by client during the development phase are first analyzed
by the development team and a change request document containing the Impact Analysis,
estimates related to time and resources required to make the new changes is created.

Page No. 8
 PMPlan <Project Id> Ver <x.y>

2. Change request document is sent to Director – Delivery/ Sr. Manager/ BDG for review.
Once approved, the Manager/Sr. Associate/PO sends the document to the client for his/her
approval.
3. If the document is approved by the client then Manager/ Sr. Associate/PO makes the
necessary changes in the project milestones and all impacted Configurable Items are
revised.
4. Change Request form is updated on SPDB by Sr. Associate/PO.

5 Project Assumptions, Dependencies and Constraints

The assumptions, constraints and dependencies can be identified and documented throughout
the project’s life cycle. These parameters play an important role during the planning process.
Risk management plan is heavily dependent on them. If we fail to properly analyze them, it may
affect the project’s objectives.

 An Assumption is a belief of what we assume to be true in the future. We make

assumptions based on our knowledge, experience or the information available on
hand.

 Dependencies are the relationships among tasks which determine the optimized
sequence in which activities need to be performed.

 Constraints are limitations imposed on the project, such as limitation of technology,

cost, schedule or resources.

Assumption/ Dependency/ Description

S.NO
Constraint

5.1 Quality Attributes

Description of Non Functional Requirement:

Apart from bug-free functionality, the nonfunctional requirements that are identified in
SOW/proposal. If not explicitly mentioned there, then it should be identified and documented in
this PMP, as applicable.

Page No. 9
 PMPlan <Project Id> Ver <x.y>

Non-functional Description Applicable Remarks

Requirement (Y/N)
Usability Usability is assessed by considering
human factors, overall aesthetics,
consistency, and documentation.
Reliability Reliability is evaluated by measuring
the frequency and severity of failure,
the accuracy of output results, the
ability to recover from failure, and the
predictability of the program.
Performance Performance is measured by
processing speed, response time,
resource consumption, throughput,
and efficiency.
Security Security (system security) at user
authentication, database and data
transmission levels.
Supportability Supportability combines the ability to
extend the program (extensibility),
adaptability, serviceability,
maintainability, compatibility,
configurability - the ease with which a
system can be installed, and the ease
with which problems can be localized.
Implementation/ Implementation (resource limitation,
Interface/ language and tools, hardware)
Operations Interface (constraints posed by
interfacing with external systems)
Operations (system management in
its operational setting)
Legal Legal Compliance to any Acts or
Regulations

Page No. 10