Red Flag 1 : The functional requirements are stated as a set of discrete, specific target outcomes
In the real world, very little is certain. The only certainty is that future events will change your requirements; future product demand will vary from your predictions; energy costs will change, facilities will achieve higher or lower reliability than planned.
The chances are, that you and your business colleagues considered these uncertainties,. In doing this, you made judgments on demand profiles, costs of energy, carbon emissions, labour cost, etc.
But then you boiled all of this into a set of specific design targets which could be considered in the requirements spec that you issued to the project design team. It could look like this:
- Capable of delivering 120 widgets per hour
- Capital budget $xm
- Operating costs of £100 per tonne of product
- -97% operational availability
The design team took these, and designed a facility that would best achieve the primary goals – but may be completely unsuitable if the requirements turn out to be wrong (and they nearly always turn out to be wrong!).
To avoid this, you need to communicate the uncertainty on the requirements to the design team; presenting the spec as a series of probability or risk envelopes. For example, we plan on average production capacity requirement of 100 tonnes per hour but this could vary between 88 and 112 tph over the lifetime of the asset.
Red Flag 2 : There is no mechanism to weigh the value of one outcome against another
Think of trying to find the best place to pitch your tent on a mountain – we can’t just say I want somewhere out of the wind, dry, no risk of rockfall, local water supply and expect to find the perfect place. In reality we’ll need to trade say the proximity to a stream for shelter from the wind. We also need to make a judgment of how likely the wind is to blow from one direction, or whether it will rain.
It’s the same with large projects. Most design requirements are presented as a series of essential outcomes – production capacity, energy efficiency, environmental impact, capital and operating costs – but usually no framework exists for balancing one need against another. Without this – we aren’t able to answer essential questions such as :
- Is a 10% reduction in operating costs worth offsetting against 2% higher carbon emissions?
- Is a 20% increase in production capacity worth offsetting against a 5% higher Capex?
The result is a missed opportunity to deliver better outcomes.
To avoid this, we believe that you need a framework that establishes how we value different outcomes against each other, which can be used throughout the project lifecycle to weigh design options and ‘what-if’ scenarios.
Using this framework as a basis, we can weigh the future impact of varying input requirements and the impact of design options in a probabilistic way to identify the real sweet spot amongst all these variables.
Red Flag 3 : There hasn’t been a robust challenge to the design from independent parties
- In-house teams tend to follow historical norms and work within unwritten perceived constraints – ‘this is how we always work’. This limits the opportunity for innovative solutions. Breaking the existing paradigms with external insight and experience can reveal dramatically improved outcomes.
- Design reviews are often conducted within silos – e.g. within the engineering design team, within the architectural design team, within the manufacturing design team, within the engineering contractor. This constrains thinking within these capabilities and loses the opportunity for cross discipline, integrated solutions.
To overcome these natural limitations, an independent project advisor role is essential; an individual or team that is external to the project and ideally independent of the organisations involved in procuring, delivering and operating the capital assets.
The remit of the independent advisor is to take a holistic view across the project, from business need through specification, functional design and detailed design. Hidden challenges and opportunities can be rapidly uncovered using a structured query process at key project stages (stage gates).
Red Flag 4 : The Design Assumptions and Constraints have not been robustly challenged at all stages of the project
All projects come with a set of explicit assumptions and constraints. Some of these have been developed explicitly for the project and are essential considerations; however others may be default constraints applied to all projects. Examples of these may include;
- Ways of working (shift patterns, operational procedures)
- Site location
- Layout conventions
We find that the design team may be applying tacit assumptions on, say, ways of working, that impact hugely on the performance of the asset and result in the design of a far larger plant than required should alternative ways of working be applied. Furthermore, these assumptions may not be visible to the business leaders responsible for approving the project.
In one dramatic example, we found that a plant was being designed to operate according to a tacit assumption of one shift working. When this was surfaced and reviewed with business leadership, a move to a 2 shift working pattern was approved, resulting in a $500m saving.
To reveal these tacit constraints and assumptions requires a project integrator role, viewing across all levels of the project specification and design, from business need to detailed design.
Red Flag 5 : The design follows Industry Best Practice and complies with Company standards
Official Design standards are essential ; they ensure that assets are safe to operate and comply with legislation. Industry Best Practices and our organisation’s internal design standards and conventions enable to avoid us re-inventing the wheel and making repeated mistakes. They’re a way of capturing our learnings over time and passing them on from project to project.
But………
Best practice guides and internal standards can also inhibit innovation:
They capture how we used to do things, not how we could do things
They often build constraint upon constraint, building in complexity
They drive our design teams to be conservative in mindset
We frequently find that systems are over-designed, with excessive redundancy and resilience, because they use company ’best practice’ guides as a basis; guidelines that were established years or decades ago and relate to materials and components that have now improved significantly. In one memorable example, the cost of a large manufacturing facility was reduced by 40% after the use of the corporate standards was challenged and found to be inappropriate.
So when you‘re told that the design complies with all official standards, best practice and company guidelines – ask whether these have been challenged and how they have been amended, streamlined and enhanced during the deign process.
