How to Manage Stakeholder Expectations
It’s possible to keep your stakeholders happy, even if quality is not great, simply by managing their expectations from start to finish.
If I had to summarise this post in a few words, I’d say something like this:
- Agree what the quality expectations are
- Figure out what to do to make sure they are met
- Agree how to measure whether they have been met
- If not, let the right people know and recommend some ways to improve quality and fix the problem
1. Agree What the Quality Expectations Are at the Start of the Project
Firstly, many Digital Transformation projects (but not all) will have public facing products. End users must be considered as key stakeholders and so it’s not always going to be possible to engage with them in the ways suggested in this post. In that case, the stakeholders referred to here, are the ones that can be realistically engaged and influenced. Other stakeholders will have different needs and expectations. So, the first thing to do is to identify who they are and what they want.
Quality must be considered at the start of your project, at the same time and in conjunction with time and cost. It’s difficult (if not impossible) to end up with a high-quality product unless this is done, and expectations are set correctly at the outset.
Testers, project managers and scrum masters should all be familiar with the time-cost-quality triangle.
Some people will say that it’s impossible to satisfy all three variables. Personally, I’d argue that it is possible – if expectations of time, cost and quality are all set accurately from the start.
I also feel strongly that if quality assurance and management practices are put in place early on, then project time and cost will both be lower than if quality is left unmanaged.
So, quality must be addressed at the very start of the project and expectations set.
Quality Planning and Quality Control
It’s important for the person and team responsible for quality (arguably everyone on the project) to fully understand project objectives and what the project is trying to achieve.
As testers, with a tester’s mindset, it’s easy to assume that the stakeholders all want the best possible quality product. However, I’ve worked on many projects where that is not the case and budget holders are willing to accept less testing, no QA processes and therefore reduced quality for a lower price and (wrongly) assumed increased speed of delivery. That certainly seems to be the case at the start of the project and when I give high level test estimates. Interestingly, this conversation can often be forgotten when bugs start appearing and as it gets closer to the release date. As such, it’s super-critical to document this, at a minimum in an email, and depending on how structured the project is, in a Quality Plan if there is one.
For successful Digital Transformation, end user needs and expectations are what matters. These need to include functionality but more than for other projects, I’d suggest usability, user experience and performance matter just as much. It may not be possible to gather these expectations from end users and so the Product Owner needs to represent their views.
2. Figure Out What to Do to Make Sure They Are Met
Part of the project plan and initiation process needs to consider how quality criteria and acceptance criteria will be documented and measured.
Define and agree quality assurance processes and what individuals need to do. Test driven development, adhering to good Agile (or Waterfall) principles, well controlled sprints and well-defined Definitions of Done are the most important things in my opinion.
Testing and bug reporting is usually how quality will be measured and in a Digital Transformation project UAT is key to this. However, in my view, testing doesn’t assure quality and good project practices must be employed throughout the delivery lifecycle, regardless of the delivery model.
3. Agree How to Measure Whether They Have Been Met
Agree what to measure throughout the delivery lifecycle. I often see a box ticking exercise against the chosen delivery process rather than checking the quality of the process and deliverables.
Also manage expectations of what is going to be reported, the format and frequency of reports. At the start, maintain the mantra “less is more” and try to keep it simple.
As well as bugs, quality risks and issues need to be identified and reported. Transparency is crucial when managing quality expectations effectively. However, timing of the message and not hitting the panic button every time there is a risk or issue, is also important.
4. Let the Right People Know and Recommend Some Ways to Improve the Quality if it Diverges from Expectations
Quality review meetings and quality reports are the way to let stakeholders know there’s a quality problem (or might be in future if something doesn’t change).
Reporting problems is good but isn’t always enough. It’s also important to discuss possible resolutions, risk mitigation tactics and make sensible and informed recommendations.
This process ensures stakeholders also have a clear expectation of how simple or complex the issue and its resolution are. By consulting stakeholders, they can see that you and the team have a real challenge and are doing whatever you can to resolve it. It’s important to properly consider stakeholder’s feedback, advice and recommendations and leverage their support (if it is forthcoming). This means they can then become part of the extended team and part of the solution – and importantly you are all in it together.
.png)
