Predicting the Future

1
Predicting the Future

• Project Scheduling
• Tools Techniques

Duane Webb, BioWare Corp.
2
Topics Discussed

• Scheduling Concepts
• Predictability
• Early Project Techniques
• Estimating Techniques
• Contingency Planning
• Managing to your Schedule

3
What is a Schedule for?

• Predicts a completion date
• Creates a picture of the entire project
• Breaks the work down into components
• Tool to track progress

4
Why do schedules fail?

• Poor estimates
• Missed or unclear requirements
• Scope changes
• Staffing issues
• Stakeholder pressure
• Poor productivity
• Inexperienced project management
• and much more

5
What makes a good schedule?

• PERT / CPM ?
• Monte Carlo simulation techniques?
• Earned Value assessments?
• PMP Certified Project Managers?
• Better estimation techniques?
• More up-front planning?
• Better specifications?

6
What makes a good schedule?

• Good management
• Experience
• Team Leads, Producers, Project Managers,
  Developers, etc.
• Historical Data
• Flexibility, Adaptability, Realism
• Understanding the trade-offs on a project

7
Project Triangle
Scope
What about Quality?
Resources
Time
8
Project Fulcrum
Balance
Scope
Time
Quality
Resources
9
Project Fulcrum
Maintain Balance
Scope
Time
Quality
Resources
10
Plan for Change

• Change is inevitable
• Scope will increase
• Requirements will be missed or forgotten
• Accept it and be prepared to adapt!

11
Topics Discussed

• Scheduling Concepts
• Predictability
• Early Project Techniques
• Estimating Techniques
• Contingency Planning
• Managing to your Schedule

12
Precision vs. Accuracy

• During initial planning, there are hundreds of
  decisions, issues and challenges which are yet to
  be made.
• An impressive-looking schedule with specific
  dates (precision) isnt close to reflecting
  reality (accuracy).
• Precision is easy, Accuracy is difficult!

• The Art of Project Management by Scott Berkun

13
Sample Schedules
14
Sample Schedules
15
Why make a schedule?

• Planning process helps identify risks, issues and
  requirements
• An inaccurate schedule still provides value
• Forecast for completion
• Provides a roadmap
• Management tool

16
Schedule Probability

• Schedules need to be good enough for the team
  and the leaders to believe in,
• provide a basis for tracking and making
  adjustments,
• and have a probability of success!

• The Art of Project Management by Scott Berkun

The Art of Project Management, by Scott Berkun
17
A day lost at the beginning of a project hurts
just as much as a day lost at the end.

• The Deadline by Tom DeMarco

18
Topics Discussed

• Scheduling Concepts
• Predictability
• Early Project Techniques
• Estimating Techniques
• Contingency Planning
• Managing to your Schedule

19
Early Project Scheduling

• You need to provide a long-term view of your
  project
• For executive producers, publishers and investors
• You need to provide a high probability of
  success, but do not assume accuracy.
• Be realistic!

20
Predict the future based on past

• Size every project, past and present
• Use common characteristics of the work
• Models, poly counts, size of levels, etc.
• Collect historical data to derive productivity
  trends from past projects
• post-mortems
• payroll data man-months
• Crunch time will NOT be included in this data!
• determine the size characteristics of your past
  projects

21
Early Project Scheduling

• Use the past to predict the future
• Estimate the size of your new project
• Compare relatively to past projects
• Factor in technology changes, engine maturity,
  available training resources
• Track the data on all new projects!

22
Early Project Scheduling

• Use your Typical project template
• Define your Typical project milestones
• Work backwards from release
• Identify differences for this project
• Create a staffing plan and establish your cost
  budget

23
Determine your Typical project
24
Determine your Typical project
25
Determine your Typical project
26
Example of a Staffing Plan
27
Topics Discussed

• Scheduling Concepts
• Predictability
• Early Project Techniques
• Estimating Techniques
• Contingency Planning
• Managing to your Schedule

28
Prototyping and Pre-production

• Address the highest risk features and unknowns on
  the project first
• Shakedown the pipeline and measure
• Measure the time to create assets and get them
  into the game
• Provides valuable data for your schedule!
• This is when most of the work is done in creating
  a schedule with a higher probability of success!

