Managing Stakeholder Engagement in Execution

The Stakeholder Who Went Around You

A client contacts one of your team members directly and asks them to "do the same thing you did for the other part of the project." The team member, wanting to be helpful, starts the work. Two weeks later, you discover the client was referring to something already handled from a different angle by a different team. The work is duplicated. The budget has absorbed the cost. The client did not document the request, and tracing responsibility is now a delicate conversation. This is not an unusual story. It is what happens when stakeholder engagement is not actively managed during execution, and many projects that skip it experience some version of it.

The PM as Project Butler

A useful frame for the PM's role in stakeholder engagement is the butler. The butler manages access to the house. They know who is expected, what their needs are, and how to handle each interaction at the door, whether it is a routine visit or an unexpected arrival. They do not control the guests; they manage the relationship between the guests and the household. The PM's role with stakeholders works the same way. You do not control what stakeholders want. You manage how their needs are surfaced, who addresses them, and how that work flows into the project. When that flow is managed, the opening scenario does not happen. When it is not, it happens repeatedly in different forms until someone puts a process around it.

Not Just the Sponsor

The most visible stakeholder on any project is the sponsor. They have the highest authority, the most obvious influence on project decisions, and the clearest stake in the outcome. It is easy to treat stakeholder management as sponsor management and consider the job done. It is not. Your team members have a stake in this project. So do the vendors whose delivery directly affects the schedule, the department heads whose operations will change when the deliverable lands, and the end users who will live with the outcome every day. Each of these relationships has a current level of engagement and a desired level. Your job is to move each stakeholder toward the engagement level the project actually needs from them, not only manage the one who signs the authorization.

Rules of Engagement

On projects with complex stakeholder environments (multiple departments, external partners, or politically sensitive relationships), a rules of engagement agreement clarifies how stakeholder interactions work in practice. Who can commit the project to taking action? How are requests from external stakeholders routed when they arrive directly to a team member? What should a team member do when a stakeholder approaches them with a requirement or a request they have not seen before? This does not need to be a formal policy document. It can be a short practical agreement made early in the project, ideally before the interactions that require it start happening. The goal is to prevent problems at the front end rather than manage the fallout at the back end.

Two Stakeholders in the Same Problem

When stakeholder engagement breaks down, the PM often has two relationships to manage at once. In the scenario above, Oliver made a request that caused a problem — but not through malice, through a gap in how the project managed its interactions. Yasmin acted on good intentions without the framework to know that what felt like a working session to her looked like a commitment meeting to him. Each needs to be handled separately, and each needs to feel heard. Oliver needs clarity on how requests are routed and a credible channel for his input. Yasmin needs to understand the expectation going forward without feeling blamed for doing what seemed helpful in the moment. The PM who handles both well comes out the other side with stronger relationships on both ends. The PM who handles it as a single problem, addressed in one group conversation, tends to lose the trust of at least one of them.

Input Is Not Authorization

One distinction worth naming explicitly: stakeholders can provide input without having authority to approve scope, cost, schedule, or contract changes. When input would change a baseline or an existing commitment, it becomes a change request, not an informal agreement. The Oliver example above lives or dies on that line. Gathering input and authorizing scope are different things, and keeping that distinction visible in every relevant conversation is one of the PM's standing responsibilities.

Engagement Is Ongoing, Not a Status

The stakeholder engagement plan built during planning established desired engagement levels for each group. Managing stakeholder engagement in execution is the work of actually moving people toward those levels and keeping them there. The engagement matrix is not a one-time snapshot. It is a reference that should be revisited regularly, because people's engagement levels change as the project progresses, as the deliverable becomes more real, and as the impact on their work becomes clearer. A stakeholder who was supportive in month one can become resistant by month three if they feel their input has stopped mattering. The PM who checks in regularly catches that shift early enough to address it. The one who does not tends to discover it when the stakeholder raises a concern in a steering committee meeting that could have been resolved in a ten-minute conversation six weeks earlier.

