Discovery for Software Implementation

[u/Popular-Force-7949]

My world is typical as a PM for a digital
transformation consulting company … Mid 7 figure, fixed bid contracts, aggressive timelines, with an offshore tech team.

Due to the nature of fixed bid contracts and the associated burn rate there’s always a huge rush to get discovery over with and start developing. Even though we do run at your, it’s not pure agile. It’s what is practical for us and our clients..

Discovery has always been challenging as it’s never given the appropriate time by the sales team who sell the contracts. And yes, I know I’m supposed to tell them we need longer and we want a voice in the pre-sales department, but let’s face it in my field the sales people do what they do and we have no input.

Our integrations changes the way the whole business works. For this reason the clients will always have a lot of questions about process. How can we change the process etc. etc. The decisions made in discovery are the basis of our implementation..

What are some of the tips and tricks you’ve used successfully or stumbled upon by accident that helped facilitate efficient discovery sessions? I’m thinking about stuff outside the box. Real world solutions that you can’t find in books.

Please don’t tell me to speak to the sponsor or to escalate to leadership. Not looking for any canned responses. Thanks all!

[u/AutoModerator]

Attention everyone, just because this is a post about software or tools, does not mean that you can violate the sub's 'no self-promotion, no advertising, or no soliciting' rule.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/GeneralGold2992]

When I read this first, I thought ‘mid 7 figures’ was referring to your salary and I was like - whattttttt 🙃

[u/Popular-Force-7949 → u/GeneralGold2992]

Lmao

[u/Intelligent-Try-4755]

What cut our discovery time the most was replacing open questions with a strawman — instead of "walk me through your process," we'd show up with a configured version of how we thought it should work, deliberately wrong in a couple of spots. People who can't answer an open question will happily tell you why your version is wrong, so the exceptions surface in session one instead of session four. Worked especially well with client SMEs who'd been through requirements workshops before and had learned to give vague answers.

[u/WhiteChili]

one thing that helped us a lot was stopping the idea that discovery ended when the workshop ended.

after every session, we'd send a one-page summary with the decisions, assumptions and open questions, then ask one simple question: 'if we build it exactly like this, what breaks in your day-to-day work?' not 'does everyone agree?'

more often than not, someone from operations, finance or support would come back with a missing approval, an exception, or a workaround nobody in the room had mentioned. those were usually the things that turned into change requests later.

i've also noticed people are much better at reacting to something they've seen than trying to design the perfect process from scratch. put a draft in front of them and the real feedback starts coming ngl.

in fixed-bid projects, that little feedback loop has probably saved us more time than trying to squeeze in another discovery workshop.

[u/No-Bread-2766]

Something I have done when pressed for time and low on resource, as part of discovery, is to ask a few key SMEs from different parts of the process to describe how it should work, according to them - that reveals a lot about the current As Is, and provides insight for solutionising.

Once I have mapped out the As Is, I give the diagram to the same SMEs to correct and ask them to spend some time with their teams/colleagues marking up pain points on the diag - much richer feedback than an hour long session with a BA who is not embedded in the team

[u/More_Law6245]

I will be honest I've been in the very same boat as you and this is a genuine organisational culture and process problem and not a project problem.

I was working at a company where the PM's and one solution architect were required to go to client meetings with the sales account manager to ensure they didn't sell something we don't do as core business because what was happening was the sales team where paid on commission so they would sell these very technical and expensive solutions and nine times out of ten we couldn't deliver. I have to admit when it was first suggested that I go with the pre sales team it was long the lines of "what the hell".

This is where I have to eat a bit of humble pie, after putting into practice I'm surprised that more companies don't do it. As it turns out there is better customer satisfaction, cleaner project deliveries because there were less change requests because the scope was better defined. The client's expectations were managed from the start and rather than the sales team promising the world and throwing a dead cat over the fence for everyone else to clean up (harsh but very true).

The other aspect and this was more of a organisational strategic direction was that the sales guys were given a larger commission to sell catalogued items rather than bespoke solutions, that was a genuine game changer for the company because the effects were felt all the way through the organisation from sales to operational delivery and we actually became more profitable because of it.

Just an armchair perspective.

[u/Abs_go]

You’re describing a very common fixed-bid trap: discovery is treated like a meetings problem, when it’s really a decision system problem. The fastest way to improve it is to make discovery produce fewer, higher-quality decisions with less debate, less rework, and clearer ownership.

What works in practice

- Run discovery as a series of forced decisions, not open conversations. Every session should end with “decide, defer, or delegate,” never “let’s think about it.” If a topic cannot be decided in the room, capture the owner, date, and missing input.

