Med Tec 2018- “Speaking the same language- How to co-innovate and collaborate when Med Tech meets Pharma”

Med Tec 2018- “Speaking the same language- How to co-innovate and collaborate when Med Tech meets Pharma”

Alan Maloney from Avellana spoke on Wednesday, 18 April 2018, at the Med Tec Europe Start-Up & Innovation Forum in Stuttgart, Germany. Alan talked about the challenges that teams face in solving complex problems when Pharma and Med Tech companies collaborate on joint ventures in a talk entitled “Speaking the same language- How to co-innovate and collaborate when Med Tech meets Pharma”.

To articulate his perspective Alan used a case study from a client that he worked with where they faced the challenge of resolving a new, complex problem with many unknown elements with two, diverse teams as contributors and stakeholders.


A collaboration with a new partner raised a new set of challenges, ones which could not be answered by referring to the current operating procedures of either participant. The challenge was to assemble a joint regulatory submission for a combination product which meets the needs of the health authorities and other secondary stakeholders. Unanswered questions about leadership, strategy and operational support led to confusion and uncertainty. The team undoubtedly did their best to allay the uncertainty and overcome the challenge using an ubiquitous project management methodology.


There were early symptoms that pointed to the fact that the existing structures were not working effectively, and change was needed in order to progress. These included the appearance of silos (or at least the beginnings of them) and the apportioning of blame between collaborating groups when routine issues would occur.


As with every “project” which is malfunctioning, the human tendency to attempt to seize control is unavoidable. Extra attention was focused on collaboration resulting in long, unproductive meetings. The existing project management structures were “beefed up” resulting in very detailed plans that attempted to control the variables, but in reality just added layers of administration.


The treatment which ultimately saved the day and helped the team to succeed was the creation of highly adaptive, agile teams. This involved the establishment of smaller, autonomous, cross-functional teams which met regularly and used visual management to see and plan their work. This agile structure essentially created an internal start-up environment, and the people involved did what it took to succeed, resolving problems as they arose and adapting to the “shifting sands” of the regulatory environment.


Once victory was achieved, the submission team ceased to be and entered the corporate history as a highly successful group who achieved much in a short period. Alan highlighted the fact that this type of situation is commonplace, especially in product development, and lamented that the organisation did not LEARN why the team was so successful. Faced with a similar problem would the companies have to solve all of the same problems again? Alan put forward an argument that the companies involved would have been better off, certainly in the medium term, to implement a Lean Innovation method, capable of applying appropriate structure to allow the teams to solve complex problems while retaining the knowledge of HOW they did it. Such a method would ensure that the organisation would be able to learn from mistakes, and learn from human innovation, to allow them to improve on the whole.

Alan would like to thanks MedTec Europe for giving him the opportunity to speak (and learn) and for hosting such interesting sessions over the course of the three days.

Why Med Tech Product Development should avoid becoming “Agile”

Why Med Tech Product Development should avoid becoming “Agile”

In recent years, there has been a surge in interest, and generally quite a buzz, around the concept of Agile, more specifically in the use of Agile Scrum, as a project management method in new product development. All industries seem to be succumbing to the allure and mystique of being “Agile” and pressure is being felt to adopt the methodology as a “best practice” for innovation. In this article I will highlight my reservations as a practitioner, and document some of the likely challenges and pitfalls associated with Agile Project Management with Scrum as applied to Medical Technology development.

Software development teams are “Agile”. They can seamlessly convert customer problems into user stories, and then into short bursts of activity (Sprints) which culminate in something that they can test rapidly with real customers. Like Pavlov’s dogs, they log in each morning, salivating to see how their latest improvement, addition or change has been received by a willing, or at least compliant, early adopter user population. A healthy shot of adrenaline to fuel the fervour for more improvement and more rapid learning. And why not? It costs nothing, right?

