Project Management Fundamentals - V1.0

Project Management
Fundamentals
- Customized for JK Technosoft
Chapter - 01
Introduction
Ground Rules
Scope vs. Time
Cell phones
Interactive Class
Time to start / end !
Tolerance Limit - 10 Minutes / 80% of the class strength
Keep an open mind & do not always link the concepts with your job
Smile on the face
Agenda
Chapter
Topic
Day
Project Management Basics
Project Scope Management
Project Time Management
Project HR Management
Project Quality Management
Project Risk Management
Project Communication Management
Change Control Process
10
Case Study - Project Plan presentation by workshop participants
1&2
Introduction - Faculty
Certified PMP, ITIL
23+ Years of industry experience
9+ Years on Project/Program Management positions
11000+ hrs. of classroom training experience
5500+ Managers trained across industries
475+ Management workshops conducted
Introduction - Participants
Name
Overall Experience
Experience in Project Management
Expectations from PM Fundamentals Training Program ( Top 2)
Goal of PM Fundamentals Training

Understand the importance of Project Management Processes and Procedures
Understand practical How To approach on Project management
Understand the Project Management best practices and new directions for Project
Management
Understand what tools & techniques, and processes can be implemented
immediately
Thank You
End of Chapter 01
Introduction
Project Management
Fundamentals
Chapter - 02
Survey by PMI chapters in 2005

Key Success Factors
Planning and Procedures 29%
Communications 21%
Knowledgeable staffs 18%
Team Work 13%
Project sponsor influence 14%
Requirements well defined 10%
Key Failure Factors

Sponsor issues 21%
Inadequate resources 19%
Poor Requirements 18%
Project planning 16%
Organization Change 14%
Agenda
Introduction to Projects
Project Vs. Operations
Introduction to Project Management
Project Management Focus
Project Lifecycle
Project Stakeholders
Project Management Knowledge Areas
Product and Project Management Lifecycle
Introduction to Projects
A project is a temporary endeavor undertaken to create a
unique product service or result
-The PMBOK Guide 5th edition
Temporary Endeavor:
With a beginning and an end

Not an on-going effort
Unique Output
Progressive Elaboration
The incremental design and refinement of the initial concept toward the project plan.
Project Vs. Operations

Project
Operations
Attain its objective and then terminate
Sustain the business
Concludes when its specific objectives
Adopt a new set of objectives and the
have been attained
work continues
Performed by people
Performed by people
Constrained by limited resources
Constrained by limited resources
Planned, executed and controlled
Planned, executed and controlled
Temporary
Ongoing
Unique
Repetitive
Project Framework
Organization
Objectives
Work
Strategic
Tactical /
Operational
Projects
Resource
constrains
Operations
Performed by
People
Process
oriented
What is Project Management

Application of knowledge, skills, tools and techniques to project activities
to meet the Project requirements
People with skills, knowledge and
motivation
Procedures and
methods defining the
relationship amongst
tasks
Tools and
Techniques to
perform Processes
PEOPLE
PROJECT
MANAGEMENT
PROCEDURES
TOOLS

Identifying the requirements
Establishing clear and achievable objectives
Balancing the competing demands for quality, scoop, time, and cost
Adapting specifications, plans, and concerns of the stakeholders

Project Manager has to balance the competing factors (included but not limited to)
like Scope Schedule and Cost along with Quality
QUALITY
COST
It is the project managers duty to balance and achieve these three often-competing
goals.
Project Management Lifecycle

Initiating
Processes
Planning
Processes
Controlling
Processes
Executing
Processes
Closing
Processes
Project Management Knowledge Areas

Cost
Time
Scope
Quality
Integration
Procurement
HR
Communication
Risk
Stakeholders
Project vs. Product Life Cycle

A product life cycle is the parent of projects
Product life cycle may start much before the project
Project Life Cycle

A project life cycle is the series of phases that a project passes through from its
initiation to its closure.
All projects are divided into phases, and all projects, large or small, have a similar
life cycle structure.
Life Cycle helps in determining work to be completed in each phase of the project
Feasibility
Analysis
Design
Implementation
Project Lifecycle
System Life Cycle

Requirement
Definitions
System and
Software Design
Implementation
and Testing
Integration and
System Testing
Operation and
Maintenance
Project Stakeholders
Key Stakeholders on a project:
Sponsor
Senior
Management
Customer
Products
End-user
Vendors
Practitioners
Projects Technical
Manager(s)
Challenges in managing Stakeholders expectations:

Stakeholders may have conflicting needs / demands
Negative stakeholders will be against the project and will try to kill the project
You can conduct Stakeholders Analysis during project planning to

