Predicting the Future
Project Scheduling Tools & Techniques
Duane Webb, BioWare Corp.
Topics Discussed
Scheduling Concepts Predictability Early Project Techniques Estimating Techniques Contingency Planning Managing to your Schedule
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
Why do schedules fail?
Poor estimates Missed or unclear requirements Scope changes Staffing issues Stakeholder pressure Poor productivity Inexperienced project management … and much more
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?
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
Project Triangle
Time
Scope
Resources
What about Quality?
Project Fulcrum
Quality Resources
Scope Time
Project Fulcrum
Quality Resources
Scope Time
Plan for Change
Change is inevitable Scope will increase Requirements will be missed or
forgotten
Accept it and be prepared to adapt!
Topics Discussed
Scheduling Concepts Predictability Early Project Techniques Estimating Techniques Contingency Planning Managing to your Schedule
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) isn’t close to reflecting reality
(accuracy). Precision is easy,
Accuracy is difficult!“The Art of Project Management” by Scott Berkun
Sample Schedules
Sample Schedules
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
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
“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
Topics Discussed
Scheduling Concepts Predictability Early Project Techniques Estimating Techniques Contingency Planning Managing to your Schedule
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!
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
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!
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
Determine your “Typical” project
Determine your “Typical” project
Determine your “Typical” project
Example of a Staffing Plan
Topics Discussed
Scheduling Concepts Predictability Early Project Techniques Estimating Techniques Contingency Planning Managing to your Schedule
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!
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
Estimate Convergence Graph
0%
50%
100%
150%
200%
250%
300%
350%
400%
450%
Concept/Vision Design Specification
Prototype Specification Pre-production Production
Est
imat
e P
reci
sio
n
Check this Rapid Development, Steve McConnell
Estimating Techniques
5-4-3-2-1 Method Planning Poker Developer Estimates in detail
5-4-3-2-1 Estimating
Size Factor Effort in days
Very Small (> 1 hour) 1
Small (> 1 day) X5 5
Medium (> 5 days) X4 20
Large (> 20 days) X3 60
Very Large* (> 60 days)
X2 120
Measures high level feasibility, “In the ballpark” LOD
*120d = “Don’t know”, should work to break this down
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.
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
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
It’s fun!“Agile Estimating and Planning” by Mike Cohn
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?
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
“There are infinitely many ways to lose a day... but not
even one way to get one back.”
“The Deadline” by Tom DeMarco
Topics Discussed
Scheduling Concepts Predictability Early Project Techniques Estimating Techniques Contingency Planning Managing to your Schedule
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 Parkinson’s Law: Work expands to fill the
time available for its completion.
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
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
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
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
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
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 team’s efficiency is good! Don’t plan for 8 hours when you only get 2-
3!
Time in a day
Task Time: Productive Work
on assigned tasks
Meetings, discussions
Email, Phone calls, IM, Interruptions
3 hours
5 hours
3 hours of lost productivity each day costs 4 man-months per year!
So plan for it!
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?
Example
5 days 3 days … … 2 days
Estimate
Duration
Contingency
Start ofMilestone
End of Milestone
Topics Discussed
Scheduling Concepts Predictability Early Project Techniques Estimating Techniques Contingency Planning Managing to your Schedule
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
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 Don’t ignore the obvious signs of trouble
Example…
5 days 3 days … … 1 d
Estimate
Duration
Contingency
Start ofMilestone
End of Milestone
1 d
Unused Contingency
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 …
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
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!
Key Points
Use a methodology that allows for change such as Agile development
Build in Quality early in the project, so it doesn’t get sacrificed at the end Plan for QA time in each milestone and
at the end of the project!
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
Predicting the Future
Duane WebbDirector of Production, BioWare
Corp.
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
Top Related