This article explains how Digital Information Design (DID)¹ can be used as an organising model to align Business Information Management (BIM), ASL and ITIL into one coherent management structure. Through this model, leadership teams can translate digital investment and delivery efforts into measurable mission-driven outcomes by combining lifecycle management, KPI/KRI-based steering and continuous improvement, supported by Lean and PDCA, with Scrum where appropriate.

[1] DID Foundation (no date) – DID: Digital Information Design

Index

• Executive summary
• 1) Fragmentation blocks growth
• 2) Governance design as structural remedy
• 3) Digital Information Design: structuring coherent information management
• 4) Embedding execution frameworks (ASL/ITIL/LEAN/Scrum)
• 5) Governing growth through measurement (KPI/KRI/PDCA/90-180-365/Scrum)
• 6) Three use cases
• 7) Board reflection

Executive summary

Digital transformation remains a strategic priority for many organisations. Yet evidence suggests that only a minority of initiatives fully realise their intended objectives.² The constraint is seldom technology alone. More often, it is digital governance fragmentation: strategy, execution, and operational control evolve without structural coherence.

This article examines how deliberate governance design reconnects strategy, delivery, and measurable value through a coherent management and operating model. It uses the Digital Information Design (DID) model as the design layer, with ASL and ITIL positioned as execution anchors, Lean as the flow and waste-reduction discipline, and PDCA as the management rhythm for continual improvement. Scrum is applied where iterative learning is required, not as a universal guidance method.

The objective is not to introduce more frameworks, but to organise existing ones into a coherent operating model

The central leadership question is straightforward: is information governed as a strategic asset, or merely operated as infrastructure? The answer determines whether digital investment drives mission progress or mainly sustains activity.

Executive relevance

For senior management, CEOs and board members, a fragmented IT operating model is not a technology issue; it is an enterprise risk. When information assets are governed incoherently, strategic execution slows, capital allocation becomes opaque, risk exposure increases, and innovation returns diminish. Structural design determines whether digital investment accelerates mission delivery or dissolves into operational overhead. The real question is not whether frameworks are used, but whether integration and coherence have been deliberately designed.

[2] Boston Consulting Group (Oct 29, 2020) – Flipping the Odds of Digital Transformation Success

1) Fragmentation blocks growth

Where digital work is transferred across multiple organisational handoffs without shared flow controls, delay, rework and decision friction increase. This is why Lean-oriented³ value stream practices⁴ focus on waiting time, dependencies, excess work in process and non-value-adding activity.

Three board-level risks follow:

• Without portfolio visibility, application sprawl emerges^5,6
• Without lifecycle governance, technical debt accumulates
• Without KPI/KRI discipline, executive steering becomes a management illusion⁵

Financial perspective

Fragmentation has direct financial consequences. Application sprawl inflates maintenance overhead. Unmanaged lifecycle decisions increase long-term remediation and run costs. Poor portfolio visibility distorts capital allocation.⁶ When cost-to-serve is not transparently linked to value, it risks shifting IT from a strategic investment vehicle to uncontrollable overhead. Organisations that do not explicitly design governance coherence will default to fragmentation.^5,6

2) Governance design as structural remedy

Digital Information Design (DID) is most useful when treated as a governance design model, not as another operational method. The DID Foundation positions DID as the successor direction of BiSL guidance, building on BiSL Next⁷ for Business Information Management (BIM). Used well, DID helps leaders structure recurring BIM activities and decision patterns before execution starts. The objective is not to introduce more frameworks, but to organise existing ones into a coherent operating model.

It brings practical value:

• Stronger control over sensitive and mission-critical information assets
• Lower cost caused by poor information quality
• A culture that prioritises quality, integrity and availability of information assets

The DID model belongs to a family of BIM models that aim to align organisational strategy, information structures and digital execution. Examples include BiSL for demand-side information management and enterprise governance models such as COBIT. DID focuses specifically on the design of coherent information structures across organisational domains.

In many organisations information is still managed as an operational by-product of applications, rather than as a strategic asset governed at enterprise level. DID shifts the conversation from “How do we manage IT?” to “How do we govern information as a strategic asset?”. It provides a structural way to align strategy, information design and operational execution.

[7] DID Foundation, in Dutch (Dec 6, 2022) – Wat is BiSL Next?

3) Digital Information Design: structuring coherent information management

DID can be understood as an organising model within the broader field of BIM. BIM frameworks aim to align organisational strategy, structures and execution so that information services contribute to measurable organisational outcomes. BiSL, for example, focuses on the demand side of information management, defining how business requirements for information services are organised and managed.

