Do your stakeholders know why your project exists?


Brad Egeland

June 29, 2016

Sometimes languishing in relative obscurity is a good thing. Traveling under the radar. Everyone oblivious to what’s goof on and why you’re doing what you’re doing. But on our own projects, with the individuals we expect to have some sort of vested interest in the outcome of our project…it usually isn’t going to be a good thing to have some or many of them not fully understand the nature of our project.

We need our stakeholders to be aware. After all, we are likely going to be assigning some project tasks to them. We are likely going to be holding them accountable for some task progress reporting and status and it will be in their best interest – and ours – for them to actually know as much as is humanly possible and logically practical from the outset of the project. If we don’t help ensure that we can never expect good performance from these individuals that lined up well with the mission and vision for the project.

How do we go about ensuring that our project stakeholders know why the project exists? How do we ensure they know what we are expected to accomplish on the project? How do we ensure that they understand the issues, the risks, the key assumptions and the direction we are going throughout the engagement? There’s no sure-fire way to ensure this, and you can only shout it from the rooftops so much if no one is listening, but here are four ways that I work – on my projects – to ensure that my stakeholders are on the same page as me from the outset of the project and from that point on…

Lay it out at kickoff. The kickoff session is the right place to get all project information that you have available to that point out in the open, agreed upon, and modified, if necessary. In short, it’s the starting point for getting everyone on the same page and with the same project understanding and the same project expectations…at that point, before moving forward. It usually includes an overview of the statement of work (SOW) and a discussion of goals, mission, assumptions, schedule and methodology, at the very least. Use this meeting to let your stakeholders know why you are all doing what you’re doing.

Distribute the statement of work. Not all will read this and of those that do, not all will fully understand it. But it will help get everyone on the same page and provide a nice go-to reference to anyone who needs a refresher mid-project. Plus, you can actually say…”duh, go back and read the statement of work” and you know that they actually do have it to go back to and refresh their memory.

Pound it home periodically in meetings. Openly discussing the project goals during meetings throughout the project engagement helps to drive it home further to those who already know, and get those who may lack some understanding a chance to embrace it…and ask questions, if necessary. You don’t have to recap it at every meeting, but you’re the leader…so bring it up however often you need to and want to.

Summarize it on the project status report. It never hurt to put a mission statement and some summary project goals information on every status report you distribute. And since this can and should go out to all stakeholders, everyone will have it at all times. It may not be great detail, but it will at least be a high-level view.

Summary / call for input

We should not always assume that everyone knows why we are doing what we are doing…even if they are part of the team doing it. Some of those key stakeholders may be a bit lost and they eventually reach a point of being too embarrassed to raise their hand and ask “what the heck are we doing?” Spare them the humiliation and just do your best to give them ways to be informed and find ways to drive home the concept on a regular basis.

How about our readers? Have you ever run into situations where mid-project you had some key stakeholders who should know about your project and what the purpose was but didn’t? What steps did you take – and do you take – to make sure you’re all on the same page?

This article was written by Brad Egeland from CIO and was legally licensed through the NewsCred publisher network.

Great ! Thanks for your subscription !

You will soon receive the first Content Loop Newsletter