QA for Projects and Programmes

A strategic perspective for internal auditors, boards and senior management

March 2026

Management Summary

QA by Internal Audit works best in four phases: a business case review before initiation, a governance and plan check at the start, scope and risk monitoring during execution, and a benefits evaluation at closure. This phasing is not an administrative obligation, it is the difference between timely intervention and limiting damage after the fact.

The figures make the urgency clear. Only 31% of all projects are completed within time, budget and scope.¹⁶ IT projects exceed their budget by an average of 73%, infrastructure megaprojects by 28%.¹ Estimated annual waste worldwide amounts to approximately 2 trillion dollars. These are not coincidences, they are patterns with known causes.

The three most persistent pitfalls are optimism bias in budgeting, the sunk cost fallacy that justifies continuation of failing initiatives, and groupthink in steering committees that suppresses critical signals. Each of these mechanisms is recognisable, and each can be identified if Internal Audit engages early enough.

Audit does not need to assess the strategy, but it does need to assess whether the decision-making process was robust. This is a fundamental distinction: it safeguards independence, makes findings acceptable to the board and senior management, and directs attention to what can be influenced.

This whitepaper is aimed at three audiences: internal auditors seeking to establish or professionalise QA, boards and senior management seeking greater control over their project and programme portfolio, and project professionals seeking to understand how independent QA strengthens their work.

1. Introduction

1.1 Context and relevance

Large organisations spend 10 to 30% of their operational budget on projects and programmes. Substantial sums. And yet most of them fail.

The success rate of projects and programmes has been a concern for decades, despite these significant investments. Only 31% of all projects are completed successfully within time, budget and scope. Worldwide, an estimated 70% of all projects fail to some degree. The estimated annual waste: more than 2 trillion euros.¹⁶

The causes are diverse and well documented. Kahneman and Tversky described how optimism bias leads to systematic underestimation of costs and timelines.² Arkes and Blumer (1985) demonstrated that the sunk cost fallacy drives organisations to continue investing in failing projects.⁵ Janis (1972) showed that groupthink suppresses critical voices in steering committees.⁴

The Dutch context adds its own layer of governance and oversight to this international picture. The Corporate Governance Code, revised in 2022, establishes that the board is responsible for adequate risk management and internal control.²⁰ With the introduction of the Statement on Risk Management (Verklaring omtrent Risicobeheersing, VOR), effective for financial years from 2025 onwards for listed companies, the board must explicitly declare that internal risk management systems are functioning properly. For large projects and programmes, this means that project risks can no longer fall outside the board's formal accountability. The VOR compels directors to treat project governance as part of their formal risk reporting, not as an operational detail.

At central government level, the Advisory Council on ICT Assessment (Adviescollege ICT-toetsing, AcICT) serves as an independent oversight mechanism for major government ICT projects. The AcICT, established by law on 1 July 2024 as the successor to Bureau ICT-toetsing (BIT), assesses ICT projects exceeding five million euros on feasibility, risks and likelihood of success.²³ Its recommendations are public and submitted to the House of Representatives. The Netherlands Court of Audit identifies a recurring pattern in its structural reports on digitalisation across central government: ambitions are insufficiently weighed against available capacity, ICT projects cost more and take longer than budgeted, and information provision to parliament is incomplete.⁶

For the financial sector, the Digital Operational Resilience Act (DORA), effective from 17 January 2025, creates an additional governance framework. DORA requires banks, insurers and other financial institutions to ensure digital operational resilience, including ICT risk management, incident reporting and oversight of third parties. DNB and AFM supervise compliance. Every IT change initiative at a financial institution must demonstrably comply with DORA requirements on resilience and continuity. Projects that introduce new systems or migrate existing ones fall under heightened scrutiny of operational risks.

The CGC, the AcICT, the Netherlands Court of Audit and DORA together form a supervisory landscape in which project failure is no longer an isolated operational problem. It has become a governance issue. Directors are held personally accountable for the quality of their project management, whether it concerns a digital transformation at a listed company, a government-wide ICT facility or a system migration at a bank.

1.2 Problem statement

Most organisations lack a systematic mechanism for independent quality assurance of projects and programmes. Internal Audit fills that gap. From the third line, with a mandate for independent and objective assessment, Internal Audit serves as the eyes and ears of the board in complex change initiatives.

1.3 Objective and reading guide

This whitepaper provides an integrated reference framework for QA by Internal Audit in projects and programmes. The structure follows twelve chapters: the conceptual framework (Ch 2), the GIAS (Ch 3), governance and risk management (Ch 4), the role of Internal Audit (Ch 5), structural failure patterns (Ch 6), methodologies and frameworks (Ch 7), Agile and QA (Ch 8), practical guidance for auditors (Ch 9), practical guidance for boards and senior management (Ch 10), case studies (Ch 11), and conclusions and recommendations (Ch 12).

2. Conceptual Framework: QA versus QC

2.1 What is Quality Assurance?

Quality Assurance in the context of projects and programmes is the systematic, independent assessment of processes, governance arrangements and risk management that determine the success of a change initiative. The objective is not to test the technical quality of deliverables (that is Quality Control), but to assess whether the right conditions are in place for a successful project or programme.

QA centres on the DIRFT principle: Do It Right the First Time. Deliverables are defect-free from the outset. Correcting errors always costs more than preventing them.

2.2 QA versus QC: fundamental distinction

Dimension	Quality Assurance (QA)	Quality Control (QC)
Approach	Proactive, prevention-oriented	Reactive, detection-oriented
Timing	Throughout the entire process	At the end, or at checkpoints
Focus	Process-oriented	Product-oriented
Involvement	Organisation-wide	Dedicated team or department
Objective	Prevent defects	Detect and resolve defects
Cost impact	Higher upfront investment, lower costs over time	Lower upfront investment, potentially higher costs over time
Responsibility	Internal Audit / independent QA function	Project team / test team

