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 Time Scope Resources What about Quality?

8. Project Fulcrum QualityResources ScopeTime

9. Project Fulcrum QualityResources ScopeTime

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) isn’t close to reflecting reality (accuracy).  Precision is easy, Accuracy is difficult!  “The Art of Project Management” by Scott Berkun

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

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 SizeFactorEffort in days Very Small (> 1 hour)1 Small (> 1 day)X55 Medium (> 5 days)X420 Large (> 20 days)X360 Very Large* (> 60 days)X2120 Measures high level feasibility, “In the ballpark” LOD *120d = “Don’t 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  It’s 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  Parkinson’s 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 team’s efficiency is good!  Don’t plan for 8 hours when you only get 2-3!

48. 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!

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 5 days3 days … 2 days Estimate Duration Contingency Start of Milestone End of Milestone

51. Plan for QA time  Developer says “Done”  But it’s 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  Don’t ignore the obvious signs of trouble

55. Example… 5 days3 days … 1 d Estimate Duration Contingency Start of Milestone End of Milestone 1 d Unused Contingency

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 doesn’t 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