In a project management framework, FDA requires computer systems to be validated (CSV), meaning we prove “a system does what it purports to do.” A computer system must be maintained in a validated state throughout the system development life cycle (SDLC). We can implement, validate and manage a computer system using a standard risk-based approach throughout the phases of the SDLC. CSV and SDLC phases, components and activities can be incorporated into an overall project management approach for Better Compliance Assurance. Project management components are project charter, project plan, project risk, resource allocation, roles and responsibilities, project budget, project documentation, quality management and project close-out.
1. Project Charter
The project charter provides: An overview of the rationale for the project, including a business case (cost benefit, ROI), a means of contracting with users and key stakeholders as to phases, deliverables, timing, budget, and scope, identification of the project organizational structure, including the Sponsor and other key participants, a means of keeping the project on track by maintaining the Charter as a ‘living’ document, which should be updated as changes occur.
2. Project Plan
The project plan provides a detailed set of phases, activities and tasks that may be tied to specific milestones and deliverables. A complete work breakdown structure that details the steps involved in accomplishing work. An understanding of timing, including the dependency of tasks on others (predecessors). A snapshot of resources required at every stage of the project in order to allocate those with the correct skill sets at the appropriate times.
3. Project Risk
Project Risk should be assessed at the beginning of the project, with all risks documented. A profile should be developed for each risk that indicates the probability of occurrence, the severity of the impact. Any mitigation that can be used to minimize or eliminate the risk should be continuously evaluated throughout the life of the project to manage it effectively, and should include identification of any new risks posed. Mitigation efforts should be documented in terms of the decision(s) and action(s) required in executing them and it must be communicated to leadership and other stakeholders, as appropriate.
4. Resource Allocation
Project resources should include management activities, technical experts, subject matter experts and any other personnel required to effectively complete the effort. Once the detailed work breakdown analysis is complete, and the required tasks and timing are known, the skills required to complete them should be identified. Resources with the required skills, who are available during the time required, should be identified for inclusion on the project team. If resources are not available internally, contract employees and consultants may be brought in.
5. Importance of Roles and Responsibilities
Roles and responsibilities hold great importance in project management. Roles and Responsibilities should be clear to all participants and stakeholders, it should be realistic and based on skills required, include clear reporting lines (direct, dotted-line, matrix), be expressed as an organization chart.
6. Project Budget
Prior to beginning a project, a cost-benefit analysis must be done that accounts for the total cost of the project, including capital, one-time operating costs and ongoing operating expenses (license agreements, hosting, maintenance, personnel, space/overhead, training). Apart from these, the opportunity cost – what else could we invest in?, return on investment – “ROI”, what hard-dollar savings can be achieved, and over what period of time? (e.g., cost savings, labor cuts, reduced cost of ownership), what soft-dollar savings can be achieved, and over what period of time? (e.g., greater efficiency and/or effectiveness) must also be considered.
7. Project Documentation
All project documentation should be maintained in accordance with FDA regulations: Use of ink; no white-out, pencil or other type of marker. Errors corrected with a single line through the incorrect data/ information, along with the initials and date of the person making the change, and the reason. Every page must stand on its own – document name, document number, version number, date, page X of N, etc. All documentation should be completed as per written protocols, including necessary reviews and approvals. The signature page of any document should identify the meaning of each person’s signature. All cells in spreadsheets or empty fields in test sheets should be filled in or otherwise a diagonal line should be drawn through each one. All documents should be accounted for in the project plan, including the development, review, revision and approval stages; some of these may be iterative, and time should be allowed for such, including waiting time for resources to be available to review and approve them. Documentation should be stored in a common repository.
8. Quality Management
Quality of the project and deliverables should be built into the project plan. A Quality Plan should be developed that addresses: How reviews and approvals should be completed. Who should be responsible for each task? What criteria should be met to consider quality achieved. A complete quality review should be documented prior to releasing the system into production and closing out the project.
9. Project Close Out
Once complete quality check of the system and project is complete, and the system is ready for the production environment, the project can be closed out. All project artefacts (documents, deliverables, etc.) should be stored in a common repository and matched against a checklist. Once the system is in production, it must be placed under formal change control procedures, requiring specific steps and approvals prior to implementing any significant change. While the project may be closed, the various deliverables may be reused or modified for use in the event of a change.