Analysts love to say stakeholders are “resistant to change.” But all too often, I think that’s the wrong assessment. Similarly, people don’t resist process documentation because they dislike flowcharts, they’re resisting because they know what comes after the flowcharts. It may be a new ERP or an automation project. Ultimately, they see a consulting engagement that ends with fewer people doing the same amount of work.
The knowledge that never reaches the manual
If you’ve been on the receiving end of these, you may start seeing process meetings like job interviews where every answer might be used against you. For example, a finance director who’s been with the company for fifteen years, known for smoothly closing month-end runs because they know which reports are commonly wrong. They know about the one approval route that breaks whenever purchasing changes vendors. And they catch posting errors before anyone else because the totals “just don’t look right.” None of that knowledge lives in the accounting manual. They catch it because of experience and instinct.
What the stakeholder actually hears
Now the company announces a new ERP. The analysts say the software will automate reconciliations, standardize approvals, and eliminate manual work. The steering committee applauds but the finance director hears something different. They may hear, “The things that make you valuable are about to become features of the new ERP.” This is a hard message to ignore. So when the elicitation workshops begin they can go like:
“Walk us through your process.”
“It depends.”
“Can you be more specific?”
“There are a lot of exceptions.”
Ask about decisions, not tasks
Technically, those answers are true but they’re also a shield or deflection. I’ve seen analysts respond by asking the same question in different ways, hoping persistence will unlock the missing information, but this rarely works. People don’t become more transparent with repeated questions, they often become quieter. A better approach is to stop asking about specific tasks but instead ask about decisions and outcomes. Don’t ask, “What do you do after receiving the invoice?” Ask, “How do you know this invoice needs your attention instead of someone else’s?” This is a different type of question that appeals to judgment. It tells the stakeholder you’re interested in their thinking process, not just what they click on. This also shows respect and begins to build trust. Other good follow-up questions may be, “What was the last invoice that almost caused a problem, and what made it different?”, “What would a new controller miss if they followed the written procedure exactly?” These are actually stories, and people respond to stories better than numbered steps on a process map.
Let the silence do the work
Silence can help, too. Analysts often rush to fill empty space by asking a question, waiting two seconds, and then rescuing the stakeholder by asking another question. It’s okay to let the silence sit in the room for a moment. In my experience, I’ve seen it often enough where the stakeholder will start talking again, and they tend to open up a bit more at this point. This is when the real process starts to reveal itself.
Name the job impact instead of hiding it
Another potential mistake is to pretend that the project has no impact on people’s jobs. Everyone knows better and it doesn’t help to try and conceal this. If an ERP is expected to eliminate manual approvals, don’t act as though the workshops are purely academic. It’s important to acknowledge this, which builds trust because recognition matters. When someone explains a complex workaround they’ve maintained for years, respond with something like, “That’s exactly the kind of knowledge we can’t afford to lose.” This conveys that their experience has value. People’s body language can change as well. Just watch people’s posture when they feel heard. Shoulders relax and arms uncross. The conversation may shift and become more free-flowing. You may even learn about the documented process that hasn’t matched reality since the acquisition three years ago.
Trust comes before the process map
This doesn’t happen from being an expert BPMN modeler, but it happens because of the trust that you created before the process map was even started.
The part that people miss about process elicitation is that you’re not interviewing a workflow, you’re interviewing a person who’s trying to decide whether telling you everything makes them more valuable, or less.