Design transfer without dropping the ball: how success needs more than SOPs

Transferring a product design into manufacture too often ends up being a sink of time and money. So what should you be looking for that isn’t in your partner’s SOPs to make sure they don’t drop the ball? From the mundane to the highly original, here are some of TTP’s tricks to ensure your medical device will soon be made in the millions and start making a difference.

When most people think of design transfer trouble, they rightly think of information transfer gone wrong. The quantity of information in the heads of a design team is vast and getting it into the heads of another team is a difficult product design challenge – whether they’re in the same company or not.

Every organisation worth its salt will therefore have a tip-top set of SOPs to make sure the design transfer to the CMO goes smoothly. But in our experience even impeccable formal control is unlikely on its own to lead to wrinkle-free design transfer.

Here are some examples of the practices we use at TTP to make sure our medical device clients aren’t exposed to the heroics of a long pass. It’s a meld of effective documentation and creating circumstances where important conversations between the teams can happen.

The idea of design transfer being held up by the need to alter projection views on 150 drawings is absurd – but it happens. Assembly specifications have been misunderstood due to the wrong version of A’s document being passed on by B to C. Friction gets built into changes because one party uses SolidWorks and another Creo.

Things like this can cost time and money which need never be spent. So we seek to capture all of these finicky little details in an agreement up-front so that they are done right first time. Not rocket science – just the everyday value of accumulated experience.

Part of the genius of the Lego company – and even IKEA on a good day! – lies in producing instructions that are easy to follow and make doing things wrong difficult. And some of that is needed for effective knowledge transfer, but with a twist.

Only a foolish design engineer deliberately tells a manufacturing engineer how to do assembly. The problem is that most design engineers accidentally do it all the time during design transfer.

Instead, the design engineer’s job is to dictate clearly what must (and must not) be achieved by an assembly step in order to set the problem up for the manufacturing engineer as cleanly as possible.

The manufacturing engineer can then use their expertise to decide how to do that. In our own short-run controlled manufacture “BuildSpace” we routinely see both sides of this, so we speak with some experience.

In addition, we’ve developed specific risk management techniques to help identify risks that could be introduced or mitigated in specifying the assembly process. Our “assembly process specification FMEA” is an example. This is notably different from a typical “process FMEA”. The latter considers how the implemented process could introduce risk by not meeting the process intent, but it doesn’t dig into how the very process intent could fail to achieve the intended device outcome. The difference is subtle, but it matters.

However good your documentation is – and ours is pretty good – listening to the conversation when finally the design team sees the manufacture team building a device (or vice versa) tends to bring out emotions from anger to amusement: “why on earth would you do it like that?”

The classic response to the apparent gap in information transfer is to demand still more documentation next time. This is a bit like asking someone to list the things they’ve forgotten. A few helpful prompts are certainly useful in bringing some things back to mind – doing one of our assembly process specification FMEAs, for instance – but the essential issue is that a lot of knowledge is wholly tacit. You just can’t get at it out of context.

Our solution is to create contexts in which it will come out. We may invite the CMO’s people over to watch us building a few devices. Talk through the process specification in detail together, and the CMO’s machine specification. And we may visit the CMO and watch their first few goes at putting things together – nice and early, when there’s still plenty of scope to change approach.

Another common problem needlessly besets design transfer. You might call it a demarcation problem. It is really easy for experts in one area to make decisions that inadvertently stray into other areas of expertise. This can lead to “less-good” approaches and solutions being used. It can cause disenfranchisement and fewer expert eyes looking out for trouble. And it can cause duplication of work.

One common example is the supply chain. As we mentioned earlier, specifying parts in source-agnostic ways is a design task; identifying the at-volume supply chain is a job for the CMO. But CMOs just using the R&D suppliers is no better than designers specifying CMOs into a corner without need. Both need to remember and respect each other’s roles and expertise.

Another example is in-process and end-of-line testing. Ignoring development testing methods created over years is not sensible; attempting the wholesale transplant of a method designed for a throughput of ten per day to a manufacturing context where it needs to handle thousands is no better.

Yet another is managing prospective changes. Making changes without input from a designer is reckless; refusing to consider the needs of a CMO is likely to hit timelines and yields. In principle, this is handled by change note systems of various kinds; in practice, these are only effective when design and manufacture people remember and respect each other’s roles and expertise.

We do our part to make these things happen, and always advocate setting up processes to help support them. But all of these fundamentally rely on the last subject we want to bring up…

Earlier we talked about not dropping the ball. In some ways, that’s a perfect metaphor for design transfer: everyone on the team doing their utmost to co-operate tightly to achieve the shared goal. In other ways, it’s exactly wrong: a discrete thing out of my hands and into yours, all at a distance.

When there are problems on an assembly machine, there’s no substitute for hands-on testing involving the design team – but that requires trust. Understanding strange results requires frank discussion and robust debate – and that requires good relationships and trust. We don’t have an SOP for building trust – just a company full of people who do it for a living…

Find out more about our work in Scalable Design at TTP.