What out the box really means

Although an off-the-shelf package designed for use in higher education institutions was chosen for implementation at Edinburgh, a lot of configuration was still required for it to meet their specific needs. During the procurement phase, research was done within the university to find out what the current business processes were and to discover any complex requirements, for example the scaling of exam results, that the system should handle. A large number of potential system users were involved in this requirements gathering process. The potential suppliers were asked to demonstrate how their system would meet these requirements. Tribal, the chosen supplier was the only company to adequately demonstrate a match with the requirements. Several members of the user community were however sceptical about the reasons for this

choice and felt that it was chosen because the university already had some undergraduate software from them. Those who were involved in the procurement process were asked which piece of software they felt was the best. Some believe that their views were ignored and that Tribal was always going to be chosen.

By choosing a software system that was already in use in other universities Edinburgh thought they were making a safe choice. While Tribal had only recently taken over SITS Ltd, they were very experienced in the education sector with other software packages of their own. As the company’s largest customer, Edinburgh also felt that extra effort would be made to make sure the system was a success to attract more high profile customers. Although other universities use the software, Edinburgh would be the first to implement it on such a large scale and at the same time they wanted a web- based system. This required extra configuration as the majority of the system is traditionally operated using dedicated client software. Whilst being a large customer gave the university some influence over Tribal and the future development of the software, they were also very much a ‘guinea pig’ as one user described it.

As the project began it became clear that the size and structure of the university did not match that preferred by the system. The University of Edinburgh has its administration distributed across its 3 colleges. However, SITS is better suited to institutions where the administration is centralised. Problems where the system did not really meet the University’s needs became more common and these incompatibilities had to be reconciled through further customisation, a view often taken by the vendors of COTS systems [13]. There are, however, areas such as assessment, where it is now clear that the system will not be able to do what the university requires. In these areas, a lot of extra work was required to generate processes that bring together university practices and that are implementable in the system. This required a large number of meetings and an extra committee was set up to come to the important decisions regarding the assessment process. Due to the large number of changes that need to be made to university practices around assessment there was a fear held by some that, due to time pressures, decisions would be made that they would later discover weren’t the right ones.

Edinburgh also started to try and influence Tribal to make changes to the software by trying to convince them that other universities would also benefit from the features. When issues regarding the software’s inability to meet the universities needs were discussed, comparisons were often made with other institutions using the software to try and see why they were not experiencing the same problems. It became clear however that many of the institutions using SITS were only using certain modules, often in isolation, and on a much smaller scale than planned at Edinburgh. They had also made fewer changes to these modules, only using those that were appropriate for their specific needs. Differences in the Scottish and English education systems in areas such as funding also added unexpected complexity.

While one of the benefits of ERP systems is that the supplier is constantly updating them in light of new requirements [91] the release of updates during system development often caused an extra level of complexity. The new versions of the software always had to be considered to ensure compatibility and time had to be allocated to installing and testing the upgrades. The timing of the install had to be chosen very carefully. If any problems were encountered they could impact the rest of the project. Certain areas of development work were also carried out by Tribal as required and delays in the delivery of these and issues with what was delivered also had an impact on the work that could be done.

The effort required to configure the system to meet even the basic requirements was vastly underestimated and it is now recognised by everyone involved that they were naïve in their expectations. This experience is being learnt from and a better idea of the effort required to web-enable the software is developing. There is, however, a rather unhelpful culture of blame in the university and this often comes to light when these issues are discussed. It became more common to question if the correct decision was made and if the system they chose was the right one. As the amount of slippage increased and more difficulties were encountered many people, both within the project and in the user community, started to believe that the university was over-sold the software and that they bought into what was simply a ‘good sales pitch’. When they are discussing the matter more seriously, however, there still seems to be a belief that they would have encountered the same problems and possibly more with any of the other systems on the market.