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), 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.
Therefore, for me the question is not “To Scrum or not to Scrum?” but rather “How much to Scrum?”. In line with the argumentation presented in the above-mentioned article, as long as you are in the development environment (DEV), the sky is the limit. Well, not exactly. Your team is the limit. The greatest priority, especially with teams new to agile, should be the implementation of the Scrum way of thinking. Without it, the implementation of the Scrum way of working is doomed for failure.
Back to the eDMS replacement project mentioned above, we started with clarifying our project priorities in terms of what we, as a team, want and don’t want. Besides building an intuitive, user friendly system, we wanted to prevent the following pitfalls:
Unmet key user expectations during the User Acceptance Tests (UAT);
Unmet key and end user expectations after the Go-Live;
Waste, especially the one that would result in firing up the change management process for reworking our validation documentation or in late reconfiguration;
Lack of transparency and misalignment within the team.
But how would you know whether you met the expectations of your users? You won’t if you fail to define those expectations first. We started however one level below by identifying our project stakeholders. We tried to select key users that are representative to our end user community of about 2500 people. By meeting the expectations of these key users, there is a high chance to meet the expectations of our end users as well. We then went ahead and defined our Change Management approach and the initial Communication Plan.
Finally, we officially kicked-off the project by conducting around 40 interviews with our key users and other stakeholders. The scope of these meetings was to initiate our official project communication on one hand and collect and manage input and expectations about the successor solution on the other hand. The results were documented in the questionnaires we used as a guideline during the interviews.
Well, is it enough to define expectations? Not really, you must also deliver on them. Therefore, we needed a project approach that would reduce the risks of ending up with unmet expectations. Once materialized, such risks lead to issues impacting not only your user satisfaction but also generating a lot of waste due to change requests, rework of validation documentation or system reconfiguration and even scope and financial repercussions or postponement of the Go-Live. As I believe that the waterfall approach cannot reduce such risks, Scrum felt like a natural choice.
And here we come again to the same question: How much to Scrum? As the project team was totally new to Scrum, I placed the focus on implementing the Scrum way of thinking by applying these two measures:
use an iterative approach for user requirements definition and
provide the SMEs with early DEV access and engage them in feedback loops during system configuration.
The following two sections describe my experience with each of these measures.
A story about the user story.
One of the first things you do when implementing a technical solution that must be validated, is to define the User Requirement Specification (URS). In case of new system implementations, you start with a blank page or, when available, with a set of best practice requirements provided by the software vendor. In case of system replacement projects, with the legacy system come along the legacy user requirements. Depending on the case, some of these legacy requirements could be reused. If you prefer to avoid anchoring, start anew.
For the eDMS replacement project, we aimed at defining easy to understand user requirements focused on the business need rather than on the technical solution. Therefore, we decided to use user stories. The structure of a user story facilitates the focus on the business need by stating:
who is the actor or the user role,
what she/ he should be able to do or see in the system and
what is the business benefit.
We went through this exercise during our kick-off User Requirements Workshop. The core team and more than 20 SMEs (who flew in from around the world) sat for three days together with the software vendor to produce the first draft of the user stories. The input was used to draft the URS, which was circulated after the workshop among SMEs for further feedback collection and agile iterations.
After additional demos and numerous feedback sessions with the SMEs and further end users from the internal organizations of the involved functions in the form of consultations, reconciliations and a lot of hard work, we closed the loop two months later with a second three-day workshop. During this second workshop, the final version of each user story was discussed in detail and confirmed by the SMEs team. As such, the User Requirements Specification was fixed and ready for approval. The document was signed later, in conformance with our validation framework, by more than 20 people.
Bottomline, we ended up with less than 200 user requirements out of which roughly 85% were user stories and 15% were classically formulated requirements. For cases such as data migration requirements, or system performance requirements, we decided to stick to the classical formulation.
To give you some additional numbers for comparison: it took about eight months to define more than 1000 user requirements for the initial system we were looking to replace. While this is not a clean and fair comparison, it can show what an impact an agile approach can make. We spent one fourth of the time to define and shake hands with the SMEs on the User Requirement Specification for the successor solution. Ending up with one fifth of the number of requirements was also a sweet achievement. Think about tracking 1000 requirements throughout your Requirements Traceability Matrix (RTM). How about just 200? Better, right?
As good as it sounds, there is always room for improvement. First, as your team’s experience with Scrum grows, go one or several steps further. Make sure you have the support of a validation resource with knowledge in agile approaches, however. A user story is not whole without a proper Definition of Done (DoD). As the name implies, DoD lists the criteria that once fulfilled qualify the user story or the requirement as done. Define your project DoD and while following it through for each user story, use the input to feed your RTM and Specifications (e.g. Functional, Configuration or Design Specifications). This way, the technically oriented input (including the one from your SMEs), will be captured in the right set of documents.
Second, while still in DEV, consider keeping the URS open to allow for updates as the users get hands-on experience and the system functionality matures throughout the test cycles. Sign the document, as required by your validation framework, once the requirements mature. Due to the strategic importance of the system and involvement of all R&D functions of the company, we decided at the beginning of our project to start with an officially signed URS to better manage stakeholder expectations. Even in such a situation, you can integrate additional viable requirements into the URS before closing DEV activities and have it signed off before moving to VAL. For further thoughts about validation on agile projects read Agile in GxP CSV Environments - The Concept.
Sneak preview.
Now that we talked about the user requirements definition, let me expand on the second measure we took: providing our SMEs with early access to DEV so that they could familiarize themselves with the new system and actively participate in feedback loops during the system configuration.
As mentioned above, we gave our software provider the chance during the User Requirements Workshops to hear directly from our key users about their requirements. Following the initial three-day User Requirements Workshop, we had a follow up Configuration Workshop where only the core team and the representatives from the software vendor participated. The scope of this workshop was to close additional open points needed to build the first version of our PoC environment.
The SMEs got DEV access once the first prototype was built. In addition to one-on-one discussions and input on daily basis, during the following months we had weekly calls to inform the SMEs about the project status and the new functionality available in the system. They would also share their feedback for the features they had the chance to test. The communication with the software vendor was clustered around the Daily Scrum calls. While we had a successful PoC endorsement that enabled the full-scale system validation and implementation, we went through several challenges. I would like to further share two of them.
The biggest challenge we had was with the transparency on our software provider’s end. After a couple of escalations and introduction of Daily Scrum to increase transparency, the vendor finally assigned a dedicated hands-on point of contact. She did an excellent job to move things forward and increase visibility. My takeaways on this topic are:
Early system access helps increase transparency by showing what was built and what was NOT built by the software provider in the system. Potential side effect: SMEs lose steam and motivation if the functionality that interests them is not built in due time.
Besides creating transparency, Daily Scrum creates accountability and responsibility for each individual team member. Potential side effect: these meetings can turn into long sessions when participants are insufficiently trained in Scrum.
A dedicated hands-on point of contact on provider’s side can significantly improve visibility when their developers/ configuration specialists cannot directly engage with your team in an agile manner. Potential side effect: get the wrong person or lose the right person and the benefits are zeroed.
The second challenge we faced was related to one of our project resources: the on-premise DEV environment. The compute and network capacity of our DEV was insufficient to simulate the potential production performance of the new system. Additionally, attempting any configuration in it was a real challenge due to its’ slow performance. Therefore, the configuration was done in one of the environments of our software provider and copied across to our DEV. Mistakes were inevitable. As such, we decided to provision a new DEV environment. We ordered the hardware and waited for it to arrive. Those of you who went through this process know how long it can take. While I have no magic solution for speeding up the delivery of system components, there is one alternative.
If you have a qualified cloud provider and your data classification allows for it, try a cloud environment for your DEV. You can purchase and configure resources online in minutes and you can shut them down, again in minutes, once your project is finished. Make sure to use services that are in line with your compliance requirements and consult your internal IT experts before doing so. Besides flexibility, scalability and high availability, a cloud environment can offer a great performance needed by the developers when building the new system, no matter of their location. If you have the chance on an agile project, or any other project, to use agile resources, as cloud resources are often called, do it!
To wrap up, we had a strong project kick-off that generated enthusiasm and high engagement not only among our SMEs but also across our end user community and key stakeholders. Yes, we might have lost the momentum somewhere along the way, faced numerous challenges, but we also learned a lot of things that took us further. We supported and, above all, constructively challenged each other to come up with creative solutions and have a successful implementation.
Conclusion.
This is the story of a great team of about 30 open-minded and courageous people rather than a story about Scrum. Their commitment and enthusiasm for the Scrum way of thinking amazed me. I believe that we, people, stay motivated and active on a project as long as we have visibility into what has been accomplished and is expected of us, and continuously have the chance to learn new things and apply what we are good at. This project experience strengthened this belief even further.
Successful projects are all about finding innovative ways of doing things rather than about trying to inappropriately force Scrum or any other framework or methodology on a context no matter what. How innovative can you be? It depends on how much your team can absorb. If new to Scrum, pick a couple of artefacts and events to facilitate your team to the Scrum way of thinking. Once their agile experience matures, focus on implementing additional elements of the Scrum way of working. Finding the fine line between comfort and disruption is the key. For further details about the Scrum way of thinking and working read Agile in GxP CSV Environments - The Concept.
Whatever approach you choose for your IT system implementations, keep the users at the heart of your project while assuring that a transparent and honest communication flows through the project’s veins. To ensure that the benefits go beyond the project lifespan into the production phase of the new system make sure: that your hands-on key users are empowered and representatives to your end user community and that user expectations are constantly managed to avoid over-engineering (e.g. of the IT solution) while creating user buy-in. A user-obsessed and failure-friendly culture, as advocated by the Scrum way of thinking, facilitates all that. Be empathetic however, changing a team’s mindset takes time. Yet, it is totally worth it.
Please feel free to get in touch with me for the sake of further exchange or just send me your comments.