Within this landscape, DID focuses on the design of coherent information structures across organisational domains. Rather than introducing another operational framework, DID provides a structural perspective that helps organisations position existing frameworks in relation to each other.

The real question is not whether frameworks are used, but whether integration and coherence have been deliberately designed

To avoid conceptual dilution, the DID vocabulary must remain consistent. Its power lies in the explicit separation between domains, drivers and perspectives. This separation keeps management discussions structurally aligned with mission intent.

The DID model structures information management through three interconnected elements: operating domains, business drivers and architecture perspectives.

In practice, DID helps organisations position frameworks such as ASL, ITIL, Lean and Scrum within a coherent information management and operating model. More details about this you find in the next chapter.

Operating domains

1. Governance: Defines policy intent, accountability, risk boundaries, assurance criteria, and decision rights to ensure information assets serve the mission.
2. Strategy: Translates mission and value intent into portfolio direction, investment choices, and prioritised change initiatives.
3. Improvement: Designs and tests change hypotheses, evaluates outcomes, and feeds structured learning back into Strategy and Governance. Scrum is an optional delivery method used where iterative learning is required.
4. Operation: Ensures stable, secure and cost-effective delivery of live services and applications in line with agreed performance standards. It feeds Improvement, which in turn feeds Strategy and Governance (PDCA logic).

Business drivers

These shape and align all four operating domains and architecture perspectives.

1. Need: The underlying problem, demand or opportunity that justifies intervention or change.
2. Value: The measurable benefit expected from an information, service or application investment.
3. Mission: The organisation’s purpose and long-term strategic intent that guide management choices.
4. Capability: The organisational ability – people, processes and systems – required to deliver and sustain value.

Architecture perspectives

1. Business: How processes, roles, management structures, and operating models create value.
2. Data: How information is structured, governed, protected, and maintained to ensure integrity, quality, and usability.
3. Service: How capabilities are delivered and experienced through service models, performance commitments, and user outcomes.
4. Technology: The platforms, integration patterns, infrastructure, and tooling that enable reliable, changable and scalable operation of applications, data, and services.

Integration logic

This creates a continuous management loop aligned with PDCA thinking.

The business drivers (Need, Value, Mission, Capability) shape and test priorities across all operating domains and architecture perspectives, ensuring management discussions remain anchored in organisational intent rather than technical solutions alone.

The operating domains are mutually reinforcing rather than linear: Operation produces performance evidence, Improvement converts evidence into change, and Governance and Strategy adjust direction and investment decisions.

The architecture perspectives ensure structural coherence across the organisation: Business frames how value is created and measured, Data ensures information integrity and usability, Service structures how capabilities are delivered, and Technology enables reliable, adaptable operation of applications and platforms.

Together these elements create a coherent information management structure in which strategy, lifecycle management and service delivery continuously reinforce each other.

4) Embedding execution frameworks (ASL/ITIL/LEAN/Scrum)

Within DID, ASL and ITIL act as execution anchors, while Lean and Scrum provide delivery discipline within that governance structure. Lean focuses on improving flow and reducing waste across processes, helping organisations identify bottlenecks in service delivery and application lifecycle management. Scrum complements this by organising development work into short iterations, enabling teams to deliver improvements incrementally while maintaining alignment with portfolio priorities. In this context Lean improves operational flow, while Scrum structures iterative product delivery.

• ASL structures lifecycle decisions. It supports disciplined choices to maintain, modernise, consolidate, or retire applications.8 Where relevant, lifecycle management is also a financial discipline: these choices influence depreciation profiles, cloud consumption patterns, and long-term operating cost structures.
• ITIL structures service management and reliability. It provides practices for service value, reliability, and continual improvement across live operations.⁹
• Lean guides flow and waste reduction. It contributes value-stream thinking, disciplined operational flow, and continuous improvement to prevent mere local optimisation and improve end-to-end value delivery.¹⁰
• Scrum guides adaptive team execution, not governance. It is applied where uncertainty is high and iterative learning is required; the Scrum Guide¹¹ defines Scrum as an iterative, incremental framework for adaptive solutions to complex problems.

5) Governing growth through measurement (KPI/KRI/PDCA/90-180-365/Scrum)

The visual below shows how DID domains and drivers operate in a measurable BIM context.

Why KPI/KRI + 90-180-365 + PDCA + Scrum is a valid structure

This structure is valid because each element addresses different needs:

