Lost in translation?

When starting some major building work on our house, we found it a challenge to visualise the outcome of the project.  We got an architect to draw up our ideas, which he presented as a series of drawings, required for planning consent.  It wasn’t easy but we could work our way through the drawings, correct mistakes and omissions, so that before we appointed a builder, we had a high degree of confidence in what the builders would create. 

I recently worked with some people in the shipping industry who buy new ships.  They also use technical drawings, but often commission scale models of new vessels.  Sometimes computer animations are produced  from the CAD drawings to enable the customer to walk through and fly around the ship.  Similarly when businesses commission new commercial properties, or new products, or any designed object, there are drawings and models for documenting the object, which is reasonably comprehensible to the customer.

These drawings and models can be viewed as a language through which all the parties can communicate.

Critically, this common language gives two major benefits:  

• Everyone involved in the project shares a high degree of common understanding of the desired outcome

• at a relatively early stage in the process, and before too much money has been spent, the customer can confidently approve the major part of the expenditure

Key thought:  the key risks of variation of time, cost and quality are reduced to an acceptable level, very early in the process, at the expense of only a small fraction of the potential total cost, because there is a common language.  The customers may not be able to write in the language, e.g. create the drawings, but the customer can understand the language sufficiently well to make informed decisions.


There is a further advantage that the drawings provide a rigorous specification of the new product, that can be verified for integrity, whether by experts like structural engineers, or by computer software, further ensuring the quality of the eventual outcome.

In computing, and to some extent in business change, we have struggled to find a language to express the detail of business processes and computer programs, before we require the customer to sign off the bulk of the budget for the project.  How often have we found that none of the customers have fully understood the specification (in whatever form) and have proceeded on blind trust?  I use the term "quality of sign off" to discuss whether the customer really understands what they are signing up to.  The number of failed projects indicates that the IT industry has not been able reliably to reduce to an acceptable level the major risks of an IT project early enough in the process.

Nevertheless, we persist with a governance and contractual model from building and engineering:  don’t proceed until you build a model that the customer can sign off – based on the analysis that the cost of errors increases throughout the project.  Moreover, the common reaction to failure of one project is to screw down the contract, by putting more detail into the models and specifications, which is of course of unknown and unverified accuracy.

We must conclude that the IT industry, blessed with some of the most innovative and stunning intellects, has not yet found a language to model a system to customers.  After 50 years, should we now presume that the problem is in fact  fundamentally insoluble, that even if we had a language, the customer simply cannot envisage a complex program or process?  Is it time to ask "will we ever?"  Instead of trying to find a "good enough" language to communicate a system, should we not be looking at the problem more fundamentally, and find a completely different approach?

So, why do we need specifications?  To reduce, and ideally minimise, the risk of developing the wrong solution, customers need to know what they are going to get for their money.    (We also need the specification for the contract between customer and developer, but let's not get legal here.)   What is the earliest point at which the customer can understand the nature of the solution?  In many cases, customers only really understand software when they use it, and often the customer has to run a full critical cycle, like year end, stock take, or Xmas, to understand the capability, and the limitations.

We have to conclude therefore that the only effective language to communicate a software design is the software itself. But even testing the software is less than effective, with many functional issues only understood from live running.

But the working software represents the end of the build cycle, when all the money has been spent.  Any deficiency must therefore increase the cost, and delay the realisation of benefits.  If the test is using the software, how can we bring forward that experience without actually building the software? 

In Agile, we prefer “working software over comprehensive documentation” (Agile Manifesto).   The Agile approach is to build first the least necessary software, or minimal useable subset, in order to let customers test and use the software, as part of the joint customer/builder learning journey.  That software will need improvement and enhancement, but at least some of the software will be good enough to use from the first release.  The build team will understand more about the customers’ needs, and the complexity of the eventual solution, so they can better understand the emerging requirements.  Then they can build additional features, with greater confidence, of outcome, cost and time. 

In summary, when commissioning software, we cannot achieve our governance goal of minimising the whole project risk by agreeing on a specification, no matter how comprehensive, before we start to build.  The best we can achieve is to reduce the scale of commitment, and therefore risk, by using iterative development and incremental deployment, so that customers are able to understand parts of the solution and gradually envisage the whole.  


That still leaves the basic governance of most organisations faced with an unpalatable catch-22:  can't proceed until until the outcome is specified; can't specify the outcome until the project is started - a subject for much future discussion.