Communication within the GEOMETER project

5.1.1 Problem 1: Structural barriers to communication

During the study the structure of the project team seemed to cause issues with communication. The separation of the team into streams working on different parts of the system, along with a separate test and training team was suitable for getting work done. The communication necessary between the streams on a project where the work was so inter-connected however seemed to be missing. A meeting-based culture existed, with each sub-team meeting weekly to discuss their progress, but this was restricted to that group. People in one stream often had very little idea what those in the other were doing, even though their work was intrinsically related. This lack of knowledge then caused problems in other areas. If a member of the team went out into the user community and was asked a question that was not related to the specific part of the system they had been working on, they were unable to answer. They often couldn’t direct the user to someone who would be able to deal with their enquiry. This frequently meant team members didn’t want to go out and talk to users and their inability to answer questions left users confused.

The team was restructured in an attempt to remove the silos, with two streams being merged and people were able to move more freely between the groups depending on the tasks being undertaken and where their skills and experience were needed. After the undergraduate go-live, a lessons learned workshop was held and one of the issues recognised there was the lack of communication throughout the team. In an attempt to address this problem, it was decided that members of each sub-team would attend the other sub-group meetings and report back, allowing a more general understanding of the project as a whole to develop amongst the team. There were, however, still issues with areas such as testing being kept involved and informed.

The emphasis on meetings also caused problems when each team was very busy and work commitments prevented them from attending the meetings held by different sub- teams. It was not always possible to continue with your own work whilst attending meetings to try and keep informed about the rest of the project and attending those meetings about the work you were doing. As the pressure mounted and the work load continued to increase with future deadlines, this practice became unsustainable. People were already working extremely long hours to get the work done and in a project with a tight plan that had already experienced a large amount of slippage, time was precious. Some may argue that it is more effective to spend their time doing their own work than learning about what other people are working on.

The layout of the office, with some groups being upstairs and some downstairs also caused problems when trying to encourage communication between the different groups. Due to resource restrictions and having to work with the office space available to them, this was hard for the team to avoid. To help with this it is important to encourage informal communication and put in place mechanisms to make communication amongst the team easier. The communication still predominantly occurs in formal settings, although attempts have been made to encourage the team to socialise, for example drinks after work on a Friday. Attendance does however vary with a small group of regulars and people still seem to stay in small groups of either people they work with or people they were friends with outside of the project.

5.1.2 Problem 2: Critical information points

Another communication issue that is related to the structure of the team is linked to the organisation of the individual streams. Groups are often focussed on a figurehead who is responsible for communicating information to the higher levels of the project. As the Project Director said: ‘everyone focuses around them and they become a bottleneck.’ Having critical information points is a problem that all areas of the project encounter. However, due to the hierarchic nature of some of the groups, when this person was away, for example due to illness or holiday, meetings and communication seemed to temporarily stop and this then impacted on what was achieved during this time. As all communication up the project hierarchy and to other areas was through this person, it was difficult for everyone else to find out what was happening in that area of the project.

Attempts have been made to try and discourage streams from developing a hierarchical structure and encourage a more flexible flatter arrangement. This however seems to have been purely through suggestion, with no way of ensuring it is happening. It also hits cultural barriers as people are more comfortable and familiar with working in a hierarchy, especially in settings such as universities which are inherently hierarchical in nature. As people became more aware of what others were doing and more emphasis was put on documentation of progress it became easier to get information when people were away. If tasks are worked on by more than one person this also helps to reduce the impact of the absence of anyone who may have been a critical information point. This means there is someone else to ask if one person is away. Prolonged absences and absences of several members of the same group can still however have an impact and affect communication.

5.1.3 Problem 3: Hierarchical decision justification

There were concerns within some parts of the team regarding decisions made by the Project Board. The justification of the decisions was often not communicated to those affected, leaving them to at times feel that it was the Board pushing their agenda and that the reasoning behind them was not sound. People were sometimes of the opinion that the Board did not have enough in-depth knowledge of the inner workings of the project to make certain decisions and didn’t really know what they meant in practice.

It was the team who had to communicate the decisions to the users and they found it hard to justify these decisions if they didn’t believe in them themselves or when they were aware the decisions were going to cause problems. Members of the wider university community also shared the view that the Board did not have sufficient knowledge about the workings of the university to know what was best for them. This was often because they were not aware of who was represented on the Board and who the members from their department were. They felt, like the team, that they knew their job best and should be consulted when decisions were being made that would affect it.

The Board having a more visible presence when announcing things to the users could have helped with this problem. Attempts were made to do this and ensure users were aware of where the messages were coming from and the justifications behind them. Emails to users announcing important decisions were changed to come from the Board, as they were members of the colleges and this helped show that it was not just the GEOMETER team making decisions but the university itself. This may have, in turn, helped the team when they talked to users about what was happening. It could have made them feel supported and helped to make the users more accepting of decisions. If the users were aware that the decisions were coming from the Board, the team may also have faced less of the negative feelings that existed.

More effort needed to be made when passing on decisions made by the Board to the project team to ensure they were clear, that they were informed decisions, and that everything had been taken into consideration. If decisions were made by the Board that affected the workload of the team, for example affecting deadlines or project scope, care needed to be taken to make sure they were well received and did not have a demoralising effect. Consulting with the team on key decisions may also have been beneficial.