If you’ve ever managed an IT project where your client wanted confirmation that the infrastructure was built correctly or the application was properly installed, you might have just assumed that a few tests were all that were required to complete the client’s request. Unfortunately, this isn’t good enough for the IT projects that need stricter control, such as those with stringent regulatory restrictions.

This article examines computer systems validation (CSV), and how CSV affects both IT systems and project managers. A key point here is that validation not only applies to government-regulated agencies, such as the DoD and the FDA, but that it can be applied industry-wide, which means that it won’t be long before it might be applicable to your enterprise as well.

CSV can be the difference between success and failure
When I was doing a logistics assignment for a government agency a while ago, the client specs were extremely tight. This wasn’t your normal run-of-the-mill project, as my team was scrutinized every step of the way. My team set up a validation methodology, established a validation team, and addressed even more than we were required to. Subsequently, the project that had no room for error was eventually finalized, and our app was installed without any problems whatsoever. This is the kind of result that CSV provides: a completely successful ending for an IT project.

Many critical IT projects are benefiting from the raised bar that CSV provides. Without CSV in place, project quality and success can suffer—and suffer greatly.

Your role as project manager is to find and highlight problems in an IT project, with the aim of improving its quality, because you have direct access to all the documentation and are responsible for the testing and examination of the product prior to its release or shipping. Once it is shipped or deployed into its designated environment, if the regulated authorities/clients validate it in detail and notice any faults, such as tolerances that are wrong, batches that are measured incorrectly, incorrect funds transfer, and so on, you can be sure that the posse will be after you.

Remember that the design and deployment of an IT system is planned and executed using an organization’s own project management methodology. Prior to starting the project, the project manager accepts responsibility for the project and takes into account all technology requirements, standards, regulatory requirements, special guidelines, and industry benchmarks. Therefore, the moment you start coming across buzzwords or keywords such as “regulatory,” “comply to standard XYZ,” “compliance,” or “validated system,” you’ll have to ensure that your project addresses and includes CSV. This means that, from the very start of the project, project managers will need to include validation within their project schedules and plans, as there are additional resources and time requirements that will be required for CSV.

Demystifying validation
Validation is a confirmation or careful examination of an IT system—hardware or software—that ensures that the system meets the exact client/user needs and that it is suitable for its intended purpose. It encompasses more than just QA, testing, or verification. Validation is of a higher order than those methods. There are typically two types of projects: those that are validated and those that aren’t. Generally, IT systems that perform regulated/critical operations should be validated. This includes any system that would:

  • Control the quality of an application/product during its development, manufacturing, testing, and distribution.
  • Provide data or generate reports, which are sent to critical clients or regulated bodies.
  • Create, modify, retrieve, or distribute records that are checked on a frequent basis.
  • Provide information on which key decisions are made.

Remember that the type of validation will vary depending upon the critical nature and architecture of the application developed specifically for the proposed client. Since software is usually part of a larger hardware system, the validation of software typically includes evidence that all software requirements have been implemented correctly and completely and are traceable to system requirements. The conclusion that software is validated is highly dependent upon comprehensive software testing, inspections, analyses, and other verification tasks performed at each stage of the software development life cycle.

Reasons for validation
Validation is a critical tool for systems compliance and is undertaken primarily for three main reasons:

  1. To ensure that good business practices are adhered to
  2. To satisfy any regulatory requirements
  3. To minimize costs to a project

What’s most important is that the computer system conforms to the standard specs and requirements, as well as increases the client/user acceptance of the project. Many organizations today are starting to require companies to validate their manufactured items that control mission-critical processes or systems, such as certain software applications or automated devices.

In reality, this can also be applied to any aspect of an IT system. Why? Because many IT systems are used to collect, analyze, and maintain data (such as algorithms, formulas, source code, and configurations) for various kinds of industries. For example, you have a network data center within your organization that utilizes three UNIX and two Wintel servers specifically for an e-commerce application. They are uniquely configured to allow qualified data to be used by engineers, doctors, or chemists. If anything went wrong, where the data was changed or configured incorrectly, the implications could be devastating.

