It is generally accepted in design that design churn is the enemy. For those unfamiliar with the term, unlike design iteration whereby a common set of requirements is agreed upon and during development new ideas are added and redesign occurs to improve the end result, churn is normally driven by an external influence which is usually requirements changes. Sometimes this is referred to as scope creep, however churn needn’t be about additional new features that are ’nice to haves’ but can be simply about what the design team originally missed or neglected as requirements.

The ways to avoid churn and creep are also generally accepted and perhaps obvious: The lead designer responsible for developing the requirements specification has a great deal of experience in the area the product is developed in and key knowledgable stakeholders from all affected end-users are involved in the development of the requirements. Once the requirements are set many lead designers are loathed to change them to keep their churn in check and reduce any potential scope creep. Unfortunately this rigid approach ignores the fact that not all design churn is bad.

In addition to the initial requirements definition phase, in Engineering there are special detailed design reviews referred to as HAZOPs that are intended to flush out the finer details of what happens to a design if/when specific things go wrong. They are intended to be thorough and run by an independent third party and can take days to perform for even a simple system. This represents a significant investment in peoples time and hence the projects money and once designs pass through a HAZOP they are often felt to be ‘set in stone’. If significant design changes are required post-HAZOP then technically the HAZOP needs to be revisited (not redone from scratch as is often touted by nervous design leads) which becomes a strong obstacle to change.

The problem with the reactionary approaches to requirements change, especially post-HAZOP, is that they ignore the very real possibility that the requirements gap is real and will cause operational or safety issues for the end user(s) upon completion. There is an implicit assumption made every time someone responds with “A HAZOP was performed” or “We had end user input” that those persons involved at those times were A) knowledgeable on all aspects of the subject and B) infallible. We are all human and we all know that people make mistakes including lapses in concentration and judgement, but the odds of obtaining the best requirements input early on is most highly influenced by the persons involved.

There are two stages to consider. During the initial requirements specifications stage, teams are often quite small consisting of a bare minimum of design staff and those staff are predominantly senior staff that, whilst they may have some field/end use experience in the past, sit in management positions and have done for some time. In my experience this assertion is not too much of a stretch as I’ve observed this to be the case in at least half of projects I’ve been involved with in my career. Remembering that age does not equal wisdom or quality and that what actually matters is recent, relevant experience then this effect should be a cause for concern.

The second stage is the detailed design review stage which in engineering usually includes a HAZOP or similar detailed design workshop/study activity. The length of these reviews is often seen as a reason to keep the numbers down - too many people means too many opinions which makes the reviews even longer. Often there are strict requirements to have only 1 representative from each stakeholder group present and those that are sent can sometimes be chosen because the more experienced designers are just too busy with other deliverables and can’t dedicate a solid week to a HAZOP review. The way in which HAZOPs are run also plays a big part with holes in requirements that are found often thrown out the window on the pretext that the current design is being HAZOPed, not what the design could or should be. Such ‘off-topic’ input is supposed to be recorded and resolved outside the HAZOP however if this leads to a design change then the requirement to re-HAZOP the resulting changes is cited as being an expensive and unnecessary exercise and those comments end up ignored.

The customer MOSTLY gets what they want

The end user or customer that is paying for the design to be done for them should be the highest authority on design requirements. There does need to be some restriction on scope creep once the initial requirements are set but the wrong way to handle it is to uncategorically say, “Requirements are set, can’t be changed now,” or “It’s too late, it’s been HAZOPed.” Both statements are ridiculous and ignore the very real possibility that omissions and mistakes were made earlier on and that ultimately the end user will suffer from a difficult to use or under-performing product.

The right thing to do is to assess the true cost of the potential design change. Be honest with how much time a HAZOP revisit would really take (if applicable) and be thorough with the number of design documents and deliverables that would require modification. Once this figure is known a rational debate can take place that factors in schedule as well as the risk to the end user(s) of NOT implementing the changes. Far too often in my industry the design team shuts out the end user from design requirements changes and forces them to spend additional money themselves further down the road (after the project is ‘finished’) to correct the mistakes they found during the project. This ends up costing the customer more money in the end and will hurt future business between the designers and the customer in question.

Everyone should care about customer satisfaction and yet the transitory nature of employment in the engineering space (about 18 months per position) leads to a culture of apathy and rigidity where customer satisfaction is seldom a big factor. Continuity in projects matters and being honest with your customer about the cost of change will help you to both succeed. Shutting down design requirements changes without thought or consideration leads to bitterness, frustration and is ultimately is bad for business.