Planning Processes

1
Planning Processes
2
Project Kickoff
3
The Good Start

• Conduct a project kickoff meeting to set
  expectation levels
• What will be done by whom
• What are the risks concerns
• How the project will be done
• What are the control processes
• What are the communication processes
• When will we be done
• Solicit individual commitments

Project Start Explosion
4
PMBOK Planning Core Processes
5
Planning Process
From Initiating Processes
Core Processes
6.2 Activity Sequencing
5.2 Scope Planning
6.4 Schedule Development
6.1 Activity Definition
6.3 Activity Duration Estimating
To Executing Processes
7.3 Cost Budgeting
5.3 Scope Definition
7.2 Cost Estimating
7.1 Resource Planning
4.1 Project Plan Development
11.1 Risk Management Planning
From Controlling Processes
Facilitating Processes
8.1 Quality Planning
10.1 Communications Planning
11.2 Risk Identification
11.3 Qualitative Risk Analysis
11.4 Quantitative Risk Analysis
9.1 Organizational Planning
9.2 Staff Acquisition
12.1 Procurement Planning
12.2 Solicitation Planning
11.5 Risk Response Planning
6
Planning Processes
Core Processes
Facilitating Processes

• Primary Activities
• Detailed Planning
• Detailed Estimating
• Detailed Scope Reqs Definition
• Staff Assign Roles Responsibilities
• Develop Detailed Project Plans (Risk,
  Communications, etc.)

• Primary Support
• Project/ROI Estimator Tools
• Project Scheduling Tools
• Project Plan Templates
• Project Status Reports
• Project Archives Established
• PMO Reporting

• Primary Products
• Project Plan, Schedule, supporting Plans
• Status Reports
• Project Metrics
• Project Engineering Notebooks
• Project Artifacts in Management Archive

7
Project Scoping
8
5.2 Scope Planning

• .1 Inputs
• .1 Product description
• .2 Product charter
• .3 Constraints
• .4 Assumptions
• .2 Tools Techniques
• .1 Product analysis
• .2 Benefit/cost analysis
• .3 Alternatives identification
• .4 Expert judgment
• .3 Outputs
• .1 Scope statement
• .2 Supporting detail
• .3 Scope management plan

Check your PMBOK Section 5 pages 55-57 for more
information related to this section
9
5.3 Scope Definition

• .1 Inputs
• .1 Scope statement
• .2 Constraints
• .3 Assumptions
• .4 Other planning outputs
• .5 Historical information
• .2 Tools Techniques
• .1 Work breakdown structure templates
• .2 Decomposition
• .3 Outputs
• .1 Work breakdown structure
• .2 Scope statement updates

Check your PMBOK Section 5 pages 57-61 for more
information related to this section
10
Scoping Process
Product Description Charter examined
Perform detailed product analysis
Determine product top-level Work Breakdown
Structure (WBS)
Generate Scope, Assumptions, Constraints
Publish WBS
11
Scoping - Requirements
12
Now The Hard Part

• Scope Statement Requirements Generation
• One of the most challenging areas associated with
  project management development
• If this doesnt go well, trouble will surely
  follow
• If you tell what you want youre likely to get
  everything but what you really need

13
Requirement Experiment

• Question Without looking back in your material,
  how many points were on the Project Start
  Explosion
• Why this exercise is important
• How do we explain answer differences - sources
• Observational
• Recall
• Interpretation Errors
• Problem Statement Ambiguity

14
Observational Recall

• No two individuals can be expected to see things
  identically
• No two individuals can be expected to retain or
  recall things identically
• This is not a statement about intelligence - It
  is a statement about perspective, experience,
  determining relevance adaptive communication

15
Interpretation Ambiguity

• Interpretation tends to create clusters of
  diverse answers that can be grouped
• This clustering aspect is viewed as a useful
  indicator of ambiguity
• Problem statements (requirements) that are not
  precise tend to result in subtle differences that
  could mean success or failure

16
Ambiguity Experiment

• Question Without going back in your material,
  write down to the best of your recall ability,
  the question about the project start explosion
  that you answered
• Notice the variants
• This is a simple application imagine the
  variants when the issues are more complex,
  numerous, a great deal of time has transpired

17
How To Proceed

• PMs may not necessarily participate in the
  requirement generation process
• But, they are responsible for managing the
  implementation process so they must ensure the
  management validation of requirements
• Ensure expectations are set by insisting
  all-parties review approve all requirements

18
Requirements Describe

• User-level behaviors or functionality
• General system properties
• Integrating systems components
• Operational constraints
• Business rules
• Development constraints

19
Clarity Requires

• Defining special terms used
• Working toward successive elaboration
• Using pictorial system representations
• Tracing requirements to representations
• Keeping requirements at the proper level
• Ensuring requirements are consistent with each
  other

20
For Completeness

• Tell what users need how well this must be done
• What will be accomplished functionally
• The data base groups items to be stored
• Performance requirements
• Hardware software systems involved

21
Requirements Must Be

• Correct They must apply to the system
• Non-ambiguous Only one interpretation
• Complete Everything is covered
• Consistent No conflicts
• Verifiable Can be checked to see if met
• Traceable Evident in design function

22
The Transition

• When you have all the requirements (system
  contract) you have a model of the project scope
• System models identify structure through objects,
  functions components
• Once structure is evident, it can be decomposed
  into logical work packages
• Packages are the key elements of a high-level
  work breakdown structure (WBS)

23
What Is A WBS

• A work breakdown structure (WBS) is a
  deliverable-oriented grouping of project elements
  that organizes defines the total scope of the
  project using tasks
• The WBS is a Key tool used by PMs to ensure the
  tasks integrate to build a system
