Project Management Cheat Sheet

A project is defined by:

Scope, Schedule, Resource: All sides must be balanced--so if scope gets larger, schedule and resources will
have to be adjusted to suit.

1. Initiate The Project

1.1 Review The Project Proposal

Full Proposal Minimum Information

Business case Project purpose

High level scope, Scope target
schedule, resources
Success criteria
Costs
Risks
Alternatives
Recommendation

1.2 Validate Proposed Objectives

Cycle of Validity: A concept describing the continuous process of validating project decisions - not a single event.

2. Define & Organize The Project

2.1 Establish The Project Organization - Who is the Team
1. Project Leader/Manager: Achieves objectives, establishes & leads team, manages project management
process

2. Core Team: Keep small and functional. Consider what skills will contribute to the success of the project and
who will benefit.

3. Extended Team: Part-time involvement or involved for specific tasks or phases. Includes Subject Matter
Experts (SMEs)

4. Other Stakeholders: Management, Sponsor, etc. A Project Sponsor authorizes project, appoints PM,
authorizes team, mentors and supports team, approves plan. Never deliver news good/bad to the whole group
before reviewing with the sponsor first.
- Success Criteria: what do the sponsors and key stakeholders think we’ll have at the end of the project?

2.2 Define the Project Parameters - What the Team will do

Project Description Document (PDD): Includes:
Project Objective Statement (POS)
Success Criteria
Flexibility Matrix
Major Deliverables with Is/Is Not Lists
Other documents that add to the definition of the project

1. Project Objective Statement (POS):

● Clear: no ambiguity (make sure acronyms are clear)
● Concise: 25 words or less
● Complete: addresses scope, schedule & resource
Tips:
● Focus on the ‘What’, not why or how
● Address the triple constraints of scope, schedule and resources
● Start your statement with action-oriented words (build, develop, implement, deploy, etc.)
● Shoot for an unambiguous statement in 25 words or less
● Avoid including strategic business targets (e.g.. increase market share, lower customer complaints, etc.)
 ● Type over the above sample with your project POS

2. Success Criteria
Defines successful project completion per the stakeholders and the sponsor. What does it include and what
does it not include.

3. Flexibility Matrix : Where the ‘give’ is.

4. Major Deliverables w/ Is/Is Not List

Final Deliverable: = Scope. Take scope in the POS & decide what the main pieces of work that have to be done
to deliver. Each piece of work is a Major Deliverable (3-10 per project).

Define each deliverable including:

● Is/Is Not List: See below:
● Completion Criteria: Completion Criteria is what does done look like? Develop a completion criteria for
each major deliverable and final deliverable.
● Date Constraints

Is/Is Not List

It doesn’t have to be long, bullet points are ok. Think of it as insurance from the stakeholders and sponsor so
that what we have stated on the ‘is not’ list doesn’t creep over to the ‘is’ list when scope/requirement change.

Is Is Not

what is it what it isn’t

what does it do what doesn’t it do
what does it look like “wants” not included
what will be included in the next project
how does it work
the “nice-to-haves” that won’t be in this project
what is its size
what are people likely to ask for that you do not
“must haves” intent
“wants” that you will include
5. Any Other Documents

**KEY VALIDATION POINT - Get the PDD Validated by the Sponsor**

2.3 Integrate the Project Scope - Only If Project is part of a Program

2.4 Define The Project Infrastructure - How the Team will operate.
Infrastructure: Written guidelines and procedures that will define how the project core team will plan, manage,
track and report on the project

Processes and Procedures Categories:

Planning Tracking Practices Relationships

Development Tracking Project File Ownership

Deliverables Reporting Managing Communication
Tools Meetings Change Escalation
Continuous
Improvement
Lifecycle

Team Logistics:

Physical needs Automation needs

Facilities Hardware
Office equipment Software
Communication equipment and infrastructure Intranet
Furniture Networks
Website

3. Plan The Project

3.1 Develop The Work Breakdown Structure (WBS)

Planning Methodologies:
Phase Planning: As below. There is a risk of delay if any phase doesn’t complete on time.
Concurrent Planning - AKA Rapid Application & Design: Begin work tasks while planning continues. Ensure that
work doesn’t start to drive planning or that unnecessary work gets done

Rigor: How rigorous will you be as a project manager everything in the project, are you going to delay step 2
until step 1 is complete, or will you be more flexible

Work Breakdown Structure

● Tool for identifying project work, detailed tasks of the project
● Hierarchical, logical structuring of project work
● Comprehensive methodology, complete. If it’s not in the WBS it isn’t in the scope of the project.
Aggregation of all the project work.

