RHEA’s experts have been using concurrent design for nearly two decades to accelerate the early phases of complex engineering projects such as space programmes, defence systems, factory design and luxury yachts. Now, in this blog series, they share 10 key factors that contribute to the success of the approach.
By Gwendolyn Kolfschoten, Concurrent Design Expert
9: Taking an iterative approach
You may have read that concurrent design takes an ‘iterative approach’. But what does that mean?
We work from high level overviews to increasingly finer details in short cycles in order to arrive at a rigorous solution. In these cycles, the solution is first explored at a high level of abstraction. It is then decomposed into smaller, sub-system level ‘chunks’. For each of these chunks, we identify, examine and elaborate upon functional solutions to specify the system to a level where it can be evaluated with respect to the key requirements.
In the next cycle, the team further develops and scrutinizes the solution to resolve key design challenges. In this way, the design is specified in detail until everyone is satisfied that all critical interdependencies are covered.
This iterative approach is central to concurrent design, but only works if you manage expectations so that revision and refinement are seen as the norm.
To start this iterative approach, the team specifies the key requirements of the system and the main components of the design. These key components or sub-systems are associated with domains and each domain is represented by a domain expert.
Next, the team needs to identify the key information required to verify if the design meets the requirements. For instance, to ensure the system is not too heavy, we need to specify the mass of each building block so the total mass can be computed. Similarly, to ensure the electrical power subsystem is powerful enough, we need to specify the power consumption for each element.
Once the basis for the model is complete and correct, the team starts its first design iteration by specifying the parameters for each building block. Once the data is verified by the team, it is published, after which it becomes available for other domain experts to use.
The value of reports
When all the data is published, we can generate a first overall report. If this is done using COMET™, we can calculate and synthesize the values at an overall system level. Typical COMET reports present a mass budget, power budget and cost budget. The results of the reports can be linked to design drivers to gain an overview of the feasibility of the design.
Based on the reports and early verification of the requirements, the team can see where the design needs to be adjusted. One advantage of concurrent design is that both the user and project manager are present at each session, so they can discuss there and then if they want to change or adapt the requirements.
Small changes in the design and requirements can be made directly in the model. Larger changes are generally referred to a splinter session or assigned as action points to be analyzed in the next session. Based on this, the team can determine if further analysis is required – if so, this task is assigned to the relevant stakeholders.
At the end of an iteration, we draw conclusions, summarize the plans and goals for the next session, and freeze the iteration. We then make a new iteration in the next session.
For each iteration all key assumptions, solutions and issues should be carefully documented and kept.
The team then works though several iterations to create a design that unites the key requirements into a functional architecture, with all the design choices traceable in the system.
- Make revision and refinement the norm.
- Frequently review the impact of design choices on the overall system performance.
- Explicitly share revisions and updates to ensure the team is aware of improvements.