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

BRII Blue Pages

Creating Oxford University Blue Pages is one of the objectives of the BRII Project (see http://brii.bodleian.ox.ac.uk.) The Blue Pages will be a directory of expertise. Through them you will be able to search for research activities and experts in Oxford University. As I see it, it will be a sort of mega tool allowing you to see what is in Oxford's Research Information Infrastructure from different angles, at different depths, and through a variety of search options.

This morning I had a meeting with Sally and Monica to start sketching a mock up. We made a few (technical) design decisions (which I could probably be able to comment on in a few weeks time, if Monica helps me!) After the meeting I ended up with the feeling that these Blue Pages are not going to be just some “Blue Pages”. Blue Pages is a nice name. It relates to the white and yellow pages where you were able to find telephone numbers or addresses of people and businesses. White and yellow pages were very useful in their time. However, those are old concepts.

BRII’s Blue Pages will be more than a list of something. Try to picture the Research Information Infrastructure as a sphere containing all information we harvest about research activities in Oxford. (The multidimensional cube analogy I used a few posts ago still applies. I used cubes to describe research activity objects.) Within that sphere you have information collected from different sources in Oxford and now connected by using semantic web technologies. There will be so much information that you will need something powerful to start exploring it and finding what you want. You will need to hold that sphere and turn it around as you wish until you find what you want (the way you need it) or at least until you find a starting point from where you can start digging (angle and depth).

The blue pages will do all that for you.

As I have mentioned in previous posts, the outcomes of the interviews I have done emphasise the need to provide access to information from different angles (are you interested in publications, in current activities, in collaborations?) and depths: broad perspectives – narrow perspectives, zoom in – zoom out. So for example if you type Pathology, the Blue Pages could give you a list of research sub fields, or research projects under pathology. If you are not interested in details, that list would give you an overview of the sort of research done there. If you are interested in detail, you can search for specific names, or click on the links resulting from your Pathology search.

At departmental and University levels there are needs for discovery of hidden connections which may lead to future collaborations. These needs may emerge from sponsors wanting to fund original, interdisciplinary research, or from the departments’ research strategies which see gaps or weaknesses in their current research. The Blue pages will be able to connect information offered at any level to whatever other information is available in the infrastructure. A straight forward example would be the Research Topics of Interest in a Researcher's Profile. With one click on a profile you will be able to find other people or projects related to the same topics.

Note: the above are just ideas. Not sure if all them will be implemented as I presented them or if we will need some changes.

--------------------
On Tuesday we had our Assembly. The event turned out to be very interesting and everyone left the place happy. I will post on this in 1 or 2 weeks after I finish a webpage with all the presentations, comments and outcomes from the meeting.

Stakeholder Analysis Report 1

On Tuesday we had our 3rd Project Board meeting. For that I prepared a short presentation with an overview of my data. I had previously emailed them a list of stakeholders I had interviewed with some comments. This gave them an idea of the kinds of (administrative/academic) areas that have participated so far. I also prepared a couple of slides to help me send a clearer message.



And this is roughly what I said:

This is an overview of the kinds of stakeholders I have met which give me an idea about their particular interests in the project and their needs of research activity data.

Top down – Bottom up (slide 2)
First, I found opposite views in terms of what stakeholders perceive of BRII. Whether some people see it as having a Top-down approach or being imposed from top levels of the University, other people see it as being a Bottom-up initiative allowing researchers make their work more visible among the administrative levels and outside the University. Mostly administrative staff at departmental and University levels have a bottom-up perception and academics have a top-down perception. The following are short profiles for these groups:

Academics already get the information and visibility they need and want. They do not have an interest beyond their field, (which can comprise interdisciplinary sub-fields), and beyond the network of connections they already have. Getting more contacts and promotion is part of their job but they do this by attending conferences and publishing.

• To find information about finished projects, they see publications
• To find information about current and new projects they attend conferences and request information from Research Services

PIs do not use the web as much as one would suspect. They are limited to academic journals and databases, some of them use bibliographic indexing systems and e-mail based alert systems, telling them about new publications in their area. That is how they find information about people and potential collaborations.
Some of them think web-visibility is important because they know that the sponsors see their websites - but due to their multiple responsibilities updating their websites gets pushed down. Academics belonging to competitive research areas put more effort in updating their information online.

Administrative staff‘s job involves overseeing a number of projects, mostly from the financial, project management point of view. They are driven by the need to get more money for the departments/units from external funding. Strategies are drawn to see how this can be achieved. All of these strategies also aim at increasing competitiveness to achieve better visibility and reputation in the eyes of sponsors, visibility and reputation on individual and departmental levels.

Some strategies involve recruitment, some others mentoring and some others tracking and controlling current projects. Other strategies involve promoting collaborations and finding particular expertise needed. The more competitive the area the more essential collaborations are. For all these tasks there is a need for information within and outside their fields of expertise. (within=current projects, outside= current and potential collaborations) Administrative staff have to deal with huge amounts of information which they get from multiple sources and which they format according to their needs. A system which helps them (1) manage and (2) find information would be very useful for them.

At (high) University level needs of information crossing academic fields is more essential. People here are not specialised or looking for information on their field but on information that provides an overview of what is going on in the University. Finding information on academics and/or activities using not specialised language is important as this information is being searched by someone who is not an expert and will probably be disseminated to a variety of people who may not be experts as well.
-----------------------------
The bars in slide 2 represent a continuum of needs of information from stakeholders. If you go more to the top you will need information crossing areas and connecting information from different sources. If you go down the continuum you need to get in-depth information on specific areas, which can perhaps complement and enhance academic journal or databases? This can be connected to the idea about a zoom in - zoom out tool I wrote a few weeks ago.

The right hand side bars represent flow of information. The actual information on research activities is generated by the researchers, this is their information. Academics make use of this information, particularly publications, which is relevant to their field(s) of expertise. Requests for this information are made by administrative staff at departmental level so they can keep (financial) control of their research activities. At University level requests of information are made to departments, information which summarises and highlights some of their research.

Research Culture (slide 3)

Research culture is a spectrum of cultures which go from the Humanities to Sciences. I have drawn this as a spectrum to emphasise the fact that most researchers are not located in either extreme but in between the extremes.

Humanities: researchers tend to work on their own. Need fewer resources. Some academics have never got a research grant in their life. Outcomes: publications and books. Their findings are more permanent in time (of course I do not want to generalise to all researchers in humanities.)

Sciences: work in bigger projects (time and size), they get their money from external funding (hence the need to be more exposed to sponsors, and the more competitive mentality.) They need specialised resources, buildings and technology. Outcomes, publications, software, discoveries, findings which can be applied in practice (e.g. drugs, treatments) some of their findings are ephemeral in time. (Of course I do not want to generalise to all researchers in sciences.)

The bigger the project (size, interdisciplinary, collaborations, resources) the more need for funding. For this, being able to sell/advertise their research to sponsors is vital.

Current Systems (slide 3)

With respect to sources of information, the bigger the area the bigger the need to organise and manage data.

Smaller departments are able to manage their information manually or with spreadsheets. They centralise the control of data and the administration of research activities. There is one person gathering information to upload in the website.
Bigger departments have systems or more staff managing their data. They are able to distribute some administrative responsibilities such as updating websites and reporting.
Everyone finds Research Services’ reports essential.