1. Basic Project Planning and Estimation 2/5/2007 Keith Rome (keith@mindfusioncorp.com)keith@mindfusioncorp.com http://www.mindfusioncorp.com/weblog/

2. Have you ever been on a project that was "over budget" or "late"?

3. Why? Bad planning Bad estimates Changing requirements Scope creep All of the above

4. How could you tell? Constantly missing milestones Rising headcount Cutting planned features Low quality (lack of sufficient QA) Poor architecture (not enough time allotted)

5. Typical “Project Planning”… Boss: "How long will that project take?" Dev: "Two weeks I think." (two weeks later) Boss: "How's it coming? You done yet?" Dev: "Just two more weeks..." (3 months later, the project is terminated)

6. How to remedy Use objective estimates, not subjective swags Document the level of "certainty" Factor in the expected planning defects (requirements flaws, design gaps, etc) Apply some basic math Identify Critical Paths and slippage limits (slack) Refine as you go

7. PERT to the Rescue! Program Evaluation and Review Technique First created in the 50’s to support R&D projects related to submarine missile programs

8. Objective estimating Can base on functional components Usually correlated with a Work Breakdown Structure Try to target blocks of work roughly 1 day in duration Update requirements as discrepencies are found (estimating is a good way to "proof" your requirements)

9. How "good" do you feel about the estimates? Rate each work item for how accurate you think the estimate is Give a reasonable Low and High estimate as well as the Likely Good idea to also rate each item for subjective risk to project

10. Factor in global modifiers Percentage of requirements completion Percentage of requirements defective / flawed Percentage of anticipated design gaps (the things we know we don't know) Variable estimate accuracy percentage (start at 100%) These will apply as global multipliers to all estimates

11. Projecting the project timeline Expected = (Minimum + (4 * Likely) + Maximum) / 6 Plot out dependencies Add zero-duration work items for start and finish events Determine Early and Late Start and Finish times Project duration is equal to the Finish time of the last task

12. Start and Finish times Early Start = maximum Early Finish of all predecessors Early Finish = Early Start + Expected Duration Late Finish = minimum Late Start of all successors Late Start = Late Finish - Expected Duration Slack = Late Start - Early Start

13. Critical Path(s) Work Items on the critical path always have Slack = 0 Can be multiple critical paths Critical paths can change when work items slip or compact In most situations, the critical paths warrant the closest attention by management

14. Slippage limits Slack determines how far a given task can be delayed Delay beyond the Slack estimate will likely impact the critical path Slack can be used to find resourcing opportunities ◦ Move resources from high-slack tasks to low- slack (critical path) ◦ Can help condense the overall project delivery date

15. Anyone know what this is? Projected path of your project…

16. Measure and Refine Track Actual times for each task as they are completed Update the Variable estimate accuracy percentage factor Watch out for shifts in critical path

17. This process is methodology- neutral Incorporate into existing management methods Especially suited for Iterative Waterfall Also can be useful with modified RUP, MSF and Agile processes

18. Questions / Comments?