Always plan on something going wrong…

Anyone who has sat through the process managing a project know, whole heartedly as a fact, no matter how much something is planned and scheduled something else will always go wrong. Believing this as fact one should never, ever, plan a time line or effort estimation based around everything working as planned. Planned and working are so far removed from each other the relationship is vague at best. No matter how many times we build the same CRUD application or data pipeline, or CI/CD process; always leave yourself some buffer time to correct unforeseen issues.

As a general guideline the less I know about a requested change the higher my effort estimation; almost geometrically. As an example:

  • 80 hours to write a single data object CRUD UI
  • 40 hours to write a single data object CRUD UI  with defined fields & validation
  • 20 hours to write a single data object CRUD UI  with defined fields, validation, and user story documentation
  • 8 hours to write a single data object CRUD UI  with defined fields, validation, user story documentation, and visual mock ups of the expected UX

Now at some point I hit a floor where effectiveness just simply keep up with the continued reduction in effort. But at that low of an effort estimate we are basically wizards doing magic as far as non code people are concerned.

Some people will  responded with ‘but estimates that high scare away clients’; This is very true and factual. However, my response is this: do you really want to work with a client who has not clear answer or concepts of what the results of the effort should be? Think `moving goal posts` but not having a goal post to begin with.

TL;DR: Always buffer your estimates, even if you know everything that needs to be done.

Leave a Reply

Your email address will not be published. Required fields are marked *