• A WBS structure is composed of levels

24
WBS Level Example

• Level 1 Total Program
• Level 2 Project
• Level 3 Task
• Level 4 - Subtask
• Level 5 - Work Package
• Level 6 Level of Effort

Leaf Tasks Have No Child
1.0
1.2
1.1
1.1.2
1.1.3
1.1.1
1.1.3.2
1.1.3.1
1.1.3.4
1.1.3.3
1.1.3.2.a
120 Person Hrs XXXXX.XX
25
WBS Rules

• The customer is involved in defining the top 3
  levels
• Designers/Developers normally define levels 4-6
• Each work package has characteristics
• Discrete unique units of work described
• Assignable responsibility with specified results
• Specified start stop dates
• Levels of effort associated costs
• Results in a product or output of some type

26
WBS Nature

• Its a primary project communication device
• It drives the estimated project schedule
• It is discrete understandable
• Contains measurable milestones products
• Tasks remain flexible with appropriate sizing
  Good rule of thumb no task should be lt 1 no gt
  10 of total project level of effort

27
WBS Variants

• Contractual - CWBS
• Deliverables - DWBS
• Organizational - OWBS
• Resource - RBS
• Bill of material - BOM

28
Activity Definition Process
29
6.1 Activity Definition

• .1 Inputs
• .1 Work breakdown structure
• .2 Scope statement
• .3 Historical Information
• .4 Constraints
• .5 Assumptions
• .6 Expert judgment
• .2 Tools Techniques
• .1 Decomposition
• .2 Templates
• .3 Outputs
• .1 Activity list
• .2 Supporting detail
• .3 Work breakdown structure updates

Check your PMBOK Section 6 pages 65-68 for more
information related to this section
30
6.2 Activity Sequencing

• .1 Inputs
• .1 Activity list
• .2 Product description
• .3 Mandatory dependencies
• .4 Discretionary dependencies
• .5 External dependencies
• .6 Milestones

Check your PMBOK Section 6 pages 68-71 for more
information related to this section
31
6.2 Activity Sequencing (Continued)
Check your PMBOK Section 6 pages 68-71 for more
information related to this section

• .2 Tools Techniques
• .1 Precedence diagramming method (PDM)
• .2 Arrow diagramming method (ADM)
• .3 Conditional diagramming methods
• .4 Network templates
• .3 Outputs
• .1 Project network diagram
• .2 Activity list updates

32
6.3 Activity Duration Estimating
Check your PMBOK Section 6 pages 71-73 for more
information related to this section

• .1 Inputs
• .1 Activity list
• .2 Constraints
• .3 Assumptions
• .4 Resource requirements
• .5 Resource capabilities
• .6 Historical information
• .7 Identified risks

33
6.3 Activity Duration Estimating (Continued)

• .2 Tools Techniques
• .1 Expert judgment
• .2 Analogous estimating
• .3 Quantitatively based durations
• .4 Reserve time (contingency)
• .3 Outputs
• .1 Activity duration estimates
• .2 Basis of estimates
• .3 Activity list updates

Check your PMBOK Section 6 pages 71-73 for more
information related to this section
34
6.4 Schedule Development

• .1 Inputs
• .1 Project network diagram
• .2 Activity duration estimates
• .3 Resource requirements
• .4 Resource pool description
• .5 Calendars
• .6 Constraints
• .7 Assumptions
• .8 Leads lags
• .9 Risk management plan
• .10 Activity attributes

Check your PMBOK Section 6 pages 73-78 for more
information related to this section
35
6.4 Schedule Development (Continued)

• .2 Tools Techniques
• .1 Mathematical analysis
• .2 Duration compression
• .3 Simulation
• .4 Resource leveling heuristics
• .5 Project management software
• .6 Coding structure
• .3 Outputs
• .1 Project schedule
• .2 Supporting detail
• .3 Schedule management plan
• .4 Resource requirement updates

Check your PMBOK Section 6 pages 73-78 for more
information related to this section
36
7.1 Resource Planning

• .1 Inputs
• .1 Work breakdown structure
• .2 Historical Information
• .3 Scope statement
• .4 Resource pool description
• .5 Organizational policies
• .6 Activity duration estimates
• .2 Tools Techniques
• .1 Expert judgment
• .2 Alternatives identification
• .3 Project management software
• .3 Outputs
• .1 Resource requirements

Check your PMBOK Section 7 pages 85-86 for more
information related to this section
37
Activity Definition High-Level Process
Generate detailed task definitions
Perform task sequencing analysis
Determine task duration's resource needs
through analysis
Develop the plan schedule
38
Whew! Looks Like Work

• We more or less know the scope
• Then we can put the tasks in the right order
• We need to pick a project management scheduling
  tool
• Many different tools are available
• We need to flesh out the task descriptions
• Determine resource needs, costs, bodies
• Then we can build a schedule its so easy

39
Lets Examine The WBS

• Use IDEF modeling of the project to create WBS
• Each Task activity has
• Inputs - Information or material to be
  transformed by activity
• Controls - Constraining Policies, Procedures,
  Requirements
• Mechanisms - Resources such as Tools, Techniques,
  Templates
• Outputs - Represent the transformed activity
  material

ICAM Definition Method (IDEF)
40
Lets Try An Example
Controls Project Charter Agency Business
Plan MITA ITSD Development Policy Budget
Inputs Project Scope Requirements Historical
Data System Network Diagrams Preceding tasks
Outputs Project Schedule Requirements Spec
Specifications Requirements Project Plan Staffing
Requirements Subsequent tasks
Perform Planning Activities
Mechanisms Requirements Management
Tool Estimation Tools MS Project
41
WBS Generation Process

