Managing Requirements: Verification vs. Validation
A common source of project failure over the past two decades has continued to be the management or mismanagement of project requirements. We are not going to discuss project failure, but only to show that a clear understanding of some of the management concepts for project requirements is crucial to the dismantling of this frightful statistic of poor performance. One such understanding is the difference between requirement verification and validation: a concept in its current state of confusion that in our experience continues to provide a level of misapplication of requirements, management techniques, and practices. This is especially true of Information Technology software-oriented projects.
The two major, but not only, processes to a successful IT project is the planning of the project and its execution. They are inexorably linked together for without sound planning, execution will be lacking in direction and focus; without sound execution, planning becomes a waste of time and resources. However, in the successful completion of any IT project, understanding the needs of the stakeholders is only part of the equation for success. The proper implementation of a feasible solution that can produce ‘fit-for-use’ deliverables able to provide for the stakeholders’ needs is also crucial to this success formulation. Thus, it is important to understand where verification and validation fits into these activities of an IT project.
First, it does not matter how the project is to be developed, using either a predictive or an adaptive style environment to understand the different perspectives and value of verification and validation. Secondly, the purposes of verification and validation while complimentary are focused on addressing different questions confronting the IT project manager and team. Finally, these processes provide checks on the planning and execution activities of the IT project ensuring that they have been appropriately implemented and completed.
What are these different questions that verification and validation address?
- Verification seeks to answer the question: Are we building the right solution?
- Validation seeks to answer the question: Are we building the solution right?
The first question therefore tries to discover if the stakeholders’ needs and business issues will be met (resolved) if the IT project provides deliverables that meet the elicited or discovered stakeholder requirements. This is similar to the manner in which an architect using blueprints and models attempts to show their clients that the proposed solution will meet their needs, constraints, and utilization once it has been constructed according to plan. Thus verification processes occur prior to the completion of actual product (software, applications, and systems) and is thus a CHECK on the efficacy of the project team’s PLANNING efforts and actions.
Verification precedes the development (predictive or adaptive) of the solution component in an attempt to decide if the development activity is the correct action to take in order to provide the stakeholders with a desired and necessary feature and/or capability. Verification seeks to match need with plan or direction.
The second question thus seeks to determine if the stakeholders’ needs and business issues have been met by the development of the actual IT component under production in either lifecycle environment. In order for this question to be answered, actual deliverables have to have been completed to a point of testing (unit, system, regression, performance, or user) where the efficacy of the project team’s EXECUTION is now able to be CHECKED.
Validation succeeds the development of the solution component in an attempt to determine if the development activity was correctly executed with the result of the produced deliverables are indeed ‘fit-for-use.’ Validation seeks to match the resolution of need with produced deliverable(s).
One final example, a non-IT one, may help to cement the differences between verification and validation. Think of parking your car at a shopping mall where free parking is provided to those that actually purchase something from one of the mall vendors. The verification of the activity is either calling or reading the requirements determined by the mall operator on how to obtain free parking. However, the validation only occurs AFTER one has parked their car, obtained a parking stub, made a qualifying purchase, had their parking stub stamped (validated), and then presented to the parking attendant for free parking resolution. Here, one cannot validate the process until after one has actually produced a ‘fit-for-use’ deliverable such a parking and purchasing. The same is in IT projects.
Verification is checking planning while validation is checking execution – it is that simple.
Thank you for joining me for this short diversion into IT project management and I trust you may be able to better utilize the verification and validation processes on your next project.
