From consulting deck to working system: a 2-week scoping playbook

Many digital transformation projects in Indonesia start the same way. A consultant spends months on discovery, delivers a long report and a polished deck, and leaves. The organization then has to find someone else to build what the deck describes, and that team often starts discovery again. Time and budget go into documents instead of working systems.

There is a faster way to start, which does not cut corners: a short, structured scoping phase that ends in a plan you can execute. This playbook explains what that phase should contain, whoever runs it.

Why scoping, not discovery without end

Discovery has no natural end point. Scoping does: it ends when you can answer four questions with confidence.

1. What is the real problem, stated in a way that can be tested?
2. What should the target solution look like across process, system and governance?
3. In what order should it be built, and what does each phase deliver?
4. What will each phase cost, and where are the decision points?

When these four answers exist, the organization can make an informed decision to proceed, adjust or stop. At Kiwi Solutions, getting there takes one to two weeks.

Before scoping: the discovery call

Scoping starts with a short conversation. At Kiwi Solutions it is a thirty-minute discovery call with Jeffrey or Archie. You describe the problem, and we tell you honestly whether and how we can help. If it is not a fit, you have lost half an hour, not a quarter.

To make the call useful, prepare:

• The problem in your own words, and why it matters now.
• The systems and teams involved.
• Any constraints that are already fixed: deadlines, regulations, budget ranges, existing contracts.

Week 1: look at reality (inductive)

The first half of scoping works from the ground up. The goal is to understand how work actually happens, which is often different from how it is documented.

• Observe current operations. Watch the process run, talk to the people who do the work, and follow a few real cases from start to finish.
• Analyze processes, data and systems. Where is information captured, retyped or lost? Which reports are assembled by hand? Which systems do not talk to each other?
• Find root causes. Separate symptoms (reports are late) from causes (data is entered twice in two systems).
• Write a testable problem statement. A good problem statement names the process, the gap and how you would know it is fixed. “We need a new system” is not a problem statement.

Week 2: design the answer (deductive)

The second half works from the top down. It starts from what the organization is trying to achieve and designs backwards.

• Start from objectives. What business outcome should change, and how will it be measured? These become the KPIs for delivery.
• Form hypotheses from proven frameworks. Use established ways of solving similar problems as a starting point rather than inventing from scratch.
• Design the end-to-end architecture. Cover process, system and governance together: what changes in how people work, which systems are built, bought or integrated, and who owns decisions and data.
• Stress-test and iterate. Walk the real cases from week 1 through the proposed design. Where it breaks, revise it.

The two directions check each other. Observation keeps the design realistic; objectives keep the observation focused.

The output: a phased plan with prices

Scoping should end with a document a decision-maker can act on, not a library of findings. It contains:

• The problem statement from week 1.
• The proposed architecture from week 2.
• A phased delivery plan. Each phase is defined by an outcome, not by activity, with milestones along the way.
• Decision gates between phases, where you review results against the KPIs and decide whether to continue, adjust or stop.
• Prices per phase, set up front, rather than open-ended hourly billing.
• Risks and dependencies, with how each will be managed.

Phasing is what makes the plan safe. You commit to the first phase with full information, and every later commitment is made with the results of the previous phase in hand.

After scoping: delivery that matches the plan

The point of a good plan is that it gets executed. In Kiwi’s delivery model, the work runs in outcome-based phases with milestones and decision gates, weekly progress reporting, and knowledge transfer at every handover. Deliverables include KPIs, actionable outputs and documentation, so your team can run and extend the system after we hand it over.

Two things make the difference between a deck and a working system:

• The same people diagnose and build. At Kiwi Solutions, the seniors who diagnose the problem build the system and ship it. Nothing is lost in a handover between a consulting firm and a separate development vendor.
• A working deliverable at every milestone. Progress is measured by what runs, not by what is written.

Checklist: is your scoping on track?

• Have people observed real operations, not only read process documents?
• Is there a problem statement you could test?
• Does the architecture cover process, system and governance?
• Is the plan phased by outcome, with decision gates?
• Is every phase priced?
• Do you know who will build it, and are they the same people who diagnosed it?

If any answer is no, the plan is not ready to fund.

Start with a conversation

Kiwi Solutions provides IT and digital transformation consulting that ends in a working system, built by our software development team. You can read more about the founders and how we work on the about page. Book a discovery call to see whether a two-week scoping fits your project.