Stakeholder engagement

As mentioned previously, groups were created in an attempt to keep the wider community informed about the project and engage them in the change and development process. Although presentations were made to the stakeholders on new areas, these were generally after something was finalised such as new processes. Other than this, the majority of the engagement was done through the Implementation Coordinators. Their role was to communicate information about the project to their departments and promote the project, whilst preparing users for the changes it would bring. They were also supposed to provide the development team with feedback from

their departments and inform them of issues with the system that they were having. This role however didn’t work as well as intended, with many implementation coordinators finding it difficult to find the time to engage fully with the project. They also seemed to struggle when championing the project due to their limited influence. The role of Implementation Coordinator was intended to be allocated to people with a high level of influence in their department. However, this was in some cases delegated to people at a lower level who felt that they lacked the authority to tell people what to do.

Engagement of academics was an area of great concern for the project team. It was recognised that this would be difficult, but crucial to the success of the project[14]. Initial work on the project focused on modules in areas related to student administration, something most academics had limited interest in. Many were happy to ‘put their heads in the sand and wait for it to blow over’. Once talks turned to assessment this changed and many academics wanted to actively engage. What engagement actually meant however, was open to interpretation and some felt they could just provide a wish list of what they wanted and that it would be provided for them. Where the responsibility for engaging academics lies is also a point that was often questioned. Some felt the schools should be responsible rather than GEOMETER itself. In reality a combined effort was necessary to prepare them for change. Although many are reluctant to get involved at the moment, when there is something for them to see and do this might change, as one academic described it:

‘They will probably complain but then just get on with it and use it anyway as there is no alternative’.

The go-live of the postgraduate system was to be their first encounter with the software however use of this will be infrequent, even during peak times as it is limited to when they have applications to assess.

During the initial procurement phase engagement with the university community was encouraged and many helped the project in understanding the potential requirements of the system. They also helped the project understand the current work practices of the different university departments. When the processes and system were presented

to the users, however, there was a perception that the changes to their work processes were driven by the project team and that they had not been consulted. These changes were actually a result of the information gathered during the procurement phase but this wasn’t made clear to the users. The Valuta review after the undergraduate go-live suggested that this could have been avoided by following the initial requirements gathering phase with a business process reengineering phase in which the processes would have been defined, with the users developing a specification for the software that they agreed with. A similar feeling developed amongst the users when the postgraduate system went live. When presented with the system in a training session, several academics questioned if there were academics present on the Board and if those who take PhD students were even consulted.

Another group of stakeholders with whom engagement appeared to be lacking is the students. Although cited as the primary beneficiary of the system, little attempt was made to get them engaged in the early stages of the project. New applicants to the university would interact with the system throughout their time as a student. The system would store all their details and would be used for almost everything, including enrolling in modules, checking exam results and payment of fees. The university hoped through introducing the system that they would increase their levels of student satisfaction. Any engagement with students however was done by proxy, a small group and the concerns of students were prioritised dependent on how they would affect the university application rates and funding. The needs of overseas students for example were given high priority as they pay high fees to the university; however ‘home’ undergraduate students were given a lower priority as the university was oversubscribed by them. Little feedback was also gathered on applicants’ opinions of the undergraduate system after go-live. However, this has only been in operation a short time and plans are in place to do this more extensively in the future. The main assessment of the system’s success focused on comparison of application numbers rather than determining if the system had succeeded in its aim of being student friendly. After the postgraduate system went live and work was due to begin on student administration it was decided that students needed to get more involved in the project, helping to push the student-centric view. The Project Director commented that it would be interesting to see how the dynamics of the project and stakeholders would change with students involved.

Engagement of stakeholders is an area recognised as being extremely important to the project but also as being very difficult. In this project, the stakeholders are from many different groups and a member of the Board described it well, comparing their composition to having

‘Lots of sheep which are easy to herd, some cats which are so so and, in a few colleges, some squirrels which are extremely difficult as they move in 3 dimensions.’