Project

Management
Hands-on Training: Session 2

13 August 2020

Trainers: Satvika & Sridhar

 AGENDA Session 2 - 13.08.2020

1 Deep Dive - Ideas & Feasibility Stage

2 Deep Dive - Planning Stage (1/2)

3 Quiz - 02

4 Assignment - 02 Brief
 AGENDA Session 3 - 18.08.2020

1 Deep Dive - Capability : Planning Stage (2/2)

2 Deep Dive - Capability : Build Stage

3 Quiz 03

4 Assignment - 03 Brief
 AGENDA Session 4 - 20.08.2020

1 Deep Dive - Capability : Test Stage

2 Deep Dive - Launch Stage

3 Quiz 04

4 Assignment - 04 Brief
 AGENDA Session 5 - 25.08.2020

1 Deep Dive - Closure Stage

2 Project Budgeting, Cost Mgmt. & Capitalization

3 Quiz - 05

4 Assignment - 05 Brief
 AGENDA Session 6 - 27.08.2020

1 Virtual Project Mgmt. & Trends in PM

2 Assignments De-brief

3 Final Test

4 Session Closure
 The Project Wireframe considering Hybrid Model

IDEAS &
PLANNING CAPABILITY LAUNCH CLOSURE
FEASIBILITY
Design, Built
and Test in
Iterations
The L1 Sprint Planning
Process Design Requirements Conceptual Go-Live &
Ideas Maturity gathering & BAU
Design Hypercare
Assessment Designing Sprint
3-4 weeks/
Solution Sprint Backlog Realisation &
sprint
Daily Scrum
Assessment
determines gap
and/or L1 Product
requirements are Backlog/Release Sprint Review
unclear Plan Sign-off

As-Is Sprint 0 Sprint 1 - n Hardening Go-Live Operate

✓ Business Decision based on ✓ Tool Set-Up for tracking (Like ✓ Sprint Planning ✓ UAT ✓ Plan and Test ✓ Benefit
Business Case Jira) ✓ Change Management ✓ Regression User Support Tracking
✓ Governance & Organisation ✓ Functional Specifications ✓ Design & Build Testing ✓ User Training
Set-up ✓ Cost Governance ✓ Test ✓ Cost Tracking ✓ Hypercare
✓ Vendor Decision ✓ Business approval on Specs ✓ Project Review ✓ PGLS defect
✓ DEMO Build ✓ Backlog planning tracker
✓ Test & Data Approach
7
* There would be a short hardening spring at the end of all the sprints. Generally hardening would be done as a part of each sprint
 Stage Gates
Stage Gates are quality control checkpoints that every project should have to ensure they are run correctly.
The decision gates are used to evaluate if a project meets set criteria, in order to progress to the next stage.
For each Stage Gate, there is a Stage Gate Checklist

Stage Gate Checklist consist of a list of entry and exit gate criteria that the project needs to meet to determine
whether the project can pass the gate and proceed to the next phase of the project. Each criteria is assigned a
certain number of points and the total score for all criteria must reach a certain level in order to pass

8
 Project Wireframe: Project Management Stage Gate
Pre-
Ideas & deployment/
Feasibility Requirement 1 Idea Strategy Prepare Charter

Gathering
PM GATE 1

Design/ Scope Definition & Plan & Start Governance Plan & Start Executing Set Up & Start
Planning Personalization 2 Requirements Sign-off
Project Kick-Off
and Progress Reviews Stage Gates Documentation Management

PM GATE 2

Build/ Monitor & Control Time, Unit/Integration/Smoke

Development 3 Build/Development
Cost & Quality
Define Test Approach Prepare for Test
Test

Capability PM GATE 3

System (Functional) System (Non Functional)

Test 4 Testing Testing
Interface Testing User Acceptance Testing

PM GATE 4

Control Testing
Launch Deployment 5 End User Training Cutover
(Validation Testing)
Release/Go-Live

PM GATE 5

PM GATE 6
Post Go-Live & Lesson’s
Closure BAU 6 Hypercare Monitor service KPIs BAU Learnt/Retrospection
Benefits Tracking
MOVE TO BAU

9
 Ideas & Feasibility
To ensure the formal start to a project. Defines the WHAT. It includes Objective, Scope, Assumptions and
Objectives Constraints of the project
Pre-Deployment/
Phases Design/ Personalisation Build/ Development Test Deployment Post Go-Live & BAU
Requirement Gathering

Innovation
IDEA & FEASIBILITY PLANNING CAPABILITY LAUNCH CLOSURE
Funnel

