CHAPTER 4

Project Planning and Budgeting

1
CHAPTER OUTLINE

4.1 Project Planning

4.2 Project Budgeting and Cost
Estimations

2
4.1 PROJECT PLANNING

3
Planning is answering questions

• What must be done?

• Who will do it?
• By when must it be done?
• How should it be done?
• How much will it cost?
• How good does it have to be?

4
 Elements of Project Master Plan
• Overview (1)
• brief description of project
• deliverables
• milestones
• expected profitability and competitive impact

• Objectives or Scope (2)

• detailed description of project’s activities (WBS, OBS)
• Scope baseline

5
 Elements of Project Master Plan
continued

• General approach (3)

• technical and managerial approaches
• relationship of the project to technologies
• deviations from routine procedures

• Contractual aspects (4)

• agreements with clients and third parties
• reporting requirements
• technical specifications

6
 Elements of Project Master Plan
continued

• Schedules (5)
• outline of all schedules and milestones

• Cost estimates(6)
• estimated project expenses
• overhead and fixed charges

• Personnel (7)
• special skill requirements
• necessary training
• legal requirements

7
 Elements of Project Master Plan
• Evaluation methods (8)
• evaluation procedures and standards
• procedures for monitoring, collecting, and storing data on project
performance
• Potential problems (9)
• list of likely potential problems

8
 (2) Project Scope
Project scope is everything about a project – work content as well as
expected outcomes.

Scope management is the function of

controlling a project in terms of its goals and
objectives and consists of:
•1) Conceptual development 4) Scope reporting
•2) Scope statement 5) Control systems
•3) Work authorization 6) Project closeout

9
The Scope Statement Process

1. Establish the project goal criteria

a) cost
b) schedule
c) performance
d) deliverables
e) review and approval gates
2. Develop the management plan for the project
3. Establish a work breakdown structure
4. Create a scope baseline

13
Project charter

• A project charter: authorizes the project manager to initiate and

lead the project.
• Issued by upper management and provides the project manager with
written authority to use organizational resources for project.
• Scope creep: project scope to expand over time—usually by changing
requirements, specifications, and priorities. activities.

14
Project Charter

- Project objectives:
- Deliverables
- Milestones
- Technical requirements
- Limitations (scope)
- Approach
- Constraints
Signed by Sponsor, Project manager, Customer..

15
 < TITLE> <date>
<sponsor>
CONTEXT / ISSUES VISION OF SUCCESS
•What is the issue and why is it important to tackle now? •What outcomes or results do you want to see?
•What is the purpose, the business reason for choosing this project? •What does success look like for our customer?
•What are the anticipated benefits to customers and staff from the project? •What does success look like for other stakeholders (staff, partners)?
•What performance measure needs to improve?
•Have you been to the Gemba?
•What process/program/customer data do you have regarding the problem
(time, cost, quality )? Show facts and processes visually using charts, graphs,
maps, etc.
•When did the problem start?
•Where is the problem occurring?
•What is the extent or magnitude of the problem?
PROJECT MILESTONES & SCHEDULE
GOALS Project Milestones Owner Proposed Actual
•What specific, measurable , attainable, relevant, time-bound results do you Date Date
want or need to accomplish?
• Show visually how much, by when, and with what impact. 1. Set project scope and goals (prepare Project Sponsor/Team
Charter, engage team, collect data) Leader, Facilitator
• NOTE: Be careful not to state a solution as a goal!
2. Understand the current situation Facilitator/ Team

SCOPE (IN BOUNDS) SCOPE (OUT OF BOUNDS) 3. Analyze the current situation (root causes) Facilitator/ Team
•What is the first step and last step in •What is off the table due to 4. Define a vision of success Facilitator/ Team
the process? resources? 5. Generate, evaluate and select improvements Team/ Sponsor
•What is the program and geographic •What are the givens or assumptions
area? for the project?
6. Implement changes and make adjustments Team Leader/ Staff
•NOTE: Be mindful of what you can •Record out of scope issues in a
realistically accomplish with available “Parking Lot” 7. Measure performance Sponsor/Team
Leader
resources and time.
8. Document standard work and lessons Team
learned

CUSTOMERS/STAKEHOLDERS TEAM MEMBERS 9. Sustain improvement Team Leader/Process

