1-2

Why Planning Fails

Recall the shocking statistics

◼ 64% of features included in products are

rarely or never used.
◼ 66% of projects significantly overrun their
cost estimates.
◼ The average project exceeds its schedule
by 100%.
Outline
◼ Why traditional planning methods fail:
 Planning by activity rather than feature
 Multitasking
 Developing features out of priority
 Ignoring uncertainty
 Estimates become commitments
1. Planning by activity rather than feature

◼ Traditionally, progress is measured in

activities completed, not features
◼ Disadvantages:
 Progress reports are of no value to the
customer because features are their unit of
understanding
 When the project overruns its schedule,
teams reduce quality / constrain valuable
changes
1. Planning by activity rather than feature

◼ Activity-based planning also leads to

schedule overruns because:
 A) Activities don’t finish early
 B) Lateness is passed down the schedule
 C) Activities are not independent
1A. Activities don’t finish early

◼ Parkinson’s Law:
 Work expands so as to fill the time available
for its completion
◼ Programmer may gold-plate or fill the time
with other activities to avoid a future
expectation/explanation
1B. Lateness is passed down the schedule

◼ Activities are strongly dependent

Example of compounded delay
◼ Suppose you can’t order a certain
hardware until your developer is finished
with her activity
◼ When she finishes, and you order, there’s
an out-of-stock delay at the company
◼ Result=one activity from one person
delays the project several days already
1C. Activities are not independent

◼ Activities are independent if the duration of

one does not affect the duration of another
◼ Software activities are not independent.
◼ When an activity takes longer than
planned, all similar activities are likely to
take longer
 Furniture move vs. Painting walls
Example of activity dependency
◼ If developing a UI screen and the first one
takes a day longer than planned then all
others will too
 “I’ll make it up next time” is unrealistic
2. Multitasking

◼ Multitasking is simultaneously working on

multiple tasks
Comments on the graph

◼ Multitasking causes further delays

◼ When you have 2 tasks, if you’re stuck on
one you can switch to the other
◼ Working on 3 or more tasks concurs a
high cost switching between them
2. Multitasking & dependent activities

◼ Work (the database and API) finish later than

planned, which will ripple through the project
◼ Work remains in process longer (20 days vs. 10)
◼ Plus, we still need to add overhead time
2. Multitasking

◼ In traditional planning, multitasking is

further compounded by the facts that:
 Work is assigned to individuals not groups,
and is assigned early on; thus is not
efficiently allocated
 Multitasking focuses on 100% utilization of
individuals
Outline revisited…

◼ Why traditional planning methods fail:

 Planningby activity rather than feature, which delays
us because:
◼ Activities don’t finish early
◼ Lateness is passed down the schedule
◼ Activities are not independent
 Multitasking
 Developing features out of priority
 Ignoring uncertainty
 Making estimates into commitments
3. Features are not developed by priority

◼ We assume we will complete all tasks so

we arrange them according to
developmental convenience
◼ Then, when the schedule is overrun, we
are sometimes forced to drop high value
features or reduce quality
4. We ignore uncertainty

◼ We assume
 the initial requirement specification led to a
perfect product specification
 users wont refine their opinions or come up
with new ideas
 we haven’t forgotten any activities at the start
of the project
Change in traditional planning
◼ In fact, change during a project is not
encouraged in traditional plans
 “New requirements should not be allowed under any
circumstances. New requirements should be
considered a new project”
 “The customer should be involved at the front of the
project and testing time and not during the project”
 “Often you should deny the change request”
Phase planning
◼ When the preliminary phases take so long
and are done during the uncertainty stage,
we may lag behind technological
advances
◼ Example:
 Thick-clients were hot when you planned, now
thin-clients are in
 100Base-T connections were usual, now
Gigabit Ethernet is expected
5. Estimates become commitments

◼ An estimate is only a probability between

0%(1 week) and 100%(10 years)
◼ A commitment cannot be made to a
probability
◼ Our estimate should progress from
 We’ll be done in the 2nd quarter
 We’ll be done in May
 We’ll be done May 9th
Conclusion: (1) Test your understanding

◼ List two reasons why traditional planning

fails
 Planning by activity rather than feature
 Multitasking
 Developing features out of priority
 We ignore uncertainty
 Estimates become commitments
Conclusion: (2) Test your understanding

◼ With and without multitasking the three

tasks take 30 days in total. So where’s the
problem?
 Conclusion: (3) Test your understanding

◼ Why is it disadvantageous to plan by

activity rather than feature?
Disadvantages:
• Progress reports are of no value to the customer because features are their
unit of understanding
• When the project overruns its schedule, teams reduce quality / constrain
valuable changes
• leads to schedule overruns because:
A) Activities don’t finish early
B) Lateness is passed down the schedule
C) Activities are not independent