2
10.1 Project Planning
Why Do We Need a Project Plan?




Unique product or service
Guide project execution
Document project planning assumptions
Document planning decisions regarding
alternatives chosen
 Facilitate communication among stakeholders
 Provide baseline for progress measurement and
project control
Software Engineering
Project Planning
Peter Müller
Chair of Programming Methodology
Spring Semester 11
Peter Müller – Software Engineering, SS 11
3
10.1 Project Planning
Aspects of Project Planning
4
10.1 Project Planning
Planning Iterations
Project Management
Scope
Planning
Project Integration
Management
Project Scope
Management
Project Time
Management
Project Cost
Management
Project Quality
Management
Project Human
Resource Management
Project Communications
Management
Project Risk
Management
Project Procurement
Management
Time
Planning
Cost
Planning
Project
Plan
Development
...
Planning
Peter Müller – Software Engineering, SS 11
10.1 Project Planning
Peter Müller – Software Engineering, SS 11
5
10.1 Project Planning
Assumptions
Constraints
 Definition:
Assumptions are factors that, for planning
purposes, are considered to be true, real, or certain
 Assumptions affect all aspects of project planning,
and are part of the progressive elaboration of the
project
 Project teams frequently identify, document, and
validate assumptions as part of their planning
process
 Assumptions generally involve a degree of risk
 Definition:
Constraints are factors that limit the project team’s
options
 A single project may contain cost, time, human
resource, technical, and other constraints
 Examples
Peter Müller – Software Engineering, SS 11
6
- External deadlines (e.g., Y2K, Euro)
- Fixed upper limits for budget
- Dependencies on other projects, etc.
Peter Müller – Software Engineering, SS 11
1
7
10.1 Project Planning
8
10.1 Project Planning
Project Plan Document
Baseline
 A formal, approved document
 A project plan is not just a schedule!
 Contains
 Definition:
The originally approved plan plus or minus
approved changes.
- Project management approach
- Scope, schedule, cost estimates, resources,
responsibilities
- Subsidiary management plans for scope, schedule, cost,
quality, etc.
- Performance measurement baselines for scope,
schedule, and cost
- Open issues and pending decisions
 Baselines are used to compare the actual
performance and forecasts of the project with the
original plan
Peter Müller – Software Engineering, SS 11
Peter Müller – Software Engineering, SS 11
10. Project Planning – Overview
9
10.1 Project Planning – Scope Planning
10
Decomposition of Deliverables
10. Project Planning
Identify the major
deliverables of the
project, including
project management
10.1 Scope Planning
10.2 Scheduling
Adequate
cost and duration
estimates possible at
this level?
Yes
No
Validate decomposition:
• Are items necessary and
sufficient?
• Is each item clearly and
completely defined?
• Can each item be scheduled
and budgeted?
Identify constituent
components of the
deliverable
Peter Müller – Software Engineering, SS 11
Peter Müller – Software Engineering, SS 11
10.1 Project Planning – Scope Planning
11
Decomposition Example 1
10.1 Project Planning – Scope Planning
12
Decomposition Example 2
Product ABC
Analysis
...
Product definition
Product ABC
Deployment
Project Management
Software
Hardware
Training
Software
Project definition
Database
Computers
Materials
Hardware
Project plan
User interface
Network
Training environment
Handbook
Status reports
Business logic
Installation
Functional design
Project Management
Project definition
Project plan
Status reports
Non-functional req.
Status quo
Approval
Peter Müller – Software Engineering, SS 11
Peter Müller – Software Engineering, SS 11
2
10.1 Project Planning – Scope Planning
13
Work Breakdown Structure (WBS)
10.1 Project Planning – Scope Planning
14
WBS Relationships
 Definition:
A deliverable-oriented, hierarchical grouping of
project elements that organizes and defines the
total work scope of the project. Each descending
level represents an increasingly detailed definition
of the project
Status
Reporting
Make-or-Buy
Decisions
Basis for
Change
Management
Basis for
Basis for
Product ABC
Analysis
System
Solution
Basis for
Deployment
Product definition
Consistency
Project
Organization
Project Management
Software
Project definition
Hardware
Project plan
Handbook
Status reports
Basis for
Plans,
Reviews
Basis for
Basis for
Schedule
Estimations
Peter Müller – Software Engineering, SS 11
Peter Müller – Software Engineering, SS 11
10. Project Planning – Overview
15
10.2 Project Planning – Scheduling
10. Project Planning
Purpose of Scheduling
10.1 Scope Planning
10.2 Scheduling
 Track the progress of the project
 Determine how possible changes might affect the