manage them better. Stakeholders Analysis is done by creating
Stakeholders Matrix
How to Manage Stakeholders?

Identify ALL of them
Determine ALL of their requirements
Determine their expectations
Communicate with them
Manage their influence
Thank You
End of Chapter 02
Existing Practices
What are the existing Project Management Practices in

the organization?
Project Management
Fundamentals
Chapter - 03
Agenda
What is Project Scope Management
Key Activities pertaining to Scope Management
What is Project Requirements Management
Project Scope vs. Product Scope
Define Requirements
Project Scope Statement
Project Scope baseline - Work Breakdown Structure
Manage Changes to Scope
Why Manage Project Scope

To ensure that the project includes all the work required, and only the work
required, to complete the project successfully.
- The PMBOK Guide 5th edition
Key Processes
Define Requirements
Define Scope
Create WBS
Control Scope
Requirements Management Plan

The requirements management plan is a component of the project management
plan that describes:
How Requirements will be collected
How requirements will be analyzed, documented, and managed.
How requirements activities will be planned, tracked, and reported.
Configuration management activities such as: how changes to the product will
be initiated, how impacts will be analyzed, how they will be traced, tracked,
and reported, as well as the authorization levels required to approve these
changes.
Requirements prioritization process
Product Scope and Project Scope

Product Scope:
The features and functions that characterize a product, service or result
Completion is measured against the requirements
Project
Scope
Project Scope:
The work that must be performed to
Project
Schedule
Product Scope
deliver a product, service or result

Completion is measured against the
Project
Budget
Functional
Requirements
Project
Artifacts
User Interface
plan
Meetings
NonFunctional
Requirements
Implicit
Requirements
Defect
Management
Status
reports
Users
training
Types of Requirements
Product or Business requirements
The desired business objectives driving the project
Defined by the customer (internal or external) organization
Output is Functional Specification Document
Project requirements
The definition of the final project deliverables or end items
Phase, activity, and task objectives / interim deliverables which contribute to
achieving the project and thereby, business requirements
Defined by the project team
Output is Project Scope Statement
Define Requirements
Using the appropriate tool to collect and define the Business and Functional
requirements
Surveys
Focus Groups
Interviews
Observation
Questionnaire
Storyboards
Prototypes
Document the requirements in Requirements Specification Document
Define Scope
Product Analysis
Product analysis, as the name implies, analyzing the product the project will
create
Product analysis can be accomplished through product breakdown, systems
engineering, value engineering, value analysis, functional analysis and quality
function
Alternative Generation
Exploring possibilities of generating different approaches to execute and
perform the project work
General management techniques such as brainstorming, lateral thinking and
pair wise comparison can be used
Application Maintenance - Scope

Scope of maintenance helps determine exactly how much support the maintainer
will give to the customer:
There are many ways to define scope and one of the way can be:
Level 1 : Full maintenance
Level 2: Corrective maintenance
Level 3: Limited corrective maintenance
Level 4: Limited Software Configuration management activities
Project Scope Statement

Project Objectives
Product scope description
Project requirement
Project boundaries
Project deliverables
Product acceptance criteria
Project constraints/assumptions
Initial identified risk
Schedule milestones
Initial project organization
Fund limitation
Configuration management requirement
Approval requirement
Scope Baseline - WBS

A deliverable-oriented grouping of project elements which organizes and defines
the total scope of the project
Each descending level represents an increasingly detailed definition of a project
component
The Work Breakdown Structure breaks down deliverables, NOT work
Work Packages are deliverables, NOT activities
WBS Additional Info

Project components may be products or services
Work not in the WBS is OUTSIDE the scope
Performing organizations utilizes templates from previous projects, while creating
the current WBS
A unique identifier is assigned to each item in the WBS it is called a Code of
Accounts
The lowest level of WBS is called the Work Package. However Work Packages can
be further broken down into activities during Activity Definition process (Time
Management)
Tool to create WBS: WBS Chart pro, MS Project
Manage Changes to Scope

Identify if Project Requirements have Changed
Y
e
s
Determine analysis effort and change impact

Coordinate changes across the entire project
Influence factors that create changes
Manage the actual changes when and if they occur
update the plan
Exercise
Scope Statement
WBS
Stakeholders Register
Thank You
End of Chapter 03
Project Management
Fundamentals
Chapter - 04
Agenda
What is Project Time Management
Key activities pertaining to Time Management
Create Project Schedule
Manage Changes to Schedule
A Simple Question
Are YOU managing the PROJECT ?