2.3 Projects versus programmes

Aspect	Project QA	Programme QA
Primary focus	Delivery within constraints (time, cost, quality)	Realisation of strategic benefits
Governance	Steering committee, project manager, sponsor	Programme board, SRO, business change managers
Risk emphasis	Scope creep, scheduling risk, technical risk	Unrealised benefits, strategic drift, complex dependencies
Business case	One-off assessment, periodic review	Continuously recalibrated against strategic objectives
Stakeholders	Defined and stable	Broad, shifting, politically charged
Time horizon	Months to 1-2 years	Years, often 3-5+ years

2.4 The Three Lines Model

Line	Role in projects	Core responsibilities
First line	Project management and operational teams	Day-to-day execution, risk management, implementation of controls
Second line	Risk management, compliance, project controls	Policy development, compliance oversight, risk monitoring
Third line	Internal audit	Independent, objective assurance over governance and risk management
Governing body	Board, audit committee, steering committee	Strategic direction, risk appetite, oversight of all three lines

The Three Lines Model, published by the IIA in 2020, marks a fundamental shift in thinking about governance and assurance.¹⁸ The removal of the words "of Defence" is not a cosmetic adjustment. The old model suggested that the three lines exist primarily to protect the organisation against risks. The new model positions all three roles as contributing to value creation. The first line manages risks in day-to-day operations. The second line supports, monitors and challenges. The third line provides independent assurance. The starting point is no longer defence but the achievement of objectives.

The emphasis on collaboration replaces the strict separation that characterised the old model. In practice, the "of Defence" model regularly led to silo thinking: the first line did not feel responsible for risk management because "the second line does that", whilst Internal Audit confined itself to identifying shortcomings after the fact. The new model emphasises that all three functions operate from shared objectives and that the value of Internal Audit increases as collaboration intensifies.

For quality assurance in complex programmes, this shift has direct consequences. Internal Audit does not operate as a gatekeeper that passes judgement at the end of a phase, but as an enabler that provides insight throughout the entire initiative. In a large-scale transformation programme, Internal Audit can review business cases early in the planning phase, assess governance structures during execution and evaluate the realisation of intended benefits at closure. That continuity is only possible when the lines view each other not as adversaries but as complementary functions with a shared interest.

At every QA review, ask the question: "How will we know whether this programme has delivered what it promised?" If the answer remains vague, that is a red flag. A sound benefits register contains, per benefit: an owner, a baseline measurement, a target, a measurement method and planned measurement points. Internal Audit is uniquely positioned to perform the baseline measurement, test the target for SMART criteria, assess the measurement method and challenge the progress of measurements.

3. The Global Internal Audit Standards and QA

The Global Internal Audit Standards (GIAS) of the IIA were published in 2024 and became effective on 9 January 2025 as the successor to the former IPPF.

3.1 Assurance and advisory services

Assurance services: Internal Audit formulates an opinion or draws conclusions about the activity under review. Central is the triangular relationship between the auditee, the stakeholder (board, audit committee) and Internal Audit as independent assessor.

Advisory services: the nature and scope are agreed in advance with the requesting party, without a formal opinion. Internal Audit operates as a critical friend or sparring partner.

For each QA engagement, establish upfront whether it is an assurance or advisory service. This choice determines the reporting requirements, the required independence and the type of conclusions.

3.2 Relevant GIAS standards

Engagement planning (Principle 13 / Standard 13.3): requires documentation of QA objectives, scope, criteria, resources and timeline. Align this with project gates or milestones.

Objectivity and independence (Standards 2.1 and 2.2) An auditor who previously served as an adviser on a project cannot without further consideration perform a formal assurance engagement for the same project.

Competence and due professional care (Standards 3.1 and 4.2) The audit team must have demonstrable knowledge of project management methodologies, governance principles and benefits management.

The transition from the International Professional Practices Framework (IPPF) to the Global Internal Audit Standards in January 2024 is more than a restructuring.¹⁵ The GIAS organises the standards into five domains: the purpose of internal auditing, ethics and professionalism, governing the internal audit function, managing the internal audit function, and performing internal audit services. The emphasis shifts from compliance-oriented auditing to value creation. For QA in projects, this means the auditor not only tests whether procedures are followed, but also whether the project genuinely contributes to strategic objectives.

Standard 9.4 requires the chief audit executive to develop a risk-based audit plan. Projects and programmes are included based on materiality and risk profile, not on a fixed rotation pattern. A transformation programme of twenty million euros with high technical complexity warrants a different audit frequency than a routine replacement project. The GIAS explicitly give the chief audit executive the latitude to dynamically adjust the plan when the risk profile changes, for example upon scope changes or turnover of key personnel.

The engagement cycle for QA engagements follows a clear pattern. Standard 13.2 requires the auditor to thoroughly understand the activity being assessed, including the relevant risks. In a project context: understanding the project objectives, governance structure, stakeholder interests and budgeting before determining the scope. Standard 13.3 prescribes that objectives and scope are documented for each engagement. During execution (Standard 14.1), the auditor gathers information that is relevant, reliable and sufficient. In communication (Standard 15.1), findings are reported to the board and management. In a project context, timing is critical: a report that appears three months after go-live has limited value compared to an interim signal that enables course correction.

Standard 6.2 requires the audit charter to specify the mandate of the internal audit function, including scope and types of services. For QA in projects, this is an essential anchor point. If the charter contains no explicit reference to project assurance, the internal audit function can in practice be excluded on the grounds that this falls "outside the mandate". A well-designed charter specifies the right of access to project information, the authority to provide solicited and unsolicited advice on project risks, and the reporting line to the audit committee for escalation. Without this foundation, QA in projects remains a discretionary activity.

