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

Stakeholder Analysis

Another week into the project....

And now I have set foot on the analysis process, writing project briefs and sending emails like crazy... hmmm well not like crazy, I am still in first gear but I gaining speed!

I have explained in previous posts that Oxford University is so big and so complex I needed a few weeks to absorb and understand all these names, acronyms, hierarchies, structures, organisational culture, reasons for doing things the way they are done, traditions, history, etc, etc. I am still digesting. Just yesterday I attended a consultation meeting where we discussed a draft of a strategic plan for OULS. As I am new in Oxford University I asked many questions, and was surprised by the answers. Those revealed an institution which takes pride in its traditions and achievements. OULS as, I think, the rest of the University, want to develop new state of the art systems by building on the strengths and opportunities inscribed in their traditions. BRII is a good example of this as it has been designed so that groups around the University can continue to work as they are used to and will not have to transfer to a new technical system to take advantage of the project work. That is, BRII will cause little interference among its stakeholders.

Anyhow, as BRII has to collect sample data sets from its stakeholders, I had to think on which departments or research areas would be suitable places to start from. I thought one strategy could be to shoot everything that moves and ask everyone in my mailing list! but then I would probably not get good feedback and good quality data. So I decided to choose according on type of area (depending on different characteristics) and of course on availability and will of stakeholders to contribute. As we need variety to demonstrate BRII will be able to cope with Oxford University heterogeneity I thought on the following:

• Choose one department from each of the following divisions: Humanities, Mathematical, Physical & Life Sciences and Social Sciences. People belonging to those divisions are from different species. They will provide us with different kinds of data in terms of the kinds of research they do and also different perspectives on the needs and new uses that Research Management data can fulfil.

I have set my eyes in Phonetics Laboratory in Humanities, ComLab in MPLS and OII in Social Sciences. I have contacted people in the first two and I am still waiting for a response from someone in the third one.

• As Medical Sciences are part and main stakeholder of BRII I should get more departments from that division involved. I am looking for variety here as well. In a conversation with Simon Neil, Medical Sciences Administrative Officer, he suggested I should look for clinical and non-clinical departments (I don’t understand the difference between them but I guess they do research in different ways.) He also suggested looking for departments which are using the standard divisional CMS (content management system) to develop their websites, and departments which are using different approaches. Finally, he suggested one big department and a small one. With all that I will get sample data that represent the whole division.

Here I have set my eyes in the following departments or units:

1. Nuffield Department of Anaesthetics – smallest department in the division, no CMS
2. Nuffield Department of Clinical Medicine – clinical department, use a different CMS, biggest department in the division
3. Department of Physiology, anatomy and genetics – Non-clinical department, use standard CMS
4. Department of Cardiovascular Medicine – clinical department, use standard CMS
5. Health Economics Research Centre – They are users of ORA
6. Babylab – they have connections with Phonetics Laboratory

• Get data from one University College
• Get data from one central administrative department, such as Research Services.

Now, I am sending emails to people working in those areas, introducing myself and the BRII project. I am first asking for a quick face-to-face or telephone conversation to inform them about the project and the possible ways that each area could get involved. I am talking about interviews and online surveys but I will explain that in another post. I have followed Simon Neil’s advice and contacted departmental administrators and research facilitators. They are people who have an overall view of their areas; they know people and may have access to some data.

Connecting stakeholders and data

The first stage in the BRII project is to carry out a stakeholder analysis. A stakeholder analysis is a process that involves the identification of the project's stakeholders and an assessment of their interests and the ways those interests could affect or be affected by the project. Stakeholders could be people or organisations and their interests could be in favour or against the project.

As the BRII project is about gathering and using Research Activity data, our stakeholders will be people or entities who produce or use that data. For example, researchers, project managers, research facilitators and administrative staff. Also units, departments, institutes, colleges, where research is carried out.

The assessment of the stakeholders' interests will give us some light on the kinds of research activity data they produce and use for work. It should also be useful to investigate other related needs that are not fulfilled at the moment, but which could be covered by the project's outcomes. So, it is not only knowing who, but also what they do and what they would like to do. But more importantly it involves getting that precious data from them which we can use to build the Research Information Infrastructure.

In a previous post I wrote about finding potential stakeholders within Oxford complex organisation. I have also written a bit about the research management and research activity data we need from them.
In this post I would like to put these two concepts together.

I would like first to make emphasis on the importance of being able to connect stakeholders and their data between them. Research is an activity which is carried out within a research community. People from that community need to communicate between them, exchange ideas, collaborate, compare their research, assess the uniqueness of their contributions, etc, etc. One way of doing this is by accessing information about research that each other have, information which could reveal interesting opportunities, connections and collaborations that are happening around them.

I have an example that could illustrate this. During this "making sense of chaos" stage (which is still going on) I have been able to identify some links between units in MedSci and other departments in other divisions as well as with external bodies. I call them paths of cross disciplinary research collaboration. In the figure on the right two paths are shown:

1) Department of Cardiovascular Medicine - Centre for Research Excellence CRE (consists of research groups from across the University) - British Heart Foundation BHF (external funding body)

CRE is funded by BHF and promote cardiovascular research from all areas within Oxford.

2) ComLab (in MPLS) - Computational Linguistics Group (interdisciplinary group) - Phonetics Laboratory (Humanities division) - Babylab (MedSci).

I have come to know about some projects and collaborations happening across this path.

Like these two examples there could be many more paths out there which could be made visible through their data and BRII. Samples of paths like the above and other areas in MedSci will be good examples as they represent the heterogeneity of research in Oxford. Heterogeneous data will help BRII create richer ontologies which represent a variety of stakeholders and research their activity data in Oxford. Similarly, getting documented needs from a variety of stakeholders will help us to design web services which can demonstrate different uses.

BRII's expected output is a pilot of the research information infrastructure. Creating a pilot means creating a piece of software and data that we could use to demonstrate that the BRII strategy is feasible and useful. Having stakeholders representing different areas within the University (but mainly from Medical Sciences*) will help us to build a pilot which accounts for different kinds of data and needs (not all of them of course). That is, a pilot which can demonstrate a small set of services which account for diverse needs to serve an heterogeneous organisation.

* The Medical Sciences division is BRII's main stakeholder.