• Use a WBS Dictionary to flesh out project task
  details
• Use IDEF modeling to help determine activity
  sequencing dependencies
• Understand the resource skill-set to determine
  productivity rates durations
• Build a high-level schedule

42
WBS Dictionary
43
Task Sequencing

• Task sequence dependencies types
• Mandatory - Construction has to follow design
• Discretionary Preferred flow
• External - Needs or impacts of outside parties
• These sequences are depicted using Network
  Diagrams - sometimes called PERT charts

44
Network Diagrams

• Two basic Network Diagram types
• Activity-On-Node (AON) or Precedence Diagramming
  Method (PDM) Boxes represent tasks
• Activity-On-Arrow (AOA) or Arrow Diagramming
  Method (ADM) Arrows represent tasks

Dummy tasks have no duration
A
C
B
Start
A
C
B
45
Task Relationship Types

• There are four task relationship types
• Finish-to-start - A task must finish before the
  next task can start - PDM ADM
• Finish-to-finish - A task must finish before the
  next task finishes - PDM
• Start-to-start - A task must start before the
  next task starts - PDM
• Start-to-finish - A task must start before the
  next task finishes - PDM

46
Estimating Fundamentals

• An estimate is an informed assessment of the
  likely project cost and/or duration
• Cost Duration are the estimate categories
• Without defined scope you should not estimate
• Use the CPM method to determine which tasks have
  the least flexibility
• Understand check the skills of the estimator

47
Estimating Task Effort

• Multiple methods
• Critical Path Method (CPM)
• Program Evaluation Review Technique (PERT)
• Precedence Diagram Method (PDM)
• WBS bottom-up
• Monte Carlo Simulation
• SWAGS, history benchmarks more often than not
• Just because it may be tool-based looks
  impressive on paper doesnt make it accurate

48
Method Differences

• CPM refers to single time/task estimate
• Emphasis on cost control schedule flexibility
• PERT refers to three times/task estimates
• Emphasis on schedule control cost flexibility
• PDM adds lag relationships to CPM PERT
• No particular emphasis besides lag time
• WBS forces more detailed analysis
• Monte Carlo Simulation is the most accurate,
  returning probability distributions

49
PMs Estimating Role

• Ensure that the people doing the actual work make
  the estimates, not the PM
• Ensure the team has enough information to
  properly estimate each task
• Complete a sanity check of the estimate
• Formulate a management reserve (more later)

50
Examining PERT
PERT uses three duration estimates
PERT Standard Deviation (P-O)/6
PERT Formula (P4MO)/6
PERT Task Variance (P-O)/62
Optimistic, Most Likely, Pessimistic
Estimates are in hours
Task
O
M
P
PERT
Standard Deviation
Variance
A
27
33
47
34.333
3.333
11.111
Answer - The task will take 34.333 hours /-
3.333 hours at one standard deviation or between
31 hours 38 hours to complete.
51
PERT Value

• Considered old-school today but is relatively
  quick easy way to estimate task durations
• Helps to identify uncertainty
• Wherever standard deviation variance values are
  high for a task, uncertainty is present. That
  means higher risk deserves watching
• Monte Carlo simulation utilizes a PERT format

52
Critical Path

• The critical path is the longest path through a
  network diagram
• The critical path determines the earliest
  completion of the project
• The path can change over time
• The critical path almost always has no slack
• Slack or float is the amount of excess or
  reserve time left before delaying the project

53
Slack (Float) Lag

• Slack is found by finding the difference between
  the earliest start date latest start date for a
  task
• Knowing this helps PMs prioritize work because
  they know the flexibility of each task
• Free Slack - Flexibility between tasks
• Total or Project Slack - Flexibility before
  project delay
• Lag - Wait time inserted between tasks

54
Reducing Float

• When float is reduced by a certain amount (n),
  float is referred to minus n
• Float can be reduced using two methods
• Crashing Analyzing tasks for opportunities to
  compress task durations using alternatives,
  tools, adjusting scope or resources
• Fast Tracking Modifying task relationships to
  allow concurrent operations vs. sequential

55
Critical Path Experiment

• Draw an PDM network diagram using the information
  below find the critical path

Preceding activity
Estimate in months
Task
Start
0
D
Start
4
A
Start
6
F
D, A
7
E
D
8
G
F, E
5
B
F
5
H
G
7
C
H
8
End
C, B
0
56
Critical Path Answer
E
8
G
H
C
7
8
5
D
4
F
B
End
Start
5
7
A
The critical path duration is 33 months
6
57
Critical Path Experiment 2

• Use the ADM network diagram on the next slide
  the information below to find the critical path

Estimate in weeks
Task
A
3
B
9
C
3
D
Dummy
E
2
F
2
G
1
H
4
I
2
58
ADM Diagram
F
C
I
A
End
D
G
Start
B
H
E
59
Critical Path Answer 2
F
C
I
A
End
D
G
Start
B
H
E
The critical path is B, E, H. The duration is
15 weeks
60
Critical Path Experiment 3

• Using your ADM network diagram, answer the
  following questions
• If the duration of activity G changes to 2, what
  is the critical path?
• What task(s) must be completed before task D
  begins?
• If management tells you to complete the project 2
  weeks early, what is the project float? Does the
  critical path change?

61
Critical Path Answer 3

• If G changes duration to 2 the critical path
  becomes
• B, E, H as well as B, D, G, H
• B must be completed before D starts
• The project float would be minus 2, the
  critical paths would not change

62
What Did We Learn?

• There can be more than one critical path
• A critical path can contain dummy tasks
• A critical path can change
• There can be negative float which requires
  crashing the schedule or fast-track solutions
