Agile in GxP CSV Environments: The Use Case

- Ecaterina Altemüller

Introduction. 

This article tells the story of a team I had the pleasure to lead on a GxP project in a Healthcare company. The team members were of different age, professional background and culture. Most of them had the project work on top of their regular daily work. They showed extraordinary dedication and genuine curiosity for the new agile approach I introduced to them. 

The task at hand was to replace an electronic Document Management System (eDMS) with a more user friendly and intuitive solution. First, we wanted to make sure that the selected solution satisfies these criteria not only on paper but also in practice. Therefore, we built a Proof of Concept (PoC) environment and invited all our Subject Matter Experts (SMEs or key users – used interchangeably) to test it. After getting the thumbs up from the SMEs and the Steering Committee, the full-scale implementation followed. 

While there is a lot to share, I would like to focus on three points in this article. The first section – “To Scrum or not to Scrum?” – shows my perspective, as a project manager, when selecting the optimal approach for this project. The other two sections present the measures I took to facilitate the team to the Scrum way of thinking. More in detail, the second section – “A story about the user story” – illustrates my experience with introducing user stories to the team. The third section – “Sneak preview” – highlights some of the challenges we faced when giving the SMEs early DEV access to the new system. 

To Scrum or not to Scrum? 

Scrum (or agile – used interchangeably, which does not limit agile only to Scrum), eDMS and Computerized System Validation (CSV) could be regarded, especially by those of you knowledgeable of these topics, as three puzzle pieces that don’t really fit together. While it is true that eDMS implementations are rather straight forward and CSV requires documentation before action (quite the opposite from agile), I believe that Scrum can add value even in such traditional settings. Let me define each of these three puzzle pieces one at a time. 

Let’s start with eDMS. The reality is that the eDMS market is a mature one. That means there are enough vendors claiming to offer best in class eDMS solutions waiting to be configured according to your industry and company needs by switching on or off readily built features. The development per se, where functionality is being built from scratch, is kept to a minimum. Therefore, eDMS implementations are straight forward, “no thrills” software configuration rather than software development projects. 

Let’s continue with GxP and CSV. In heavily regulated industries, such as Healthcare, GxP is a collection of quality standards to assure safety and efficacy of products for the patient through delivering high quality of e.g. laboratory, manufacturing or other processes. IT systems used to support such processes must undergo CSV. That means, the System Development Life Cycle or Change Control has fixed stage gates with specific documentation (as specified by the company validation framework) and milestones aligned in a waterfall sequence (DEV to VAL to PROD). 

And the third and final puzzle piece, Scrum. Without going into details, Scrum is an iterative approach or an agile framework for teamwork that defines the team structure, artefacts and events. According to Shenhar and Dvir (Reinventing Project Management” by Aaron Shenhar and Dov Dvir), iterative approaches are best suited to deliver good results in situations of great uncertainty. Therefore, it is not a coincidence that Scrum first picked up for software development projects. The more certainty on a project, the more suitable the classical project management approach becomes. 

This brings us to the point. Great uncertainty is definitely not a characteristic of the eDMS implementation projects. And how to go about the waterfall-aligned documentation and milestone requirements as per CSV? In other words, how agile can you be on a “no thrills” software configuration project that imposes documentation and milestones that seem to misalign with Scrum? As I show in my article Agile in GxP CSV Environments - The Concept, Scrum can benefit even regulated projects by providing the means to end this-is-how-it-was-always-done cycles: a fresh way of thinking and working. 

To read further please register here

Name *
Name
Request

Please also read my first article of this series: Agile in GxP CSV Environments: The Concept