Don’t Pave the Cowpath: What Boston’s Streets Teach Us About ITIL (Version 5)’s Last Two Principles

Boston's streets are a useful warning for service teams. Do not automate inherited mess before asking whether the process should exist at all.

There's a legend Americans love to tell about Boston: that its streets were laid out by cows. Seventeenth-century cattle wandered from pasture to water, their hoofprints hardened into paths, the paths became lanes, the lanes became streets, and four hundred years later a rental car satnav in the North End quietly gives up and suggests you walk.

Historians will tell you the cow story is mostly myth. Boston's tangle actually follows the original shoreline, the hills, and the footpaths of a 1630 settlement that grew one expedient shortcut at a time. Which, if you think about it, is worse. The cows are innocent. People did this, sensible people, each making a locally reasonable decision, none of them ever stepping back to ask whether the whole thing still made sense.

Compare that with Philadelphia, where William Penn and his surveyor Thomas Holme sat down in 1682 and drew a grid before anyone laid a brick. Or Manhattan, where the Commissioners' Plan of 1811 stamped numbered streets and avenues across the island. A first-time visitor can navigate Midtown in ten minutes. I can vouch for this personally: on my first ever visit to New York, I found myself directing the cab driver, who was confidently heading east when my hotel was west. I'd been in the country roughly an hour. That's not me being clever, that's the grid doing its job. A tenth-time visitor to Boston still can't find Faneuil Hall.

If you manage services for a living, you already know where this is going. Every organisation has a Boston somewhere in its process estate.

In this blog, we'll explore:

• Why Boston's street plan is the perfect picture of an unexamined process
• What ITIL (Version 5)'s sixth guiding principle, keep it simple and practical, has to say about grids
• Why the seventh, optimise and automate, puts those two verbs in that order on purpose
• How to spot when you're about to pave a cowpath, and what to do instead

The city you inherit, the city you design

Or: nobody ever chose the mess. They just never chose anything else.

Here's the uncomfortable truth about Boston's streets: at no point did anyone decide to build a labyrinth. Every lane made sense when it appeared. The path to the well was the shortest path to the well. The road hugging the shoreline hugged the shoreline that existed in 1640, never mind that Boston later filled in the bay and the shoreline moved half a mile.

Your process estate grew the same way. That six-step approval workflow made sense in 2011, when the auditors demanded it after an incident everyone has since forgotten. The service desk re-keys data between two systems because in 2015 the integration budget went elsewhere. Each decision was locally rational. Nobody owns the accumulated result, so nobody questions it.

ITIL (Version 5), which now frames its scope as digital product and service management, not just IT service management, closes its seven guiding principles with the two that deal with exactly this inheritance: keep it simple and practical, then optimise and automate. I don't think the ordering is accidental, and I'd argue the sequence is the whole point.

Keep it simple and practical

The grid principle

Philadelphia's grid is simplicity as a design decision. Numbered streets one way, named streets the other, and the address itself tells you where you are. Nobody needs a guided tour or a resident guru. The system explains itself.

That is what ITIL (Version 5)'s sixth guiding principle asks of a process: use the minimum number of steps needed to accomplish the objective, and judge every step by whether it contributes to the outcome. Not whether it's traditional. Not whether removing it would upset the person who added it. Whether it creates value.

The test I use with clients is blunt: could a competent new joiner follow your process from the documentation alone, the way a tourist navigates Manhattan from the street signs alone? If the honest answer is "well, you'd need to ask Deborah, she knows why we do the second sign-off", congratulations, you've found a cowpath. Deborah is your shoreline from 1640, and the bay has long since been filled in.

Simplicity also has a compounding payoff the manual is explicit about: simple processes are easier to measure, and, critically for what comes next, far easier to automate.

Optimise and automate

In that order. The order is the entire principle.

The seventh guiding principle contains its own instruction manual in four words: optimise, and then automate. ITIL (Version 5) is unambiguous that optimisation comes first, because automating a flawed process doesn't fix the flaw. It industrialises it.

Michael Hammer made the same argument in the Harvard Business Review back in 1990 with the subtlety of a wrecking ball: "Don't Automate, Obliterate." Bill Gates put it more diplomatically, automation applied to an efficient operation magnifies the efficiency, and automation applied to an inefficient one magnifies the inefficiency. American planners even have a phrase for it: paving the cowpaths. You take the crooked path the cows made and you pour tarmac on it, and now you have a crooked road. A faster mess is still a mess. It's simply a mess with a maintenance contract.

Boston offers the cautionary price tag. When the city finally tried to retrofit sensible infrastructure onto its inherited tangle, the result was the Big Dig, burying the Central Artery at a cost that ran from a planned $2.8 billion to roughly $15 billion, the most expensive highway project in American history. That is what deferred rationalisation costs. Every year you spend automating around a broken process instead of fixing it, the eventual fix gets more expensive, because now it has to be untangled from the automation too.

And the temptation has never been stronger. ITIL (Version 5) arrives with an AI Capability Model sitting in its Information and Technology dimension precisely because every vendor on earth is currently offering to automate your processes with GenAI or agentic AI. The technology is genuinely impressive. It will also pave your cowpaths at unprecedented speed, and with unprecedented confidence.

Warning: you might be paving cowpaths if…

• Your shiny new RPA bot faithfully re-keys data between two systems that could share an integration, you've automated the workaround, not the work.
• An approval chain has six steps because it had six steps in 2011, and the last person who knew why retired in 2019.
• You're pointing AI agents at a process nobody has mapped, on the theory that speed will compensate for confusion.
• You've automated the weekly report nobody reads. Nobody now fails to read it much more efficiently.
• Your service catalogue offers 400 automated request items and users still email the service desk, because finding the right item takes longer than typing "please help".

The grid comes first

How to rationalise before you automate

The good news: unlike Boston, you don't need to demolish anything or bury a motorway. You need a sequence.

• Map the value stream before touching the tooling. ITIL (Version 5) lists value streams and processes among its four dimensions for a reason: you cannot simplify what you haven't seen end to end.
• Apply keep it simple and practical as a demolition tool. For each step, ask what outcome it serves. No outcome, no step, however long it's been there and however much Deborah protests.
• Optimise what survives. The continual improvement model gives you the route: establish where you are, define where you want to be, and check "are we getting there" as you go, ITIL (Version 5)'s deliberately present-tense rewording of the old "did we get there".
• Automate last, and only the process that has earned it. A stable, simple, measured process is an automation candidate. Anything else is a cowpath with planning permission.

Penn drew the grid before Philadelphia existed; you have to draw yours through a city that's already built. Harder, certainly. But the alternative is Boston: charming to visit, eye-wateringly expensive to run, and entirely dependent on locals who know the shortcuts.

Rationalise first. Then, and only then, reach for the tarmac.