Interfaces between packages and functions
Has anyone examined the seams, as distinct from examining each of the things the seams join?
What goes wrong without it
Assurance is bought by function and by package, and each buyer receives a report on their own scope. The arithmetic error is to assume that adding those reports produces coverage of the programme. It does not, because programme risk is not additive across functions: the interactions between packages generate exposures that no single package review is scoped to see, and the failure appears in whichever package is least able to absorb it.
This one is ours
The standards require risk-based planning and integrated practice. Neither states that coverage is non-additive across functions, or that interfaces generate exposures invisible to package-level review. That reading is this publication’s, argued from how assurance is procured on large programmes rather than from any clause.
What to examine
- Draw the interfaces. Then ask whose assurance scope each one falls inside. The ones falling inside nobody are the finding.
- Check whether any review has been scoped across two packages rather than within one.
- Test the schedule logic between packages, in particular where one package holds float that another package is relying on.
- Establish who owns interface risk in the contract structure, and whether that party has the information to manage it.
Required by
- Global Internal Audit Standards, Institute of Internal Auditors, effective 9 January 2025, on risk-based planning.
- ISO 21502:2020, Clause 6, integrated project management practices.
In the asset lifecycle method
The steps of the two methods that this domain examines.