You want something important delivered on time. So you take it out of the day-to-day business. You call it a project or a change programme. You put a dedicated team around it and protect it, as far as possible, from the firefighting, reprioritisation and competing demands of BAU.
In many respects, that makes delivery easier. But at some point, what's being built has to land in the organisation that will use it, and the two sides need to be ready for each other.
After more than a decade delivering CLM and KYC programmes at global financial institutions, across multiple continents and programmes of very different shapes and sizes, l've seen this challenge come up repeatedly.
The programme may be ringfenced, but eventually it has to merge back into the heavy traffic of BAU. That's where pace becomes important.
If the programme moves too slowly, the organisation will change around it. Requirements evolve, priorities readjust, regulations are updated and operating models are reorganised. By the time the programme delivers, what's been built may no longer fully reflect what the business needs.
On the other hand, if delivery gets too far ahead, the technology may be ready before the data, processes, people and operating model are able to start using it effectively. The business is then left changing plans at short notice, or go-live falls flat and confidence in the new solution takes a hit.
Different programmes face different pacing risks
CLM implementations tend to follow one of two broad approaches.
The first is the large, bespoke programme, with significant investment, lengthy design phases and extensive customisation. In some cases, an entity master is built alongside the platform implementation.
There are good reasons for taking this route. Large banks have complicated requirements, many stakeholders and years of legacy complexity to work through. But the longer a programme runs, the more the organisation changes around it. Sponsors and other senior stakeholders may also change.
As a result, a programme can stay faithful to its original design while gradually losing touch with what the business now needs. Decisions taken early may no longer fit the organisation, and reopening them brings extra cost, complexity and delay.
Other programmes follow a leaner, faster and more standardised model. There is less design by committee and more willingness to adopt a well-configured platform with limited customisation.
The pace this brings can be valuable, but it can also take the programme ahead of the business. Technical capability may arrive before the data is ready, while processes, responsibilities and operating model decisions are still being worked through.
For example, unresolved data quality problems can be carried into BAU, leaving the business to deal with them after go-live.
Both approaches can work. But the first risks taking so long that the business changes around it, whereas the second risks leaving the business with too little time to prepare.
Requirements need to keep moving
Requirements management is one of the clearest examples of this pacing challenge.
On any multi-year programme, requirements will evolve. The programme needs a practical way to assess those changes and understand what else they affect.
Requirements don't change within neat workstream boundaries. A policy change may have consequences for technology, data, controls, testing and training. A change to the operating model may alter workflows, ownership and adoption plans.
This becomes especially important when a programme runs for several years. The organisation receiving the solution may look quite different from the one that approved the original design.
Separate plans create shared problems
Complex CLM programmes usually have plenty of plans. Technology has a plan. Data has one. Compliance has one, and business adoption has another.
Each plan may look sensible on its own. The trouble starts when they aren't joined together.
A delay in technology could affect data preparation, testing, training and operational readiness. A change in requirements may alter design, build and adoption activity across several teams. Without a shared view, one workstream's delay quickly becomes another workstream's material risk.
An integrated plan allows programme leaders to see where delivery and readiness are beginning to diverge. It gives teams a common basis for working through the consequences when a date, requirement or sequence changes.
The plan has to be actively maintained and genuinely used to run the programme. A document that is only updated for governance meetings probably won't be robust or current enough when things start to go wrong on the ground.
Technology and adoption need the same timetable
Technology sequencing is one of the most consistent challenges l've seen on CLM programmes.
Technology teams are usually under pressure to demonstrate progress and commit to delivery dates while dealing with complex work. Capability may be delivered later than expected or in a different order, forcing adoption teams to reorganise their plans.
Faster delivery can be disruptive as well. The business may suddenly have to bring forward data preparation, training, process changes or operating model decisions.
Faster delivery can be disruptive as well. The business may suddenly have to bring forward data preparation, training, process changes or operating model decisions.
The potential for these problems means technology delivery and business adoption need to be considered together from the outset.
Flexibility is key. Adoption plans should allow for dates and sequencing to move. Data teams need to understand what a different release order would mean for preparation and migration. Programme leaders need visibility across both sides, so they can see the consequences early enough to do something about them.
Programmes don't operate in ideal conditions
Major CLM programmes often run for several years, while senior sponsors may be expected to show meaningful progress within a much shorter period. That can create pressure to accelerate visible delivery, even when the data, process and adoption work needs longer.
Regulatory deadlines and remediation commitments add to that pressure, alongside limited budgets and competing priorities. These are real constraints, and they affect decisions about scope, sequencing and pace throughout delivery.
A programme can't choose an ideal pace and expect the rest of the organisation to follow. It has to work within that environment and leave enough room to deal with changes along the way.
Build flexibility into the programme
The programmes l've seen work well have combined good preparation with enough flexibility to respond when plans move.
Data readiness should be designed around more than one possible go-live sequence. Business adoption plans need to reflect the connections between technology, people, processes and the operating model. Requirements need to be checked against current business needs throughout delivery.
Relationships across the programme are just as important. When something changes, technology, data, compliance and business teams need to have direct conversations quickly.
Delays become much more damaging when teams argue over ownership, defend their individual plans or work from different versions of the truth. Strong working relationships make it easier to understand the consequences and agree a sensible response.
None of this removes the complexity from CLM delivery. It gives the programme a better chance of adapting without passing a long list of unresolved problems into BAU.
From my time working on CLM and KYC programmes, that remains one of the clearest lessons. Delivery and readiness both have to keep moving.
The hard part is keeping them together.