Help! Do I need to complete design verification before starting design validation?

We’ll, it depends.

But let’s get into what it depends upon…

We will look at this question in relation to compliance and business risk.  If you have not done so, take a look at THIS POST that gives the background and context on these risks.

To the question at hand, there is nothing in the regulations nor the general standards that state verification needs to be complete prior to design validation.  (I have not looked at every medical device standard, so it might be in one, somewhere…) For this specific question, the compliance risk overall is not going to be high, assuming that everything passes.  If you do your testing in parallel and everything passes, then there are no issues. But the purpose of looking at compliance risk is to assume that there is an issue and it needs to be delt with.

As to the business risk, you need to look at the nuance of the issue, the specifics of the issue, and most importantly the culture of the organization.  I’ll explain…

Nuance is important.  You don’t have to do your work the same way every time, but you should have the same methodology every time.  Keep in mind, my discussions are mostly around the design process, which, by design … is going to be different for the type of product you are designing.  However, the methodology you use to design your products should be the same.

But for the nuance of doing V/V testing in series, you are essentially reducing risk.  And this is mostly a business risk, with a little compliance risk too.  Often businesses will have procedures to wait until verification is complete before executing design validation, because design validation is a costly activity.  You must pay clinicians, and if you have 15 users per user group, the number can get large and can get expensive very quickly.  If you are manufacturing products, and multiple ones at that, it can get expensive too.  Businesses don’t want to spend a lot of money and fail.  And project managers don’t want to explain to their bosses why they wasted so much money.  So as a project risk mitigation, doing them in series makes perfect sense.  Especially if these are more novel products where the chance of failure is higher.

However, let’s say that the product is not that different from products you already make, so the project team has a very good feel for the design and the manufacturing.  Maybe the product is not too expensive to manufacture, and there are not that many user groups, so the execution of the design validation is not that expensive.  Could you do design verification and validation in parallel in that case?  For sure!  If you can reduce your timeline by a few months, taking that risk would be completely appropriate.  But you just need to make sure everyone is aware of the project risks…

At the start, I mentioned culture is important, and this is where it bears out.  Is your business OK with failure?  If yes, then test in parallel!  If not, then be wary.  Ideally when the decision is made to test in parallel, there would be an understanding of the risks. If there is an issue with design verification, it could have an impact on the validation efforts, and would push back timelines and increase costs.  A good project manager will lay that all out, so it is clearly understood by the functions and managers involved.  Ideally, when that design verification defect occurs, everyone understood that it was a possibility and is OK with project delays and cost overruns. 

This is very rarely the case.  This will lead to the project team yelling Help!, pointed fingers, and some early morning meetings.  There often is a push to find a way to make it work, which increases your compliance risk with either some convoluted rationales or a hold your breath moment that no auditors will find the issue later.  Both of which are not good options.  This is why culture is key. 

If the culture is very very very timeline focused, then I would recommend more of a serial execution, to not force the team to make these difficult decisions.  Very savvy project managers might provide the timeline for the V/V execution in series, while doing the testing in parallel.  Businesses do not get upset with teams that over deliver…

But generally, if the project team has very high confidence in the design and manufacturing process, and you have a good method to deal with verification and validation failures, can you do verification and validation testing in parallel?  Of course!  And if the team does a good job, they won’t have to start singing “Help, I need somebody, help, not just anybody…”

Reference: Help! “The Beatles.” 1965, Parlophone.