Don’t forget that in an Information Systems CSV environment there is much more, depending on the GAMP (if applicable to your company) category you are operating in. Including, in addition to the above mentioned message, but not limited to:
Invitiation To Tender (ITT)
Vendor Auditing & Selection
System Requirements
Software Development Plan
Unit Specs & Unit Tests
System Specs & System Tests
Technical Installation Plans & Reports (Developement/Test Environment)
Technical Installation Plans & Reports (Production/Go-Live Environemnt)
Deployment Plans
Change Management Plan
Configuration Management Plan
Document Management Plan
Training Plan
Project Support Plan (post ‘go-live’)
Service Agreements & Licenses
User SOPs
Incidident Management Plans
Bug/Issue Reports
Project Planning
WBS
Risk & Issue Management
IQ & OQ for development/test environment?
Configuration Verification
IQ for production/go-live environment
Post Implementation Review (PIR)
I understand that you can have all of the headings that you mentioned, but when do you say stop!.
If you developed a document for each GAMP requirement it could take a long period of time before your application goes live.
I assume all of this will be decide in the risk assessment anyway, from my experience there seems to be standard set of documents that are always generated and documents such as Incident Management Plans and
Bug/Issue Reports are just fluff that is not really required.
I would agree…almost. My advice is to follow the GAMP categories and/or clients Policies and Procedures, certainly in Information Systems or Process Controls systems. In most cases it is quite resonable (with justification) to combine deliverables also.
I think the safe way to do all of this is to make sure you justify the approach you are taking within the Validation and/or Project Plan. However be very, very sure you are in compliance with the clients Policies and Procedures. I have been on FDA inspections (only as an observer) and have heard the dreaded statement/phrase from a ‘Systems Inspector’: “if you are not in compliance with your own company policies and procedires, how can you possibly be expect to be in compliance with the FDA CFR”!
Actually, the biggest thing I learned from working at a company under Consent Decree was exactly what your wrote. If you can’t follow your own procedures you surely do not follow GMPs.For computer validation it is “Do what is written in your plan” Not following plans or SOPs are what an auditor calls low lying fruit, why would an auditor break out the ladder to get the top most fruit when here is this juicy apple on this low branch. I have seen numerous companies kill themselves trying to meet “GAMP” in their plans. I say GAMP is a good start but typically unattainable, therefore the company must define their SDLC and follow.
Also, I sometimes will write a project plan that defines the entire project, and define what is required for GMP compliance and what is outside of the scope of the validation. That way if I don’t write a “project support plan,” an auditor can ding me for not being validated. With this approach I will also write a validation plan that details the validation. This is the document I give to an auditor.
Very interesting to read your comments on GAMP there also, and again I would totally agree with your project approach. GAMP is just a ‘reasonable guidance document’ and/or sub component of “proposed” GxP project deliverables; this must be remembered (particularly by the Project Manager) when mapping out a major project or you will die as a Project Manager/Organization.
PS. I am neither pro or anti GAMP. In my opinion it’s just a reference document; not a full life-cycle project management methodology with integrated SDLC.
I also like to have a configuration specification for off the shelf systems. also a commissioning plan can be useful if you don’t specify in validation plan.