WBS - Example for Making a fist and shaking it...

Level 1 = Major Components, often the Major Deliverables
Level 2 (+) Tasks = Tasks necessary to complete major components. Often the ‘Is’ statements.

Top-Down vs Botton-Up
Top-Down:
Have the team:
1. Identify 4 - 7 major components of work (how you will manage work)
2. Identify Level 2 (+) tasks for each grouping
● with one owner (may be multiple doers),
● Clear deliverable,
● 2 - 20 days duration,
● Credible estimate of duration,
● Ability to be tracked
4. Use Verb-Noun: action statements including who/what

Bottom-Up:
Have the team:
1. Brainstorm all tasks
2. Organize tasks into 4 -7 major groupings reflecting how the project will be managed

WBS Formats & Coding

Coding usually follows WBS
Automatically assigned by some systems
Task Completion Criteria
● Specific definition of task output
● Needs to be clear and binary (you did or you did not)
● Extremely important for interfaces and tracking

Task Ownership
● One owner/task, responsible for planning and managing task
● Owner may or may not be “doer”
● Plan and manage the work
● Identify requisite skill sets
● Estimate task duration
● Act as point-of-contact until resources are assigned
● Ensure work is to specifications and within schedule

Task Information Database/WBS Dictionary

Consider other columns:

Predecessors, Duration estimates, Successors, Assumptions
Preliminary Schedule
1. Identify what the logic is, what comes first, second, etc.
2. Task duration estimates

Logic
Dependency Diagram: Flow/sequence of work form start to finish:

● Frequently based on judgment about sequence

● No dates yet
● Terminology: Dependency Diagram, Logical, Networks, PERT, Network Diagram

Types of dependencies, start-to-start, start-to-finish, finish-to-finish. With or without lag.

Everything has to be connected from start to finish.
Annotation Dos:

Annotation Dont’s
Avoid Loops.

Milestone: A point in time, no duration or work:

● Start/Finish
● Significant events (e.g., trade shows)
● External dependencies/deliverables
● Major accomplishments
● Phase signoffs
● Intermediate checkpoints
● Status reporting periods
Marked by:

Estimating Methodology: Key Elements of Successful Estimating

1. Follow the PM process:
Assure excellent WBS
Negotiate and agree on task completion criteria
Assure 2 to 20 days task duration
Understand and validate your assumptions

2. Consider the number of people: Adding people to a task cuts down on the time it takes to complete the task.
Be sure to consider communication lines when adding bodies to a task to speed up an estimate.
3. Consider productivity: Average 4.6 productive hours in a productive day.
No padding - use Management Reserve:

No fractional days
No task duration greater than 10% of project phase
Managers: Don’t arbitrarily alter estimates
Estimators: Don’t just give in to pressure
Use multi-approaches - compare results
Perform peer reviews
Watch for overly optimistic/pessimistic estimates
Apply more intensity for critical path tasks

4. Assure equal probability that actual duration will be longer or shorter than estimate

5. Document assumptions
Rigors of Estimating
Low Rigor:
● Just use the last estimate
● Add an “allowable” slip to the previous estimate
● What does the boss want to hear?
● Subtract the past slip from the new estimate

Medium Rigor:
● Apply historical data
● Apply rules of thumb
● Gather expert input
● Break large tasks into smaller ones
● Complete a portion, then extrapolate

Maximum Rigor Estimating:

PERT Estimation: (Performance Evaluation Review Technique)
Most common form of maximum rigor estimation.

Also: COCOMO (COnstructive COst MOdel) & Delphi Methods

Effort (doesn’t =) Duration (doesn’t =) Calendar Time

Optimistic Fact Based Pessimistic

Fact based estimate = fact based duration estimate. Productivity and “wait time”

Critical Path Method (CPM)

● Critical Path (CP) is longest and least flexible sequence

● Any slippage on Critical Path slips project
● Only way to shorten schedule is to shorten CP
● CP focuses management attention

Identifying Resources
● Task owner identifies the resource needs - Functional Manager provides the resources
● Dependent on rigor
○ May only have titles or organizations later in the plan
● Occurs from the proposal phase through Track & Manage
○ Document assumptions that affect resources
○ Document/manage issues
○ Update/communicate Team Roster when necessary

Clarify expectations (Sponsor, Functional Manager, Project Manager)

● How to assign resources (near/long term plan)
● What tools to use in resource management
No resource commitment - no plan
Document assumptions about inputs that affect resource requirements
● Team Roster, WBS Dictionary name, skill set
Manage team members wisely:
 ● Attitudes
