Article · Methodology
The 4D Framework: How PAC Delivers Consulting That Sticks
Advisory work usually loses its value in the weeks after the final presentation. Diagnose, Design, Develop, Deploy is our attempt to build the handover into the work from the first week.
At a glance
- Recommendations stall for practical reasons: they were designed for the organisation on paper, the people who must run them were not involved, and nobody owns the first ninety days.
- Each of the four phases ends with a specific output and a test that someone other than the consultant can apply.
- The framework moves effort forward into diagnosis and keeps it going after launch. It is not linear, and it is not free.
Consider a strategy document that is clear, well argued and approved by the board. Three months later the finance team is closing the month the way it always did, the new approval thresholds are known to two people, and the dashboard built for the launch has not been opened since. Nobody did anything wrong. The work was finished before it was adopted.
That gap between finished and adopted is where we have organised our method. The 4D Framework has four phases, Diagnose, Design, Develop and Deploy, and four phases are not unusual. What we try to do differently is treat each phase as complete only when it has produced something specific and passed a test the client can run without us.
This note sets out those outputs and tests, explains why we weight them the way we do for organisations working in East Africa, and describes the places where the framework is a poor fit.
Why good work stalls after the final presentation
When a recommendation fails to take hold, the analysis is rarely the cause. Three mechanisms explain most of what we see.
The design fits the organisation on paper
An organisation chart says who approves what. The working reality is often different: a purchase order that formally needs three signatures moves through one finance officer who chases the other two on WhatsApp. A process redesign that starts from the chart will break the workaround without understanding why it exists, and the people doing the work will quietly rebuild it.
The people who must run it were not in the room
Decisions made at leadership level and handed down as a change programme tend to arrive as instructions. Where a few senior people carry much of the institutional knowledge, the gap widens. The person who knows why the vendor list looks the way it does was interviewed for an hour and never consulted again.
Nobody owns the first ninety days
Most advisory engagements end with a presentation or a report. The period that decides whether anything changes, when the new template meets its first real deadline, is left to a team already at capacity. Kenyan national and county governments work to a financial year that runs from 1 July to 30 June, and many donor-funded programmes report against grant calendars of their own. A change that misses its window can wait months for the next one.
A recommendation is finished when someone other than the consultant is running it.
The four phases, and what each one must produce
The figure summarises the framework. The columns matter less than the last two rows of each: what the phase hands over, and the test it has to pass before the next one begins.
Figure The 4D Framework: output and exit test for each phase
Diagnose
What is actually happening here?
Produces
A one-page problem statement signed off by leadership, an evidence log, and a list of what is out of scope.
Exit test
A manager who was never interviewed recognises their own week in the findings.
Design
What will we change, and what will it cost?
Produces
A decision paper with two or three costed options, and a list of what will stop.
Exit test
The preferred option fits inside a budget line and a calendar the client already has.
Develop
What will people actually touch?
Produces
Working templates, procedures and reports, piloted in one unit, each with a named owner.
Exit test
A client team member runs the pilot without a consultant in the room.
Deploy
How do we get through the first full cycle?
Produces
A phased rollout, agreed measures, and a handover with an owner, a review date and a stop rule.
Exit test
The client can say what working looks like using numbers it already collects.
Diagnose: find the organisation that actually exists
Diagnosis starts with documents but does not end there. We read the strategy, the policies and the last two reporting cycles, and then we watch the work. A useful exercise is to pick a single transaction, such as a supplier payment or a new hire, and follow it from request to completion, noting every hand-off, every point where data is typed in again, and every moment where someone leaves the system to solve a problem by phone.
Interviews run at three levels: leadership, middle management, and the people doing the work. The disagreements between levels are usually the finding. When a director describes a process one way and the team describes it another, the useful question is not who is right but what the difference is protecting.
What comes out
The main product is a problem statement short enough to fit on one page and specific enough to be wrong. It says what is happening, what the evidence is, and what the engagement will not attempt. Leadership signs it. The signature matters because it is the last point at which scope can be argued cheaply.
Diagnosis sometimes ends with a recommendation not to proceed. If the constraint is a disagreement at the top that no process fix will resolve, we would rather say so in week three than in month six.
Design: make choices, and cost them
A design phase that presents a single recommended answer invites approval and discourages scrutiny. We present two or three options, each with its cost in money and in staff time, and each with an honest account of what it puts at risk.
The constraints we check first are the unglamorous ones: the budget line and when it can next be changed, the procurement rules that govern buying anything, the connectivity at the sites where the work happens, and the hours a busy team can spare in a month. An option that needs a new budget line in March cannot start in a public body until the next financial year. An option that assumes reliable internet will not survive a branch office that loses it every afternoon.
Design with the people who will run it
Working sessions with the future owners belong inside the design phase, not in a consultation held afterwards. They catch practical problems early, and they change who feels the result belongs to them.
Say what will stop
A design that only adds work loses to the existing workload. We ask every option to name at least one thing the organisation will stop doing, such as a report nobody reads or an approval that adds delay without adding control, so that the change has room to fit.
Develop: build what people will touch
Development produces the artefacts themselves: procedures, templates, reports, training material and, where needed, software configuration. Our default is to build in the tools the organisation already uses. If a team lives in spreadsheets and messaging groups, a well-built spreadsheet with clear ownership will be used long before a new platform is. New software is justified when volume, audit requirements or the number of sites make the existing tools a real constraint, and even then it goes in after the process is stable, not as a substitute for the process.
Every component gets a named owner on the client side, a person and not a department. Material is written in the language the team uses at work, which in many Kenyan workplaces is a mix of English and Kiswahili, and it is piloted in one unit before anything is scaled. The pilot is judged by one question: can the client's own staff run it when we are not in the room?
Deploy: stay through the first full cycle
Deployment rolls the pilot out in waves and stays until the organisation has been through one full operating cycle: a month-end close, a reporting quarter, a hiring round, whichever the change touches. The first cycle is where the surprises appear, such as the report that depends on data nobody collects, or the approval that stalls when one person travels.
Measures are agreed during Design, not invented at go-live, and they use numbers the organisation already collects wherever possible. A change that needs a new data source to prove it worked will rarely be measured.
The handover
Handover is a short document with three items: the person who owns each component, the date of the first review, and a stop rule that says what result would lead the organisation to reverse or rework the change. Clients find the stop rule unusual. It stops a change from becoming permanent simply because nobody is responsible for questioning it.
Where the framework bends
The phases are a sequence for planning and a loop in practice. Development regularly reveals something Diagnosis missed, and the right response is to go back, not to press on.
- It front-loads effort. Diagnosis takes longer than clients expect, and some would rather begin designing in the first week. For small organisations we compress the four phases into weeks and drop the formal decision paper, but we keep the exit tests.
- It depends on a committed sponsor. Without one person with authority who attends the reviews, the tests cannot be applied and the work drifts. We treat the absence of a sponsor as a finding of Diagnosis.
- It costs more than a report. Staying through the first cycle is time the client pays for. The argument for it is that a report nobody adopts costs the same and delivers less.
- It does not suit every problem. A one-off technical question, such as a valuation, does not need four phases.
Five questions to ask any advisory firm, including us
If you are commissioning outside support, these questions separate work built to be adopted from work built to be delivered.
- Who on our side will run this after you leave, and when do we meet them?
- Which parts will use tools we already have?
- What will you ask us to stop doing?
- How will we know it is working in ninety days, using numbers we already collect?
- What happens if your diagnosis says we should not go ahead?
The answers tell you more about an advisory firm than a credentials slide does. If you would like to test them against ours, we are glad to talk through how the four phases would apply to a problem you are working on.
Bring us a problem, and we will show you how the four phases would run.
A conversation is usually enough to tell whether the framework fits. If it does not, we will say so.
Book a Consultation