Owner
•Who is the end-user customer? •Team Leader:
•Team Members:
•Who are other stakeholders who RESOURCES
have a role or interest in the success
of the process? •Time commitment for a 4 day Kaizen, excluding time to implement changes:
Sponsor (6-10 hrs.); Team Leader (40 hrs.); Team Members (32 hrs.); Facilitator
(40-50 hrs.)
CUSTOMER REQUIREMENTS (CTQ) •External Resources:
•What do customers/stakeholders expect and require from the process? •Equipment:
What are their critical to quality (CTQ) requirements? •Materials:
•What legal requirements (laws, rules) govern the process?
 < TITLE> <date>
<sponsor>
CONTEXT / ISSUES VISION OF SUCCESS

GOALS PROJECT MILESTONES & SCHEDULE

SCOPE (IN BOUNDS) SCOPE (OUT OF BOUNDS)

CUSTOMERS/STAKEHOLDERS TEAM MEMBERS

•Team Leader:
•Team Members:

CUSTOMER REQUIREMENTS (CTQ) RESOURCES

•Time commitment for a 4 day Kaizen, excluding time to implement changes: Sponsor (6-10 hrs.); Team
Leader (40 hrs.); Team Members (32 hrs.); Facilitator (40-50 hrs.)
•External Resources:
•Equipment:
•Materials:
 Project Charter
Clinical Research Filtered Query (CRFQ) - pilot
Problem Statement: Evaluation of protocol feasibility against Roles and Responsibilities
patient population, patient recruitment and monitoring patient
- Leader: I. de Zegher, C. Mead
population with specific safety conditions are today very difficult to
achieve for clinical research organizations. Access to patient information - Team Members:
is very fragmented; there are some centralized databases like GPRD, • See enclosed table
which allows to check specific patient criteria but this is not sufficient to - Steering Committee: OC from the EHR stakeholder
cover a wider population. EHR offers new possibilities that need to be workshop
clarified and piloted. • Ilias Iakovidis
Project Scope: • Isabelle de Zegher
·Pilot implementation of a standard service such as CRFQ. A request • Veli Stroetmann
would be issued by a clinical research organization, be forwarded to • Georges De Moor
Health Care providers (hospital, third parties like GPRD, other regional • Gudrun Zahlmann
or national Databases) to evaluate patient population against specific • Jean Samuel
criteria. • Petra Wilson
·Evaluate needed changes (business processes and organizational • Mats Sundgren
aspects, additional services, legal implications) to implement the
service in full production.
·Evaluate how to work together as a Health Care “continuum” to further
defined service in the clinical research area
Goals Time Frame (proposal)
· Support specification of the already started service specification
within HL7 RCRIM –going to ballot early 2008 (see document in annex) Milestone Date
· Evaluate business process changes in the context of protocol
feasibility, patient recruitment and safety monitoring Kick-off TC – agreement on scope by team Dec07
· Evaluate business case – benefits and cost for full implementation Template for organizational and financial Dec07
across the Health Care chain evaluation
· Understand legal implications
· Define roadmap on how to implement in full production Comment to service specification – HL7 Jan 08 ?
ballot
Business benefits Use case finalized for protocol feasibility, May 08
· Understand complexity of implementation on EHR integration for patient recruitment, safety monitoring
specific purpose across the Health Care value chain – with a
documented business case that allow the different decision makers to Implementation of pilot within 3 to 5 Sept 08
decide on the way forward partners & evaluation
· Support informed decision for go/no decision on EHR integration for Final recommendations Dec 08
the use cases in scope
 Project Charter – cont.
