Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


PM Meme Visualization 5

No description

Robert Higgins

on 26 March 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of PM Meme Visualization 5

Why do we do this?
What do we think we want?
Who has the power?
Develop Project Charter: The document issued by sponsor authorizes existence and provides authority
.1 Inputs
.3 Output
Project Selection Methods:

Constrained Optimization Methods: Mathematical
Linear Programming
Non-Linear Prgramming
Dynamic Programming
Integer Programming
Multi-objective Programming

Benefit Measurement Methods: Comparative
Economic Models
Present Value *If I put $225,394 (Today presnt Value) will be $300,000 in 3 years @ 10% Interest*
Net Present Value (NPV) Bigger is Better

Scoring Models
Comparative Approach
Benefit Contribution
Murder Board

3. Additional Methods:
1 Benefit Cost Ratio (BCR),
2. Economic Value Add (EVA) - If a project does not make more moeny than those opportunity costs, it has not truly added economic value to the organization,
3. Internal Rate of Return (IRR) - Bigger is better,

4. Opportunity Cost - 'What is the cost of the other opportunities we missed by investing our money in this project?'. The Smaller the opportunity cost, the better.
5 Payback Period - a Shorter payback period is better than a longer one., 5. Present Value (PV) and Net Present Value (NPV): Bigger PV or NPV makes a project more attractive.,
6. Return on Investment (ROI) - Bigger is better., and
7. Retun on Invested Capital (ROIC) = Net Income (after tax) from Project / Total Capital Invested in the Project.
Written description of the project's product, service, or result
Elements of SOW
WHAT is to be done (Product Scope Description),
WHY The Business REASON for doing it (Business Need), (Business Value)
HOW the project supports the organization's strategy (Strategic Plan)

'A Contract Statement of Work'
For Internal Projects, the Project Initiator or Sponsor provides.
For External Projects, the Customer provides as part of a bid document.
Organizational culture, structure, process
Government Standards
Political Climate
Commercial Databases
External and internal factors that surround the project
Have to just deal with it
No control over
Project Management Information System
Organizations communication Channels
Processes, Procedures, Policies
Corporate Knowledge Base
Project Files
Historical Information
Assist and guide to a shortcut
Cut and Paste
Network Diagrams
Lessons learned
Previous Estimates
Grumpy old men who have done it all before and they dont need no paperwork
Why Stakeholder Approach?
"Customer is King"

Salience ~ Relative importance based on context
Shareholder Management
Maximize Profits
Maximize Value
Stakeholder Management
Command and Control
Shareholders are #1
Next Person in the process is the customer
Clarify Requirements
Uncover Assumptions
Manage Expectations
Continuously Improve
'The captain is the consumer…the consumers determine precisely what should be produced, in what quality, and in what quantities…They are merciless egoistic bosses, full of whims and fancies, changeable and unpredictable. For them nothing counts other than their own satisfaction…In their capacity as buyers and consumers they are hard-hearted and callous, without consideration for other people…Capitalists…can only preserve and increase their wealth by filling best the orders of the consumers… In the conduct of their business affairs they must be unfeeling and stony-hearted because the consumers, their bosses, are themselves unfeeling and stony-hearted.’ @Ludwig Von mises
@ Saladis
How to approach Stakeholders?
Matrix Management
Who imagines What it looks like, When it is Done?
Proactively Manage Expectations
How will we collect the requirements?
How will we prioritize and track changes to requirements?
How will we elevate a "Requirement Candidate" to a "Requirement"
How will we reject a "Requirement Candidate"
that which is required; a thing demanded or obligatory
Complete, No Defects, Validated, Ready to Use
Research, Analyze, Communicate
Curated requirements candidates
Requirements Documentation
Project Title_______ Date Prepared______
Stakeholder | Requirement | Priority | Acceptance Criteria
Requirements Traceability Matrix
Project Title_______ Date Prepared______
ID Requirement Priority Category Source
Requirement Information
Requirement Traceability
Relates to Strategic Objective
Manifests in
Cover your 4SS
Somebody, Said, Something, So........
As a <Stakeholder>
I { must, should, could, reject} <What>
So that <Why> it fulfills the objectives
When it is done I expect to {See, Feel, Measure} <What>
Who Said What Does Done Look Like?
Copy, combine, remix, Breakthrough Innovation
Transformational Value
Done poorly is a "root cause" of the need to change
Translate Intangibles into Tangibles
.1 Inputs

