Essential Skills of Successful Project Management

1
Essential Skills of Successful Project Management

• Robert Barnes, PMP
• March 2009

2
Course Objectives

• To equip students with the right blend of
  practical project management skills to
  successfully lead and manage projects.
• Project Management tools and skills
• Choosing and applying appropriate tools and
  methodologies
• Project Team Leadership

3
Course Outline

• 5 Introduction
• 11 Project Initiation
• 43 Project Planning
• 53 Communication Management
• 58 Scope Management What?
• 79 Time Management When?
• 120 Cost Management How Much
• 128 Risk Management
• 144 HR Management Leading Effective Project
  Teams
• 152 Quality Management (64)
• 164 Project Completion

4
Housekeeping

• Timetable
• Breaks
• Toilets
• Stupid questions
• Introductions

5
Introduction

• What is a project?
• Temporary, Unique
• Has Start, Finish
• Expected Outcomes (Deliverables)
• Resources, Budget (time, )

6
Projects and Processes
Programmes
Processes
Projects

• Discuss
• Find examples of Projects, of Processes
• What is a Programme
• Compare Project Management and Process Management
• What is different about Project Management?

7
The Project Life Cycle
Intermediate Phase (s)
Cost Staff Level
Final Phase
Initial Phase
Time
8
Why Project Management

• Project Management is different to line (Process)
  management
• A bad project can even destroy a company or a
  country
• Airbus A380?
• Invade Russia (WW2)
• Smaller-scale disasters can often be hidden
• But they are still not career enhancing!
• All organizations do projects
• Not just Fletcher Construction etc
• So wed better be good at it!

9
Project Management is

• PMBOK the application of knowledge, skills,
  tools, and techniques to project activities to
  meet project requirements
• Jain The art and science of converting vision
  into reality

10
The 6 Phases of a Project

• Initial Enthusiasm
• Early Disillusionment
• Onset of Panic
• Search for someone to blame
• Punishment of the appointed scapegoat
• Promotion of the non-involved

11
Getting the result that we want
As proposed by the Project Sponsor
As Specified in the Project Request
As Designed by the Systems Analyst
As produced by the Programmers
As Installed at the Users Site
What the User Really Wanted!
12
Project Processes
Planning
Initiating
Controlling
Executing
Closing
PMBOK, Fig 3-1 (Project Management Institute,
www.pmi.org)
13
Overlap of Process Groups
What about multi-phase Projects?
Executing
Planning
Closing
Initiation
Controlling
14
Project Initiation
15
The Initiation Process
Business Case
Project Charter
Sponsor
Project Manager
Steering Committee
Champion
Project Team
16
Project Initiation
What do we want to Achieve?

• Objective - get approval to proceed
• to next stage?
• Identify and Enrol Stakeholders
• Top level commitment
• Peer-level support
• Authority over resources
• Organisational priorities
• Mission/vision Alignment
• Financial commitment

What does it take?
17
Project objectives

• Understanding objectives
• see Amys Need.doc
• Discussion
• What were Amys real needs?
• What are the consequences of getting this wrong?

18
Requirements and Solutions
19
Project Initiation Involves

• Gathering Information
• Define Scope - WHAT
• Understand Rationale for Project - WHY
• Identifying Business need(s) to be satisfied -
  Criteria for Success
• What can go wrong - Risk Assessment
• High Level Budget - How Much (time, )
• Formally qualify Project - Priority

20
The Business Case(Project Proposal)

• MUST Include
• What? (deliverables)
• Why? (objectives)
• General, and
• Specific ()
• How much? ()
• Budget
• When?

• MAY include
• Background
• Alternatives
• Initial (high level) Project Plan
• Review points

Buscase Proforma.DOC
21
How Detailed Should theProposal Be?

• How detailed are the examples you found?
• Too little, or too much detail?
• We usually go overboard, providing far too much
  detail, in a mistaken belief that this reduces
  project risk. After all -.
• Construction is much more successful than IT at
  project management.
• This is how construction does it, so we should
  too.
• But applying construction thinking to an IT
  project can be a recipe for disaster!

22
So why do we make this mistake?

• Management say they want Certainty
• What ? (youd better not be wrong,
• What time? or heads might roll!)
• Is this what they really want?
• (discussion)
• Imagine weve just been given PM responsibility
• Whats uppermost in our mind?
• How do we react to their need for certainty?

23
Back to Project Initiation

• Remember, the objective of the Initiation process
  is NOT to plan the whole project
• It is to set up the project to succeed
• Set clear stakeholder expectations
• Enlist (enrol) support
• Informal messages from Initiation
• Are you being set up to fail?
• Hidden or conflicting objectives, secret agendas,
  company politics
• Which methodology is best for this project
• How certain are you that you know everything you
  need to know?

24
The Initiation Process(again)
Business Case
Project Charter
Project Manager
Sponsor
Champion
Project Team
25
The Business Case(reminder)

• MUST Include
• What? (deliverables)
• Why? (objectives)
• General, and
• Specific ()
• How much? ()
• Budget
• When?

• MAY include
• Background
• Alternatives
• Initial (high level) Project Plan
• Major review points

Buscase Proforma.DOC
26
Justifying Projects

• When do we need to justify a project?
• When is it unnecessary
• How to justify a project
• Tangible cost-benefit
• Intangible benefits
• Strategic benefits

