Project Planning and
Management
PMI Knowledge Areas
 Project Management Institute (PMI)
 Project Management Professional (PMP)
 PMBOK: Project Management Body of Knowledge
 Five (5) Processes
 Nine (9) Knowledge Areas
PMI Nine Knowledge Areas










The nine knowledge areas are, Project:
Integration Management
Scope Management
Time Management
Cost Management
Quality Management
Human Resource Management
Communications Management
Risk Management
Procurement Management
PMI – Five Process Areas
 The five process areas are:
 Initiating
 Planning
 Executing
 Controlling and Monitoring
 Closing
PROJECT MANAGEMENT
 Course Introduction
 Initiate the Project
 Planning
 Define and Organize the Project
 Track and Manage the Project
 Close Out the Project
PROJECT MANAGEMENT
 What is Project Management?
 Key of Project Management is:
 Provide Common project goals
 Keep people involved
 Confirm Assumptions
 Clarify Roles
Challenges
 Unclear Objectives
 Unrealistic schedule
 Over/under committed resources
 Unclear or changing priorities
 Poor Communications
 Unclear Organizational relationships
PROJECT MANAGEMENT
Why is PM important?
PROJECT
 Objective
 Project Sponsor
 Project Manager
 Group Work
Different Terminology
 Project Manager
 Program Manager
 Delivery Manager
 Project Management
 Program Management
 Portfolio Management
Track and Manage the Project
 Manage the project plan
 Manage issues, changes, and risks
 Manage the communication process
Scope, Schedule and Cost
 Need to define Scope, Schedule and Cost
 Need to define Quality Control, i.e. completing a project
within Scope, Schedule and Cost may not always equate to a
successful project
 Software alone does not manage projects
Project Governance
 Steering Committees vs. Working Committees
 Project Sponsor
 Escalation process
 Project gating
Risk and Issue Management
 Risk vs. Issue Management
 Identification of risks
 Scoring / rating of risks
 Risk mitigation plans
 Escalation of unresolved issues
Communications Strategy
 Key elements
 Schedule of information release
 Mode of communication
 Frequency of communication
 Duplication of message
 Noise
Close Out the Project
 Complete transition activities
 Conduct project close-out reviews
 Complete administrative close-out
Definition of Success

Project Charter must answer three key questions:
1.
Who gets to judge success?
What does success look like?
When are we done?
2.
3.
SOME OF THE PM RESPONSIBILITIES
 Defining the project management process.
 Prepare and obtain project management approval of the project
plan
 Assume that all team members understand and accept their
responsibilities.
 Assure timely adaptive action is taken
 Negotiate
 Establish priorities
 Provide periodic status reports and information (gather)
GOOD PROJECT MANAGER
 Totally problem oriented, sees the “big picture’
 Good motivator and team leader
 Familiar with company practices and processes
 Goal oriented
 Willing to challenge internal/external obstacles
 Has an understanding of the technology involved in the project
 Is committed to the project’s success
PROJECT MANAGEMENT
 INITIATION:
 Project Proposal
 Research/ Validate
 PLANNING:
 10-15%
 Scheduling
 PM process:
 From start to end
 Supports other parts and organizations.
 Cycle of Validation:
 Continuous and constant process- Should not be skipped.
INITIATE- (overview)
 Review the project proposal
 Identify the project:
 E.g. Extreme project
 Project Description Document
 Project Proposal vs. PDD
 Validate proposed objectives
 Assumptions
 Risks
 Issues
 Document Log- Log Issue
 Prepare the project charter
INITIATE
 COMPLETE PROJECT PROPOSAL Sample;










Business Case
Market Requirements
Financial Analysis
Success Criteria
High Level Scope and Requirements
High Level Schedule
High level Resources
Risks
Alternatives
Recommendation
INITIATE
 Test Project Information
 Best Practices:
 All right components of information
 Validity/ Current Relevance
 Validate with Sponsor
 Update assumptions, issues and risk
 Validate Proposed Objectives