• The network diagram doesnt change when the end
  date changes

63
Cost Estimating
64
7.2 Cost Estimating

• .1 Inputs
• .1 Work breakdown structure
• .2 Resource requirements
• .3 Resource rates
• .4 Activity duration estimates
• .5 Estimating publications
• .6 Historical Information
• .7 Chart of accounts
• .8 Risks

Check your PMBOK Section 7 pages 86-89 for more
information related to this section
65
7.2 Cost Estimating (Continued)

• .2 Tools Techniques
• .1 Analogous estimating
• .2 Parametric modeling
• .3 Bottom-up estimating
• .4 Computerized tools
• .5 Other cost estimating models
• .3 Outputs
• .1 Cost estimates
• .2 Supporting details
• .3 Cost management plan

Check your PMBOK Section 7 pages 86-89 for more
information related to this section
66
7.3 Cost Budgeting

• .1 Inputs
• .1 Cost estimates
• .2 Work breakdown structure
• .3 Project schedule
• .4 Risk management plan
• .2 Tools Techniques
• .1 Cost budgeting tools techniques
• .3 Outputs
• .1 Cost baseline

Check your PMBOK Section 7 pages 89-90 for more
information related to this section
67
Arent We Done Yet?

• You now have time estimates resource
  requirements - do you want to perform resource
  leveling?
• Resource leveling is a project management tool to
  take the peaks valleys out of resource load
  from one month to another
• Resource leveling almost always moves the
  schedule out costs up

68
Cost Estimating Fundamentals

• Labor, materials, supplies, licenses,
  maintenance, etc., must be factored into your
  cost estimates
• Rates/costs for all the above are needed
• Make sure to document your estimating work with
  supporting information
• PMs make sure your cost details match your
  accounting categories standards

69
How Is Estimating Done?

• Analogous estimating - Top-down, been there done
  that expert judgment
• Parametric modeling - Need good historical data,
  must be scaleable, generic parameters
• Bottom-up estimating - Rolling up cost work
  packages
• Computerized tools - Pretty rough in IT

70
Almost There - Budget

• When we have cost estimates we can create a
  project budget cost baseline
• The project budget can now be managed by tasks,
  milestones, phases based upon how the budget is
  assigned
• Dont forget to address project risk in your
  budget calculations

71
Project Plan Development
72
4.1 Project Plan Development

• .1 Inputs
• .1 Other planning outputs
• .2 Historical information
• .3 Organizational policies
• .4 Constraints
• .5 Assumptions
• .2 Tools Techniques
• .1 Project planning methodology
• .2 Stakeholder skills knowledge
• .3 Project management information system (PMIS)
• .4 Earned value management (EVM)
• .3 Outputs
• .1 Project plan
• .2 Supporting detail

Check your PMBOK Section 4 pages 42-45 for more
information related to this section
73
Putting It All Together

• We take the output off all previous planning
  activities put them into a consistent, coherent
  document
• This information becomes the Project Plan
• The Project Plan is supported with other project
  products
• Requirement, design, test, quality, etc., specs

74
Plan Checklist

• Project Charter
• Scope Statement - deliverables objectives
• WBS to the level the project is to be exercised
• Cost estimates baselines
• Performance measures for cost schedule
• Dated Milestones
• Staff roles

75
Plan Checklist (Continued)

• Key risks, assumptions constraints
• Supporting project documentation - requirements,
  quality, design, management, etc.
• Network Diagrams
• Schedule driven (MS Project) Gantt Charts
• Contingency plans
• Open items issues list
• Other??

76
PMBOK Planning Facilitating Processes
77
Quality Planning
78
8.1 Quality Planning

• .1 Inputs
• .1 Quality policy
• .2 Scope statement
• .3 Product description
• .4 Standards regulations
• .5 Other process outputs
• .2 Tools Techniques
• .1 Benefit/cost analysis
• .2 Benchmarking
• .3 Flowcharting
• .4 Design of experiments
• .5 Cost of quality

Check your PMBOK Section 8 pages 97-101 for more
information related to this section
79
8.1 Quality Planning (Continued)

• .3 Outputs
• .1 Quality management plan
• .2 Operational definitions
• .3 Checklists
• .4 Inputs to other processes

Check your PMBOK Section 8 pages 97-101 for more
information related to this section
80
Quality Planning

• What if analysis - Cause affect Ishikawa or
  fishbone diagrams
• Design of experiments - What happens with
  different skill-set mixtures
• Benchmarking - Comparing proposed actions to
  other projects successful or not
• Cost/Benefit analysis - Quality costs

81
Quality Planning Results

• Quality Management Plans
• Operational Definitions document - Metrics
• Checklists
• Planning
• Design
• Construction
• Test
• Production

82
Staffing
83
9.1 Organizational Planning

• .1 Inputs
• .1 Project interfaces
• .2 Staffing requirements
• .3 Constraints
• .2 Tools Techniques
• .1 Templates
• .2 Human resource practices
• .3 Organizational theory
• .4 Stakeholder analysis
• .3 Outputs
• .1 Role responsibility assignments
• .2 Staffing management plan
• .3 Organization chart
• .4 Supporting detail

Check your PMBOK Section 9 pages 108-112 for more
information related to this section
84
9.2 Staff Acquisition

• .1 Inputs
• .1 Staffing management plan
• .2 Staffing pool description
• .3 Recruitment practices
• .2 Tools Techniques
• .1 Negotiations
• .2 Pre-assignment
• .3 Procurement
• .3 Outputs
• .1 Project staff assigned
• .2 Project team directory

Check your PMBOK Section 9 pages 112-114 for more
information related to this section
85
Planning Acquisition