27
Strategic Projects

• Just do it Business imperative
• Discussion 1 find examples
• Discussion 2 how does this change the
  initiation process/documentation

28
Basic Cost/Benefit Analysis

• Improve efficiency of Business
• Decrease Costs
• Increase Revenue
• gt increased NET revenue
• Cost savings
• Fewer Staff
• Less material waste
• Reduced inventory
• gt reduced holding costs
• Revenue Increases
• More throughput with same resource

29
Common Measures of Benefit

• Simple ROI
• Discounted Rate of Return (IRR)
• Net Present Value
• Most valid (accounting)
• Profitability Index
• Payback Period
• Very simple

30
Calculation of ROI etc
Issue What about Risk?
31
Exercise presenting budgets

• Individual sketch out solution to Scenario 1
• Class Develop spreadsheet to solve scenario 1
• Scenario 2
• Scenario 3
• Discussion how do you present all of this?

Problem 1.doc
32
Contingency

• How much (if any) contingency should you allow?
• Should you hide it within task estimates, or show
  it explicitly?
• Types of Contingency
• Project reserve - can be spent by PM
• Covers estimation error
• Management reserve held by steering committee
• Used for scope enhancements
• PMBOK hints at 15 each.
• But it varies by project type

33
The domain of Basic ROI
Strategic Systems
The domain of Basic ROI Calculations
Value
Information Systems
Operational Systems
Time
34
Intangible Factors

• Tangible factors cost savings, increased income
  can be estimated, put into spreadsheets, and
  measured during and after the project to see how
  were doing.
• For this reason, a business case often seems to
  be about the spreadsheet!
• Yet concentration on tangible factors may
  completely miss the point!
• Intangible factors may be MUCH more important!

35
Intangible Factors - 2

• Definitions -
• Something that cant easily be calculated in
• Something that is strategically important
• Some examples of intangible factors
• Higher quality
• Better service
• Increased customer satisfaction
• Increased staff satisfaction
• Improved safety

36
How do we handle intangible factors in the
business case?

• Usually we try to convert them to
• Sales will be increased by 10
• This may be bt
• Figures plucked out of the air, not solid. What
  evidence is there that sales will in fact be
  increased by 10
• Valid when theres good data, and we can convert
  the benefit to
• New road will reduce average commuting time by 5
  minutes. Whats this worth?
• New drug reduces the risk of heart attacks by
  10. Whats this worth?
• That still leaves a residue of intangible factors
  that we cant handle.
• A possible model for IT projects

37
Information EngineeringScorecard

• A formal way of rating intangible factors in IT
  projects
• Headings not really important - key thing is the
  attempt to be systematic about benefits that are
  difficult to quantify
• Need to develop alternative headings for other
  project types.
• Not useful for one-off projects, but useful in
  deciding relative priorities among competing
  projects

IE Scorecard.doc
Parker and Benson Information Engineering
Economics. Prentice Hall, 1988
38
Classes of Value

• Return on Investment
• Classical C-B analysis
• Strategic Match
• Competitive Advantage
• Management Information
• Competitive Response
• Strategic IS Architecture

39
Business Domain Values and Risks
40
Technology DomainValues and Risks
41
gt IE Scorecard

• Gives rating for project an Information
  Economics Score
• Parker Benson have a way of loading the
  individual values to arrive at a single number
• Honestly? OTT, but a useful checklist

42
The Project Charter
Business Case
Project Charter
Project Manager
Sponsor
Champion
Project Team
43
Charter functions

• Define responsiblities and authorities
• Sponsors
• Project Manager
• Project Team
• Typically very brief will refer to the business
  case/proposal
• Discussion what (if any) is the value of this?

Charter.doc
44
The Specification (SoW)

• Defines
• What you are going to do
• What it will cost
• May be
• Part of the business proposal
• Part of the charter
• A separate document
• Needs to be appropriately formal
• Is the most important part of the initiation
  document set.

SOW Statement of Work Scope of Work
45
Initiation

• (Discussion)
• Question 1 of the Course Preparation deals with
  project initiation.
• How did your example compare with this?
• What are the reasons for the differences (if any)

46
PM Process Groups (again)
47
Project Planning
48
Planning failures

• Failure to plan
• Failure to plan in sufficient detail
• Failure to know when to stop planning
• Failure to involve task performers in planning
• Failure to reflect risk and uncertainty in plans
• Failure to keep the plan current

49
Project control and monitoring is -

• Monitoring and reporting progress against the
  plan ( budget schedule).
• The SCs role is to approve changes to the plan!
• So youd better have a plan!
• Actually youll already have a plan that you
  developed in the initiation phase
• But it may not be detailed enough
• Detailed Planning -

50
Planning Processes - Core Processes
Activity Sequencing
Scope Planning
Schedule Development
Activity Definition
Activity Duration Estimation
Scope Definition
Cost Budgeting
Resource Planning
Cost Estimation
Project Plan Development
This is too one-way (construction?). In my
experience, much more iteration is needed within
an IT project!
51
Activity Definition Work Breakdown Structure
(WBS)
Build House
Electrical
Builder
Framing
Gib
Wiring
Plugs

• Breaks work into smaller chunks, by area
  usually topic or responsibility.