Organizational Change Management: What Survives After the Project Closes

Most project failure analysis focuses on what went wrong with the project itself: budget overruns, scope creep, schedule slippage, stakeholder conflict. But there is a quieter failure mode that rarely appears in post-mortems — the project that delivered exactly what was specified, on time and within budget, and that nobody actually used. The ERP system that went live and was abandoned six months later. The process redesign everyone worked around. The office relocation that technically happened but left half the workforce demoralized for the next year. These projects succeeded by every project performance metric and failed at the one thing that justified the investment: they did not produce a change the organization actually absorbed and sustained.

Organizational change management, commonly abbreviated OCM, is the discipline that addresses that gap. It is not the same as integrated change control, which governs how changes to the project plan are authorized. OCM governs something different: how the people, systems, and culture within the organization transition from their current state to the future state the project is building toward. Change control asks whether the WBS should be updated. OCM asks whether the people who will live with the result are ready, willing, and able to operate in the world the project creates. Both matter. Neither replaces the other.

The most widely used OCM framework is ADKAR, which describes five conditions that must be present in an individual before they will successfully sustain an organizational change. Awareness of why the change is happening. Desire to support it rather than wait for it to fail. Knowledge of how to behave differently in the new state. Ability to perform the new behaviors consistently under real working conditions, not just in a training room. Reinforcement: mechanisms that sustain the change over time rather than allowing old habits to reassert themselves. A project that delivers a new system without addressing all five conditions in the people who must use it has not changed how the organization works. It has added a new system to an unchanged organization, which is a common outcome and a poor return on investment.

The PM's role in OCM sits at the intersection of delivery and sponsorship. The PM raises the flag when the project's deliverable will require a level of organizational transition that the existing stakeholder engagement plan does not adequately address. The PM works with the sponsor to identify who in the organization holds OCM accountability and ensures the project timeline includes transition activities: training programs, communication campaigns, pilot groups, feedback loops, and post-implementation support. These take time. If they are not in the schedule, they will be compressed at the end or skipped entirely. The sponsor owns the organizational change. The PM makes sure it is planned for.

Resistance to change is a normal organizational response, not a sign that something has gone wrong. People resist for predictable reasons: they value something in the current state that the change threatens, they do not trust that the new state will work as promised, they were not included in the decision to change, or they lack confidence that they can perform in the new environment. None of these is irrational. The PM who encounters resistance during execution and responds by increasing communication volume is not addressing the resistance. They are talking over it. The more useful move is to understand what is actually driving it, determine what concerns can be addressed, and surface the organizational dimension to the sponsor. Resistance that is engaged honestly and adjusted to tends to dissipate. Resistance that is managed through announcements tends to go underground and reappear during the go-live as the organization reverts to the behaviors it knows.

The measure of successful OCM is an organization that operates in the new state without the project team still in the room. Users who understand the system and use it correctly. Managers who reinforce the new behaviors rather than quietly tolerating workarounds. Metrics that reflect the changed operation. A project that delivers its go-live date but requires ongoing PM involvement to keep the new state functioning has transferred the deliverable. It has not transferred ownership of the change. OCM planning, built into the project from initiation rather than tacked on in the final sprint, is what produces the second outcome rather than the first.

What's Next

With the executing section complete, the next chapter opens the monitoring and controlling phase — the PM's shift from driving the work forward to ensuring it is being done right, catching deviations early, and maintaining the baselines the project committed to at the end of planning.

Reflect

• On your current or most recent project, did you have a formal or informal rules of engagement agreement? If not, what was the first situation that made you wish you had one?
• Which stakeholders on your project are you most confident are at the right engagement level? Which ones are you least sure about, and what would a direct check-in reveal?
• Think of a situation where a team member responded to a stakeholder request directly, outside the project's formal channels. How did it surface? How was it resolved?
• When did you last revisit your stakeholder engagement matrix to check whether current engagement levels still match what the project needs? What might have shifted since you last looked?