Let’s go more deeply to managing stakeholder expectations as it was discussed in earlier post comments. Successful project and product needs successful stakeholder expectation management. When expectation management is kept effective it provides valuable source for the feedback. Even expectation management sounds relative simple to do I have found myself many times figuring how it would be good to done. Other question is that how much it’s needed.
In this post I’ll go through basics of stakeholder expectation management from product owner point of view and in next post I’ll adopt theory to practical example in my agile context.
From the wiki we can find that project stakeholders
- sponsor a project, or
- have an interest or a gain upon a successful completion of a project;
- may have a positive or negative influence in the project completion
In practice it can be management, customer, main users, dev team and customer support. For finding how much expectations management is needed we could group these entities with these question.
How much communication is needed
First you need to identify the need. Identify and analyze your stakeholder to different groups based on their needs. After you have groups then communicate based on group needs. This way you are avoiding unnecessary overhead. After a while start to get feedback and re-arrange groups if needed.
For grouping there is several ways
- Users, governance, influencers and providers (source)
- Priority groups which are based on variables: power (high/low) and interest (high/low) (source)
- Impact of product (ROI, change in future work load etc.)
Also there is needed to consider that how big trust there is for project/product success. If stakeholder trusts product success then need of the communication is not so high. From my experience there is variances like
- Competence people vs. not competence people working with product
- Small project vs. big project
- Known markets vs. unknown markets
How communication can be done
Keeping expectations in already familiar tools will help you to avoid unnecessary overhead.
- Here you will capture your business value, customer main needs, critical attributes etc. So it is already telling you what are the stakeholder expectations
- Checking this regularly will give to you and other stakeholders opportunity to know if product is still going to deliver value what was expected
- This usually is document. For communicating more about critical attributes I propose tool from Mike Cohn’s blog.
- What expectation are going to be filled and when? What are milestones? When people with impact needs to be ready?
- With this it’s also easy to visualize what happens when stakeholders come up with new ideas and requirements (yes it really happens when stakeholders understands that changes and feedback are welcome) or some key people are lost from project.
- Visualization can be simple time line or gant chart or release burndown chart.
- Which are the next things to be build.
- More detailed than release plan and from my experience big picture can be hided to backlog. Use it for correct purposes for needed stakeholders (like dev teams and users).
- Useful session to make sure that expectations for this sprint are filled.
- Is more detailed and might hide big picture so this is not ideal for all stakeholders.
Identify and analyze your product stakeholders. Try to find how often and what kind of information they are interest to get. After this is done then include information to existing tools which you are using for your product. During implementation phase get back to these tools and check is product still meeting stakeholder expectations. If not then fix direction (or expectations).
One point which also good to know is mentioned in this post. There are realistic and unrealistic expectations. Don’t let unrealistic expectations be alive.