The University of California
Berkeley Extension
X470 Project Management
Lisa Bausell
1
X470 Project Management
1 Project Management
2 Project Planning
3 Project Planning
Introduction
Scope
Resources
Project Initiation
Workflow
Finalization
4 Project
5 Project
6 Project Management
Baseline
Reporting & Communication
Review
Monitor & Control
Closure
Presentations
2
Review of week 1
• Teams debrief; leader, questions, results
• What is a project
• Triple constraint (2 words)
• Project, Program, Portfolio
• PMI, PMBOK
• Project Initiation
3
Project Initiation
•
•
•
•
•
•
•
•
•
•
Select projects
Develop project charter
Secure project sponsorship
Identify stakeholders
Plan communications
Acquire project team
Define initial project scoping and objective
Establish project priorities
Define a project vision
Conduct a project start-up workshop
4
5
UC Berkeley Certificate in
Project Management
Six project management courses are required to
complete the certificate (Student must complete 3 Required
courses and select 3 Electives)
Required Courses are:
• X470 Project Management
• X469.2 Project Leadership & Building High Performing
Teams
• X471.9 Project Execution & Control
6
UC Berkeley Certificate in
Project Management
Electives:
Student must select 2 of these 3 electives:
•X470.9 Project Scope & Quality Management
•X440.4 Project Schedule & Risk Management
•X470.3 Project Cost & Procurement Management
Students must select 1 additional elective. There are
currently over 20 options.
7
UC Berkeley Extension
• Founded in 1891 by the University of
California, Berkeley
• 60 certificate programs
• 1,500 courses per year
• 30,000 students per year
• Multiple centers in the Bay Area
8
Example Extension Courses
•
•
•
•
•
•
•
•
•
•
•
9
Accounting, Finance, Business Administration
Project Management
Agile Management
Project Management for Biotech
Marketing, Human Resources, Management
and Leadership
Product Development
Woman and Leadership
Effective Writing in the Workplace
Fundamentals of Green Building with LEED
Organic Chemistry
…
Academic Excellence
• Courses, certificates, and programs
approved by UC Berkeley
• Academic Advisory Boards including UC
Berkeley faculty and industry experts.
• UC Berkeley-approved instructors with
industry experience.
10
UC Berkeley Extension Project
Management Offerings
• Beginning through advanced level courses
• Professional certificates
• Specialized and on-site programs
UC Berkeley Extension is a PMI® Registered
Education Provider (REP) and all offerings are
consistent with the PMI
PMBOK® Guide.
11
Project Planning (Scope)
•
•
•
•
Develop Project Management Plan
Collect Requirements
Define Scope
Create WBS (Work Breakdown Structure)
12
Develop Project Management Plan
“Documenting the actions necessary to
define, prepare, integrate, and coordinate all
subsidiary plans.” (PMBOK 4.2)
Project plans include:
•
•
•
•
13
Schedule
Budget
Quality plan
Communications plan
•Human resources plan
•Risk Management Plan
•Procurement plan
•…
Benefits of Project Planning
•
•
•
•
Set a basis for good communication.
Minimize rework and missing work.
Improve performance to schedule.
Create deliverables that meet
expectations.
• Better manage risk.
• Refine the understanding of the project.
• Establish that the project is possible.
14
Project Plan Development
Adequate planning leads to shorter projects:
Plan
Do
Plan
Do, redo, undo, redo . . .
15
Project Planning
• Project planning processes are scalable,
applicable to projects of any size.
• Planning continues throughout a project, so it is
self-correcting (progressive elaboration).
• While project planning processes are generally
started in a set sequence, later steps are likely to
reveal information that results in iteration back to
adjust earlier planning and assumptions.
16
Project Planning Steps
• Collect requirements, define scope.
• Define work breakdown structure (WBS) and
project activities.
• Sequence activities
• Estimate activities
• Analyze workflow
• Delegate responsibilities, analyze resources
• Assess constraints and risks
• Negotiate, adjust, and finalize plans
• Set the project baseline
17
Project Planning Horizon
• Detailed planning is often inaccurate for work
more than six months in the future.
• Longer projects often use Phase or “Rolling Wave”
planning.
• Regardless of project duration, periodically review
project plans and assumptions.
• Planning and execution inevitably overlap for most
projects.
18
Collect Requirements
“Defining and documenting stakeholders’
needs to meet the project objectives.”
(PMBOK 5.1)
Scope planning begins by defining
requirements.
19
Requirement Specification Process
Technology
Capability
Current
Knowledge
Gather
Requirements
Validate
Requirements
Specify
Requirements
Valid
Requirements
Specification
Agreement
NO
20
YES
Gather Requirements Data
• Begin with your written project objective.
• Develop a two-column table: What you know and what you
don’t know.
• Recognize and manage your biases.
• Gather requirements:
• Build a relationship with the customer.
• Use open and closed questions.
• Use descriptions, diagrams, and physical models.
• Prioritize and establish boundaries.
• Check your information within your team, and with your
sponsor, stakeholders, customers, and users.
21
Document Requirements
Formalize specifications in writing. Strive to make
each requirement:
 Specific
 Measurable
 Achievable
 Stable
 Clear and unambiguous
