Software Project
Management
Estimation and scheduling
INFO 638
Glenn Booker
INFO 638
Lecture #3
1
After the WBS
 Once the rough scope of tasks has
been defined in the WBS, we need
to estimate each task in terms of
duration and effort
 From effort we’ll get the cost of each
task, and eventually the project
 After estimation, can start to organize
the project schedule
INFO 638
Lecture #3
2
Welcome to Estimation!
 This is often the most challenging
part of project management
 Most don’t want to admit what their
methods are for estimating work – it’s
just a WAG (wild approximate guess )
 Estimation is the basis for creating a
plausible schedule
 Need to estimate the duration and effort
of each task
INFO 638
Lecture #3
3
Duration versus Effort
 Duration, or time for a task, is the
amount of calendar time needed to
accomplish it
 Effort is the number of working hours
(or months or years) needed for a
task or project
 One week of effort is 40 hours,
one month of effort is about 168 hours
 May have units of staff-months, peoplemonths, labor-months or man-months
INFO 638
Lecture #3
4
Average Staffing
 An easy measure of a project is the
average number of people working on
it – equal to the effort divided by time
 Ave staffing = effort / time
 A project might take 9 months (duration)
and 12,000 hours (effort)
 Ave staffing=(12,000 hrs / (168 hrs/mo))/
9 months
= 7.9 people
INFO 638
Lecture #3
5
Why Average Staffing?
 Most software projects require few
people in the beginning, peak in the
middle of the project, and taper off
later on as testing is completed
Staff
Ave Staffing
Time
INFO 638
Lecture #3
6
Resource Loading
 Resource Loading is the number of
people assigned to a task
 Some tasks can be completed sooner
if more people work on them
 Sweatshops of people sewing shirts
will produce more if there are more
employees
 Other tasks might take longer, if tasks
are dependent upon each other
INFO 638
Lecture #3
7
Task Duration Varies
 How long does it take to drive from
Philly to Baltimore?
 Depends on how fast you drive, what
route you take, traffic, weather, how
much construction there is, etc.
 Development tasks will vary in
duration from one person to another
depending on their skill level,
motivation, outside influences, etc.
INFO 638
Lecture #3
8
Creating a Good Estimate
 There are six techniques for
estimating the duration and
effort of a task






INFO 638
Similar activities
Historical data
Expert advice
Delphi technique
Three-point technique
Wide-band Delphi technique
Lecture #3
9
Similar activities
 This just means estimate a task
based on similar tasks in the past
 If you’ve developed lots of web pages,
you can safely estimate how long it’ll
take to develop similar pages
 A common rule of thumb is to
 Take the time it’d take you to do a task,
double it, and add 10-20%
INFO 638
Lecture #3
10
Historical data
 If you can find data from similar
projects developed by your
organization, they can form the
basis for a good estimate
 This assumes the project uses similar
technology as previous projects
 This is why big new projects want to
see experience developing similar big
projects – to lend credence to your
estimates
INFO 638
Lecture #3
11
Expert advice
 If you don’t know anything about the
task, ask someone who does!
 Could find experts within your
organization, outside consultants,
vendors, academia, etc.
 Notice the first three estimation
methods depend on someone having
experience doing the task before
INFO 638
Lecture #3
12
Delphi technique
 The Delphi technique is a formal way
to get group consensus on a wild
guess for the estimate
1. Get a group of people together
2. Tell them about the project and its
tasks
3. Get them to all estimate the duration
of each task
INFO 638
Lecture #3
13
Delphi technique
4. Tabulate the guesses in a histogram
called First Pass
5. For estimates in the outer quartile
(<25% and >75%), ask them for
their rationale
6. Have everyone guess again, and
retabulate the results: Second Pass
7. Have the outer quartile defend their
choices again
INFO 638
Lecture #3
14
Delphi technique
8. Make a third set of guesses, and use
the average value for the task’s
estimate
 Though it sounds a bit goofy, this
method actually works pretty well
INFO 638
Lecture #3
15
Three-point technique
 The actual duration of a task could
vary, depending on many factors
 Hence there could be a distribution of
possible values for the duration
 Based on best judgment, determine
the Optimistic, Most likely, and
Pessimistic values for the duration,
then use Estimate = (O+ 4*M+ P)/6
INFO 638
Lecture #3
16
Wide-band Delphi technique
 Combine the three point technique
and Delphi to get the Wide-band
Delphi technique
 In each of the three Passes (sets of
guesses), have each person estimate
the Optimistic, Most likely, and
Pessimistic values
 Use results from the third Pass and
apply the three point formula
INFO 638
Lecture #3
17
Estimation Accuracy
 Keep in mind that early estimates of a
project could be off by a factor of four
either way from the final effort
(McConnell, Rapid Development), so don’t treat
the estimates as perfectly precise
 Expect that estimation accuracy will
improve throughout the project
INFO 638
Lecture #3
18
Estimating Resources
 While ‘resources’ often refers to
people on a project, it may refer to