29
Estimating effort

• Estimates are inaccurate be realistic
• Putting a lot of effort into estimating does not
  always result in more accuracy
• Experienced developers should be part of the
  process

30
Estimate Convergence Graph
Check this ? Rapid Development, Steve McConnell
31
Estimating Techniques

• 5-4-3-2-1 Method
• Planning Poker
• Developer Estimates in detail

32
5-4-3-2-1 Estimating
Size Factor Effort in days
Very Small (gt 1 hour) 1
Small (gt 1 day) X5 5
Medium (gt 5 days) X4 20
Large (gt 20 days) X3 60
Very Large (gt 60 days) X2 120
Measures high level feasibility, In the
ballpark LOD 120d Dont know, should work
to break this down
33
5-4-3-2-1 Estimating

• Provides quick, high level, long term scoping
• Can be done individually (then distribute)
• Estimate the size of the task, not days
• Should include QA time for acceptance tests
• Compare relative sizes with other tasks
• Then take a second pass through once you are
  complete.

34
Planning Poker

• Agile Development method
• Includes the customer
• Includes a number of developers
• Uses cards numbered
• 1, 2, 3, 5, 8, 13, 20, 40, 100
• Numbers represent relative size, not days

• Agile Estimating and Planning by Mike Cohn

35
Planning Poker Process

• Select a User Story (feature)
• Group discussion on how it should be implemented,
  customer answers questions
• Moderator limits the discussion
• Group selects a card representing estimate
• All cards shown at same time
• Discuss reasoning of high and low estimators
• Redo card estimates again
• Estimates will converge on a number

36
Planning Poker works

• Multiple expert opinions involved
• Discussion brings up missing information and
  reduces the uncertainty and variability
• Jr. staff learn from hearing Sr. staff
  explanations
• Feeds into group accountability
• Minimizes the time spent in estimation phase
• Its fun!

• Agile Estimating and Planning by Mike Cohn

37
Developer Estimates

• Expert Opinions
• Utilize your most experienced staff to either
  create or review the estimates
• Utilize proven time measured estimates
• Test out a process and measure the time it takes
  to complete a task
• Are they including QA time? Integration time?
  Polish phase?

38
Caution Developer Estimates

• Every developer will estimate differently
• You have to agree on the primary unit of time
• Developer says 5 days
• Ideal days - 40 hours uninterrupted?
• 5 days, with normal interruptions
• OR bigger than a bread box estimate

39
There are infinitely many ways to lose a day...
but not even one way to get one back.

• The Deadline by Tom DeMarco

40
Topics Discussed

• Scheduling Concepts
• Predictability
• Early Project Techniques
• Estimating Techniques
• Contingency Planning
• Managing to your Schedule

41
Contingency Planning

• Combination of risk, confidence level,
  efficiency, scope change, etc.
• Hard to sell 30-40 contingency to management
• Contingency time in your schedule is for Project
  Manager, NOT the developer.
• Have the developer stick to their original
  estimates
• Parkinsons Law Work expands to fill the time
  available for its completion.

42
Contingency Confidence Level

• Apply a confidence level to the estimate
• High, Medium, Low
• 5-4-3-2-1 System does this
• Planning Poker utilizes group discussion
• Do you have experience developing similar
  activities on previous projects?
• What is the Level of Analysis?
• Early guess, good estimate, or a detailed and
  thorough analysis

43
Risk Management

• Manage your project by managing the risks
• Embrace the risks!
• Create a list of risks
• Quantify the risks
• Probability of occurrence and cost if it does
• Prioritize them accordingly
• Look for early warning signs!
• Have an action plan ready for top 5 or 10

44
Contingency Risk Management

• Risk is inherent in each development activity,
  task or feature
• Analyze the level of risk
• Activities that are dependant on others have a
  higher risk
• Quantify your risk tolerance on activity
• 10, 40, 60, low, med, high
• Calculate your risk contingency and add it to
  your schedule

45
Contingency Scope Change

• Plan for change during project
• Rate of discovery
• As you learn more about your project, you will
  discover new or forgotten requirements
• Apply a change factor to your estimates
• Apply a change to each estimate
• Adds to the contingency time

