Henrik Rasmussen, Partner, DA Network
Published: August 2026
Across my career in enterprise transformation, I have observed a gradual shift away from Integrated Delivery Methods (IDMs; see the Appendix for the definition used in this article) towards specialised frameworks and delivery approaches assembled by individual practitioners. My hypothesis was that renewed use of IDMs could improve delivery assurance and make delivery less dependent on the experience and judgement of individual practitioners. A survey of experienced practitioners confirmed the underlying pattern and the potential for improvement.
The opportunity is not to replace specialised methods. Agile delivery methods, governance frameworks, change management methods and other specialised approaches are widely used and valuable within their respective disciplines. The potential lies in connecting them through the integrated, end-to-end delivery system that an IDM was designed to provide.
An IDM can support more complete estimates, earlier identification of dependencies and faster decisions. It can also reduce reliance on individual practitioners and their judgement of what should be delivered. This creates the potential to reduce rework, protect schedules and control cost - all of which improve delivery assurance. Customers buying transformation programmes should therefore require an IDM, while suppliers bidding for the work should provide and explain the IDM they will use.
During the 1980s, 1990s and early 2000s, major consulting firms developed and trained their consultants in proprietary Integrated Delivery Methods. Examples included Accenture's METHOD/1 and Business Integration Methodology, Oracle AIM and IBM Catalyst. These methods differed in detail, but they shared a purpose: to provide a repeatable way to estimate, plan, govern and execute complex enterprise transformations from proposal through business adoption and benefits realisation.
An IDM connected the principal delivery disciplines within one framework. Business process design, application configuration, integration, data migration, technology, testing, organisational change and deployment were planned as interdependent workstreams. Common terminology, roles, deliverables, estimation approaches, templates and traceability mechanisms supported that integration.
Consulting firms formally trained people in these methods and maintained reusable delivery assets. Over time, that model weakened. Formal IDM training declined, proprietary methods became less visible and delivery knowledge became dispersed across specialised communities and individual practitioners. No single decision removed IDMs; the capability gradually ceased to be taught, requested and applied as an integrated whole.
IDMs were not replaced by one alternative. They were replaced by combinations of specialised frameworks, supplier practices, customer governance models and the experience of individual team members.
Scrum and SAFe support iterative delivery. PRINCE2 and PMBOK address aspects of governance. Prosci ADKAR supports organisational change, while ITIL addresses service management. Platform vendors and implementation partners also provide product-specific guidance and accelerators. These approaches solve important problems, but each covers a particular discipline, organisational level or stage of delivery.
The integration between them must therefore be designed programme by programme. In practice, each leader brings preferred frameworks, templates and ways of working. The programme's delivery approach becomes BYOM - Bring Your Own Method - assembled from what the people involved know and have used before.
BYOM can work when experienced people consciously integrate the parts. It is also inherently variable. Interfaces between governance, design, build, data, testing, change and deployment may remain implicit, and the resulting approach is difficult to train, assure or reuse. A programme may use several recognised frameworks while still lacking a shared end-to-end view of its activities, responsibilities, dependencies, deliverables and decisions.
The survey asked experienced enterprise transformation practitioners whether they recognised the shift I had observed during my career. Their responses confirmed a consistent pattern across education, commercial practice, delivery practice and delivery assurance.
Respondents had themselves received formal IDM training through consulting firms, but reported that new consultants generally receive little or no training in IDMs. Enterprise delivery is now learned primarily through on-the-job experience. Organisational capability has therefore been replaced by experiential learning that is harder to transfer consistently across people and programmes.
Customers rarely require an IDM in requests for proposal, and suppliers rarely make one explicit in their proposals. Delivery approaches are commonly only partly documented before contract signature, and a documented IDM is not normally agreed. Scope, price and timetable can therefore become contractual before the integrated delivery approach has been fully defined.
Respondents described delivery approaches largely defined by individual experience and programmes strongly dependent on key people. When disagreements occur, teams rely on escalation, programme-specific documentation or experienced individuals rather than a documented method. The wide mix of specialised frameworks reported in the survey is consistent with BYOM rather than a common integrated approach.
The prevailing assessment was that delivery assurance has deteriorated compared with earlier in respondents' careers. Reduced use of IDMs was identified as a significant factor, and respondents agreed that wider use of IDMs would benefit enterprise transformations. Planning was the capability most consistently considered to have declined, followed by programme governance, benefits realisation and estimation.
Taken together, the findings confirm the hypothesis: reduced use of IDMs has increased dependence on individuals and has contributed to lower delivery assurance.
In my experience, an IDM improves delivery by making the complete transformation visible and giving all parties a common reference from bid through delivery and into operation. Without that reference, omissions and misunderstandings consume time and money, schedules slip, costs increase and delivery assurance declines.
Without an IDM, there is no reliable basis for confirming that an estimate includes the full transformation scope. Teams tend to estimate the work they recognise, while activities or deliverables in areas such as data, environments, change, security, deployment or business readiness may be overlooked partly or entirely. The estimate becomes overly optimistic, and the missing work must later be added through more time, more resources or both.
Transitions from bid to delivery and from delivery to operation typically involve new teams. Without a shared IDM linking scope, assumptions, activities, deliverables and decisions, knowledge is lost and responsibilities or deliverables can fall between teams. People must reconstruct the original intent, while omissions discovered after the transition create rework, delay and additional cost.
When people join a programme, they bring different methodological references and often use the same terms to mean different things. Without an IDM, they must negotiate what should be delivered, by whom and when. Mobilisation takes longer, and some workstreams may never converge on the same delivery model, slowing coordination, decisions and acceptance.
Enterprise deliverables are not independent. Process design affects configuration, integrations, data, testing, organisational change and operations. Without an IDM, dependencies between these deliverables may not be identified, owned or sequenced. Downstream work then starts on incomplete or incorrect assumptions, and late discovery creates waiting, rework, schedule slippage and additional cost.
The pattern is consistent: optimistic estimates, knowledge lost at phase transitions, incompatible delivery references and hidden dependencies all create unplanned work. A well-architected IDM can help programmes address these issues earlier, control time and cost, and make the original commitments a more reliable forecast of the outcome.
AI can help a supplier design a customer/transformation specific IDM for a particular tender or transformation scope. It can assemble an end-to-end lifecycle, activities, deliverables, roles, dependencies, assurance points and reusable assets around the customer's situation. I have used AI in this way to develop an IDM for a software selection process. The result was not a generic methodology, but a structured delivery model tailored to the specific purpose and scope.
AI can also help teams retrieve guidance, tailor templates, improve estimates and plans, identify inconsistencies, maintain traceability across phase transitions and expose dependencies between deliverables. Its value is greatest when it operates on an explicit delivery model with defined concepts and relationships.
AI will not replace integrated judgement. An AI-assisted IDM must still be architected, validated, owned and applied by experienced people. Programme leadership, customer engagement, governance and consequential decisions remain human responsibilities. AI can accelerate the creation and use of an IDM, but it cannot compensate for a delivery approach that has never been integrated or agreed.
Suppliers do not necessarily need to invent entirely new IDMs. They should architect a customer-specific IDM, consistent with the definition in the Appendix, and apply it end-to-end across the transformation. The quality and credibility of the proposed IDM should be evaluated in internal deal reviews as part of both delivery risk and the probability of winning.
Suppliers should also rebuild method capability through regular training. This need not mean repeating the three-week methodology courses of the 1990s, but delivery professionals should receive structured refreshers at least annually. Universities should likewise consider adding project delivery and Integrated Delivery Methods to curricula for students likely to work in transformation programmes.
Projects must have sufficient delivery experience in place from the outset. An IDM is not self-executing: experienced people are needed to tailor it, establish the delivery model and ensure that it is used consistently. Bringing that capability in early improves the programme's ability to deliver on time and within budget.
Finally, customers should require an IDM in the request for proposal and validate the proposed IDM during evaluation. They should test whether it covers the full scope, supports continuity across phase transitions, establishes a common delivery language and manages dependencies between workstreams. This is how the IDM becomes a practical basis for delivery assurance rather than simply another attachment to the bid.
As enterprise transformations become more complex, the integrated delivery methods designed to manage that complexity have renewed relevance. The industry's move towards BYOM has created programme-specific combinations of frameworks and personal practices that make delivery increasingly dependent on experienced individuals.
The survey confirms the pattern I have observed throughout my career. Formal IDM capability is no longer transferred systematically, IDMs are seldom explicit in commercial practice, and programmes lack a common end-to-end delivery reference. The consequences are optimistic estimates, knowledge lost at phase transitions, slower mobilisation and hidden dependencies - which ultimately mean longer schedules, additional cost and reduced delivery assurance.
The opportunity is not to return to the methods of the past, but to apply their integrated discipline in a contemporary form: suppliers can architect and apply customer-specific IDMs, rebuild method capability and use AI responsibly; projects can bring experienced delivery leadership in from the start; and customers can require and validate an IDM as the basis for stronger delivery assurance.
If you have experience with Integrated Delivery Methods — or with the consequences of working without one — I would welcome the opportunity to compare perspectives.
For the purpose of this survey, an Integrated Delivery Method (IDM) is a structured, end-to-end delivery framework for enterprise transformation programmes. It provides a structured approach to estimating, planning, governing and executing implementations from proposal development and estimation through mobilisation, design, build, testing, deployment, pilot, roll-out, business adoption and benefits realisation.
Integrated Delivery Methods were developed primarily by major consulting firms during the 1980s, 1990s and early 2000s. Examples include Accenture’s METHOD/1 and Business Integration Methodology (BIM), Oracle AIM, IBM Catalyst and similar proprietary enterprise delivery methods.
An IDM covers the full scope of an enterprise transformation by integrating all major delivery workstreams within a single delivery framework. These typically include business processes or features, system integrations, technology platforms and environments, organisational change management, data migration, security and other non-functional requirements, which subsequently converge into integrated testing, deployment, go-live and hypercare.
An IDM also provides a comprehensive delivery toolkit, including standard terminology, lifecycle definitions, work breakdown structures, activity definitions, role definitions, estimation methods, governance guidance, reusable templates, checklists, traceability mechanisms and supporting guidance.
Integrated Delivery Methods differ from specialised methods and frameworks, which address specific aspects of enterprise delivery. Examples include Agile frameworks such as Scrum and SAFe, governance frameworks such as PRINCE2 and PMBOK, change management methods such as Prosci ADKAR, and other discipline-specific approaches.