In this month’s blog, I’d like to talk about Requirements Specifications and why I feel they’re the most important document in the Validation Lifecycle.
1. Requirements get the validation project moving.
A project that hasn’t started defining requirements is not a project, it’s an idea. Usually is not until people start defining requirements, that they really start thinking about what will it take to implement the project, not just the benefits or needs that triggered the project in the first place. It gets people thinking in detail, and in the best of cases creatively, about what the project really means for everybody. Who will this impact? Who’s asking for this? Do we really need this technology? Why? Is it feasible? What are the alternatives? These are all things that we should have thought of before deciding to proceed with the project. But in my experience is not until a multi-functional team sits down to define requirements that the real talk about how to implement the project gets going.
2. User and functional requirements get the team together (especially the system owner)
When executed correctly, the User (and Functional) Requirements definition gets a team talking. In my opinion, this is the only document in which all functional departments should weigh in as if each of them were the System Owners. Usually, in other documents such as the Design Specifications or Qualification Protocols, one unit or department is considered the experts and the others just review to make sure they agree. A properly executed User Requirements exercise involves all the units as equal stakeholders. Any requirement could impact any department at any moment in the project. Therefore, this is the document that should be peer-reviewed the most, face to face is possible.
Additionally, the System Owner often gets forgotten when implementing a project. Usually, because this is the unit less likely to be dedicated to the project. We’ve all seen the image below and laughed about it:
The User Requirements Specifications is the best time to bring the System Owner to the table and have him or she really weigh in and think about what they need out of the project. It’s also the best (and only time) to document it. Once the project gets going, usually you won’t hear much of the System Owner until the Performance Qualification and by then, it will be too late.
3. Well written requirements give the validation project documented goals, priorities, and the true acceptance criteria
Is not uncommon to have a lot of Project Management be done for the Equipment Design and Implementation but not so much for the Validation Phase. If that was the case of the project in which you were brought in late, the User and Functional Requirements may be your only chance to quickly give some scope and goals to your Validation Project. You can use them to prioritize your execution schedule and help you resolve tough test deviations. If you were brought in at the last minute for a Validation Project, make sure you read and understand the Requirements Specifications for each process and equipment and hope they were well defined and written. If they were, you’ll have a scope and plan in no time.
4. Requirements close projects (and pass validation tests)
This is an obvious and well-known fact, that is regularly forgotten. Requirements objectively define the scope and the success criteria for a project. The same applies to a validation scope. When done correctly, they’re bedrock on which the rest of the validation documents and tests should be developed. Therefore, they can be used to resolve test deviations or allow protocol amendments. If for some reason a test was ambiguously developed or doesn’t have the best pre-determined test method or acceptance criteria, you can always go back to the process or equipment requirements. Does the deviation or amendment have no impact on User or Functional Requirements? Does the Actual Test Result comply with the User Requirements? If the answer is “Yes”, then the User Requirements can be used as evidence that your equipment or system functions as expected and that the test deviation is justified. When well documented, User Requirements can save a lot of time resolving Test Deviations and avoiding lengthy discussions.
5. Requirements force the team to simplify and see the big picture
This isn’t always true though, as badly written Requirements can do just the opposite. But a good User Requirements Specifications should be written in layman’s terms which has the side effect of forcing us to simplify unnecessarily technical specifications. Trying to simplify helps us think of why we need this particular specification, which in turn allows us to see the big picture of what a requirement really means for the process, business, and quality.
This is the reason why I ask the engineers I interview which they think is the Most Valuable Document in the Validation’s Life Cycle. It gives me an idea of which aspect of the process they value most. Usually, young engineers go for the qualification protocol itself which is where the actual testing takes place. This is the obvious choice. Really technical engineers, usually very detailed oriented, go for the Functional and Design Specifications. Engineers that have been in Validation Projects from beginning to end, or have some Project Management experience, quickly respond that the User Requirements Specifications are the Most Valuable Document. This tells me they’ve experienced the pain of having to work poorly defined projects and will likely be able to see the big picture when things go wrong. Obviously, no answer is wrong. It all depends on the answer they give to the unavoidable “Why?” I ask next. But this gives me an idea of which aspect of Validation they value and therefore, which projects or clients they are better equipped to support.
These are 5 of the major reasons why I think the User Requirements Specifications is the Most Important Document in the Validation’s Life Cycle. Do you agree? Are there others I missed?. Thanks for reading!
