Rules of Meeks: #003 - "When in doubt about an estimate, multiply by three"

(image source: 995645 on Pixabay)

From The Rules of Meeks

#003 - "When in doubt about an estimate, multiply by three"

This is hard-won wisdom that has proven itself again, and again.

This rule originated with my own early experiences trying to estimate software development tasks for myself - and over time, I learned that it was pretty damn good heuristic for many of the developers that I managed (at least until they established a higher level of reliability).

9 times out of 10, when you ask someone for an estimate - if they are honest, dilligent, and have confidence in their skill - they will be naturally optimistic. However, in my experience, most managers (and, engineers/developers) do not adequately include sufficient contingency (if at all) in their plans for the following:

• Delays due to legal review, compliance review, contract negotiations, funding approval processes
• Late discovery of requirements
• Effort to do a minimally proper level of design
• Effort to coordinate (and schedule!) the necessary communications and reviews of a proposed design approach - for complex projects that involve building something new - that involve multiple parts of an organization.
• Effort to ensure that the Security parts of the org are involved and have reviewed the proposed solution
• Effort to ensure that Legal has been involved and has reviewed the proposed solution
• Effort to ensure that business stakeholders are adequately engaged, informed - and have buy-in
• Effort to prepare Test Data
• Effort to think through - and document Test Scenarios
• Effort to develop and debug Test Scenarios
• Effort to develop and execute Performance Tests
• Effort to debug/fix issues that usually arise during System Testing
• Effort to prepare (and test!) deployment procedures
• Effort to write and document the solution's design, deployment, operational aspects, and just-enough documentation to communicate with other dependent teams/orgs
• Effort to perform the inevitable rework that arises when designing something new for the first time
• Unplanned meetings/interruptions - team productivity hits when folks have to attend meetings, training, the inevitable sick days - and accounting for slowdowns around holidays

This rule has also proven to be true when dealing with boat yards that have been tasked with maintenance/repair jobs on my sailboat. Usually, the factor is closer to 5x in that case.