Clinical Research Filtered Query - pilot
Project Deliverables: Approach:
· Dec07.
· Pilot implementation for testing at least in one sponsor and one hospital; pilot - Kickoff of the project (agreement on this charter) Microsoft Word
based on technical Specification of CRFQ (not part of this project but input from this - Introduction to the CRFQ project – ongoing currently Document
project very important at balloting time) (see enclosed document)
- Identification of partners ready to implement the services
· Description of new business process (on the complete HC value chain)– including
(preferably different organization than the ones that will pilot core
CRFQ – for
data sets)
• Evaluation of protocol feasibility - Agreement on the template – with draft use case – for business
• Patient recruitment process clarification; identification of participants for each of the
use case
• Safety monitoring condition
- Agreement on monthly TC + possibility for 1 day F2F in
· Specification of legal requirements/constraints (to be provided as input to team February/March
working on Governance model) · Feb/March (F2F workshop ?)
- Draft business process for 3 aspects – identification of missing
· Estimate of feasibility and cost for implementation of the service in full production – components (i.e. additional services) for full implementation
including a roadmap - Draft identification with quantification of benefit
- Draft identification with quantification of related cost
- Draft identification of legal requirements
Measurement · June
- First version of pilot – agreement on testing scenario across
Metric Baselin Goal Blue Sky several institutions
e - Consolidation of business case (benefit and cost)
Pilot implementation of CRFQ in 2 sponsors, 2 0 2+2+2 Anything more - Consolidation of legal requirements
hospital, with 2 vendors (2+2+2) than 2+2+2
Description of the 3 processes in scope fully 0 2 3 processes
· Sept/Oct (F2F workshop ?)
documents – in terms of changes processes - Execution of pilot and lessons learned
Business case documented with 70% 0% 70% 80% - Finalization of use case description with business process
certainty changes
Legal requirements – related to business ? 80% 100% - Draft recommendations – including roadmap for implementation
process changes – can be implemented
without major changes in regulations
· Questions: Where do we publish results – as part of Collaboration
Forum/Governance body

· Overall SC with core data sets and third party to understand

dependencies (only at SC level – not at team level)
· Routinely share ‘exchange point/ commentary resource’ with legal
stream to ensure alignment
Participants lists
Project objectives

- Project objectives: define the overall objective

to meet your customer’s need(s).
- The project objective answers the questions of what, when, and how
much.
For example, to design and produce a completely portable,
hazardous waste, thermal treatment system in 13 months at a
cost not to exceed $13 million.

21
Project Objectives

22
 Project deliverables
• Expected outputs over the life of the project.
• Tangible things that the project produces to enable the objectives to be
achieved.
• May be Product/service realisation outputs – Supporting
documentation – Project management outputs
For example: Developing a software
- Design phase: a list of specifications
- software coding and a technical manual
- test prototypes
- final tests and approved software.

23
Project milestones

• A milestone is a significant event in a project that occurs at a point in

time.
• The milestone schedule shows only major segments of work.

24
Project limitations/scope/boundaries

• What project does (in scope) and what it doesn’t do (out of scope)-
avoid false assumption

25
Project constraints

• Budget
• Human resources
• Technical issues
• Time frame

26
Project approach

• Assumptions: predetermined agreement

• Principles: technological/managerial requirements
• Guidelines how the task objectives will be pursued

27
Table 5-2: Sample Project Charter

28
29
The Work Breakdown Structure
(WBS)
• a process that sets a project’s scope by breaking down its overall
mission into a cohesive set of synchronous, increasingly specific
tasks.
• A hierarchical planning process
• Breaks tasks down into successively finer levels of detail
• Continues until all meaningful tasks or work packages have been
identified

30
a WBS: Bill of Materials for a Toy Bus

31
 WBS: Common Format
• An outline with Level 1 tasks on the left and successive levels indented

LEVEL DESCRIPTION
1 Total Program
2 Project(s)
3 Task(s)
4 Subtask(s)
5 Work Package(s)
6 Level of Effort
33
Work Breakdown Structure and
Codes 1.0 The project is the overall
project under
development
1.2 1.3 1.4

Deliverables are
1.2.1 1.3.1 major project
components
1.2.2 1.3.2

1.2.3 Subdeliverables are

supporting deliverables
1.2.3.1
Work Packages are individual
1.2.3.2 project activities
34
 WBS Preparation
WBS Planning:
• Define the Levels of the WBS for your program (Level 4 minimum)

Mission Product
(Level 1)

Hardware Database Application Services

(Level 2) (Level 2) (Level 2) (Level 2)

Development Design Module 1 Apportioned

Environment (Level 3) (Level 3) Costs
(Level 3) (Level 3)

Test & Eval Document Module 2 Oversight &

Environment (Level 3) (Level 3) Reviews
(Level 3) (Level 3)

Production Develop Module 3 Operations /

Environment (Level 3) (Level 3) Support
(Level 3) (Level 3)

Non-Direct
Labor
(Level 3)

35
 WBS Preparation (Cont’d)
Mission Product
(Level 1)

Application
(Level 2)

Module 1 Module 1
CI# xxx CI# xxx
(Level 3) (Level 3)