OR
Is PROJECT managing YOU ?
Key Activities
Define Activities
Identify Dependencies
Create Activity Sequencing
Estimate Activity Duration
Understand Lead and Lag
Understand Critical Path
Define Schedule
Why Time Management?

Project Time Management will clarify:
When will deliverables be completed?
When will resources be required?
When will key milestones be achieved?
When will the project be completed?
Define Activities
Identify and document the specific actions to be performed
Decomposition
Involves subdividing project work packages into smaller, more manageable
components to provide better management control
Rolling Wave Planning
Rolling wave planning is a form of progressive elaboration
Work in near future is elaborated in detail as more information is available
When less information is available about the project, the activities can be
defined at milestone level
Sequence Activities
identify and document relationships among the project activities
After activity lists are created, they need to be logically sequenced to
Identify the optimal duration of the project
Identify the Critical Path
Plan resource and material of the project
Sequencing of activities can be done using
Manually
Software MS Project, Primavera
A blended approach
Sequence Activities - Methods

identify and document relationships among the project activities
Precedence Diagramming Method (PDM or AON)
The Precedence Diagramming Method (PDM) is the most common method of
arranging the project work visually
Activities --- on Boxes called Nodes
The arrows represent the relationship and the dependencies of the work
package
Activities
Relationship
Activities
Dependency Determination:
Mandatory dependencies
Logical relationships inherent in the set of activities
Also called hard logic
Discretionary dependencies
Dependencies which are defined by the project team or the performing organization
Also called preferred logic or soft logic
These dependencies need documentation as they may impact scheduling options later on
in the project
External dependencies
Represents relationship between project and non-project activities. E.g. projects
requiring government approval
edureka
Types of Dependencies
Finish-to-Start (FS) The finish date of the predecessor task determines the start
date of the successor
High Level Design

F-S
Detailed Design
Start-to-Start (SS) - The start date of the predecessor task determines the start
date of the successor
Scrap the flecking paint off the house
S-S
Prime the house
edureka
Types of Dependencies (contd..)

Finish-to-Finish (FF) The finish date of the predecessor task determines the
finish date of the successor
Onsite KT
F-F
Offshore Infrastructure
Set-up
Start-to-Finish (SF) The start date of the predecessor task determines the finish
date of the successor. This type of relationship is rarely used
Testing lab is available
S-F
Set-up of automation
tools
edureka
Sequence Activities Lead & Lag

Lead and Lags are represented to connote the delays or leads between two
activities
Lead time: The overlap between tasks that have a dependency.

Lag time: The delay between tasks that have a dependency.
edureka
Critical Path Method

The sequence of activities that represents the longest path through a project, which
determines the shortest possible duration.
- The PMBOK Guide 5th edition
The critical path method consists of three distinct operations:
Calculate Forward pass (ES, EF)
Calculate Backward pass (LF, LS)
Calculate Float
edureka
Determining Critical Path

Calculates a single deterministic early and late finish date for each activity based on
specified sequential network logic and a single duration estimate
ES
1
1
Task A
6 Days
2
LS
EF
6
ES
13
7
LF
14
LS
ES
8
Start
ES
1
1
LS
0
Task D
7 days
EF
7
7
LF
8
LS
0
Task B
5 Days
1
Task C
8 Days
EF
20
21
LF
EF
12
12
LF
ES
22
ES
13
13
LS
0
Task E
9 Days
EF
21
22
LS
0
Task F
5 Days
EF
26
Finish
26
LF
21
LF
edureka
Critical Path Analysis

Nature of Critical Path
Critical Path changes while tracking
Changes while change in scope of works
Multiple Critical Paths
Changes while monitoring!
edureka
Define Schedule
Considering Schedule Risk and Optimizing the Schedule
Resource dependencies between projects
Parallel projects with higher priorities
Team members operational responsibilities
Other business or personal commitments
Use appropriate schedule compression techniques:
Crashing
Fast-tracking
Manage Changes to Schedule

Identify if Project Schedule has Changed
Y
e
s
Determine change impact

Coordinate changes across the entire project
Influence factors that create changes
Manage the actual changes when and if they occur
update the plan
Exercise
Define Activities
Create Schedule
Thank You
End of Chapter 04
Project Management
Fundamentals
Chapter - 05
Project Stakeholders Management
Agenda
What is Stakeholders Management
Stakeholders Analysis
Concept of RAM/ RACI
Key Areas of Managing the Team Effectively
Stakeholder Management
Stakeholder Management helps:
Identify the people, groups, or organizations that could impact or be impacted
by the maintenance process
To analyze stakeholder expectations and their impact on the process
To develop appropriate strategies for effectively engaging stakeholders in
decisions making and RTB
Customer is a key stakeholder and customer satisfaction should be

