Design and the fit-gap decision

Station four secured people’s time. This station is about how that time is spent.

The commonest mistake in a design workshop is one question: “what do you want?”

It invites the user to describe their old system in new words, and turns the workshop into a wish list. The right question is: “show me how you do it today, and why that way?” — which produces a real process with its constraints, most of which disappeared with the old system and nobody noticed.

The shape of the workshop

Part	Share	Output
The current process	30%	A map with its steps and documents, and the reason for each step
The demonstration	40%	The screen is actually opened, not slides
Gaps and decisions	30%	A classified gap list, and a decision record

The second part is non-negotiable. A design workshop with no screen open is a meeting about an imaginary system. A user who has not seen the screen agrees to a description, and then rejects the screen at UAT, when changing it costs ten times as much.

The why rule: every step in the current process is asked for its reason. In every workshop, a third of the steps answer “that’s how the system was” — which is not a requirement, but a constraint that dies with the system.

The gap ladder

Every gap is classified on four rungs, and no rung is climbed before the ones below are exhausted.

Rung	What it means	Its permanent cost
1. Change the process	Standard is enough, and the process changes	Zero
2. Configuration	Solved by settings inside the product	Near zero
3. Extension inside the framework	A supported extension that does not touch the product	Tested at every upgrade
4. Customisation or integration	Code outside the framework	Tested and maintained forever

Rung one is the hardest politically and the cheapest financially. The resistance is human rather than technical: “this is how we have worked for twelve years”.

The question that opens the door: “what happens if we do it the standard way?”

If the answer is “a regulatory breach”, it is a real gap. If it is “it would take two extra clicks”, it is a preference. If it is “I don’t know”, it is a habit. Most customisation requests are habits.

The rule written into the workshop minutes: every climb of a rung needs a written reason and the sponsor’s approval. Requiring the signature alone kills half the requests.

The walkthrough on the system

Instead of a hundred pages of design signed by somebody who did not read them, show the customer the system running on their own data.

It is a session where a full cycle is built in a configured environment on a sample of the customer’s real data: an item they know, a supplier they know, a price they know. Then the cycle is run end to end in front of them.

Three things happen there that happen in no document.

• They see the screen, so they understand what they agreed to.
• They discover a requirement they never mentioned, because it did not occur to them until they saw it.
• They approve the design with confidence, and UAT rejection falls sharply.

The rule: no design is approved that has not been seen on a screen.

What comes out of the design phase

Design is not meetings. It is four documents, and what does not come out of them did not happen.

Document	What is in it	Who approves it
The target process map	Steps, documents and roles, per cycle	The key user
The classified gap list	Every gap, its rung and its reason	Both project managers
The accounting decisions book	Which account moves on which event	The finance director
The agreed report list	By name and by count	The sponsor

The third is the one that gets forgotten and is paid for at the first close. A project that documents screens but not the journal each document produces delivers a working system and financial statements nobody believes.

The fourth is the baseline that the whole of station three rests on. Without a number in it, there is no change control.

The rule: do not start real configuration before all four are approved. Starting earlier means building on a design that shifts underneath you, doing the work twice and calling it “being flexible”.

Approving the design

Approval is a decision rather than a procedure, and three conditions make it real.

• It is approved process by process, rather than as one document at the end of a phase.
• It is signed by whoever will use it, rather than by whoever manages them.
• It is accompanied by what was not accepted — the gaps classified “change the process”, written out explicitly. A customer who signs a design without seeing what was refused meets it at training.

What you actually do in this station

• Write each workshop’s agenda to the three shares, and actually open the screen in it.
• Ask for the reason behind every step, and mark every step whose reason was the old system.
• Classify every gap on the ladder in the minutes, with a written reason for any climb.
• Run a walkthrough per cycle on real customer data.
• Take approval process by process from whoever will use it, attached to the list of what was not accepted.

The three commonest mistakes

One: a workshop with no screen. A description is agreed and the reality is rejected at UAT.

Two: classifying straight onto rung four. A permanent customisation is bought for a temporary habit.

Three: approval signed by a manager who did not attend. The signature exists and the acceptance does not, and the difference shows after go-live.

The acceptance test for this station

1. Show a workshop agenda with the three shares and each part’s output.
2. Name three steps in the current process whose reason was the old system.
3. Show ten gaps classified on the ladder with their reasons.
4. Describe a walkthrough you ran and what it surfaced that the document did not.
5. Show a design approval signed by a user, with the list of what was not accepted.

What comes next

The design is approved. The next station is the riskiest phase of the project and the one that consumes the contingency: data migration.