Design Design
(Level 4) Document 1 (Level 4)
(Level 5) 2
Document
Document (Level 5) 3 Document
(Level 4) Document
(Level 4)
(Level 5) 4
Document Build
(Level 5) (Level 5)
Develop Develop
(Level 4) (Level 4)
Integrate
Test Test (Level 5)
(Level 4) (Level 4)
CV&I Test 1
(Level 5)

CV&I Test 2
(Level 5)

36
 WBS Preparation (Cont’d)
Mission Product
(Level 1)

Application Apportioned Services

Costs
(Level 2) (Level 3) (Level 2)
Risk & Issue Mgt
Module 1 Oversight & Operations /
(Level 4)
CI# xxx Reviews Support
(Level 3) Prgm Plan (Level 3) (Level 3)
(Level 4)
Design Phase Rvws EMA/SLA
(Level 4) Contract Mgt (Level 4) (Level 4)
(Level 4)
Document Tech Rvws Cust Spt
(Level 4) Financial Mgt (Level 4) (Level 4)
(Level 4)
Develop Planning
Mgt Rvws
(Level 4) Tech. Mgt (Level 4)
(Level 4)
(Level 4)
Test IPTs / Mtgs Non-Direct
(Level 4) Test & Eval (Level 4) Labor
(Level 4)
(Level 3)
Compliance
Req. Mgt (Level 4) Training
(Level 4)
(Level 4)
Config. Mgt
(Level 4)

37
Hierarchical Planning

• Major tasks are listed

• Each major task is broken down into detail
• This continues until all the activities to be completed are listed
• Need to know which activities “depend on” other activities

38
 A Form to Assist Hierarchical
Planning

39
Figure 6-2
Career Day

40
WBS for a complex project

41
Sample WBS in MS Project

42
Steps for designing and using a WBS

1. List the task breakdown in successively finer levels of detail. Continue until
all meaningful tasks or work packages have been identified.
2. For each such work package, identify the data relevant to the WBS: scope,
begin/end dates, person (organization) responsible for each task, budget.
3. Verify the accuracy of the WBS by reviewing all work package information
with the individuals or organizations responsible for doing or supporting the
work.

43
 Steps for designing and using a
WBS (continued)
4. The total project budget should consist of
• direct budgets from each task
• an indirect cost budget for the project
• a “contingency” reserve for unexpected emergencies;
• any residual, which includes the profit derived from the project
5. The project master schedule integrates schedules for different parts
of the project

• Items 1-5 focus on the WBS as a planning tool but it may also be used to
monitor and control the project

44
 Steps for designing and using a
WBS (continued further)
• Items 6, 7, and 8 use the WBS as an aid to monitor and control a project:
6. Examine actual resource use, by work element, work package, task, up to the
project level.
7. Identify problems, harden cost estimates, and make sure that corrections
have been designed and are ready to implement.
8. Like a budget: Compare actual progress to scheduled and take corrective
action.

45
Organizational Breakdown Structure
(OBS)
• Useful to create a table that shows staff needed to execute WBS tasks
• One approach is a organizational breakdown structure
• Organizational units responsible for each WBS element
• Who must approve changes of scope
• Who must be notified of progress
• WBS and OBS may not be identical

46
Organizational Breakdown
Structure
Organizational Breakdown Structure (OBS) allows
• Work definition
• Owner assignment of work packages
• Budget assignment to departments

OBS links cost, activity & responsibility

47
48
49
50
Responsibility Assignment Matrix
LEAD PROJECT PERSONNEL
Task Ann
Dave Sue Jim Bob
Deliverable & Code IS HR R&D R&D IS
Match IT to Problem
Org. Tasks Analysis 1.1.1
1.1
Develop
info 1.1.2
Identify IS Interview
user needs users 1.2.1
1.2
Develop
1.2.2
show
Gain user
“buy in” 1.2.3
Prepare Find cost/ 1.3.1
proposal 1.3 benefit info
Notification Responsible Support Approval
51
Risk management

Risk management - the art and science of identifying, analyzing,

and responding to risk factors throughout the life of a project and in
the best interest of its objectives.

Project risk – any possible event that can negatively affect the
viability of a project

52
 Process of Risk Management
• What is likely to happen?
• What can be done?
• What are the warning signs?
• What are the likely outcomes?

53
Four Stages of Risk Management

1. Risk identification

2. Analysis of probability and consequences

