The IT Division. Refactored.

Read the 49-slide argument as a system, not an organisation chart

The recovered 2009 presentation is The IT Division Refactored, by Richard Durnall. Its period-specific examples and quotations stay attached to the source. The decision worksheet below is a new editorial addition.

New explanation and worked examples by the editorial team.

The diagram in words: People and capability → Architecture and routines → Culture, outcome and review.

A route through the presentation

Slides 4–14 establish the agenda, the problem and organisational context; the PARC lens separates people, architecture, routines and culture. Slides 15–24 consider the refactored organisation, structure and trade-offs. Slides 25 onward move into processes, flow, cultural choices and consequences of changing the system. Page numbers here are PDF page positions, including the title material.

Four lenses for one decision

People concerns include skills and development; architecture concerns include structural boundaries and authority; routines concern how work and decisions move; culture concerns behaviour and incentives. These lenses interact. Redrawing reporting lines alone cannot establish whether a customer outcome improves.

Compare inside-out and outside-in logic

The deck contrasts starting from organisational structure with starting from customer and strategy, then designing processes, measures and supporting structure. Use that contrast as a question: what customer outcome and process requirement justify the proposed boundary? The deck’s case models are examples from the presentation, not universal templates.

A completed fictional handoff review

A service request crosses intake, analysis, delivery and release approval. The team records a five-day approval wait but only half a day of active review. The proposed change gives one authorised decision owner a bounded class of low-risk requests. Before adopting it, the team must examine capability, escalation rules, incentives and the work’s actual risk. The timings are invented.

Make a structural proposal testable

Write the customer outcome, current queue, authority conflict, affected skills, changed routine and possible unintended incentive. Choose observations for both benefit and harm, then a review decision. A lower local queue can conceal a new bottleneck elsewhere; follow the whole request rather than one team’s utilisation.

What the slides do not prove

The deck’s old organisational examples, project statistics and professional contacts are not current results or support details. The source demonstrates an argument about systems management; a present reorganisation needs its own evidence. The worksheet does not report work performed by Durnall or a client.