Transformation is a function, not a project

Most organizations change their systems the same way. Someone makes the case for a project. A budget is approved, a team is assembled, a vendor is chosen, and a go-live date goes on the calendar. The team works hard, the system goes live, and the project closes. The people who understood the work move on to other things.

Then the organization keeps changing. A new product line needs a new approval step. A regulation changes what must be recorded. Two teams merge, and their spreadsheets do not. None of this waits for the next project, yet the capacity to respond left with the last one.

This is the pattern behind a lot of frustration with technology. The problem is rarely that the last project failed. It is that the project model treats change as an event, when for most organizations change is a permanent condition.

Why the project model keeps disappointing

The project model was designed for work with a clear beginning and a clear end: building a warehouse, moving an office, installing a machine. Those things are finished when they are finished. Software that runs an operation is never finished in that sense. It sits in the middle of the work, and the work does not stand still.

When a system is delivered as a project, three things tend to happen once the project closes.

• Knowledge disperses. The reasons behind the design, the edge cases the team discovered, the compromises that were made: most of that lived in people and meetings. When the team disbands, the organization keeps the system but loses the understanding of it.
• Small changes pile up. Each request is too small to justify a new project, so it waits. Meanwhile people work around the gap with a spreadsheet, an email, or a manual check.
• The system drifts from the work. Month by month, the way the organization actually operates moves away from the way the system expects it to operate. The next project then begins by rediscovering what the last one already knew.

None of this is anyone's fault. It is what the model produces.

What a function looks like

Organizations already know how to handle work that never ends. Finance does not close the books once and disband. Legal does not stop reviewing contracts after the first one. These are functions: standing responsibilities, carried by people who stay, with a memory of what came before and a steady capacity to handle what comes next.

Transformation can work the same way. Treating it as a function means a few concrete things.

• Someone owns it continuously. There is a named, accountable owner for how the organization's systems evolve, not only for the next initiative.
• The capacity is steady. Instead of assembling a team for each project and dissolving it afterwards, there is an ongoing capacity that moves from one need to the next as priorities change.
• The memory is kept. Decisions, context and constraints are recorded where the next person can find them. Nobody has to reconstruct why the approval flow works the way it does.
• Change is continuous. The cycle of understanding a need, shaping an answer, building it, verifying it, deploying it and evolving it runs again and again, at the pace the organization needs.

Three shifts in practice

Moving from projects to a function is less about organizational charts than about habits. In our experience the change shows up in three places.

From deliverables to capacity

A project is described by what it will deliver. A function is described by what it can take on. The question moves from "what will this cost to build" to "what should our capacity work on next". That makes it possible to fix the small things that never justified a project, and to change direction without starting a new procurement.

From handoff to continuity

In the project model, the most dangerous moment is the handoff: from the people who designed the system to the people who run it, or from one vendor to the next. A function removes most handoffs, because the same crew carries the work from the first conversation to operations and back again. What it cannot remove, it records.

From big releases to steady evolution

When change is expensive to start, organizations save it up and release it in large batches. Large batches are harder to test, harder to explain and harder to undo. A standing function can make changes in smaller steps, each one understood, verified and explained to the people it affects.

What it asks of leaders

A function is not free of management. It asks leaders to decide a few things deliberately.

First, who owns the evolution of the organization's systems, and how that person is supported. Second, how the steady capacity is set and reviewed, so that it stays proportionate to the ambition. Third, how priorities are chosen, because a capacity that can take on anything will be asked to take on everything.

It also asks for patience of a particular kind. The benefits of a function are cumulative. They come from knowledge that stays, from problems that are fixed while they are still small, and from systems that keep matching the work. They are easier to see over a year than over a quarter.

Where Croo fits

Croo was built around this idea. Your Croo is a crew that stays beside the organization: one person in the room who knows your operation, and behind them the disciplines the work calls for, from business process and architecture to software engineering, finance and governance. The Factory gives that crew a shared memory and a production system, so that each change builds on the last one instead of starting over.

The relationship runs on ongoing capacity rather than on a sequence of projects. It is not a software licence and it is not a one-off engagement. It is a way to make transformation something the organization carries continuously, without having to build an entire department of its own.

Projects will still have their place. Some changes are large enough to deserve a name, a plan and a date. But when the project ends, the function should not. The organization will keep changing. Its capacity to change should stay.