managed as a key objective
Stakeholders vary by:
Level of interest and influence
Level of power and impact
Legitimacy
Power Vs. Interest grid
Responsibility Assignment Matrix (RAM)

A: Accountable
R: Review
I: Input
P: Participants
Define
Requiremen
ts
I/S
Design
Team
Set-up
Pilot
Sign-off
A/R
A/R
A/R
Operations Manager
Quality Leads
People / Phases
Project Manager
HR Executive
Help Desk Engineer
Admin Executive
Finance Executive
Trainer
Supervisor
I
I
edureka
Managing Team - Types of Power

Formal Power:
Power related to position, authority granted by organization
Expert Power
Power earned due to expert knowledge and skills
Reward Power
Power to give rewards, promotions, salary raise, etc.
Penalty Power
Power to penalize, suspend from work, remove from work, etc.
Referent Power
Power gained due to admiration from team, team takes as role model, etc.
edureka
Conflict Management
Conflicts are bad ?
Conflicts are bad, issues created by people and issues to be avoided.
Conflicts are good?

Conflicts are good and need to be confronted in order to bring out real issues and in
turn resolve the issues.
edureka
Conflict Resolution Technique

There are five different approaches to conflict resolution:
Problem Solving
Forcing
Compromising
edureka
Conflict Resolution Technique
Smoothing
Withdrawal
edureka
Abraham Maslows Hierarchy of Needs

Self
Actualization
Self fulfillment, growth, learning, etc.
Esteem
Social
Safety
Physiological
Accomplishment, respect, attention,

appreciation, etc.
Love, affection, approval, friends,

association, etc.
Security, stability, freedom from threat,
etc.
Air, water, food, house,

clothing, etc.
edureka
Hygiene Factors - Frederick Herzberg

Management supervision
Company policy & administration
Positive working condition
Good interpersonal relationship
Job security
Status within the organization
Compensation
Personal life
Presence of hygiene factors will not insure higher productivity but
absence of these factors may result in poor productivity.
edureka
Motivating Agents - Frederick Herzberg

Sense of achievements
Sense of recognitions
Environment for self working
Sense of responsibility
Opportunities of advancement
Opportunities for growth
Motivating agents give desired results if hygiene factors exist.
edureka
Exercise
Thank You
End of Chapter 05
Project Stakeholders Management
Project Management
Fundamentals
Chapter - 06
Agenda
What is Quality Management
Key activities pertaining to Quality Management
Plan Quality
Quality Assurance
Quality Control
Process Improvement Plan
Basic Tools of Quality
What is Quality?
Quality is the degree to which a set of inherent characteristics fulfill
requirements
- The PMBOK Guide 5th edition (Glossary)
Conformance of requirements of the customer - Philip Crosby

Predictable uniformity & dependability at low cost and suited to the market - W.
Edwards Deming
Fitness for use - Joseph Juran
Quality Concepts
The Road Ahead
Definition of Quality
Need for Quality in App Maintenance work environment
Quality Dimensions
Tools for achieving Quality
Quality Dimensions
To be used at a strategic level to analyze quality characteristics
Quality Dimensions
Reliability
Tangibles
Conformance
Responsiveness
Flexibility
Assurance
Security
Tools for achieving Quality

