“Verification vs Validation in Projects”

What is the difference between verification and validation?

verification vs validation in projects is a key topic in modern project management and teamwork. Verification evaluates a deliverable against its specification. Validation evaluates it against the intended use. Both produce evidence, both are quality activities, and neither replaces the other.

The confusion usually comes from the words themselves. In everyday English, “verify” and “validate” are close synonyms, and quite a few organisations use them interchangeably in status reports. The standards do not. ISO 9001:2015 separates them explicitly in its design and development controls: verification confirms that outputs meet input requirements, while validation confirms that the resulting product meets the requirements for its specified application or intended use. The PMBOK Guide takes the same position, describing verification as compliance with a regulation, requirement or specification, and validation as assurance that the product meets customer and stakeholder needs.

Barry Boehm’s formulation from *Software Engineering Economics* is still the cleanest memory hook: verification asks “are we building the product right?”, validation asks “are we building the right product?”.

Two practical consequences follow from that table. First, the same deliverable can be fully verified and still fail validation, and that is not a paradox. Second, a validation failure is a requirements failure. Fixing it means changing the specification, not just the code.

Where do verification and validation sit in the V-model?

The V-model places verification on the left-hand descent and validation on the right-hand ascent. Each decomposition level on the left has a matching test level on the right, and the test level is written at the same time as the design it will check. That timing is the whole point: the test criteria are derived from the specification before anyone is emotionally attached to an implementation.

On the left side you decompose: user needs become system requirements, system requirements become architecture, architecture becomes detailed design, detailed design becomes code or fabricated components. On the right side you integrate and test upward: unit tests, integration tests, system tests, acceptance tests. Verification activities run at every level. Validation concentrates at the top, where the finished system meets real users, though smart teams also validate incrementally with prototypes and pilots.

Notice the asymmetry that trips teams up. Verification evidence is produced constantly and is easy to count: 118 test cases, 96% pass rate, 12 open defects. Validation evidence is messier: eight of thirteen user journeys completed without assistance, four users abandoned the form at step three, the night shift cannot read the screen in low light. Because validation evidence is harder to put in a dashboard, it gets skipped. That is exactly how a verified product reaches production with a fatal usability flaw.

Worked example: a clinic booking system with acceptance criteria

A regional clinic group commissioned an appointment booking system to replace phone-only scheduling. The approved scope contained 42 requirements, of which 13 described user journeys rather than system behaviour. Budget was $240,000 over five months, with a three-week pilot before full rollout.

The requirements were written in two styles, and that split determined the outcome.

• Verification-style requirement: “The system shall send an SMS reminder 24 hours before the appointment.”
• Validation-style requirement: “A patient who books online arrives at the right time and place without calling the clinic.”

The team built a traceability matrix and wrote 118 test cases. All 42 requirements mapped to at least one case. In system testing, 118 of 118 cases passed after three defect fixes, and verification coverage was 100%.

Then the pilot ran with 18 patients, four receptionists and two clinicians, using real appointment types and real data. The findings were not subtle.

Of 27 pilot findings, 9 were blocking, and the team needed three additional weeks and $41,000 to close them. The 100% verification coverage number was accurate and useless. Validation coverage, measured as journeys completed without staff intervention, was 8 of 13, or 62%.

The acceptance criteria that would have prevented this were available at requirements time. For each journey the team could have written: “Given a patient over 65 with no mobile number, when they book online, then they receive a confirmation through a channel recorded in their profile.” That single sentence forces the SMS-only assumption into the open, where it costs a meeting instead of a release.

How do acceptance criteria split between verification and validation?

Write two criteria for every important requirement: a conformance criterion and an outcome criterion. The conformance criterion is testable against the document. The outcome criterion is testable against the user.

The pattern below works for most projects, whatever the delivery method.

Two metrics keep this honest. Verification coverage is the share of requirements with a passing, evidence-backed conformance criterion. Validation coverage is the share of in-scope user journeys observed end to end with representative users. If your verification coverage is 100% and your validation coverage is below 70%, you have a documentation success and a product risk. Publish both numbers side by side in every status report until someone asks why they diverge.

What does each cost when you get it wrong?

Late validation failures are expensive because they invalidate work that was already accepted as complete. The arithmetic is simple enough to do in a steering meeting, and doing it changes behaviour faster than any process memo.

Take a programme with 1,200 requirements and a blended delivery cost of $95 per hour. In this example, 40 defects escape to production because no one tested with real users. Each takes 6.5 hours to diagnose and fix, including regression testing, which is 260 hours or $24,700. Add the release delay: two weeks of a service desk handling manual workarounds at 30 hours per week, or $57,000 in loaded staff time plus $18,000 in overtime. The total is $99,700, and that excludes the reputational cost of a broken promise to the customer.

The same arithmetic applied earlier looks different. A two-day requirements workshop with six users costs roughly 12 person-days. If it surfaces three of those 40 defects, the saving is immediate. This is not an argument for more documentation; it is an argument for putting real users in front of the requirement before the build starts.