● Experience
● Utilization constraints, etc.

3.5 Optimize The Project Plan

Optimizing
● Meet POS
● Consider impact on team
● Good business sense
● Tradeoff among 3 parameters with guidance
● from flexibility matrix

Two Steps Of Optimizing:

1. Modify the preliminary plan to achieve the POS
Stay within the boundaries of the POS
Act on ideas for which you have authority
Perform “what-if” analysis

2. Propose modifications to the project objectives if the POS is still not met
Modifications could be significant
*Prepare three options and a recommendation
Provide “what-if” analysis
Present to the sponsor for approval (using below template)

Sponsor Tradeoff Analysis Template

Take one issue at a time (be specific)

Is the problem about scope, schedule or resource?
Take on the tactics, look for ideas about solution.
Benefit & Tradeoff analysis (leads to
recommendation)

KEY VALIDATION POINT--If changes will be made ie: Step 2 of Optimization.

“What if” fact-based alternatives
Multiple (3) options and a recommendation
Present recommendation for management decision-making
3.6 Develop Risk Management Plans
Risk Management
1. Identify risks
“Parking lot” risks
Scope, schedule, resource risks
General brainstorm

2. Assess Risks
Risk Assessment Matrix

Ask these four questions of each risk and rate each risk High, Medium, Low. Do not average first three to get
fourth.
1. Potential Impact
2. Likelihood of Occurrence
3. Difficulty of Timely Detection: The higher the surprise of the risk occurring the higher the rating. If you
can see the risk coming then you give it a lower rating.
4. Overall threat = do we need an impact plan for this risk? High=Yes, Low=No, Med=Time dependent

3. Create Risk Management Plans

Preventive Actions reduce the likelihood of a risk occurring

Contingency Plans will address each and every effect of a risk if it were to occur

At what point does a contingency plan become an action?

Triggers: The metric value that triggers the contingency plan
Six Elements of an Effective Trigger:
1. Functional
2. Specific
3. Appropriate
4. Binary
5. Timely
6. Automatic

Risk Management Plan

Risk management planning matrix:

KEY VALIDATION POINT - PROJECT PLAN

Can you meet POS? If no, 3 options and recommendation
Major components of WBS
Optimized schedule (Gantt with critical path)
Major resource issues
Significant risks and their management plans
Open issues/key assumptions

Project Baseline
Snapshot of approved plan
Establishes a target
Provides something to measure progress against
Makes project goals visible

Once the Project is baselined, use Change Management for any changes to the Project Plan
Change Management:
● Review proposed changes
● Log all changes
● Validate if outside POS
● Announce changes
4. Track & Manage The Project
Tracking:
● Provides clear indication of progress
● Keeps everyone informed
● Encourages the addressing of problems
● Provides credible completion estimates
● Provides data for Organizational Mastery

Tracking Continuum:

Tracking Intensity Guidelines

Trac
king Tactics
Hard - Quantitative: What is happening?
1. If started, on what date did the task start?
2. If not started, on what date will the task start?
3. If finished, on what date did the task finish?
4. If not finished, on what date will the task finish?
Soft - Qualitative: Why is it happening?
● Listen
● Ask why
○ “Tell me more …”
○ “Help me understand …”
● Be alert to:
○ Requirements changes
○ Customer requests
○ Organizational issues, changes

Request Status Data From Task Owners:

Variance Analysis
Many standard reports show variance
Backtrack slippage
Variance tells “what” (hard data)
More detective work for “why” (soft data)

Adaptive Action
If significant variance is identified, take Adaptive Action (like Optimization)
● Redefine Logic
● Use Flexibility Matrix
● Re-deploy resources
Might trigger contingency plans
May require revalidation (3 options and 1 recommendation)

Managing Issues:
Issue: A problem that is currently impeding the project. Today’s issue is yesterdays risk!
● From status data
● From meetings, discussions
Identifying Issues:

Issue Log

Responding To Issues
Manage the issues log
Issues resolution meetings
Hold issues owners accountable
May affect scope, schedule, or resources
May need to update the plan
May need to escalate to the sponsor
Communicate appropriately

Addressing Change
Change: A modification in the scope, schedule or resources of a project
● In requirements, scope
● In schedule targets
● In resources
Change could be: An opportunity for new business/An opportunity for organizational learning

Addressing Change
1. Document the need/request for change
Internal
External
2. Follow the Change Management process
Change Request Form
Analysis
3. Proceed to the appropriate step in theProject Management Model, if necessary

Managing the Communication Process

Dashboard - Example: