 |
ISO 9000 | ISO 14000 |
 GMP Consulting |
Computer Validation as a Team Sport: Project Management Issues Computer validation in the pharmaceutical, medical devices and biotech industries is frequently viewed as a necessary evil. It often is under estimated and under resourced. The United States Food and Drug Administration (FDA) and other agencies have mandates that must be adhered to, but these requirements do not constitute the glitzy part of any project. It is important to explore the psychology and personal dynamics in a project lifecycle, and avoid some of the pitfalls of leaving the ‘paperwork’ until the end. This article assumes that computer validation is good business and engineering practice regardless of the industry being regulated. All too often, computer validation is assigned to a person who is faced with trying to be “Superman” or “Wonder Woman.” Computer validation requires a cross-functional team that is highly focused on the tasks at hand. Sometimes Superman or Wonder Woman as part of the validation team must make an individual sacrifice, but it helps to have the team moral support behind the effort. If the validation activities are not done in parallel during the development/implementation phase, the project team rolls off the project, and the task soon resembles retrospective validation. This adds to the overall cost of the project, and becomes a thankless task where there are no winners. For the validation effort to be successful, it is critical to have a captain to assure that there is a plan, and that the entire team is headed in the winning direction. A Project is Born – The Vision Projects are conceived either because there is a burning need to fix a problem, or because someone has an idea that will help the company achieve its business objectives, and provide a return on investment to stakeholders. Once in a while both reasons coincide. In the 1990’s there was the impetus of the Y2K impending crisis that drove many businesses to replace legacy computer systems. That time period was viewed as a bonanza for consultancies around the globe. Of course, during that timeframe, 21 Code of Federal Regulations (CFR) Part 11 (electronic records; electronic signatures) became an FDA regulation in the United States and scared industry into action. Conferences proliferated and validation consultancies sought to make validation activities seem like rocket science. The justification for many projects is based on intangible benefits like “improved compliance.” So, the company decides to spend the money, and after months worth of effort, the original goal of the project is more or less forgotten, the system works to a certain extent, and then someone realizes that the validation is not complete. Various industry groups like Good Automated Manufacturing Practice (GAMP) provide common sense guidelines, and there are training courses for new personnel to learn about the science of computer validation. Entire career paths have opened up as Industry recognizes that computer validation skill sets are much more rare than process validation skills. Computer validation has become paramount for systems like Laboratory Information Management System (LIMS), e.g., LabWare LIMS, Beckman, etc., Enterprise Resource Planning (ERP), e.g., SAP, J.D. Edwards, etc., Document Management System (DMS), e.g., Documentum, etc. and Supervisory Control and Data Acquisition (SCADA), e.g., WonderWare, Fix D Max, etc. as regulatory bodies focus on electronic signatures and records. These validation initiatives are largely ignored by the project visionaries. Computer validation is, unfortunately, still not viewed by Industry as merely good business practice. Project conceivers tend to ignore it, Quality Assurance (QA) imply that they are the keepers of the flame, Information Technology (IT) do not believe it is necessary, and consultants generally work on projects in diverse industries, so it is an unknown factor. So the project begins and the team is identified. Generally the last people to be named to the project have the task of “computer validation” – whatever that means. The project plan has a single line item task called “validation” and with luck someone has decided to write a validation plan. The document itself is generally thick, a tome on its own, and no one really reads it or takes it seriously. Project Staffing A steering committee is identified and the project manager is named. Key users are identified. Consultancies are interviewed. There is a project kick-off and the project assumes a life of its own. Frequently a name is given to the project that highlights the management focus. The staffing activity should be done very thoughtfully. It is important to consider everyone’s ability to communicate, and their willingness to participate for some months in a group activity. Ensuring that people are dedicated to the project is critical. Telling someone that they should work on the project 25% of their time means that it will be difficult to get their attention when it is most needed. This is true for key users and the validation team. Consultants and contractors are much easier to schedule because they generally have schedules days that are well known, and when they are on site, they are dedicated to the project. If the validation team is identified at the beginning of a project, they can begin immediately to determine the exact details of the methodology for validation to be used. The validation methodology generally followed is that proposed by GAMP. This involves not only a validation plan, but also a User Requirements Specification (URS), a Functional Design Specification (FDS), a Detailed Design Specification (DDS) (if there is bespoke code, user exits, etc. in use), plus the usual Installation Qualification, Operation Qualification (OQ), and Performance Qualification (PQ). The PQ must be conducted in a production environment with the appropriate operating procedures in place, as well as any paper processes that mesh with the computer operations. The selection of the exact documentation set is generally one of the first tasks that the computer validation team must agree upon. There should be an assessment of how customized the software application will be. Exactly how the OQ and the PQ will be executed and what determines success can be decided. The validation team can hold GMP and computer validation training sessions for the consultants, contractors, and key users. They can set appropriate expectations in terms of the level of documentation and the amount of detail to be included.
The Ideal Validation Team To quote the ‘Justice League’: “Sometimes the job is too big for just one hero.” Computer validation requires a cross-functional skill set that encompasses IT expertise, working QA knowledge (including GXP practices and computer validation), business acumen, and software modeling. The members of the team should understand GAMP and software development lifecycle methodology. The team must fulfill many tasks during the project, each requiring a bit of specialization. In order to understand why this must be a team effort, it helps to have an overview of the duties needed and the associated skills, as shown in Figure 1. Role of the Consultant and the Contractor Because IT projects tend to be complicated from a technical perspective, there generally are consultants involved with specialized skill sets. The first consultants to be considered usually have the software modeling expertise or business process re-engineering. These consultants need to thoroughly understand the business processes they are being asked to model. In the beginning of the project, many times the role of computer validation is assumed to be a clerical task at best, and there are no staffing considerations for external resources. Because the pharmaceutical industry is not on the forefront of IT projects, in some ways, project managers are naive. It is easy to suggest to the sellers of consulting that there is some “validation” required without the consultancy realizing the implications. The very term “validation” to a non-pharmaceutical industry person can be translated to mean “verify.” It probably sounds like ‘some documentation’ will be necessary. What this means from a project perspective is that the first few weeks of the project generally are a steep learning curve for the consultants in terms of the specialty of this industry, the key users in terms of the software application, and the programmers doing the customization in terms of understanding good software development lifecycle practice. Many pharmaceutical companies do not distinguish between consultants and contractors. A “consultant” is a hired expert with a specific skill set who is paid to provide services, foresee problems, and assist in resolving issues. A “contractor” is more of a ‘body shop person’ in that no matter what the task, they will be paid to do it – make coffee, change the toner in the printer, write documents, install software, whatever. In general, “consultants” are treated like professionals and “contractors” are viewed more like hourly employees. It is crucial for the project to recognize the difference, and to determine who will do what type of work. Both types are needed, especially on large projects. In general, validation expertise, in terms of philosophy, documentation organization, management, planning, and execution should be handled by a consultant. The person ideally has previous computer validation expertise of a practical nature, and also understands the regulations and the software. A number of reputable organizations provide such services and have proven track records. A practical example of this role involves implementing SAP (an ERP system) where decisions must be made relative to:
However, additionally, there is a true role for a “document administrator” – someone who is computer literate, organized, meticulous, and a self-starter in order to keep the documentation moving. This role may or may not be viewed as a permanent position, and can be out-sourced to a contractor. In order to produce the best documentation possible, it should be considered from the beginning of the project. If the same SAP example is used, the tasks for this person are enormous and involve:
Typically, the validation documentation set grows enormously over time. A validation consultant once said that it falls into three categories:
The War Room The concept of a war room is not new. For projects in this industry, it is critical for the project team, including the validation group, to be physically located in close proximity. When the consultants, for example, are placed in porta-cabins, it is easy for them to remain isolated, in a vacuum of sorts. The key users don’t get to observe how the modeling is done, and the validation team does not understand the models at all. The whole idea of having a project team with external resources is to provide a knowledge transfer. It is important to get the biggest bang for your buck, and the way to do that is to become a sponge for the knowledge to sink in. After all, it is the company who must educate the consultants as to their business practices, and the consultants who must educate the client as to the functionality of the application. People, in general, do not like to sit all together, because there is a certain lack of privacy. However, it does breed an intimacy and a sense of camaraderie that makes for a real team spirit. When everyone hears the conflicts and the choices that are made, and knows what discussions have taken place, they develop an ownership “buy into” the concepts and the models. It helps to minimize the number of phones. The project managers should also sit with everyone else – consultants, contractors, IT staff, key users, and validation team. If the manager sits in an isolated office, it is often difficult to really know what is going on from minute to minute. Sitting in a big room or on the same floor of a building often helps to minimize the disruptions. Key users, in particular, suffer from the fact they had a job before they got this one. Good key users are generally the most valuable people in an organization, and are thus in high demand. If they are removed from their normal surroundings, they are more likely to be replaced and less likely to be distracted. The war room should also take into account the needs of the validation team. There should be sufficient space to keep the validation documentation (and system documentation) for the duration of the project. Printers in the room are important, since there are a lot of screen shots required, and many documents are maintained in hard copy (paper). The validation people are most efficient if they can ask quick questions to the key users and the software experts. Preparing validation protocols and test scripts in external locations is always difficult. In the war room (or in very close proximity) it is also beneficial to have a table for quick, ad hoc meetings, and several whiteboards for those times when a picture is worth a thousand words. A conference phone also is useful for discussions with software application providers or colleagues who are not on site. Now, We Are Live! Now What? The consultants and contractors are rolling off the project. There is a sudden sense of panic when the first lines of support, the people who know the software application as configured the best, begin to leave. Major questions include:
The most important thing to recognize is that computer validation is not a one-time event. It is not something that you can afford to put on the shelf to collect dust. It needs to be maintained over time. The fact is that software applications are going to change, probably more frequently than expected, and the validation status and documentation must be kept synchronized. How to Prepare a Computer Validation Report The principal requirement for the preparation of the report is to be intimately familiar with the raw data, test protocols and scenarios, software application, and the personnel who conducted the actual testing. Without an in-depth view, it is nearly impossible to summarize the data from the various test cycles in a concise and understandable way. Keep in mind that the validation report is largely written for an audience who are not that familiar with the process or the application. It is one of the first documents you would be asked to show to an FDA inspector who questioned your validation of the software application. There are some basic principles:
Computer Validation Documentation Reviews The role of the documentation reviewer is a bit like that of the schoolteacher who is going through a series of essays, term papers, and data. To be effective requires a quiet place, a chunk of time, and plenty of room to spread the various documents out. (This review is the critical one before the report gets issued officially because it saves time in the long run.) The last item you want is to see ‘Revision .006’ on a final validation report because that implies that much more happened than is recorded, or that the report itself was not well-thought out prior to its writing. So what to look for includes:
Now it is Audit Time Ideally the team who participated in the validation activities of the project are still in place, and have maintained the documentation in an orderly fashion. There should have been a mock audit with someone external to the validation team to help hone their skills. An audit preparation plan is in place, and is executed without panic. Counseling is done for those people who “freeze” during questioning. If computer validation has truly been a team effort, then there should be no issues with a set of questions from any auditor, whether FDA, client, or another regulatory body. About the Author Linda Forstedt has 25 years experience in manufacturing and process control engineering in both the semiconductor and pharmaceutical industries. Currently she is working as a GMP consultant in Holland. She can be reached by phone at 003-17-1524-2725, or by e-mail at forstedt@gotomy.com. Article Acronym Listing
|
|