One caution on the widely quoted claim that defects cost 100 times more to fix in production than in requirements. That ratio circulates constantly and traces back to 1970s and 1980s defect studies with specific contexts. Treat it as a directional warning, not a law. The multiplier depends on your industry, your architecture and your release process. Build your own number from your own last five escaped defects, and use that figure in the business case.

How do you run verification without slowing delivery?

Verification only slows a team down when it is bolted on at the end as a gate. Built into the workflow, it is the cheapest quality activity available.

Five practices carry most of the value:

1. Review the requirement, not just the code. A 30-minute review of a badly written requirement prevents more rework than a week of testing.
2. Make the definition of done include evidence. “Code complete” is not done. “Test log attached, peer review recorded, traceability row updated” is done.
3. Automate what is deterministic. Linting, schema checks, unit tests and interface contract tests run on every commit and cost nothing per run.
4. Keep a live traceability matrix. Requirement to test case to result. If a requirement has no test, that is a visible gap rather than a discovery in month five.
5. Separate the reviewer from the author. Self-verification is a conflict of interest even when the person is honest.

The habit that matters most is writing the verification criterion at the same moment you write the requirement. If you cannot state how you would prove conformance in one sentence, the requirement is not ready to be built.

How do you run validation when users are busy?

Validation fails on logistics more often than on method. Users cancel, the pilot slips, and the team ships on the original date with a promise to “gather feedback after launch”. Prevent that by shrinking the ask.

• Five users per journey, not fifty. For usability-level validation, a small number of representative users finds most of the serious problems. Recruit from the actual shift patterns, not from head office.
• Give them a task, not a demo. “Book an appointment for your mother next Tuesday” produces findings. “Here are the new features” produces compliments.
• Use real data with the messy cases. Duplicate records, missing phone numbers, non-standard names.
• Observe, do not instruct. Every time you explain the interface, you have found a validation finding.
• Record the environment. Gloves, low light, noise, intermittent connectivity. The warehouse scanner failed on nitrile gloves, which no lab test would have caught.

If a full pilot is impossible, run a two-hour task-based session with three users and call it what it is: partial validation with stated limits. Partial evidence, honestly labelled, beats a sign-off based on nothing.

Which mistakes turn verification and validation into theatre?

Signing off without artifacts. A signature with no attached evidence is an opinion. Ask for the review record, the test log or the observation notes.

Verifying against the design instead of the requirement. If the test was written from the solution rather than the need, you are checking internal consistency and calling it quality.

Treating UAT as a demo. A guided walkthrough where nobody is allowed to deviate from the script validates the presenter, not the product.

Asking the author to validate. The person who wrote the requirement will unconsciously test the interpretation they had in mind.

Testing only the happy path. Most escaped defects live in the exceptions: the missing phone number, the duplicate record, the night shift.

Confusing regulatory validation with project validation. In regulated manufacturing, validation means documented evidence from qualification activities such as installation, operational and performance qualification. That is a specific, formal process with its own protocols. Do not borrow the vocabulary loosely in a project plan that has no such protocol.

Do agile teams still need verification and validation?

Yes, and the concepts matter more in agile, not less. Agile changes the cadence, not the questions.

In a Scrum or Kanban flow, verification lives inside the sprint: peer review, automated tests, acceptance criteria checked by the team. Validation lives at the sprint review with real stakeholders and, more importantly, in production usage data after release. A sprint review where the team presents to the product owner is not validation if the product owner never uses the product in the real environment. Add a short “who used this and what happened” item to the review agenda, and the gap closes quickly.

The practical adjustment is granularity. Validate a thin slice every two weeks instead of a monolith every nine months. That reduces the blast radius of a wrong assumption from a quarter of the budget to a fortnight of work, which is the entire economic argument for iterative delivery.

Where does this fit in a project workspace?

The reason verification and validation collapse in practice is that the evidence lives in three places: requirements in a document, tests in a tracking tool, and user feedback in someone’s inbox. When the three are separate, the monthly quality report becomes a reconciliation exercise and people stop trusting it.

That is the problem Doitify is built for. Requirements, tasks, sub-tasks, checklists, quality-control checkpoints and progress reports sit in one workspace, so a verification result can be attached to the task it belongs to and a validation finding can be traced back to the journey it invalidates. Doitify is our product, so read that with the appropriate discount. It will not design your acceptance criteria for you, and for a five-person team running a single pilot, a shared spreadsheet may well be enough.

Conclusion

Verification and validation answer two different questions, and a project needs both answers to be true. Verification gives you defensible evidence that the build matches the specification. Validation gives you defensible evidence that the specification matches reality. Skip the first and you ship something unreliable. Skip the second and you ship something irrelevant, on time and on budget.

Three habits make the distinction operational. Write the conformance and outcome criteria at the same time as the requirement. Publish verification and validation coverage side by side so the gap is visible. Put real users in front of the product before the release date is fixed, not after. Teams that do these three things spend less time arguing about whether something is “done” and more time shipping work that survives contact with the real world.

If this post on verification vs validation in projects was helpful, you might also enjoy Project Management Software for Creative Agencies: 2026 Guide and Free Gantt Chart Template (Excel & Google Sheets).