Running SAP Discovery Workshops That Produce Decisions

Ask anyone who has sat through an SAP discovery workshop what came out of it, and you get a shrug more often than a straight answer. Everyone remembers the sticky notes. Nobody remembers what got agreed.

That is not a facilitation problem. It is a structure problem. Most discovery workshops are built to cover topics, not to produce decisions — and those are two very different things.

I have run discovery workshops that ended with a signed decision log before anyone left the room. I have also sat through ones that produced forty flip-chart pages and three weeks of follow-up emails trying to work out what was actually agreed. The difference was never the people in the room. It was the structure around them.

This post covers that structure — the pre-work, the agenda, the room, and the decision log — so your next discovery workshop produces something a steering committee can act on, not a deck nobody rereads.

🔗 Before this post — This assumes you already know where discovery sits inside an SAP project. SAP Activate — The Methodology Behind Every S/4HANA Project covers the wider methodology, and What Does an SAP Solution Architect Actually Do? covers the role that usually owns this workshop.

Why discovery workshops fail before they start

Three things kill a discovery workshop before the first slide even loads. No decision owner is confirmed in the room. No pre-work has been sent to attendees. The agenda is organised around what to cover, not what to decide.

An agenda item that reads “Finance processes, 9:00 to 10:30” tells people what topic is coming. It does not tell them what needs to be agreed by 10:30. People turn up ready to discuss, not decide — and ninety minutes later, you have a good discussion and nothing signed off.

⚠️ Warning — The agenda predicts the outcome

If an agenda item is a noun — a topic — rewrite it as a question with a deadline. “Finance processes” becomes “Do we run tax determination on SAP standard or a custom BAdI — decision by 10:30.”

The second failure is quieter and more damaging. Nobody has confirmed who can actually say yes. Every project has someone who can approve a scope decision, and people who can only recommend one. If that person is not in the room — or is not named on the agenda as the one who decides — everything discussed that day is provisional. Provisional decisions rarely survive contact with the next steering committee, where someone who was not in the room reopens the whole question.

I have watched a two-day discovery workshop unravel three weeks later because the finance director who could approve the chart of accounts design sent a controller instead. The controller nodded along all day. The finance director disagreed with half of it at the steering committee — and the team lost two weeks re-running conversations that had felt finished.

The pre-work that determines the outcome

The workshop itself is the easy part. The pre-work is the other ninety per cent of the outcome, and it is the part most projects skip because it does not show up on a project plan as billable workshop time.

Three things need to happen before anyone walks into the room.

Pre-work step	What it produces	Owner
Pre-read circulated	Shared understanding of current state and session scope before the room opens	Workshop lead / architect
Decision list drafted	A list phrased as decisions, not topics — forces a position before the room	Workshop lead
Decision owner confirmed	A named, accountable person committed to attend in person	Project manager

💡 Practical tip — Send decisions, not topics

Send the decision list at least five working days before the workshop, separately from the agenda. A list phrased as decisions — “Do we use SAP standard for tax determination, or a custom BAdI?”, “Do we run one company code or three?” — forces stakeholders to form a position before they walk in.

If a decision owner cannot attend and cannot send someone with real authority to decide, move the workshop. Running it anyway and hoping to get sign-off later almost never works. The moment has passed, and re-litigating a decision after the fact costs more time than the delay would have cost up front.

Stakeholder mapping is worth doing properly here, not as a box-ticking exercise. For each decision on the list, write down who owns it, who needs to be consulted, and who just needs to be informed of the outcome. That single exercise usually halves the guest list for the actual workshop.

Structuring the room for decisions, not discussion

Rebuild the agenda around decisions, not topics. Every item should be phrased as the decision that needs to be made by the end of that slot, with the name of the person accountable for making it sitting right next to it on the agenda, not buried in a project charter nobody rereads.

Time-box every item, and defend the time-box out loud. The moment a topic runs long because someone wants to explore an edge case, name it and move it to the parking lot — a visible list, on the wall or in the shared document, of things raised but not resolved in this session. The parking lot is not where good ideas go to die. It is where scope creep goes so the workshop can keep moving toward the decisions it was actually convened to make.

Build in a buffer between sessions, not just between days. A workshop with back-to-back ninety-minute blocks and no breathing room looks efficient on the agenda and falls apart by lunchtime, because nobody has had time to actually process the last decision before the next one starts.

Who needs to be in the room, and who does not

Every extra chair in a discovery workshop slows the room down. More people in the room does not mean more decisions — it usually means more discussion per decision, because more people feel entitled to weigh in before anything gets signed off.