That is the critical point, it costs nothing.  If a decision is made to try something new, and it is negatively received, it can be easily reversed, and a team has only forfeited a couple of days. In fact this rapid experimentation demands less rigour in planning as oftentimes the team happens upon surprise results which point them in a new direction. Long-term planning is an anathema to this new, nimble system. Long-term planning restricts and confines the ability of the team to react, adapt and change. It asks you to continuously refer back to assumptions made seemingly light years ago, before you embarked on a major phase of learning. It frustrates the teams and often kills innovation.

In a world with limited regulatory requirements, decisions can be made without significant risk to the business and if a decision is wrong, there is a low cost of change. In this world Agile is the perfect way to go. An innovative, Lean solution to the problem of inadequate project management structures for their industry.

“We must be more nimble, more agile, and able to react and change”

This success has generated a buzz which has led to a clamour to adopt Agile Project Management methods across a wide range of industries, but this is where the wheels come off. This is especially true in life science research and development but also applies to the development of most physical products.

Here are the main problems as I see them:

  1. You still need a detailed plan.

In the software world the continuous feedback loops from customer to development teams essentially dictates direction, and direction will change regularly based on learnings from the user population, hence the agility. In Med Tech, you cannot test your design iterations on real life patients (thankfully!!) without the rigour of regulated trials, therefore the results of most your experiments to test early hypotheses are likely to be learning and evidence, as opposed to absolute facts. They may point to a revision of the plan, but they in themselves are not going to determine the plan. Appropriate planning is vital to ensure you are still on course to solve the right problem and avoid building assumption into your decisions.

  1. User stories may take years to resolve.

Software developers can identify a problem, create a story, define sprints and release an update in days or weeks. Gaining closure and resolving a user need or problem in Med Tech may not be achieved until the approved product is in the hands of the end user, or in the internal organs of hundreds of patients!

  1. Sizing work is a dark art.

In software development there are far fewer “foundational” variables and the technology is consistent. Most stories can be adequately tested by flowing them through the same process (coding) whereas with science and engineering, learning will require a large number of highly variable investigative processes. Every week, a task that you thought would take 3 hours, will turn out to take 3 weeks. How do you build that level of buffer into a Sprint plan? And what if this happens to most of your Sprint tasks? It rapidly becomes unworkable and you will expend huge effort and time revising the short-term plan and keeping it current.

  1. The sprint window will not make sense.

For the IT sector, one-two week sprints tend to be the norm, solely due to the fact that the work can be subdivided into chunks that suit this cadence of iteration. Scientific research will regularly present you with bodies of work that will take weeks to complete, with activity split unevenly between the weeks. One option might be to split each experiment into convenient bite sizes to suit the Sprint window, but in reality this will not make any sense to the researcher, and you will only be doing it to maintain your system. Moving to longer Sprint windows is also an option but now you are creeping back to the days of yore and conventional planning methods (longer, less frequent meetings).

  1. You will micromanage.

Fundamentally, product development teams in Med Tech companies are made up of highly skilled Engineers and Scientists, who have inquisitive minds and have been trained to solve problems. When you reduce their work down to the level of task management, you have put a cap on the value which they can add and are likely to have obliterated their motivation at the same time. The Project Lead will inevitably assign smaller, standalone pieces of work, for instance a HPLC test. The assigned team member will go off and perform the test, and then the Project Lead will inquire the very next day as to the outcome. The ownership of the problem will have shifted to the manager, and the role of person who carried out the test will have been restricted to executing a set of instructions as opposed to solving an important problem. This approach will devastate team ethos, restrict personal development and make your team run for the door.

  1. Beware of the customer proxy.

Agile, as applied to medical technology and life sciences in general, has strayed into “Lean Start-up” territory by championing customer interaction and feedback early and often. As discussed earlier in this article, getting real customer feedback is virtually impossible for a medical device until it has completed many stages of the development process, hence the approach from many Agile practitioners to solicit as much feedback as possible from customer proxies such as physician round-tables and so on. I have even read an article which suggested that you should try to sell a non-existent product to potential clients as if it were approved and on market! I would never suggest that talking to potential customers is a bad thing, but I would definitely caution against over emphasizing the importance of the feedback as it is not a real life situation. There is a big difference between “would you buy this?” and “will you buy this?” and by placing too much credence on this type of feedback it is entirely likely that a key decision could be made on false premise and assumption.

