Skip to main content
1MPACTFIRST
All insights

Failed projects never say "but the IV&V was excellent"

Independent verification and validation is judged by whether the program succeeded, not by whether the findings were correct. That is the right standard — and it is the argument for embedding the IV&V team rather than stationing it at the perimeter.

September 15, 2026 3 minute read

Post-mortems on failed modernization programs name the vendor, the requirements, the governance and the schedule. They do not record that the independent verification and validation was excellent. The discipline has no version of a successful failure.

That asymmetry defines the work. An IV&V team whose findings were accurate, delivered on schedule, correctly formatted and acted upon by nobody has not succeeded; it has documented a failure in real time. The deliverables were sound and the program still failed. We have an interest in the program succeeding — a professional interest, not a reputational one — and that interest should determine how the engagement is structured.

Two operating models

The perimeter model is the more common. The IV&V team receives deliverables on a defined schedule, assesses them against a standard, and issues findings into a report that reaches a steering committee. It is defensible, auditable and straightforward to contract for. It also guarantees that by the time anyone hears of a problem, the problem is a month old and attached to a document that took that month to produce.

The embedded model places functional and technical specialists alongside the people doing the work: in design sessions, in test planning, reading work products as they are produced rather than when they are formally submitted. Findings surface while remediation is still inexpensive. The team continues to report independently — independence is a function of reporting line, not of physical or organizational distance.

On a $100MM enterprise resource planning program spanning human resources, finance, procurement and pension, this is the structure we used: an embedded team reviewing every work product as it emerged, and an IV&V leadership group operating as peers to the authority’s executive leadership rather than reporting through the implementation vendor. Findings reached the people able to act on them while action remained possible, and the program stayed on track. We did not deliver it — the vendor built it and the authority ran it — but the findings arrived early enough to matter, which is the only contribution independent oversight can legitimately claim.

Enablers rather than obstacles

The standard objection to embedding is that proximity erodes independence: work closely enough with a delivery team and you begin defending its decisions. The risk is genuine, and it is managed as every professional-independence risk is managed — through the reporting line, through what the engagement is contractually obliged to escalate, and through whether the relationship can survive a quarter of unwelcome findings. None of that requires distance. It requires a reporting line that does not pass through the party being assessed.

What proximity provides is the difference between an enabler and an obstacle. An obstacle identifies a defect and records it. An enabler identifies the defect, quantifies what it will cost if it reaches production, and proposes a route through. Both are honest positions. Only the second changes the outcome, and it is materially harder, because it requires understanding the program well enough to propose something workable. That understanding is available only from inside.

There is a version of this discipline that protects the assessor: rigorous, fully documented, conducted at arm’s length, and blameless when the program fails. It is not the version we practise. If the program fails, we have failed with it, however sound the reports were.

What to specify

Three questions separate the two models, and they belong in the statement of work rather than in the first status meeting:

  • When does the team see the work? As it is produced, or when it is submitted for review?
  • Where do findings go, and how quickly? A monthly report to a steering committee is a different instrument from a call in the same week.
  • What is the team accountable for? If the answer is the accuracy of its findings, the procurement has bought an audit. If it is the program landing, it has bought a partner.

The third question is the one that determines the outcome, and it is the one most statements of work never ask.

Tell us about the program.

Send us the scope. We will tell you honestly whether we are the right firm for it.