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.