3. Risk mitigation strategies

4. Control and documentation

54
An Example

55
Quantitative Risk Analysis

1. List ways a project can fail

2. Evaluate severity of the consequences of each type
of failure (1-no effect, 10- very severe)
3. Estimate likelihood of risk occurence (1-remote, 10-
almost certain)
4. Estimate the ability to detect (1-almost certain, 10-
not be detected in time)
5. Find the risk priority number (RPN) (RPN = S  L  D)
6. Consider ways to reduce the S, L, and D for each
cause of failure

56
 Risk Matrix

57
Figure 6-12
Risk Mitigation Strategies

• Accept
• Minimize
• Share
• Transfer
• Contingency Reserves
• Mentoring
• Cross training

58
Control & Documentation

Help managers classify and codify risks, responses, and outcomes

Change management report system answers

• What?
• Who?
• When?
• Why?
• How?

59
4.2 PROJECT BUDGETING
and COST ESTIMATIONS

60
 Project Budgeting
WBS

Project
Plan
Scheduling Budgeting

The budget is a plan that identifies the resources, goals and

schedule that allows a firm to achieve those goals

61
Budgeting

• The budget for an activity also implies management support for that
activity
- Higher the budget, relative to cost, higher the managerial support
• The budget is also a control mechanism
• Many organizations have controls in place that prohibit exceeding the budget
• Comparisons are against the budget

62
Estimating Project Budgets

• On most projects
• Material + Labor + Equipment + Capital + Overhead + Profits = Bid
• In other words
• Resources + Profits = Bid
• So we are left with the task of forecasting resources

63
Estimating Project Budgets Continued

• Like any forecast, this includes some uncertainty

• There is uncertainty regarding usage and price
• Especially true for material and labor
• The more standardized the project and components, the lower the
uncertainty
• The more experienced the cost estimator, the lower the uncertainty

64
Rules of Thumb

• Some estimates are prepared by rules of thumb

• Construction cost by square feet
• Lawn care cost by square feet of lawn
• Printing cost by number of pages
• These rules of thumb may be adjusted for special conditions
• However, this is still easier than starting the estimate from scratch

65
Estimating Budgets is Difficult

• There may not be as much historical data or none at all

• Even with similar projects, there may be significant differences
• Many people have input to the budget

66
Estimating Budgets is Difficult Continued

• Multiple people have some control over the budget

• There is more “flexibility” regarding the estimates of inputs
(material and labor)
• The accounting system may not be set up to track project data
• Usage of labor and material is very lumpy over time

67
Types of Budgeting

• Top-down
• Bottom-up
• Negotiated

68
Top-Down Budgeting

• Top managers estimate/decide on the overall budget for the project

• These trickle down through the organization where the estimates are
broken down into greater detail at each lower level
• The process continues to the bottom level

69
Advantages

• Overall project budgets can be set/controlled very accurately

• A few elements may have significant error
• Management has more control over budgets
• Small tasks need not be identified individually

70
Disadvantages

• More difficult to get buy in

• Leads to low level competition for larger shares of budget

71
Bottom-Up Budgeting

• Project is broken down into work packages

• Low level managers price out each work package
• Overhead and profits are added to develop the budget

72
Advantages

• Greater buy in by low level managers

• More likely to catch unusual expenses

73
Disadvantages

• People tend to overstate their budget requirements

• Management tends to cut the budget

74
 An Iterative Budgeting Process–
Negotiation-in-Action

• Most projects use some combination of top-down and bottom-up

budgeting
• Both are prepared and compared
• Any differences are negotiated

75
Work Element Costing

• Labor rates include overhead and personal time

• Direct costs usually do not include overhead
• General and administrative (G&A) charge

76
Example

• Suppose a work element is estimated to require 25 hours of labor, by

a technician. The labor cost is paid $17.5/hour. Overhead charges to
the project are 84% of direct labor charges.

77
Typical Monthly Budget

79
 Project Budget by Task & Month

80
Table 7-2
 Improving The Process of Cost
Estimation
• Inputs from a lot of areas are required to estimate a project
• May have a professional cost estimator to do the job
• Project manager will work closely with cost estimator when planning
a project
• We are primarily interested in estimating direct costs
• Indirect costs are not a major concern

81
Problems

• Even with careful planning, estimates are wrong

• Most firms add 5-10 percent for contingencies

82