I strongly believe that some elements of Agile, judiciously applied in the right environments, have real merit, and represent innovation in project management and product development. It has solid Lean credentials; however, it is worth noting that many of the successes to which Agile has been accredited, are really just foundational elements of Toyota’s Lean Product Development System, and have been around for decades (take multi-disciplinary teams, product managers, visual planning and management, daily huddles etc. etc.). This doesn’t really matter, a good idea is a good idea and it is a moot point if Agile is a repackaging of Lean. The bottom line is that the truly new elements of Agile Scrum, such Sprint workload management and user stories, were creative solutions to particular problems in a specific industry, and they do not work at all well in life science product development. Project managers should be fully aware of it as a method, and should understand why it works so well in certain circumstances, but should not feel a need to implement it in any stringent form. The one caveat I would highlight is if there is a software component to the technology you are creating, you should definitely consider Agile Scrum to manage that part of the project, particularly if there is an external partner who will probably expect it.

The people who created Agile were themselves innovating their processes to develop a “right-fit” for them and this is the challenge that faces Med Tech companies right now. What is your Agile? What will allow you to innovate at speed, while minimising risk and ensuring the highest quality? My opinion is that you should focus on excellent Lean management of decisions with high impact AND a high level of knowledge gaps, and use the learning needed to close these knowledge gaps (and make such key decisions without assumption) to form the basis of your plan. Applying appropriate structure to making your key decisions will allow you to rigorously test the level of assumption and drive you to eliminate project risk, and this will increase your speed and predictability. Trust yourselves to figure this out. Who better to innovate process than innovators themselves? Create your own paradigm shift and don’t rely on someone else’s supposed best practice.

If an Agile practitioner darkens your door my advice would be to turn them around and invite them to sprint off in which ever general direction they may choose. Anywhere but here…..

Regulatory Outsourcing- No alarms and no surprises please!

Regulatory Outsourcing- No alarms and no surprises please!

Outsourcing of regulatory support has been on the rise over the last decade and it is now a common practice. The Annual RIM Whitepaper 2016 by GENS & Associates stated that “ Since 2014 outsourcing has been considered a common practice with many qualified suppliers having positive satisfaction ratings”. The primary drivers of this push to externalise are cost saving, organizational flexibility (managing peaks) and increasing operational efficiency. Talent management (freeing up internal resources for higher value adding activities, and ensuring the right people are available for the right job) is also an increasingly important business driver.  Freeing up scarce internal resources would, in theory, allow companies to devote more attention to extracting the value from their regulatory data, feed intelligence back to the business, and become truly valued partners in innovation and execution.

Anyone with experience of externalizing activities will attest that it is not a decision that can be taken lightly, and a cautious, methodical approach is warranted. It requires careful consideration, evaluation, planning and management in order to fulfill the unspoken mantra of senior leaders (and Radiohead!), “no alarms and no surprises”. The evolution of Pharma regulatory outsourcing strategies has been predictable to date, with companies starting small, with functional activities that are quite obviously non-critical, like publishing of routine life-cycle submissions or document support. A combination of increased confidence in the ability of the partners to consistently deliver, and an improvement in the quality of service from the partners themselves, have moved the game on significantly to the point where companies are now externalizing, or investigating the externalization of, more complex and more business critical tasks, such as life cycle management or full functional outsourcing.


Here we present our top ten tips for successful, low risk regulatory outsourcing:

  1. Define your “Why?”, your needs and your goals

The first step is to clearly articulate WHY you are investigating the use of partner support.  This seemingly obvious, but often overlooked, exercise is a critical step in effective change management and your “Why” statement should be a key part of your communication strategy.  It also informs the next critical step:  To document and prioritize your needs.  These needs may reflect pain points in delivery of existing services or the inability to meet the needs of your customers.  A clear articulation of needs and requirements will improve focus when selecting targets for externalisation. The plan to externalize MUST have a solid line connection back to the needs of the business and primary customers.

  1. Identify critical control points and targets for externalization

