Summary

While efforts are being made to address the project communication problems, it seems that they have only just become aware of the fact that some of them existed. They are now trying to find a better way to extract information from the team when addressing issues. When users report issues they are often related to the business processes. The use of the JIRA risk management system has been found to be over- complicated by some users and is going to be replaced for users with CMS, a content management system which is seen as more user-friendly. They are also now asking users to attempt to quantify the benefit of a change request, forcing them to think differently and this will help with resource issues and prioritising of requests. The creation of the Change and Prioritisation Group has also helped with this issue. In January 2009 support for applicants was transferred to Registry, reducing the load on the support team but this load is likely to increase again with future go-lives. However, as the scope of the project has now been dramatically reduced, the impact of the go-live of any future enhancements to the system will be much less.

The lessons-learned workshop with the ICs seemed to bring forward a lot of the issues that needed to be addressed and emphasised the impact some problems were having. Clarity of information seemed to still be at the heart of many of the issues arising and it is important that these problems are addressed if support is to be gained for the new system. While the team could see the areas that needed improvement, finding appropriate strategies is difficult and determining which are most appropriate in which circumstances and for which groups of stakeholders is even harder. Although a variety of strategies were being tried to overcome some of the communication issues these all required a large amount of the team’s time and as the project progressed this time was not available. While they hoped to continue to get the benefits from the small group interaction, finding a way this could be done in practice was something

they continued to struggle with. A ‘one size fits all’ approach was not possible and there was no ‘silver bullet’ that could solve all the problems. They failed to find a communications approach that could be applied to the variety of different areas involved in the project and that could scale with the planned scope of the project. Due to the impact of the problems encountered, further go-lives have not been cancelled and focus has moved to improving the usability of the undergraduate and postgraduate modules. Ensuring communication is managed effectively during this process will be important in gaining the help and support of the users that will be required for it to be successful.

5.4 Conclusions

While the GEOMETER project experienced a variety of problems with communication, these issues are not unique to the project. Many of the problems are general issues that are encountered in most large scale deployment projects. Getting information to and from a large number of different groups of, often distributed, stakeholders, and keeping this communication going throughout the life of a project is a complex and difficult task. The introduction of most new systems will involve a degree of change and effective communication is necessary to manage this process and minimise resistance. In order to ensure system requirements are met and that these reflect the needs of the users, continuous communication is necessary. Traditional approaches such as meetings, email and file stores are however often inappropriate for large projects as they do not scale to the levels necessary.

People are comfortable with the idea of meetings and a communication culture based around these is often quick to develop. There are however many problems with meetings:

• They do not scale well

• When you increase the number of participants scheduling becomes a problem

• People are reluctant to give up too much of their time

• In large projects, the number of stakeholders will be so large it will never be possible to meet with them all.

• Those who cannot attend meetings may still have valuable inputs but these contributions are often lost.

• As the number of attendees increases the effectiveness of any discussions held in the meetings is reduced.

• Gaining feedback from everyone present is not possible

• Only those who are most vocal will get their opinions heard and these may not be reflective of the majority of attendees.

A project website can be used as an outward facing mechanism to communicate with the wider stakeholders. This can be used as a place to find out what is happening in the project. However, this also has many inherent problems:

• Keeping it up-to-date is time consuming and often not done on a regular basis.

• Finding out when a website has changed and what has changed is difficult.

• If it is used as a file store, users need to know the files are there, how to find them and when they have been changed.

• Email notifications of changes contribute to people’s overloaded inboxes and may be treated as spam.

Email was one of the first widely adopted Internet communication technologies and its use has now become embedded in work routines, with most people checking it regularly. It is the most frequently used mechanism for communicating with stakeholders outside meetings and for gathering feedback. Its familiar nature, however, often means it is used in situations where it is not effective. Davenport found that 26% of people surveyed felt that email was being overused in their organisations ([156] cited in [157]). He also found that 21% felt overwhelmed by the amount of email they received and that it could sometimes diminish their productivity. Problems associated with the mass use of email include:

• An overflowing inbox can put people off reading messages, because of the amount of time it would take to find those that are relevant to them.

• Important information may be ignored or even deleted.

• Email is not effective for having discussions with multiple recipients.

• It’s hard to follow discussions and understanding can be dependent on the order that messages are received.

• The sequential nature of email makes it difficult to keep all responses together so they become intermingled with the rest of your messages.

• Emailing files can result in multiple versions being in circulation at the same time, which can become a source of confusion.

• Determining who to send an email to can also be extremely difficult when trying to send it to everyone who is interested without blanket communication.

As described above, the traditional methods of communication have many problems that are exasperated when scaled up to the size of complex projects. An alternative solution is required that will provide for the variety of communication needs in a complex project, helping to support communication amongst distributed stakeholders.