• Not strictly sequenced left-to-right
• Does not include precedence relationships

52
Work Breakdown Structure

• How fine?
• Too much detail
• always planning, never doing
• Not enough
• Plans worthless
• Part of creating Gantt with MS project?
• Or separate?

S.M.A.R.T.
53
Integration Management Work Sequencing
Build House
Electrical
Builder
Framing
Gib
Wiring
Plugs

• Task Completed sign-off
• What level of formality do you need?

54
Gantt Charts

• Probably the most important Project
  Planning/management Tool
• Early stages - graph paper
• Later - software (MS-Project?)
• Shows Task schedule and relationships
• Task relationships (although not the best diagram
  for this)
• Task Start, Finish schedules
• May show resource assignments

55
WBS or Gantt (with MS-Project)?

• WBS focusses on work breakdown and task
  responsibilities
• Gantt also introduces schedule
• But this can be misleading in early stage
• WBS can be a lot of work
• Less software support
• Relationships not so obvious
• gt Personally I use MS project from the start,
  and go straight to a Gantt
• Demo create equivalent of WBS

56
The Project Plan

• There is usually a formal document, the Project
  Plan, produced as output of the planning phase
• It includes (by reference/copy) everything
  previous
• Proposal, Charter, Specification
• Plus outputs of planning phase
• Budget
• Schedule
• Risk Register

57
Now, lets get on with it!

• Were now ready to start doing (executing) the
  project
• In theory, we should have completed planning
• In reality, we will already have started
• Keep planning throughout project

58
PM Knowledge Areas

• Communications Management
• Integration Management
• Scope Management
• Time Management
• Cost Management
• Quality Management
• Human Resource Management
• Risk Management
• Procurement Management

• All applicable through Doing phase
• Importance varies
• Type of project
• Phase of project
• A PM does all of these
• Areas overlap, not really distinct
• But a useful way of thinking about what a PM does

PMBOK
59
Communication Management

• Ive put this first to me, Communication is a
  managers most important job
• Grahams law If they know nothing of what
  youre doing, theyll suspect that youre doing
  nothing

Robert J. Graham Understanding Project
Management
60
Communication Management
Regular (monthly?) Steering Committee Meetings
What does she need to know to control the
project?
Regular (weekly?) and ad-hoc Project Meetings
What does the Steering Committee want to know?
61
Communication up

• When are we going to get it?
• Whats it going to cost?
• What are the risks?
• Whats gone wrong?
• Whats gone right?

What does the Steering Committee want to know?
What do you want the Steering Committee to do!
62
Communication up (again)
What does the Steering Committee really want to
know?

• Are you in control?
• No surprises
• What do you want from them?

Review March 8.ppt
63
Communicating upwards

• Its all about confidence
• They dont want to know about the detail
• But they want to know that you know, and are on
  top of any problems
• They dont want to speak Microsoft
• They do want to speak business
• Costs, schedules, risks, business objectives,
  opportunities
• They HATE surprises
• Early warning of issues is GOOD
• Reporting next month that the issues been
  resolved is EVEN BETTER
• Visible buffers are VERY GOOD
• But dont let them take them away before youre
  ready!!!
• Be clear on what you want from them
• If you take them an issue, have at least one
  recommendation on how to deal with it.

See Review March 8.ppt, slide 6
64
Reporting format

• PMs report doesnt have to be a Word document
• PPT sometimes better
• (depends on format of the SC meeting)
• Or Excell
• SC meeting is an important project activity
• Should be formally minuted

Review March 8.ppt
65
Communication Down
What does she need to know to control the
project?

• At task level
• What have we finished?
• What are we working on?
• Whats late?
• What issues do we have?
• Whats gone wrong?
• Whats gone right?
• What are our resources?

Regular (weekly?) and ad-hoc Project Meetings
Ad-hoc Problem Solving Meetings
66
Project Documentation

• Important to be in control
• And to be seen to be in control
• The Project Folder
• Usually both physical folder, and on computer
• Word hyperlink for toc

67
Discussion

• Question 2 of Preparation was about upward (
  outward) communication
• How did your example compare with this?
• What are the reasons for the differences (if any)

68
Scope Management What

• What do you mean you wanted a door? Its not in
  the contract!

69
The Construction Approach

• Specify EXACTLY what were building
• And prepare a detailed contract and plan
• Sign off specification, and dont change anything
  without formal change control
• Which is difficult and expensive
• This works well for construction projects
• In fact, its the only approach that works there
• But will it work for your project?
• (Discussion)

70
We Should Run Our IT Projects Like Construction
Projects

• You often hear this opinion expressed
• Especially when there is another large IT
  failure.
• When none of us knew anything about IT projects,
  the only model for project management was
  engineering/construction
• So early methodologies were based on construction
  and aerospace.

Where Project Managers are King Project
Management Journal, December 2001
Who does it better IT or Construction -
Robert Purcell, PMI NZ Conference 2002.
71
The Waterfall SDLC
Proposal
72
This Works Well for Construction, but -

• There are significant differences between IT and
  constructions situations.
• This can be the WORST way to develop an IT
  system.
• Most large IT project failures have used
  Waterfall (or variants). Example INCIS.
• Key IT/Construction differences(in planning) -.
• Getting it right 1st time (or iterative design).
• Modelling tools and estimation metrics.

