Getting stakeholder buy-in across a siloed organization
Robert Mills
Founder, Fourth Wall Content
In 2016, the University of Auckland embarked on a three-year program to revive its web presence. It wanted to change its digital first-impression from an out-of-date, content-heavy, organization-focused, and traditional website to an engaging online experience designed for its users that truly showcased the vibrancy of university life.
On paper, the brief was fairly straightforward: conduct user research, define personas and customer journeys, design a new information architecture, and audit and rewrite hundreds of pages of content so that it was useful and usable.
But the team knew that a critical component to the success of the project was to get stakeholder buy-in.
Without that, none of the deliverables would be accepted, content would not be reviewed or approved in the tight timeframes, and the new centralized website would lose its integrity quickly after launch.
In a 2018 GatherContent webinar, some of the University of Auckland team shared their journey through this program of work.
The team shared how they engaged stakeholders from the beginning, adapted content production workflows so they fit the business, and built an agile content team that mobilized content producers across the University to create user-first content that ignored internal silos.
Why stakeholder buy-in is important
Before we hop into the details of this particular case study, let’s talk about why stakeholder buy-in is important.
"Getting your key stakeholders on board for a project before it starts is vital to the success of the project."
Not only do internal stakeholders like your team members need to be on board, but key decision-makers like the executive team need to be as well.
If they understand why a project is important and how it will impact the overall organization, they’re more likely to contribute, providing whatever resources necessary to make it a successful project.
The impact of stakeholder buy-in
When you gain buy-in from project stakeholders and senior management, you ensure your project’s success. Senior leaders, project managers, and any other stakeholder group who are committed to the success of a project will provide whatever resources or support they need to see that the project is successful on various levels.
However, just as buy-in from important stakeholders can be transformative for a project, a lack of buy-in can be detrimental. If different stakeholders in and outside of your organization don’t understand why something is important, they likely won’t do everything they can to support your project and ensure its goals are met.
Stakeholders need to understand not only why a project is important for the organization as a whole but also how it impacts them. How will this project’s success correspond to their success?
Case study: A digital-first university
The impetus for committing to a long-term transformation project was to be a truly digital-first university. Despite being steeped in tradition, the University of Auckland is also cutting-edge and at the forefront of research.
Facts about the University:
Founded in 1883
The largest university in New Zealand
More than 40,000 students, nearly 10,000 of whom graduate annually
5 main campuses
8 faculties and 2 large scale research centers
This was their first truly agile project, and it needed a big change in ways of thinking about how to solve challenges.
What the project achieved
Over 19,000 pages of old content were reviewed, rewritten, or removed to form just over 7,000 pages in the new formats
15 websites consolidated into one
Service Divisions, Faculties, and LSRIs have analytics dashboards to see how their web pages are performing
A true culture of collaboration between all the content writers and content coordinators across Faculties and LSRIs
Building a content team
It was about eight months into the project that they started to build the necessary content team. This would bring together lots of different roles and disciplines—but with the provision that they had to be sat together as working remotely wouldn't cut it.
The assembled team included seconded staff members and contractors.
The seconded staff members had real knowledge of how students use the website and the problems that they face with it.
The contractors brought different ways of working, open minds, and lots of energy. New people bring questions. The University has its own language, so contractors asked questions about that.
For example, when internal staff said they couldn’t do something, they often asked, why not? The contractors positively challenged the status quo.
An outdated homepage
The legacy homepage had been added to and allowed to grow for eight years. It was “the place where everything is housed.” As part of this project, the team spent six months creating components for the new homepage.
It took the team six months to redevelop and redesign the university’s home page so that it was easier to find information.
Once the homepage was planned, structured, and under control, the team moved onto the faculty sites.
In this instance, a faculty is like a college, not a staff member. Then they tackled program or course pages, news, and are improving other areas as the project continues.
The team also worked on redesigning the faculty sites to make things easier to find, read, and access.
In addition, the pages for different academic programs also needed a redesign and new content.
Lessons learned
As with any project, there were plenty of lessons learned, which presenters Michelle and Sally were happy to share during the GatherContent webinar.
Many different stakeholders had to work together to make this project a success!
1. Our ways of working evolved throughout the project.
The team set up a lot of the agile processes, hired two contract writers, and made sure everybody was on board with agile methodologies and vocabulary.
The team grew and changed as contractors came and went, but publishers were involved for the project duration. It was essential that there was a versatile team that could move between roles because ways of working did change and things were learned.
There were four key areas to the project, each with its own processes:
Planning
Writing
Publishing
Launching
Each team member was comfortable at every stage of the process. The publishers didn’t write, but the writers did learn to publish. The team was flexible and willing to learn, within clear roles, so that meant they could also level up their own skills.
Every stakeholder understood their role during each part of the content production process.
2. Delays to development didn’t give the content team extra time.
The content team had to work closely with external forces such as the development team. While they were on the same project, the content process wasn't affected by any changes from the teams around it.
A content roadmap was defined and adhered to regardless. There was no shift in content deadlines, even though this was an agile project. Eventually, delivering what was promised on time gained the trust of stakeholders.
The content team had to work closely with other stakeholders like the development team to deliver their portion of the project on time.
3. It helps to have a great product.
There was a lot of wariness across the university. Many stakeholders stood back and waited to see what happened with the project.
The website wasn't loved. The homepage had been neglected. Templates were breaking down as they tried to make them do things they weren’t designed to do. Naturally, people distrusted the whole thing.
As the project progressed and the new website started to come together, those skeptics could see the new version (product) was great! They started to see the removal of duplication of content and an improvement in content quality.
Of course, they wanted that for their own programs and many of those reluctant stakeholders became advocates.
As different stakeholders work together, they start to see the final vision coming together.
4. Stakeholder engagement was ongoing and continued to grow.
Stakeholder engagement isn't a box-ticking exercise or one-off task. It never stopped for the entire project, and beyond. It wouldn't work to have a one-off chat to provide occasional updates.
The content team admitted that they underestimated the engagement effort. As the project gained momentum, engagement didn't decline over time, it became more intense. Luckily they implemented a solid engagement plan.
Engaging stakeholders
The next stage of the webinar looked in more detail at the fourth lesson learned. There were three clear stages to the content teams engagement strategy:
Pre-engagement
Engagement hierarchy
Tell the story
The university had a huge ecosystem of content and needed a multi-phased approach to communication and engagement.
The project leads went in and answered all of the big questions from stakeholders before any work had taken place. They broke the big rocks, per se, so the content team only had little rocks to deal with.
During these pre-engagement chats, they discussed the project, how it would run, and what the different phases would be. They also kept track of who they engaged with and when and what issues had been raised.
Next, they had to map out an engagement hierarchy. It was necessary to build relationships across a hierarchical organization. People respected that they had a 1:1 conversation rather than group discussions or workshops as it made them feel able to be honest—especially with senior leadership.
They also ran kickoff sessions with new business areas being worked with. This was an opportunity to disseminate the language around agile, sprints and share tools for the project. They also shared their golden rules, which we will come onto shortly.
Telling the story was important, and in ways that would make people listen and would resonate. Part of this process included showcases where updates were provided.
During the showcase, someone was named a stakeholder of the sprint. This costs nothing but was well received. It showed the project team members were nice people to work with, and the showcase became an amazing communication tool that helped to raise champions and advocates.
Content review and workflow
There was a lot of legacy content in the university's digital estate. A lot. With the new user-centered approach, not all of the existing content was fit for purpose.
The team created different templates for each type of content so the content team would better understand what content was needed.
To solve this they created different templates for different content types. Such as a homepage template, link pages that connected different sections, and content pages.
Here’s an example of the front page template and what the final product looked like.
When talking to different areas they could show them how their page would be structured. The content was written in Google Docs (you can also use GatherContent for this)!
Below you can see source content on the left and the published equivalent for an alumni page.
Here’s how the alumni home page copy looked like before it went live and what it looked like after being published.
A spreadsheet was then used to track progress:
The team used this spreadsheet to track the progress of each page, which was a vital part of keeping all stakeholders on track and organized.
In this example, they were keeping track of if a page had been approved if there were blockers, and if it had been published.
That was okay for straightforward content, but a lot of it wasn't straightforward. So they needed to be flexible on how to collaborate with content owners, get feedback, sign off, and publish it.
The course information was complex, with multiple owners, so preconceived ideas about engagement had to be changed. It had to be tracked at a component level:
Each deliverable was tracked on a spreadsheet so that everyone was on the same page about progress.
This information was used as a communication tool for showcases and a way to push content owners forward. There was no one size fits all for creating and publishing content so the team had to leave their egos at the door and adapt as the content needed, with lots of course correction.
The golden rules for project management
Some golden rules were developed by the team, but they extended beyond the core content team. Not to mention, the rules were embraced across the organization.
The golden rules were the points of truth to reflect on when things were rushed or intense and when there were lots of demands from across different areas of the university.
The work itself:
Accessibility and responsive design
Not all content is equal
Minimum Viable Product (MVP)
Where we work:
The University is not an agile environment
The website is not the answer to all of the businesses problems
To have a great website we need great publishers and remember, the faculties are not all the same
How we work:
Aim for better, not perfect
No one knows as much as all of us. We are learning and working at the same time
How we get things done is as important as getting them done
What’s next?
A new team has been formed to help continue with the work—the web team. Their aim is to continue the direction and support of those doing the work.
The team will begin looking at artifacts around the website—communication pathways, style guides, policies—and making sure they are all in line with the website. The website is still being iterated on to remain aligned with the golden rules too.
How to get stakeholder buy-in
Getting stakeholder buy-in on a project is easier said than done. Here are some simple tips you can use to get buy-in from everyone in your organization:
Engage stakeholders as early as possible. Don’t wait until the project has started to get buy-in from your stakeholders. For best results, engage stakeholders early in the management process.
Provide a clear rationale for the project. People don’t tend to argue with logic or statistics. Make sure you have clear and rational reasons for completing a project.
Speak their language. As you begin to speak with stakeholders, try to speak their language. Discuss the project in terms that make sense to them, making a clear connection between the project’s success and their success.
Identify and manage risks. There are going to be risks with any project. By identifying these risks early on, you’ll be better prepared to manage them. Be clear about your risk management plan.
Make expectations clear. Stakeholders are far more likely to commit to a project when they understand clearly what is expected of them, what their goals are, and how they will benefit.
Watch the recording
If you want to find out more about this project at the University of Auckland, watch our on-demand recording where Sally and Michelle talk through everything in this summary in more detail.
Good to Know: You can also check out our webinar library to learn more ways to use GatherContent and how the platform is helping other organizations.
On paper, the brief was fairly straightforward: conduct user research, define personas and customer journeys, design a new information architecture, and audit and rewrite hundreds of pages of content so that it was useful and usable.
But the team knew that a critical component to the success of the project was to get stakeholder buy-in.
Without that, none of the deliverables would be accepted, content would not be reviewed or approved in the tight timeframes, and the new centralized website would lose its integrity quickly after launch.
In a 2018 GatherContent webinar, some of the University of Auckland team shared their journey through this program of work.
The team shared how they engaged stakeholders from the beginning, adapted content production workflows so they fit the business, and built an agile content team that mobilized content producers across the University to create user-first content that ignored internal silos.
Why stakeholder buy-in is important
Before we hop into the details of this particular case study, let’s talk about why stakeholder buy-in is important.
"Getting your key stakeholders on board for a project before it starts is vital to the success of the project."
Not only do internal stakeholders like your team members need to be on board, but key decision-makers like the executive team need to be as well.
If they understand why a project is important and how it will impact the overall organization, they’re more likely to contribute, providing whatever resources necessary to make it a successful project.
The impact of stakeholder buy-in
When you gain buy-in from project stakeholders and senior management, you ensure your project’s success. Senior leaders, project managers, and any other stakeholder group who are committed to the success of a project will provide whatever resources or support they need to see that the project is successful on various levels.
However, just as buy-in from important stakeholders can be transformative for a project, a lack of buy-in can be detrimental. If different stakeholders in and outside of your organization don’t understand why something is important, they likely won’t do everything they can to support your project and ensure its goals are met.
Stakeholders need to understand not only why a project is important for the organization as a whole but also how it impacts them. How will this project’s success correspond to their success?
Case study: A digital-first university
The impetus for committing to a long-term transformation project was to be a truly digital-first university. Despite being steeped in tradition, the University of Auckland is also cutting-edge and at the forefront of research.
Facts about the University:
Founded in 1883
The largest university in New Zealand
More than 40,000 students, nearly 10,000 of whom graduate annually
5 main campuses
8 faculties and 2 large scale research centers
This was their first truly agile project, and it needed a big change in ways of thinking about how to solve challenges.
What the project achieved
Over 19,000 pages of old content were reviewed, rewritten, or removed to form just over 7,000 pages in the new formats
15 websites consolidated into one
Service Divisions, Faculties, and LSRIs have analytics dashboards to see how their web pages are performing
A true culture of collaboration between all the content writers and content coordinators across Faculties and LSRIs
Building a content team
It was about eight months into the project that they started to build the necessary content team. This would bring together lots of different roles and disciplines—but with the provision that they had to be sat together as working remotely wouldn't cut it.
The assembled team included seconded staff members and contractors.
The seconded staff members had real knowledge of how students use the website and the problems that they face with it.
The contractors brought different ways of working, open minds, and lots of energy. New people bring questions. The University has its own language, so contractors asked questions about that.
For example, when internal staff said they couldn’t do something, they often asked, why not? The contractors positively challenged the status quo.
An outdated homepage
The legacy homepage had been added to and allowed to grow for eight years. It was “the place where everything is housed.” As part of this project, the team spent six months creating components for the new homepage.
It took the team six months to redevelop and redesign the university’s home page so that it was easier to find information.
Once the homepage was planned, structured, and under control, the team moved onto the faculty sites.
In this instance, a faculty is like a college, not a staff member. Then they tackled program or course pages, news, and are improving other areas as the project continues.
The team also worked on redesigning the faculty sites to make things easier to find, read, and access.
In addition, the pages for different academic programs also needed a redesign and new content.
Lessons learned
As with any project, there were plenty of lessons learned, which presenters Michelle and Sally were happy to share during the GatherContent webinar.
Many different stakeholders had to work together to make this project a success!
1. Our ways of working evolved throughout the project.
The team set up a lot of the agile processes, hired two contract writers, and made sure everybody was on board with agile methodologies and vocabulary.
The team grew and changed as contractors came and went, but publishers were involved for the project duration. It was essential that there was a versatile team that could move between roles because ways of working did change and things were learned.
There were four key areas to the project, each with its own processes:
Planning
Writing
Publishing
Launching
Each team member was comfortable at every stage of the process. The publishers didn’t write, but the writers did learn to publish. The team was flexible and willing to learn, within clear roles, so that meant they could also level up their own skills.
Every stakeholder understood their role during each part of the content production process.
2. Delays to development didn’t give the content team extra time.
The content team had to work closely with external forces such as the development team. While they were on the same project, the content process wasn't affected by any changes from the teams around it.
A content roadmap was defined and adhered to regardless. There was no shift in content deadlines, even though this was an agile project. Eventually, delivering what was promised on time gained the trust of stakeholders.
The content team had to work closely with other stakeholders like the development team to deliver their portion of the project on time.
3. It helps to have a great product.
There was a lot of wariness across the university. Many stakeholders stood back and waited to see what happened with the project.
The website wasn't loved. The homepage had been neglected. Templates were breaking down as they tried to make them do things they weren’t designed to do. Naturally, people distrusted the whole thing.
As the project progressed and the new website started to come together, those skeptics could see the new version (product) was great! They started to see the removal of duplication of content and an improvement in content quality.
Of course, they wanted that for their own programs and many of those reluctant stakeholders became advocates.
As different stakeholders work together, they start to see the final vision coming together.
4. Stakeholder engagement was ongoing and continued to grow.
Stakeholder engagement isn't a box-ticking exercise or one-off task. It never stopped for the entire project, and beyond. It wouldn't work to have a one-off chat to provide occasional updates.
The content team admitted that they underestimated the engagement effort. As the project gained momentum, engagement didn't decline over time, it became more intense. Luckily they implemented a solid engagement plan.
Engaging stakeholders
The next stage of the webinar looked in more detail at the fourth lesson learned. There were three clear stages to the content teams engagement strategy:
Pre-engagement
Engagement hierarchy
Tell the story
The university had a huge ecosystem of content and needed a multi-phased approach to communication and engagement.
The project leads went in and answered all of the big questions from stakeholders before any work had taken place. They broke the big rocks, per se, so the content team only had little rocks to deal with.
During these pre-engagement chats, they discussed the project, how it would run, and what the different phases would be. They also kept track of who they engaged with and when and what issues had been raised.
Next, they had to map out an engagement hierarchy. It was necessary to build relationships across a hierarchical organization. People respected that they had a 1:1 conversation rather than group discussions or workshops as it made them feel able to be honest—especially with senior leadership.
They also ran kickoff sessions with new business areas being worked with. This was an opportunity to disseminate the language around agile, sprints and share tools for the project. They also shared their golden rules, which we will come onto shortly.
Telling the story was important, and in ways that would make people listen and would resonate. Part of this process included showcases where updates were provided.
During the showcase, someone was named a stakeholder of the sprint. This costs nothing but was well received. It showed the project team members were nice people to work with, and the showcase became an amazing communication tool that helped to raise champions and advocates.
Content review and workflow
There was a lot of legacy content in the university's digital estate. A lot. With the new user-centered approach, not all of the existing content was fit for purpose.
The team created different templates for each type of content so the content team would better understand what content was needed.
To solve this they created different templates for different content types. Such as a homepage template, link pages that connected different sections, and content pages.
Here’s an example of the front page template and what the final product looked like.
When talking to different areas they could show them how their page would be structured. The content was written in Google Docs (you can also use GatherContent for this)!
Below you can see source content on the left and the published equivalent for an alumni page.
Here’s how the alumni home page copy looked like before it went live and what it looked like after being published.
A spreadsheet was then used to track progress:
The team used this spreadsheet to track the progress of each page, which was a vital part of keeping all stakeholders on track and organized.
In this example, they were keeping track of if a page had been approved if there were blockers, and if it had been published.
That was okay for straightforward content, but a lot of it wasn't straightforward. So they needed to be flexible on how to collaborate with content owners, get feedback, sign off, and publish it.
The course information was complex, with multiple owners, so preconceived ideas about engagement had to be changed. It had to be tracked at a component level:
Each deliverable was tracked on a spreadsheet so that everyone was on the same page about progress.
This information was used as a communication tool for showcases and a way to push content owners forward. There was no one size fits all for creating and publishing content so the team had to leave their egos at the door and adapt as the content needed, with lots of course correction.
The golden rules for project management
Some golden rules were developed by the team, but they extended beyond the core content team. Not to mention, the rules were embraced across the organization.
The golden rules were the points of truth to reflect on when things were rushed or intense and when there were lots of demands from across different areas of the university.
The work itself:
Accessibility and responsive design
Not all content is equal
Minimum Viable Product (MVP)
Where we work:
The University is not an agile environment
The website is not the answer to all of the businesses problems
To have a great website we need great publishers and remember, the faculties are not all the same
How we work:
Aim for better, not perfect
No one knows as much as all of us. We are learning and working at the same time
How we get things done is as important as getting them done
What’s next?
A new team has been formed to help continue with the work—the web team. Their aim is to continue the direction and support of those doing the work.
The team will begin looking at artifacts around the website—communication pathways, style guides, policies—and making sure they are all in line with the website. The website is still being iterated on to remain aligned with the golden rules too.
How to get stakeholder buy-in
Getting stakeholder buy-in on a project is easier said than done. Here are some simple tips you can use to get buy-in from everyone in your organization:
Engage stakeholders as early as possible. Don’t wait until the project has started to get buy-in from your stakeholders. For best results, engage stakeholders early in the management process.
Provide a clear rationale for the project. People don’t tend to argue with logic or statistics. Make sure you have clear and rational reasons for completing a project.
Speak their language. As you begin to speak with stakeholders, try to speak their language. Discuss the project in terms that make sense to them, making a clear connection between the project’s success and their success.
Identify and manage risks. There are going to be risks with any project. By identifying these risks early on, you’ll be better prepared to manage them. Be clear about your risk management plan.
Make expectations clear. Stakeholders are far more likely to commit to a project when they understand clearly what is expected of them, what their goals are, and how they will benefit.
Watch the recording
If you want to find out more about this project at the University of Auckland, watch our on-demand recording where Sally and Michelle talk through everything in this summary in more detail.
Good to Know: You can also check out our webinar library to learn more ways to use GatherContent and how the platform is helping other organizations.
Rob is Founder of Fourth Wall Content working with clients on content strategy, creation and marketing. Previously, in his role as Head of Content at GatherContent he managed all of the organisation's content output and content operations.
Share on Facebook
Share on Twitter
Share on LinkedIn
Share with email