project
 Communication
16
- Will the activities be completed in time?
- When are which resources needed?
- When will major milestones be reached?
Peter Müller – Software Engineering, SS 11
Peter Müller – Software Engineering, SS 11
10.2 Project Planning – Scheduling
17
Activities
18
Milestones
Appartment Renovation
Kitchen
10.2 Project Planning – Scheduling
Bathroom
Workroom
Sleeping room
Remove carpeting
Clean room
Serve food
Refurnish
Remove furniture
Paint
Paint walls (1)
 Definition:
A significant event in the project, usually completion
of a major deliverable
 Milestones have no effort or duration
 Milestones do not have resources
Paint walls (2)
Paint ceiling
Lay parquet
 Example: Painting completed
 Rule of thumb: 40 to 80 person hours per activity
Peter Müller – Software Engineering, SS 11
Peter Müller – Software Engineering, SS 11
3
10.2 Project Planning – Scheduling
19
10.2 Project Planning – Scheduling
20
Dependencies
Lag and Lead
 Logical relationships among activities
 Modify a logical relationship to direct a delay
or acceleration of the successor task
 No modifier
- Finish-to-Start (FS)
- Start-to-Start (SS)
Time
- Finish-to-Finish (FF)
 Lag (+3 units)
- Start-to-Finish (SF)
Time
 Lead (-2 units)
 Dependencies can be mandatory (hard logic)
discretionary (soft logic), or external
Time
Peter Müller – Software Engineering, SS 11
Peter Müller – Software Engineering, SS 11
10.2 Project Planning – Scheduling
21
Network Diagrams
10.2 Project Planning – Scheduling
22
Network Example
 Precedence Diagramming Method
START
- Show all activities (depicted by boxes)
- Show the logical flow (depicted by arrows)
- Clearly illustrate dependencies
Serve
food
 Rules
Remove
furniture
- Each activity has at least one predecessor and
successor (start and end as milestones)
- No loops, no dangling arrows
Remove
carpet
-1
+24
Paint
walls (1)
 Other network diagramming methods
- Arrow diagramming method (activity-on-arrow)
- Conditional diagramming methods
Lay
parquet
Refurnish
Paint
walls (2)
Paint
ceiling
Peter Müller – Software Engineering, SS 11
END
Clean
room
Painting
completed
Peter Müller – Software Engineering, SS 11
10.2 Project Planning – Scheduling
23
10.2 Project Planning – Scheduling
Computing a Schedule
Forward Pass
 A schedule consists of the planned dates
for all activities and milestones
 Notation
 Determines overall project duration
 First activity starts on time unit 0
 Calculation of the early start and early finish dates
Early
Start
ES
EF
Early
Finish
Activity
LS
Late
Start
Peter Müller – Software Engineering, SS 11
D
Duration
24
 For Activity A:
ES(A) = MAX P  predecessors(A) ESP(A)
EF(A) = ES(A) + Duration(A)
LF
Late
Finish
Peter Müller – Software Engineering, SS 11
4
10.2 Project Planning – Scheduling
25
Calculating Early Start
ES
EF
Activity
LS
D
L
ES’
EF’
ES
Activity’
LS
D
LF
EF
Activity
LS
D
ES’
EF’
--
D
0
LS’ D’ LF’
LF
4
8
3
3
SF-relation:
ES’ := ES + L – D’
Peter Müller – Software Engineering, SS 11
27
Backward Pass
LS
11
8
0
D
L
4
-1
40
43
Paint
walls (1)
3
12 15
3
39
+24
40
75
8
51
Peter Müller – Software Engineering, SS 11
LS
D
LF
EF
D
EF’
Activity’
LS’ D’ LF’
SS-relation:
LF := LS’ – L + D
EF
Activity
L
ES’
LF
ES’
LS
EF’
D
LF
ES’
EF’
Activity’
LS’ D’ LF’
L
LS’ D’ LF’
FF-relation:
LF := LF’ – L
51
--
END
75
67
0
--
75
SF-relation:
LF := LF’ – L + D
10.2 Project Planning – Scheduling
30
67
8
51
75
67
Lay
parquet
51
51 16 67
51
51
Painting
completed
51
0
51
67
75
Refurnish
67
8
75
28.11.
17.11.
17.11.
-- 0 0
START
-- 0 0
17.11.
Clean
room
39 12 51
11
43
8
Paint
walls (2)
Paint
ceiling
EF
Activity
Network Diagrams with Dates
12
Remove
carpet
15
ES
Activity’
40
4
4
EF’
Activity’
LS’ D’ LF’
LF
Activity
LS
Serve food
3
ES’
ES
29
0
0
28
Peter Müller – Software Engineering, SS 11
0
Remove
furniture
51
Painting
completed
EF
ES
Backward Pass Example
4
8
51
FS-relation:
LF := LS’ – L
10.2 Project Planning – Scheduling
0
16
L
Peter Müller – Software Engineering, SS 11
0
75
Refurnish
Paint
ceiling
Activity
- early  late, start  finish, +  -, primed  unprimed
0
67
12
 The logic is “inverted”