The GIAS do not impede QA in projects. They strengthen it. The distinction between assurance and advisory, the emphasis on risk-based work and the competence requirements give Internal Audit a robust professional framework.

4. Governance and Risk Management

4.1 Governance architecture

Effective governance is the strongest predictor of project and programme success. For projects, this means: a clear mandate for the project manager, an active steering committee with decision-making authority and well-defined escalation routes. For programmes, this additionally requires a programme board, a Senior Responsible Owner (SRO) with ultimate accountability for benefits realisation, and business change managers.

4.2 Taxonomy of project risks

Risk category	Description	QA focus areas
Strategic risk	Misalignment with organisational strategy	Business case validity; strategic fit; periodic recalibration
Governance risk	Unclear roles; ineffective decision-making	Role descriptions; steering committee effectiveness; mandates
Scope risk	Scope creep and unclear requirements	Change management and requirements traceability
Scheduling risk	Unrealistic deadlines and resource conflicts	Planning realism and critical path analysis
Financial risk	Budget overruns and unreliable cost estimates	Cost estimation methodology and earned value indicators
Technology risk	Immature technology and integration issues	Technology readiness and architecture decisions
Organisational risk	Change resistance and cultural barriers	Change readiness and stakeholder analysis
Benefits risk	Benefits undefined; no owner assigned	Benefits register; KPI definitions; benefits tracking
Cybersecurity and digitalisation risk	Projects involving data migrations, system integrations or cloud transitions introduce digital risks. Test environments often contain production data without adequate security. Shadow IT emerges when project teams set up their own tooling outside IT governance. NIS2 and DORA impose additional requirements on digital resilience that must be incorporated from the design phase.	Verify that data migrations have a validated migration plan with rollback scenarios. Confirm that test environments do not contain unprotected production data. Check that DORA and NIS2 requirements are included in the project plan and that compliance is demonstrable.
Supplier and outsourcing risk	Dependence on external suppliers creates risks around continuity, quality and cost. Vendor lock-in reduces negotiating position. Multi-vendor environments introduce coordination complexity and unclear responsibilities during incidents. Contractual arrangements do not always match actual project needs, particularly regarding intellectual property and exit arrangements.	Assess whether contracts contain exit clauses, escrow arrangements and performance indicators. In multi-vendor projects, verify that the demarcation between suppliers is clear and that an effective service integration model is in place. Check that supplier risk is included in the project risk analysis.
Regulatory and compliance risk	Projects operate within an increasingly complex regulatory landscape. GDPR applies to every project that processes personal data. Sector-specific regulation such as the Wft, DORA and NIS2 imposes additional requirements. The risk extends to delays and cost overruns from failure to implement legal requirements in a timely manner.	Verify that a Data Protection Impact Assessment (DPIA) has been carried out for projects involving personal data processing. Check that sector-specific regulation has been translated into concrete project requirements. Assess whether the project schedule accounts for the effective date of new regulation.

4.3 Behavioural science dimension

The planning fallacy, described by Kahneman and Tversky, explains why project schedules are systematically over-optimistic.² People base their estimates on the best conceivable scenario rather than on historical outcomes of comparable projects. Flyvbjerg demonstrates that in large projects, budget overruns and delays are not the exception but the norm, and that this pattern has been stable for decades.¹

Alongside this unconscious bias, Flyvbjerg identifies a deliberate variant: strategic misrepresentation.¹⁹ Project sponsors deliberately present costs as too low and benefits as too high to secure approval. In a competition for scarce resources, the project with the most attractive business case wins, not the project with the most realistic one. Flyvbjerg considers strategic misrepresentation a more serious factor than the planning fallacy: where optimism bias is a human limitation, strategic misrepresentation is a rational choice driven by perverse incentives. The auditor must not only test whether a schedule is realistic, but also whether the institutional incentives promote honesty or punish it.

The sunk cost fallacy keeps alive projects that should be stopped.⁵ The more that has been invested, the harder it becomes psychologically to stop, regardless of the prospects. This effect is amplified by escalation of commitment: not only the costs already incurred play a role, but also reputational effects and political dynamics. A director who has publicly championed a programme experiences termination as personal failure. The result is that projects continue that no longer have a reasonable chance of success.

Groupthink manifests in project environments as the absence of critical challenge.⁴ Steering committees in which all members share the same interests produce decisions without genuine deliberation. A project manager who escalates problems risks being labelled "negative". Dissenting signals are not suppressed by coercion but by social pressure and the desire for consensus.

The uniqueness bias is a less well-known but equally damaging factor: the conviction that one's own project is fundamentally different from all preceding projects. "Our situation is unique, so historical data is not relevant." This reasoning blocks the use of reference data and turns every schedule into a gut-feel estimate. Flyvbjerg regards this as one of the most persistent obstacles to better project forecasting, because it closes the door to the most effective debiasing technique.⁷

Reference Class Forecasting (RCF), developed by Flyvbjerg on the basis of the work of Kahneman and Tversky, offers a systematic correction.¹⁹ The method works in three steps: assemble a reference class of comparable projects, analyse the statistical distribution of outcomes in that class, and position the specific project forecast within that distribution. If ninety per cent of comparable projects exceeded their budget by more than twenty per cent, a forecast that lands precisely on budget is statistically implausible. Internal Audit applies RCF by asking during business case reviews: what reference class was used? Were historical outcomes factored in? And if the project team claims their project is unique: on what empirical grounds?

5. The Role of Internal Audit

5.1 Mandate and positioning

With a failure rate of approximately 42%,¹⁶ internal audit cannot afford to passively wait for the next audit interval or stage gate. The greatest value lies not in confirming control design, but in asking whether the programme is genuinely set up to deliver on the strategic intent.

5.2 The role spectrum

