Return to journal

Website development’s ‘make or break’: internal stakeholder engagement

Practical tips for website development’s unfashionable ‘must do’, written by Head of digital project management, Mark Sullivan. 

Two males sitting in an office environment looking at a computer screen together

Building a beautiful, effective website relies on many things. Smart UX thinking. Analytics. Inspiring design. Clean project management. The right tech. But one often overlooked factor can derail a project before it even begins: internal stakeholder engagement. 

 

Every new site needs to tick boxes for multiple decision-makers. The process can’t be about making choices on their behalf: the right people need to be fully engaged throughout the process. Get it wrong and you’ll struggle to spot problems until late in the process (when it’s harder and more expensive to put them right). You’ll be trusting to luck that your site will meet the needs of your business and audiences, too. 

 

So what’s the secret? When and how should you engage internal stakeholders constructively without adding complexity - or derailing the process entirely?

 

Target the right people - and recruit ‘heroes’


The first question to answer is: who should you involve? You can’t engage everyone, and not everyone you engage should be involved at the same level. 

 

It’s important to identify a range of high-priority stakeholders - let’s call them ‘heroes’ - early-on who can represent the needs of specific business audiences (for example investors, jobseekers or the media). While a broader number can be involved in information-gathering, this group must take an active role in shaping the final product from kick-off to launch. Alongside your core project team, they’ll feed-in to decisions at key stages. 

 

Seniority is important, but ideally you’ll recruit people with the right mindset: people with the flexibility to embrace new, more flexible ways of working and the basics of digital. 

 

Tip: at the outset your ‘heroes’ may not be sure how to involve themselves. Your first communication to them will be crucial to building trust and securing their ongoing involvement on the right terms. Let them know they’ve been identified and tell them why. Be clear about their relevance to the project’s broader context, and what they’ll be responsible for.

 

Crowdsource the brief


Critical to any website build project is developing a clear scope - a brief everyone can get behind and use to inform decision-making. Engaging your ‘heroes’ in defining this upfront will not only help you arrive at the right brief, but also encourage the key players to get behind it. It could prove useful in handling conflict later, too. 

 

Once your heroes are recruited, get them to articulate their website needs and pain-points through a questionnaire or interviews. This isn’t to say everything they want should be incorporated: you don’t want to dilute the end product. It’s your job to reconcile individual requests with the broader needs of the business, but you’ll be able to put a deep understanding of your stakeholders’ needs into the mix.

 

From there you can bring the group together to play back a map of requirements and collectively refine a set that will guide the site’s development. 

 

Tip: when you communicate your project scope back to the group, be transparent about your decisions and back them up with data. This will help reduce surprises and mitigate grievances that could prevent productive engagement with the project in the future.  

 

Transparent, regular, clear: get the comms right 


Internal stakeholders will come to the project with different skillsets. Your comms will need to both educate and inspire - keep language simple and jargon-free, and make sure you’re being ultra-clear about the purpose of each ask. 

 

The channels you use will be important - you’re going to need direct lines for quick decision-making. We prefer Slack for ongoing comms with both a core project team and stakeholder ‘heroes’. We also suggest using Jira to empower all stakeholders to report bugs and issues on their terms. 

 

Tip: while technology can boost collaboration, don’t underestimate the value of face-to-face contact. Some milestones - early scoping workshops, for example - work better in person, but there’s a wider rationale: developing chemistry and rapport on these demanding projects can be helpful - getting people together can help.

 

Embrace agile


No website build project worth its salt doesn’t embrace Agile. Put simply, Agile makes sure you reach the best possible product efficiently and effectively. 

 

But it can feel scary from a stakeholder perspective: decision-makers unfamiliar with it can feel uncertain about signing off on plans if they can’t ‘see’ what they’re going to get, or unable to input constructively on ‘work in progress’. 

 

You’ll need to encourage a mindset shift - that not doing everything at once will result in a better end product - among key stakeholders. Avoid making assumptions about levels of understanding and be super-specific about what useful feedback looks like at each stage. 

 

Tip: flag Agile with stakeholders at the outset and explain how it should influence their input further down the line (and what kind of feedback might be counter productive). Surface the typical concerns and issues people tend to have working in this way, and suggest the best ways to tackle them. 

 

Set yourself up for the future


Stakeholder engagement can’t end when the site is launched: your ‘heroes’ and their departments will be owners of it going forward, and their evolving needs will help define its continuing evolution. 

 

Hand over the keys to these users and their teams alongside a clear framework covering how it should be used (including anything that’s relevant from digital policy through tone of voice). Supporting this with training tailored to each team’s needs can help provide the rigour and control needed to guarantee quality and alignment with your overarching strategy as your site develops.

 

Tip: as new requirements roll-in post launch, handling requests for change or development can become complex and political. We recommend forming a ‘triage’ team to manage and action emerging requirements - making sure they’re aligned to the wider needs of the business.

 

We built a sector-defining website for GSK through a process that took in consultation with more than 150 stakeholders - and now work as an ongoing partner for the pharma giant in the ongoing development of its web estate. Here’s how we did it.