The impact of unchecked assumptions in the design process: Technical Debt and impact latency

Linear versus non-linear processes

The complexity of the design and engineering phase of projects is often underestimated. Irrespective of the scale, novelty, or value of the project, multi-disciplinary teams of design professionals must work collaboratively to share information, coordinate across interfaces, check that requirements have been met, and mature the design at an agreed rate to gain sign-off and approval to proceed. Unlike the linear process of construction, where dependency is the driving logic between work activities, the design process is non-linear, with design activities being both dependent and interdependent. This interdependency is critical to enabling iteration, the lifeblood of the integrated design development process. However, interdependency also requires designers to identify which disciplines need to work together, when this focused coordination activity will start and end, what activities must be undertaken during that period, and what represents a successful outcome from their combined efforts. Consequently, determining the optimum sequence in which to complete the work is complex.

Activity completion, readiness, and the impact of assumptions

When design activity is not sequenced correctly and thus, periods of iteration and coordinated working are not identified, information is not available when it is required. In the linear process of construction, it is not possible to start and finish an element of work if everything is not ‘made ready’. In the design process, however, work can be commenced…and completed for that matter irrespective of whether the information required is available or not. How? Any missing information can be assumed…and it generally is. In fact, in this situation, the only way that design can be progressed is via the introduction of an assumption.

Designers are making assumptions on a continuous basis. Some of these are recorded, the majority are not. It would be nice to think that the individual who introduces an assumption, will advise those that use the output (typically further information) of his work that an assumption has been made. This rarely, if ever, happens of course and as further activity is undertaken based on the initial assumption, the impact of the assumption being incorrect flows through the subsequent activities with a snowball-like impact. Design is undertaken by professionals of course and consequently, how likely is it that an assumption has been poorly made? Well, if the only variable was the qualifications and experience of the people involved then the likelihood would be small. However, when individuals are pressured to progress design, bill hours, meet deadlines, or generate deliverables to enable contractors to ‘get into the ground’, the probability increases substantially. Consequently, many of the assumptions are ‘quick and dirty’ in order to satisfy the increasingly irate demands of other stakeholders. The downstream impact of this on the design are poorly understood and are likely to have significant cost, schedule, and coordination implications. It is inevitable that this build-up of ‘debt’ will have to be repaid by the project at some point.

The concept of ‘Technical debt’ and impact latency

In software development, the concept of ‘Technical Debt’ is the implied cost incurred when programmers introduce ‘fixes’ that enable progress whilst recognising that they will need to be rectified in the future. The longer technical debt is left unchecked, the longer it builds up, and the more costly it becomes to rectify.

Just like in design, Technical Debt in software development is accrued when a ‘quick and dirty’ solution is used to enable a software development problem to be progressed / overcome. In so doing, progress can be made in the short-term but debt is now accumulating – and the longer the timescale between taking on the debt and paying it off, the more costly it is to the project if the quick fix is proven to be wrong. This impact latency is an important concept when considering when to introduce assumptions and what needs to be done to ensure that they are not left unchecked.

Although it may appear that the introduction of Technical debt via assumption-making is a bad thing, when a design team is entering a period of iteration (where the information flowing between multiple activities results in interdependency) the only way to proceed is to make an assumption, attempt a solution, learn more about the problem from a multi-disciplinary perspective, before going back through the process again to fine-tune. This iterative process, which is commonplace in design, is critical to resolving coordination ‘hotspots’ whilst limiting the build-up of technical debt in the solution. In effect, the activities held within an iterative loop limit the extent of impact of the assumption. This iteration is contained and ensures that the Technical Debt does not spread beyond the limits of those pre-defined activities. Furthermore, by bounding the scale of iteration, additional check points can be introduced at the end of a cycle to check and, if necessary, correct an assumption, thus limiting the latent impact of poor / incorrect assumptions on the cluster of interdependent activities.

The key to successful Design Management

Only by differentiating between the positive iterations that enable effective interdisciplinary working and the negative re-work cycles that are created as a result of poorly sequenced activities, is it possible to pin-point where assumptions must be made, identify the assumption check points, and limit the accumulation of technical debt. These two very different ‘cycles’ are indistinguishable to those engaged in them, but they have very different impacts on the timescales to complete the design process, the impact latency, and the veracity of the solution that emerges. Whilst the idea of re-working design that was previously believed to have been developed based on firm information is frustrating and costly, it is, relatively speaking, inconsequential compared with moving into the construction phase of a project carrying a significant Technical Debt load! Imagine realising that the foundations that have just been constructed are based on an assumption that was left unchecked and turned out to be incorrect – the cost of re-working the design is one thing, the cost of re-working the built asset is entirely another!

The impact goes way beyond the financial implications. Paying off Technical Debt involves completing the same work again (and, maybe, again and again), which is unrewarding, demotivating, and frustrating for the designers, contractor, and the client. Frustrations boil over, designers avoid collaboration, and clients can stop work. ?

Given that Technical Debt must be introduced to the design process to initiate a period of iterative working, it is essential that all working assumptions are logged and tracked to the point that they can be checked and confirmed or refuted. Limiting the timescale between making the assumption and checking the assumption will minimise the impact latency and contain the Technical Debt. Critically, sequencing and planning the work correctly to differentiate between positive cycles of iteration and needless periods of re-work is the key enabler of effective Design Management.

#designmanagement #projectcontrols

Adept Management is a Design Management and Project Controls business that specialises in workflow definition and management during the design and engineering phases of projects.