Role	Characteristics	Output	Independence
Formal audit	Full audit with formal report and follow-up	Audit report with findings and recommendations	Maximum assurance
Assurance review	Targeted assessment of specific components	Review report with conclusion	High
Advisory	Advice on request; no formal conclusion	Advisory memo or presentation	Moderate; requires safeguarding
Critical friend	Ongoing involvement, real-time feedback	Informal signals and periodic reporting	These two tracks are in tension and require explicit agreements
Observer	Attending steering committees, reviewing reports	Early warning signals to management	High; passive role

The organisation employs three review forms: (1) quick scan, a rapid high-level assessment; (2) opinion, an advisory-oriented review without formal assurance character; and (3) deep dive, a concentrated review of a single specific subject.

5.3 Six strategic focus areas

1. Challenging the risk universe - Project risks may not have been incorporated into the periodically updated risk universe
2. Agile audit planning, Flexible, agile and responsive audit plan with a standing allocation for project assurance
3. Early involvement, Greater value in reviewing the business case during development than in post-implementation
4. Real-time feedback, Shorter, dashboard-style reports; standing invitations to governance forums
5. Outcome assurance, Ask: "What will be different for the business and how will we know?"
6. Due professional care and specialisation, Co-sourcing where expertise is lacking; fluency in Agile terminology

5.4 Competence profile

• Knowledge of PRINCE2, PMBOK, Agile/Scrum, SAFe and relevant sector-specific methods
• Understanding of benefits management and programme governance (MSP)
• Financial analysis skills (earned value management, cost estimation methods)
• Stakeholder management and communication skills at board level
• Knowledge of IT architecture and technology in digital transformation programmes

6. Why Projects Fail: Structural Patterns

The Chartered Institute of Internal Auditors identified ten recurring patterns that consistently contribute to project failure. These patterns are structural and cut across sectors and project types.

6.1 The ten recurring patterns

1. Inadequate adoption risk management Change management is treated as a peripheral activity. Projects stall because end users are not ready.

2. Unclear or misaligned programme outcomes Everyone has a different picture of what the project should deliver. Decisions are taken in a fragmented manner, without a coherent framework.

3. Weak governance and role ambiguity Steering committees constantly change composition, escalation paths are vague and decision-making stalls. Nobody feels ownership, so nobody intervenes.

4. Risks invisible to leadership Risk registers exist, but they are superficial. The view is inward and downward. What is happening externally and above does not reach the boardroom.

5. Inadequate business readiness Projects are given the green light without anyone testing whether the organisation can absorb the change. The consequences become visible after go-live, not before.

6. Fragmented architecture Parallel workstreams without overarching architecture lead to duplication and missed synergies. Each department builds its own solution, disconnected from the whole.

7. Optimism bias and visibility gaps 'Green until it is red': overconfidence and the absence of a genuine challenge culture mask problems until it is too late.

8. Benefits not tracked or traced After go-live, benefits realisation drops off the agenda. Post-implementation reviews remain superficial or do not take place at all.

9. Data, integration and process readiness underestimated Insufficient insight into data quality and interface readiness during system transitions produces surprises at the worst possible moment.

10. Operating model or culture not aligned Delivery teams build for a future the organisation is not yet ready for.

6.2 Cultural warning signals

• Reluctance to escalate or challenge deficient plans
• Resistance to adopting new processes despite formal go-live
• Tactical closure of issues to meet deadlines; root causes deferred
• Misaligned incentives: speed or cost over strategic objectives
• Excessive optimism in reporting: 'green until it is red' surprises

7. Methodologies and Frameworks

7.1 Gateway Review process

Gate	Name	Focus
Gate 0	Strategic assessment	Alignment with organisational strategy and business need
Gate 1	Preliminary evaluation	Feasibility and options analysis
Gate 2	Business case	Quality and robustness of the business case
Gate 3	Procurement	Readiness for contract and supplier management
Gate 4	Readiness for service	Operational readiness and transition planning
Gate 5	Benefits realisation	Actual realisation of planned benefits

7.2 QA focus per project phase

Phase	Key questions for QA	Deliverables for review
Initiation	Is the business case sound? Are governance structures in order?	Business case, project charter, stakeholder analysis
Planning	Are the estimates realistic? Is risk management effective?	Project plan, WBS, risk register
Execution	Is the project on track? Are risks being actively managed?	Progress reports, change logs, earned value data
Delivery	Have acceptance criteria been met? Is the transition to operations secured?	Test results, transition plan, lessons learned
Closure and benefits	Are the intended benefits actually being realised?	Benefits realisation report, post-implementation review

7.3 MSP 5th edition

MSP was developed by AXELOS (now PeopleCert) and is regarded as the most comprehensive and most widely used programme management framework in Europe. The fifth edition (2020) rests on three core components: seven principles, seven governance themes and seven processes.

The seven MSP principles:

1. Lead with Purpose: Leadership with a clear vision and strategic direction
2. Collaborate Across Boundaries: Collaboration across organisational boundaries
3. Deal with Ambiguity: Dealing effectively with uncertainty and complexity
4. Align with Priorities: Continuous alignment with organisational priorities
5. Deploy Diverse Skills: Deploying diverse competencies and perspectives
6. Realize Measurable Benefits: Focus on measurable benefits realisation as the core outcome
7. Bring Pace and Value: Combining speed with genuine value delivery

The seven governance themes:

Theme	Description	Relevance for QA and audit
Organisation	How roles, responsibilities and decision-making are structured	Makes visible who is accountable for quality
Design	The design of the desired end state (blueprint)	Quality criteria and measurable objectives
Justification	Ongoing validation of the business case	Foundation for assurance on investment decisions
Structure	Project structure and coherence within the programme	Monitoring of dependencies and integration risks
Knowledge	Knowledge management, information flows and lessons learned	Structurally embedding learning effects
Assurance	Establishing assurance at programme level	Direct alignment with the role of internal audit (Three Lines)
Decisions	Decision-making and escalation	Governance effectiveness and escalation culture as audit focus