Project deliverables, like all parts of scope definition,
will become clearer and more specific over time.
22
Requirements: Is & Is Not
Is
Is not
•
•
•
•
•
•
• What it isn’t.
• What it doesn’t do.
• “Wants” that you will
exclude.
• Features to be included
in the next project.
• Valid requirements that
won’t be in this project.
• …
Set boundaries on the project; make needed adjustments
before you plan and begin the work.
What it is.
What it does.
What it looks like.
How it works.
“Musts.”
“Wants” that you will
include.
• …
23
Acceptance/Completion Criteria
• The criteria your project customer will use to
verify scope and accept your project
deliverable.
• Specific testing criteria that will be used to
validate the deliverable is complete.
• Technical specifications and performance
data.
Define what “done” looks like at the start.
24
Define Scope
“Developing a detailed description of the project and
product.” (PMBOK 5.2)
Scope definitions may be called (or be part of):
•
•
•
•
•
•
•
25
Project Charter
Project Data Sheet
Proposal
Reference Specifications
Statement of Work
Plan of Record
…
Whatever you call it,
write it down.
QUIZ
26
* Create Work Breakdown Structure
“Subdivide project deliverables and project
work into smaller, more manageable
components.” (PMBOK 5.3)
A Work Breakdown Structure (WBS) is a logical hierarchy
where:
• Each lower level provides greater detail than the previous level.
• Any level can be easily and completely "rolled up” to the next
higher level.
• All activities that must be completed in order to complete the
project are identified.
Most projects will require multiple iterations of the WBS to
develop a complete picture.
27
WBS Preparation
• This is a team process.
• Allow enough time; have “yellow sticky” notes,
pens, other materials.
• Review project documents: scope definition,
project requirements, life cycle, retrospectives
from similar past projects.
• Partition big teams and projects into smaller
sub-parts before creating WBS.
28
Identify the Work
• Review past projects.
• Brainstorm all activities; Strive for
completeness.
• Capture each task on a separate sticky note.
• Break large tasks into shorter tasks;
continue the breakdown process seeking 2 to
20 day tasks.
• Check that subtasks add up to the larger
decomposed tasks.
29
Organize the Work
• Develop task descriptions in "verb-noun" form.
• Group all tasks into major categories of work.
Some typical methods are:
•
•
•
•
•
Major deliverables
Organizational responsibility
Business Function
Geographical location
Life cycle or project phases
• Seek groupings of subtasks with no more than 4 to
7 items.
30
WBS Formats
Graphical
Outline
Project Objective
1.0
2.0
3.0
4.0
1.1 1.2 1.3 1.4
(As with “sticky” notes)
31
Project Objective
Task 1.0
Task 1.1
Task 1.2
Task 1.3
Task 1.4
Task 2.0
Task 3.0
Task 4.0
(As with scheduling tools)
Example WBS
Project Zinfandel
Analyze
System
Design
System
Develop
Prototype
Conduct
Internal
Test
Conduct
User Test
Do Project
Start-up
Workshop
Determine
Software
Specs
Build and/or
Obtain
Hardware
Install
Prototype
Install User
Systems
Prepare
Feasibility
Analysis
Determine
Hardware
Specs
Write
Software
Perform
Internal Test
Perform
User
Tests
Prepare
Financial
Analysis
Design
System
Identify
Test Users
Fix Internal
Test Defects
Develop
Marketing
Strategy
Document
System
Assemble
Prototype
Assemble
User Test
Systems
Update
Learning
Products
Develop
Support
Strategy
Develop Test
Plan
Prepare
Learning
Products
Prepare for
Support
Release
System
Summarize
Project
Goals
Specify
Learning
Products
32
Prepare
Marketing
Materials
Fix User Test
Defects
Do Project
Retrospective
Top-down vs. Bottom-up
 Top-down: Work from the project objective down.
 Bottom-up: Have everyone brainstorm as many
