Project Management Professional (PMP)
Training
LEARNING OBJECTIVES
• Project Management Concepts
• Introduction to the Workshop
• Project Management Overview
• Integration Management
• Scope Management
• Schedule Management
• Resource Management
• Communications Management
• Stakeholder Management
• Introduction to Agile
Project Management
Overview
ARE THESE PROJECTS?
“Improving employee engagement”
1 National Citizenship Card 6 Initiative
Maintenance of a software application
2 Medical Surgery
7 – major fix lasting 4 weeks
3 year contract given by Boeing to HP
3 for IT Support 8 4 hour Birthday Party
Developing muscle mass to achieve a
4 higher level of fitness 9 Launching McDonalds Restaurant
5 “Friends” TV series
10 Updating the employment agreement
Purpose Of PMBOK® Guide
▪ Stands for Project Management Body Of Knowledge.
▪ The PMBOK Guide is a foundation upon which organizations can build
methodologies, policies, procedures, rules, tool & techniques.
▪ Provides & Promote a CommonVocabulary for Project Management Profession.
▪ Generally recognized as “Good Practice”.
▪ “Generally Recognized – The knowledge & Practices described are applicable to
most projects most of the time, and reached to the consensus about their value and
usefulness.
▪ “Good Practices”- General agreement that the application of the knowledge,
skills, tools and techniques can enhance the chances of success over many projects.
@All Rights Reserved. 5
Purpose Of PMBOK® Guide
▪ PMI Defines the Project Management Body Of Knowledge as a term that describe
within the profession of Project management .
▪ The project Management Body Of Knowledge includes proven Predictive, Adaptive
& Hybrid practices that are widely applied as well as Innovative Practices that are
emerging in the profession.
@All Rights Reserved. 6
PMI-ism
▪ Project Manager is the center of the Project, without skilled PM, a project is destined to fail
▪ The PM puts the best interest of the project first
▪ The PM should assigned during project initiating, not later in the life of the project
▪ Organization must have a formal project selection process
▪ Team members are motivated, empowered and engaged
▪ The PM works within the existing system and culture of the company
▪ Stakeholders are involved throughout the project
▪ Agile stakeholders are represented by product owner as part of the Team.
▪ Team members can see customer perspective through the use of personas
▪ The development approach should also be determined
▪ The PM has authority & Power
▪ No project is complete unless there has been final acceptance from the customer
@All Rights Reserved. 7
PMI® Code Of Ethics & Professional Conduct
✓ Responsibility
✓ Respect
✓ Fairness
✓ Honesty
@All Rights Reserved. 8
PROJECT & PROJECT MANAGEMENT DEFINED
• A project is "a temporary endeavor undertaken to create a unique product or service, or result”
Temporary: has a start and end, unlike operations
Unique: No two projects are the same
Result: Profitability improvement, cost reduction (no service / product here)
PROJECT & PROJECT MANAGEMENT DEFINED
Unique Product, Service or result:
➢ Projects are undertaken to fulfill objectives by producing deliverables.
• A unique product that can be either a component of another item, an enhancement
or correction to an item, or a new end item in itself.
• A unique service or capability to perform a service.
• A unique result, such as an outcome or document.
• A unique combination of one or more products, service or result.
• The output of project may be tangible or intangible.
• Although the repetitive elements may be present in some project deliverables and
activities, this repetition doesn’t change the unique characteristics of the project
work.
PROJECT & PROJECT MANAGEMENT DEFINED
➢ The end of the project is reached when one or more of the following is true-
✓ The project objectives have been achieved.
✓ The objective will not or can not met.
✓ Funding is exhausted or no longer available.
✓ The need for the project no longer exist.
✓ The human or physical resources are no longer available.
✓ The project is terminated for legal cause or convenience.
@All Rights Reserved. 11
PROJECT & PROJECT MANAGEMENT DEFINED
❑ Examples of Projects include, but are not limited to:
• Developing a new pharmaceutical compound for market.
• Expanding a tour guide service.
• Merging two organizations.
• Improving a business process within an organization.
• Acquiring and Installing a new computer hardware system for use in an organization.
• Exploring for oil in a region,
• Conducting research to develop a new manufacturing process,
• Construction a building.
@All Rights Reserved. 12
Project Management
Project Management is the application of
knowledge, skills, tools and techniques to project
activities in order to meet project requirements
Integration of 49 Processes, 10 Knowledge
Areas, 5 Process Groups
▪ Project Management is the Systematic
process of managing the project work
effectively & efficiently.
▪ The systematic process of managing the
projects work takes many forms that exists
along a continuum from predictive
approach to agile and hybrid approach.
@All Rights Reserved. 13
Project Management
Agile is a time boxed, iterative approach to that builds Product incrementally from the start of the
project, instead of trying to deliver it all at once near the end.
It works by breaking projects down into little bits of user functionality called user stories,
prioritizing them, and then continuously delivering them in short two week cycles
called iterations.
There is no perfect recipe for building great product
Agile team use simple, straightforward practices that have been proven to work on real
life projects.
A practice that works really well for one team causes serious problem for another and the
difference is TEAM MINDSET.
That’s why Agile Manifesto & Guiding Principles came.
@All Rights Reserved. 14
Project Management
@All Rights Reserved. 15
Project Management
Progressively Elaborated
Project: Getting to know
more about the project as
time progresses – addressing
the unknowns
@All Rights Reserved. 16
Importance Of Project Management
Effective project management helps individuals, groups, and public & private organizations to:
• Meet business objectives,
• Satisfy stakeholders expectations,
• Be more predictable,
• Increase chances of success,
• Deliver the right product at the right time,
• Respond to risk in a timely manner,
• Optimize the use of organizational resources
• Identify, recover or terminate failing projects
• Manage Constraints ( Scope, Time, Cost , Quality, Resources)
• Balance the influence of constraints on the project
• Manage changes in a better manner.
@All Rights Reserved. 17
Importance Of Project Management
✓ Poorly managed projects or the absence of Project Management may result in:
• Missed deadlines,
• Cost overruns,
• Poor quality,
• Rework,
• Uncontrolled expansion of the project,
• Loss of reputation for the organization,
• Unsatisfied stakeholders.
@All Rights Reserved. 18
Importance Of Project Management
✓ Effective & efficient project Management should be considered a strategic competency
within organizations.
It enables organizations to:
• Tie project results to business goals
• Compete more effectively in their markets
• Sustain the organization
• Respond to the impact of business environment changes on projects by appropriately
adjusting project management plans.
@All Rights Reserved. 19
Process Groups In a Project
UNDERSTANDING THE PROCESS GROUPS
Initiating Process Planning Process Executing Process Monitoring & Closing Process
Group: Define a Group: Establish Group: Perform the Controlling Process Group: Finalize
new project or Scope, Refine work defined in the Group: Track, review activities as defined
phase, obtain objectives, define project plan and and regulate the in plan, formally
authorization, know course of action (the approved change progress and close project or
the stakeholders plans) to attain requests performance of the phase
objectives project; identify
changes required to
plan, initiate the
changes
PROCESS GROUP INTERACTIONS
Business Value
Projects Drive Change:
• From a business perspective, a project is aimed at moving an organization from one state
to another state in order to achieve a specific objectives.
• For some projects , this may involve creating a transition state where multiple steps are
made along a continuum to achieve the future state.
• The successful completion of a project results in the organization moving to the future
state and achieving the specific objective.
@All Rights Reserved. 23
Business Value
Domain-III
Task-04
Organization
Projects Drive Change:
Future State
Business Value
Project Activities
Activity A
Activity B
Current State Activity C
Time
@All Rights Reserved. 24
Business Value
Projects Enables Business Value Creation:
• PMI defines business value as the net quantifiable benefit derived from the business
endeavor.
• The benefits may be tangible or Intangible.
• The business value is considered the return, in the form of elements such as time,
money, goods, or
• Intangibles in return for something exchanged.
@All Rights Reserved. 25
Business Value
Projects Enables Business Value Creation:
Examples of tangibles elements include: • Examples of intangibles elements include:
• Monetary assets • Goodwill
• Stockholder equity • Brand recognition & reputation
• Utility • Public benefit
• Fixtures • Trademarks
• Tools & market share • Strategic alignment
@All Rights Reserved. 26
PROJECTS ENABLE BUSINESS VALUE CREATION/ENHANCEMENT
• Tangible and Intangible benefits - Examples
Monetary Assets
Revenue / Utility
Tools / Equipment
Market Share
Goodwill
Public benefit
Reputation
Brand Recognition
E.g. Radical Improvement in dietary intake of
international level athletes to enable them to compete
better in the Olympics
TOP 10 REASONS WHY PROJECTS TURN UNSUCCESSFUL
•Source: Standish CHAOS Report: 31% cancelled, 52% cost 1.9 times more
Lack of User Input & Involvement
Incomplete Requirements & Specifications
Changing Requirements & Specifications
Lack of Executive Support
Technology Incompetence
Lack of Resources
Unrealistic Expectations
Unclear Objectives
Unrealistic Time Frames
New Technology / Illiteracy
Also: Lack of planning, don’t need it any longer, can’t use what is delivered
BALANCING PROJECT CONSTRAINTS
• How will you handle the following scenarios (independently):
You are assigned as a project
Your manager wishes to pull out 10 resources for some other manager to set up a
1 work, for 20 days manufacturing plant for a
new product line. You have
been given the specifications
for the plant, required
Your finance department recommends cost cutting, and budget, suitable resources,
2 reduces your budget by 10% sufficient time and authority
to execute the project.
Assume that no resource is
kept idle and has some work
New Covid19 regulations require spending extra to ensure
assigned always. You have
3 sanitization and safety requirements, thus implying 10%
more costs
committed to deliver the
project in line with the
targets
Your Product Head wants you to complete the project 1
4 month in advance to get more revenue for the financial year
BALANCING PROJECT CONSTRAINTS
Risk Stakeholders
Procurement
Resources Communication
Organizational Project Management (OPM)
❑ OPM is a Strategy Execution Framework utilizing project, program, & portfolio
management as well as organizational enabling practices to consistently deliver organizational
strategy for better performance, result, & competitive advantage.
❑ OPM advances organizational capability by linking project, program, portfolio management
principles and practices with organizational enablers (Structural, cultural, technological, &
HR practices) to support strategic goals.
@All Rights Reserved. 31
Organizational Project Management (OPM)
Portfolio Reviews & Adjustment
Program & Operations
Portfolio Value
Strategy Projects Business Value
Decision
Result Delivery Realization
Business Impact Analysis
Value Performance Analysis
@All Rights Reserved. 32
SUB PROJECTS, PROJECTS, PROGRAMS, PORTFOLIOS
SUB PROJECTS, PROGRAMS, PORTFOLIOS
Subprojects: Projects are frequently divided into more manageable components or ‘Subprojects”- although the
individual subprojects can be referred to as projects and managed as such.
Program: A program is a group of related projects Managed in a coordinated way to obtain benefits and control , not
available from Managing them individually.
Portfolio: A portfolio is a collection of projects or programs and other work that are grouped together to
facilitate effective management of that work to meet strategic business objectives. Give examples of each of the
above
PROJECTS VS OPERATIONS
Note: Project from a
customer’s point of
view could be
operation from
vendor’s point of
view
Projects: Operations:
• Create own charter, organization, and goals • Semi-permanent charter, organization, and goals
• Purpose of change (current state=>future state) • Purpose of status quo
• Unique product or service • Pre defined & approved product or service
• Heterogeneous teams • Homogeneous teams
• Definite Start –Definite end • Ongoing
• Progressively elaborated process deliverables • Fully known process deliverables
PROJECT MANAGER’S ROLE
Lets say you are assigned as a project manager for setting up a
Theme Park / refinery / building a new software / starting a large
shop or a project for achieving cost reduction. Consider any
project in your company also.
What are the common project managerial activities that you need
to do?
• Note: Acquisition of Land, Constructing the buildings are examples of non-managerial
activities, and they may not apply to all projects. On the other hand, project
managerial activities (such as preparing the project schedule, status reporting) apply
to all projects
PROJECT MANAGER’S ROLE – ENSURE THE FOLLOWING
Benchmarking gives us the chance of gaining:
• Check feasibility; prepare charter • Select the vendors & give them work
• Capture & freeze the requirements • Get the right skilled people
• Chalk out the scope of work • Find out the challenges and how to deal
• Plan for the project • Train the people to do their work
• List of tasks & sequencing • Execute the project (with vendors if needed)
• Estimation of time & resources needed • Get customer to check the product/steps/parts
• Decide what to make and what to buy • Get completion certificate from customer
• Project Costing & Schedule • Wind up supplier delivery; close project (including
• Project Communications lessons learnt capture)788
PROJECT MANAGER’S ROLE – ENSURE THE FOLLOWING
IN PARALLEL, DO ONGOING ACTIVITIES
• Track/Monitor schedule progress
• Manage the team
• Monitor the spending
• Avoid “Extra” work; do as agreed
• Report progress and performance
• Take care of issues and risks
• Check the quality of work
• Check the methods followed
• Identify, track & Make the necessary changes
• Communicate with team and others (stakeholders)
• Get payment; pay the vendors
• Identify & manage stakeholders
• Make sure vendors deliver
• Deliver on approved changes
• Documentation for the above
STAKEHOLDERS AND THEIR ROLES FOR THE PROJECT
Project Sponsor: Provides financial resources, handles
escalations, signs off on the project charter, checks whether
Program Manager: Governance of the project, coordination
the financial resources are utilized appropriately. Takes key
with other projects, programs in the portfolio
decisions on the course of the project (including its
cancelation)
Product Manager: Is the receiver of the work done by the
Portfolio Manager: Governance, balancing of resources,
team. Decides on projects required across the life cycle of
ensures alignment of project within the portfolio
the product
Functional/Resource Manager: Provides the resources
Other Stakeholders: Include End Users (accept the project
needed for the project. Could have different influences
deliverables), Regulatory Bodies (ensure compliance),
based on the structure. May be the beneficiary for the
Impacted parties (want minimal negative impact)
project
INTERPERSONAL AND TEAM SKILLS
• Active Listening • Team Building
• Conflict Management • Decision Making
• Facilitation • Emotional Intelligence
• Meeting Management • Communication Styles Assessment
• Leadership • Cultural Awareness
• Networking
• Political Awareness
• Nominal Group Technique
• Observation and Conversation
• Influencing
• Motivation
• Negotiation
SPHERES OF INFLUENCE FOR THE PROJECT MANAGER
ORGANIZATIONAL INFLUENCES ON HOW PROJECTS ARE DONE
Doing a project in India vs Doing the same project in
1 US/Europe – what changes do you need to take into
account?
2 Doing a project in Nomura and doing the same
project in Barclays – what is the difference?
Doing an ERP Implementation project in IBM and
3
doing it in Pepsi – how is it different?
Doing a project in HSBC vs doing a project in a small
4 NBFC – how is it different?
ORGANIZATIONAL FACTORS INFLUENCING PROJECTS
Size
Workplace Style
Culture
Structure Maturity
Systems
ORGANIZATIONAL PROCESS ASSETS (OPA)
Plans, Processes, Policies, Procedures, and Knowledge Base Guidelines,
product and project life cycles, methods and procedures Includes
Artifacts, Practices or Knowledge relevant for the project Pre-approved
supplier lists, contract agreement formats Includes Lessons Learned
Includes Historical Data / Information on projects executed by the
organization Inputs to most planning processes Configuration
Management Repository Project Files from previous projects Risk, Issue
and Defect Repository
TWO CATEGORIES:
• Processes and Procedures
• Corporate Knowledge Base
ENTERPRISE ENVIRONMENTAL FACTORS (EEF)
• Conditions not under control of team, that influence, control or direct the team
• Organizational Culture, Structure, Governance
• Geographic Distribution of facilities & resources
• Government or Industry Standards Infrastructure
• Resource Availability & Employee Capability
• Personnel policies
• Work Authorization Systems
• Marketplace conditions, Workplace Considerations ,Risk Tolerances of Stakeholders
• Political Climate, Communication Channels in the organization
• Commercial Databases and Academic Research
• Project Management Information System (PM tool)
• IT Software for internal use
• Social & Cultural Influences
EEF can be enabler or disabler
ORGANIZATIONAL STRUCTURE - TYPES
Organic or Simple: Flexible, informal
Functional: Grouped by nature of work/job being done
Multi divisional: Replicate functions by product, production processes, portfolio
Matrix: Strong, Weak, Balanced
Project Oriented – by project
Virtual - network with points of contact
Hybrid - mix of other types
PMO
PROJECT MANAGEMENT OFFICE (PMO)
The PMO may get involved in following or similar types of activities:
1. Provide guidance to project resources / stakeholders
2. Support project Integration tools / enterprise software
3. Co ordinate Lessons learned / knowledge updates
4. Help getting resources for enterprise wide projects
5. Manage resource sharing and intra dependencies
6. Maintain, develop Organizational standard documents
7. Monitoring compliance to these
8. Re-initiate or terminate projects if required
9. Overall mentoring platform for project managers/ resources
Different types of PMO structures:
Controlling: Support & Compliance with moderate
Supportive: Consultation, available when needed control
Directive: Directly managing projects with high control
PROJECT GOVERNANCE
• Why do we need Governance?
• If you are a capable PM, is Governance necessary?
• What constitutes Governance?
• Success Criteria definition
• Project Communication to Stakeholders
• Metrics Reporting
• Status Review Meetings
• Escalation Process
• Audit Function
• Roles & Responsibilities & Reporting Structure
• Deliverable Review Mechanisms
• Stage Gates
• Change Control
PROJECT GOVERNANCE FRAMEWORK: ELEMENTS
Rules
Policies Systems
Project
Governance
Norms Relationships
Procedures Processes
PROJECT PHASES, PROJECT LIFE CYCLE, PHASE RELATIONSHIPS
Sequential Relationship Overlapping Relationship
RA Design Develop Design Develop Test
Concept Ideation Feasibility Study Customer requirement
Project Life Cycle
Prototype Design Solution Development
Commissioning and
Build Test
Handover
OVERLAP OF PROCESS GROUPS IN DIFFERENT PHASES
Project Design
Life Cycle HL Develop/
RA Logic/ Handover/
Plan Construct Test
Proto Implement
Executing
Processes
Planning
Processes
Monitoring &
Controlling
Initiating Processes
Processes Closing
Processes
Project Start Time Project Finish
PROJECT LIFE CYCLES
Adaptive
PROJECT LIFE CYCLES
Predictive / Plan Driven Iterative
PROJECT LIFE CYCLES
Agile / Adaptive (Scrum example)
STAKEHOLDER INFLUENCES , UNCERTAINTY & COST OF CHANGES
6
5
Value at stake
Stakeholder Influences
4
Uncertainty
1
Cost of changes
In the project
Life span of the project
BUSINESS CASE FOR THE PROJECT: CONTENTS
Business Need: the problem or the opportunity
Stakeholders affected
Scope of the project
Analysis of the situation – root causes, contributors
Gap analysis – as is / to be
Recommendation / Implementation Approach – what should be done
Critical Success Factors
Key Milestones
Success Measures – what signifies success and how is it measured?
WHAT DOES PROJECT SUCCESS MEAN?
Delivering the project benefits
Meeting the financial performance metrics (profit, saving, sales)
Meeting the non financial objectives stated in the business case
Move the organization from its current state to the desired state
Fulfilling contract terms and conditions
Meeting organizational strategy, goals and objectives
Achieving stakeholder satisfaction
End user adoption of the project deliverables
The problem statement has been addressed
BENEFITS MANAGEMENT PLAN: CONTENTS
• Tangible and Intangible Benefits
• Strategic alignment – linking the project
to business strategy
• Timeframe to realize benefits
• Benefits owner
• Metrics to measure benefits
• Assumptions
• Risks
Integration Management
WHAT IS INTEGRATION MANAGEMENT?
Ensuring alignment of project deliverables, life cycle
Measuring and monitoring project progress
and benefits
Providing a plan to achieve the objectives Collecting data on results achieved
Creation and use of knowledge to do the project Completing all the agreed work
Managing the performance Managing transitions across phases
Managing the changes with integrated decisions Closing the project
WHY INTEGRATION?
A Project Manager does not deal with processes
1 in isolation
2 Processes interact and impact each other closely
PM constantly balances the needs of competing
3 objectives and alternatives
Change in one of the STCQ constraints need to be
4 addressed by changing the other
Defects and project performance variances too
5 trigger other changes
PROJECT CHARTER
Start Here
"A document issued by senior management that provides the project manager with the authority to apply organizational
resources to project activities.”. It is a pre-requisite to start the project.
• Contents
• Business need or product requirements
• Project purpose or justification
• Stakeholders needs and expectations
• Milestones (and their schedule, if possible)
• Project’s expected end date
• Organization, environmental and other constraints & assumptions
• Business case justifying the project (including ROI) – is it worth it?
• Summary budgets
• Key staff
• Written authorization
• Risks identified, if any
• High level project constraints
PROJECT KICKOFF MEETING: OBJECTIVES
Stakeholders brought on board the project
Establish a common understanding about the project charter and its components (especially objectives)
Understand expectations, communicate our expectations
Identify potential conflicts in expectations
Set the “ground rules” for the project (includes frequency of meetings, reporting, escalation rules )
Establish a common sense of purpose
Communicate Responsibility Assignment, Escalation Matrix
PROJECT MANAGEMENT PLAN: KEY CONTENTS
• Client & Project Overview
• Project Objectives
• Project Scope (Scope Baseline)
• Critical Success Factors
• Deliverables, Review and Acceptance Criteria
• Execution Approach / Methodology (Project Life Cycle)
• Development Approach
• Project Management Subsidiary Plans
• Resource Plan (Staffing, Infrastructure Resources & Training Plan)
• Project Schedule (Schedule Baseline) and Milestones with supporting estimates
• Team Structure & Stakeholder Responsibility Matrix
• Status Reporting & Monitoring (including Management Reviews)
• Issue Resolution & Escalation
• Performance Measurement Baseline
• Change Management
• Configuration Management
• Project Costing (Cost Baseline), Funding Requirements & ROI
• Dependencies, Constraints and Assumptions
DIRECT AND MANAGE PROJECT EXECUTION ACTIVITIES
Perform activities and spend funds to accomplish project requirements
Create project deliverables; Implement approved changes
Staff, train and manage the team members
Obtain quotations, bids, proposals and select and mange sellers
Obtain, manage and use resources ( man-machine-material) , tool equipments
Implement planned methods and standards
DIRECT AND MANAGE PROJECT EXECUTION ACTIVITIES
Establish and manage communication channels, external and internal
Capture project data ( Schedule-Cost-Technical-Quality etc)
Manage Change Requests
Manage risks and implement risk responses
Manage sellers and suppliers
Collect and document lessons learned, implement approved process improvements
MANAGE PROJECT KNOWLEDGE
• Tacit and Explicit Knowledge
• Creating New Knowledge, Reusing Existing Knowledge
• Knowledge Management Tools; Information Management
Tools
• Motivating people to share knowledge; developing trust
• Networking
• Communities of Practice
• Communication Technology
• Shadowing
• Focus Groups
• Creativity and Idea Management Techniques
• Story Telling
• Knowledge Fairs / Cafes
MONITOR AND CONTROL PM ACTIVITIES
6.Monitoring implementation
1.Comparing
of approved changes
performance Actual
v/s Planned
5.Status report, progress
measurement and 2.Assessing performance
Sprint for corrective or preventive
forecasting (Schedule, Retrospective
Cost) actions and
recommendations
4.Maintaining accurate, 3.Analyzing ,tracking
timely information of and monitoring Risks
project’s product and and respective
documentation response plan
CHANGE REQUEST LIFE CYCLE
Origination of Change Raise (Document) Change Impact
(external events, errors / Change Request Analysis (Including
defects, requirements, Estimation);
complaints,
preventive/corrective
actions etc.)
Identify opportunities Discuss with Recommendations to
to reduce impact of customer/sponsor Change Control
change; response about change and its Board
alternatives impact
CHANGE REQUEST LIFE CYCLE
Decision by Change Control Board & its communication to stakeholders
Update project documents (to reflect the change)
Implement Changes
Update project status & progress reporting
Close change request
Irrespective of the reason/motivation, paid or free, the process must be followed. Any unplanned activity is a change. Changes
need not originate from customers. Changes later down the project cost more.
PROJECT CLOSURE ACTIVITIES
Can happen through Starvation, Extinction or Addition
• Project Closure Meeting (Including Lessons Learnt, KT)
• Complete all deliverables. Verify Scope and Acceptance • Project Closure Report /Final Project Report
Criteria met. • Transfer ownership of deliverables to assigned
stakeholders
• Issues resolved, costs charged, accounts closed, material,
facilities released • Release Resources (challenging to get resources to stay on
till the end!)
• Seller work acceptance, claims closure, “contract complete”
• Update organizational repository & knowledge base
notice
(project archives)
• Complete project documentation (including financial related) • Release final payments to suppliers
• Formal Acceptance (sign off) from customer, feedback • Note: End/Exit of a project phase is called as a “Kill Point”
or Stage Gate.
• Aborting a project will NOT require completing activities in
black above.
PROJECT CLOSURE IS DONE WHEN…
1 The project objectives were met 5 The need for the project no longer exists
2 The objectives will not be met or cannot be met
6 There is a change in the strategic priorities
The human or physical resources are no longer
3 Funding is exhausted 7 available
The project is having legal or regulatory
4 Funding is no longer available
8 issues/hurdles
ARCHIVING PROJECT INFORMATION PRIOR TO CLOSURE
• Project Closure Report • Status Reports
• Lessons Learned • Project Presentations
• Metrics • Project Communications
• Defect Log
• Project Issue Log • Customer Complaints
• Project Risk Log • Customer Feedback
• Project Action Items • Project Plan & Project Schedule
• Change Log • Performance improvement plans
• Minutes of Meetings • Requirement Documents
• Resource Register
• Effort Estimates • Project Timesheets
• Project Costing
• All other project documents
PROJECT DOCUMENTS: EXAMPLES
• Activity Attributes • Procurement Statement of • Requirements
• Activity List Work Documentation
• Assumptions Log • Project Calendars • Requirements Traceability
• Basis of estimates • Project Communications Matrix
• Change Log • Project Schedule • Resource Breakdown
• Cost Estimates • Project Schedule Structure
• Costs Forecasts • Project Schedule Network • Resource Requirements
• Change Requests Diagrams • Resource Assignments &
• Duration Estimates • Project Staff Assignments Calendars
• Forecasts (cost and • Project Scope Statement • Risk Register
schedule) • Project Team Assignments • Risk Report
• Issue Log • Quality Control • Schedule Data
• Lessons Learned Register Measurements • Stakeholder Register
• Milestone List • Quality Metrics • Team Charter
• Procurement Documents • Quality Report • Test and Evaluation
Documents
Scope Management
WHY SCOPE MANAGEMENT?
Customers often want changes during the course of
the project
Team members want to add value for the client
(freebies) without approval
Teams miss out to check if they have delivered
everything that was indicated in the scope
Project teams may not obtain sign-off / approval
/acceptance from customer for all deliverables
REQUIREMENT DOCUMENTATION
Business Requirements
•Business and Project Objectives
•Business Rules & Guiding Principles
Stakeholder Requirements
•Impact to entities inside and outside the organization
•Communication Requirements
Solution Requirements
•Functional Requirements
•Non-Functional Requirements
•Technology and Standard Compliance Requirements
•Support and Training Requirements
•Quality Requirements
•Reporting Requirements
Project Requirements
•Levels of Service
•Acceptance Criteria
Requirement Assumptions, Dependencies and Constraints
ASSUMPTIONS, DEPENDENCIES AND CONSTRAINTS
Assumption is a statement Dependencies are Constraints are limitations that
that is considered to be true, requirements / expectations are outside the control of the
on the basis of which certain that the stakeholders should project team. There is nothing
decisions, conclusions, fulfill for the project activity to much you can possibly do
estimates and actions are be executed as planned. about it, as compared to
proposed / implemented. risks/issues where you can
have alternative plans /
workarounds / mitigation /
solutions identified, to tackle
them. Constraints are a given.
Also: Triple Constraints – Scope, Time, Cost. Expanded to: STCQ (Quality)
CHARACTERISTICS OF GOOD REQUIREMENTS
• Logically structured (Loan origination, approval,
disbursement, collection)
• Uniquely Identifiable (1.1.2, 5.3.1)
• Unambiguous (There should be a way to cross from one
building to the other)
• Traceable (Reqt A Design B Code C Test Case D
Defect E)
• Testable (The UI should be attractive)
• Complete (There are 3 payment options. List them as
VISA, MasterCard)
• Consistent (1.1.2 says Android only….4.5.1 says all
mobile platforms)
• Acceptable (User will need to wait for 90 seconds after
submitting form).
REQUIREMENT TRACEABILITY MATRIX
PROJECT SCOPE STATEMENT FRAMEWORK
1. Project and product objectives
5. Project Constraints and Assumptions
2. Product or service requirements and
6. Initial WBS & high level identified Risks
characteristics
7. Schedule milestones & cost estimate with
3. Product acceptance criteria (Quality)
approximation order
8. Project configuration management and Approval
4. Project requirements, deliverables and boundaries
requirements
Consider: “Smart City” Project
SCOPE RELATED ISSUES
• Client says that work is part of scope, project team says it
is a change request
• We didn’t realize till we were half way through, that
there is more to the scope than what we imagined
• After you did a lot of hard work, customer tells you that it
is not needed
• Additional requirements are coming up at a stage where
team is crunched for time
• Client’s vision are not translated effectively by
stakeholders; disillusionment
• Contradicting requirements – interpreted differently by
each stakeholder
• Commitment made to deliver certain scope without
checking technical feasibility
WORK BREAKDOWN STRUCTURE
SAMPLE WBS
VALIDATING THE WBS
All major elements been identified at top level?
Decomposed into measurable components?
Lower level(s) items necessary? All inclusive?
Would stakeholders agree WBS is satisfactory?
Can elements be scheduled, budgeted, and assigned to a unit that will accept responsibility?
Each element is defined with clear completion criteria?
Too much or too little visibility and control?
Can status reports be generated at all levels?
WBS: PRACTICE EXERCISE
• Develop the WBS for your project
• Think time based sequence of work; phases,
deliverables, end results
• 3 levels of detail desired. Don’t make it into a
flowchart – focus on drill down
• Figure out components that make up everything.
• Check if you missed something
Estimation and
Scheduling
ESTIMATION & SCHEDULING: KEY STEPS
Identification of Activities based on WBS
Sequencing of Activities based on dependencies
Estimating size and efforts for the activities
Translating efforts into resource count and duration
Scheduling the activities via a Network Diagram
INGREDIENTS FOR THE PROJECT SCHEDULE
TYPES OF DEPENDENCIES
Mandatory Discretionary Dependency: External dependencies:
Dependencies:
Nature of work is It is the way decided by When it is required to
inherent technical and the project manager and get the work done
must be done in his team members as through a party outside
stipulated manner to preferred to set the project (as against
meet the requirement. ( dependencies which can Internal dependencies)
Hard Logic) be changed if required . (
Soft logic – Preferred logic
– Preferential logic )
TASK RELATIONSHIPS
Construct Start 1st Floor
Foundation Construction
ODI game begins Testing Complete
Broadcast begins Dev Support Over
New System Go-Live Stop Legacy System
LEADS AND LAGS
Developmen Prepare
t Design
Test Review the
Execution Designs done
ARROW DIAGRAMMING METHOD
Arrow Diagramming Method (ADM): Activities are shown on arrows (AOA), and are connected to each other at
the nodes.
Dummy Activity (in ADM) – Zero duration, only for showing dependency
PRECEDENCE DIAGRAMMING METHOD ( PDM)
Also called as ‘Activity On Node’ (AON)
B D
Dependency is represented by
‘Arrow ’
A G H
Rectangle & junction point is called as
C F ‘NODE’
Activities are represented on Node
Early Start Duration Early Finish
Task Name
Late Start Slack/Float Late Finish
KEY TERMINOLOGIES
Forward Pass: Starting at the beginning (left) of Backward Pass: Calculate late start and late finish
the network develop early start and early finish dates by starting at project completion, using finish
dates for each task, progressing to end (right-most times and working backwards
box) of the network
Duration (DU) : Number of work periods, Elapsed Time : Number of work periods, including
excluding holidays or other nonworking periods, holidays or non working periods required to
required to complete the activity; expressed as complete the activity; expressed as workdays or
workdays or workweeks workweeks
Float or Slack : Latest point in time a task may be Critical path: Longest path to complete a project
delayed from its earliest start date without and it has no or negative Float
delaying the project finish date
PRACTICE EXERCISE 1: NETWORK DIAGRAM
Shown below are activities with their durations and precedent activity.
Activity Duration (days) Precedent Activities (finish start)
A 3 -
B 5 -
C 9 A,B
D 8 C with 2 days LEAD
E 5 C
F 5 D & 2 days LAG with E
G 4 D
H 7 E
I 5 F,G,H
1. Draw network diagram and determine the critical path ,duration of the project
2. List out activities with float and their values.
NETWORK DIAGRAM SOLUTION
0 3 3 12 8 20 20 4 24
A FS-2
D G
5 9 14
2 2 5 13 1 21 22 2 26
C
0 5 5 14 5 19 21 5 26 26 5 31
5 14
B E FS+2 F I
0 5 14 19 21 26 26 31
19 7 26
H
19 26
PRACTICE EXERCISE 2: NETWORK DIAGRAM
5 6
8 9 11
6 2 8
7 5
11 15
1. Determine the critical path, duration
2. Determine free and total float
FACTORS INFLUENCING ACTIVITY ESTIMATES
Scope of Work
Types and Skills of resources
Number of Resources Available
Resource Calendars
Constraints imposed (Duration, Effort, Cost, Resource count, scheduling technique)
Quality of Input Data (for requirements, scope, quantum of work)
Law of diminishing returns
Technology advances
Staff Motivation and Productivity
DURATION ESTIMATION TECHNIQUES
PERT / 3 Point: Not much experience in estimating the work.
Parametric – formula based, using historical data (org/project baselines) PERT Duration = P + O + 4M
6
(P=Pessimistic, O=Optimistic, M=Most Likely)
Analogous – Similar project / prototype done in the past SD = P – O Variance = SD2
6
Range of estimate = PERT Duration +/- SD
Bottom Up – add up estimated efforts by activity
Heuristic - Trial and Error, rule of thumb. It is a Rough Order of Magnitude
Estimate - with a range of +/- 50% or +75/-25% (as against budgetary estimate
with +25% / -10%) and definitive estimate (+10% / - 5%)
COMPARING ESTIMATION METHODS
Method Advantages Disadvantages
Analogous Quick, Low Cost Very Rangy, a form of expert judgment
Parametric Can be more detailed than analogous, Parameters may not scale, accuracy can vary
faster than bottom-up
Bottom-Up Better team buy in; accurate Longer time; higher cost. Team may pad
estimates
Three Point (PERT) Can be accurate for well understood Can be inaccurate if ranges are based on
activities unknown elements
Heuristics Quick, low cost Based on trial and error – no scientific
rationale; biggest range
PERT DURATION EXAMPLE
SCHEDULE COMPRESSION & RESOURCE LOADING TECHNIQUES
• Before finalizing the schedule, use compression techniques to the extent feasible
Fast tracking : Crashing : Resource Resource Critical
levelling: Smoothing: chain:
Doing critical path Making cost and
activities in parallel schedule tradeoffs can also be used
that were originally to determine how to balance the Not only activity
planned to be in workload of Reschedule work
to obtain the dependencies for
series. ( trade off primary resources by delaying non
greatest amount of critical path, but
between TIME and over the course of critical path
schedule also resource
Quality, causing the project, usually activities so as to
compression for dependencies/avai
increased risk.) at the expense of reduce fluctuation
the LEAST lability determine
Risk management one of the in resource
Incremental cost the critical chain.
and careful traditional triple requirements
while maintaining
communication is project scope. Can constraints (time, Schedule Compression
key here. lead to increase in cost, scope). is best used when there
cost, risk and is pressure of
lower resource time/delay.
morale
COMPARING THE SCHEDULE COMPRESSION OPTIONS
COST BENEFIT ANALYSIS OF CRASHING
SAMPLE DETAILED SCHEDULE
CONTROL SCHEDULE – WHAT IS DONE HERE?
• Understand the status as of date, in comparison with plan
for the same period (could also be in the form of
burndown charts)
• What if scenario analysis – what will be the end date if…
• Influence the factors that are impacting the schedule
• Revision to schedule may be initiated as a change request
• Revisit the cost reserves and schedule buffers
• Update the schedule when approved
• Conducting Retrospectives (also during Closure) to
improve performance
• Reprioritizing the remaining work
• Determining the velocity of work (or SPI/SV)
• Schedule status reporting and reviews
• Trend Analysis
• Schedule forecasts
ITERATION BURNDOWN CHART
Project Resource
Management
HR ACTIVITIES FOR THE PROJECT MANAGER
• Find out what type of resources you need, how
many, when and how long
• Seek the resources – internally or externally
• Select the suitable resources
• Onboard the resources & assign reporting
• Job Specific Training
• Work Allocation
• Manage Resources (motivate, support, handle
conflicts)
• Analyze Resource Performance
• Release Resources
RESOURCE HISTOGRAM
HUMAN RESOURCE SELECTION CRITERIA
Availability: Available to work on the project within the time period needed
Cost: Verify cost of the team member is within prescribed budget
Ability: Whether team member has the competencies needed by the project
Knowledge: Relevant knowledge of the customer, similar project & nuances of the project environment
Skills: Relevant skills to use project tool, implementation or training
Attitude: Ability to work with others as a cohesive team member
International factors: Team member location, time zone and communication capabilities
Also consider: Cultural factors, willingness to travel, customer approvals, background checks, work visa
RACI CHART: ALLOCATING RESPONSIBILITIES
RESOURCE DEVELOPMENT ACTIVITIES: INVESTING IN PEOPLE
Understanding the current state - skills,
Providing opportunities to grow (job
behaviors, performance, expectations
enrichment, promotions)
(assessment)
Defining the roadmap for growth (career
Providing guidance on the job (mentoring)
path)
Knowledge and Skills enhancement (training) Shaping good behavior (coaching)
Also see: PCMM Framework to find out what are the various facets of employee developement
PM’S ROLE IN TEAM BUILDING
• Encourage Collaborative Working
• Obtain Top Management Support
• Obtain Commitment of Team Members
• Rewards and Recognition
• Team Identity
• Manage Conflicts
• Promote Trust and Open Communication
• Provide Good Team Leadership
• Co-location
TEAM EVOLUTION: TUCKMAN LADDER
Forming (Initiation): Team meets, learns about work, not mixing, independently working. Your style:
directing
Storming (Planning): Bring in different ideas, intense discussions, arguments, start taking decisions. Your
style: facilitating
Norming (Planning & Executing): adjust work habits, collaboration, trust. Your style: coaching
Performing (Executing): well organized unit, interdependent, smooth, effective, results. Your style:
supporting
Adjourning: Moves on, disperses after completing work
Ground rules (Team Charter) are important – sets expectations regarding acceptable behavior, guidelines, decision making &
conflict resolution methods, values that are important. Team shares responsibility for enforcing rules. Encourage discussion on
the rules to understand rationale.
TYPICAL RESOURCE RELATED ISSUES
• Unhappy with role-responsibilities
• Compensation / growth related issues
• Interpersonal conflicts – peers, subordinates, superiors
• Work Location issues
• Work Timings
• Lack of Commitment and Ownership
• Inability to cope with pressure; work stress
• Lack of ability and willingness to learn / perform
• Misalignment of personal and organizational goals, values
• Inappropriate management styles
The PM needs to identify these issues proactively and address them before they have any adverse impact on the project and
team performance
CONFLICT MANAGEMENT
First, give the conflicting parties the opportunity to resolve the conflict between themselves. If this is not working, then step in to
aid resolution. Final option: impose a decision.
Conflicts often take place due to (in descending order):
• Schedules
• Priorities
• Resources
• Technical Beliefs
• Administrative policies and procedures
• Project costs
• Personalities
CONFLICT HANDLING STYLES
• Withdrawal/Avoiding: Parties move away from (discussing) the
conflict
• Smoothening: Avoid areas of difference, emphasize areas of
agreement
• Compromising: Both sides take one step back; bargaining
• Forcing/Competing/Directing: Exerting one’s point at the
potential expense of the other, using formal power
• Confrontation/Collaboration: Affected parties face the conflict,
attack the problem, work through to resolve disagreements.
• Arbitration: Both parties agree to a appoint a neutral third party
to resolve conflict
• Not always will one style work best. PM needs to decide what
will be the best approach based on expert judgment.
CONFLICT MANAGEMENT – WHICH STYLE?
• One style may not work all the time
Conflict Handling Style When to apply?
Withdraw / Avoid You want to take some time to collect facts and build
your case
Smooth/Accommodate When people are not trusting each other
Compromise/Reconcile When relation is important and matter is not of high
importance, you can not win or stakes are not high
Force/Direct / Compete You know you are right, time is less, relation is not
important, stakes are high
Collaborate/Problem Solve Stakes are high, and both parties trust each other,
collaborate to find best option for project
CONFLICT RESOLVING TECHNIQUES: EFFECTIVENESS
1. Withdraw/Avoid Temporary Only,
2. Smoothen Fails to Resolve,
LOSE-LOSE
3. Compromise
(LOSE-LOSE)
4. Force (WIN-LOSE) Provides
5. Collaborate / Resolutions
Confront (WIN-WIN)
Collaborate/Confront (Problem Solve) is the only “WIN – WIN” solution
THEORIES FOR MOTIVATION
Maslow’s Theory: Physiological (roti kapda makaan), Safety (security, stability), Social (association, affection, approval),
Esteem (respect, attention, appreciation), Self Actualization (self fulfillment, growth, learning)
Herzberg’s Theory: Hygiene Factors (absence demotivates, such as working conditions, salary), Motivators (good work
and recognition)
McGregor’s Theory: Theory X (watch over people) and Theory Y (self drive, w/o supervision). Theory Z – Japanese
philosophy (lifetime employment, employee well being)
Expectancy Theory: The individual does something if the expected results of the behaviour are aligned with the desired
results, and are feasible
David McClelland Theory of Needs (Acquired Needs Theory) – Need for Achievement(I made it happen), Affiliation
(likes), Power (status).
Oldham-Hackman Job Characteristics Model: Skill Variety, Task Identity, Task Significance, Autonomy, Feedback
POWER EXERTED BY PM AND ITS OUTCOME
Type of Power Commitment Compliance Resistance
Legitimate/ Formal Possible Likely Possible
Reward Possible Likely Unlikely
Penalty/Coercive Unlikely Possible Likely
Expert Likely Possible Possible
Referent Likely Possible Unlikely
Connection Possible Likely Possible
Also: Bureaucratic Power: knows how get work done through the system
TYPES OF POWER (EXPANDED LIST)
• Positional – Role of PM
• Referent / Charismatic – Aura / personality
• Informational – has information of value
• Situational – under the circumstances
• Relational - connected / network / alliances
• Expert – has the expertise
• Reward – can provide benefits
• Coercive – can deny benefits
• Ingratiating – flattery or false praise
• Pressure based – consequences due to limited time /options
• Guilt based – sense of duty / obligation
• Persuasive – arguments or logic that compel others to follow
• Avoiding – refusal to participate
LEADERSHIP STYLES, DELEGATION MODEL 1
• Authoritarian
• Democratic
• Laissez-faire
• Transactional
• Transformational
• Charismatic
• Interactional
• Servant Leadership
• Also: Blake and Mouton’s
Managerial Grid (task vs
people orientation)
DELEGATION MODEL - 2
Do not Delegate: Sensitive aspects of leadership, key stakeholder management, anything that you or anyone would rather not do
BIASES TO BEWARE OF, DURING APPRAISAL
• Halo Effect: Tendency to judge all aspects of an individual using a
general impression that was formed on only one or a few of the
individual’s characteristics.
• Contrast Effect: The contrast error occurs when a leader compares
subordinates with one another instead of against performance
standards
• Recency Effect: The recency bias occurs where a person forms an
impression based only on the most recent experiences with the
other individual, rather than over a period of time.
• Leniency or Severity Bias: Too lenient or severe with employees
during performance appraisal
• Horn Effect: Extend negative traits to other work characteristics
• Spillover Effect: Past performance is an indicator of present
• First Impression (primacy effect):based on initial impressions formed
Project Communication
Management
BASIC COMMUNICATION MODEL
Sender-Receiver model: Feed back loops and barriers to communication
Message
Encode
Decode
Noise
Media
Sender Receiver
Noise
Decode Encode
Feedback
message
COMMUNICATIONS RETAIN / ABSORB
Retain Absorb
50% Now 10% of what we read
25% in two days 20% of what we hear
10% after seven days 30% of what we read and
hear
50% of what we discuss
80% of what we experience
90% of what we teach
Bottlenecks in Communication
Successful PM decisions must pass through the bottlenecks of barriers to communications prior to achieving desired results.
Take mouse over each text for
additional information
COMMUNICATION BARRIERS & MINIMUM PRECAUTIONS
Micro barriers obstruct communication in specific situation.
Macro barriers obstruct communications most of the time.
Perceptions :
• Sender’s view of receiver: How sender perceives the level of
knowledge and ability to understand the message
• Receivers View of Sender: How receiver personally feels about the
sender
Points to ponder:
1. Communicate when receiver is having complete attention
2. Minimize resistances to smooth communication
3. Minimize noise level for clean communication (avoid interference)
4. Use standard terminology (Avoid specific terminology)
5. Provide glossary of terminology
TYPES OF COMMUNICATION
• Pull Communication: Intranet, e-Learning, Knowledge
Repository
• Push Communication: Letters, emails, faxes, voice mails, press
releases
• Push-Pull (Interactive Communication): Meetings, Phone Calls,
Video Conferencing, Chat
• Formal v/s Informal.
• Verbal v/s Written
• Informal verbal communication is the best approach for
expressing your concern with a team member. Then follow
formal written approach
• With the customer, in most situations you will use formal
written communication (unless it is a concern, for which you
will precede it with informal verbal). With team, face to face
for important/sensitive communications.
PROJECT COMMUNICATION - DIMENSIONS
• Internal (within project team) vs External (customers, vendors,
other projects, organizations, public)
• Formal (reports, minutes, briefings, emails, memos) and
informal (ad hoc)
• Vertical & Horizontal
• Official (Newsletters, annual reports) and unofficial
• Written vs Oral
• Verbal (Tone, variation) vs Non Verbal (body language)
COMMUNICATION SKILLS REQUIRED ON PROJECTS
Listening actively and effectively
Questioning and probing ideas and situations to ensure better understanding
Educating to increase team’s knowledge so that they can be more effective
Fact-finding to identify or confirm information
Setting and managing expectations
Persuading a person, a team, or an organization to perform an action
Motivating to provide encouragement or reassurance
Coaching to improve performance and achieve desired results
Negotiating to achieve mutually acceptable agreements between parties
Resolving conflict to prevent disruptive impacts
Summarizing, recapping, and identifying the next steps
Additional Tips
COMMUNICATION PLAN CONTENTS
May Include: Why are we communicating?
DIFFERENT REPORTS
• Progress report: Description of what is accomplished
• Status report: Snap shot of project generally on S -T- C- Q
parameters
• Variance report: Comparing Plan v/s Actual
• Trend report: Analysis of project results over time to
examine performance.
• Forecasting report: Predictions of expected project status &
performance
In general reporting of performance is about collecting,
organizing and disseminating information about performance
based on the objectives
Stakeholder Management
PROJECT STAKEHOLDERS
End User Client
Client’s Top
Client Management
Site PM
Project Project Technical &
Sponsor Manager Engg.Group
Support PMO
Teams Top
Management Team Members/
Resources Vendors
Portfolio/
Program
Manager
STAKEHOLDER REGISTER – SAMPLE TEMPLATE
Stakeholder Register
Project Name: Date:
Project Phase:
Type of Type of
Name of Departme Role in Expectation Interest Influence on Project
Designation Stakehold Communicati
Stakeholder nt Project s s Outcome
er on
STAKEHOLDER ANALYSIS – WHAT DO WE WANT TO KNOW?
What is their Interest in the project?
What rights do they have or what rights do they intend to use
What ownership do they have for this project?
What specialized knowledge are they possessing which would be
of relevance?
What (kind, level and extent) will be or should be their
contribution to the project?
STAKEHOLDER ANALYSIS – CLASSIFICATION MODELS
1. Power – Interest Grid (Authority, concern)
2. Power – Influence Grid
3. Influence – Impact Grid (Active Involvement, ability to
effect changes)
4. Salience Model – Power, Urgency (needs immediate
attension), legitimacy
5. Stakeholder cube (listing the above in three dimensions)
Also check: Direction of influence → and outward
Prioritization of stakeholders will be based on the above
STAKEHOLDER ANALYSIS: POWER / INTEREST GRID OF STAKEHOLDERS
HIGH
Keep satisfied Manage closely
Power
Monitor Keep
(minimum efforts) Informed
LOW
Interest
LOW HIGH
STAKEHOLDER ENGAGEMENT LEVELS
• Current engagement level of all stakeholders needs to be compared to the planned engagement
levels required for successful project completion. These levels are classified as:
1. Unaware: Unaware of project and potential impacts
2. Resistant: Aware of project and potential impacts and resistant to change
3. Neutral : Aware of project yet neither supportive nor resistant
4. Supportive : Aware of project and potential impacts and supportive to change
5. Leading: Aware of project and potential impacts and actively engaged in ensuring the project is a
success.
C = Current engagement D = Desired engagement
Stakeholder Unaware Resistant Neutral Supportive Leading
Stk. 1 C D
Stk. 2 C D
Stk. 3 C D
STAKEHOLDER MANAGEMENT ACTIVITIES
• Engaging Stakeholders at appropriate project stages to obtain or
confirm their continued commitment to the success of the project
• Managing Stakeholder Expectations through negotiations and
communications, to achieve goals
• Addressing potential concerns that have not yet become issues
and anticipating future problems that may be raised by
stakeholders
• Clarifying and resolving issues
• Also see: http://www.bsr.org/reports/BSR_Five-
Step_Guide_to_Stakeholder_Engagement.pdf
Agile Overview
AGILE SIMPLIFIED A wish-list is created
that contains the
features desired in
the product /
application
At the end of each
The key stakeholders
Iteration, the
meet to determine the
“increment” is
most important features,
demonstrated to the
to include in the next
client. Iterative changes
release
are noted
Every day, the team tracks its After understanding
progress by updating each other more about the work,
on what they did and what they the team plans what
plan to do next. They replan features they can take
remaining work if required up in the next iteration
The Iteration is detailed
• Product out in terms of tasks,
• Release with time estimates.
• Iteration Team decides which
• Tasks tasks they will do and
when
EXAMPLES OF AGILE IN THE NON IT WORLD
1. Unit Test 1 (Sprint)
2. Unit Test 2
3. Terminal
4. Unit Test 3
5. Unit Test 4
6. Final (Release)
…repeat sequence every academic year till
you are done studying (Product)
INDUSTRY’S REASONS FOR ADOPTING AGILE
ISSUES WITH TRADITIONAL METHODS
Problems with non Agile approaches
• Huge effort during planning, which does not have much value
later
• Less customer involvement leads to an incorrect / unsuitable
product being developed
• Poor requirements conversion in a rapidly changing environment
▪ Too many artifacts being produced which are not directly
related to software product
▪ Difficulty in dealing with incomplete or changing requirements
▪ Customer gets to see the product too late
▪ Does not appreciate ideating or changing minds later
▪ Also, project management success (Good on STCQ)
does not mean successful project (business success)!
AGILE VS WATERFALL
“… it is cheaper to fail early”
• Always working on the difficult
problem first
Or “Sashimi” • Development team ranks
deliverables as to their technical
risk
• Prioritized Product backlog
AGILE VS TRADITIONAL PROJECT MANAGEMENT
INCREASED USER INVOLVEMENT AND FEEDBACK
Agile
Short Cycles and Continuous User
Feedback results in high degree
of visibility through out the
release
User Involvement
Conventional (Waterfall)
User involvement starts high, but
tapers out early. Users do not
normally get involved for an
extended period of time
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Start Release End
MINDSET – VALUES – PRINCIPLES - PRACTICES
HISTORY OF AGILE
• On February 11-13, 2001, at The Lodge at
Snowbird ski resort in the Wasatch
mountains of Utah, seventeen light weight
methodologists met to talk, ski, relax, try to
find common ground and of course, to eat.
• They discussed their feelings that the
traditional approach to managing software
development projects was failing far too
often, and there had to be a better
way. They came up with the agile manifesto.
THE AGILE MANIFESTO (2001)
• We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over
processes and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation http://www.agilemanifesto.org
• Responding to change over following a
plan
• That is, while there is value in the items on
the right, we value the items on the left more
TWELVE PRINCIPLES OF AGILE
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust
them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-
to-face conversation.
TWELVE PRINCIPLES OF AGILE
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain
a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
THE AGILE TRIANGLE
AGILE METHODOLOGIES
Also:
• Feature Driven Development
• Dynamic Systems Development Method
• AUP (RUP Lite)
• Disciplined Agile
SELF ORGANIZED & CROSS FUNCTIONAL TEAMS
Self‐organized: Scrum Team Cross‐functional: Scrum Outcomes:
manages own efforts Team has expertise and Whole Development Team
Not managed or directed by competencies responsible and accountable
others. They find their own Get the job done without Boost to creativity
way instead of receiving help from outside the team Team and project
orders Experts are responsible for commitment – Improves
Management and specialist delivering backlog items, Accuracy of estimate
efforts are not separated in and managing their efforts Team success is more
Scrum Capable of the creation of important than individual
Members decide who will each Product Backlog item success
perform the what work in
each iteration
Anyone can be a leader on
an agile team. Team
members take charge
They motivate each other.
They show recognition of
individuals and team
FEEDBACK
We’re committed to empower you to be
#FutureReady
through powerful training solutions.
We build the workforce of the future.
250+ 30,000+ 25000+
Corporate Clients Learners Trained Learners Placed