Connecting People, Not Just Systems: Stakeholder Management in Integration

Stakeholder management covers two things:

Together, they help teams make better decisions, reduce risk and keep the project focused on its real objective.

Integration work rarely stays within one domain. An API, an event flow, a file transfer or a platform choice touches business processes, security policies, operational support, data ownership and sometimes external partners. One interface can involve several teams, responsibilities and priorities at once.

And the landscape is shifting. In an Autonomous Business, integrations no longer just move data between systems. They feed AI agents, trigger automated decisions and connect flows that adapt at runtime. The more autonomous the system, the more it matters that the people around it agree on what “good” looks like. Technology is rarely the limiting factor. Alignment is.

What we see in many organisations when the right stakeholders are involved early:

“We built an endpoint” is output. “The process runs faster and more reliably” is an outcome. A CEO, an architect, an operations engineer and a key user each look through a different lens. Stakeholder management brings those perspectives together to make better decisions.

Below are the ingredients for a more practical approach.

Good questions help you understand what matters to someone before you propose a solution. But wording and timing matter. The same question can open up one conversation and put someone on the defensive in another.

“You do understand that, right?” is likely to make someone feel judged. “Which part needs more explanation?” gives them room to speak.

Ask to understand their point of view, not to prove your own.

Socratic questions help you explore someone’s thinking. You put your own assumptions aside and stay curious about what they mean.

In an integration project, that might sound like:

• “What makes this deadline important?”
• “What happens if we deliver later?”
• “What does ‘good’ look like for this application?”
• “How does this problem affect the process today?”

The five whys can help uncover the need behind a request. “We want a Power BI dashboard” might mean “We need to understand what slows down our shipments.”

Keep it conversational. Five blunt “whys” can feel like an interrogation. Vary your questions, summarise what you hear and check that you’ve understood.

It’s easy to start preparing your answer while someone is still talking. Two rules of thumb help:

• LSD: listen, summarise, dig deeper (in Dutch: luisteren, samenvatten, doorvragen).
• NIVEA: never fill in for someone else (niet invullen voor een ander).

Always test your assumptions. Say “I hear that stability matters more than speed, is that right?” rather than “So you mainly want to avoid risk.“

We’ve all been in meetings where everyone talks and nothing moves forward. Alongside an agenda, you need room to question ideas, share concerns and make decisions.

Pay attention to repeated “yes, but…” responses, vague answers or topics that keep coming back. They can point to a concern nobody has voiced, an unclear responsibility or a decision still waiting to be made.

Pause and ask: “What do we still need to resolve before we can move forward?”

Start with the client and the project manager, then look further. Who makes the decisions? Who influences them? An architect, key user or operations lead may have a big say in whether a solution gets accepted, even without formal authority.

Consider:

• Business owners and teams such as operations, sales and marketing.
• End users and key users.
• Development, platform, security, infrastructure and support teams.
• Architecture, compliance and legal.
• Suppliers, partners and consultants.
• Management and project sponsors.

A power-interest matrix helps you tailor your involvement to each stakeholder’s influence and interest in the project.

This helps you give people the attention they need, including those who rarely speak up.

“This only takes two weeks, right?” Small assumptions can turn into big frustrations. Be clear about scope, timing, risks and dependencies. When something changes, say so early.

A useful update sounds like this: “I’ve made less progress than planned because X took priority. I’ll pick this up again on Thursday and update you on Friday. If it needs to happen sooner, let’s agree on what can wait.”

Your capacity belongs in that conversation too. Asking “If I take this on, what moves down the list?” makes the trade-offs clear and helps everyone agree on what’s realistic.

A CEO needs to know what a delay means for the business. A developer needs enough detail to act. Security needs time to assess risks before go-live gets close.

Tailor your message to what each audience needs:

Before sending an update, ask: what does this person need to understand or do next?

Security needs stronger controls. Users want fewer steps. The business wants to launch sooner. These tensions are familiar in integration projects.

As an architect or consultant, help people understand the options. Explain the benefits, risks and consequences of each scenario so decision-makers know what they’re choosing.

“Why did we choose this again?”

A clear decision log saves everyone from reopening the same discussion. Record the context, the options considered, the decision, the reasoning, the owner and when to review it. Include why alternatives were dropped. Future colleagues will thank you.

“This is not what we meant” is painful feedback at the end of a project. Short demos, early architecture checks and feedback sessions help catch misunderstandings while there’s still time to act.

Before presenting to an Architecture Review Board, for example, discuss the proposal with the key architecture stakeholders. Give them time to raise concerns and help you prepare for the formal review.

Keep your promises. Flag problems early. Be clear about what you know and what still needs checking.

People need to trust that you’ll follow through and speak up when something goes wrong. That comes from being reliable, honest and consistent throughout the project.

Focus on what could cause confusion or risk down the road:

• Decisions and the reasoning behind them.
• Key assumptions.
• Scope boundaries.
• Clear requirements.
• Risks, owners and agreed actions.

Keep it short, current and easy to find. The next person should be able to understand what was agreed and pick up the work.

Understand why the project exists, which KPIs matter and what success looks like for the people involved.

Remember the dashboard request above. Knowing the goal behind it helps you question the proposed solution and make technical choices that improve the process.

• Date: when was the decision taken?
• Context: which problem or choice was on the table?
• Options: which alternatives were considered?
• Decision: what was chosen?
• Not chosen: what was deliberately not chosen, and why?
• Rationale: which pros, cons and risks were decisive?
• Owner: who guards the execution?
• Review moment: when do we revisit this if needed?

When responsibilities get blurry, a RACI helps: who does the work (Responsible), who answers for the result (Accountable), whose input is needed (Consulted) and who needs updates (Informed)?

Agreeing on those roles together prevents confusion later.