I’ve been developing, defining, integrating and estimating projects for over a decade. Having worked with hundreds of companies as well as with tons of internal development and external consulting firms, I’m always amazed at just how wrong the industry always is on setting estimates of completion and deadlines for completion. As a result, I’ve come up with the new D.E.A.D. and D.I.T.O. computations for project estimation and completion. Here they are:
D.E.A.D.: Development Estimates and Deadlines:
- Sales Management: The client expectations will take 25% longer to develop than the actual project that promised by the Salesman.
- Functional Requirements: The functional requirements you defined will not actually work. Add 25% more planning time to ensure functional requirements can actually be implemented based on your system architecture and application interface.
- Functional Requirements: The functional requirements you defined will not actually be developed the way you expected. It’s something to do with the language barriers of Klingon vs. English (or vice versa) between Developer and Product Manager. Add 25% more development time to your project, pre-release to ensure that it’s developed according to your requirements.
- Project Management: The actual development will take 25% longer to develop than the actual project estimate.
- Use Cases: The business use cases you defined only consist of 25% of the actual use cases that will be incurred. Add 50% more development time to your project, post release, to adjust for actual use vs. expected use. This includes functionality as well as performance.
- Project estimated and sold for 10 business days completion.
- It will actually take 12.5 days to complete as promised.
- It will actually take 15.625 days to clarify issues with incorrect or missed requirements.
- It will actually take 19.53125 days to complete the project as properly defined.
- So… project is completed in ~20 days.
- Once launched, it will require 10 more days to correct outstanding issues.
- Total Project time is 30 days.
D.I.T.O.: Developer Insomnia and Take Out.
Luckily, though, our companies have the D.I.T.O. compensating factor to apply, save the project, and quote the next project.
- The incredible Developers you hired are actually insomniacs and can often stretch 8 business hours into many more, including weekends. A 100% gain in productivity Savings: ~10 days. Now we’re only 10 days late.
- By cajoling programmers with Take-Out food, you’re able to gain weekends and working through meals. (Developers are brilliant guys but I always wondered why a $75/hr programmer would work through an hour of lunch for a $10 pizza… who knew?!). Savings: ~25%. Now we’re only 5 days late.
- As deadlines loom and clients get angrier, you’ll need to add Mountain Dew to the Take-Out but this will result in sometimes a 24 to 36 hour stretch of direct programming. The resulting solution will be released, with bugs (sometimes due to pizza crust crumbs in the keyboard) on time.
- D.I.T.O. applied post-release results in a 5 day savings on post-release enhancement.
Combining the D.E.A.D. and D.I.T.O. computations results in a simple 1.5 multiple on project completion. Always apply 50% more time for completion on projects than you expect.
NOTE: The acronym D.E.A.D. is applicable because Developers will die an average of 25% sooner than the typical employee due to complications resulting from no sleep, high blood pressure, diabetes and weight problems from Employer-purchased Pizza, Donuts, Mountain Dew and Coffee. D.I.T.O. applies because your Sales folks will apply the original estimate on the next project sold.