• Project requirements determine staff needs
• Negotiate user staff participation commitments
• Organize roles responsibilities
• Develop a staffing management plan if appropriate
  (usually reserved for larger projects)

86
Responsibility Matrix
Person
A
B
C
D
E
F
...
Phase
S
A
A
Initiation
Planning Design
P I
I
S
P
A
Construction Test
R
I
S
S
P
A
Completion Deployment
R
S
P
R
P Participant, A- Authorizes, R Reviews, I -
Inputs, S - Signs
Remember Paris
87
Another RR Matrix
88
Communications
89
10.1 Communications Planning

• .1 Inputs
• .1 Communications requirements
• .2 Communications technology
• .3 Constraints
• .4 Assumptions
• .2 Tools Techniques
• .1 Stakeholder analysis
• .3 Outputs
• .1 Communications management plan

Check your PMBOK Section 10 pages 119-121 for
more information related to this section
90
Communications Planning

• Determine the information communication needs
  of the project team customer
• This includes the information type or content,
  its format, level of detail, frequency
• The communications plan must track to project
  roles responsibilities
• Good communications is expectation risk
  management in practice

91
Communications Plan Components

• Spells out how the project plan milestones are to
  be used as a communication device
• Explains the requirements for reporting to be
  placed upon the project team
• Describes communication distribution paths
• Describes the requirements for project
  communication data archive storage

92
Risk Management Planning
93
11.1 Risk Management Planning

• .1 Inputs
• .1 Project charter
• .2 Organizations risk management policies
• .3 Defined roles responsibilities
• .4 Stakeholder risk tolerances
• .5 Template for the organizations risk
• .6 Work breakdown structure (WBS)
• .2 Tools Techniques
• .1 Planning meetings
• .3 Outputs
• .1 Risk management plan

Check your PMBOK Section 11 pages 129-130 for
more information related to this section
94
11.2 Risk Identification

• .1 Inputs
• .1 Risk management plan
• .2 Project planning outputs
• .3 Risk categories
• .4 Historical information
• .2 Tools Techniques
• .1 Documentation reviews
• .2 Information-gathering techniques
• .3 Checklists
• .4 Assumptions analysis
• .5 Diagramming techniques
• .3 Outputs
• .1 Risks
• .2 Triggers
• .3 Inputs to other processes

Check your PMBOK Section 11 pages 131-133 for
more information related to this section
95
11.3 Qualitative Risk Analysis

• .1 Inputs
• .1 Risk management plan
• .2 Identified risks
• .3 Project status
• .4 Project type
• .5 Data precision
• .6 Scales of probability impact
• .7 Assumptions

Check your PMBOK Section 11 pages 133-137 for
more information related to this section
96
11.3 Qualitative Risk Analysis (Continued)

• .2 Tools Techniques
• .1 Risk probability impact
• .2 Probability/impact risk rating matrix
• .3 Project assumptions testing
• .4 Data precision ranking
• .3 Outputs
• .1 Overall risk ranking for the project
• .2 List of prioritized risks
• .3 List of risks for additional analysis
  management
• .4 Trends in qualitative risk analysis results

Check your PMBOK Section 11 pages 133-137 for
more information related to this section
97
11.4 Quantitative Risk Analysis

• .1 Inputs
• .1 Risk management plan
• .2 Identified risks
• .3 List of prioritized risks
• .4 List of risks for additional analysis
• management
• .5 Historical Information
• .6 Expert judgment
• .7 Other planning outputs

Check your PMBOK Section 11 pages 137-139 for
more information related to this section
98
11.4 Quantitative Risk Analysis (Continued)

• .2 Tools Techniques
• .1 Interviewing
• .2 Sensitivity analysis
• .3 Decision tree analysis
• .4 Simulation
• .3 Outputs
• .1 Prioritized list of quantified risks
• .2 Probabilistic analysis of the project
• .3 Probability of achieving the cost time
  objectives
• .4 Trends in quantitative risk analysis results

Check your PMBOK Section 11 pages 137-139 for
more information related to this section
99
11.5 Risk Response Planning

• .1 Inputs
• .1 Risk management plan
• .2 List of prioritized risks
• .3 Risk ranking of the project
• .4 Prioritized list of quantified risks
• .5 Probabilistic analysis of the project
• .6 Probability of achieving
• the cost time objectives
• .7 List of potential responses
• .8 Risk thresholds
• .9. Risk owners
• .10 Common risk causes
• .11 Trends in QQ risks analysis results

Check your PMBOK Section 11 pages 140-144 for
more information related to this section
100
11.5 Risk Response Planning (Continued)

• .2 Tools Techniques
• .1 Avoidance
• .2 Transference
• .3 Mitigation
• .4 Acceptance
• .3 Outputs
• .1 Risk response plan
• .2 Residual risks
• .3 Secondary risks
• .4 Contractual agreements
• .5 Contingency reserve amount needed
• .6 Inputs to other processes
• .7 Inputs into a revised project plan

Check your PMBOK Section 11 pages 140-144 for
more information related to this section
101
What Risk?

• Risk is A discrete occurrence that may affect
  the project for good or bad.
• Superior Risk Management can reduce project
  problems by as much as 90
• Risk assessment is not a one-time event, it is
  constant throughout the project
• Sources of risk can be both internal external
  in nature

102
Risk Management Process

• Risk Management Planning
• Risk Identification
• Qualitative Risk Analysis
• Quantitative Risk Analysis
• Risk Response Planning
• Risk Monitoring Control
• Note We will deal with risk control in the PMBOK
  Controlling Facilitating Processes section

103
Risk Management Planning

