Legacy Replacement

To manage the logistics of clinical trials requires accurate, reliable, flexible systems.  When those systems near their end of life, how do you manage their replacement?

Founded in 1980, Marken supports the premium logistics of Pharmaceutical, Biotechnology and clinical service companies. With over 400 people in 23 offices around the world, Marken manage the collection and transport of specimens, and the distribution of clinical trial supplies through customised programmes to ship items globally and deliver locally to investigator sites or directly to patients.

Marken needed to develop a new suite of systems to support their service aspirations and desire for innovation while at the same time, maintaining the legacy systems which underpinned current operations. The business runs 24×7 and is highly focused on tailored services for each of their clients so there was no opportunity to define a fixed specification of requirements, develop it and then undertake a switchover.

Marken decided the new software should be designed as the project progressed. Instead of a detailed plan, the development would be guided by a high level vision while functions and their priorities would be decided en route with reference to the evolving needs of the prime stakeholders.

After an unsuccessful attempt with an offshore software vendor, in 2009, Marken commissioned Pinesoft to undertake a piece of work and were impressed with the results of using Agile methodology. So a dedicated team of developers was ordered and the work quickly scaled up with an increasing level of collaboration.

The team use an iterative scrum approach to manage the software development process. As new priorities emerge, the sprint backlog is adjusted so that the most important things for the business at that point are developed first.

Using scrum allows Marken to consider and amend requirements as the project moves ahead. Hence, effort is expended on the most valuable functions and waste is cut down to a minimum.

Scrum requires the dedicated input of a Product Owner. The Product Owner is someone who represents the voice of the customer and prioritizes the items of software to be developed – known as user stories.

For Marken, the Product Owner is CTO, Simon Kirk. Simon fosters an open and collaborative work environment where each member of the team is familiar with their colleagues’ workload and contributes ideas and expertise in order to further the project. An important part of the process is the daily “stand up”, a meeting that Simon himself takes part in.

Simon observes that many organisations attempt to avoid risks. Marken however, has a culture of selectively embracing risks in order to innovate, extend and improve services and thereby differentiate itself from competitors. To accommodate this culture, a fundamental philosophy is that Information Systems cannot be compromised.

Therefore the project has been designed around systems continuity alongside innovative and flexible systems which meet the evolving needs of the business.

This is a tough challenge for Simon. Popular perception of IT projects is that the most difficult aspect of implementing new IT is the new technology itself. However, the majority of new systems are going into businesses with an existing infrastructure supporting on-going revenues. Therefore the most challenging aspect of new systems projects is usually the management of 2 systems running in parallel.

There are financial costs to consider, pressure on timescales and milestones, communication with stakeholders and maintaining positive momentum in the face of unforeseen challenges. These factors are not just 2 times the scale because there are 2 times the number of systems. Instead, there are the 2 systems plus many interfaces between the systems to set up and maintained.

So this is a key management challenge that Simon faces.  And so far, he is succeeding.

“The final stage – and the completion of the primary aim – is now in sight” he comments.

Marken has been able to grow and develop without the stress and business risk of turning off legacy systems. Despite the comprehensive cover, development costs have been much less than a large integration company would have charged.

How do you manage replacement of legacy systems? The answer seems to be that you embrace them as business risks, develop alongside them, as part of a long term vision and they will ultimately become redundant without creating any adverse effect on the business.