Regardless of the desired end state, it should be considered compulsory to manage validated EDM projects using a waterfall
systems development life cycle. EDM applications have many changing values — users and groups, roles, metadata values, folder
structures, and so forth. Likewise, many changes can occur in work flows and life cycles as projects move closer to implementation
(not necessarily because business analysis is bad, but because the combination of requirements, design approaches, and product
functionality cannot perfectly align).
The business sponsor and functional teams should understand that their functional requirements must be finalized and signed
prior to moving into design. The sponsor and functional teams should also go through the same finalization process prior to
moving from design and configuration to testing and other aspects of the overall plan. The alternative is massive change control
to validation documents, which often delays the project more than changes to true application functionality. The waterfall
methodology aligns the development life cycle with the project governance needs of validated EDM.
Project Planning Guideline 4 Complete one successful compliant document management solution to establish your organization's guidelines before trying to
run additional projects in parallel.
In many cases there is a tendency to attempt to run 16-week projects in parallel. Consider this only after successfully implementing
the compliant document management solution. By then, the effort, rules of thumb, and pitfalls will have been identified, and
you can determine if performing parallel projects is prudent. Most organizations find parallel implementations very difficult
to manage unless there are completely separate teams. The amount of information sharing and team coordination required for
parallel projects often increases the project effort by 25 percent or more.
Project Planning Guideline 5 Mitigation of high validation costs start with understanding answers to at least three sets of questions:
1. Was your validation strategy written for data acquisition and management systems (as many have been for organizations starting
as research and development companies)? Does it provide some measure of flexibility for process facilitating systems?
2. Does your company have part of the infrastructure for your EDM solutions installed and validated (e.g., application servers,
database servers, server hardware, or document management software)?
3. Does your company's template for the validation master plan and the quality assurance group allow for frequently changing
values such as user lists and groups, attribute values, and service packs to be documented and managed via the administrator's
With timelines and rules of thumb for effort in mind, the number of people involved in compliance document review, the prescriptive
nature of the templates used for the validation documentation, and the number of review cycles are just a few of the primary
drivers for the amount of time required for validation. In worst-case scenarios, the 25 to 33 percent rule of thumb can turn
into 100% or more.
EDM Validation Guidelines
FDA's website defines "PQ" as "performance qualification," "process qualification," or "product qualification." Validation
strategies oriented for data-acquisition software often apply the "performance qualification" definition, which often translates
into problems for testing a process facilitating tool such as EDM.
In a data acquisition-orientated operation qualification (OQ), there are usually straightforward tests to prove that the software
is functioning out-of-the-box, as it should; there are often few changes to the real functionality of the application. In
this case, the performance qualification can focus on the repeated successful performance of: (1) configured business rules;
(2) extract-transfer-load procedures; (3) integration reliability with other systems; and (4) such things as fail-over and
In the case of compliant document management solutions, an application is much more like a manufacturing system: the application
is responsible for controlling and producing a document. The PQ definition of process qualification often fits better than
Under this scenario, discrete functions of the EDM application are checked by the OQ scripts to ensure proper application
function: document import, document check-in and check-out, attribute input and validation, and more.