What to settle with the CEO before the first workshop, how to choose and sequence the first use cases, how a use case gets into production, and how ownership moves to your team.
The job usually arrives with a budget, a rough mandate, and a board that expects something visible inside a year. This is the sequence we use with clients in that position, and the places where it commonly goes wrong.
The sequence holds across industries. What changes between a plant, a logistics network, a utility, and a bank is where the money sits, which data is hardest to get at, and what the organization pushes back on. The order of the work stays the same.
Two things get built at the same time. The program is the set of use cases that produce financial results: the demand forecast, the maintenance predictor, the document copilot, the fraud model. The office is the team, the platform, and the rules that deliver those use cases and keep them running once they are live.
Programs fail when only one of the two gets built. Use cases delivered without an office leave systems nobody in the company can operate, extend, or fix once the delivery team goes home. An office built ahead of the use cases produces a payroll and a platform bill with nothing in the P&L to defend at budget time. The use cases fund the office, and the office is the reason results are still there in year three.
Two questions go to the CEO before anything is scoped, and the answers have to be said out loud, because the people in the room are each assuming something different.
The first is what the program is for. Cutting cost to protect gross margin, growing revenue, and reaching technical parity with competitors who moved earlier are three different programs, with different use cases, different time horizons, and different tolerance for a use case that fails. The funding case looks different in each.
The second is where the office reports. It reads like an org chart detail and it decides whether the program is still there in eighteen months. The value sits in the business units, so the office has to sit close to them, with a named sponsor who owns a P&L line and wants the result. An office placed inside IT with no business owner tends to build work that meets its own standards and gets little use.
Spend the first six to eight weeks finding out where the company actually makes and loses money by product, customer, and process; what data exists, which system holds it, and what condition it is in; and who inside is already doing this work. Most large companies have analysts in the business units building models nobody upstairs knows about. Find them before hiring around them.
By the time this starts there is always a list of candidate use cases. Score each one on the value at stake and on feasibility, and treat adoption as part of feasibility: whether the person whose work it changes will use it, and whether anyone has agreed to own the result. Scored that way most of the list falls away, and it is worth recording which ones were rejected and why, because they come back.
Then sequence what survives. A few short use cases go first, because you will be asked what has shipped long before the large ones return anything. One or two larger ones carry the reason the program was funded at all. Use cases that touch regulated processes, or that depend on the worst data in the company, wait until the platform and the controls can carry them.
Every use case walks the same four steps: map the process and the data underneath it, frame the problem and choose the technique, build against a business KPI rather than a model metric, and run it in production.
The step that decides the outcome is not on the diagram. A churn model the retention team does not open returns nothing, and it will not get opened if it arrives as a separate application with its own login. The output belongs inside the systems those people already work in, which usually means the CRM, the planning system, or the case queue. Expect the process around it to change, and staff that change with more effort than the model itself takes.
Adoption decides whether a use case returns anything, and it depends on where the output lands and who owns the result.
Then measure. Set the baseline before release, measure after, and have finance validate how the number was calculated. The second wave of funding gets decided on a number finance agrees with.
The first deployment is hand-built. The cost trap is hand-building the next twelve. Shared pipelines, deployment templates, and a platform sized to what is actually shipping bring the tenth rollout down to a few weeks rather than another quarter, and stop it depending on whether one engineer is free that month.
The other half of scaling is change management across many sites or business units at once. It usually takes longer than the technical rollout and needs its own budget, its own staffing, and someone senior accountable for it.
The office is built from the start to run without the people who built it. Your engineers and analysts work alongside us on the first use case and take a larger share of each one after that, until a use case is delivered without us in the room. The code, the documentation and runbooks, the model cards, the monitoring, and a named production owner for each system transfer with it.
Whether we stay on for production support after that is agreed at the start of the engagement.
Tell us the process or system you are trying to improve, and we will tell you what it would take to change it.