Stakeholder Buy-in

On the 9th of June we hosted an Assembly. The topic was Stakeholder buy-in and we invited participants from other 6 JISC-funded projects and a representative from the JISC. (Find the programme here.) Our aim was to have a small but friendly gathering where we could exchange ideas, issues and problems related to stakeholder engagement. Basically what we asked presenters was to share their practical experiences at trying to engage their stakeholders. The event proved to be veeeeery interesting and useful for everyone! And I do not think I am exaggerating.

Most of our projects are focused on the development of a technological tool, and that on its own is an enormous task. Activities such as interviewing users, user needs analysis, writing of specifications and prototyping, are very much connected with the projects' cores. Somehow we take for granted that everyone is going to like our product and find it useful. That is not always the case.

Around all these initiatives there are a lot of human and social forces which affect or are affected by our projects. These forces need to be understood and assessed so they can be used in the design and implementation of our products. Stakeholders are the people and organisations that generate those forces which can be in favour or against us. Knowing what they do, think and expect is essential for the success of our work. We need to get most of them on board, and when that is not possible we need to be aware of their presence… and reasons for not liking us.

Anyway, we had 6 presentations, all of them different. (Yes, it was unbelievable how different our approaches were.) I guess those depended on the kinds of organisations we are working in, the kinds of projects we are working on and the kinds of stakeholders we were aiming at. I have embedded the presentations below so you can have a look at them (they are organised by order of presentation). Next to them I have attached some comments that Sally Rumsey (BRII project manager) wrote.



BRII [Oxford]

• Aims at efficient sharing of research activity information by using semantic web technologies.
• Exploratory phase around the whole University, aimed at understanding organisational structures and research cultures
• Difficult to make sense of the chaotic structure of Oxford
• Polarized views were found with respect to uses and needs of research activity data
• views are influenced by research field, and kind of job (academic, non-academic), and scope (does the job involve just one field or department, or more: divisional level, University level, cross disciplinary?)

CAIRO [Roehampton]

• Aimed at high level enterprise systems
• Developed a communication plan
• An intellectual thread runs through all communications whatever the medium
• Delivering this high intensity communications is hard work
• There is a distinct gulf between the strategies and the technologies

IDMAPS [Newcastle]

• Aiming to improve institutional data flow
• Systems have grown up piecemeal
• 32 separate systems so data sharing is problematic
• Creating a new information architecture which will lead to personalised services
• Selling data flow as an institutional problem
• Created ‘Wall of data doom’ diagrams of systems. Invited comments on their interpretation of systems based on the interviews.

SLAP [Gloucestershire]

• Simplifying learner administration processes
• Aiming to improve student enquiries and applications processes
• Identified blockers and supporters within their stakeholders
• Created a graph of Power against Interest and aimed communications at each group
• Use staff news publication for regular updates
• Demonstrate progress and change to counter any cynicism about nothing ever happening

Academic Networking [Cambridge]

• Created using user experience methodology
• Research phase followed by design phase
• Need to design the criteria and then decide the number of participants
• Used academia.edu and LinkedIn to find participants
• Asked the question “Where are the problems?”
• Clustered people who behave in the same way
• Used similar behaviours to create 3 personas (a bit like use case)
• Get input from stakeholders. Using a paper based task helped create ownership. Ask lots of ‘Why?’ questions when testing paper prototype
• Keep going until every participant is happy
• Read full text
  

eAdministration of Teaching [Cambridge]

• Created sort of entities of jobs, people, units. Jobs are a teaching activity done by one person
• Using 6 departments for this project
• Involve those who will be involved in future ongoing maintenance of the system from early on
• A problem of how to maintain momentum of input. Develop user forum
• Read full text
  

Guest Speaker

After lunch Susannah Wintersgill,, Head of Internal Communications, Public Affairs, Oxford University, gave a presentation on Stakeholder buy-in for a project that involves the desing of a new staff web gateway for Oxford University.

She told us that the Uni website has >7000 pages managed by around 24 groups and includes about 187 departments etc. Any decisions have to be approved by Congregation, a group of around 4000 people. This preserves academic freedom and the democratic structure of Oxford.

There are major questions of who are the stakeholders and how to reach them
Three groups:

• Steering Group (for direction)
• Consultation Group (as representative of College & University as possible and carry out user testing)
• Contesting Group – vocal and critical at set milestones. Clear criteria and remit. They are there to challenge and critique not for every thought of theirs to be incorporated in the website

They spent months user testing and user acceptance testing, from that she is able to recommended a few things:

• Good to build in communications from an early stage.
• Use volunteers as champions who will talk to others and gather research. To senior officers of the University eg VC. Use departmental newsletters to communicate. Plan and build in from the beginning.
• Important not just to have one editor of the website – bias and could limit development
• Consultation is key – everyone likes to have a say
• Danger of stakeholder fatigue. Don’t overload your stakeholders. Use a mini survey to find out who else is doing similar or related work within the University
• Important to learn from user research but not be absolutely tied to it

Breakout group

These are some notes from our last session. We discussed in groups our approaches and came up with ideas and suggestions for better practices. We hope we will develop these notes into more userfriendly format in the near future:

• It is easy to pay only lip service to stakeholder buy-in
• Communications plan – do it early. Importance of planning.
• Tasks – make your stakeholders do something but keep it within reason and not to much
• Identify stakeholders – what do they want?
• Sending out newsletters etc can have mixed results. It doesn’t necessarily mean they’ll be read. Timed carefully eg Friday afternoon or just before lunch
• Choose the right tools for the job – the message, the medium and the way to know and approach your audience (identify narrow bands of different groups). Eg some may prefer podcasts (young?) to printed literature (older?)
• Manage expectations
• Try not to appear too one-sided. If everything appears marvellous people may not believe you.
• Difficulties of selling the potential when the project is only a proof of concept or pilot. How do you show the bigger picture? Stakeholders may only see the things that are immediately relevant to them (think – light bulb is useful, but the potential of electricity). Counteract this by ensuring that the initial project is useful. Create relevant demos and pilots, something that people can use
• Either describe by saying ‘This is the end goal and these are the prerequisites we need to get there (painting bigger picture but possibly raising expectations) or say ‘This is what we’re going to do in this project that is useful to you’ (but danger of losing the ultimate goal
• Communications must be onging. Distinguish between dissemination and discussion
• Balance the number of stakeholders involved with the quality of the feedback.

We finished the day with a tour to the Bodleian Library

Print this post