Getting Projects Right
For the uninitiated, the terms “validation” and “verification” are inter-changeable - they both mean some form of checking. But quality assurance and control (QA/QC) people and project management professionals (PMPs)® are very aware of the difference.
Barry Boehm (the author of the seminal book “Software Engineering Economics”) put the distinction very neatly: validation is about building the right product; verification is about building the product right. In other words, QA/QC sets out to verify that the stuff we produce does not have any defects in it. In PMP® courses, this activity centres on the Control Quality process and sees the QA team use various quality tools and techniques to ensure that what we produce is consistently correct. If there are disturbing trends in the data, they will study the process to find what is causing the deviation. It is important work.
Of course, enthusiasts of Lean Manufacturing will argue that a calf was never fattened by inspection and quality should be designed in rather than inspected in. For example, when Toyota began making cars, the company was horrified to learn that the average Mercedes Benz spent half its time in the factory undergoing rectification. This did not make sense.
But, however much we ensure that the end product is defect free, it will not satisfy our customers if it does not do what they require. For project managers, Project Scope Management is the cause of many sleepless nights. The Collect Requirements process is absolutely vital – get this wrong and the whole project could be a waste of time. In fact, one of the reasons agile methods came about was to address the issues of requirements. Instead of defining requirements in a very legalistic fashion in order to produce a contract, the agile people work with the customers to develop a mutual understanding of what the end result should be.
So, instead of taking what the customer has asked for and going off to implement it entirely, the agile team will implement a part of the solution and return quickly to the customer for feedback. This feedback will amplify the team’s understanding and they will adjust their system accordingly. They will keep doing this, until the customer is happy that they are on the right track.
But, even with this understanding, there is scope for disaster (no pun intended). Having perfect requirements is one thing, but making sure that the end product or service satisfies them is another. This is where validation and the project management process, Validate Scope, come in. Here we need to correlate the project’s deliverables with the original requirements: Have we met these requirements?
A useful tool to ensure this is a traceability matrix. PMP® exam students will remember that this is produced by the Collect Requirements process, but it is also used extensively by the Validate Scope process. This matrix can be as simple as an Excel® spreadsheet. For each and every requirement, there needs to be evidence that it was included in the product or service. There also needs to be a series of tests, demonstrating that this functionality or attribute is present in the end product. Depending on your company or industry, these tests are called Site Acceptance Tests, Customer Acceptance Tests or Handover Acceptance Tests.
When you come to develop a requirements traceability matrix, you will appreciate why the instructors on your PMP® course insisted that all requirements be measureable and testable. I cannot demonstrate “User Friendly Interface”, because I cannot quantify user friendliness. I cannot even define user-friendliness, because we all have different perceptions. But I can demonstrate that certain values are displayed and that response times are within specified thresholds.
Ironically, time spent clarifying requirements also helps to reduce errors in implementation. A clear picture of what the requirements are leads to cleaner, more elegant designs. As an example, in one software product, the parameters for a certain part of the code were unclear. Instead of determining what these values were, the developers made them configurable. This added clutter to the configuration file and slowed the initiation sequence. Ironically, once the values were discovered, they never changed during the life of the product.
In summary, verification is important, especially in critical industries like medical devices. However, all the verification work imaginable will have gone to waste, if the project’s deliverables do not meet their requirements. Making your chocolate more consistent and better tasting will not stem falling teapot sales.
If you would like to learn more about Project Scope Management, Project Quality Management and the other project management concepts, please visit our training page. We run our project management courses online in our virtual classroom, making training more convenient for you. To get more details, please contact us directly.