INFO 638
People
Facilities
Equipment
Money
Materials
Lecture #3
19
People Resources
 People on a project are generally
identified by their skills
 Systems analyst, web developer,
programmer, system administrator,
database admin, etc.
 For each activity or task, determine
the skills needed to perform it
 Your staff has a known set of skills
 Then match up activities to staff (p. 107)
INFO 638
Lecture #3
20
Facilities Resources
 Part of planning a project is to
consider where the people will
be working
 Might be able to use existing facilities
 Large or long term projects may
require leasing new facilities
 Need to decide where to put them
 Beware of communication lag
between facilities
INFO 638
Lecture #3
21
Equipment Resources
 Some kinds of activities may require
special equipment to perform them
 This isn’t the material needed to create
the product – equipment refers to
anything needed to fabricate or test
components of the product
 Automated testing is the most
common equipment need for software
INFO 638
Lecture #3
22
Money Resources
 Above and beyond the other
resources, money may be
needed for other expenses
 Service contracts for non-project
equipment
 Travel expenses
 Office supplies
 Other overhead expenses not
covered directly by the project
INFO 638
Lecture #3
23
Materials Resources
 Material costs include the cost of
parts that become part of the
completed product
 This might include various kinds of
servers and network equipment,
software licensing, printers, etc.
 This is often the biggest resource
after labor
INFO 638
Lecture #3
24
Organization Chart
 Since we need to define the types of
staff needed to perform each task,
this feeds into developing the
organization chart of the project
 The roles needed for performing tasks
should all appear on the org chart
 It’s called a Resource Breakdown
Structure in the text (p. 108)
INFO 638
Lecture #3
25
Assigning People to Tasks
 Keep in mind that the number of
people assigned to a task might be a
fraction, or greater than one
 Hence the duration and effort could
be quite different
 A low demand task might be assigned to
a tenth of a person, so a 20-day duration
would only have 2 days of effort
INFO 638
Lecture #3
26
Cost Estimation
 Cost is easy to estimate once effort
has been determined and assigned to
specific roles
 For labor cost, just multiply effort by
the labor rate for that role
 A senior programmer might cost $90/hr,
so a 10-hour task would cost $900
INFO 638
Lecture #3
27
$90/hr = $187,200/year?!
 Does that labor rate mean the
programmer makes $187.2k/year?
 No, the labor rate also includes
overhead expenses
 Taxes, vacation, sick leave, health
coverage, etc. all contribute to overhead
 Pay for managers is often from overhead
 Depending on the organization, one’s
salary is about 35-50% of the labor rate
INFO 638
Lecture #3
28
Resource Planning
 Now the real challenge of planning
occurs
 Need to take the project’s needs for
people and other resources, and
make sure it’s feasible
 Need to avoid committing a given person
for multiple tasks at once, or scheduling
two activities in the same facility on
one day
INFO 638
Lecture #3
29
Resource Planning
 Another key is to do load balancing
 Avoid having gaps in a person’s
schedule
 If you need Pat to run tests in July
and September, what’s she going to
do in August?
 Also want to avoid large spikes in
staffing needs
 Implies a lot of people hired only briefly
INFO 638
Lecture #3
30
Cost Control
 The costs for the project consist of
cost for all of the resources needed
 To manage cost, need to get weekly
reports of costs incurred, and compare
to the plan
 Variances are the difference between the
actual and planned costs
INFO 638
Lecture #3
31
Project Network Diagram
 Now that the tasks and activities have
been resourced (is that a word?), we
can put them in order
 Need to determine dependencies
among the tasks
 Which are sequential? Parallel?
 Which tasks must finish together?
Start together?
INFO 638
Lecture #3
32
Project Network Diagram
 The goals of the Project Network
Diagram are to help identify key
characteristics of tasks, and the
project as a whole
 When can each task start, at earliest?
 When can we expect completion of
the project?
INFO 638
Lecture #3
33
Gantt Chart
 Editorial note: the text hates Gantt
charts (p. 119) – whereas most
projects I’ve seen rely on them
 Take your pick whether to use them
or not
INFO 638
Lecture #3
34
Gantt Chart
 Identify major tasks, based on life
cycle model and project needs
 Determine size and schedule
estimates for each major task
 Identify sequential or parallel tasks,
ongoing activities, and task
dependencies
INFO 638
Lecture #3
35
Gantt Chart
 Identify milestones and work
products wherever possible
(decisions, documents, baselines)
 Assign WBS to tasks
 Determine timeline scales needed
INFO 638
Lecture #3
36
Timelines
 Timelines for a schedule may follow
either a calendar schedule, or a
relative schedule
 Calendar schedule is broken into
absolute time intervals based on actual
time (e.g. Feb. 2004)
 May use a second or third calendar scale
of larger intervals (quarters, years)
 Calendar (CY) or fiscal (FY) years may
be used
INFO 638
Lecture #3
37
Timelines
 Relative schedule is measured from the
