A couple of months ago I wrote an article proposed how DSDM could be used even in strictly regulated environments such as the Pharmaceutical Industry.  One of the recent projects undertaken using “most” of DSDM was a project to replace an existing raw material dispensing system.  This is a key part in the manufacture of drugs.

The existing system was developed by a third party, but was going out of support and no longer met requirements.  So we decided to write a new system in house, and to use as much of DSDM as possible during the development.  So what did DSDM provide over our traditional approaches?

Active User Involvement

Whilst the previous system was validated and would dispense correctly in all cases, it was really written without much involvement from those who would use it. The result was solution that was actually quite difficult to use and meant we had to shoe horn our processes to fit.  This time we had the chance to make sure the system would be the best fit for us, because the people using it were the people designing it - we were determined that the solution would come from the users. 

DSDM ensured that they were continually reminded that this was their system, so they owned the decisions about how they wanted it to look and work (within the guidelines!), what was fit for business purpose and what met their needs and requirements.

Integrated Testing

Throughout development, the ambassador users were creating test scripts, running them, finding problems both with the system and the test scripts and therefore amending both.  This ensured not only that the solution fitted the requirements, and was of high quality, but also that the testing validated the real requirements.

Communication, Collaboration and Empowerment

Throughout the life-cycle the users involved, fed-back and consulted the other users.  We used a Project Website which had all the information available for the total project.  It controlled access to the environment as well as listing all the stages, documentation, who the teams were and future meetings. This website was available to the whole organisation, so people outside the project were also able to keep up to date with progress.

When the solution had been built and validated, we ensured that project briefings took place for all areas (including management).  It would not matter how good the solution was if the communication was poor at this stage. Without keeping people informed of what, why, when and how the project had been achieved and what it was delivering, all the hard work which had been put in would be in jeopardy.

Everyone worked towards the same goals. Ultimately, the solution was wanted/needed by all parties.  The team made all decisions, including the design, the look/feel and the operation of the solution.  It must do x but not y.  The only exceptions to this were due to regulatory/validation issues which were taken to the Quality representative on the Project Board for help with the decision.

Iterative and Incremental

The design/build phase of the project was broken down into 3 dispense types.  The first cycle consisted of the pre/dispense/post screens for Full Container and therefore the cycle was longer (12 weeks) than the other 2 (3 weeks each) as these used the already designed pre/post screens and only required the dispense screen to be designed.

The technique that the ambassador users used was to initially design the screen on flipchart paper, and then hand this to our developer(s) to code.  The coded screens were then available for us to review and test and we passed any changes back to the developer(s).  This continued throughout the entire design and build phase.

Parallel timeboxes were performed to ensure all the documentation required for validation was being produced.  For instance, the Functional Design Specification, required by GAMP, was written and developed throughout the iterative approach.  Workshops were used to design the screens initially, these were handed to the developers who delivered prototypes for review/testing.  This was an ongoing process and a ‘living’ document throughout the project, until baselined prior to the required validation testing.

Frequent Delivery and Fitness for Purpose

The DSDM approach ensured screens were available very quickly and that the project continued to progress.  Then comes the one departure from “true” DSDM but one that no one in the Pharmaceutical industry would argue against.  The system deliverables were “delivered” into the validation testing.  Because of the testing throughout the lifecycle (which meant that not only the system but also the test scripts had been verified many times before), this became a formality and very few problems were encountered.   As advocated by DSDM, a risk assessment was carried out to target the testing priorities to the areas that were critical to the business and regulatory requirements.

The Result

Using the DSDM framework on this project, together with some additions for regulatory requirements, has ensured the end users have a system that not only dispenses materials correctly but also meets their requirements and that they feel is their system, since they designed it. Even with the final required testing the system was implemented much faster than a traditional waterfall approach.