Improving Quality Nuggets: Rule 2

This one rule in a multipart series. Please see the intro article for the full list of rules.

Rule 2: Fixing a design issue during development has a 10x cost; fixing it post go-live is another 10x cost

I’ve been blessed to have had many good architects on my projects. The quality of your architect can really make or break your project. The above rule is a quote that a great architect used to recite to remind the delivery team about the necessity of having high quality deliverables. This rule is the engineer’s version of “Haste makes waste”.

This rule is taking some using some round numbers to make a point. We don’t know for certain is it exactly 10x. However, how many times have we seen something in production and thought it would have been much better to have developed this properly or thought it would have been even better to have spent more time thinking about the design. We can see the exponential increase in the effort for corrections downstream.

Further, sometimes we get deep into the project execution only to discover a fundamental design issue. It could be one we might call “invalid requirements” which are problematic or even unachievable business requirements, such as requirements which conflict with other requirements for the same deliverable.

One classic example of conflicting requirements is that a customer wants a device-independent visual design that could work on laptop, table or phone while still having a while separately asking for fixed design elements that do not change based on display size. Either two people created such a requirement or a single person who did not understand the conflicts between the two design principles. Nonetheless, the fixed elements will conflict with the device-independent responsive design principle.

At this point we might need to adjust the requirements and change the design. It could involve substantial re-coding and re-testing if it is discovered late. Likewise, after a go-live when production data has been generated the fixes and testing methods will be a lot more complicated and cumbersome if a data model change were to be introduced at that time.

When we have a solid design then the goal of the project manager on a day-to-day basis during execution is to inspire the project team to work in a way that is most efficient (e.g. taking less time). However, there is also a competing goal to consider. There will be no time saved when the rushed deliverables contain defects that will require downstream work in testing and remediation.

The cost of this additional downstream rework might be fully or partially shouldered be an entirely different team to the one which created the deliverables containing the defects. Some of the cost might be at the expense of the customer or the customer’s customers. On the one hand we want to move fast to get a project completed on time. However, if we move too fast, we can end up production issues that cost a lot more than the time saved by rushing.

Go to Next Rule

Return to Intro and Rule List

Disclaimer: The opinions expressed are solely mine. They do not necessarily reflect the view of any of my employers nor relating to their business or policies.