Introduction
Few things derail a project faster than unclear stakeholder expectations.
Soon after I started Scissortail Creative Services, I learned a hard lesson about this topic that led me to create the tool I’m sharing with you today.
My team had been working with our client for months. As we were finishing up their second eLearning course, we received some harsh feedback. The client wasn’t happy. The course wasn’t the style he was expecting. And neither was the first one—but he chose not to speak up when we delivered that one.
Have you ever come to what you thought was the end of a project, only to have to start over? To put it bluntly, it sucks. Fortunately, there’s an easy way to prevent this situation.
One Document to Rule Them All
(I couldn’t resist a Lord of the Rings reference.)
Here’s my simple tip for preventing problems like the one my team encountered: set stakeholder expectations upfront.
I do this with a document that I review with stakeholders at the beginning of the project—one I’ll share at the end of this post.
Make sure everyone knows their roles and responsibilities, the development process, deliverables, time expectations, and how to work with you.
If I had done this with that project I mentioned, the executive who was the final approval authority would have known that we expected him to review interim deliverables, not wait until the end. That way, he would have seen our initial design ideas and could have shared his expectations with us before we had fully developed a course he didn’t like.
For what it’s worth, we thought we had this covered. The client assigned SMEs to review each course, and because they were considered the project owners, we assumed they had approval authority. But you know what they say about assuming. Clarifying who needs to review what, and when, would have saved a lot of headaches.
Without this step, projects start to drift. Review deadlines are missed because SMEs don’t set aside enough time from the beginning. Team members duplicate work—or assume someone else is handling it. In fact, a lot of people on all sides of the table tend to make assumptions that often turn out to be incorrect.
In my experience, a stakeholder expectations document prevents more problems than almost anything else.
How to Use a Stakeholder Expectations Document
I review the stakeholder expectations document at the project kickoff meeting, and I send a copy to every client team member who is identified as a stakeholder. In this context, a stakeholder is anyone who has decision-making authority, provides expertise, reviews deliverables, or otherwise influences the success of the project.
Reviewing the document together is important because I can clarify concepts and answer questions. Plus, we all know how easy it is to ignore an email.
Identifying the right stakeholders is also important. Ever since that project I mentioned, I always ask, “Who has decision-making power for this project?” I want to get them involved early.
While I’ll use learning experience design projects as the example throughout this article, the same approach works for almost any collaborative effort. Whenever multiple people are working together to produce something, setting stakeholder expectations early pays off throughout the life of the project.
Get Decision-Makers Involved Early
One common challenge is that executive leaders are busy people who don’t have time to review every deliverable, so they often want to wait until the end. From their perspective, waiting until the end probably seems like the most efficient way to provide input. But it simply doesn’t work if their expectations aren’t aligned with the rest of the team’s—the problem we ran into with the project I mentioned.
So, during the kickoff, I explain the importance of early stakeholder involvement—and what can happen without it. We request executive sign-off at the design or prototype stage and then again at the end. The early approval step confirms we’re heading in the right direction before significant development time has been invested. That way, neither the executive nor our team is surprised at the end.
What to Include in a Stakeholder Expectations Document
So, what goes into a stakeholder expectations document? The answer might be different for you than it is for me. I encourage you to think about the biggest challenges you’ve experienced in your project work. What expectations could you set from the beginning that could prevent those challenges?
I’ll share the major points of the document I use, and you’ll be able to download my template at the end of this post.
Who Does What?
One of the biggest sources of project frustration is uncertainty about roles.
- Who reviews content?
- Who approves graphics?
- Who coordinates schedules?
- Who is responsible for keeping the project moving?
- Who makes final decisions?
If no one knows, everyone either assumes someone else is handling it or everyone tries to handle it. The expectations document should briefly explain each person’s role, responsibilities, and decision-making authority.
For instructional design projects, for example, I explain that subject matter experts provide accurate content and business context, while the instructional designer is responsible for translating that expertise into an effective learning experience. Project managers coordinate timelines and communication, while graphic artists, developers, QA specialists, and accessibility specialists contribute their own areas of expertise behind the scenes.
That clarification can prevent a lot of unnecessary tension. SMEs don’t have to become experts in adult learning, and instructional designers shouldn’t be expected to know the intricacies of every technical topic they’re teaching.
What Does the Process Look Like?
People are much more comfortable participating in a project when they understand where they’re headed. Instead of simply telling stakeholders, “We’ll send you things to review,” walk them through the overall process. Explain the major phases, when reviews will occur, and how each review builds on the previous one.
For example, our course development process begins with preparation (planning and analysis), then moves to design and development, and finally to rollout (which includes testing, revisions, and implementation support).
You don’t need to overwhelm people with every task happening behind the scenes. A simple visual timeline often works best. The goal is to help stakeholders understand that projects develop in stages—and that each stage has a different purpose.
An analogy I often use—especially when stakeholders want to jump straight into development—is building a house. You wouldn’t put up walls and then decide you’d rather move the kitchen. You review the blueprints first (design documents and prototypes).
What Will I Be Reviewing?
It’s helpful for reviewers to know what deliverables they’ll be reviewing and what is expected from them for each review. That way, they’ll spend their time evaluating the right things.
For example, below is a list of what I look for at each stage of a typical eLearning development. Your milestones may look different depending on your industry, but the principle is the same: every review should have a clear purpose.
Sample Deliverables & Review Process
- Design Plan: Are we solving the right problem and teaching the right content? Is it organized appropriately?
- Prototype: Does the overall look, feel, and functionality match expectations?
- Storyboards: Is the content accurate and complete? Does the script sound natural? I like to emphasize the importance of this review and tell stakeholders to be their most careful here, because from this point forward, changes will get more time-consuming and more expensive. That’s because script changes may require rerecording narration, recreating animations, updating captions, retesting interactions, and conducting additional quality assurance reviews.
- Alpha/Draft: Are the graphics accurate and do they support the content well? Are videos appropriate? For courses with voiceover, I generally use AI voices at this point because script edits are still expected—and once professional narration has been recorded, changes become more expensive. Communicating this to reviewers helps set their expectations.
- Beta/Interim: Did we make the requested changes correctly? Have we broken anything new in the process? Concurrently with this verification review, we often test with the target audience during this stage to collect feedback from end users.
- Gold/Final: Were all requested changes made correctly? Is the course accessible? Does it work on the client’s learning management system?
How Much Time Will This Take?
One of the most common reasons projects fall behind is surprisingly simple: nobody planned ahead to set aside enough time to review the materials.
Your stakeholders probably have full-time jobs in addition to supporting your project. If review periods appear on their calendar without warning, they’ll naturally get pushed behind more urgent responsibilities. Instead, provide realistic estimates upfront.
Doing this allows stakeholders to reserve time before the project reaches that milestone—and dramatically increases the chances of receiving thoughtful feedback on schedule. If you can also provide a project schedule at the same time—with the caveat that dates can shift—they can go ahead and block off that time on their calendars from the beginning.
How Can I Give Useful Feedback?
Not all feedback is equally useful. Comments like “This doesn’t feel right” or “Can we make this better?” leave your team guessing. Instead, encourage stakeholders to provide feedback that is specific, actionable, and supported by context.
Provide specific examples for reviewers, such as:
- Instead of, “This is wrong,” try, “Step three should occur before step two because technicians must verify the pressure reading before opening the valve.”
- Instead of attaching a photo with no explanation, explain what the learner should notice in the image and why it matters.
I also encourage SMEs to share real examples, stories, case studies, and scenarios whenever possible. Those examples often become the most memorable parts of a learning experience because they help learners connect abstract concepts to real-world situations. When asking what steps learners must complete, I also ask what common mistakes people make—and what can happen when they make those mistakes. The answers often become the foundation for great scenarios.
Again, I emphasize to stakeholders that thorough reviews early in the project will reduce the amount of work later. Changes become progressively more expensive—both in time and budget—as development progresses.
Summary
Looking back, I wish someone had advised me to create a stakeholder expectations document before that project years ago. It would have saved a lot of rework—and that client relationship. That’s why I start projects with one today.
I’ve found that if you’ve answered everyone’s questions before they arise, clarified responsibilities, explained the review process, and set realistic expectations for timelines and feedback, you’ve removed a tremendous amount of uncertainty.
The result is fewer surprises, fewer missed deadlines, better feedback, and a much smoother experience for everyone involved.
Download a Template with an Example
Download my template below if you’d like a starting point for your own projects. Adapt it to fit your workflow, your team, and your clients—but don’t skip the conversation. A little expectation-setting at the beginning can save a lot of frustration at the end.
Not only will you need to modify my example for your own use, but you’ll also need to revise it periodically for different projects and clients. Just like when you’re designing learning experiences, you’ll want to tailor it to the audience so it’s relevant to them.
Comments
The frequent feedback pushback for interim steps reminds me of Agile penny game, https://www.youtube.com/watch?v=SumHmhjFMWM.
It illustrates efficacy of passing on smaller tasks in a team environment. To illuminate the pivots add a Left-Right dice roll to it.