Sponsor + Core Management Team
Customer + Core Technical Team
Where are we going?
What does look like?
What does done look like
Authority to plan in detail
Done Detailed Description
Negotiate with stakeholders
Balance Requirement Candidates
Business Requirements
Product Requirements
Systems Engineering
Value Engineering
Technical Performance
Accepted Requirements
Project Scope Management Plan
How will we define, develop, verify Scope, WBS
How will we manage Changes to Scope
Product Scope Management Plan
Product Technical Performance Requirements "CSF" Critical Success Factors
How will we define, develop, engineer, verify Product Performance
How will we manage Changes to Product Technical Performance
Conformance to requirements and Fitness of use
High Level
Risks, Quality
Work Breakdown Structure
Define Deliverables
S pecific
M easurable
A ssignable
R ealistic
T argeted
Management Level
Team Level
Scope Baseline = Scope Statement + WBS + Dictionary
Breakdown smaller and smaller
Visual Map
Where are we going?
PMI Practice Standard WBS
Must Have
Should Have
Could Have
Don`t Want
or "Shall"
or "Reject"
Significant Point or Event "No Duration"
What are we actually doing?
Reasonable and Realistic
Rolling Wave ->
1 week ?
2 weeks ?
1 month ?
3 months ?...
Pick a time pattern that makes sense. Get everyone to agree in detail for that time “Planning Package”,

“Planning Package” we all know what done looks like. Fully Specified.
Team level +/- 5 %, Subject Matter Expert
Close the phase gate, analyze in Retrospective, document your lessons learned. Open next Gate.

“Summary Package” we kind of know what done looks like.
Analogous Medium Level Plan +/- 25%

“Known Package,” we all agree that we will spend some budgeted time and money to do something
Order of magnitude “Heuristic” rule of thumb, experts only
We will worry about that when the time comes
Knowing when enough is enough is enough to know
Management Level
Team Level
1 Deliverable may have many activities
Parametric, Three Point...
Work Package
How do we get there?
Finish to start
Finish to Finish
Start to Finish
Start to Start
(Dig Foundation) FS (Pour Concrete)
(Write Code) FF (Write Documentation)
(Execute Project) SS (Monitor Project)
(start New Shift) SF (Finish First Shfit)
Mandatory Predecessors (Hard Logic) "Have to",
Discretionary Predecessors (Preferred or Soft Logic) Its a good idea to, Best Practices, External Predecessors
Lag. A modification of a logical relationship that directs a delay in the successor activity.
Lead. A modification of a logical relationship that allows an acceleration of the successor activity.
tools, people, materials, things
Do we have enough resources?
Bottlenecks of equipment, people, places......
Schedule activities have alternative methods of accomplishment using various levels of resource capability or skills, different size or type of machines, different tools (hand versus automated), and make-or-buy decisions (procurement) regarding the resource.
When and How Long?
What Kind and How Many per Activity Level?
Categories, Type, Grade, Quantities
Go back, Refine Activities, Scope
or Dictionary
Do we have enough resources?
Work Periods
Cone of Uncertainty
Variance ~ Small Changes Critical Path
Foreseen Uncertainties~ Identifiable and Understood
Unforeseen Uncertainties~ Unidentifiable
Chaos ~ Scientific Research Project "Alice in Wonderland"
How much time does the project need to be confident of being on time?
For example: difference between "Most Likely" and Expected Duration.
Amount of time to respond to "Unforeseen" risks.
Effort. The number of labor units required to complete (Scale to Units that are meaningful for the granularity required)
Duration. The total number of work periods (not including holidays or other nonworking periods) required to complete.
If it takes 80 hours of effort to complete

1 resource available for 40 hours 5 days a week. Duration is 10 days or 2 weeks.

4 resources available 40 hours 5 days a week. Duration is 20 hours or 2.5 Days
Similar ~ fast ~ Good for looking out at the horizon
Math ~ cost per square meter ~ repetitive work
Best case, most likely, worst case. Range of Estimates-> PERT, Monte Carlo
or "Dictionary"
fidelity and precision
Do we have enough resources?
How long will it take?
Use what you have to create the schedule
Do we have enough resources?
How much will it cost?
Do we have enough resources?
How much will it cost?
How often evaluate risks?
What Tools do we use?
How will Risk Reserves be used?
Credible, Realistic and Approved
Execute the Plan
World Wide Web
Project Management Institute (U.S.) A guide to the project management body of knowledge (PMBOK® Guide) Project Management Institute, Inc., Newtown Square, Pa. : 2012
Stackpole, Cynthia Snyder
A User's Manual to the PMBOK Guide

Glen Alleman http://herdingcats.typepad.com/

Herzberg's Theory of Motivation
McGregor Theory X and Y
Hygiene ~ Don't motivate ~ The Way implemented or not implemented may lead to employee dissatisfaction
Motivation ~ lead to higher performance
Working Conditions
Interest in the job
Job Challenge
X Management believes that workers will do as little as possible to get by, and need lots of direction
Theory Y states workers are interested in doing their best and given freedom will perform well.
Maslow's Hierarchy of Needs
What do people really want?
David McClelland's Theory of Needs
"Acquired Needs Theory"
People are motivated by need thus managed
Need for Achievement
Need for Affiliation
Need for Power
Challenging but Reachable projects
Like recognition
Enjoy cooperating with others
Seek approval rather than recognition
Honesty creates conflict
Conflict creates energy
Energy creates commitment
Commitment creates results
team building
Trust is the heart of global project management @Jean Binder
People perform projects
Who will do what when
Human Resource Plan
Recognition & Rewards
Team Building
Secure limited resources
Who will do what when.
Human Resource Plan
Resource availability
Perform planned work to achieve objectives.
Change Requests:
1.Corrective Actions: Documented direction for executing the project work to bring expected future performance of the project work in line with the project management plan.
2.Preventive Actions: A documented direction to perform an activity that can reduce the probability of negative consequences associated with project risks.
3.Defect Repair: The formally documented identification of defect in the project component with a recommendation to either repair the defect or completely replace the
What Deliverables are done?
Tailor to Product of the Project
Proactive People Management
Day to Day
Feedback and Issues
Management by walking around
Stay in touch with
Working Conditions
Conflict Management Techniques
Problem Solving
Smoothing or Accommodating
Withdrawal or Avoiding
If there is Time and Trust
When the Objective is to learn
If you have confidence in the others Ability
When you need a win-win
If you want to maintain and build good relationships
When you need buy-in to the solution
If the situation is complex
When you need the best possible resolution
When both parties need to win
When you can't win
Equal Relationship
To Maintain relationship
When the stake are moderate
To avoid a fight
To reach an overarching goal
To maintain harmony
When any solution is adequate
When you will lose anyway
To create goodwill
When you are right
In a do-or die situation
High Stakes
To gain Power
If relationship is not important
When time is of the essence
When you can't win
When the stakes are low
To preserve neutrality or reputation
If the problem will go away
Issue log documents situations that need attention on the project
Why Conflict?
1. Schedules
2. Project Priorities
3. Resources
4. Technical Opinions
5. Administrative procedures
6. Cost
7. Personality
Problem Solving Methods
1. Define what is the real or root problem, not appearance
2. Analyze the problem
3. Identify Solutions
4. Pick a solution
5. Implement a solution
6. Review the solution, and validate problem is solved
Individual Performance on Project
Sender-receiver models
Choice of Media
Writing Style
Meeting Management techniques
Presentation Techniques
Facilitation Techniques
Interactive ~ conversation..
Push ~ Email
Pull ~ Wiki, Sharepoint
Set time limits
Schedule in advance
Agenda ~ team
Distribute Agenda before
stick to the Agenda
Salient people
Chair and Lead with rules
Integrate new work with change Control
Document and Publish meetings
Execute the Communications Plan
Respond to Information Requests
Is the quality process effective?
Validate and Improve
Are Process followed?
Are metrics valid?
Is "The Quality Plan" valid with "Reality"
Will the customer be satisfied?
If not, how can we pivot and improve?
Continuous Improvement
Integrated Change Control
A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.
Wayne Gretzky
Product and Project
Technical, Schedule, Cost Performance
Review, Analyze, Approve, Implement
Change Process Checklist
.1 Prevent Root Cause
.2 Actively Search for Change "Candidates"
.3 High Level "Candidate" Assessment
.4 Create "Formal" Change Request
.5 Perform Integrated Change Control
.6 Cascade the Approved Changes Update all the Documents
.7 Validate the Approved Change
Configuration Management
Monitor & Control Quality
a. Detailed Assessment ~ "Beneficial to the project"
b. Alternatives Analysis ~ Simulate what if
c. Change is Approved or Rejected ~ by The Organizations System "Change Control Board"
d. Update Status of the Change
Did we get the outcome we predicted?
Did you really identify the requirements?
Earlier is usually cheaper, easier
Collect, Compile, Analyze
"Change Request"
Performance Measurement Baseline
Inputs to Integrated Change Control
How long are you willing to wait before you find out you are late?
<Government, Industry> Regulatory, Product, Quality, Workmanship...
Work Authorization System
Control who works where when
Stakeholder risk tolerance
How comfortable key people are with taking chances
Standard Procedures
Communication, Finance, Quality, Risk
Corrective Action ~ How to return to baseline
Preventive Action ~ How to stop a Risk Trigger
Defect Repair ~ Repair or Replace
Interpret the Information
Interpret and Confirm Contractual Obligations
Seller performance reports, technical documentation… indicate which deliverables have been completed and which have not..
dispute resolution
tracking systems
Is the seller performing?
"Seller Change Request"
Invoices, Reports, Payments, Quality, Risks......
Formal, Legal, Critical
.1 Cause and Effects Diagrams
.2 Control Charts
.3 Flowcharting
.4 Histogram
.5 Pareto Chart
.6 Run Chart
.7 Scatter Diagram
.8 Statistical Sampling
.9 Inspection
.10 Approved Change Requests Review
Are we meeting the standards?
Visualize and Verify
Measure Quality
Identify improvements
Validate Deliverables
Complete Checklists
Prevention ~ establish processes to make sure errors or defects don't occur.
Inspection ~ ensuring defective parts do not reach the customer.
Attribute Sampling ~ Determining if results conform or not.
Variable sampling ~ Determine the degree of conformity
Control Limts ~ thresholds that define in and out of control.
Quality standards and Policies
Standard Work Guidelines
Issues-defects reporting procedures and communication policies
Cause and effect diagrams, also called Ishikawa diagrams or fishbone diagrams, illustrate how various factors might be linked to potential problems or effects
Control Charts graphically answer the question: “Is this process variance within acceptable limits?”
Flowcharting Analyzes the steps in a failing process steps and identifies potential process improvement opportunities
A histogram is a vertical bar chart showing how often a particular variable state occurred
A Pareto chart or diagram~ specific type of histogram, ordered by frequency of occurrence. Rank the cause of defects by type or category.
Run Chart ~ history and pattern of variation.
Forecast Future Performance
Future Technical Performance
Scatter Diagram ~ shows relationship between two variables
Analyze possible relationships between two variables.
Closer two points are to a diagonal line more closely related
The Teams GOAL
Did the Approved Changes we Made from "Integrated Change Control" Work?
This is everything that we think the customer will accept. The Input to 5.5 Validate Deliverables
From 4.3 Direct and Manage Project Work
Implementing Risk Response Plans
Monitoring Residual Risks
Identifying new risks
Evaluating Risk Process Effectiveness
Continuous Risk Management
Risk Plan
ID New Risks
How have Identified Risks Changed?
Can Risks be closed?
How effective are strategies?
How should we modify the contingency reserves?
Is our Risk Process working?
Are we putting out fires?
Are we spending time looking at what might stop us in the future?
Did the responses we used work?
Technical performance measurement compares technical accomplishments during project
execution to the project management plan’s schedule of technical achievement. It requires definition
of objective quantifiable measures of technical performance which can be used to compare actual
results against targets. Such technical performance measures might include weight, transaction
times, number of delivered defects, storage capacity, etc. Deviation, such as demonstrating more or
less functionality than planned at a milestone, can help to forecast the degree of success in achieving
the project’s scope, and it may expose the degree of technical risk faced by the project.
What is our technical performance risk?
Can we actually make the product we thought we could?
Does the amount of the remaining contingency reserves match the amount of risk remaining?
Communication is the key to surfacing Risks
What is the ratio of ID Risks to actual Actual Risks?
Customer Product

From 8.3 Quality Control
To 4.6 Close project or phase
Close Contracts: Completion, Cause or Convenience
• What went right or wrong
• Learn Lessons
• Continuously Improve
• every contract
• before project closure
• formal record keeping
Settle by
• Negotiation
• Alternative Dispute Resolution
• Litigation
Formal Indexed Procurement Files
Accepted or Rejected Deliverables
Formal Acceptance
The Contract
Change Control
Performance Information
• Continuous Improvement
• Learning Lessons
o Compare final with conceptual
• Release Resources
Formal Final Phase
Select seller
how to
what is best
doing things right
doing the right things
5.5 Validate Scope
6.7 Control Schedule
8.3 Control Quality
11.6 Control Risk
13.4 Control Stakeholder Engagement
5.6 Control Scope
7.4 Control Cost
10.3 Control Communications
12.3 Control Procurements
Control & Validate Data by Output-ting Information
Perform & Manage Risky Procurement Reports by Output-ting Information
4.4 Monitor and Control Project Work
4.3 Direct and Manage Project Work
4.5 Perform Integrated Change Control
10.2 Manage Communications
9.4 Manage Project Team
11.6 Control Risks
12.3 Control Procurements
4.4 Monitor and Control Project Work
Part of Plan Scope Management
Against Baseline
Formal Document
List of Deliverables
Every project every time has to have a WBS...
This means a "Structured List of Deliverables"
Control Account is Special Intersection with Accounting
To Monitor Control Scope
To Monitor Control Scope
To Monitor Control Scope
To Monitor Control Scope
from Direct and Manage Project Execution

from Direct and Manage Project Execution

from Direct and Manage Project Execution

from Direct and Manage Project Execution

Mistake see fifth Edition

Direct and Manage always produces data
Information always inputs to Monitor and Control Project Work

Leadership, personally oriented
These people like to organize
Monitor and control project work
Manage Stakeholder Engagement
Who needs to know what information, when, why and how?
Monitor and control
Percent Chance, Impact ~ Cost Value, Schedule Value
Seven basic quality tools ~ Technique
Control Chart
Assignable Cause-Input Why
Cause and Effect
Why, why, why, why
Flow Chart
Check Sheet
From Flow chart process
Scatter Diagram (Regression Analysis)
Don`t know what is important….
Issue and Frequency
Pareto diagram
Focus on Critical few

Description of the project scope, major
, assumptions and constraints.
Product Scope Description
Acceptance Criteria
Project exclusions
Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. Deliverables also include ancillary results, such as project management reports and documentation. These Deliverables may be described at a summary level or in greater detail
Technique used for dividing and sub-dividing the project scope and project
into smaller, more manageable parts. The level is often guided by the degree of control needed to effectively manage the project
Full transcript