The need for Agile Innovation

Big Bang Innovation

We are occasionally asked by organisation why they shouldn’t simply bring in the large consulting firms to solve their development challenges?  We are absolutely not against large consulting organisations.  Program execution with a large Life science company often demands large and well resourced vendor firms to deploy change. We work with these companies.

However, we believe that innovation cannot be created by committees.  Big project innovation requires big project management and big budgets.  The only sure thing in these kinds of innovation programs will be high expense and long durations.  Agile – by definition – is about keeping things lean and fast.

Agile Innovation

The term ‘Agile’ has been used and abused. However, in software development terms, it has been applied with tremendous success for a number of years.

When defining our innovation consulting offering, we decided to apply a number of the methods used in agile development to innovation.  The root of the agile approach derived relatively recently, from a small team formed back in 2001 that defined the ‘agile manifesto’.  This approach was specifically designed to redirect a focus in the way software development was carried out;

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Lets look at each of these in turn, and discuss how they apply to the field of innovation in clinical research.

Individuals and interactions over processes and tools

As someone who has worked on both tools and processes extensively, I first of all baulked at the idea of them being put aside.  However that is not the point. The idea is more to focus on the individuals that participate in an activity and to determine how they interact.  This may lead to processes and tools, but it is not the processes and tools that come first.

Working software over comprehensive documentation

A nice one – of course we cannot do away with some form of documentation – but, ultimately, it is the working software that really matters.  In recent years, we have seen better designed software actually supplement documentation.   Basically – it is self explanatory and does not need exhaustive words to understand how to configure or use it.

Customer collaboration over contract negotiation

An interesting concept … but surely we need to work within a contract …  yes. What is suggested here is that the terms of a contract should not necessarily govern the effective design of the solution.   Collaboration will define the details of a solution to meet requirements.

Responding to change over following a plan

My personal favourite.  This is saying that handling change is more critical than adhering to an original plan. Lots of new information and ideas are usually uncovered during the process and it’s only natural that these are incorporated during the process. The way we like to interpret that is that the change aspect of project management takes priority.

Innovation Manifesto

When executing innovation in a life sciences R&D group we can take the above manifesto principles and apply them specifically against the challenges we see.

Individuals and interactions over processes and tools

Typically a set of processes within a clinical R&D section are put together after the process has already been implemented. They rarely describe the use of technology and they rarely attempt to optimise work methods.  They document.

With a focus on individuals and interactions, we analyse how people work with tools and process.  We measure, assess and appreciate what works, and what does not work.  The resulting picture gives the information necessary to make decisions that may influence people , processes or technology.  We document the ‘as-is’, but also highlight to potential for ‘to-be’ processes, people and technology.

Working software over comprehensive documentation

This may seem like a high risk approach in Clinical R&D – but, when used appropriately, we believe it is correct.   Pharma does not want faulty software supported by good documentation.    The correct emphasis here will ensure that the software is as good as it needs to be and well documented so that any  gaps in understanding are filled.

Customer collaboration over contract negotiation

Innovation is all about collaboration.   When the eClinicalHealth team enters into an innovation project, our first step is collaborative discovery.  It is about jointly understanding – and documenting – the organisational challenges, and the potential improvement opportunities.   Contract negotiations still occur, but as part of the process and not at the cost of effective innovation.

Responding to change over following a plan

We do believe in plans – plans are important – they set out a schedule, list of actions and responsibilities.  However, even more important in Clinical R&D Innovation is the need to adjust this plan as priorities are seen to shift.   A plan is simply a representation of your approach based on the information at any given time and as new information is uncovered, plans also must be adapted.  It is how the changes are effectively managed that is important.  Unmanaged change is chaos.

Measuring success in agile innovation

Failure to measure innovation is, failure to innovate.

Innovation is the start point. It is about putting together a solid evidence case for change.  Executives need facts, backed by figures, to support business spend.  Without the facts – risks are high, and failure increasingly likely.

 

More articles on Innovation

For more about eClinicalHealth – read here

Contact us to discuss Innovation

 

Leave a Comment