DEFINE AND ORGANIZE THE PROJECT
 Establish the project organization
 Define project parameters
 Integrate project scope (if part of a program)
 Define the project infrastructure
DEFINE AND ORGANIZE THE PROJECT
 Establish the project organization
 Start a Project Notebook
 Identify Project Sponsor Do we need one?
 Multiple Sponsors
 Appoint the Project Manager
 Project Team:
 Core Team
 Extended Team
 Selecting Members
 Define Roles
 TEAM ROSTER
TEAM ROSTER
DEFINE AND ORGANIZE THE PROJECT
 Define project parameters
 Project Definition Document PDD
 Project Objective Statement
 Success Criteria
 Flexibility Matrix
Major deliverables
 IS/IS NOT LIST
Scope/Final Deliverable
Major deliverable #1
Major deliverable #2
Major deliverable #3
Major deliverable #4
IS/IS NOT
 Example:
POS: Implement an integrated employee systems database by
12/31/20XX for $5M
Deliverables: Hardware, Software, Training, Documentation
 Tangible deliverables
 Manage Expectations
DEFINE AND ORGANIZE THE PROJECT
 Identify Customers and Suppliers
 Identify Customers and Suppliers Requirements
 Interview
 Scope Creep
 Obtain Approval to Proceed
DEFINE AND ORGANIZE THE PROJECT
 INTEGRATE PROJECT SCOPE
 Integrate project scope into program parameters
 DEFINE PROJECT INFRASTRUCTURE
 Rigor
 DEFINE PROJECT PROCESSES AND PROCEDURES
 Research information
 Central location of work
 Review Information
DEFINE AND ORGANIZE THE PROJECT
 ESTABLISH PHYSICAL AND AUTOMATED RESOURCES
 Project Office
Best Practices
TEAM LOGISTICS
Physical Needs
Automated Needs
-Facilities
-Hardware
-Office equipment
-Software
-Communications
-Intranet
-Equipment and infrastructure
-Networks
-Furniture
-Web-site
DEFINE AND ORGANIZE THE PROJECT
 TIPS:
 It is ok to ask for help if need it.
 Request support, look for what’s available.
 Clarify Scope and project parameters
 Get them right, so ask 10 times if necessary
 Create a well detail PDD, and not a quick lousy one.
 It will save you lots of time.
 RE-RE-RE Definition of POS- PROJECT
OBJECTIVE STATEMENT.
5 MIN BREAKGROUP PROJECT
Project Charter
 Serves as a tool in Project Initiation
 Communication tool
 Allows everyone to understand their roles in the project
 Acts a strong governance tool
 *It is a living document – modified as the project is
elaborated
Project Charter

1.
2.
3.
Three (3) key sections
Overview / Background Section
Governance / Authority Section
Approach Section
Project Charter
 Overview / Background Section
 Executive Summary (for the senior executives)
 Definition of business need
 Project Objectives
 Measures of success (*Quantifiable)
 Assumptions (tested for accuracy)
 Constraints (e.g. budget, resources, schedule, etc.)
Project Charter
 Governance / Authority Section
Organization structure
Identifying sponsor(s)
Identifying Steering Committee members
Roles / responsibilities and assigning people to them
Terms of reference (mandates) for any committees involved in
the project (e.g. defining up front: why are the people there)
 Project approval processes





Project Charter
 Approach Section
 Scope statement (in-scope, out-of-scope)
 Work Breakdown Structure (WBS) of the tasks (typically
completed AFTER the project charter is in place)
 High level schedule
 Timeline
 Milestones / deliverables
 Budget (capital vs. operating)
 Risk Management Approach (matrix) – ongoing and actively
managed sections of the Project Charter
Project Charter
 High level mapping (not an exact flow, but a reasonable
prism to view the steps through)
 Business Need
 Project Objectives
 Project Scope
o WBS
The project from heaven or hell
 What went well?
 What went wrong?
 What are your most vivid memories
 Was there a Post Implementation Review (PIR) performed?