• KPI/KRI: Using the right metrics provides an objective view of organisational performance and risk. KPIs track performance outcomes, while KRIs track risk exposure. Managing one without the other distorts decisions.¹²
• 90-180-365 cadence: This is a practical governance cadence, not a DID standard. Ninety days aligns with quarterly steering rhythms, 180 days enables two learning loops, and 365 days supports annual portfolio rebalancing.¹³
• PDCA across DID domains: PDCA is not merely a method inside DID; it functions as the management rhythm that orchestrates continual improvement across domains. This iterative framework provides an evidence-based approach to managing change, ensuring decisions are validated before scaling.¹⁴
• Scrum where applicable: Scrum is used where adaptive, incremental delivery is needed; it is not required for all work types.

None of these frameworks resolve fragmentation unless embedded in a coherent governance design.

PDCA animates DID

The PDCA cycle does not replace DID; it animates it. This is what it comprises:

• P – Plan: Set objectives for the system and processes to deliver results (“what to do” and “how to do it”).
• D – Do: Implement and control what was planned.
• C – Check: Monitor and measure processes and results against policies, objectives, requirements, and report results.
• A – Act: Take actions to improve process performance.

Applied within the DID operating domains:

• Governance (Plan/Check): Set policy intent, controls, and conformance checks.
• Strategy (Plan/Do): Translate mission and value into portfolio and funding decisions.
• Improvement (Do/Check): Test change hypotheses, evaluate impact, feed learning back.
• Operation (Check/Act): Monitor service and application performance, then standardise corrective actions.

KPI/KRI-coupled growth model

Financial coherence emerges when lifecycle decisions, service performance and capital allocation are reviewed in the same governance cadence. Separating operational KPIs from financial steering reproduces fragmentation at board level.

6) Three use cases

The following examples show that lifecycle governance and flow discipline produce measurable operational and financial outcomes.

Case 1: Application rationalisation local authorities UK¹⁵

A collaboration between several UK local authorities, including Hounslow and Chesterfield, faced fragmented consultation processing across planning teams. Responses to public consultations were manually tagged and categorised in different ways by different teams, leading to inconsistent execution, duplicated effort and long processing times. Because workflows and information structures were not aligned, the cycle time for analysing consultation responses varied significantly between teams, reducing confidence in decision speed and transparency.

The intervention focused on rationalising the application landscape and standardising information flows. Shared data structures and a unified workflow were introduced, supported by digital tooling that automated classification and tagging of consultation responses. Delivery was organised iteratively, allowing teams to test and refine the process while aligning improvements with broader portfolio priorities.

The pilot demonstrated measurable operational gains. Officer time spent processing consultation responses was reduced by approximately 45%, significantly improving consistency and enabling planning teams to focus on higher-value analytical work rather than manual processing.

Case 2: Platform architecture and data-driven operations bol.com¹⁶

A well-known example from the Dutch private sector is bol.com, one of the largest e-commerce platforms in the Netherlands and Belgium. The organisation operates a digital platform that connects millions of customers with thousands of retail partners, requiring a scalable architecture and disciplined operational processes.

To support this scale, bol.com built its platform around an event-driven architecture in which systems respond to business events in real time. This approach allows operational processes and digital services to react quickly to changes in demand, while ensuring that decisions are based on current data rather than delayed reporting.

The platform also relies on reusable automation and shared services. By defining operational processes once and reusing them across the platform, bol.com reduces duplication, improves consistency and enables teams to scale services without increasing operational complexity. From an organisational perspective, multidisciplinary teams work continuously to improve the platform, combining service development, operational monitoring and data analysis. This model illustrates how a coherent service architecture and disciplined lifecycle management can translate digital capability into reliable operations and scalable platform growth.

Case 3: Lifecycle integration in high-tech manufacturing at ASML¹⁷

A well-known example from the Dutch private sector is ASML, the semiconductor equipment manufacturer whose products require the integration of extremely complex hardware, software and data systems. Managing this complexity requires strong lifecycle coordination across engineering, manufacturing and service operations.

To support this, ASML uses integrated digital lifecycle management tools that connect product design, engineering data and production planning. These systems allow engineers to simulate production scenarios and evaluate design changes early in the development process, reducing rework and improving coordination between development and manufacturing teams.

By managing engineering information, product design and manufacturing processes within one integrated digital environment, ASML improves the reliability and scalability of its innovation process. The approach illustrates how disciplined lifecycle management and shared architecture principles can support the development and delivery of highly complex technological systems.

From a Digital Information Design perspective, this reflects the alignment of business processes, data structures, services and technology within one coherent lifecycle environment, enabling innovation without losing operational control.

7) Board reflection

Before approving the next transformation wave, leadership teams should ask:

• Are we funding mission outcomes or legacy project scope?
• Are we reducing application complexity or silently scaling technical debt?
• Are our dashboards proving value creation or merely reporting activity?
• Do ASL and ITIL execute DID priorities, or operate as disconnected initiatives?