tasks as possible. Organize the tasks into logical
groupings.
Either approach (or a combination) can result in a
thorough WBS. Use the approach that works best for
you and your team.
33
Document the Structure
• Store the WBS with your other project data.
• Code each project task. (Project scheduling
tools can do this automatically.)
• Update the WBS throughout the project
whenever new tasks are identified.
34
35
36
37
In Class Exercise
WBS Exercise
Project is “Opening a new restaurant in San Francisco.”
• Individually 10 high level tasks (hint: 1 is start and one is open
for business)
• Teams Consolidate activities
38
Project Planning (Workflow)
•
•
•
•
•
•
Define Activities
Sequence Activities
Estimate Activity Durations
Develop Initial Schedule
Create Network Diagrams / Gantt Charts
Analyze Project Critical Path
39
Define Activities
“Identify the specific actions to be performed
to produce the project deliverables.” (PMBOK
6.1)
Activities are usually derived from the lowest level
of the project WBS.
Project activities may also be called tasks, work
packages, “stories,” or other names.
40
Document Activity Information
• Identify a single owner for each task
• Clearly define the output deliverables of each
project task
• Document key assumptions for all tasks
• Collect and store all task data
41
Activity Ownership
Ownership: Many owners = No owner
• Assign one, and only one, owner per task
• Owners plan, estimate, monitor and report task
data
• Owners are not necessarily ‘doers’
42
Activity Staffing
In addition to the activity owner, determine all
contributors expected to participate in the
work. Capture:
• Names
• Roles and skills
• Availability
43
Measurable Deliverables
• Owners specify the deliverable(s) for each lowest-level
task
• Define the deliverables clearly
• Tasks with several deliverables may need further break
down
• Determine measures and completion criteria
• Capture key assumptions
44
Project Milestones
In addition to activities, projects also contain
milestones, which are “moments in time” and have
no (or almost no) work or duration. Examples of
milestones:
•
•
•
•
•
Project start
Project end
Life cycle transitions or phase gates
Significant events or decisions
Links between projects
Also document all project milestones.
45
Sequence Activities
“Identify and document the relationships among
project activities.” (PMBOK 6.2)
• Dependency relationships generally follow work flow.
• Every identified activity must precede another activity (or
milestone).
• Every identified activity must follow another activity (or
milestone).
• Activity linkages are based on logic, not dates.
Determine and thoroughly document all project
activity dependencies.
46
Project Estimation Terms
Effort:
Total personal time spent working
on a activity
Duration:
Workdays required to complete a
activity
Calendar time: Total number of days on the
calendar to complete a activity
47
Estimate Activity Durations
“Approximate number of work periods needed
to complete individual activities with estimated
resources.” (PMBOK 6.4)
– Initial duration estimates relate to project time
management.
– Calendar duration estimates include both
workdays and non-workdays
– Effort (resource) estimates relate to project
cost, and are measured in “person hours” or
similar units. Effort and duration estimates must
be consistent.
48
Initial Duration Estimates
Initial project estimates are:
• Best provided by task owners
• Based on activity details:
• Duration estimates are based on history
• Effort assessments are based on staffing
assumptions
49
Project Estimates
Project
Information
Assumptions
Activity
Information
Archived
Metrics
Estimates
Estimating Process
50
Activity Estimates
Project
Specifics
History
Base
People and
Teams
Duration
Estimates
Non-Project
Factors
Effort
Estimates
Good estimates take into account:
• History base
• Project specifics
• People and team variables
• Non-project factors
51
Calendar
Time
Historical Basis
• Documented history
• Project retrospectives
• Project files
• Metric databases
• Anecdotal data
• Experiences of activity owners and ‘doers’
• What will be required to complete the activity
• Assumptions and expectations
52
Project Specifics
• Unclear or changing specifications
• Technical complexity
• Long project duration
• Requirements for innovation or new methods
53
Activity Duration Estimates
• Reduce unknowns.
• Thorough definitions
• WBS level of detail
• Consider worst-cases.
• Document assumptions.
• Skills and experience of people
• Availability and capability of tools
• Complexity and size of tasks . . .
54
Consider Effort
• “Work time” — Personal time required to
complete a task.
• Measured in ‘person-hours,’ or similar
combination of staffing and time.
• Test credibility of duration estimates based
on expected staffing. Effort and cost
estimates are to be refined in later planning
steps.
55
3-Point Estimates
3-point estimates
originated with “PERT”
(Program Evaluation and
Review Technique), and
can help account for risk.
to
0
TIME
tp
tm t e
50%
1%
99%
t o = “Optimistic” estimate
te
56
tp
4tm
6
to
tm = “Most likely” estimate
t p = “Pessimistic” estimate
t e = “Expected” estimate
Non-Project Factors
• Holidays and paid time off
• Vacations
• Off-site meetings
• Other projects and responsibilities
• Equipment downtime
• Scheduled sick leave
57
Calendar Time Estimates
• Calendar time estimates are based on
duration estimates, incorporating non-project
factors.
• Calculations can be automated using project
scheduling tools.
58
Activity Information Database
WBS
Code
Task
Name
Completion
Criteria
Task
Owner
Duration
Estimate
3.2
Write
Software
No testing
errors
Charles
Winchester
15 days
Task information such as this may be documented in a project
scheduling tool, in a spreadsheet, a notebook, or a file cabinet...
59
Develop Initial Schedule
Combine all dependency and activity duration
estimates to assess project workflow.
This bottom-up analysis should be based only on
workflow, not arbitrary date targets.
Formats:
• Network or precedence diagrams emphasize logical
relationships.
• Bar or Gantt diagrams display timing.
60
61
Create Network Diagrams
Initial network diagrams can use sticky notes and
penciled arrows to show the project as sequences
of defined activities and milestones.
3.1
Build
Hardware
10 d
2.3
Design
System
15 d
...
62
2.4
Document
System
5d
2.5
Develop
Test Plan
7d
3.4
Assemble
Prototype
18 d
3.2
Write
Software
8d
...
Create Bar or Gantt Charts
63
Analyze Project Critical Path
(Critical Path Method—CPM)
Start
End
= Critical path task
•
•
•
•
= Non-critical path task
A Critical Path (CP) network path with the longest duration.
Any CP activity slip will delay the project.
To shorten the schedule, you must shorten the CP.
CP focuses management analysis and tracking.
64
Critical Path Analysis
• The project critical path (or paths) is the longest,
and least flexible, path through the network.
• To determine:
• Calculate the early schedule using forward path analysis.
• Calculate the late schedule using backward path
analysis.
• The calculated difference between Late and Early
schedules = Float, or Slack.
• Non-critical tasks have a positive float, showing
flexibility.
• Critical tasks have no (or negative) float.
65
Review Homework
•
•
•
•
66
Mid Term Prep
Reading
Individual Homework
Team Homework