Do Construction Methods lead to Rotting
Systems?.ppt Should IT Projects be run like
Construction Projects.doc?
73
The importance of Getting it right first time

• Construction industry
• Strong emphasis on DIFOTIS (Delivery In Full, On
  Time, In Spec)
• later change usually impossible
• (e.g. Meremere Power Station)
• IT
• Strong emphasis on delivering business benefit
• later change often easy.
• Other project types it varies
• But usually have to deal with much less certainty
  than in construction

74
Possibility of Iterative Design

• Can we use the same tools for design and
  building?
• Can we grow a Hut -gt House -gt Hotel?
• Can we grow a Personal System -gt Department
  system -gt Enterprise System
• In IT, iterative design is not only possible,
  its a Best Practice!

?
?
75
Modeling Tools
Do we have an equivalent in your projects?
(What is it? Does it communicate as effectively?)
What is the Design/Build ratio In
construction? In your projects?
76
Estimation Metrics

• Construction
• Good reference data and formulae
• Materials and fixed-price quotes for gt 90 of
  project
• Possible to estimate to within 3 (1/2 for
  house)
• IT
• Nothing comparable
• Major cost labour, hourly rate
• Price/fp varies widely over the project lifetime

77
But We Dont Have to Use WaterfallVarious SDLC
Models

• Waterfall
• Code and Fix
• Prototyping
• RAD
• FDD (feature-driven development)
• Xtreme Programming (XP)

Horses for Courses
Choose a SDLC. PDF (Rapid Development, ch 7.11)
78
Prototyping
Successive refinement - Creates excellent
match between system and requirement
Analyse
Build
Whats the Budget?
When are you finished?
Good for small projects
79
Spiral Methodology?
EVALUATE
IDENTIFY
OPERATIONS PRODUCTION SUPPORT
DEPLOY
UNIT
TEST
EVALUATION
SUBSYSTEM
EVALUATION
SYSTEM
RISK ANALYSIS
BUSINESS
PROOF OF CONCEPT
CONCEPTUAL
1ST BUILD
LOGICAL
2ND BUILD
PHYSICAL
FINAL BUILD
FINAL
DESIGN
CONSTRUCT
80
Rapid Application Development
Grosh?A project which does not deliver a
satisfactory system in six months will NEVER
deliver a satisfactory System

• RAD

Use 4GL, CASE to speed up delivery
81
Version Releases
Plan
Plan
Develop
Develop
Market
Market
Support
Support
82
Conclusions -

• No one answer is always right!
• Vital to have feedback loops
• Need to balance Planning and Doing
• The later you can safely leave a decision, the
  better the decision will be
• Early decisions
• Construction layout, foundations. IT
  architecture
• Late decisions
• Construction furnishings. IT Form and report
  layout

83
Change Management
84
Relative Cost of Change

• Later Change can be MUCH more expensive

Measured cost of correcting errors discovered at
various stages of a classical (COBOL, Waterfall)
project
180
160
140
120
100
0
Re
Des
Co
D-
A-
Op
Re
Des
Co
D-
A-
Op
Proposal
Analysis
Design
Coding
Module testing
System testing
t
t
ion
t
t
ion
85
So how should we react?

• Get everything specified up front, and stick to
  it?
• Or
• Specify as loosely as possible?

86
The correct answer - neither

• Not all changes are equal
• The later we can leave a decision, the more
  likely we are to make the correct one
• Specify the fundamental things early
• Eg architecture, high-level object design,
  standards
• Do proof-of-concept implementation to explore
  areas of uncertainty
• Leave details to later (dont sweat the small
  stuff)
• But whats a detail?

87
Change requests

• Assess impact
• 0 or trivial, local impact handle within team
• Has cost or schedule implications, or global
  scope change consider at Steering Committee
• Steering committee
• Accept/reject/refer to sponsor.
• Increase budget for accepted changes
• Contingency reserve
• Go to sponsor for more budget/time

88
Discussion

• Question 6 of Preparation was about change
  management
• How formally is this handled within your project?
• Do you think too much, or too little, gets
  referred up?

89
Review of Day 1

• What is a project
• Project lt-gt Process mgmt. Programmes.
• Initiation
• Importance. Purpose.
• Key outputs (deliverables)
• Justifying projects. Cost/benefit. Intangible
  factors
• Budgets, Contingency.
• Planning
• WBS, Gantt chart. The Project Plan

90
Review of Day 1 (2)

• Communication Management
• Up. The Steering Committee
• What do you tell them?
• What do you want from them?
• Down. The Project team
• What do you want to know?
• Scope Management (What)
• How much detail?
• Change management
• Relative cost of change
• How do we respond?
• Change Requests

91
Time Management When?Setting and Maintaining
the Schedule
92
Time Management Tools

• Precedence Diagram
• Gantt Chart

B(5)
C(10)
H(8)
I(5)
A(2)
E(5)
D(3)
G(4)
F(3)
93
Task Relationships - Precedence and the Critical
Path

• Exercise - Plant Start-up Project
• 1/ Draw a Precedence Diagram
• 2/ Identify the Critical Path
• 3/ Calculate the shortest duration

StartupExercise.doc
94
Issues

