There are lots of times that stakeholders have unrealistic expectations and that you, as the product manager/business analyst will have to manage them so that the scope of the project doesn’t balloon out of proportion. In this blog post, however, I am going to speak to a very specific type of stakeholder expectation: that your project, despite whatever the business objectives are or scope of the project is, will solve all his problems.
For clarification, I’m currently on a project that is touted as the new, great thing at the company; a project that will transform the company. Because of this and the generic nature of the name of the project, I am always fielding requests from future stakeholders/ SMEs who want to meet with me on a fact-finding mission to see how their requirements can be incorporated into my project.
Sometimes, the SMEs are right on the money and their requirements DO belong in the project I’m working on. We have found some very key interlocks this way. However, more often than not, the SMEs are expecting my project to solve their underlying problems/issues. For instance, I had a fact finding mission with a team that had issues with services not showing up. They expected my project to tackle this and fix it. However, the issue was an underlying data problem, not an issue with the application my project is replacing.
So, how do you manage these sorts of stakeholders with their silver-bullet expectations? I’ve collected a couple of tools for my arsenal to help at most of my fact finding meetings:
- At the beginning of the meeting, state clearly what the scope of your project is, what things are considered in scope and which things explicitly lay outside of the scope of your work. Be very clear about this. A Business Objectives Model can be very helpful in visually illustrating the complete scope and rationale behind the project.
- Listen to their pain. Regardless of whether or not their problems lay within the scope of your project, you have already agreed to meet with them, so listen, even if you think the features will be out of scope.
- If their request is out of scope, be up front about that, but offer to help to the extent that you can. Possibly by getting them in contact with a project that might be the one to help with their features/requirements.
- Finally, ask follow up questions. Even if their biggest pain point is not within your scope, you’re probably talking to them because they (the stakeholder/SME) generically fall under the scope of your project, so see if there is another problem they have that your project can solve.
- Additionally (not necessarily in meetings), I’ve found it helpful to have an “Out of Scope” section in my documentation. This is a section where you can document the issues and problems people have, but explicitly call it as out of scope for your project. Ideally, with these features, you would have an alternative project where they might belong.
Now, this is not a comprehensive list of things you can do to manage stakeholder expectations and it is not a one-size fits all solution either. You have to tailor every conversation you have to the needs at hand. But I found this to be extremely helpful in reining in scope on projects while still maintaining good relationships with my SMEs/stakeholders.
What do you do that is effective at managing stakeholder/SME expectations?
