It’s a familiar scenario; a high profile piece of work with multiple stakeholders involved needs to fulfill everyone’s expectations. With many opinions, objectives and often, shifting deadlines, how can your team ensure you create something within the given timeframe without it becoming a free-for-all? Here are my tips.
Agree roles and responsibilities upfront
Some of your key contacts will be subject matter experts or consultants rather than official sign-offs. Ensure that they understand early on in the process where their knowledge will be needed and when (and if) you’ll be keeping them updated on an ongoing basis. Failure to do this can lead to ad hoc interruptions and delays to your project whilst you manage communications with them. Having a clear communication plan will also avoid any nasty surprises for them when they find something out further down the line that you forgot to tell them about. On big projects, ‘show and tells’ can help stakeholders feel included, as long as they understand when they are for info only and when feedback is required.
Map out a more formal sign-off process for the reviewers of your work, and stick to it. Any deviation from this allows people to ‘sneak in’ feedback which again can derail you from your tasks. And be strict on deadlines so that you keep on track.
It’s wise to agree some ground rules for the project up front that everyone signs up to, whether it’s meeting attendance or some collective behaviours such as regular communication. Every so often throughout the project these should be revisited.
Ensure your core team are empowered
Part of assigning roles and responsibilities is about creating a sense of empowerment to the delivery team. Too many people too heavily involved in the detail not only slows down work but it undermines the very skills you’ve built up within the team.
If you have the right people in the right roles (which have been outlined from the start) they should know if, and when, they need to bring in the wider members and stakeholders to help make key decisions. Some projects nominate ‘gatekeepers’ and bring those gatekeepers in at the required gates to approve the work so far, before it can progress any further.
Everybody has the right to an opinion. But not everyone needs to ‘like’ the end result. Subjective views can distract away from the ultimate aim; to create something that delivers the business objective in a way that resonates with users/customers. One of the behaviors you could instill in your team (at the start of the project) is that they will always view the work through one of the two lenses: customer, or business. This can prevent personal viewpoints creeping into feedback.
This isn’t to say that the team shouldn’t acknowledge opinions. Of course they should. But if it’s purely an opinion, the team should be able to make a decision whether or not to act upon it. Recognise whether the feedback is a deal-breaker, or just a ‘nice to have’, and move on.
Agree on your MVP
Sometimes ‘good’ is good enough, and the tweaks and refinement can be made later on. To get your minimum viable product to market it doesn’t need to be perfect (as epitomised by Facebook’s famous mantra ‘Done is better than perfect’). It can be useful to remember that when taking stakeholders and wider team members through the work.
Start a backlog or carpark of all the ideas people have for improvements later on. Once the delivery team have built something, some of these ideas can form great opportunities for testing and learning when live.
Use your experts and quantitative data
When it comes to customer and user experience, you’ll often come across the ‘Well I’m a user’ argument from stakeholders when they voice their feedback. However true that may be, they may not be the target audience for the product, and reacting to one piece of feedback by making a change is not always necessary.
Any good delivery team will user-test rigorously and base iterations on solid evidence. If you see several users stumbling or struggling to understand a concept, then you probably do need to change something. If you hit a fundamental sticking point with one user, then again you might need to consider a change. But decisions should be considered, rather than knee-jerk reactions.
Once you begin sharing your output, things will be ruthlessly challenged by stakeholders. The team should be prepared and be ready to explain the rationale and justification for their designs. A team that have consulted subject matter experts throughout the process, and used learnings from previous projects to inform their decisions, will be better armed to deal with these challenges.
If you liked this article, why not read Content Design — fact or fiction?