• Do we have all the tasks?
• Are our estimates correct?
• What is the uncertainty in our estimates?
• Have we missed any important relationships?
• Are the relationships correct?
• (Do we have to finish X or just do enough to
  allow Y to start?)
• Well just park these for now, and come back to
  them later

95
The Critical Path
Critical Path - longest dependent path A -gt B
-gt D Assumes flexible resource, as much as we
want
B
A
D
C
Available Manpower
96
The Critical Chain - a levelled CP
Critical Chain - takes into account resource
limits Either A -gt B -gt C-gt D or A -gt
C -gt B -gt D
B(3)
A(2)
D(2)
C(2)
Available Manpower - or other limiting resource
97
Resource-constrained projects

• May not need any of the preceding complexity
• Just a list of tasks
• Example last 3 FBL projects
• (Purebuild, SIS, FIRST)
• Minimise cost, schedule not so important
• Entire project managed with a task-list database
• GANTT charts used only at particular points

RMDB
98
Assign resources to tasks

• Do you have the resources you need?
• Are they overallocated?
• (What do we do about this?)

99
Adding resources

• Even if resources are available, it may be better
  to accept a delay
• Brooks Law Adding more people to a late
  software project makes it later
• Why?
• Pseudo-dependency
• Assigning people to two or more tasks at once

100
The Value of Time

• Finishing a week earlier or later
• What is this worth?
• Minimum cost plan
• Minimum time plan
• Crashing, Fast-tracking
• Does the deadline matter?

101
Time Management how are we doing?
S.M.A.R.T

• Whats done?
• Estimating progress of partly-completed tasks
• Whats in trouble?
• Do we need to worry about every task?
• Do we care how long a non-critical task takes?
• What resources/options are needed?
• Do estimates need revision?
• Are there new tasks?
• Has the critical path/chain changed?
• What resources/options are available?
• when do staff become free?

102
Calculating Whats Done?

• Add up the completed tasks
• Budget completion age completed
• Schedule completion age completed along
  critical path

completed
Simplified example 1 day 1000, No other
costs No partly-completed tasks Estimates have
been exact so far
103
Whats Done?
completed
Simplified example 1 day 1000, No other
costs No partly-completed tasks Estimates have
been exact so far

• We have done 11/15 (73) of the work
• We have used 7/10 (70) of the time available

104
Partly-completed tasks

• Estimated progress
• Often meaningless, eg Analysis complete
• Outline tasks
• Sub-tasks can be S.M.A.R.T.
• complete Completed tasks/all tasks
• 50-50 rule
• 20-80 rule Works best with small tasks
• 0-100 rule

105
Test Certification/sign off

• When is a task complete?
• Based on tangible deliverables,
• Eg, Program passes these tests
• Not related to effort.
• Just because youve spent a week on a task that
  was budgeted as a weeks work, that doesnt mean
  that its complete!
• Completion criteria should be defined early
• test before coding
• Separate testers?
• Split off sub-tasks.

106
Tracking tools

• MS-Project will manage all of this for you
• Gantt chart
• Tracking Gantt
• EVA calculations
• Resource-bound project you dont even need
  MS-Project
• Excel or Access Tasks/Issues Database
• But

RMDB
107
Perils of PM software - 1

• MS-Project can
• Do very sophisticated analysis
• Handle large and complex networks
• Provide a lot of useful analysis
• Eg Resource Loading graphs
• But it can also
• Absorb a lot of the project managers time
• Swamp you with detail
• Dont let it drive you
• Dont update too often
• Dont detail too far ahead
• Use its helpful features (like levelling) with
  care

108
Perils of PM software - 2

• MS-Project does not
• Give you any easy way of expressing risk or
  uncertainty
• Task1 will take 5 days
• Task2 will take from 2 to 6 days (probably 3)
• Highlight what is important
• What you really want to know is What are the key
  tasks that I must keep a close eye on
• MS-project tells you Here are the 50 tasks
  active this month

109
Perils of PM software 3

• MS-Project gives an air of precision to our
  progress reporting and schedule forcasting
• But
• What do we mean when we say (e.g.) 50
  complete?
• Where did the estimates come from anyway?
• And what do they mean?

110
The problem with estimates

• Task will take 5 days
• Where does this estimate come from?
• What does this mean?
• Will take on average 5 days?
• 50 probability that it will complete in 5 days?
• Almost certainly (80? 90?) will complete in 5
  days?

111
What Is an Estimate?

• A commitment?
• A target?
• A prediction?
• A minimum?
• A maximum?
• The most optimistic prediction that has a
  non-zero probability of coming true?

112
How Do We Make an Estimate?

• Gut Feel
• Usually optimistic
• History of similar tasks
• But what data do we use?
• Should use actuals, not old estimates!
• Estimate from FPs, or LOC, using Industry data
• Eg COCOMO estimation models

113
Estimate Revision in Theory
Do some tasks
Review Actual/Estimate

• To improve estimates, create a database of
  measurements
• Task Size
• FPs, Pages of Spec, of stories, of Use
  Cases, etc
• Actual Cost (effort)
• Actual hours
• Who (person -gt senior, junior, etc)
• A TRAP using the same data for estimating, and
  for performance review.

Review Remaining estimates
Review schedule
114
Estimate revision in practice

• Rarely as formal as preceding slide.
• Estimation error if early tasks out by x,
  remaining tasks likely to be out by x