--
Paint
walls (2)
67
Lay
parquet
10.2 Project Planning – Scheduling
ES
 For Activity A:
LF(A) = MIN P  successors(A) LFP(A)
LS(A) = LF(A) - Duration(A)
0
51
Calculating Late Finish
 Determines latest possible dates for each
activity that do not delay the overall project
 Last activity ends at time unit of project duration
 Calculation of the late start and late finish dates
START
8
Peter Müller – Software Engineering, SS 11
10.2 Project Planning – Scheduling
--
+24
--
75
Clean
room
51
39
12
LS’ D’ LF’
FF-relation:
ES’ := EF + L – D’
15
Paint
walls (1)
EF’
LS’ D’ LF’
L
0
67
4
--
END
12
Remove
carpet
Activity’
Activity’
4
Remove
furniture
-1
ES’
75
40
40
0
EF
LS
EF’
0
Serve food
Activity’
Activity
L
LF
ES’
SS-relation:
ES’ := ES + L
ES
0
START
L
ES
--
EF
Activity
FS-relation:
ES’ := EF + L
26
Forward Pass Example
LS’ D’ LF’
LF
10.2 Project Planning – Scheduling
17.11.
17.11.
0 0 4
Remove
furniture
0 4 4
-1
17.11.
18.11.
4 49 12
Remove
carpet
43 8 51
18.11.
3
0 15
Paint
+24
walls (1)
3 12 15
17.11.
21.11.
0 0 40
Serve food
0 40 40
21.11.
39
25.11.
0 51
Paint
walls (2)
39 12 51
18.11.
3
55 11
Paint
ceiling
43 8 51
75
75
27.11.
0 -END
0 --
28.11.
67
0 75
Clean
room
67 8 75
25.11.
27.11.
51
0 67
Lay
parquet
51 16 67
25.11.
27.11.
67
28.11.
0
75
Refurnish
67
8
75
25.11.
51 0 51
Painting
completed
51 0 51
Peter Müller – Software Engineering, SS 11
5
10.2 Project Planning – Scheduling
31
Bar (Gantt) Charts
10.2 Project Planning – Scheduling
32
Milestone Charts
Serve food
Current Date
Rem. Furn.
Rem. Carpet
Milestone 17.11. 18.11. 19.11. 20.11. 21.11. 22.11. 23.11. 24.11. 25.11. 26.11. 27.11. 28.11.
Wall 1
START
Paint
Wall 2
Painitng
completed
Ceiling
Parquet
END
Refurnish
Clean room
17.11.
19.11.
21.11.
23.11.
25.11.
Planned
27.11.
Actual
Time
Peter Müller – Software Engineering, SS 11
10.2 Project Planning – Scheduling
Peter Müller – Software Engineering, SS 11
33
10.2 Project Planning – Scheduling
34
Diagramming Methods
Analyzing a Schedule
 Network diagrams





- Show dependencies and workflow
- Purpose: planning
 Gantt charts
- Show dates and durations
- Purpose: reporting and progress tracking
Identify schedule risks
Determine if deliverables will be made on time
Check resource usage
Find potentials for compressing the schedule
Consistency
 Milestone charts