Why / Why not?
PLAN DE PROJECT
PLAN THE PROJECT
 Develop the work breakdown structure
 Develop the preliminary schedule
 Integrate the project schedule (if part of a program)
 Refine estimates and finalize resource commitments
 Optimize the project plan
 Develop risk management plans
 Transition from planning to managing
PLAN THE PROJECT
 Is it always necessary to Plan?
 Concurrent Planning
 Benefits and Risks
 Work Break Down Structure – WBS:
 Major components
 Top Down vs Bottom-up process
 100% Rule
Work Breakdown Structure (WBS)
 Descending levels reflect more details
 Develop to the level that it will be controlled (e.g. week
long vs. 1-day packages of work)
 Ask yourself:





Is the element necessary?
Is it clearly and completely defined?
Can it be scheduled?
Can it be defined?
Can it be assigned to a person, department that will accept
responsibility for doing it?
RACI Chart
Task
Responsible
party
Accountable
to
Coordinate
with
Inform
1.
Project
Manager
Project
Sponsor
Finance
Division
Human
Resources
of changes
2
3
PLAN THE PROJECT
 Consider often forgotten tasks:
 Planning the project
 Approval cycles
 Key project meetings
 Management /customer interface
 QUALITY INSPECTIONS /FIXING DETAILS
 TRAINING
 Project management
 TEST PLANNING, DEVELOPMENT AND EXECUTION
PLAN THE PROJECT
 Assure that tasks are Coded
PLAN THE PROJECT
 Assign Ownership
 Multiple owners = 0 owners
 Owner Responsibilities
 Plan, Manage, identify, estimate, point of contact, completion.
 Select Owner:
 Capabilities, accuracy, creativity, past experience, career goals
 Conflicts, work style.
Project Management Office (PMO)
 Role of the PMO?
 Weather station
 Project delivery
 Repository of information
 Development and monitoring of standards
 What is the PMO accountable for and to who?
PLAN THE PROJECT
 Responsibility Matrix
PLAN THE PROJECT
 WBS DICTIONARY
WBS CODE
1.2.2
TASK NAME
Shopping List
COMPLETION
CRITERIA
All food
ingredients have
been purchase
OWNER
Sarah
RESOURCES
$1,200
Car, and Costco
membership,
Telephone
Sergio**
The Project Environment
 The challenge of managing projects:
 Estimating…because each project is different, estimates may
contain more assumptions than facts. Whatever is being built
has never been built before, at least not within this exact
environment
 Budgeting…budget cycles for companies tend to run in 12month intervals, but projects rarely do
 Authority…when projects cross organizational (e.g. divisional)
boundaries it is not always clear who has the authority for many
decisions
LIFE CYCLE
 The Project Life Cycle
 Define: the phase begins when a project and a project manager are named in
a project charter and is completed when the project rules are approved.
Approving this written document means that all interested parties agree on
the project goals, approach, and cost-schedule-quality equilibrium
 Plan: the project manager begins building the project plan. Defining and
planning can be short phases, particularly for short projects. Since planning
often changes the project rules, some companies use a single phase, called
Initiation, to describe both of these activities
 Execute: performing the actual work as approved in the plan
 Close out: transition activities and should includes reviewing project
successes and failures
Sucess
 The Definition of Success
 On time
 On budget
 High Quality
 Is this limited to conformance to requirements?
 Is it possible and/or realistic to specify all requirements?
 Need to ensure Functionality and Performance
 “What does success look like?”
PLAN THE PROJECT
 Approximate Duration
 Good WBS
 Negotiate and agree on task completion criteria
 2-20 days task duration
 Understand and validate assumptions
 Use multiple approaches
 Consider the number of people
o
= 4 (4-1) / 2 = 4(3)/2 = 12/2 = 6
PLAN THE PROJECT- PART 2
 RIGOR
 No/low rigor estimating
 Medium rigor estimating
 Maximum rigor estimating
 PERT, COCOMO, DELPHI METHOD
PLAN THE PROJECT- PART 2
 PERT – Program Evaluation and Review Technique
 COCOMO
 DELPHI
