What is the platinum standard for “communicating back to our customer” our understanding of their requirement?

Many years ago I introduced prototyping concepts to the oil and gas company I worked for at the time. It used database and data concepts to create sample systems based solely on data structure using what we referred to as CRUDs (Create, Read, Update, Delete for non-IT people). This was expanded by a colleague a few years later to CUDDL (Create, Update, Display, Delete, List). I have to say the second rendition of this acronym was much more acceptable. After all, would you like some crud? Or would you prefer a cuddle?

But I digress.

The systems we were creating at the time were very data heavy, information systems mainly. See input screens, lists, reports, displays and the mechanics of maintaining the data was key to finding holes in the requirements. They beauty of the approach was that it was data focused, using Dr. E.F. Codd data design methods, and once the data was structured, a push of a button produced the system. Demonstrations of the prototype immediately highlighted any issues, often with missing data structures or relationships. Once corrected, another push of a button produced the corrected system.

This method was visualizaztion of something very abstract and it worked very well. It lent itself to a sort of Agile approach with iterations that pre-dated the invention of Agile and Sprints.

To apply this little story from the eighties to the questions you asked, George:

[1] So, if we agree that the physical-world architect’s method of communicating "their understanding of the requirements" to their customers is best-of-class, why would we aspire to any standard that falls short of visualization?

Totally agree. The method of showing a working system rather than having some one read a document (the [boring and mind-numbing] gold standard at the time) provided a clear understanding of what was coming, and highlighted any issues that could be quickly corrected..

[2] Although a higher burden is associated with bringing requirements to this level, is this a valid reason to abort or not consider the effort?

The point here I believe, is to structure the approach so that it is, indeed, not a higher burden, such that something can be quickly created, showcased, and if it doesn't work, try again. The prototyping method.

But, if a higher burden is required because it is too complex to generate the model based on a piece of work you have to do anyway (in the case of my example, data design), it may very well still be worthwhile. Everything comes down to quality, time and cost in the end. So if not building visual models introduces rework effort that is beyond the effort of building a visual model in the first place, one would have to agree that the modelling effort is worthwhile. The trick is in knowing this in advance. One needs binoculars, not a rear view mirror. ;)

[3] What consequences do project professionals face when they do not advocate for and direct their teams to communicate project knowledge at this level of quality?

Consequences might include not meeting client expectations, being late, cost overruns, budget overruns and so on. All those things we used to hear about in the "Chaos reports" of years past.

Thanks for the thought-provoking post, George.