Design as a false narrative


One of the trophes I’ve noticed in design projects over the years is the tendency of engineers to instinctively jump from need to a singular conceptual solution. Unfortunately that initial solution rarely stands the test of time, and inevitably at some crisis point there’s a recognition that this will not work and the engineers go back to change the concept, often junking it completely.

Of course, this also usually occurs slap bang in the middle of the detailed design phase so the effect on project cost and schedule is predictably dire, cue the project manager’s first nervous breakdown. If you’re lucky, read very lucky, you only pass through this loop once, if not cue the project manager’s next nervous breakdown.

Ask the engineers of course and you get the usual explanations, ‘we didn’t have enough time’, ‘we needed to give the draftsmen, coders, detailers something to do’, ‘the project manager is a horses ass’, somewhat more rarely do you get ‘well I made a mistake’. But what’s fascinating is that if you asked these same engineers prior to the crisis point they’d vigorously defend their initial design solution.

Leaving aside our tendency to engage in after action rationalisation of our behavior I think there’s a deeper process of work, one that goes to the heart of what it means to be a human being, that is our unconscious and natural tendency try to find links and patterns in data, regardless of whether they exist or not, and to form a narrative around them.

The narrative fallacy addresses our limited ability to look at sequences of facts without weaving an explanation into them, or, equivalently, forcing a logical link, an arrow of relationship upon them. Explanations bind facts together. They make them all the more easily remembered; they help them make more sense. Where this propensity can go wrong is when it increases our impression of understanding.

Nassim Taleb. The Black Swan.

Engineers making design decisions are I think peculiarly vulnerable, they are presented with a problem, under time pressure, and the availability bias proffers up the solution that most easily comes to mind, which is not necessarily the best. They now have a solution, relief! And hindsight bias promptly steps in to ensure that this solution becomes the inevitable and obvious choice. All the while confirmation bias is ensuring that those little warning signs are ignored, until the project hits crunch time. Of course ask an engineer and they’ll provide you with a perfectly lucid and rational narrative, that smooth’s out all the rough, illogical messiness.

From this perspective the old mantra of always asking for two design options and then comparing the pros and cons of both should be seen for what it is, a primitive attempt to force the mind out of it’s naturalistic heuristic driven narrative mode and into the slower, harder logical mode where it consciously reflects, considers and tests decisions. For the sake of all our project managers.

4 responses to Design as a false narrative


    Reblogged this on Mindocr’s Weblog.



    This approach would be counter to good Systems Engineering, where Analysis of Alternatives is a core process in the ISO-15288 and INCOSE Vee.
    SE is not always present, which may be the source of the issue.


      Matthew Squair 04/03/2014 at 9:51 am

      Yes, yes it is counter. But I think the real value of the ‘analysis of alternatives’ step is not necessarily what we think it is. My hypothesis is that it forces the engineer to step back from the problem/solution and look at it in a critical frame of mind. That moves you from a subjective to more objective standpoint and good things come from that. Now if that’s true, then are there other techniques that we could use to achieve the same effect?


Trackbacks and Pingbacks:

  1. New PM Articles for the Week of March 3 – 9 | The Practicing IT Project ManagerThe Practicing IT Project Manager - March 10, 2014

    […] Matthew Squair explores the evolution of initial designs, from obvious to plainly unworkable. […]