The approaches used to drive this new revolution are very different from the classical approaches we used to build the first railways, steam engines and textile mills. At Pcubed, we believe these techniques are ready to be applied to large infrastructure projects, such as nuclear decommissioning projects. Delivering benefits that could transform the industry.
For many years, we have tended to use the same delivery approach for all large projects, but is this right? Would you expect to use the same delivery approach for, say, the fourth iteration of a complex product like a nuclear submarine as you would for a one-off solution for a nuclear decommissioning project? The nature of risk involved varies between the projects. In one case, the detailed requirements are well known upfront, whereas for the other the requirements will need to be discovered as the project progresses.
Traditionally when we have applied what I will call the “Classical Approach” we struggle to maintain the balance between safety, design and operational functional requirements. The cycle time for changes to the safety case is so long compared to the other areas that these requirements increasingly dominate the requirements set. This results in complex, highly interdependent and non-optimal solutions.
Whilst, Calder Hall, the first civil nuclear project, pioneered a non-classical approach focussed on collaboration and where detailed requirements were discovered as the project progressed, we have gradually adopted a more classical approach to nuclear projects in the belief that this is “best practice”. The lead times as a result have spiralled.
However, if we look at other industries, such as aerospace or automotive, we are seeing more advanced concepts being applied to the delivery approach. SAAB’s Gripen fighter programme is a great example of this. These industries have seen their lead times tumble to the point where products can be tailored to an individual demand.
The classical approach was developed by thinkers such as Taylor, Gantt and Fayol at the start of the 20th century. The end of the 20th Century and the beginning of the 21st gave us methodologies like Lean Six Sigma, systems engineering and agile. These techniques have been adopted on a piecemeal basis on large infrastructure projects, acting as augmentations to the classical approach rather than replacements.
At Pcubed, we have developed an integrated approach: Engineering Agility. Taking learning from classical and modern approaches, it fuses them into a single system designed to enable complex engineering ventures in safety critical industries.
The beauty in this approach is the variety of methodologies it marshals into a coherent whole, the result is a system that synthesises the benefits of decades of project innovation and delivery experience.
- The Agile approach fixes time and cost, whilst Agile at Scale means that this can be applied to large projects as well as small ones.
- Systems thinking: high-level requirements are clear and controlled, innovation takes place in the discovery and development of the detailed requirements.
- Lean Six Sigma - leaders and teams are constantly improving delivery and stimulating innovation in all aspects of delivery.
- Modular design solutions with relatively small teams giving the people a high degree of ownership and autonomy to innovate.
More than anything else, Engineering Agility enables an innovative culture which responds quickly to change, embracing change as a key way of meeting the project objectives.
The teams working in an Engineering Agility organisation find it highly motivating, stimulating and fast. There’s always a new “release” just around the corner to introduce a new modular “feature” into the solution.
In developing Engineering Agility, we have worked with, or taken learning from a wide range of global companies working across business sectors and some of them are starting to deploy it on new products and services.
The key principles of Engineering Agility are:
- Focus on value. Delivering value rather than contract deliverables is the goal.
- Modular design for quality solutions. The ability to add features throughout the design and operational life cycle as they become available.
- The organisation should be designed around these modules and not around functions. Small, integrated teams are formed to deliver the modules. The fast pace of work and constant improvements motivate and empower these teams.
- Collaboration must be enabled both by the culture of the organisation and by the processes and tools adopted. It is more important for the toolsets to be integrated than to use the latest state of the art tool if it can’t be integrated to the rest of the suite.
- A regular cadence for implementation of features should be adopted to give structure to the project and enable configuration control to be maintained at all times.
These are the 9 enablers that support engineering agility. They are all important to maximise agility, however, there are two levels of enablers. The Level 1 enablers are:
- Innovation framework: Constantly stimulating new ideas and being able to introduce them into the solution with ease.
- Modularity and bundled development: Allows development to be disconnected from the product development program. Modular architecture paves the way for the modular organisation of small, empowered teams.
- Agile at scale: For large projects, this provides an increment and release cadence for the modular developments to be integrated within the product program.
- Capabilities for reintegration of design changes into the product: This requires a highly collaborative environment both commercially and physically.
Applying Engineering Agility to a nuclear decommissioning project means we start at a different place.
In the classical approach, we develop a concept design based on the nuclear design standards. The belief is that this will enable us to achieve the basic safety objective (BSO), i.e. the level of safety at which it is considered no longer reasonable to continue to expend further effort on enhancing safety. This is equivalent to the “maximum credible product” in Agile terms. We have attempted to define every requirement in detail upfront and then we have crammed every feature into the design on day one.
This means we are challenged for space, cost and time from the start. Functions must be shared and the design must be highly integrated and interdependent. A subsequent change to one feature will impact many other features. This design is complex.
With Engineering Agility, the concept design is based on conventional design standards with high levels of quality. In Agile terms, this is the “minimum viable product”. The design is not challenged for space and time and cost are minimised. The design is modular meaning that new features can be added later to enhance the design and get closer to the BSO. This design is simple.
The next step in the classical approach is to calculate the time and cost based on our fixed and highly detailed scope. This is generally a shock and is deemed unaffordable and late by the customer. The time and cost budgets are set at more affordable levels, but the scope remains the same. The contractor is “challenged” to find cost and time savings. Due to the competitive nature of the process, the contractor is prepared to do this to win the contract. The design is now complex and undefined.
By contrast, the Engineering Agility team fixes time and cost at a fraction of the classical cost. Decommissioning processes are generally simple in principle (e.g. cementation) but the cost in the classical approach comes from the added complexity built into the design to meet the design principles.
It is not unreasonable to think that the minimum viable product cost may be a tenth of the maximum credible product cost. Stop and think about that. That means that the Engineering Agility team has a baseline cost and price well inside the affordability limits, opening the door for a contingency budget of a multiple of the baseline cost and time budget to implement new features. Instead of a contingency of 5% for the classical approach (even though this is not real because of the way the project was forced to be forward sold) you now have a contingency of, say, 200%. Even at this level of contingency, the total cost is still a fraction of the classical cost.
On reflection doesn’t it seem odd that we have built many nuclear decommissioning facilities without ever knowing the minimum viable product cost?
If the MVP cost was, say, £80m how can we justify a budget of £2.7bn (this is a real example)? Is it really ALARP (as low as reasonably practicable) to spend over 30 times the MVP cost in an attempt to gain two decades of safety improvement?
In the classical approach, the highly integrated, interdependent and complex nature of the design means that design issues and enforced changes cannot be accommodated, scope has to be removed or the design will be compromised. Paradoxically, the attempt to remove cost actually drives it up at the same time as safety is driven down.
Ultimately the project is late and over budget, the BSO is not achieved and the plant is very difficult to operate.
At this point, the Engineering Agility team is now highly motivated. They have a large ALARP contingency to spend to add features to their modular design to improve safety and operation.
Operation will still start on time and it will be close to the BSO (possibly better than the now compromised classical design). Features are added at defined points in the lifecycle so that commitment to manufacture and construction can be made with certainty. The modular teams and design all enable this approach. Once in operation, ALARP improvements continue to be made (aided by the modular design) until the ALARP budget is spent or the BSO is achieved.
David Whitmore is an experienced project manager, programme manager and nuclear engineer with a proven track record of leading teams of people engaged in high technology programmes of work in the nuclear sector. He is currently Managing Consultant at Pcubed heading the development and delivery of opportunities in the nuclear sector.