The process qualification is used to test the application from the role-based perspective of such steps as: the author generates
a document for review, and the reviewer completes the review cycle. These types of tests involve testing sets of disparate
functionality in a sequence that matches how the role-players will actually use the application. For business users, this
approach appears to be similar to user-acceptance testing. For administrators, this approach provides tangible examples of
the functions they will be asked to serve almost immediately after "go-live."
Validation Guideline 1 It is important to validate EDM infrastructure hardware and software well in advance of application deployment.
If your validation strategy calls for an approach more in line with performance qualification, and your EDM application's
purpose is compliant document management, work with your QA department to write a variance or amendment to the validation
strategy. The validation strategy for compliant document management systems should include a process qualification
Validation of an EDM system is not limited to the application created within the EDM tool. The entire hardware and software
stack — the physical server hardware and operating systems, database servers, application servers, EDM applications, and EDM
support software — should be validated. If your company has installation and operational qualification (IOQ) protocols for
validating these components — and the IOQ protocols can simply be updated to suit your environment — then some of the validation
risk and effort has been mitigated.
Ensuring that test and production hardware are delivered early; resources are available to execute the protocols; and hardware,
operating system, and database servers are validated well in advance of the planned date for setting up the test environment,
additional validation risk is mitigated.
Validation Guideline 2 Do not forget about the impact of your EDM system on the desktop image. New applications may need to be installed and qualified
even for web-based applications.
A related risk is the qualification procedure for the desktop image (the set of desktop software approved by QA to work effectively
and reliably together). If your company has created a qualified desktop-software image, ensure that your EDM administrator
works with the desktop-application administrator to understand the tools that will be installed on the desktop in conjunction
with the EDM implementation.
Some examples of EDM support software that should be checked are applets and Java run-time environments for the EDM; versions
of viewers required (e.g., Adobe Reader and WinZip) on the desktop to support the EDM usage; and compatibility of all desktop
tools with the EDM stack being implemented. Changes to the image may require the desktop image to be requalified, a time-consuming
process that can cause major project delays in cases where several tools need to be changed, updated, or uploaded.
Finally, consider licensing implications of changing any desktop components, support software, or components of the EDM stack.
Validation Guideline 3 Set up "test" and "integration test" environments to promote early identification and rapid resolutions of bugs and other
Consider implementing four environments when performing a ground-up implementation: development, test, integration test,
and production. The integration testing environment allows the EDM application to be tested with other applications, such
as scanning environments or desktop applications. The test environment should allow the EDM application to be tested in isolation.
The two together provide an opportunity to view what has changed during integration efforts, thereby allowing early identification
and rapid resolution of bugs and other issues.
Validation Guideline 4 Fully understand the scope of the validation effort. The amount of documentation and supporting software and the number of
review cycles and architectural components can all cause the scope of validation to balloon out of control. EDM solutions
are often more complex to validate than originally expected.
Change Control Rules of Thumb
EDM solutions have many values that change on a regular basis: users, groups, metadata values, folder structures, service
packs, and so on. While the requirements for these values should be identified during the requirements gathering process —
and documented in detail during design — the maintenance of actual values is often better managed by an administrative SOP.
The design document can reference the SOP and actual values as a starting point. Value changes should be governed by an administrative
change that does not require the entire system to be revalidated and does not require documents contained in the validation
package to come under change control.
Change Control Guideline An administrative SOP and change procedure should govern frequently changing values. If you leave the sole documentation
of the values within the requirements or design documentation, the application will need full revalidation when these values
change (to maintain compliance).
PULLING IT ALL TOGETHER
Understanding the business charter of an EDM implementation will most likely lead the team fluidly to the envisioned end state
of the project. For example, a project charter with a stated purpose of "increasing and automating the creation of compliance
documents" leads to maturity state 3 as an endpoint, while a project charter that simply specifies "sharing less-sensitive
project documents among team members" is likely to indicate maturity state 1. Once the end state is known — once you have
your vision — the functionality necessary to achieve that vision is relatively clear. Transitioning to bottom-up planning
requires some EDM project planning knowledge as well as application of proven guidelines.
Work from the vision or end state backward to decompose the project for bottom-up planning purposes. Start the decomposition
using the planning guidelines above. When executing the project, work in a stepwise manner — achieving high levels of success,
one maturity state at a time, before moving to the next maturity state. On the first project, apply loose effort estimates
initially. Learn from the projects by tracking effort for each phase of the development life cycle, and calculate more precise
guidelines for your organization as more projects are implemented. Applying consistent methodologies and using similar project
governance techniques will enable best practices.
Planning a validated project requires substantially more time and coordination than an un-validated project. Knowing the pitfalls
of managing validated projects, and then taking action at the inception of a project by applying the validation guidelines,
will help to mitigate the largest project risk: delays in the project due to documentation rework rather than actual system
quality. The guidelines in this article allow you to benefit from other organizations' best practices.
Last, but certainly not least, governing EDM implementations through short planning horizons strongly encourages prioritization
of user requirements. Effective prioritization coupled with well-aligned development and validation methodologies will enable
you to consistently manage sponsors' expectations. Positively and effectively managing the sponsors' expectations will build
"apostles" for the EDM system — the best practice for achieving the desired value from an EDM system
Daniel Hahn aniel Hahn is engagement director, Life Sciences Division, Ness Technologies, 3 University Plaza Drive, Hackensack, NJ 07601, 201.488.7222, ext. 415, Fax: 862.596.0178; firstname.lastname@example.org