Comment
Boosting agility to accelerate project timescales
Traditional two-year project cycles are no longer practical in today’s fast-changing business and regulatory environment. Pharma businesses must boost agility – whether through adoption of accelerated, technology-aided processes, or rolling out and exploiting a more agile approach to development. Vice-president of strategy for life sciences at Amplexor Romuald Braun explains more.
Pharma businesses need to be increasingly nimble, agile and responsive to the changing market conditions they are operating in. More often than not, they look to technology to help make this possible. So, when ‘transformational’ projects look set to take 12-24 months - or longer - before business owners are likely to see any benefits, this can feel quite jarring.
This is particularly the case given that global compliance is a moving target. Requirements are being updated and supplemented continuously. This makes it impractical to try to define all probable needs up front, then lock down an IT project and go through all the rigorous sequential stages of designing, approving, developing, validating/testing, piloting and rolling out.
By the time that end point comes, there is a strong possibility that needs will have changed and new regulatory requirements will be coming through. This then necessitates a new round of modifications and additions – incurring more delay, cost and frustration.
There has also been a growing realisation that major IT investments can and should deliver more than the immediate specific requirement. Where possible new systems should feed into and contribute towards bigger transformation ambitions – those geared to improving operational transparency globally, for instance; and/or cost-efficiency and speed to market.
These strategic plans may involve harnessing some degree of smart process automation, using the latest AI capabilities as these emerge and become more reliable and affordable. At the very least they should take into account a broader view: for instance, how the new system will connect with, draw from, and add value to other core business systems.
Continuous engagement
Improved agility is not something companies can achieve overnight. It might appear to be the case with so many out-of-the-box, cloud-based software solutions now available, but these can be a compromise too far and still demand a hefty amount of data preparation and migration before they are ready to use, and before they can be trusted.
Rather, business and IT teams need to adopt a more iterative and collaborative mind-set and culture as they approach new system requirements, because there are ways to accelerate even fairly bespoke projects if all of the stakeholders involved are prepared to plan and manage developments in new ways.
Business and IT teams need to adopt a more iterative and collaborative mind-set and culture.
Agile software development typically involves a much closer and more continuous engagement with the IT supplier – including monthly meetings to discuss progress and feedback; suggestions of tweaks to keep the evolving system tightly aligned with the latest needs of the business.
In a regulatory information management (RIM) scenario, this regular dialogue would provide an opportunity to feed in the latest authority guidelines and data standards as these are announced and firmed up.
Since agile development happens as a series of short ‘sprints’, a continuous collaboration ensures that no part of the project can go too far along one path without reconfirmation that this remains the right course.
Concurrent activity
Another feature of agile development projects is that different aspects of the work can be progressed in parallel. In the case of a first formal RIM system, when there is so much contributing data to locate, verify and clean up/prepare, it makes practical sense for this work to be happening alongside the system development/configuration process.
This will help ensure that by the time an approved system is operational, it can be populated fairly swiftly with a reliable master resource – one that multiple applications and types of document will be able to draw from.
This concurrent activity is important also because software release models are more fluid and continuous in an agile development environment. Start-up application companies will often talk about putting a ‘minimum viable product’ (MVP) into users’ hands, so that people can start to interact with the product and check that it works well for them.
The thinking is that it is far better to discover at an early stage that improvements could be made, than to expend time and budget finessing a system that has inherent design or functionality flaws.
Shorter, iterative release cycles – a prominent characteristic of collaborative, agile development processes – will ideally be supported by convincing, meaningful data so that users have a realistic picture of what they’ll be able to do once the new system is more fully formed.
Success and speed of delivery will depend on everyone’s mental preparedness.
The more they can visualise what the finished product will look like and what it will do for them, the greater the chance that users will accept and embrace the system and use it to its full potential.
While much of the direction and synchronisation of the agile process will be down to the technology vendor, internal IT teams, business sponsors and user groups will need to be primed to support the agile development process. This needn’t take up huge amounts of their time: actually, key representatives are more likely to be involved at just the stages that are relevant to them.
But success and speed of delivery (the ultimate goal here) will depend on everyone’s mental preparedness – their proactive involvement and commitment to being part of the whole journey.
IT teams are likely to have a good understanding of agile delivery, and associated methodologies and tools. However other parts of the organisation may need bringing up to speed on the benefits of the approach and what it means for them.
Quality teams, for example, may be concerned at any deviation from the traditional V-model/linear development approach, and the implications for rigour around defining and validating requirements. If so, it will be worth involving them in discussions about how that same rigour can be carried across to a more incremental, iterative development cycle, which features all of the same checks, just on a more frequent basis and smaller scale.
Cutting time to deployment by half
Pharma businesses know they need to develop new systems more quickly to meet fast-changing market requirements. There is a renewed drive to exploit technology advances to improve operations.
Adopting an agile development practice could result in a good 50% reduction in time to deployment – even for customised solutions. Organisations that embrace agile processes will be best placed to innovate and to meet changing customer demands ahead of the competition.