The seven MSP processes:

1. Identify the Programme: Establishing the programme scope and strategic rationale
2. Design the Outcomes: Designing the desired end results and the blueprint
3. Plan Progressive Delivery: Planning phased delivery through tranches
4. Deliver the Capabilities: Executing projects that deliver the required capabilities
5. Embed the Outcomes: Embedding the results within the organisation
6. Evaluate New Information: Continuously evaluating new information and adapting
7. Close the Programme: Formal closure with evaluation of benefits realisation

7.4 Comparison of normative frameworks

Aspect	MSP	ISO 21503	PMI Standard
Origin	AXELOS/PeopleCert (UK)	ISO (international)	PMI (US)
Character	Methodology (prescriptive)	Guidance (principle-based)	Standard (descriptive)
Assurance component	Explicit theme	Governance activity	QA within life cycle
Benefits management	Very extensive	Described	Performance domain
Suitable as criterion	Yes, upon adoption	Yes, universally	Yes, upon adoption
Certifications	MSP Foundation and Practitioner	Not certifiable	PgMP

7.5 Maturity model for QA assessment

Level	Classification	Characteristics
1	Initial (Ad hoc)	No formal QA process. Results are entirely dependent on individual competence.
2	Repeatable	Basic processes exist but are not consistently applied. Governance is limited.
3	Defined	Standardised methods, a functioning PMO and integrated risk management.
4	Managed	KPIs, portfolio management, active benefits tracking, CI/CD in Agile projects
5	Optimised	Organisation-wide learning, predictive analytics, integration with strategy execution

Assess primarily against the standard the organisation itself has adopted. In the absence of an explicit methodology, ISO 21503 is the most neutral and widely recognised reference framework.

--- ✓ Klaar: deel 1/2 vertaald. Alle HTML-structuur, attributen, citatie-links en kader-classes intact. IIA-terminologie consistent toegepast (GIAS, Three Lines Model, CAE, governing body, etc.).

8. Agile as a Project Methodology and the Impact on QA

Agile projects succeed three times more often than waterfall projects (Standish Group CHAOS Report).¹⁶ This demands a fundamentally different design, execution and assessment of quality assurance.

8.1 Waterfall versus Agile

Dimension	Waterfall	Agile
Project structure	Linear and sequential: each phase is completed before the next begins	Iterative and cyclical: short sprints of 2 to 4 weeks
Quality assurance	QA takes place in a separate test phase after development	QA is embedded in every sprint; testing is a continuous process
Feedback cycle	Feedback at the end	Continuous feedback via sprint reviews and retrospectives
Stakeholder involvement	Involved only at the start (requirements) and at delivery	Continuously involved in every iteration
Change management	Changes are costly and avoided as much as possible	Changes are expected and are part of the process
Delivery	Deliver a working product at the end	Working increments after every sprint, early value realisation

8.2 SAFe built-in quality: five dimensions

• Flow: Optimising the value stream to eliminate bottlenecks
• Architecture and design quality: flexible, maintainable and scalable design
• Code quality: code reviews, pair programming and automated testing
• System quality: testing the entire system including integrations
• Release quality: releases that are stable, complete and production-ready

8.3 Governance comparison: waterfall versus Agile

Governance aspect	Waterfall	Agile / SAFe
Decision points	Phase gates and gateway reviews	Sprint reviews, PI planning, system demos
Quality gates	Formal QA phase after development	Continuous testing with a Definition of Done per sprint
Progress reporting	Status reporting per phase	Burndown charts, velocity metrics and dashboards
Risk visibility	Risk register, periodic updates	Sprint retrospectives, PI risk boards
Stakeholder feedback	Beginning and end	Every sprint (2-4 weeks)
Audit approach	Formal phase reviews	Agile audits within sprints with real-time feedback
Benefits tracking	Post-implementation review	Incremental, measurable after each release

8.4 Recommendations for internal audit in Agile environments

1. Invest in training the audit team in Agile principles and practices
2. Assemble a diverse team with knowledge of Agile methodologies and deep sector expertise
3. Develop a flexible audit plan with a prioritised backlog rather than a rigid 12-month plan
4. Build a closer relationship with the audit sponsor to understand evolving needs
5. Leverage data analytics and technology to increase audit efficiency
6. Establish KPIs to measure the effectiveness of Agile audits and make adjustments

Agree on QA moments upfront that align with the Agile cadence: after every third or fourth sprint, or at PI boundaries in SAFe.

8.5 Hybrid models and "Agile in name only"

Most organisations do not work in a purely agile or purely waterfall manner. The reality is hybrid. Common combinations include water-scrum-fall, where the planning and delivery phases follow waterfall but the build phase is executed in sprints, and PRINCE2 Agile, which combines the governance framework of PRINCE2 with agile delivery.²¹ Hybrid models are pragmatic. They become problematic when the organisation claims to work agile but waterfall thinking actually dominates. This phenomenon, sometimes referred to as "Agile in name only", is characterised by performing Scrum ceremonies without embracing the underlying principles.

An auditor recognises this pattern through concrete signals. The scope is fixed at the outset and is not adjusted based on emerging insights. Sprint reviews are demonstrations to management rather than feedback sessions with end users. The Definition of Done has been diluted to the point where technical debt is systematically deferred. The Product Backlog is treated as a detailed project plan. Retrospectives take place but do not lead to measurable improvements.

Internal Audit specifically assesses in hybrid projects whether the chosen method suits the nature of the project and whether the governance structure aligns with the way of working. A waterfall steering committee that meets monthly provides insufficient oversight for a project that works in fortnightly sprints. The auditor assesses whether the hybrid approach is a deliberate design choice, documented and considered, or an unintended compromise that combines the worst of both worlds.