An assessment of regulatory processes complete with listing of critical control points is an important step in the journey. A Critical Control Point (CCP) is the point where a failure could cause harm to customers and/or to the business, or even loss of the business itself.  For every CCP, the risks of both internal delivery and outsourcing strategies should be thoroughly documented, and accompanied by risk management and appropriate risk mitigation tactics to ensure that everyone knows what they are signing up for, and to begin the process of avoiding the dangers associated with unacknowledged assumptions.  This risk assessment should be a key input to choosing the initial targets for externalisation.

  1. Assess the value

It is important at this point to assess if the chosen targets for externalization will deliver the value anticipated, meet the goals, and fulfill the Needs and “Why” from Step 1 above.   Overlooking or paying insufficient attention to this step is a common pitfall, as teams can make assumptions about the level of value and move swiftly on with vendor selection without adequately testing the validity of these assumptions. Being completely aware of “the things which need to be true” in order to achieve this value is enormously helpful, as “death by a thousand cuts” can eat in to the potential gain as the detail is ironed out.

  1. Define your requirements from an external vendor and select a partner

Once you know what elements you want to outsource, it is time formally to describe what you require from a vendor in terms of description of services, quality of service and capacity requirement. This is a critical document in the negotiation process and ensures that there is full transparency on what is required and expected from both parties. This should be a “two way street” and a good partner will inform you of their requirements also. Careful consideration and attention to the requirements of both parties is vital in establishing trusting relationships. Obviously the selection process itself is detailed and complex involving cost, competency, geography and a myriad of other considerations too numerous to describe within this article.

  1. Plan for the benefits

Planning for the benefits is not as simple as you would imagine, especially when a key benefit is freeing up high value internal resources.  Sure, if you have 5 people who exclusively perform the task that you outsource, it is relatively easy to repurpose these individuals to other activities.  But what happens, as is most often the case, when you remove only part of many people’s daily activity through an outsourcing initiative? I have seen it claimed many times that removing an activity which takes 20% of a person’s time equates to a 20% efficiency gain or productivity improvement. It does not.  Unless you plan for the new, higher value contributions that you desire, that theoretical 20% of time will quickly be absorbed by other tasks. In some circumstances, creating this “breathing room” this may be sufficient value add and can be warranted, but if so this should be the pre-articulated goal.  In general, I would recommend identifying higher value adding activities and planning to introduce the new activities in tandem with removing the old.

  1. Harmonize and standardize your process

The requirements discussion from earlier will have copper-fastened the need for harmonised and standardised processes.  It is imperative that everyone in your organisation needs to be following the same process when interacting with an external vendor.    In order to be able to manage service levels and quality, and avoid issues with execution of process, it is a necessity that all appropriate standards, templates and work aids have been rigorously applied by both parties.  Failure to do so will lead to problem after problem.

  1. Manage the handoff

The hand-off to a partner has many elements, but the over-arching principle should be that things cannot be “thrown over the fence”. The most important thing is that the handover is completed with due care and consideration of what was to follow, and that the interface is visual. We often use online visual management boards (but low tech approaches can also work) as these tools allow you to design in data integrity through standard lists and required fields. Visibility of tasks also allows continuous real-time visibility of the status of tasks and issues arising, and gives an accurate overview of the volumes that are externalized at any given time. This is also critical in ensuring that commitments in terms of volume are not being breached, thereby overwhelming a partner and impacting on their performance.

  1. Manage the transition

Outsourcing is not a turnkey activity.  It requires careful support and babysitting for a period of time. Start small and build from there. Move forward only when you have learned enough to do so and be agile, react to feedback and make changes.  Behave like a start-up.  It is better to start is a small way, and learn rapidly from your experience, than to plan a large scale transition that is reliant on untested assumptions.

  1. Manage the relationship