High Level Prepare Charter

Idea Strategy
Steps

Inputs • Ideas from various

• Initial Project Information • Signed-off Business Case
stakeholders

• Ideas further developed and

• The Business has a concept Lock defined
project idea • The Business Case is
• Project Charter is created
Activity • Initial Project prepared and presented to
and signed-off
Information is the top Management
compiled • The idea is accepted into the
Business Portfolio

Output • Signed-off Business Case • Project Charter

10
 Components of Business Case & Project Charter

Business Case Project Charter

Required for approval of Top Management/Project Sponsor Input
Required for approval of Product Owner to start a project
for go ahead for a project (Go/No for an Idea)

Executive summary Project purpose or justification

Project purpose or justification Measurable project objectives and related success criteria

Project Outline High level requirements Assumptions and constraints

Timeline & Plan High-level project description and boundaries

Business Benefits High-level risks Summary milestone schedule

Risks Summary budget Stakeholder list

Economic Costs (CAPEX related-Reliability, Security, Project Sponsor Assigned project manager
Efficiency, Performance Improvement, Safety
Project approval requirements
Recommendations – For decision making

11
 Typical Project Scenario

Hi, there is a
major problem What
in my project! happened?

12
 Typical Project Scenario
We have started a project
Is there a Business Case
and just few days away in
document with all the critical
Hi, there isofa the build
completion
details like business benefit,
major But
stage. problem
suddenly the What
economic cost, etc. signed
in my project!
Project Sponsor stopped happened?
off by the top management
the project as the top
before start of the project?
management realised that
there is no value to the
organisation

13
 Typical Project Scenario
We have started a project Oh! In that case the project is
Is there a Business Case
and just few days away in bound to fail/close as without
document with all the critical
Hi, there
completion
No isofa have
we don’t the build
any business case and proper
details like business benefit,
major But
stage.
Business problem
suddenly
Case the
document. justification What
a project should
economic cost, etc. signed
in
Wemy
Project project!
Sponsor
started thestopped
project not be started. Its sad that
happened?
off by the top management
the project
when as thegetting
we started top organisation’s valuable
before start of the project?
management
the high-level realised that
requirement resources are wasted
there is no value to the
organisation

14
 Planning – Scope Definition & Requirements Sign-off
To set out what can be achieved, in what timescales and at what cost. Defines the HOW. It is the Project Plan and
Objectives includes activities, tasks, responsibilities, time & resources
Pre-Deployment/
Phases Design/ Personalisation Build/ Development Test Deployment Post Go-Live & BAU
Requirement Gathering

Innovation
IDEA & FEASIBILITY PLANNING CAPABILITY LAUNCH CLOSURE
Funnel

High Level Scope Definition & Plan & Start Governance and Plan & Execute Project Set-Up & Start documentation
Steps Project Kick-off
Requirements Sign-off Progress Reviews Stage Gate Management

Scope Definition Requirement Gathering List of Requirements signed-off Stakeholder Mapping

• Determine existing list of

• Detailed Scope of work is defined • Requirements gathering from the stakeholder and capture their roles
• List of requirements to be signed-
by the Project Manager and signed- various stakeholders like • Populate a stakeholder register and
Activity off from Project Owner
off by the Project Sponsor customers, users, vendors, others agree on stakeholder management
strategy

• Project resources assigned

• Signed-off List of Requirements
• Scope of Work Document
• For Agile Process, Final list of
Output • All documentation templates like • List of Requirements capture
requirements to be converted to • Stakeholder Register and their roles
Project plan template, Action Log (functional, system, technical. etc.)
user stories and placed in product
template, Issue Log template, Risk
backlog
Log template

15
 Scope of Work Document
▪ A Scope of Work is a framework document that will outline the work that will be
performed under a contract or subcontract
▪ This is NOT an actual contract, but it will detail the expectations for the job or project
WHAT IS SCOPE OF
▪ A Scope of Work is typically broken up into various sections that detail the specific
WORK(SOW) tasks/deliverables and their individual deadlines
DOCUMENT? ▪ This information ensures that all the parties are aware of their responsibilities regarding
the assignment
▪ SOW should be clear, concise, thorough, and easy to comprehend

TYPICAL COMPONENT OF SCOPE OF WORK DOCUMENT

Objectives: What is the purpose of the project? What are its goals? Tasks: these include a catalog of individual action items required to
complete each phase of the project. asks should be broken down into a
Deliverables and Milestones: What end result must be attained? What work breakdown structure (WBS)
are the deadlines or delivery dates for each phase of the project?
Inclusions: this includes anything included in the project in the SOW
Variables: Variables include cost, schedule, resources, and the
technology required for each phase of the project, from initiation to
Exclusions: this includes anything not included or specifically stated in
completion.
the SOW
Requirements (besides actual output): requirements include all things
16
necessary to support the project.
 Typical Project Scenario

Oh! What
My Project is not happened?
going well?

17
 Typical Project Scenario

Do you have the

There is a major Oh! What
signed-off scope
scope
My creepisand
Project not happened?
document?
don’t know
going how
well?
to handle?

18
 Typical Project Scenario

If the scope document

had been
Do you signed-off
have the
I There
have aisvery rough
a major Oh! What
before thescope
kick-off
signed-off
scope
scope
My document,
creep
Project isand
not happened?
meeting, then you could
document?
but it isknow
don’t
going not signed-
how
well? have managed this
off
to handle? situation well

19
 Components of Requirements Management
Project overview: Will come from the Project Charter The requirements gathering process: Describe the process that you
will use to elicit, analyze and document the requirements
Stakeholders considered for Requirement gathering: This will come
from the stakeholder mapping document based on which the list of
stakeholders for requirement gathering will be finalized Roles and responsibilities: Roles that will be involved with
managing the requirements through the rest of the project lifecycle
Tools: Describe any automated tools that will be used to manage the
requirements
Requirements traceability: The overall process of requirement
Change control: There should be a formal process to manage changes tracking (tracing) throughout the rest of the lifecycle to be detailed.
to the requirements. The entire project should have a formal scope This process should then be added to the schedule to ensure the
change process which should be specifically applied to the changes in proper tracking of requirements occurs throughout the rest of the
requirements too project

Typical document which are Business Requirement

Requirement Traceability Matrix
required for Requirements Document
Management
(Note: Some of the documents might
Functional Specs Technical Specs
be a combined document in some
cases)

20
 Most of the issues that cause
project failure, including scope
creep, poor communication, lack
of stakeholder involvement and
inadequate sponsor support is due
to gap in understanding of
requirements

Requirement gathering is an essential part

of any project. It is the process of
determining, documenting and managing
stakeholder needs and requirements to
meet objectives. Involve all the stakeholders
in the relevant meetings

Benefit: It provides the basis for defining the scope document

 Typical Project Scenario

Do you know the

Hi, I am not sure stakeholders whom
how to do the you must contact for
requirement requirement
gathering? gathering?

22
 Typical Project Scenario

You should have a

Do you know
stakeholder the
mapping
Hi, I am not sure stakeholders
document andwhom
capture
how
No tonot
I am do sure.
the yourequirements
the must contactusing
for
requirement
What to do? requirement
Requirement Traceability
gathering? gathering?
Matrix (RTM)

23
 Typical Project Scenario
RTM will help
Youyou to track
should havethea
requirements, stakeholders
Do you know
stakeholder who has give
the
mapping
Hi, I am not sure the requirements and theand
stakeholders
document project
whom team
capture
How
how RTM dowill
tonot thehelp members assigned to thecontact
requirements.
yourequirements
the must for
using
No I am sure.
me in managing
requirement These requirements are later
requirement
Requirement converted
Traceability
What to do?
project?
gathering? into User Stories inMatrix
Agile Scrum
(RTM)Process
gathering?

24
 Typical Project Scenario

Try to finish the planned

activity on time. Build
buffer for contingencies
and not for the planned
activity

Sign-off is must on
Scope/Requirements/
User Stories to take care
of any scope creep or
scope change

25
 Colloquium Experience Cards

26
 Experience Card - 01

How do you avoid scope creep in your projects? What measures can be put in
place based on your project experience?

Re-prioritise rationally on
Look for alternatives to
Perform impact analysis timeline, skills and business
mitigate impact
requirements

Have interventions on change

Decision making by engaging If vendor goes back on
request with steering
client and calling out risks and commitment, escalate timely,
committee, change control
impact to decide on course of action
board and sponsor

27
 Experience Card - 02

How different Project Management will be for a Thoucian, where the development
team / vendor doesn't formally report to us?

Structured escalation and Client buy-in and then he

Key decision makers who Properly defined and
decision matrix, roles should set the
can help resolve signed off governance
and responsibility and expectation to make your
controllership issues document
scope of work role defined to vendor

Involve in technical, Connect regularly with

Build good rapport by
functional discussions, vendor but keep client
leading and not bossing
and show the value informed and escalate
around the vendor
addition that you bring timely

28