Custom Software Scope Changes (Not)

I spent roughly 22 years of my life building somewhere between 150-200 custom software systems ranging from accounting systems, llama genealogy systems, labor reporting systems, airport profitability systems, huge consolidation consumer data warehouses, and sewer flow modeling systems to the first versions of NORA.

There was one particularly interesting lesson from these days:

“Custom software change orders CLAIMED by builders … are actually more often changes in understanding that come to light as the visions between parties are forced to reconcile.”

Here is how this goes: The buyer describes what they want to the builder. The builder captures this vision in the form of requirements, features, design layouts, etc. This exchange of vision continues until the builders and buyers think they are in synch. The builder starts to build. The buyer starts to see the system come to life. The buyer notes that what he sees is not quite what he had in mind and calls for some adjustments. The builder calls this a change order.

What is really happening is the visions between parties are being forced to reconcile as the system takes shape in the real world.

In my book, this is not a scope change. This only demonstrates that both parties had something different in mind on day one.

There is only one way to safely avoid this all too frequent problem and that is blueprints. And I am not talking about a few screen sketches and report headers. I am talking about robust architectural plans: complete screen layouts with error messages, full report mock-ups containing realistic data and sub-totals. I am talking about a degree of design completeness that the specifications could be used to simulate (e.g., in paper form) the use of the whole system by each type of user.

No one builds a high-rise building let alone a doghouse without blueprints. Otherwise, there is an extraordinary risk of a) an abandoned project or b) the creation of a Dr. Seuss “Who House.”

On a related note: some think that rapid prototyping of big complex systems can shortcut a comprehensive design phase. With few exceptions, I think this is ridiculous. [I will elaborate on this is a coming post. But in the mean time, as a teaser, I have a single test question that determines if a custom software system has been well-conceived. Once the system is all done, knowing what you know now, would you have built it the same way?]

Is the custom software world still this way?