8.6 Scrum-specific QA questions

In projects that apply Scrum, Internal Audit focuses on the core elements of the framework. The Product Owner maximises the value of the product. The central question is whether this role truly has mandate. Can the Product Owner independently set priorities and remove items? Or does he or she function as a conduit for a steering committee that takes the actual decisions? A Product Owner without mandate undermines the entire Scrum mechanism, because prioritisation is then driven not by value but by hierarchy.

The Definition of Done determines when a product increment is considered complete. An effective DoD is demanding: not only functional requirements but also test coverage, documentation, security checks and performance criteria. The auditor assesses whether the DoD is documented in writing, whether it is periodically tightened and whether the team adheres to it. A diluted DoD is an early indicator of future quality problems.

The Sprint Retrospective is Scrum's learning mechanism. The auditor establishes whether retrospectives take place, whether the outcomes are recorded and whether improvement actions are followed up. A team that identifies the same problems every fortnight without anything changing is not learning.

Technical debt deserves attention as an audit topic. It accumulates when a team deliberately opts for a quick fix that creates additional work in the longer term. Signals include a rising number of defects per sprint, longer lead times for simple changes and a growing gap between the team's velocity and the value actually delivered. The auditor makes technical debt a topic of discussion by asking how much sprint capacity is structurally spent on resolving existing problems rather than building new functionality.

9. Practical Guidance for Auditors

9.1 QA checklist for project reviews

A. Governance and oversight

• Is there a current and approved project charter with clear objectives?
• Are roles and responsibilities (RACI) unambiguously documented and communicated?
• Does the steering committee function effectively: meeting frequency, decision-making, attendance?
• Are escalation routes defined and used in practice?

B. Business case and benefits

• Is the business case based on realistic assumptions and externally validated?
• Are benefits defined as SMART with clear owners and measurement points?
• Is the business case periodically reassessed based on emerging insights?
• Is there a mechanism for post-implementation benefits tracking?

C. Risk management

• Is there a current risk register with owners, mitigating actions and deadlines?
• Have the key risks been escalated to the steering committee with concrete action proposals?
• Is there adequate contingency in budget and schedule for identified risks?

D. Planning and progress

• Is the schedule based on a detailed Work Breakdown Structure?
• Are progress reports delivered on time and accurately?
• Is there a formal change management process for scope changes?

E. Quality and delivery

• Is there a quality plan with defined acceptance criteria?
• Have test plans been drawn up and are test results systematically recorded?
• Are lessons learned systematically captured and shared?

F. Additional for Agile projects

• Does the team apply a clear Definition of Done that includes quality criteria?
• Are sprint reviews genuinely used to incorporate stakeholder feedback?
• Is technical debt consciously managed?

9.2 Reporting format and communication

• Use a RAG status (Red-Amber-Green) dashboard as the first page of every report
• Limit findings to the five to seven most materially significant observations
• Formulate each finding with a clear implication and a concrete, actionable recommendation
• Always discuss draft findings with the project team first; plan ahead, as alignment takes time

Use a one-page QA dashboard that shows at a glance the status of governance, business case, risks, planning, quality and stakeholders.

10. Guidance for Board Members and Senior Management

10.1 QA as a strategic steering instrument

Project failure costs money and undermines strategy. For board members, project governance is not a technical detail but a core responsibility that affects value creation, reputation and stakeholder confidence.

What board members and senior management must safeguard in project governance:

• Financial oversight: Ensuring that projects stay within budget and that financial risks are adequately managed
• Investment decisions: Assessing and approving investment opportunities including the potential return on investment
• Strategic direction: Establishing the vision, mission and values as a compass for all project investments
• Tone at the top: Fostering a culture of escalation, transparency and realistic reporting
• Portfolio optimisation: Maintaining a balanced portfolio
• Accountability: Holding management accountable for implementing policy

10.2 Critical questions for board members and senior management

Strategic questions

• Does this project or programme still align with our strategic priorities?
• If we were starting again today, would we make the same choices?
• Who owns the benefits and how is he or she held accountable for their realisation?

Governance questions

• Does the steering committee have the right composition, mandate and time commitment?
• Have there been escalations and, if so, were they handled adequately?
• What information is not reaching me through the regular reporting lines?

Risk perspective questions

• What are the three biggest risks and what are we doing about them?
• Which assumptions in the business case are most vulnerable and what is the impact if they do not materialise?
• Is there a realistic fallback scenario if the project proves unsustainable?

Additional questions for Agile and programme management

• Are Agile principles such as built-in quality and continuous feedback being applied effectively?
• For programmes, is the MSP assurance framework structured in line with the Three Lines Model?
• Is the organisation ready to absorb and sustain the change?
• Are lessons learned genuinely integrated into subsequent project phases?

The most powerful question a board member can ask is not 'how are things going?' but 'what don't I know?' QA by Internal Audit exposes precisely those blind spots in the information supply.

10.3 QA at portfolio level

At portfolio level, Internal Audit assesses whether resource allocation aligns with strategic priorities, whether there is visibility of cross-project dependencies and cumulative risks, and whether portfolio governance provides for periodic reassessment.

One annual portfolio review by Internal Audit, based on aggregated findings from individual QA engagements, delivers more organisation-wide improvement than ten separate project reviews.

11. Case Studies and Lessons Learned

11.1 Public sector

In the Netherlands, the Elias Committee (Tweede Kamer, vergaderjaar 2013-2014, 33 326, nr. 5) concluded that government ICT projects structurally suffered from unrealistic schedules, inadequate governance and insufficient independent review. In the United Kingdom, the National Audit Office repeatedly highlighted the importance of independent assurance (HC 960, Session 2019-2021; HC 554, Session 2023-24).

