How to get the spec right the first time round.

Software development has its challenges, we take a brief based upon some requirement, we design a solution, it takes time to implement and at that point, we often deploy to production hoping the business case that defined the project holds well.

The above statement defines a waterfall process, which is the way that most fixed price, fixed delivery projects commence.

Core deliverables need time to implement, they need a spec. Regardless of what method is used Waterfall or Agile we must consider the impact of the first release.

Getting it right first time.

I’ll take a stand here, it’s impossible to get it 100% right first time. The only way to do this would be to spend years writing the most detailed spec ever, during which the requirements will have changed.

Your best assumption.

There’s a theory called the cone of uncertainty. At the start there is a high degree of uncertainty, as time and the project commences the certainty improves. No one knows for sure a the start until its delivered, but we can give an educated guess.

https://en.wikipedia.org/wiki/Cone_of_Uncertainty

We can only give our best. Whenever possible, expect to iterate, plan to iterate. Your business case may have had assumptions when you planned and now you’ve delivered those assumptions may not hold up. The application may perform differently than expected, users may not like it (initially). We must monitor, review and assess, then iterate.

The best software isn’t the best on the 1st release, the best are applications which have incrementally improved. Plan for failure, expect to iterate and establish KPIs to help measure accordingly.

Leave a Reply

Your email address will not be published.