46
More Contingency

• Put vacation time directly into your schedule!
• Plan for sick time in contingency
• How many days are typical?
• HR Training, Performance Reviews, etc.
• QA based on your organization
• Put QA time as separate tasks
• OR
• Allocate some contingency to QA bug fixes

47
Duration vs. Effort

• Duration factors in effective work time
  during the day.
• Some studies have shown software developers doing
  only 2-3 hours task work in a day.
• Effective work time decreases as developer
  seniority increases
• ? more interruptions and guidance to others
• Knowing the teams efficiency is good!
• Dont plan for 8 hours when you only get 2-3!

48
Time in a day
3 hours of lost productivity each day costs 4
man-months per year! So plan for it!
Email, Phone calls, IM, Interruptions
3 hours
Meetings, discussions
Task Time Productive Work on assigned tasks
5 hours
49
Example

• Developer Estimate 5 days
• Confidence Level Medium (add 15)
• Risk Analysis High probability, Medium impact
  (add 15)
• Efficiency 5 hours/day
• What is your primary unit of time?
• What do you put in your schedule?

50
Example
Duration
5 days
3 days

2 days
Estimate
Contingency
Start of Milestone
End of Milestone
51
Plan for QA time

• Developer says Done
• But its not!
• QA should do acceptance tests on each feature ?
  QA Accepted
• Plan time in each iteration or milestone for QA
  and bug fixing by each developer

52
Topics Discussed

• Scheduling Concepts
• Predictability
• Early Project Techniques
• Estimating Techniques
• Contingency Planning
• Managing to your Schedule

53
Managing to your schedule

• Track your progress along the way
• Collect data ? your actual results
• Project Managers/Producers are responsible
• But have the team update their status
• Commitment!
• Use a tool to track task progress
• Bug databases, online databases, bulletin board
• suited to your organization

54
Managing to your schedule

• Manage your milestones
• Obtain commitment from your team
• Make them deliver ? do mini-crunches
• Every milestone (or phase) can be treated as a
  mini-project
• Manage to a list of tasks and priorities
• Developers hate big schedules and will ignore
  them
• Each person gets their own list!
• Online, at their desk, in their favorite tool
• Early warning system
• Open and honest communication paths are essential
  
• Dont ignore the obvious signs of trouble

55
Example
Unused Contingency
Duration
5 days
3 days

1 d
1 d
Estimate
Contingency
Start of Milestone
End of Milestone
56
Agile Development

• Deliver early and often!
• Inspect and adapt
• Know what your efficiency is
• Always do highest risk or highest priority work
  first
• Scrums, Sprints, Releases, Backlogs, User
  Stories, Velocity

57
Agile Development

• Uses empowered Scrum teams
• Scrums demonstrate progress each Sprint (every
  2-4 weeks)
• Major Releases every quarter
• Always do highest risk or highest priority work
  first
• Plan and review each Sprint ? opportunity to
  re-focus and re-prioritize
• Measure velocity of teams and use to predict
  future Sprints

58
Key Points

• Use past data to predict the future
• Create a staffing plan first based on your
  typical project
• Size your projects and adjust
• Prototyping should mitigate the highest risks and
  provide the data to estimate better
• Use an estimating system that your team supports

59
Key Points

• Time Scheduling must
• Factor in efficiency and effective work time
• Factor in confidence level of estimates
• Factor in risk on the task
• Factor in change expectation
• Factor in vacation, sick time
• Factor in QA Polish time
• Create a contingency pool for managers, not for
  the developers!

60
Key Points

• Use a methodology that allows for change such as
  Agile development
• Build in Quality early in the project, so it
  doesnt get sacrificed at the end
• Plan for QA time in each milestone and at the end
  of the project!

61
Key Points Why schedule?

• Planning process helps identify risks, issues and
  requirements
• An inaccurate schedule still provides value
• Forecast for completion
• Provides a roadmap
• Management tool

62
Predicting the Future

• Duane Webb
• Director of Production, BioWare Corp.

63
Book References

• The Deadline
• by Tom DeMarco
• Agile Estimating and Planning
• by Mike Cohn
• The Art of Project Management
• by Scott Berkun
• Rapid Development
• Steve McConnell