Key lessons from the public sector:

• Independent QA must be embedded in the governance framework from the initiation phase
• The SRO must be held personally accountable for requesting and following up on QA findings
• Gateway reviews at natural decision points are more effective than periodic audits at arbitrary intervals

11.2 Case study: core banking system at a major bank

A major Dutch bank launched a programme to replace its core banking system. Budget: 400 million euros, duration four years. Internal Audit only became involved in the second year, after the steering committee discovered that progress reports were contradicting each other.

Internal Audit's first QA review revealed three issues: the business case relied on migration scenarios without empirical evidence, the programme had three reporting lines that were not aligned, and no benefits owner had been appointed at board level. The programme was delivered eighteen months late. The business case remained positive, but the delay was avoidable.

Lesson: Had Internal Audit been at the table earlier, the governance issues would have surfaced months sooner.

11.3 Case study: digital portal at a government agency

A large government agency launched a programme to develop a digital citizen portal: nine sub-projects, four suppliers, total budget 85 million euros. Internal Audit was involved from day one.

After the third quarter, Internal Audit identified that two sub-projects were building technically incompatible solutions. That early detection saved an estimated four to six months of rework. The CIO in retrospect: "The project managers knew, but did not dare to escalate. They were afraid of the consequences."

Lesson: QA by Internal Audit breaks through the information silos that remain intact within the project organisation.

11.4 Case study: ERP implementation at a manufacturing company

An international manufacturing company rolled out a new ERP system across fourteen locations in six countries. Halfway through, it became clear that change management had been structurally neglected: staff reverted to shadow administrations in Excel. Only after a dedicated change management workstream was added did the adoption rate at the next rollout phase measurably increase.

Lesson: Technical success does not guarantee programme success. QA must explicitly assess the human side of change.

11.5 Case study: the migration nobody wanted to stop

A mid-sized financial institution decided to migrate its core processing system to a new platform. The business case promised lower operational costs and a more modern architecture. Budget: fourteen million euros, duration eighteen months. The steering committee consisted of three board members who jointly sponsored the project.

After six months, the first problems emerged. The complexity of the data migration had been underestimated: historical transaction data contained inconsistencies that required manual correction. The project team requested a scope change and three additional months. The steering committee agreed but adjusted the budget only marginally. Internal Audit was not involved at that point. The audit charter contained no explicit reference to project assurance and the Chief Audit Executive had not included the project in the audit plan because it fell "under board responsibility".

After twelve months, the project was eight months behind schedule and five million euros over budget. An external review, commissioned at the insistence of the supervisory board, identified fundamental shortcomings: no independent quality assurance, no structured risk management, no reference class benchmarking against comparable migrations. The supplier held a strong contractual position and had changed team composition twice. The migration was eventually completed after 28 months and 23 million euros. The promised benefits were only partially realised.

Lesson: Had Internal Audit tested the business case with Reference Class Forecasting during the planning phase, the underestimation of migration complexity would have been identified early. Had the audit charter safeguarded project assurance, independent quality assurance would not have been a favour but a right. The difference between a project that derails and a project that is corrected is rarely the technology. It is the presence of someone who asks the right questions at the point when course correction is still possible.

11.6 Universal lessons

Lesson	Implication for QA practice
Starting early delivers the greatest return	Establish QA from the business case phase, not only when execution problems become visible
Independence is non-negotiable	The auditor reports directly to the board or audit committee, without an intermediary layer of project management
Benefits realisation requires structural embedding	QA does not end at go-live. Benefits often materialise only months after delivery
Competence determines credibility	Invest in project management knowledge for auditors. Deploy guest auditors for specific expertise that the in-house team lacks.
Culture determines effectiveness	In an open organisation, QA works fundamentally better than in one where mistakes are punished.

12. Conclusion and Recommendations

12.1 Synthesis

Quality Assurance by Internal Audit adds value at three levels. At project level, it identifies risks before they escalate. At portfolio level, it exposes structural patterns that remain invisible at project level. At organisational level, it embeds accountability and transparency in governance.

In agile environments, quality assurance shifts from a separate phase to a continuous activity. The Three Lines Model, MSP and the Global Internal Audit Standards (GIAS) 2024 provide the professional framework. Culture makes the difference: the willingness to escalate, to demand realistic reporting and to test strategic alignment.

Data analytics and artificial intelligence open new possibilities for continuous project monitoring. Where the auditor traditionally tested on a sample basis through periodic reviews, technology makes it possible to analyse project data continuously. Automated anomaly detection flags when the burn-down rate structurally deviates from the plan, when the number of outstanding risks grows faster than mitigating actions, or when the budget trajectory follows a pattern that led to overruns in comparable projects. Predictive project analytics goes one step further: based on historical data, a model calculates the probability of delay or budget overrun. This does not replace the auditor's judgement. It enriches that judgement with patterns that the human eye cannot discern in the mass of project reports.

Generative AI is changing the project work itself. Teams generate code, documentation and test scenarios faster than ever. This accelerates iterations but introduces new risks. AI-generated deliverables require their own quality assurance: who reviews the output, against what criteria and with what mandate? When a project team bases an architectural decision on an AI recommendation, the auditor must be able to establish what input the model received, what alternatives were considered and whether the decision was made deliberately and documented.

Continuous assurance, the ideal of ongoing rather than periodic assurance, is the logical next step. For projects, this means: not performing a one-off gateway review, but receiving, analysing and feeding back signals throughout the entire trajectory. This requires a different way of working: real-time access to project dashboards, a methodology that shifts from sampling to continuous monitoring, and competencies that combine data analysis and knowledge of agile practices with classical audit expertise. The GIAS provide the space for this.¹⁵ The challenge lies not in the standards but in the ability of internal audit functions to use that space.

