DE Book a call

The delivery model

Approach

Every workstream runs the same cycle. The structure is deliberately boring, because the interesting part should be your business, not our process.

Four phases, per workstream

Effort curve across four phases: discovery, implementation, rollout, handover. Effort peaks at implementation and then declines to zero.

  1. Understand the real situation, decide the target, and produce a plan you can fund.

    • As is assessment across product, processes, technical architecture and team
    • Target picture and requirements
    • Tool selection with a five year total cost of ownership comparison, proof of concept where the call is close
    • Feasibility checks on the parts most likely to break
    • A sequenced, costed transformation plan

  2. Build toward the agreed architecture, release by release, starting where it hurts most.

    • Detailed design: processes, requirements, migration plan, system and integration design
    • Iterative build to a working v1, never a big bang
    • Highest pain workstream first
    • Time and materials with a blended team

  3. Get it into live operation across every market, with the people who have to use it.

    • Training and change management
    • v1 into a smaller market first, then wave rollout across markets and channels
    • Support and operations
    • Further development against the roadmap

  4. Leave a team that runs it without us, and a run rate that goes to zero.

    • Knowledge and ownership transfer
    • Enablement and documentation: runbooks, architecture docs
    • Integration into your team
    • Clean self operation and exit, with an optional support retainer

Workstreams (shop, OMS, ERP, data) are modular and individually selectable. They start staggered, roughly a month apart, so senior capacity stays cleanly loaded and no single cutover carries the whole programme risk.

Delivery principles

Four rules we do not bend.

Plan the whole target picture. Ship in pieces.

The final architecture is decided up front and never optimised locally. Then we build toward it release by release, at speed. The two are not in tension. Skipping the first is what makes the second expensive.

Highest pain workstream first.

Not the easiest one, and not the one with the most willing stakeholder. Early credibility comes from fixing something people actually feel.

Never a big bang.

v1 goes live in a market small enough to absorb a bad week and real enough to prove the model. Then waves.

The plan contains its own ending.

Handover is a phase with a date and a scope, not a goodwill gesture at the end. Our run rate declines on a schedule agreed before we start.

Ownership

Three seats. Never merged.

Most programmes that drift are not short of effort. They are short of a clear answer to who decides.

  1. 01

    Sponsor

    Yours, senior, part time but genuinely engaged

    Owns the outcome and the budget, sets priorities when they conflict, and is the final approver. This seat cannot be outsourced, including to us. A named business leader in this seat works better than a technology function owner, because most of the hard calls are commercial.

  2. 02

    Delivery Lead

    One person, near full time

    The single driver of the plan and the execution. There is exactly one. At the start this is usually ours. You name a co-lead from your side who is embedded from day one and takes the seat over at a defined trigger, with us stepping back to support and coaching.

  3. 03

    Delivery team

    Blended, ours and yours

    Architects, engineers, product managers and change leads from our side, working alongside your domain and product owners. Specialists join when their workstream starts and come off when it no longer needs them.

Decision rights: the Delivery Lead drives, the Sponsor approves. One driver, one approver, no split ownership.

Team model

Blended is the recommendation. Fully external is available and worse.

In a blended team we hold the delivery lead and the key engineering seats, and your people take the roles where you already have capacity and domain knowledge. It costs less than a fully external programme. More importantly, it is the only structure that reliably ends with a team that can run the result, because ownership cannot be transferred in the last month. It has to be built during.

Optional: building your team while we deliver

Some clients use the programme window to build the internal team that will inherit it. We can deliver the external capability now while recruiting, onboarding and upskilling your own people in parallel, with as much or as little recruiting involvement as you want.

What drives the number

Four things decide what this costs.

We clarify all four in discovery, because an estimate produced without them is a guess with a decimal point.

  1. 01

    How deeply the systems are wired together

    Decoupling effort is usually the single largest and most underestimated line in a replatforming programme.

  2. 02

    How much process has to be redesigned

    Lifting a broken process into a new system produces a more expensive broken process.

  3. 03

    How much the team has to be reskilled

    A platform nobody can operate is not a delivered platform.

  4. 04

    What is missing entirely

    The components nobody has counted yet, a CMS, a PIM, a data layer, tend to surface in week three.

Start with six weeks.

A discovery gives you a target architecture, a costed and sequenced plan, and a recommendation you can defend to your board. If the answer is that you should not run the programme, you will get that answer too.

Book a 30 minute call

Or write to hi@colayer.io