Organizational transformation

Digital products, automation and AI are not things an organization installs. They change how work is organized, who decides what, how money flows, what skills people need and how success is judged. That broader change is organizational transformation. Studies and surveys of large transformations have repeatedly found that many fall short of their goals, with estimates often quoted at well over half; the usual reasons are not technology but unclear purpose, weak leadership, structures that fight the new ways of working and change fatigue.

This lesson covers what transformation means, how to define the target operating model, how team structures shape outcomes, how to plan and govern a transformation roadmap, and how ITIL's guiding principles apply. Lesson 11 covers people, skills and culture, and lesson 12 covers measurement. Larchmont's three-year digital plan is the running example.

What transformation is

A transformation is a fundamental change in how an organization creates value, as opposed to incremental improvement within the existing model. Moving from a project-funded IT department serving the business to persistent product teams delivering digital services to customers is a transformation; making the existing change advisory board meet twice a week is an improvement. Both matter, but transformation changes several dimensions at once: strategy, structure, processes, technology, skills, culture and measures.

ITIL's four dimensions of service management, introduced in ITIL-110, are a useful check that a transformation is holistic: organizations and people; information and technology; partners and suppliers; and value streams and processes. A transformation that changes technology but not people, or processes but not suppliers, is likely to stall. The guiding principle 'think and work holistically' applies directly.

The target operating model

An operating model describes how an organization runs: its structures, decision rights, processes, governance, sourcing, locations, technology and measures. A target operating model (TOM) describes the intended future state. It should be specific enough to guide decisions ('who approves a production change?', 'who funds the booking app?') but not so detailed that it becomes a rigid blueprint that ignores learning.

Larchmont's target operating model, agreed by its executive team, rests on five design choices: organize around customer journeys and products; fund persistent teams through quarterly portfolio reviews; provide shared capabilities through an internal platform; embed controls in automated pipelines with central standards; and govern AI through the framework from lessons 8 and 9. Each choice was explained with the outcome it serves, so that people could apply the intent when details were unclear.

Team structures and Conway's law

In 1968 the computer scientist Melvin Conway observed that organizations design systems that mirror their own communication structures. If three separate teams build a booking system, it tends to end up with three parts joined by awkward interfaces. This observation, known as Conway's law, cuts both ways: an organization can shape its architecture by shaping its teams, a tactic sometimes called the 'inverse Conway manoeuvre'.

The book Team Topologies (Skelton and Pais, 2019) describes four team types that many digital organizations now use. Stream-aligned teams own a flow of work for a product, service or customer journey from end to end. Platform teams provide internal services that reduce the load on stream-aligned teams. Enabling teams are specialists who help other teams adopt new skills, such as test automation or AI, and then step back. Complicated-subsystem teams own parts that need deep specialist knowledge, such as a pricing engine. It also describes three interaction modes: collaboration, X-as-a-service and facilitating.

Team design also considers cognitive load: the amount of information and responsibility a team can handle well. A stream-aligned team that must also run its own Kubernetes clusters, security tooling and AI models may be overloaded; a good platform and enabling teams reduce that load. Larchmont capped stream-aligned teams at about eight to ten people and tried to give each a clear area of ownership.

Where the ITIL practices live

In a product operating model, practices are not owned by single departments. Some are performed mainly inside product teams (much of incident handling, deployment, release, and continual improvement for their products). Some are provided as platform services (monitoring tooling, pipelines, configuration data). Some remain central because they need an enterprise view (major incident coordination, enterprise risk and information security standards, supplier contracts, portfolio and financial management). Larchmont published a simple matrix showing, for each practice, who sets standards, who performs the work and who gives assurance, which removed many arguments about 'who does ITIL now'.

Planning the transformation

Transformations can be attempted all at once or step by step. Big-bang reorganizations promise speed but create long periods of disruption and leave little room to learn. Incremental approaches, consistent with the guiding principle 'progress iteratively with feedback', start with one or two pilot areas, learn, adjust the model and then expand in waves. They take longer to reach the whole organization but are more likely to work and to keep the business running.

Larchmont planned three waves over three years. Wave one built the Larchmont Connect product team, the first version of the platform and the AI governance framework. Wave two moved warehouse operations and transport planning into product teams and scaled self-service and automation in the service desk. Wave three moved finance systems, retired the old portal and moved most suppliers to new contracts. Each wave ended with a review that could change the plan for the next.

