Monthly Archives: March 2015

If you don’t have time to do it right…

“…when will you have time to do it over?”

beautiful pebble stackMost of us will agree that there is an ever increasing pressure to deliver immediate results from our projects. As organisations in many sectors tighten their belts, there is an expectation of doing more with less, in shorter time. But, in the rush to get on with doing, are we throwing out the baby along with the bath water? Are project time-lines and costs actually increasing as a result of skipping over or rushing through the scoping or planning activities?

There are many pressures on projects within the modern organisation. Some of these are cultural, such as the belief that “productivity = doing something”.

Can we kick back against this pressure, to identify or check that we are “doing the right something”?

Or, do we usually get swept along by the drive to “get on with it” while no one is quite sure what “it” is. Other pressures are related to project management capabilities and leadership.
Taking sufficient time (you can spend too much time on this, as well as too little) over these initiation activities delivers several benefits ; Continue reading

Try this to set clear, straightforward goals, so you develop the right product

I had a flash of inspiration during lunch with a colleague last Friday.

Our conversation included how difficult it seems to be to set a clear, concise statement of the objective for developing a device (or indeed any product). The conversation drifted from there to the most memorable presentations we’d experienced.

My eureka moment; the power of a story to anchor and clearly describe the objective. I’d like to share with you an experience that I still vividly recall.

There was an AAMI/FDA meeting in early 2012. On the first afternoon, I listened to a series of presentations around the perhaps dry topic of “device clock synchronisation challenges”. After hearing several speakers talk about technicalities, standards and protocols, I still didn’t really appreciate what the pressing issue was. Then James Fackler, MD (The Johns Hopkins University School of Medicine) shared his experience of working in a paediatric ICU…ICU device array

The first slide was of a large bank of very similar looking devices in an ICU.

The doctor was faced with banks of instruments all humming and bleeping away, all alerting them to their patient’s bodily functions.

Slide two had a graph of an output versus time from one of the instruments.

The chart was explained, then a second graph was added, followed by a third, fourth and fifth; each with a trace from another device in the ICU, potentially covering the same 30 second time period.

The MD then talked about the blips on the traces and what they meant to the healthcare professional.

Then came the shock.

The blips on each of the charts showed failure of a different bodily function. Crucially, the relative timings of these blips meant a different surgical procedure may be needed to save the patient, a child.

It was like a smack on the forehead!

I understood how important the chart accuracy was to the doctor. A decision how to proceed has to be made within that 30 second window, so device clock synchronisation was critical to presenting the correct sequence of blips that pinpointed the next steps. The doctor is wholly reliant on data from all the devices being accurately displayed, at the right time points, in order to select the appropriate treatment.

Device clock synchronisation suddenly became a matter of life and death.

Encapsulating the problem in a story, clearly presented what needed to be solved and why it mattered, in a straightforward and profound way.

As an aside, although there were no hand-outs from this session, it’s the one I recall most readily from the meeting.

Maybe, as you read this post, you reached the same realisation about the life saving importance of device time synchronisation. How powerful it would be if you described your development goals in terms of what it will mean for the eventual user; described them so that everyone understands exactly the imperative you’re working to address.

Base jumper or fell runner?

International standards such as ISO 62366, ISO 14971 compliance gurus and journals all talk about taking a risk based approach to elements of your development project.

As with many things in life, the strategy you choose to achieve this becomes a matter of how much risk you are prepared to live with;

  • How comfortable are you with the risk of meeting a costly surprise if you choose to test late in development?
  • How much risk are you prepared to pass onto your customers, your users?

Lets take a look at two strategies for a medical device development project.

Base Jumping

A high risk strategyThe dare devil approach. It’s a high risk strategy that is often seen as the fast way of getting down the mountain.

For this strategy to succeed, the device manufacturer has to be super confident in their design, either because it is very similar either a design they have already done or it is very similar to what’s already on the market. The design will also use existing production and assembly processes, without modification.

In this scenario most device testing and process validation activity is done at the last possible stage, when the design is frozen and the company is ramping up for launch.
Sometimes, testing is even done after launch when the regulators ask for the documented evidence.

To take on this strategy you have to have a lot of confidence that you know how to repeatably and reliably manufacture your product, your customers (and ultimate users) know how to work your device as well as you do.

After all, “Its not the fall that kills you”.

Fell Running

A more measured approachThis approach is often perceived as slowing down a fast track project. Yet, the strategy includes the right development activities, at the right times throughout the various stages of product development.

It’s the more conventional way of getting down a mountain.

“The sooner [you] get involved, the quicker, cheaper development is” Vicki R Lewis, AAMI/FDA summit 2013.

In reality, adding development activities to a project at the right time should not impact on time-lines, as activities can run in parallel. Indeed, these activities will greatly reduce the likelihood of expensive re-designs or fire-fighting as you get closer to scale-up and launch preparation.

Of course, development activities need to be budgeted for, but;

  • How much expensive is unfreezing a design to start developing new mould tools?
  • How much more expensive is a product recall because of a foreseeable use error?

Taking this approach should not end messily, as you descend your mountain.

Which of these two strikes a chord with you, feels like the usual one for development? Perhaps you can see the differences in likely outcomes from the two strategies.