- Show major events
- Purpose: reporting to management and customer
Peter Müller – Software Engineering, SS 11
10.2 Project Planning – Scheduling
Float
 Definition:
The amount of time that an activity may be delayed
from its early start without delaying the project
finish date
 Float = LF – EF = LS – ES
 Interpretation
- Float > 0: Time is available
- Float = 0: Situation is critical
- Float < 0: Project is behind
 Sometimes called Total Float, Slack, or Total Slack
Peter Müller – Software Engineering, SS 11
35
10.2 Project Planning – Scheduling
--
0
0
0
START
--
0
0
0
0
4
4
Remove
furniture
0
4
-1
0
40
40
4
0
15
Paint
walls (1)
3
12 15
3
+24
43
8
51
39
0
51
Paint
walls (2)
75
67
0
--
75
0
Clean
room
67
8
75
51
0
67
Lay
parquet
51 16 67
67
0
75
Refurnish
67
8
75
39 12 51
40 11
Paint
ceiling
8
--
0
END
39 12
Remove
carpet
3
75
40
Serve food
0
43
Peter Müller – Software Engineering, SS 11
36
Float Example
51
51
0
51
Painting
completed
51
0
51
Peter Müller – Software Engineering, SS 11
6
10.2 Project Planning – Scheduling
37
Critical Path
10.2 Project Planning – Scheduling
38
Critical Path Example
--
 Definition:
The series of activities that determines the duration
of the project (the longest path through the
network)
 Sum of float on critical path is zero (or negative)
 Critical path is important
0
0
0
START
-0
0
0
0
4
Remove
furniture
0
4
-1
4
3
0
3
15
+24
12 15
3
0
40
4
39 12
40
43
8
51
39
0
51
Paint
walls (2)
40 11
43
Peter Müller – Software Engineering, SS 11
8
75
67
67
8
75
51
0
67
Lay
parquet
51
0
51
51
0
39
0
4
0
6
15
15
Paint
walls (1)
-1
3
9
75
67
8
75
51
10.2 Project Planning – Scheduling
40
 Fast tracking to shorten critical path
4
0
51
 Definition:
The amount of time that an activity can be delayed
without delaying the early start of any immediately
following activity
Free Float
15-15=0
 Free Float = ES’ – EF – L
0
67
Painting
completed
Schedule Compression
Remove
furniture
--
Refurnish
51 16 67
Free Float
0
0
75
0
Clean
room
Peter Müller – Software Engineering, SS 11
10.2 Project Planning – Scheduling
3
--
0
END
39 12 51
Paint
ceiling
 There can be several critical paths in a project
75
40
Remove
carpet
Paint
walls (1)
- To shorten project duration
- To focus progress control
- To identify schedule risks
0
Serve food
6
27
Paint
walls (2)
12 21
3
21 12 33
55
0 33
Paint
ceiling
4
3
- Do activities in parallel instead of in sequence
- Problem: increases risk
 Crashing the network
- Add resources to the critical path (e.g., from non-critical
activities)
- Problem: Law of diminishing returns
Free Float
33-27=6
33
0
 Increasing productivity by different technology
 Extended hours and weekends should not be
considered during planning
33
Painting
completed
33
0
33
- You will need them during project execution anyway
30 33
Peter Müller – Software Engineering, SS 11
10.2 Project Planning – Scheduling
Resource Leveling
Peter Müller – Software Engineering, SS 11
41
10.2 Project Planning – Scheduling
 Common results of critical path method
- More resources required than available
- Changes of resource levels are not manageable
 Analysis: Resource histograms
 Heuristic: Resource-based method
42
Consistency
Staff skills
Required
roles for task
Staff
availability
Network
diagram
Task
estimates
- Allocate scarce resources to critical path first
 Resource leveling usually leads to longer project
duration
Peter Müller – Software Engineering, SS 11
Peter Müller – Software Engineering, SS 11
7
43
10. Project Planning
Main Planning Processes
Time
Time
Time
Activity
Definition
Activity
Sequencing
Schedule
Development
Scope
Cost
Activity
Duration Est.
Scope
Definition
Resource
Planning
Cost
Cost
Cost
Estimating
Cost
Budgeting
Risk
Integration
Risk Mgmt.
Planning
Project Plan
Development
Time
Peter Müller – Software Engineering, SS 11
8