• This means that if youre 10 late now, expect to
  finish 10 late, not make up the time on later
  tasks
• Learning effect
• Example, LICs SUPRA-gtDB2 conversion
• Excellent statistics, predicted finish 3 months
  late
• Actually finished on time (without more resource
  or scope change)
• gt perhaps statistics arent much use after all!

115
Will you complete on time?
25
50
80
90

• Almost certainly estimates contain substantial
  buffers
• Most workers are unaware of this, and cant tell
  you How much buffer is allowed?
• Even if they could, theyd be too suspicious of
  your motives to tell you

116
Critical Chain Project Management

• Open, honest communication can reduce project
  duration (and cost).
• Yet this is NOT what we usually get.
• Getting the Right estimate seems impossible
  there are simply too many conflicting objectives.

Joes story Reading 1.doc
117
Which is better at your next salary review?

• You estimated 5 months for a job, and finished it
  in 4
• Or
• You estimated 2 months for the (same) job, and
  finished it in 3
• ?

118
So what do you do?

• Take the Reasonable Estimate and multiply by
  fudge factor
• necessary in order to meet promised delivery
• But you dont want to be seen to be idle
• So work on several other things as well
• how else to keep busy?
• Both of these are COMMON PRACTICE
• According to Critical Chain theyre BOTH WRONG
• Heres why

119
Combining Estimates

• Each job estimate agreed as 5 months (hidden 20
  buffer)
• How long will the project take?
• If each task has safety margin, 20 must be a SAFE
  estimate!!!!
• After all, 16 is the private estimate

Job 1(Wkr A)
Job 2(Wkr B)
Job 3(Wkr C)
Job 4(Wkr B)
120
Job 1(Wkr A)
Job 2(Wkr B)
Job 3(Wkr C)
Job 4(Wkr B)

• The simple maths answer (20) is invariably
  optimistic.
• Experienced Project leaders add their own fudge
  factors 5 5 13
• Yet we have already seen that each estimate has
  substantial safety
• Why do we have to add more?

121
Non-critical Jobs
Another Job(Wkr B)
Another Job2(Wkr B)
Job 1(Wkr A)
Job 2(Wkr B)
Job 3(Wkr C)
Job 4(Wkr B)

• If Job 1 finishes early, can Wkr B start on Job
  2?
• Perhaps - has he finished Another Job?
• If not, does he know that Another Job is not
  critical, and should be set aside? What if this
  makes AJ2 critical?
• Result-
• Delays are passed on in full
• Advances are usually wasted.

122
The result

• We have planned a 23 month project
• for
• Something that should take only 16 months
• 30 more than necessary!
• Of course if higher management know this is going
  on, so they may reduce the budget anyway
• So Id better but even more in!

123
Where do we go wrong?

• Lets do it again, changing the way we talk about
  estimates

124
Project Plan, with explicit buffers
Job 1(Wkr A)
Job 2(Wkr B)
Job 3(Wkr C)
Job 4(Wkr B)

• What effect does this have?

125
Whats Changed

• We think about estimates differently
• Not a number, but a range
• Uncertainty is acknowledged
• Not a deadline, that I judge YOUR performance by,
  but
• WE have a new tool to manage the project
• Monitor buffer consumption
• We communicate differently
• What do I tell WkrB about starting Job 2?
• What do I report to management
• We are more confident (if less certain)
• So I dont need to add another fudge factor
• Statistical maths actually says that we can
  safely reduce the buffer, but I never do because
• Psychology. Non-randomness

126
The Result

• We have replaced this project plan -
• with one that is
• Shorter
• More likely to be met
• Easier to monitor
• through intelligent use of explicit buffers

Project, with safety margins hidden
Project, with NO margin
Explicit Buffer
127
Buffers and Schedule Pressure

• Should project due-date be pushed to make room
  for buffers?YES!!!!!
• BUFFERS ARE NOT OPTIONAL!!!!!
• YOU HAVE ALREADY CHOPPED 25 OUT OF THE SCHEDULE
  - DONT LET MANAGEMENT FORCE YOU TO HIDE YOUR
  BUFFERS, AS YOU USED TO!

128
Keeping focus

• Priority 1. The Critical-chain tasks
• Priority 2. Near-critical tasks Job 1a
• You can almost ignore everything else (Job 1b)
  unless theyre identified as a project risk

Job 1
Job 1a
Job 1b
When should non-critical tasks start?
129
Feedback, Delegation, Etc

• Within your team, improved openness gt
• Shared objectives
• Better communcation
• More useful feedback
• More ways to respond
• This in turn
• Increases motivation
• Allows more delegation/empowerment
• But it may take time to build up trust

130
Schedule Communication
Project, with NO margin
Explicit Buffer

• At start, you only commit to deliver when ALL
  buffer is used
• But you can communicate the buffer also
• As the project executes and you can bank your
  gains, you can negotiate
• Finish early, or Scope increase?

131
Critical Chain Project Management (CCPM) in
Perspective

• CCPM is
• over-hyped by its promoters
• Largely ignored by the PM establishment
• It is clearly simplistic
• Deals only with schedule management, ignores
  other project constraints
• It is not well supported by current software
• But
• Its concept of explicit buffer management is
  tremendously valuable.

