White Paper: The Problem Is the Lifecycle Approach, Not the Plan: The Case for Mid-Execution Lifecycle Transition in Complex Digital Transformation Public Sector Programs
- John Al Khateeb
- 7 hours ago
- 9 min read
Updated: 1 hour ago
John Al Khateeb
MAICD | MAPPM | MSc | B.Eng | P3GP | PMP | RMP | SP | ACP | PBA
Complex Projects Governance | Management Consultant | Seasonal Lecturer
Executive Summary:
This white paper documents a consultancy engagement with a major public sector organisation in the Arabian Gulf region — an institution dedicated to developing the country's future leadership talent. The program comprised multiple concurrent projects including business process redesign, IT systems development, CCTV, access control, fire detection systems, and facilities infrastructure, with a total program investment of approximately USD $5–7 million.
The engagement began at approximately the 30% execution mark, when an independent maturity assessment identified critical delivery failures. The central finding was not a technical problem. It was a lifecycle misalignment: the business process redesign and IT development project had assumed a delivery approach directly from the program level, without interrogating whether that approach was fit for the nature of the work.
The consulting intervention redesigned the delivery lifecycle of the business process and IT project mid-execution — transitioning from a predictive (waterfall) approach to a hybrid iterative model. Within one month, the new approach was operational. The outcomes were significant: accelerated requirements capture and analysis, dramatically improved stakeholder engagement, systematic management of scope and rework through a structured backlog, avoided contractual penalties, and a measurable improvement in solution quality.
The core argument of this paper: what appeared to be an execution problem was a lifecycle classification failure. Applying a program-level lifecycle to a project with dynamic, evolving requirements was the root cause — not team performance, not resourcing, not scope.
1. Program Context and Structure
The client organisation occupies a strategically significant role within its national context — responsible for designing and delivering leadership development programs that shape the country's future public sector and institutional capability. The program subject to this engagement was a transformation initiative spanning organisational process, digital infrastructure, and physical facilities.
Program structure comprised five discrete projects running concurrently:
• Business process redesign and IT systems development (the subject of this paper)
• CCTV infrastructure installation
• Access control systems
• Fire detection and safety systems
• Office furniture and facilities fit-out
Each project carried its own technical complexity and vendor relationships. The program was being managed under a single unified lifecycle framework — a predictive, phase-gate structure applied consistently across all projects. This approach was appropriate for the physical and infrastructure projects, where requirements were fixed and execution was linear. It was not appropriate for the business process and IT project, where requirements were inherently emergent and stakeholder input was critical to solution validity.
The consultant was engaged at approximately the 30% completion mark — not as an extension of the existing team, but as an independent assessor with program management authority. The mandate was to diagnose delivery performance and implement corrective action.
2. The Diagnostic: A Lifecycle Misclassification
The maturity assessment conducted on engagement identified a pattern of delivery failure that is common in complex programs but rarely named explicitly: lifecycle assumption by inheritance. The business process and IT project had not selected its delivery approach through a deliberate analysis of project characteristics. Instead, it had assumed the program-level lifecycle by default.
KEY FINDING
The project's delivery model was never chosen — it was inherited. A predictive lifecycle applied to a business process redesign project with evolving stakeholder requirements will always produce the same outcome: stalled delivery, frustrated stakeholders, and escalating rework.
The consequences of this misclassification were measurable and interconnected:
• Requirements capture was sequential and slow. The waterfall model required requirements to be fully defined before development could proceed. In a business process redesign context, this is structurally impossible — requirements emerge through engagement, testing, and iteration.
• Stakeholder participation had collapsed. With no mechanism for iterative feedback, stakeholders had disengaged from the process. They had been asked to sign off on documentation rather than participate in solution development.
• Rework was unmanaged. Changes that inevitably arose were being treated as exceptions to be resisted rather than inputs to be absorbed. There was no backlog, no velocity tracking, and no systemic mechanism for managing evolving scope.
• Contractual risk was accumulating. Delivery timelines were slipping against fixed contractual milestones, creating exposure to financial penalties.
• Quality assurance was document-centric. Quality was being managed through requirements documentation rather than through working solution increments reviewed by stakeholders.
The assessment concluded that the solution was not to work harder within the existing model. The solution was to change the model.
3. The Intervention: Transitioning Mid-Execution
Transitioning a project's delivery lifecycle at the 30% execution mark is not a technically simple exercise. It requires justification, stakeholder alignment, methodological redesign, and team change management — all while delivery continues. The consultant led this process with full program management authority and secured organisational approval before implementation.
3.1 The Justification Case
The case for transition was built on three arguments: the nature of the remaining work (approximately 70% of the project) was requirements-intensive and stakeholder-dependent; the current model had demonstrably failed to deliver; and the risk of continuation outweighed the risk of transition. Approval was secured from the relevant steering authority within the program governance structure.
3.2 The Hybrid Agile Model
The adopted approach was a hybrid iterative model — not a wholesale adoption of any single agile framework, but a purposeful selection of tools and practices calibrated to the project's public sector context and existing contractual structure. Key elements included:
Product backlog: All requirements, changes, and emerging needs were captured in a single managed backlog, providing transparency and priority control.
Sprint-based delivery: Work was structured into short iterative cycles, with working increments reviewed by stakeholders at each sprint boundary.
Burn-up and burn-down charts: Progress was tracked visually against both total scope (burn-up) and remaining sprint work (burn-down), providing the program with reliable forecasting capability.
Velocity measurement: Team throughput was tracked across sprints, enabling realistic planning and early identification of capacity constraints.
Stakeholder review ceremonies: Formal stakeholder engagement was embedded at sprint boundaries, replacing document sign-off with working solution demonstration.
Training and upskilling: A structured capability-building program was delivered for both the project team and the client organisation, covering iterative principles, backlog management, sprint ceremonies, and structured feedback techniques. This was treated as a core deliverable of the transition, not an optional add-on.
3.3 The Transition Timeline
The transition from predictive to hybrid iterative was completed operationally within three months. This included not only the redesign of the delivery model but a structured training and upskilling program for both the project team and the client organisation. Building capability on both sides of the delivery relationship was a deliberate design choice — sustainable iterative delivery requires that clients understand how to participate in sprint reviews, how to prioritise a backlog, and how to give structured feedback on working increments. Without this, the model cannot function as intended.
Phase | Activity |
Month 1 — Weeks 1–2 | Maturity assessment findings presented; transition case approved by governance |
Month 1 - Weeks 2-4 | Backlog capturing and prioritising all existing and open requirements |
Month 2 | Team and client training and upskilling in hybrid agile practices, ceremonies, and tooling |
Mothn 3 | First sprint planned and executed; burn-up and velocity baselines established |
Month 3+ | Full iterative cadence operational; client participating actively in sprint reviews |
4. Outcomes and Impact
The outcomes of the lifecycle transition were evident within the first two sprint cycles and sustained throughout the remainder of the engagement. The following represents the key impact areas:
4.1 Requirements Velocity
Requirements that had taken weeks to define, circulate, and agree under the predictive model were being captured, analysed, and baselined within a single sprint. The iterative structure created a rhythm that stakeholders could participate in, rather than a documentation process they were asked to validate retrospectively. The speed improvement was remarkable — not because the team became faster, but because the model stopped creating the friction that had been slowing them down.
4.2 Stakeholder Engagement
Stakeholder participation transformed from passive to active. Sprint reviews gave client representatives a concrete, testable increment to engage with at regular intervals. Rather than reviewing requirements documents, they were reviewing working process designs and system components. Engagement levels and quality of feedback increased substantially, and the feedback loop between stakeholder input and solution output shortened from weeks to days.
4.3 Scope and Rework Management
The product backlog became the single source of truth for scope. All change requests, emerging requirements, and rework items were captured in the backlog, triaged against priority, and addressed in subsequent sprints. This replaced an ad-hoc change environment with a systematic, visible, and auditable process. Rework was not eliminated — it is inherent to business process redesign — but it was contained, managed, and reflected in velocity rather than allowed to accumulate as invisible technical debt.
4.4 Contractual Risk Averted
The transition and resulting delivery acceleration enabled the program to recover against its contractual milestones. Penalties that had been accumulating as a consequence of predictive-model delays were avoided. This represented a direct financial benefit to the client and a significant reduction in program risk.
4.5 Quality Improvement
Solution quality improved through a combination of iterative testing, stakeholder review at sprint boundaries, and the separation of quality management from requirements documentation. A dedicated quality management process was implemented outside the requirements document, providing a systematic and trackable mechanism for identifying, logging, and resolving quality issues across sprints.
Speed of requirements delivery: markedly improved. Stakeholder engagement: transformed from passive to active. Rework: systematically managed through backlog. Contractual penalties: avoided. Solution quality: improved through dedicated quality management process operating independently of requirements documentation.
5. The Program Lifecycle Dimension
A dimension of this case that warrants explicit attention is the program-level complexity within which the project transition occurred. The program comprised five concurrent projects at different stages of delivery, each with distinct technical profiles, vendor relationships, and risk exposures. Managing a mid-execution lifecycle transition in one project while maintaining coherence across the broader program required deliberate program governance.
The program-level lifecycle appropriately remained predictive. The physical and infrastructure projects — CCTV, access control, fire detection, facilities — did not share the requirements uncertainty that characterised the business process and IT project. Applying a blanket agile approach at the program level would have been as inappropriate as the original blanket application of predictive methods had been at the project level.
The critical insight is one of lifecycle differentiation: effective program management requires the ability to identify and apply the appropriate lifecycle at the project level, independently of the lifecycle operating at the program level. This is standard doctrine in program management frameworks but is frequently collapsed in practice — either through organisational habit, contractual constraints, or governance convenience.
Program managers must resist the gravitational pull of lifecycle uniformity. A program is not a large project. Projects within a program can — and when their nature demands it, must — operate on different lifecycles.
6. Lessons for Practitioners and Program Managers
This case offers transferable insights for practitioners working in complex program environments, particularly in public sector contexts where governance structures and contractual frameworks can create powerful inertia toward predictive delivery models.
Lifecycle selection is a deliberate act, not a default. Every project within a program should undergo explicit lifecycle selection based on the nature of its requirements, the degree of stakeholder involvement needed, and the uncertainty of its solution space. Inheriting a lifecycle from the program level without this analysis is a governance failure.
The cost of a wrong lifecycle compounds. At 30% completion, the project had already absorbed significant wasted effort. Earlier intervention would have reduced this. Program maturity assessments should be conducted at the outset and at key decision gates — not only when delivery is visibly failing.
Mid-execution transition is achievable. The assumption that a lifecycle cannot be changed once execution has begun is incorrect. With clear justification, governance approval, deliberate change management, and a structured training and upskilling program for both team and client, transition is possible — and in this case was fully operational within three months.
Stakeholder engagement is a design question. The collapse in stakeholder participation observed under the predictive model was not a people problem. It was a model problem. Designing for engagement — through ceremonies, increments, and review rhythms — produces fundamentally different stakeholder behaviour.
Rework is not the enemy; invisible rework is. Making rework visible through a managed backlog does not increase the amount of rework. It makes existing rework manageable, traceable, and plannable.
Conclusion
The program described in this paper was not failing because its people lacked capability or commitment. It was failing because a critical design decision — the selection of a delivery lifecycle — had never been made. When that decision was finally made, and made correctly, delivery transformed.
The broader lesson for program and project management practice is this: lifecycle selection is not an administrative formality. It is a strategic decision with direct consequences for delivery speed, stakeholder engagement, quality, and risk. In complex programs where projects vary significantly in their nature and requirements uncertainty, lifecycle differentiation is not optional — it is essential.
The public sector context adds a further layer of significance. Organisations that serve the public interest — particularly those entrusted with shaping national capability, as in this case — carry an obligation to deliver effectively. That obligation is not discharged by following the plan. It is discharged by following the right plan.
The switch from predictive to iterative delivery was not a concession to project difficulty. It was the correct professional response to a misclassification that, left uncorrected, would have compromised the program's ability to serve its purpose.
About the Author
ohn Al Khateeb is the Founder and Managing Director of INMAA Advisory, a research-led company helping organisations strengthen governance, navigate complexity, and equip their people to manage complex projects with greater confidence and rigour.
With more than 20 years of experience across project delivery, program leadership and management consulting, John has worked with clients across a wide range of industries, including defence, engineering, retail, manufacturing, and education.
John is an active member of multiple prestigious and professional organisations, including the Australian Institute of Company Directors (AICD), the Project Management Institute (PMI), the International Centre for Complex Project Management (ICCPM), and others in the field of complex project governance, management, and systems thinking, and their application.
Confidentiality Notice
Client identity, industry sector specifics, and commercially sensitive details have been deliberately omitted or generalised in this paper to protect client confidentiality. The quantitative outcomes and project parameters presented are factual. This paper is intended for professional and academic readership and does not constitute a solicitation of any kind.
Comments