• Determine how to approach manage risk
• Define roles responsibilities based upon
  organizational stakeholder tolerances
• Conduct meetings to determine risk thresholds
• Determine the risk management processes,
  reporting requirements, tools to be used

104
Risk Identification

• First determine what risks are most likely given
  historical information, scope of work, project
  timelines, technical challenges other
  constraints
• Risks can be classified as
• Business Good or loss
• Pure - Loss

105
Risk Identification (Cont.)

• Risk factors Examine probability, outcome
  ranges, possible timings, frequency
• Risk symptoms What are the early warning signs
  - Triggers
• Risk tolerances What amount of risk is
  acceptable

106
Qualitative Quantitative Analysis

• Basically what risks require a response
• Two methods of determining probability amount
  at stake
• Qualitative high, medium, low probability
• Quantitative calculated cost impact
• Monte Carlo Simulation Can determine
  probability of task completion range

107
Qualitative Quantitative Analysis (Cont.)

• Expected Value Probability Impact
• What is the expected value of the tasks below

Task
Probability
Impact (Amount at Stake)
Expected value
A
10
20,000
2,000
B
30
45,000
13,500
Management reserve for the 2 tasks should be
15,500
108
Qualitative Quantitative Analysis (Continued)

• Decision Tree Mutually exclusive paths
• What is the expected value of line X below

A1 Prob 20, impact 30,000
A Prob 35, impact 120,000
X
A
Outcomes
Decision
B
Answer 48,000 A42,000 A16,000
109
Qualitative Quantitative Analysis (Continued)

• Based upon risk analysis youll know
• Opportunities to pursue
• Opportunities to ignore
• Threats to respond to
• Threats to ignore

110
Risk Response Planning

• What are we going to do about the risk?
• Three alternatives or risk mitigation strategies
• Avoidance
• Mitigation
• Acceptance
• Get insurance
• Contract out work

111
Risk Response Planning (Continued)

• Contingency Planning
• Based upon risks you should have
• Management reserves
• A Risk Management Plan
• What is the most important item to address in
  every team meeting - Risk

112
Risk Monitoring Control

• Management tracking of risk issues
• Monitoring how the evolving project environment
  affects existing or creates new risks
• Perform risk reviews
• Perform risk response audits (measure document
  the effectiveness of avoiding risk)

113
Risk Monitoring Control (Continued)

• When a project is in its earliest phases risk
  opportunity are highest impact at its lowest
• Be aware when
• Future timings of events or activities is vague
• A wide variation in estimates exists
• Appropriate contingency plans do not exist
• Many alternatives are deemed possible

114
Procurement Management
115
12.1 Procurement Planning
Check your PMBOK Section 12 pages 149-152 for
more information related to this section

• .1 Inputs
• .1 Scope statement
• .2 Product description
• .3 Procurement resources
• .4 Market conditions
• .5 Other planning outputs
• .6 Constraints
• .7 Assumptions

116
12.1 Procurement Planning (Continued)

• .2 Tools Techniques
• .1 Make-or-buy analysis
• .2 Expert judgment
• .3 Contract type selection
• .3 Outputs
• .1 Procurement management plan
• .2 Statement(s) of work

Check your PMBOK Section 12 pages 149-152 for
more information related to this section
117
12.2 Solicitation Planning

• .1 Inputs
• .1 Procurement management plan
• .2 Statement(s) of work
• .3 Other planning outputs
• .2 Tools Techniques
• .1 Standard forms
• .2 Expert judgment
• .3 Outputs
• .1 Procurement documents
• .2 Evaluation criteria
• .3 Statement of work updates

Check your PMBOK Section 12 pages 152-153 for
more information related to this section
118
Procurement Management

• Project management includes the processes
  required to acquire goods services from outside
  the performing organization
• A legal contract must be
• An offer
• Acceptance
• Consideration
• Legal capacity (parties) purpose (no illegal
  goods)

119
Things To Remember

• A contract is a formal agreement
• All requirements should be in or referenced by
  the contract
• All contract requirements must be met or waived
• Any changes should be in writing formally
  controlled
• Contracts are backed by a court system
• PMs should understand the contract prior
  issuance

120
Procurement Management Process

• Procurement Planning - Make or buy
• Solicitation Planning - RFP
• Solicitation Ask Answer questions
• Source Selection - Pick solution
• Contract Administration - Administer
• Contract Closeout - Finish

121
Contract Types

• This is important because a contract is a risk
  mitigation tool
• Contract types are
• CR - Cost Reimbursable
• FP - Fixed Price
• TM - Time Material

122
Cost Reimbursable

• Buyer bears the risk of cost overruns
• Form 1 - Cost Plus Fixed Fee (CPFF)
• Contract compensation plus a fee of 10,000
• Form 2 - Cost Plus Percentage of Cost (CPPC)
• Contract compensation plus 10 of costs as fee
• Form 3 - Cost Plus Incentive Fee (CPIF)
• Contract compensation plus 10,000 for every
  month the project is completed sooner than agreed
  upon

123
Fixed Price

• Seller bears the risk of cost overruns
• It is the most common type of contract sometimes
  called Lump Sum or Firm Fixed Price
• Form 1 - Fixed Price FP
• Contract compensation equals 100,000
• Form 2 - Fixed Price Incentive Fee (CPIF)
• Contract compensation equals 100,000. For every
  month the project is completed early you receive
  10,000

124
Time Material PO

• Used for smaller dollar amounts
• Form - Time Material TM
• Contract compensation equals 100 per hour plus
  materials at cost
• Purchase Orders (POs) are a contract form used
  to procure commodities
• Contract to purchase 30 CPUs at 1,200 per unit