Project Management Journal, Dec. 2002
132
Cost Management How much?
133
Concepts of Cost Management

• Similar to Time Management,
• , not Days
• (Outside Construction/Engineering projects, most
  cost elements are cost-of-time)
• Same issues -
• What is an estimate?
• How do we estimate?
• When is a task complete?
• Cash Flow Forecasting and Monitoring
• Earned Value Analysis

134
Cash Flow Forecasting
2000
10000
135
Cash Flow Monitoring

• After three months
• Budget is 22,000
• Actual is 20,000
• So we are doing pretty well
• Right?

136
What about this one?
2000
A
10000
B
Done
Equipment
C
D
E
F
G

• Budgeted 22,000, Spent 6000
• How are we doing?

137
Cash Flow Reporting

• Budget vs Actual almost meaningless
• Report revised Estimate-at-Completion (EAC) or
  Earned Value
• Revised EAC
• Costs to date PLUS
• Costs to complete
• Always ask Cost/Time to complete, NEVER age
  completed
• So how are you really doing?
• gt earned value analysis (EVA)

138
EVA Calculations

• Work Progress Measures
• BCWP - Budgeted Cost of Work Performed
• BCWS - Budgeted Cost of Work Scheduled
• ACWP - Actual Cost of Work Performed
• Evaluate Progress
• Cost Variance BCWP - ACWP
• Schedule Variance BCWP BCWS
• NOTE schedule variance is expressed in
  (could use average /day to get a Days
  delay/advance)
• EVAExercise.doc

139
EVA in Practice

• In my experience
• BCWP, ACWP essential concepts
• But report to management in more user-friendly
  language
• Cost Variance useful, also cost ratio (ACWP/BCWP)
• I havent found Schedule Variance terribly useful
• Instead, Ive reported Progress along the
  critical chain (in time, not )
• Single most-useful metric is Estimate at
  Completion

140
Project Risk Management
141
Risk Management Activities
What can go wrong?

• Identification
• gt risk register
• Analysis
• Probability. Impact
• Response Planning
• How can you reduce the risk?
• What will you do if..?
• Monitoring and Control
• What gets reported to the Steering Committee?
• The Sponsor?

142
The Risk Register

• May be a separate formal document
• More often just a section in the proposal or
  project plan
• Usually Word, sometimes Excel, rarely a database

143
Identifying Risk

• How do we identify a risk?
• Risks and Issues
• Risk Acceptance
• Contingency (Management Reserves)
• Practice
• Discuss each preparation project
• ?Sample projects

144
Risk Analysis

• Cost
• Cost to the project if the risk occurs?
• Probability
• How likely is it to occur?
• (Expectation Cost probability)
• Mitigation
• How can we reduce the expectation?
• What do we record in the risk register?
• Triage. Trivial risks, global catastrophes
• Risks that we want to track

145
Risk Tracking

• At each SC meeting, report on each risk
• Any change to probability, cost
• Risk lifetimes
• New risks appear. Old risks disappear

146
External Relationships

• What changes?
• Employee lt-gt Contractor lt-gt Supplier
• When do you prefer E, C, or S?
• How does this affect your project risk?

147
Discussion

• Question 4 of Preparation was about risk
  management.
• How did your example compare with this?
• What are the reasons for the differences (if any)

148
Reducing risks in IT Projects

• Next few slides deal with reducing risk
• Data specific to IT, but concepts apply generally

149
Size/Risk. Some Industry Data
Project Size (Function Points)
Software Productivity Research (Capers Jones),
1996
See http//www.ifpug.com/fpafund.htm for fp defn
150
Small Projects

• Small projects
• Lower risk
• Lower cost
• Conclusion
• Break projects up
• But only at REAL boundaries
• Frequent REAL Milestones.

Groshs Law (I think) - If a project does not
produce something useful in lt 6 months, it never
will
151
Size/Cost
Why?
Project Size
152
Standish Group - Risk Index
Standish - Voyages.mht
Standish - Chaos.mht
153
Involve Users

• How do you involve users?
• Getting sign-off on voluminous specifications
  doesnt do it
• Need to communicate well
• New system - need a prototype
• Package - work closely with similar customers
• Implement in stages

154
Discussion

• Question 3 of Preparation was about monitoring
  and control
• How did your example compare with this?
• What are the reasons for the differences (if any)

155
Human Resource Management Leading Effective
Project Teams
156
Effective Project Teams

• Your job
• Is to get the best project outcome possible
• Maximum function, lowest cost, shortest time
• To do this you need to get the best from your
  team
• Effective work
• Correct direction. Common understanding
• Job satisfaction
• Individual growth, development. Enjoyment.

157
So how do you do this?
Scope
Cost.
Time
Cost
Especially when faced with the usual management
approach!
158
Leadership Styles
Czar
Coach
Colleague

• You need
• Personnel skills empathy, communication
• Technical skills enough to be respected
• Analytical skills sort out what matters
• Communication skills boardroom to workbench
• Know yourself
• Use style that you feel comfortable with
• Manage your weaknesses
• (as you would any other team member)

159
Project Leadership

• Whats different from process leadership?
• Constant state of uncertainty
• Lack of long-term relationships with team
• Need cooperation of people over whom you dont
  have direct control
• Dont usually have formal authority

160
Motivating your team

