Date
27 January 2022
Category
Blog, Collaborative Engineering, Concurrent Design, Data, Media Updates
No commentsRHEA’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
3. Be Driven by Data
Concurrent design focuses on a rational, fact-based type of decision-making. However, exact values are not always available at this stage of a project. In this post, we explain how to deal with estimates and margins when assessing trade-offs.
From assumptions to facts
Early in any study, the team has to identify what the key trade-offs are in the design. These trade-offs become clear when the team bases its work as far as possible on facts. By focussing on the most critical and challenging requirements of the design, and quantifying these early in the study, the team will become aware of key choices, explicit design challenges and important risks and uncertainties.
However, in this preliminary phase, the team often does not have access to precise metrics and values. Instead, it relies on experts being capable of creating realistic estimates and well-reasoned assumptions. Using these across several iterations, the team can progress from assumptions to facts.
Our experience shows that these first assumptions are not entirely accurate, but they do enable and support discussions about trade-offs that would otherwise remain hidden until much later in the design.
Several techniques can be used to improve these early estimates. The choice will depend on the type of data available, but may include quantification techniques, the pareto principle or expert analysis.
Margins are data too
The reliability of the data and the domain both indicate what type of margin may be used. For example, in project management, slack in throughput time is calculated, whereas in construction a building margin is used.
Each domain has its own margin philosophy, which provides a structured way to deal with different types of uncertainty in the design. Based on the margin philosophy, a quantitative margin is added to each variable, depending on the uncertainty of the value. What is important is that the approach to margins is agreed on early in the design, to ensure that margins are not stacked on margins. Ultimately, margins are quantifiable data as well and should be communicated openly with the whole team.
In COMET™, RHEA’s software platform, the reliability of shared data is indicated by three types of parameter values:
- Manual – this is a direct expert estimate of the value
- Calculated – this is a value that is calculated based on more detailed information
- Reference – this value is derived directly from a system specification.
For each level of certainty (or degree of uncertainty), a different margin can be assigned. In this way, any lack of certainty is compensated for and the preliminary design can be verified against key requirements.
Taking the team view
It is important that the results of estimates and calculations are presented to the team to test if the values concur with the experiences of other experts. When this is not the case, the team needs to further analyze the assumptions and calculations used, as errors can stack on errors. After several iterations, not only do the estimates improve, but also the support for the calculations and the insights of the team on how to optimize the design.
Once the data is verified by the team, it is published in COMET as a single point of truth, after which it becomes available for other domain experts to use.
Our tips
- Quantify requirements early, as this will result in specific trade-offs and focused discussions.
- Use a margin philosophy to deal with uncertainty of estimates and continuously share the margins used with the complete team.
- Present estimates and calculations to the team for feedback and scrutiny.