ISO 20000
Total Quality Management (TQM)
CMMI (People Capability Maturity Model Integration)
eSCM (eSourcing Capability Model for Service Providers and clients
PCMM (People Capability Maturity Model)
Quality Metrics
Some of the Key Quality Metrics in Application Maintenance
Environment:
Responsiveness: Time to respond with acknowledge of the request (sometimes the case
may resolved at this level also)
Resolution time: Time to fix for L1, L2 and L3 tickets (eg. L1 to be finished in 2 hours, l2 4 hours, l3 - 12 hours etc.)
On time delivery: OTD (Out of 100 requests, 98 should finished on time so that OTD is
98%)
First Time Quality: (Out of 100 requests, 98 should finished should not return for re-fix
or rework i.e. right at the first time without reopening of the bug then FTQ is 98%)
Productivity: Targeted volume / month
MTBF (Mean Time Between Failure): Bug reopening time or application failure time
(intervals of failure)
MTTF (Mean Time To Fix a bug reported): Goes with SLA as quoted above
MTFR (Mean Time to Final Resolution): Goes with SLA as quoted above
Casual Analysis and Resolution

Causal analysis indicated when out of control situations arise
For a problem or major bug reported, do following to arrive at root causes :
Brainstorming: Identify possibility of future issues / defects
Analyze with data:
o
Analyze MoM trend of FTR (First Time Resolution) or OTD (On Time
Delivery)
MoM trend of L1 request / bugs
Use fish bone diagram

Analyze the root cause and find a solution for preventive and corrective action.
7 Basic Quality Tools

Control Charts
Cause & Effect Diagram
Pareto Charts
Run Charts
Scattered Diagram
Check Sheets
Histogram
Root Cause Analysis (RCA)

RCA is the fundamental breakdown or failure of a process which, when
resolved, prevents a recurrence of the non-conformance.
RCA is a systematic approach to investigate, identify and eliminate the
true root cause of the failure
Why to conduct RCA?
Not to blame people
Not to address the symptoms
Reduce chances of recurrence of the problems
How to conduct RCA?
Investigate an incident or series of incidents
Attempt to understand the underlying cause of the incident(s)
Generate effective corrective actions to prevent and mitigate
incident(s)
Exercise
Exercise Case Study on RCA
Typical Steps in Conducting RCA

Define the problem, collect information
Draw existing process flow charts
Brainstorm, and draw fish bone (cause & effect) diagram
Arrive at root causes
Recommend actions with ownership
Implement, monitor and compare results
Define the Problem

If I had one hour to save the world I would spend fifty-five minutes defining the
problem and only five minutes finding the solution Einstein
ITIL (Information Technology Infrastructure Library) definitions:

Problem: An incident for which the root cause is not known or incident that is
recurring.
Incident: An event that disrupts or degrades the quality of product or service.
88
Define the Problem

If I had one hour to save the world I would spend fifty-five minutes defining the
problem and only five minutes finding the solution Einstein
ITIL (Information Technology Infrastructure Library) definitions:

Problem: An incident for which the root cause is not known or incident that is
recurring.
Incident: An event that disrupts or degrades the quality of product or service.
89
Define the Problem - Techniques

Rephrasing
Employees were asked suggestions to improve productivity (no responses)
Rephrased the problem as ways to make their jobs easier (Got many
responses)
Zoom in or zoom out of problem (different perspectives)

Capturing defects effectively (project perspective)
Reducing rework (business perspective)
Use of questions
What bugs have to be fixed to overcome the issue?
90
Define the Problem - Techniques

Positive phrasing
Productivity of the project is low (negative phrase)
There is an opportunity for productivity improvement (positive phrase)
Reverse the problem

How to lose? (original problem statement)
How to win? (reversed problem statement)
Self contained
Defect density of ABC project is 0.25 Defects / function point from 5 releases
done till September 2008.
91
Define the Problem Collect Information

Key information required to understand the problem
Quantifying the problem
Productivity dropped from 24 test cases / day to 18
Time frame
Problem exists from January 08 to September 08
Area of applicability
All development projects - size > 1000 person-hours
Impact
Customer satisfaction is dipping
Revenues / margins are tapering down
Severe competition from other vendors
92

93
Draw Existing Process Flow Charts

Customer was dissatisfied with the maintenance of ABC application; the Jan 08
release of 10 maintenance requests resulted in rejection of 2 request after UAT
(User Acceptance Testing). This has caused delay in the customers product release
by 2 weeks.
start
Receive the
request
Conduct Impact
Analysis (IA)
Get clarity on
queries and
finalize IA
Conduct unit
testing
Update the code

and conduct
review
Build and release

the code
End
Rework
NO
Are
defects
fixed?
YES
94

95
Brainstorm Points
Problem definition: Customer was dissatisfied with the maintenance of ABC
application.
Request was received through telephone and not properly recorded
Impact analysis was not done
Impact analysis was done by developers (not by technical leader)
Impact of related applications / modules was not considered
Impact analysis had certain assumptions not clarified
Answers to clarifications from customer were pending
Clarifications were not correct (provided by not customer SPOC)
96
Brainstorm Points .continued

Clarifications were not updated in the final IA document
Updated IA document was not reviewed
Code was not updated based on IA document
Updated code was not reviewed
Review defects were not fixed
Defects fixed led to some other defects
Unit testing coverage was not adequate
Unit testing defects were not fixed / were not adequately addressed
Some of the fixes by team members were not part of the build / old code was
used for build
Wrong version was released
97
Key Points - Brainstorming

ENSURE
Understanding of the problem definition
Participation across and within groups
AVOID
Criticism of causes (ideas) generated
Discussions while thinking & writing causes
Solutions to the problem
Hitch-hiking on ideas
98
Draw Fish Bone Diagram

It is also known as Cause and Effect diagram or Ishikawa diagram
Helps to structure the brainstorm points and arrive at root cause
Resembles a fish with head as the effect and the bones as causes
Causes are further drilled down to secondary and ternary causes
5 Why technique is used for the drill down
RCA
99
Fish Bone Diagram

Elaborate the bones (major causes) using 5 Why technique
100

101
Arrive At Root Causes

Collect data related to the causes listed
Causes
Data (out of 100 requests in

past 6 months)
Impact analysis not upto date
IA did not consider all applications
Backup SPOC not identified
Test case coverage was low
15
Assumptions not clarified
Code not reviewed
Defects not fixed
Fixes led to side effects
Wrong version
Code modules missed in the build
102
Arrive At Root Causes - Identify Problem Steps

Highlighted the problem steps
start
Receive the
request
Conduct Impact
Analysis (IA)
Get clarity on
queries and
finalize IA
Conduct unit
testing
Update the code

and conduct
review
Build and release

the code
End
Rework
NO
Are
defects
fixed?
YES
103
Control Impact Matrix

To be used when data is not available for deciding priority
High
Backup spoc
I
M
P
A
C
T
Low
Unclear assumptions
CONTROL
IA not update
Low test coverage
Code not reviewed
Defects not fixed
Improper fixes
Wrong version
Missed code modules
High
104

105
Recommended Actions
Causes
Action items
Identify backup SPOC

Backup spoc (customer end)
IA review
IA Review
Build &
Release
Prepare checklist for IA

completion
Modify projects process to
include review of IA document
using the above checklist
Conduct release review
meeting to check :
1. Defect fix
2. All reviews and results
3. Test coverage results
Action by
By Date
Status
Project
Manager
(customer &
Vendor)
28 Dec-09 Open
Tech Leader
Vendor
12- Jan 10 Open
Project
manager
28-Dec-09
Delivery
manager
OnNext release going
Open
106

107
Arrive at Root Cause

Pareto chart
Key causes
Low test case coverage is still a problem but other causes were brought
into control.
Pareto Diagram
20%
100%
0.909190%
18%
0.8182
16%
0.7273
70%
Rel. Freq.
0.6364
12%
60%
0.5455
10%
0.0909
0.0909
0.0909
0.0909
0.4545
0.0909
0.0909
0.0909
0.0909
0.0909
8%
50%
40%
Cum. Rel. Freq.
0.7273
14% 0.1818
80%
0.3636
6%
30%
0.2727
4%
20%
2%
10%
0%
0%
1
10
108
Implement and Monitor Results

Ensure implementation through internal audits and project reviews
Collect metrics related to defects after UAT and compare the results
If results are not satisfaction, further RCA is to be initiated
When improvements are noticeable fine tune the process if required.
109
Triggers for RCA

Reactive
Effort variance is high after design phase
End of the phase defects analysis
Internal defects are high after increment 1
Customer reported bugs are more than the target
Proactive
Strategies for achieving project goals
Planning for improvements
Preventing internal defects for future releases
110
Root Cause Analysis (RCA)

Function
Six Sigma
RCA
Use
Proactive - Reduces process variation
Reactive Identify, reduce or eliminate

root cause
Phases

Definition
Tools
Is/is not, Time line, Input output,

Pareto Chart, Flow Chart
What, When, Where, Significance
Analysis
Tools
Fishbone Diagram, Contradiction

Matrix, FMEA, 5 Whys
5 Whys
Solution
Selection
Selection Matrix, Force Field Analysis,

Brainstorming
Eliminate root cause conditions
Define
Measure
Analyze
Improve
Control
Problem Statement
Risk Assessment
Analyze
Corrective Action
Effectiveness
111
Corrective Action Cycle
Data
Process
Corrective
Action(s)
Process
Analysis
Out of Control
Signal & Data
Action
Planning
Causal
Analysis
Proposed
Action(s)
112
Thank You
End of Chapter 06
Project Management
Fundamentals
Chapter - 07
Agenda
What Risk Management
How to Manage Risk
Risk Vs Issues
Risk Identification in a project
Risk probability and impact
Risk response Plan
Risk Monitoring & Control
What is Risk Management

Risk Management is the name given to a logical and systematic method of
identifying, analyzing, treating and monitoring the risks involved in any activity or
process.
Risk Management is a methodology that helps managers make best use of their
available resources
Risk Management is now an integral part of business planning
How to Manage Risk

The Risk Management process steps are a generic guide for
any organization, regardless of the type of business, activity or function.
Establish the context
Identify the risks
Analyse the risks
Evaluate the risks
Treat the risks
Risk is dynamic and subject to constant change, so the process includes continuing
Monitoring and review

Communication & consultation
Risk vs. Issue
Risk
Issue
Risk is an uncertain event or event that

might happen in future
Issue is an event that has already occurred
Once risk is identified, its impact should be

analyzed and the response plan should be
prepared
Once the impact of Issue is analyzed, the

same should be resolved or escalated
Risk Identification
The Risk identification process involves
Identifying the different sources of risk or risk categories and
Applying appropriate risk identification techniques to identify risks that may
affect project
Risk identification needs to be Structured and Repeatable
Participants in risk identification could include
Operations/Project/Process Manager
Process Teams
Risk management team / risk manager
Subject Matter Experts from outside the project team
Customer, end users
Other stakeholders
Types of Risks
Operational risks: Possible slippages on quality, cost or speed of process
execution etc.
Strategic risks: Related to issues such as protection of intellectual property,
security and privacy etc.
Composite risks: Longer term risks, such as losing the capability to execute such
business processes in-house in the future due to loss of talent and knowledge of
the business process.
Technological risks: Related to issues such as network outage, application
downtime etc.
Process risks: Poor CSAT score.
Analyze Risk Probability and Impact

The three components of risk: R = P * I
R - Risk
P - Probability of Risk Event
I - Impact of Risk Event (Risk Event Value) and the relationship between the
components
Analyze Risk Probability and Impact

Example: Guidelines for determining Probability
Probability Description
Category
Probability
Value
Probability of event occurring is more than 50/50
Very Likely
0.8
Probability of event occurring is around 50/50
Probable
0.5
Probability of event occurring is less than 50/50
Less Likely
0.3
Impact on Schedule
Impact on Effort
Technical
Performance
Overall
Impact
Weightage
(Scale 1 to 10)
More than 50%

slippage
More than 50%

slippage
Not achieved
Catastrophic
30% to 50% slippage
30% to 50% slippage
Significant
Critical
10% to 30% slippage
10% to 30% slippage
Some
reduction
Marginal
None
Less than 10%
Minimal
Negligible
Risk Response Planning

Strategy for Negative risks or Threats:
Risk Mitigation
Risk Avoidance

Involves changing making changes to plan to

eliminate the threat posed by an adverse risk
Examples:
Selecting only high experienced people for the
key processes
Extending TAT for major bugs

Risk Acceptance
For those risks which cannot be avoided or where

the cost of avoidance is not justifiable, risks are
accepted
Examples:
Change in government regulations leading to
rework in the project
Defining measures to prevent risk from occurring

The implementation of risk mitigation will be
initiated very early to ensure that the impact and / or
probability is low
Examples:
Develop prototype if the technical solution is
built on a new technology
Planned training of resources before project
starts
Risk Transfer
Transfer of risk responsibility to the internal or

external party more capable or willing to manage the
risk
Examples:
Insurance policy is a mechanism for risk
transfer to a third party
Sign-off mechanism
Risk Response Planning

Strategy for Positive risks or Opportunities:
Exploit Reversal of Avoid
Eliminates Uncertainty associated
Share
Enhance (Reverse of Mitigate)

Modifies the size of the opportunity by increasing

the probability and / or impact
Allocating ownership to a third party who is best able

to capture the opportunity
Accept
Action to be determined after the risk occurs. A

decision to accept risk should be communicated to
the stakeholders
Exercise
Risk Register
Risk Response Plan
Thank You
End of Chapter 07
Project Management
Fundamentals
Chapter - 08
Project Communications
Management
Agenda
What is Project Communication Management
Communication Requirement Analysis
Communications Management Plan
General Model of Communication
Manage Communication (Reporting of KPI, Issues, risks, Changes etc)
Communications Management centers on determining who needs what

information and whenand then produces the plan to provide the needed
information.
Project Communications Management includes generating, collecting,
disseminating, and storing communication. Successful projects require successful
communication.
Communication is the key link between people, ideas, and information.
Project plans
Project meetings
Status reporting
Organization charts
Requirements
Contracts
Project presentations
Decision memorandums
New policies or procedures
Historical records
Communication Requirement Analysis

Communication Requirements Analysis: Based on the needs of the
stakeholders. Can be analyzed by Organization Chart
Logistics and location
Internal information needs
External information needs
Stakeholder information
Communication Technology:
Urgency
Availability of technology
Type of project staff
Project duration
Project environment
Communications Management Plan

Acronym
Definition
Who
Sender/receiver
What
Scope of communication
How
Email, telephone, meeting including format
When
Communication schedule, Escalations
Feedback
Confirmed message received and understood
Filing
Retrieval and storing
Delete
Deleting the message permanently
General Model of Communication

Communication is essentially the interpersonal process of
sending and receiving
message.
Medium
Thinking,
Encoding
Message
Message
Perceiving,
Understanding &
Decoding
Perceiving,
Understanding &
Decoding
Feedback
Receiver
Sender
Letter
Fax
Email
Telephone
Body language
Feedback
Noise / Filter
Thinking,
Encoding
Exercise
Project Communication Plan
Thank You
End of Chapter 08
Project Communications
Management
Project Management
Fundamentals
Chapter - 09
Agenda
Configuration Management
Software Configuration Items
Baselines
Change Requests
Change Management Tasks
Configuration Management
Software changes are inevitable
One goal of software engineering is to improve how easy it is to change software
Configuration management is all about change control.
Every software engineer has to be concerned with how changes made to work
products are tracked and propagated throughout a project.
To ensure quality is maintained the change process must be audited.
Software Configuration Items

Computer programs
Source
Executable
Documentation
Technical
User
Data
Contained within the program
External data (e.g. files and databases)
Baselines
A work product becomes a baseline only after it is reviewed and approved.
A baseline is a milestone in software development marked by the delivery of one or
more configuration items.
Once a baseline is established each change request must be evaluated and verified
before it is processed.
Change Requests
Requests can come from users, customers, or management
Change requests should be carefully analyzed as part of the maintenance process
before they are implemented
Some changes requests must be implemented urgently due to their nature
Fault repair
System environment changes
Urgently required business changes
Change Management Tasks

Identification
Tracking changes to multiple SCI versions
Version control
Controlling changes before and after customer release
Change control
Authority to approve and prioritize changes
Configuration auditing
Ensure changes are made properly
Reporting
Tell others about changes made
Change Control Process - 1

Change request is submitted and evaluated to assess its technical merit and impact
on the other configuration objects and budget
Change report containing the results of the evaluation is generated
Change control authority (CCA) makes the final decision on the status and priority
of the change based on the change report
Change Control Process - 2

Engineering change order (ECO) is generated for each change approved
ECO describes the change, lists the constraints, and criteria for review and audit
Object to be changed is checked-out of the project database subject to access
control parameters for the object
Modified object is subjected to appropriate SQA and testing procedures
Thank You
End of Chapter 09
Project Management
Fundamentals
Case Study & Exercise
Thank You
End of
Project Management Fundamentals
Course

Project Management Fundamentals - V1.0

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Project Management Fundamentals - V1.0

Transféré par

Droits d'auteur :

Formats disponibles

Project Management

Smile on the face

Project Management Basics

Project Scope Management

Project Time Management

Project Quality Management

Project Risk Management

Project Communication Management

Change Control Process

Case Study - Project Plan presentation by workshop participants

Goal of PM Fundamentals Training

Survey by PMI chapters in 2005

Key Failure Factors

With a beginning and an end

Project Vs. Operations

Attain its objective and then terminate

Sustain the business

Concludes when its specific objectives

Adopt a new set of objectives and the

have been attained

Constrained by limited resources

Constrained by limited resources

Planned, executed and controlled

Planned, executed and controlled

What is Project Management

Project Management Focus

Project Management Focus

Project Management Lifecycle

Project Management Knowledge Areas

Project vs. Product Life Cycle

Project Life Cycle

System Life Cycle

Challenges in managing Stakeholders expectations:

You can conduct Stakeholders Analysis during project planning to

How to Manage Stakeholders?

What are the existing Project Management Practices in

Why Manage Project Scope

Project Scope Management

Requirements Management Plan

Product Scope and Project Scope

deliver a product, service or result

Document the requirements in Requirements Specification Document

Application Maintenance - Scope

Project Scope Statement

Scope Baseline - WBS

WBS Additional Info

Manage Changes to Scope

Determine analysis effort and change impact

Are YOU managing the PROJECT ?

Why Time Management?

Sequence Activities - Methods

High Level Design

Types of Dependencies (contd..)

Sequence Activities Lead & Lag

Lead time: The overlap between tasks that have a dependency.

Critical Path Method

Determining Critical Path

Critical Path Analysis

Manage Changes to Schedule

Determine change impact

Customer is a key stakeholder and customer satisfaction should be

Level of interest and influence

Level of power and impact