12.2 Recommendations for Internal Audit

1. Explicitly include project and programme QA in the audit universe with an annual risk assessment
2. Differentiate the QA approach: project-focused (scope-planning-budget) versus programme-focused (governance-benefits-alignment)
3. Combine formal assurance moments at gates with informal advisory and monitoring
4. Invest structurally in project management knowledge, including Agile frameworks (Scrum, SAFe) and MSP
5. Adopt Agile audit methods for Agile projects; use the MSP assurance framework for programmes
6. Report concisely, visually and action-oriented: dashboards and RAG statuses; no more than seven findings
7. Aggregate findings into organisation-wide insights; share periodic meta-analysis with senior management
8. Shift the focus from delivery tracking to outcome assurance; put adoption risk on the agenda

12.3 Recommendations for board members and senior management

1. Actively use QA by Internal Audit as a strategic steering instrument
2. Establish a formal follow-up process for QA recommendations with owners and deadlines
3. Ask the right questions: not just 'how are things going?' but 'what don't we know?'
4. Secure ownership of benefits at board level; benefits realisation is a line management responsibility
5. Demand robust business cases with quantified benefits and independent validation
6. Understand the differences in financial oversight between waterfall and Agile projects
7. Foster a culture of transparency and open escalation
8. Endorse Agile adoption and create the cultural preconditions: psychological safety and a continuous willingness to learn

QA costs a fraction of the project budget. It makes the difference between course correction and write-off. Successful project assurance is not measured by the number of findings. It is measured by realised project objectives.

Appendix A: Overview of relevant standards and frameworks

Framework	Publisher	Relevance for QA
PRINCE2	AXELOS / PeopleCert	Process-based project management; built-in quality review techniques
PMBOK (7th ed.)	PMI	Principle-based framework, widely adopted as a standard
MSP (5th ed.)	AXELOS / PeopleCert	Programme management, benefits management, explicit assurance theme
COBIT 2019	ISACA	IT governance framework, applicable to digital transformation programmes
Agile / SAFe	Scaled Agile Inc.	Iterative methods, built-in quality assurance, adapted QA approach
ISO 21503:2022	ISO	International standard for programme management and programme assurance
PMI Standard for Program Management (5th edition)	PMI	Program QA, governance and benefits management
GIAS (2024)	The Institute of Internal Auditors	Normative framework for internal audit; requirements for assurance and advisory services
PRINCE2 (7th ed.)	PeopleCert	Process-based project management; 7th edition (2023) integrates agile principles
CGC 2022	Monitoring Commissie CGC	Dutch Corporate Governance Code; internal audit function and the role of audit (principle 1.2)

References

1. Flyvbjerg, B. (2021). Top Ten Behavioral Biases in Project Management. Project Management Journal, 52(6), 531-546. DOI: 10.1177/87569728211049046.
2. Kahneman, D. & Tversky, A. (1979). Prospect Theory. Econometrica, 47(2), 263-291.
3. Flyvbjerg, B. (Ed.) (2017). The Oxford Handbook of Megaproject Management. Oxford University Press. ISBN: 978-0-19-873224-2.
4. Janis, I.L. (1972). Victims of Groupthink. Houghton Mifflin. ISBN: 978-0-395-14002-4.
5. Arkes, H.R. & Blumer, C. (1985). The Psychology of Sunk Cost. Organizational Behavior and Human Decision Processes, 35(1), 124-140.
6. Commissie-Elias (2014). Eindrapport: Grip op ICT. Tweede Kamer, vergaderjaar 2013-2014, 33 326, nr. 5.
7. Flyvbjerg, B. & Bester, D.W. (2021). The Cost-Benefit Fallacy. Journal of Benefit-Cost Analysis, 12(3), 395-419.
8. UK National Audit Office (2020). Lessons learned from major programmes. HC 960, Session 2019-2021.
9. UK National Audit Office (2024). Lessons learned: Delivering value from government investment in major projects. HC 554, Session 2023-24.
10. ISO (2022). ISO 21503:2022 Guidance on programme management.
11. PMI (2024). The Standard for Program Management, 5th Edition. ISBN: 978-1-62825-814-1.
12. PMI (2021). PMBOK Guide, 7th Edition. ISBN: 978-1-62825-664-2.
13. AXELOS (2020). Managing Successful Programmes (MSP), 5th Edition. ISBN: 978-0-11-331676-2. Rights transferred to PeopleCert in 2021 (PeopleCert ISBN: 978-9-92560-044-1).
14. ISACA (2018). COBIT 2019 Framework: Governance and Management Objectives. ISBN: 978-1-60420-764-4.
15. IIA (2024). Global Internal Audit Standards (GIAS). Effective 9 January 2025. theiia.org/standards
16. Standish Group (2020). CHAOS Report 2020.
17. Chartered IIA (2024). Auditing What Matters: Patterns from Recent Project Assurance Reviews.
18. IIA (2020). The IIA's Three Lines Model: An Update of the Three Lines of Defense. Position paper, July 2020. theiia.org
19. Flyvbjerg, B. (2023). How Big Things Get Done: The Surprising Factors That Determine the Fate of Every Project. Macmillan. ISBN: 978-1-250-19665-1.
20. Monitoring Commissie Corporate Governance Code (2022). Nederlandse Corporate Governance Code 2022. The Hague. commissiecorporategovernance.nl
21. AXELOS (2015). PRINCE2 Agile. TSO. ISBN: 978-0-11-331151-4.
22. Kotter, J.P. (1996). Leading Change. Harvard Business Review Press. ISBN: 978-0-87584-747-4.
23. Adviescollege ICT-toetsing (AcICT) (2024). Instellingsbesluit AcICT. Staatscourant 2024. acict.nl