Predicting the Future Project Scheduling Tools & Techniques Duane Webb, BioWare Corp

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


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


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


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!


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



Example of a Staffing Plan

Topics Discussed


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.”


Topics Discussed


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


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


“Agile Estimating and Planning” by Mike Cohn

“The Art of Project Management” by Scott Berkun

“Rapid Development” Steve McConnell

Documents

Predicting the Future Project Scheduling Tools & Techniques Duane Webb, BioWare Corp