start of the project - or some other key
event - then uses time intervals counted
from that event (e.g. Month 2 after grant
received)
INFO 638
Lecture #3
38
Gantt Chart
 Label each activity with its WBS and
task name, followed by a bar to
represent its duration on the timeline
 Milestones are generally a diamond
symbol ◊
 Used for key decisions
 Symbol format not critical, as long
as it’s clear and consistent
INFO 638
Lecture #3
39
Gantt Chart
ID
1
Task Name
1.0 Requirements Definition
Duration
10 days
Predecessors
2
2.0 Architectural Design
10 days
1
3
3.0 Detailed Design
20 days
2
4
4.0 Coding and Unit Testing
45 days
3
5
4.1 Coding
25 days
6
4.2 Unit Testing
20 days
5
7
5.0 Integration Testing
15 days
6
8
6.0 System Testing
10 days
7
INFO 638
2nd Quarter
Apr
May
Jun
Lecture #3
3rd Quarter
Jul
Aug
Sep
4th Quarter
Oct
Nov
Dec
1st Quarte
Jan
40
Network Diagrams
 Historic note: early network diagrams
(and some forms of PERT chart) used
the lines between nodes to represent
tasks
 This is called activity on the arrow (AOA)
Node
10
INFO 638
Task 3.2,
5 days
Lecture #3
Node
20
41
Network Diagrams
 Now we use boxes to represent each
task; and the lines between them
imply their relationship
 Here, task 3.2 may start after 3.1
finishes, a finish-to-start (FS)
dependency (very common)
Task 3.1
3 days
INFO 638
Task 3.2
5 days
Lecture #3
42
Network Diagrams
 The other dependencies are
 When task A finishes, task B may finish
(FF)
A
B
 When A starts, B may start (SS)
A
B
 When A starts, B may finish (SF)
A
INFO 638
B
Lecture #3
43
Other Constraints
 Other constraints may affect the
relationship between tasks
 Technical constraints, such as the way a
task may need output from a previous
task before they may begin
 Management constraints, such as to
meet competitive pressure, or get things
done before a major event (holiday,
conference, etc.)
INFO 638
Lecture #3
44
Other Constraints
 Interproject constraints, such as the
need for a related project to finish their
side of an interface before yours can be
fully tested
 Date constraints, where a specific event
guides an activity, such as needing a
task done no earlier than, no later than,
or on a specific day
INFO 638
Lecture #3
45
Lag
 Lag can be used to specify delay
between events
 Customer surveys are distributed 30
days after product release – that’s a 30
day lag in the distribution task
 Lag can be positive or negative
INFO 638
Lecture #3
46
Creating the Schedule
 These concepts allow the schedule to
be created
 For every task, determine its relationship
to some other task, and lag (if any)
 The early schedule gives the earliest
times each task may start and finish
 This defines the earliest start (ES) and
earliest finish (EF) date for each task
INFO 638
Lecture #3
47
Creating the Schedule
 Conversely, the late schedule gives
the latest start and finish times –
without changing the completion date
 This defines the latest start (LS) and
latest finish (LF) date for each task
INFO 638
Lecture #3
48
Critical Path
 A key output is the critical path,
which can be defined as
 The longest duration path in the network
diagram, or
 The series of tasks whose early and late
schedules are the same dates, or
 The set of activities with zero slack
INFO 638
Lecture #3
49
Slack?
 Slack (or float) is the amount of delay
in starting or completing a task that
can be tolerated without affecting
some other task
 Specifically, free slack is the time a task
can finish without affecting the early
schedule of anything after it
 Total slack is how much completion of a
task can be delayed without affecting the
project completion date
INFO 638
Lecture #3
50
Detailed Task Estimate
 If we define not just the time
Estimate (E) of each task, but also
compute the earliest start and finish
(ES, EF) and latest start and finish
(LS, LF) and slack time, task name
“ID” looks like
ES
EF
ID
LS
INFO 638
Lecture #3
Slack
E
LF
51
Editorial Comment
 Most projects are doing well to come
up with a plausible estimate (E) for
each task – they aren’t going to
determine ES, EF, LS, LF, and slack
time for every task too!!
INFO 638
Lecture #3
52
Schedule Compression
 Often you need to shrink the
projected completion date
 Look for tasks which can be done
simultaneously instead of sequentially
 Look for tasks which may begin when
part of a previous task is done (instead
of all of that task)
 Focus on critical path and near-critical
path tasks
INFO 638
Lecture #3
53
Schedule Compression
 Look for tasks that can be assigned to
more than one person (partitionable)
 Look for possible changes to task
dependencies (beware of added risk)
 SF to SS, for example
INFO 638
Lecture #3
54
Management Reserve
 At the project level, try to keep a
little reserve of time (padding) to
allow for likely schedule slips
 Don’t do this on individual tasks – tends
to bloat the schedule
 5-10% is a good schedule reserve
 So a 6-month project might try to finish
6-13 work days early
 6 months = 26 weeks = 130 work days
INFO 638
Lecture #3
55