# Order transformation initiatives by dependency (topological sort), then group into waves
from collections import defaultdict, deque
deps = {
    "AI governance framework": [],
    "platform v1": [],
    "Connect product team": [],
    "observability by default": ["platform v1"],
    "automated change controls": ["platform v1"],
    "ticket classifier": ["AI governance framework"],
    "warehouse product team": ["platform v1", "automated change controls"],
    "tracking virtual agent": ["AI governance framework", "Connect product team"],
    "self-service portal relaunch": ["ticket classifier"],
    "retire old portal": ["tracking virtual agent", "Connect product team"],
    "finance product team": ["warehouse product team"],
}
indeg = {k: len(v) for k, v in deps.items()}
users = defaultdict(list)
for k, v in deps.items():
    for d in v:
        users[d].append(k)
wave, ready, n = {}, deque(k for k, d in indeg.items() if d == 0), 0
for k in ready:
    wave[k] = 1
while ready:
    k = ready.popleft()
    for u in users[k]:
        wave[u] = max(wave.get(u, 1), wave[k] + 1)
        indeg[u] -= 1
        if indeg[u] == 0:
            ready.append(u)
for w in sorted(set(wave.values())):
    print(f"step {w}: " + ", ".join(sorted(k for k in wave if wave[k] == w)))

step 1: AI governance framework, Connect product team, platform v1
step 2: automated change controls, observability by default, ticket classifier, tracking virtual agent
step 3: retire old portal, self-service portal relaunch, warehouse product team
step 4: finance product team

The dependency ordering is a planning aid, not a schedule: it shows, for example, that the virtual agent cannot safely launch before AI governance exists and that the old portal cannot be retired until the new product and virtual agent are in place. Larchmont grouped the resulting steps into its three waves according to capacity and business calendars, such as avoiding big changes before the autumn retail peak.

Governing the transformation

A transformation needs its own governance, light enough not to slow it down and strong enough to keep it on course. Typically an executive sponsor owns the outcome, a transformation office coordinates the roadmap, dependencies, risks, communication and measures, and a steering group of senior leaders meets regularly to review progress, remove obstacles and make decisions that cross boundaries. The transformation office should be small and temporary, helping the organization change rather than becoming a new bureaucracy.

Governance should focus on outcomes and leading indicators, not only on milestones. 'Product team launched' is a milestone; 'lead time for Connect changes fell from 19 days to 2' is an outcome. Lesson 12 covers how to design these measures. It should also watch risks specific to transformation: key people leaving, loss of operational stability during change, supplier transitions, budget overruns and change fatigue.

Transformation that changes jobs must respect labour and employment law. For federally regulated employers with unionized staff, which include many interprovincial trucking firms, the Canada Labour Code's technological change provisions generally require notice to the union, at least 120 days in advance, of technological change likely to affect the terms or security of employment of a significant number of employees, and can open the collective agreement for negotiation on that change. Provincial labour laws and collective agreements contain their own rules, and employment standards set notice requirements for layoffs. Early, honest consultation is both a legal duty and good change management.

Applying the guiding principles

The seven guiding principles from ITIL-120 are a good test for any transformation plan. Focus on value: is every initiative tied to a customer or business outcome? Start where you are: have we assessed what already works, such as Larchmont's reliable warehouse system, before replacing it? Progress iteratively with feedback: are we piloting and learning? Collaborate and promote visibility: are people involved and is progress visible? Think and work holistically: does the plan cover all four dimensions? Keep it simple and practical: is the model as simple as it can be? Optimize and automate: are we simplifying before automating?

Larchmont's steering group used the principles as a checklist at each wave review. In wave one review it found that 'start where you are' had been neglected: a team had planned to replace the warehouse management system, which worked well and was not a constraint on customer experience. The replacement was dropped and the money moved to observability and the virtual agent.

Partners and suppliers in the transformation

Transformations often stall at supplier boundaries. Larchmont's existing contracts were written for the old model: fixed-scope projects, change requests for every new idea, monthly reports on activity, and long notice periods. A product team that wants to release weekly cannot wait six weeks for a supplier change request. The supplier management practice from ITIL-141 therefore became part of the transformation plan rather than an afterthought.

Larchmont took three steps. It reduced the number of small application vendors by consolidating overlapping tools. It renegotiated its largest contracts to include outcome-based measures, such as API availability and incident restore times, along with the right to integrate through modern interfaces and to receive release notes in advance. And it built a sourcing principle into the operating model: product teams may choose suppliers for components below a cost threshold from an approved list, while strategic suppliers are managed centrally with joint quarterly reviews.

Suppliers can also be partners in the change. The cloud provider ran training for the platform team, the mapping API vendor joined the Connect team's discovery sessions, and the managed security service agreed to ingest pipeline events so that security monitoring kept pace with faster delivery. Treating key suppliers as part of the value stream, with shared goals and visible measures, made the new ways of working possible at the boundaries.