An effective IT service organisation is not created by adding more frameworks, but by one coherent design in which information, applications, and services jointly deliver mission-driven growth.

Most intranets underperform not because of technology, but because their purpose is unclear and organisational ownership is weak. Even with significant investment, many intranets struggle to deliver ongoing value. Research shows that intranets deliver value only when these are treated as strategic organisational platforms, not mere IT or communications tools.

What distinguishes successful intranets

Successful intranets are not technology projects but leadership initiatives that require clear intranet strategy and governance.

• Clear purpose linked to its way of work and goals
• Reliable, governed content that employees trust
• Visible leadership engagement that signals importance

For leaders, the message is simple

Clarity, practical leadership, and continuous stewardship result in sustained intranet value. When these are in place, intranets become effective digital workplace platforms that improve employee experience, alignment and productivity.

Start with purpose, not platform

A recurring cause of intranet failure is the absence of a clearly articulated purpose and intranet strategy. Too many initiatives begin with a platform decision rather than a strategic question.

What organisational challenges should the intranet help to solve?

Intranets explicitly linked to organisational goals are significantly more likely to demonstrate measurable value. Successful intranets are anchored in a number of clear objectives, such as reducing friction in internal communication and supporting knowledge sharing across silos.²

Page views and login frequency tell little about real impact. Organisations that align intranet strategy with business goals, and measure outcomes such as search success and task completion, report significantly higher engagement and impact.^3a Research also recommends outcome-oriented measures such as reductions in duplicated effort, and completion rates of key employee journeys like on-boarding or service requests.^3b

Design around how people actually work

Since 2020, research shows that intranets succeed when they support actual work behaviours – prioritising usability over feature lists.⁴

Common design problems

• Complex navigation
• Ineffective search
• Content structured around organisational silos rather than user needs

Human-centred design practices

• User research
• Journey mapping
• Iterative usability testing

Multiple industry studies show that intranets designed in this way achieve measurably higher engagement, trust, and perceived usefulness.^5a,5b For example, modern best practice guidelines from Coveo⁶ show that relevance engines, personalized results, and employee-centric design correlate with higher workplace engagement.

Personalisation and mobile access

Employee expectations have shifted. Research indicates that personalised intranet experiences – tailored by role, location or context – reduce cognitive load and increase relevance for users.^7,8

Mobile access is equally critical: for frontline, hybrid and remote workers, a mobile-first intranet is often the primary way the platform is used, and without it, large parts of the workforce may be excluded from communication and services.⁹

Common pitfalls that undermine intranet value

What this means for leaders

When intranets work well, the benefits extend beyond communication to measurable improvements in productivity and alignment. In hybrid and increasingly complex work environments, these outcomes are strategically significant.

• Improved employee experience and engagement
• Faster knowledge flow and decision-making
• Reduced friction in communication
• Lessened duplicated effort
• Stronger organisational alignment

Conclusion

The intranet is a strategic organisational platform that reflects how people work and organisations function

Intranet excellence is not delivered at launch, but built over time, grounded in real work, and sustained through deliberate attention to content quality, governance and leadership engagement. Its success depends less on choosing the right technology and more on clarity of purpose, fitting design, visible leadership, and continuous stewardship.

Leaders should embed intranet success into organisational KPIs, governance frameworks, and executive behaviours to ensure sustained strategic value. In this sense, intranet governance is not an IT responsibility alone but a leadership discipline embedded in the organisation’s digital workplace strategy.

• Project Online will be shut down on September 30, 2026
• Project Server 2016 and 2019 move into security-updates-only and then out of support
• Several desktop and cloud variants reach lifecycle transitions within the same timeframe

Individually, these dates may seem to look manageable. Together, they form a compound risk that affects governance, security, cost predictability, and the way organisations run projects.

Lifecycle decisions are often assessed per product. A common argument is simply: “Project Server is still supported”. What this approach overlookos is the portfolio effect. When multiple platforms transition simultaneously, organisations face:

• Overlapping migration pressure
• Limited availability of specialist skills
• Rising operational and compliance risk
• Unplanned cost escalation

Table 1 – Life-cycle milestones across 16 Microsoft project management products

Organisations planning a Microsoft Project migration must now assess multiple lifecycle transitions simultaneously. This life-cycle table – which you also find in the free whitepaper (no registration) – makes it visible at a glance, showing 16 Microsoft project management products and their support timelines side by side. In the whitepaper, the page thereafter shows “Table 2 – Focus on decision-relevant capabilities of 8 active products, not an exhaustive list”.