COCOMO
 ORGANIC
 project that is routine for a company
 Well understood domain
 Team works well and efficiently together
 Project expected to run smoothly
 Typically a smaller system
COCOMO
 EMBEDDED
 A project that will be difficult for a company.
 Project that is hard (control software for a nuclear
plant, or spacecraft)
 Team has little experience in domain
 New or inexperienced team
 Tend to be large projects with lots of constraints
COCOMO
 SEMI-DETACHED
 In the middle
 Complex system, but something the company is
familiar with
 Teams may be made up of experienced and
inexperienced members
 System not huge, but not small either
COCOMO
 Simply: Plug and Chug
 What if it doesn’t work?
 Play with adjustment factors
 Tweak aand bto make the equation fit the result
 Use a more complex metric
DEPLHI METOD
 Structuring of information flow :The initial contributions from the
experts are collected in the form of answers to questionnaires and their
comments to these answers.
 Regular feedback: Participants comment on their own forecasts, the
responses of others and on the progress of the panel as a whole. (While in
regular group meetings participants tend to stick to previously stated opinions
and often conform too much to group leader, the Delphi method prevents it.)
 Anonymity of the participants : Usually all participants maintain
anonymity. Their identity is not revealed even after the completion of the final
report. Allowing experts to express their opinions, encourages open critique
and admitting errors by revising earlier judgments.
ESTIMATION
 Estimating comes with experience
 Using something like Function Points to come up with
code size doesn’t always works
 (personal belief)
 COCOMO is too simple and too old to really be of use
 Good starting point, more advanced models available
 Tweaking formulas might yield good results
PLAN THE PROJECT
 PRELIMINARY SCHEDULE
 Critical Path Method (CPM)
 FLOAT
 GANTT CHART
PLAN THE PROJECT
 TRANSITION FROM PLANNING TO MANAGING
 Project Baseline:
PLAN THE PROJECT
 REFINE ESTIMATES
 PURE EFFORT
 GAIN AGREEMENT ON CHANGE
 RISK MANAGEMENT
 Identify Risks
 Assess risks
 Create risk management plans
PLAN THE PROJECT
 IDENTIFY RISK
 SCHEDULE E.g. Supplier might be late, technology might not be ready
 Customers might not respond quickly enough
 RESOURCES
 E.g. Key resources might not be available when needed
 Resources might not be skill/ enough
 SCOPE
 Customer requirements might change late in the project
 Requirements might be un-attended.
PLAN THE PROJECT
 ASSESS PROJECT RISK
 GENERATE RISK MANAGEMENT PLANS
 Trigger
PLAN THE PROJECT
 Modify Plans as Needed
 Optimizing Plan
 Step 1: Modify preliminary plan to achieve the POS
 Step 2: Propose modifications to the project objective if the POS is still
not met.
“Opportunity for creative inventiveness”
PLAN THE PROJECT
 Modify Plans as Needed
 Tactics to change Schedule
 Renegotiate tasks start dates
 Re-order tasks
 Renegotiate deadlines dates
 Tactics to change Resources
 Reconcile your resources
 Consider change
 Improve productivity
PLAN THE PROJECT
 Modify Plans as Needed
 Tactics to change Scope
 Reconcile scope
 Analyze the processes
 Quality
TRACK AND MANAGE THE PROJECT
 Tracking the project
 Benefits of tracking
 Progress
 Problems
TRACK AND MANAGE THE PROJECT
 Data Collection
 Hard vs Soft Data
 HARD (quantitative)
 4 Q’s
 SOFT (qualitative)
 Women rule
 Status from Task Owners
 Request one
 Activity
 Resource
 Performance and Quality
TRACK AND MANAGE THE PROJECT
 Analyze Variances
 Analyze Risks, Issues and Changes
 MANAGE CHANGE
CLOSE OUT THE PROJECT
 PROJECT CLOSE OUT
 Announce end of project
 Complete paperwork
 Convert key leanings to Organizational Mastery
 Acknowledge and reward