• 1. Convey People and their work are valued
• 2. Convey confidence in peoples knowledge,
  ability, and work ethic
• 3. Recognize good performance
• 4. Lead by example

Motivation.doc
161
Team Structure
Surgical Team
Infantry Platoon
?Where do we fit??

• Are your team members specialists or generalists?
• What are the roles within your team?

• If we can identify the Surgeon, should (s)he be
  the project manager?

162
Project Organizations

• A specialist project company (e.g. Civil Civic)
  has few staff, uses many contractors
• Can add resources as needed
• Doesnt pay for idle time
• Each task is contracted, the contractor has no
  other work (as far as CC are concerned)
• This is the usual model in the construction
  industry
• What issues does this cause?

163
Functional Organisations

• At other companies, project staff may be drawn
  from different areas
• Project staff may have many tasks at once
• This is typical of many service companies, eg
  Insurance, Banking, .
• What issues does this cause?

Accounts
Claims
Branch
164
Team Building

• It takes more than a pizza party!

Team Building
165
Discussion

• Question 5 of Preparation was about team
  structure.
• Where do your project teams lie on the Infantry
  Platoon lt-gt Surgical team scale?
• Is your projects department like a Project
  Company (construction) or a Functional Company
  (insurance).
• Are any problems caused by team members having
  responsibilities outside the project?

166
Quality Management
167
Quality Management

• What is Quality? 7
• Quality ? Scope
• Can we have too much?
• Quality Techniques
• Reviewing 19
• Review techniques and management
• Testing 38
• Testing and Test Management

168
What is Quality?

• No errors?
• Fit for purpose
• Good features
• Something that is worth paying for
• What is the value of more quality?
• Lifetime Cost of a project
• Initial cost, plus support cost over expected
  product life
• Can you reduce support costs by building in more
  quality up front?
• Recall day-1 NPV calculation, with 10K/qtr
  ongoing. What if another 20K in the development
  cost would halve this?

169
Crosby 4 absolutes

• Quality is defined as conformance to
  requirements, not goodness or elegance
• The system for causing quality is prevention, not
  appraisal
• The performance standard must be Zero Defects,
  not "that's close enough".
• The measurement of quality is the Price of
  Non-conformance, not indices.

Phillip Crosby - Quality is free the art of
making quality certain New York McGraw-Hill
ISBN 0-07-014512-1
170
Quality is Free
171
Quality Assurance Fundamentals

• QA techniques provide critical support for
  maximum development speed (or min cost)
• If too many defects -gt spend more time fixing
  than writing

95 correct is fastest

• Later Change is MUCH more expensive
• 1 -gt 60 Ratio!!!

172
We havent got time(for more testing, for review)

• A decision not to focus on defect detection early

• is a decision to postpone defect detection until
  later in the project,

• WHEN IT WILL BE MUCH MORE EXPENSIVE IN TIME AND
  

173
Quality value

• Need gtgt 95 perfection for
• Critical systems
• Pacemaker, radiotherapy, Air traffic control, etc
• Critical parts of systems
• DBMS, OS Kernel, etc
• Software products in general
• It can be very expensive to fix problems in
  delivered package
• Need high quality for key bits of normal
  application
• Key question What is the cost of a defect
  (missing feature, error, etc)

174
Focus

• But not all the system is equally critical
• Rarely used, or specialist parts of the system
  (eg Admin)
• Like project risk analysis
• Cost Probability Expectation

175
Procurement Management
176
Procurement is

• Buying goods and services from an external
  supplier
• Buy or build its usually obvious
• Goods always buy
• Services Use internal supply IF you have
  suitable available resource
• Company policy. Project/Functional
  organizations. Type of project.

177
More formal than internal supply

• Supply contracts
• What, when, often fixed.
• Statement of Work (SOW)
• Process
• Planning gt Issue order gt Accept gt Pay
• New or regular suppliers?
• Supply contracts

178
Issues

• Record keeping (eg Purebuild)
• Open orders, unpaid, etc
• Flexibility
• Order lead time
• Scope, schedule management
• When this goes well, procurement increases
  project certainty
• Tasks well defined, price fixed, quality agreed,
  date specified
• When it goes badly, it can be difficult to manage
• Scope errors gt cost, schedule overruns

179
Project Completion
180
Closure Processes

• Closes stage of project
• Acceptance - did it meet spec (contract)?
• What did we leave out?
• What extra things did we do?
• How did we do?
• Cost, schedule variance
• What worked? What didnt?
• What can we learn for next time
• Should we update our standards? Methods?
  Suppliers?

181
Closure

• What happens after the project is more
  important than the project
• Is this your (PM) problem?
• Closure issues
• Keeping focus as project staff drift away
• Project can drag on and on and on .
• The Punch List

182
Assessing Project Success

• Level 1 Meeting Project Targets
• Cost, schedule, functionality/quality
• Level 2 Project Efficency
• How well was the project managed?
• Client disruption. Effective resource use. Cost,
  communication, management of conflict.
• Level 3 Customer or User Utility
• Was the problem solved? Did we achieve the
  increase in sales/profit/??? Is the customer
  actually using the product as intended?
• Level 4 Organizational Improvement
• What have we learnt?

183
How formal is this?

• Discussion, Preparation Q 7

Close Out Report V1.1.doc
184
Thank you for listening
The End