IT systems are designed and deployed in compliance with specific performance and quality standards. It basically boils down to the fact that you should be able to prove—using CSV—that the IT system can actually achieve the desired results. Also, the documentation created during the CSV effort is extensive for validated projects. It will ensure that your project has been subjected to a high degree of quality assurance as to the trustworthiness of the functionality of the proposed computer system. When you look at minimizing project costs you see that once a project is closed and becomes operational, it could cost up to 20 percent more to correct each error. So, it becomes crucial to catch these errors as early as you can in the life cycle. The advantages I’ve noticed using CSV are that it:

  • Minimizes regulatory actions that can be placed on your system.
  • Assists in the product or service being recalled.
  • Results in decreased failure rates.
  • Improves the level of control and reliability of the system.
  • Ensures a good working relationship between the company and its suppliers.
  • Demonstrates an adherence to a quality methodology.

A critical part of the validation process is to provide an assurance that the development and operational processes are, in fact, consistent and adhered to. CSV team members often have to deal with design errors. In the CSV world, an application that doesn’t meet its specifications or design criteria is a lousy application.

Validation requirements
Here are some of the more immediate things to start addressing once you’ve decided to validate a project:

  • Validation methodology: Create a validation methodology when introducing validation into an IT project. This methodology should look at (1) supplier qualification, (2) compliance assessments, (3) validation plans, (4) procedures and controls, and (5) validation reviews.
  • Validation policy: Create a policy by defining the general principles and philosophies as to why your organization performs validation, as well as communicating executive expectations.
  • Validation guideline: Develop a guideline that will comply with all formal procedures within your organization. This will typically list internal documents detailing software checks, activities, and steps for executing an IT system (such as installing a Linux server).
  • Master validation plan: This plan details the validation steps. You should review this plan with the client, QA, project or development manager, tester, and so on.
  • Installation protocols: Create the necessary checklists and install procedures for each technology you are either installing or deploying. For example, the procedure for a Linux install, an Oracle 9i install, or an HP Superdome install.
  • Gather your team: Begin addressing the fact that, for a validation project, you’ll need resources. Identify the team members needed.

Time to gather the validation team
There are many internal and external groups that could support the validation of an IT system. The executive team in your organization should provide the resources to assist with project validation. These resources will typically be:

  • Technology vendors
  • IT developers
  • CSV members
  • Operations personnel
  • Quality control staff
  • Project managers
  • Or any other delegated individuals

The CSV team should also receive validation overview training on how IT systems are validated, since it will be creating and using checklists on the job. The project/development manager must appoint a central validation coordinator who will “bird-dog” any validation concerns that crop up. The amount of involvement by the validation coordinator would depend on the size of the project. So it’s important to assign these resources right from the start of the project.

The CSV team is ideally responsible for:

  • Creating and executing the master validation plan and protocols as required.
  • Developing an IT validation approach for the specific project, which the team will follow.
  • Creating all the install procedures and adhering to the validation policies as needed.
  • Documenting each system build (this will be the domain of the developers/system administrators).
  • Documenting system components and capturing each configuration type.
  • Creating a separate system development file for each unit.
  • Enforcing organizational strategies on validation.
  • Developing the validation summary report.
  • Auditing the IT system for compliance and document results.
  • Archiving the IT project validation documentation once completed.

I’ve found that one of the biggest problems with validation projects is that electronic records are hardly ever maintained once they’ve been started. Somehow, they just never get updated. Project teams need to ensure that they maintain the necessary records at all times. Remember that all IT projects must be validated before they are moved into the production environment.

The last word
In the future, a greater emphasis will be placed upon the roles project management and CSV have in validated projects. Industry has already started to demand higher compliance to standards and specifications. Proper testing and quality assurance are great contributors to successful projects, but where IT projects demand higher levels of compliance, one needs to consider validation as a starting point.