Creating appropriate governance structures and key performance indicators will ensure the sustainability of the relationship. Maintaining open and honest communication will nurture it and helps it to grow. Be willing to listen and learn from partners as they have a breadth of knowledge that your company does not have, through support of many different companies, regions and countries.

  1. Grow and evolve

By embarking on this journey you will have learned a lot of important things which are worth making an effort to build into your corporate memory. Document your methods and outputs so there is a record of how decisions were made, and convert your knowledge into organisational wisdom so that others will know how to do this again. Continue to look for opportunities to add more value and save cost. Continue to forge partnerships and learn from others with a different perspective.


As confidence grows in the ability of external providers to meet and exceed expectations, and as you learn how to leverage them more effectively, so too will the willingness to attempt more ambitious targets.  You can learn your way to effectively managing and mitigating the risks, and realising the benefits that drove your plan from the beginning.  With a commitment to proceed in a manner, and with a process, that manages that risk effectively, you can avoid unpleasant surprises, and instead of wasting time reacting to foreseeable alarms going off, you can celebrate productive new partnerships and higher value internal capabilities.


Lean Laboratory- The secret to success.

Lean Laboratory- The secret to success.

  My Son, I’ve been told, has a brilliant mind. When he’s “in the zone” he could baffle you with brilliance and make you wonder where all the knowledge comes from. However, far too often, he seems not to be in that zone, unmotivated, uninterested and unable to...

New Product Development- The Predictability Paradox

New Product Development- The Predictability Paradox

Predictability, and the pursuit thereof, is a common theme we encounter when working with large company clients and their Product Development teams. The concept is understandable, as big business must have some mechanism of predicting future performance and...

New Product Development- The Predictability Paradox

New Product Development- The Predictability Paradox

Predictability, and the pursuit thereof, is a common theme we encounter when working with large company clients and their Product Development teams. The concept is understandable, as big business must have some mechanism of predicting future performance and communicating this to its stakeholders and shareholders.

However, many of the traditional steps companies take in the pursuit of predictability, in combination with the pursuit of speed, are counterproductive and ultimately lead to less predictable outcomes and reduced speed due to rework and back tracking.

Let me give you an example. The pursuit of predictability often manifests itself in the form of a design freeze at a certain point in the process. Beyond this point the business does not want any open questions or changes to design in order to allow other functions to kick off their activities in earnest (Operations, Regulatory, QA etc.). Theoretically, the idea of a design freeze makes good business sense and should drive and focus the development teams to ensure that all of the open design questions have been resolved by a particular point in time, thus giving certainty to downstream activity planning.

That theory is fine when the decisions are made well.  But when the quest for speed and predictability, and a rigid focus on deadlines, leads to a lack of vigour in the closure of knowledge gaps, the result is often the making of decisions that have unacknowledged assumptions.

“Unacknowledged assumptions breed unmitigated risk.”

The criteria for making decisions, and the level of knowledge required to make each decision, is often not well defined and the business is reliant on ad hoc inquisitions at a stage gate review to unearth hidden assumptions and unresolved knowledge gaps. Unacknowledged assumptions in key decisions which have been made represent risks to the project that will lead to a significant reduction in the ability to accurately predict future performance, hence the paradox.

Happily resolving, or at least reducing, the risk associated with hidden assumptions does not require a root and branch redesign of your product development processes and relatively simple changes to the execution of a project can have transformative results.

Here are five critical elements to an approach which minimizes risk and improves overall predictability;

  1. Define the project Key Decisions and who needs to be involved in order to make them
  2. Document what needs to be learned in order to make each decision
  3. When making a Key Decision, forensically examine whether or not the prescribed level of learning has been achieved
  4. Where knowledge gaps still exist, commit to learn more or proceed with an acknowledged level of assumption
  5. Treat all assumptions associated with Key Decisions as risks, and plan to mitigate the risk through further action

It is not correct to suggest that product development is inherently unpredictable. Nor is it correct to suggest that it is predictable. Treat each endeavour on its own merits and make a determination about the level of predictability based on the level of risk. Only then can your teams have the confidence that they are moving forward with their eyes fully open, and only then should you communicate to others about what is likely to occur.