Role	What they contribute	Attends the full session?
Decision owner	Approves the outcome — one named person, not a committee	Yes
Subject matter expert	Informs the decision with process knowledge, does not own it	For their topic only
Observer / stakeholder rep	Needs visibility into the outcome, adds nothing to the decision	No — gets the decision log after

✅ Best practice — Cap the room

Cap the room at people who can either decide something or directly inform a decision. Anyone who only needs to know the outcome does not need a seat. A workshop with six focused people who can actually decide outperforms one with sixteen people who can mostly only comment.

Capturing decisions so they survive the workshop

Minutes are a record of what was said. A decision log is a record of what was agreed. Only one of those two documents survives a project audit eighteen months later, and it is not the minutes.

A decision log entry needs four things and nothing more: the decision itself in a single sentence, who made it, the date it was made, and what happens if it needs to be revisited later — who has the authority to reopen it, and under what condition.

📌 Key takeaway

If the decision cannot be written in one sentence, it usually has not actually been made yet. It is still a discussion wearing a decision’s clothes.

Get sign-off in the room, not by email afterward. Read every entry back before people leave and get a visible nod from the decision owner, not an “I will check and get back to you.” Email sign-off after the fact is where clear decisions quietly turn back into open questions, because the person reads it three days later with less context and more doubt than they had in the room.

Store the decision log somewhere every workstream can reach it, and reference it by number in later design documents and blueprints. A decision that only exists in one person’s meeting notes might as well not exist six months into the project.

Common facilitation mistakes that quietly kill outcomes

Even with the right structure, a handful of habits undo it in the room.

Mistake	What it does	Fix
Loudest voice steers the room	Conversation drifts away from the decision owner’s actual position	Facilitator redirects explicitly back to the decision owner
Parking lot exists but is never used	Every tangent gets discussed in full instead of parked	Name the parking lot out loud the moment a topic drifts
Decision owner never explicitly asked	Workshop ends with a lean-toward, not a decision anyone can act on	Close every item with a direct question to the owner
Agenda is overpacked	Last items get rushed through in the final twenty minutes	Cut scope before the workshop, not during it

⚠️ Warning — Multi-day fatigue is real

A room that is sharp at 9 a.m. on day one is making noticeably worse decisions by 4 p.m. on day two. Shorter, well time-boxed sessions of four to five hours, spread across two or three days with real breaks, consistently produce better decisions than one exhausting full day crammed with everything on the agenda.

At a glance — running a discovery workshop that works

Concept	One-line summary
Decision-first agenda	Every item is phrased as a question with a deadline, not a topic with a time slot
Decision owner	One named person who can say yes — not a delegate, not a committee
Pre-read	Shared current-state understanding sent before the room opens
Decision list	Circulated at least five working days ahead, phrased as decisions to force a position
Parking lot	A visible list for tangents raised but not resolved in the session
Decision log	Four fields only — decision, owner, date, revisit condition — signed off in the room
Room size	Capped at people who can decide or directly inform a decision
Multi-day format	Four to five hour sessions across two to three days beat one long exhausting day

What to take away

A discovery workshop is not a meeting. It is a decision-making instrument, and like any instrument, it only works if you build it to do the one job you actually need from it.

The pre-work decides more of the outcome than the room does. Get the decision list out early, confirm the real decision owner will attend in person, and build the agenda around questions with deadlines instead of topics with time slots. Do that consistently, and the room mostly runs itself.

The teams that get discovery right are not the ones with the best facilitators in the room. They are the ones who stopped confusing a good conversation with a good decision.

🔗 Related posts on this site

SAP Activate — The Methodology Behind Every S/4HANA Project — where the discovery workshop sits inside the wider Activate phases.

What Does an SAP Solution Architect Actually Do? — the role that usually owns and facilitates this workshop.

SAP S/4HANA Migration: Greenfield, Brownfield, Bluefield — the migration path decision that discovery workshops often exist to settle.

S/4HANA Architecture Decisions Every Solution Architect Needs — the kind of architecture decisions a well-run discovery workshop should surface early.

SAP Blueprinting — Fit-Gap to Design Freeze — the next post in this series, for when a decision from this workshop needs to survive fit-gap and reach a design freeze that holds.

SAP Fit-Gap Analysis — When Business, IT and Finance Disagree — for when a decision from this workshop resurfaces as a disagreement between competing stakeholders.

Published on rakeshnarayan.com — Articles

URL: https://rakeshnarayan.com/articles/running-sap-discovery-workshops-that-produce-decisions/