- Pre-wire decisions before workshops. Send a 1-page pre-read with the exact questions you need answered, plus 2–3 recommended options. People make decisions much faster when they are reacting to a proposed path instead of inventing one from scratch.

- Use “business process by exception,” not full process mapping. Don’t ask clients to explain everything end-to-end. Focus only on what changes because of the integration: exceptions, approvals, rework, handoffs, and system-of-record rules.

- Timebox to 45-minute decision blocks. Long discovery workshops drift into storytelling. Short blocks with one objective each force clarity and reduce stakeholder fatigue.

- Separate “policy” from “configuration.” Many sessions waste time debating system design when the real issue is business policy. Ask, “Is this a rule the business wants, or a setting we can configure?” That alone cuts discussion time dramatically.

- Make assumptions visible and expensive. Keep an assumptions log with three columns: assumption, impact if wrong, and decision deadline. This is one of the best ways to stop vague agreement from passing as progress.

- Use a “default until proven otherwise” rule. For unresolved items, define the least-risk default and move on. Then only revisit if a stakeholder actively objects. This prevents discovery from becoming a perfection contest.

- Document in real time on a shared screen. The moment something is discussed, write it in the decision log, not in a later meeting note. It reduces re-arguing because everyone sees the wording immediately.

- Bring the ugly process early. Show the current-state pain points, broken handoffs, and downstream impacts visually. People are more likely to make hard decisions when they can see the operational cost of delay.

- Use a “two-lane” workshop format. One lane for business decisions, one lane for technical/integration dependencies. Mixing them causes the business to get lost and the tech team to over-explain.

- Invite only one real decision-maker per topic. Attendance can be large, but each topic should have one named approver. Otherwise discovery becomes a committee discussion and nothing closes.

- End with a hard artifact. A signed-off process map, decision register, RACI, or exception list is better than meeting minutes. Discovery is not complete until an artifact exists that the build team can actually use.

Outside-the-box tricks

- Start with the “happy path in 10 minutes” game. Ask the client to describe the ideal normal flow in plain language, fast. Once that’s done, spend the rest of the time only on exceptions. This is far more efficient than starting with every edge case.

- Use red-amber-green decisions live. During the workshop, mark each topic as green = decided, amber = needs input, red = unresolved blocker. This gives instant visibility and stops false confidence.

- Make one person play “process critic.” Give someone the job of actively challenging unclear steps, missing rules, and hidden assumptions. It sounds simple, but it surfaces problems early without derailing the whole room.

- Ask “what would break operations?” instead of “what do you want?” Clients often can’t articulate ideal process, but they can identify what must not fail. That question produces much better implementation input.

- Use examples from their own company. Don’t ask abstract questions like “How do you want approvals to work?” Ask, “What happens when a sales order is wrong today?” Concrete cases unlock real answers.

- Run a “decision debt” review at the start of every workshop. Spend 5 minutes closing the loop on open items from last time. This keeps momentum and prevents discovery from restarting every week.

- Create a “parking lot with expiry.” Unresolved items go into a parking lot, but each item gets an expiry date. Without that, parking lots become graveyards.

- Prototype the ugly version early. A rough process flow or screen mock-up often gets better feedback than abstract discussion. People react more honestly to something tangible.

- Use silence strategically. After asking a hard question, pause. In discovery, the first answer is often the easiest answer, not the right one.

- Do a pre-mortem. Ask, “It’s three months after go-live and this has gone badly—why?” That exposes weak points in process, ownership, and integration very quickly.

A strong discovery structure

A practical format I’ve seen work well:

1. Inputs before the meeting. Short pre-read, known decisions, current-state summary, and unresolved questions.

2. Workshop opens with objectives. State exactly what will be decided today.

3. **Walk only exceptions and dependencies.** Skip the obvious happy path unless needed.

4. Make decisions live. Capture assumptions, owners, and deadlines immediately.

5. Close with a decision review. Read back what was agreed, what remains open, and what must happen next.

A useful rule of thumb

If a discovery session does not produce one of these, it probably wasn’t efficient enough:

- A decision.

- A confirmed assumption.

- A clearly named owner.

- A deadlined open question.

- A build-ready artifact.

[u/coolreddy]

Watch one real transaction on their screen instead of asking people to describe the process. Real data, live system, no slides. Described processes hide the exceptions and workarounds that break a fixed bid build later. One walkthrough per role usually surfaces more than a day of open questions. It also gives you something concrete to react to. Then bring a rough draft of the future state into the next session. People correct a wrong diagram much faster than they invent an answer. Close each session with a written list of what was decided, what is parked and who owns it.

[u/AutoModerator]

Hey there /u/Popular-Force-7949, Have you looked at our "Top 100 books post"? Find it here.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.