125
Statements of Work

• Are elements of the contract that specify the
  types of work to be completed under the terms of
  the contract
• They can address performance, functionality
  design
• SOWs can include drawings, specifications,
  technical descriptive wordings

126
Procurement Documents

• Request For Proposal (RFP) - Requests a detailed
  proposal on how the work will be accomplished
• Invitation For Bid (IFB) - Request one price to
  do all the work
• Request For Quotation/Information (RFQ/RFI) -
  Requests a price quote per item, hour, etc.

127
Bidders Conference

• Formal question answer session to clarify
  issues or requirements
• Formal changes to procurement documents
• Can be used for vendor demo shoot-outs
• Often used by vendors as a fishing exhibition to
  see who the competition is what their issues are

128
Proposal Evaluation Criteria

• Contractual compliance
• Understanding of requirements
• Overall or life cycle costs
• Technical ability approach
• Management resource approach
• Organizational financial health
• Qualified Sellers Lists

129
Source Selection

• Selection short-listing processes use one or more
  of the following
• Weighting system - Grading against set criteria
• Screening system - Meet a minimum standard
• Independent estimate - Cost compare to estimate
• Past performance history - Reputation record

130
Negotiation

• Objective of negotiations
• Obtain a fair reasonable price
• Develop a good working relationship
• If a win-win is not achieved, the vendor (or you)
  will be looking for opportunities to get well
  later at the projects expense
• PMs should be involved in negotiations to
  protect working relationship

131
Pre-Negotiation Rules

• Know what you want to buy
• Determine real urgency of requirement
• Develop strategies tactics in detail
• Research your opponent
• Develop a contingency plan
• Determine team or individual approach
• Set min/max negotiation objectives limits

132
Pre-Negotiation Rules (Continued)

• Identify give take points
• Understand the limits of your authority
• Know your strengths weaknesses
• Ensure your team is properly trained
  understands their respective roles
• Run practice scenarios to determine tactics

133
Negotiation Rules

• Establish a common starting point
• Observe proper business protocol
• Establish rules for appeal or impasse settlement
• Do not make the first major concession
• Use team members skillfully
• Dont be afraid to say no

134
Negotiation Rules (Continued)

• Always keep your main objective in sight
• Be willing to change tactics strategy
• Be willing to compromise
• Be calm, poised, patient
• Permit your opponent to save face
• Allow each party to claim a win

135
Negotiation Rules (Continued)

• Negotiate a deal fair to both parties
• Obtain written concurrence at the end of each
  session
• Use surprise as required
• Be willing to pass on a bad deal regardless of
  the pressure
• Be confident

136
Post-Negotiation Rules

• Reduce the total agreement to writing promptly
• Avoid disparaging remarks relative to your
  opponents negotiation skill
• Dont discuss negotiation results with opponent
• If required make agreement public
• Conduct a self-critique of results
• Obtain maintain project execution feedback

137
Questions For Vendors

• Identify the top 10 risk items, their probability
  of occurrence, triggering events, their impacts
  associated recovery plan
• Describe their risk management techniques to
  mitigate negative impact to the project
• From the risk list what items are not under
  vendor control why

138
Questions For Vendors (Continued)

• Describe the mechanisms timeliness that they
  will use to report potential problems
• What will the vendor do to control project
  requirements, their growth, stability
• What is the vendor approach to ensure that
  requirements are complete, consistent, correct
  - what tools processes do they use

139
Questions For Vendors (Continued)

• How will they address requirement defects
• What is the smallest code component of source
  code for which all code components will have
  system requirements traced
• How will system requirements be traced to all
  individual test cases

140
Questions For Vendors (Continued)

• Describe how interfaces will be managed
• At what point in the development will all user
  interfaces be designed
• Describe the processes used in cost, resource,
  schedule estimating
• What level of uncertainty is assumed in planning
• What of total cost is allocated to WBS level 3
  tasks or lower

141
Questions For Vendors (Continued)

• Does the Network Diagram track areas not under
  vendor control? How will they track the status
  of external dependencies if theyre not on the
  diagram
• Which leaf task (task with no child) has the
  highest budgeted cost
• Are named resources within tasks committed for
  the duration of their project assignments

142
Questions For Vendors (Continued)

• What of proposed tasks are on the critical path
• What percentage of proposed tasks not on the
  critical path have a slack period of less than 5
  days
• Relate how critical path task interface with your
  risk management plan
• How is proper task exit criteria ensured
  throughout the project

143
Questions For Vendors (Continued)

• Identify describe the development life cycle
  model that will be used the rationale for it
• Describe the approach to discovering early
  indications of cost schedule problems
• Describe how the vendor will compute report
  project earned value the steps to ensure its
  accuracy

144
Questions For Vendors (Continued)

• Identify describe the management metrics they
  will collect report on as well as rationale
• What metric will the vendor use to measure
  report client productivity
• What software development productivity metric was
  used to estimate the cost of developing this
  project software

145
Questions For Vendors (Continued)

• Explain the approach for transitioning software
  from development to operations without disrupting
  business operations
• Describe the vendors concept for post-deployment
  software support
• Since maintenance costs increase with the density
  of defects what are the vendors delivered defect
  density goals - How will they achieve this goal

146
Questions For Vendors (Continued)

• Does the vendor plan to reuse functionality or
  source code from other systems
• What is the vendors software size estimate for
  this project - How was the estimate developed
• What cost models were used in the cost estimate
• How will vendors track defects through
  resolution
• Describe the various levels of the vendors test
  program

147
Questions For Vendors (Continued)

• How will product stability reliability be
  demonstrated validated
• Describe the process of ensuring products meet
  development standards guidelines