This is where “waiting a bit longer” stops being a neutral option.

Impact SharePoint 2013 workflow retirement on Project Online

The retirement of SharePoint 2013 workflows on 2 April 2026 further compresses the migration timeline concerning Project Online.

Automations in Project Online that rely on SharePoint 2013 workflows – such as approvals, change control or onboarding – will stop functioning when the service is retired. This creates a material risk of disrupted portfolio governance and stalled project approvals up to six months before the Project Online service itself is discontinued.

You can resolve this temporarily by replacing these workflows with Power Automate ones. Then you have bought some time before migrating from Project Online to another solution.
Using Power Automate for Project Lifecycle Workflows in Project Online – Part 1

Supported does not mean future-proof

A key insight from the whitepaper is the distinction between:

• Technical support status, and
• Strategic sustainability

Some platforms remain supported but are positioned for sustainment rather than innovation. Microsoft’s strategic investment has shifted toward a role-based project ecosystem, deliberately separating:

• Execution (Planner)
• Planning and control (Project desktop / Project Plans)
• Governance and insight (Power BI, Power Platform)

There is no single successor to Project Server or Project Online. Migration is therefore not a lift-and-shift, but a redesign of how project work is organised and governed.

Lifecycle transitions require operating model decisions

Lifecycle transitions are therefore not only technical migration events. They also force organisations to reconsider how project work is organised and governed. In the Microsoft ecosystem, planning, execution, collaboration and reporting are now distributed across multiple services. This means migration decisions inevitably affect the project operating model: how portfolios are governed, how teams collaborate, and how information flows between planning, delivery and reporting.

Organisations that treat migration purely as a tooling replacement risk recreating the same structural limitations in a new platform landscape. Those that treat it as an operating model decision can use the transition to improve portfolio governance, transparency and decision-making.

Why 2026 matters

The decisions organisations defer today will still need to be made – but under less favourable conditions:

• Higher risk
• Higher cost
• Less freedom of choice

Lifecycle milestones do not force a specific solution, but they do force a decision.

What was once a single integrated platform has evolved into a role-based ecosystem that separates execution, planning, governance and reporting across multiple products. This shift has direct financial, operational, and risk implications for organisations that do not adapt in time.

Table 1 – Life-cycle milestones across 16 Microsoft project management products

This life-cycle table – also included in the free whitepaper (no registration required) – makes the transition visible at a glance, showing 16 Microsoft project management products and their support timelines side by side. In the whitepaper, on the page thereafter you will find “Table 2 – Focus on decision-relevant capabilities of 8 active products, not an exhaustive list”.

This is where “waiting a bit longer” stops being a neutral option.

Whitepaper

To support executive decision-making, I have published a whitepaper that explains what this change means in practice – and how organisations can respond in a controlled, future-proof way.

From tool replacement to operating model change

A common assumption is that moving away from Project Server or Project Online is a technical exercise: replace the platform, migrate the data, and continue operating as before. In practice, this approach often increases cost and complexity while delivering limited business value.

For many organisations this therefore becomes a governance decision rather than a purely technical migration. Choices about tooling directly influence how project portfolios are governed, how information flows between teams, and how leadership gains visibility into delivery performance.

Microsoft’s modern project and portfolio management model is based on:

• Different tools for different roles
• Reduced customisation and lower technical debt
• Clear separation between delivery, control, governance, and insight

This means the transition is not about feature parity, but about modernising the project operating model. Organisations that attempt a one-to-one functional replacement typically encounter:

• Low adoption and limited return on investment
• Escalating support and maintenance costs
• Recreated legacy risks in a new technical landscape

The whitepaper explains how to avoid these outcomes and where executives should deliberately not migrate existing functionality.

What executives will find in the whitepaper

The whitepaper is written for boards, CFOs, CIOs, and senior management who require clarity rather than technical detail. It provides:

• An overview of the current Microsoft project and portfolio management landscape
• Lifecycle and support implications for Project Server and Project Online
• Three pragmatic migration paths aligned to organisational scale and governance maturity
• Indicative cost and risk considerations, including total cost of ownership
• Clear guidance on what should be retired rather than rebuilt

The emphasis is on decision-making, risk control, and financial sustainability.

Why this requires action now

With Project Online scheduled to stop and Project Server approaching the end of its strategic product life, the window for controlled decision-making is narrowing. Deferring decisions beyond 2026 typically leads to:

• Higher run costs
• Increased security and compliance exposure
• Reduced flexibility and higher change costs later

The key question for executives is no longer whether change is required, but how deliberately and on what timeline it will be addressed.