Date

23 March 2023

Category

Collaborative Engineering

No comments

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.

In this blog series, they share their insights into how you can ensure concurrent design sessions are rigorous and the outcomes are high quality.

By Gwendolyn Kolfschoten, Concurrent Design Expert

Catch up with last month’s post: Focus without losing a holistic view

6. Challenging the experts

When you are the facilitator in concurrent design sessions you may know a lot less about the topic than the participants, and yet you have the task of challenging experts and even calling out flaws.

How do we do that without bruising their egos? How do we send them away with homework to improve the rigour of their results without making them feel they did a bad job?

Managing mistakes

When experts present their estimates and first system level calculations have been made, often some of the estimates are obviously wrong. For example, in a drone it cannot be correct that the communication system is heavier than the batteries. When you see such large deviations, there are two options: either you have uncovered a major infeasibility within the requirements, or the communication expert has made a mistake in their assumptions. And that means you will need to ask the expert to explain their rationale and ask them to fix their calculations.

Another situation is when experts claim something is not feasible, but do not substantiate their claim with evidence. You may hear “That will take way too long” or “That will be much more expensive”. In these situations, again you need to ask the expert to make clear why they think it is infeasible, and to calculate “How much longer?” or “How much extra cost?”

Both situations are tricky because it necessitates calling out an error or flaw – possibly even fleshing out what the mis-assumptions underlying the mistake are – and then asking experts to do it again. However, they are the experts, whereas you as the team lead often are not. So you risk wrongfully accusing someone and/or making an expert feel ashamed. Both are challenging and a potential trigger for resistance.

Here are some ways to deal with this situation.

  • Explain beforehand that our objective is to find mistakes, and that they are very common in the first phases of design; also that they help us to create shared understanding and critical trade-offs. People should be comfortable with revealing problems – in fact they are a blessing because they can still be solved in this phase.
  • Set the example by making yourself vulnerable: “I am not an expert on this, but it seems this is somewhat off”. This gives the expert space to identify their own flaw, and helps you to avoid any dispute about ‘who knows best’. In this way we also keep the expert in the role of expert; we do not challenge them, only the content of what they present.
  • State that, in general, the intention of the exercise is to create shared understanding of assumptions and reveal misunderstandings: in this way the mistake is framed in advance as a misunderstanding instead of a fault. Finding ‘misunderstandings’ and ‘potential issues’ is safer than finding ‘mistakes’ and ‘problems’.
  • Associate calling out ‘vagueness’ with your role: “You just said very long, so now it is my job to ask you how long”. This ‘sharp ear’ for any signs of vagueness is something you have to develop over time. When you consistently call on this, it becomes a habit of the team.
  • Admit your own mistakes, or show understanding. “I did not get that either” or “I also did not realize that that was a key issue”. This helps the team to feel safe when identifying challenges in the design.
  • Call the revision or fix an ‘iteration’, which it is. It is normal that our first estimates are not always spot on – that is why this is an iterative process. In the next round we need to scrutinize this aspect and see if it holds.
  • Correct any shaming or blaming. It is critical to ensure that participants do not get negative attention when bringing in a problem. (We will look at this in the next post in this series.)

Find out more

In this series of blog posts on concurrent design, we present techniques to improve rigour and quality. These offer a toolbox for concurrent design team leads to support their teams effectively in improving and testing the design. We cover aspects such as how to handle validation when working with rough estimates, how to zoom in and focus without losing a holistic view, and how to capture the wisdom of the whole team of experts.

Follow RHEA Group on LinkedIn to be alerted to new posts in this series.

Catch up with our previous blog series on 10 Success Factors for Collaborative Design.