• Describe the data conversion approach to be used
• Who owns change configuration management how
  is it handled

148
Questions For Vendors (Continued)

• How will the vendor decide whether or not delays
  or other problems are beyond their control
  responsibility
• What criteria will they use to determine whether
  a change of scope requires change orders or
  contract modifications
• What is the project contract escalation process
  
• Whats your favorite color - just checking

149
Planning Process Summary
150
Planning Process Summary

• Level-set expectations commitments with a
  project kickoff meeting
• Establish the proper scope with complete
  accurate requirements
• Determine the project activities their
  sequences
• Define WBS products associated with activities
  work packages

151
Planning Process Summary (Continued)

• A properly leveled estimated WBS is the key
  project management tool
• Capture WBS in project management system (MS
  Project or other)
• Create a detailed WBS dictionary
• Understand estimating methods PERT, CPM, PDM
  Monte Carlo

152
Planning Process Summary (Continued)

• Build a network diagram to understand task
  dependencies
• Be able to determine critical paths
• Know how to estimate budget costs
• Understand what goes into a project plan
• Determine project quality metrics
• Define staff roles responsibilities

153
Planning Process Summary (Continued)

• Publish a clear communications plan
• Determine, quantify, mitigate risk
• Understand different contracting types
• Use clear evaluation criteria
• Ask good questions, be a sophisticated buyer
• Negotiate a win-win solution
• Document, document, document

154
Lets look at a real world example

• Integrated Tax System RFP

155
Supporting Planning Resources

• PMM Chapters
• Montana_PMM_Overview_01
• Montana_PMM_Planning_01
• Montana_PMM_Appendices_01
• PMM Appendices
• Appendix A Project Management Methodology
  Glossary
• Appendix B Project Management Methodology
  Templates
• Appendix C Capability Maturity Model
• Appendix E Books, Publications, Periodicals
  Resource and Reference List

156
Supporting Planning Resources (Continued)

• PMM Templates
• PMM01_Feasibility_Document_01
• PMM02_Concept_Document_01
• PMM03_Project_Charter_01
• PMM04_Project _Plan_Document_01
• PMM05_Scope_Statement_01
• PMM06_Critical_Success_Factors_01
• PMM07_Work_Breakdown_Structure_01
• PMM08_Cost_Benefit_Analysis_01

157
Supporting Planning Resources (Continued)

• PMM Templates
• PMM09_Resource_Plan_01
• PMM10_Risk_Management_Plan_01
• PMM11_Procurement_Plan_01
• PMM12_Quality_Plan_01
• PMM13_Communications_Plan_01
• PMM14_Configuration_Management_Plan_01
• PMM15_Project_Budget_Estimate_01
• PMM16_IVV_Plan_01

158
Supporting Planning Resources (Continued)

• PMM Templates
• PMM17_Business_Case_Document_01
• PMM18_Project_Status_Report_01
• PMM19_Change_Control_Request_01
• PMM20_Issue_Document_01
• PMM22_Active_Project_Transition_Document_01
• PMM23_IVV_Report_01
• PMM24_Service_Level_Agreement_01
• PMM26_SOW_Template_01
• PMM27_Contractor_Assessment_Form_01

159
Supporting Planning Resources (Continued)

• SDLC Chapters
• 2-SDLC_Model_01
• 4-Introduction_01
• 5-Lifecycle_Model_01
• 7-Planning_Phase_01
• 8-Requirements_Definition_01
• 9-Functional_Design_01
• 10-System_Design_01
• 11-Programming_Phase_01
• 12-Integration__Testing_01
• 16-Records_Management_01

160
Supporting Planning Resources (Continued)

• SDLC Appendices
• A-Glossary
• B-Abbreviations
• D-In Phase Assessment
• E-Phase Exit
• F-Exhibits
• G-Web Development Method Guide
• H-CMM
• I-COTS

161
Supporting Planning Resources (Continued)

• SDLC Appendices
• J-Documentation Standards
• L-Large Projects Guide
• M-Medium Projects Guide
• N-Small Projects Guide
• O-Static Web Pages
• P-Bibliography

162
Supporting Planning Resources (Continued)

• SDLC Templates
• SDLC02_Requirements_Specification_01
• SDLC03_System_Design_Plan_01
• SDLC04_Functional_Design_Plan_01
• SDLC05_Project_Test_Plan_01
• SDLC06_Conversion_Plan_01
• SDLC07_Acceptance_Test_Plan_01
• SDLC08_Transition_Plan_01

163
Supporting Planning Resources (Continued)

• Tools
• Tool04_Requirements_Management_Checklist_01
• Tool05_Software_Configuration_Management
  Checklist_01
• Tool06_Software_Design_Checklist_01
• Tool07_Software_Maintenance_Checklist_01
• Tool08_Software_Testing_Checklist_01
• Tool09_Software_Quality_Assurance_Checklist_01
• Tool12_Project_Planning_Checklist_01

164
Supporting Planning Resources (Continued)

• Tools
• Tool13_Project_Planning_Questions_01
• Tool14_Project_Assessment_Matrix_01
• Tool16_Project_Estimator_01
• Tool17_Requirements_Traceability_Matrix_01
• Tool18_CARA_Risk_01
• Tool19_Project_Risk_Assessment_01
• Tool20_Project_Priority_01

165
Supporting Planning Resources (Continued)

• Tools
• Tool21_RITE_ROI_1.7
• Tool24_Project_Planning_Transition_Checklist_01
• Tool25_Due_Diligence_Checklist_01
• Tool27_RFP_Checklist_01
• Tool28_Writing_Tips_01
• Tool29_Risk_Calculator_01