The project team – IT department developers

Three IT developers were allocated by the IT department to assist the finance department and the vendor during the system development. Since this project adopted

the joint development strategy, they were expected to learn and understand the system structure to enable them to support and maintain the system when the vendor completed their task. The vendor at the same time had to transfer their knowledge and skills to these developers during the course of development.

6.4 Detailed chronological narratives of project trajectory

In general, the implementation of the new system tried to achieve system integration within the university, from academic systems right up to human resource systems, a complete campus solution. The islands of systems that were currently in operation had been creating confusion and frustration in relation to data instability and inconsistency. This had especially affected users in finance, where data from other departments were everything to them and they were the receivers of any system inconsistencies. Relying on these data had also created work redundancy, where data from other systems needed to be re-entered into the finance systems (W1). It was hoped that in the future by a push of a button, reports would be generated with correct figures and with supporting documents in place.

The island of systems that was erected from different departments, although initially only to cover their daily operation, over time had been outgrown by the expansion of the university. With 16,000 students, data provided by these different systems also differed, hence reducing the reliability of the reporting. The non-integration between these multiple systems also created redundancy of work for staff, especially in updating information in the respective systems. This created a gap between technology and structure and task and technology. The existing stand alone finance system with its limited parallel users also created a gap between technology and people.

Stakeholder Analysis

The reason for developing the legacy system was mainly to support their daily operations especially in the reporting of financial figures. From 1997 the system was used with continuous enhancement made to it to cope with the ever changing reporting requirement set by the government. But as the university expanded and competition increased, the legacy system was not able to cope with the expansion. This also reduced the efficiency of daily work practice and the problem of redundancy of work emerged. Thus it was not able to meet its raison d‟etre. The expectation that the users put on it collapsed. This created multiple conflicts between the stakeholders. Conflict between legacy systems (technology) and the reporting task (task) arose due to the failure of the legacy system to provide sound and valid financial reporting.

W1 Technology Structure Task Peopl e

At the same time, the legacy system (technology) also failed to

accommodate the governmental reporting structure

(structure), which caused further conflicts with the users (people) who had to restructure the reports manually to satisfy the reporting requirement. These conflicts failed to support the operations and the reporting function of the department thus establishing the need for a new integrated financial system.

At the project level (P1), the need for a new integrated system was well acknowledged by all stakeholders involved. Although different stakeholders had different expectations of the new project, this was all in congruence with the overall objective, which was to develop a new integrated system to support the university‟s operations. The steering committee, the finance users, the ICT developers and other internal parties (people) saw the need for the new integrated systems. At the same time, the external groups (being the vendor and the project manager) came into the project with systems that worked and fulfilled the client requirements. As such, the objective of the new system was aligned with the project group intentions and expectations.

The vendor came in with a base system which had been developed in Case 1 (V2). The vendor, acknowledging their system incompetence in relation to their process robustness, had tried to play the system integration card. The base system incompleteness was mainly due to the fact that Case 1 was still in its infancy during development. The system integration was hoped to crucially support what their clients existing system was missing. The need for the integration was hoped to supersede their ego of their so-called complete system. With an open mind, the vendor saw the project as an opportunity to improve their existing system and to make it a system best practice. In other words, the vendor came into this project with a system that integrated all functional areas of the university and this base system acted as a prototype during the development. The use of this prototype was to enable users to view the system as the development moved along. The vendor prepared themselves with enough manpower (developers) to comprehend the possible complexity of the project. This inevitably improved the overall project structure for the vendor. This created an equilibrium at the vendor level.

At the vendor level, each element and its expectations of the project were fully aligned, thus establishing a coalition among themselves. The base system (technology) acted as the prototype of the new integrated system, which was supported by a structured development activity (task). At the same time, the vendor (people) applied the knowledge and skills to support the project, thus ensuring the project would be a success.

As the development started with the business requirement session, the vendor was confronted with the users‟ unusual request. Rather than the legacy system being mapped to the base system, they (the users) suggested that the vendor should identify the additional functionalities of the legacy systems, update them onto the base system and then the actual requirement session could proceed. This activity created a gap between task and technology, where the base system was considered as having a lack of functionality and also between task and people, meaning the developers had to do additional work.

Stakeholder Analysis

The vendor was confident that the base system that they had was capable of improving the situation in the university through its integrated features. But at the same time, the end- users were also confident about their modified system and insisted that the vendor, before starting their development, should match the base system functionalities with the legacy system. Any discrepancies on the base system should be updated to follow the legacy system before actual development could start. Conflict arose between the vendor (people) and users (people) when the users insisted on using their base system as the base of the development, which was different from the vendor‟s expectation: the vendor expected to use the base system as the basis of the development and the base system as a prototype. Further conflict arose between the vendor (people) and system development (task) when the vendor changed the development approach to accommodate the users‟ request, thus creating an additional task for the developers. Another conflict arose between the base system (technology) and system development (task) where the base system was not stable enough to act as a prototype to assist the vendor to simplify their development. However, a coalition was established when the vendor agreed to match functionalities of legacy system with the base system. This agreement was mainly because of the process already embedded within the legacy system and with the vendor‟s expectation to improve the functionalities of their base system; this matching process would ensure their expectation was met. However, other conflicts still persisted.

V3 Technology Structure Task Peopl e

The vendor was in a dilemma when the users requested them to use their legacy system as the basis of the system requirement (V3). The users were claiming that in terms of functionalities, their legacy systems offered more than the vendor‟s base system. During the initial part of the business requirement sessions, the vendor had taken some time to sit down with the users and run through the vendor base system. This was because the users were completely familiar with their legacy systems and able to point out which part of the vendor‟s base systems needed to be updated. At the same time, the users had also provided the vendor with their work process to support their processes in the legacy systems. The most important point was that the users wanted the vendor to match their systems with the users‟ existing system. The reason was that their legacy system had gone through major changes from its inception many years ago. The flexibility of the legacy system had ensured valid changes were made. And what the system had now was complete enough to cater for their operational processes.

Moving forward with their requirements or in addition to their legacy systems, due to their years in operations, they were able to spell out other requirements that further enabled the vendor to improve their systems. Most of these requirements related to system reporting capabilities which referred to new guidelines and procedures. These guidelines and procedures covered internal and external parties. Government policies were the first to be adhered to, followed by other applicable policies by other universities. According to the users, it was important to know what they wanted and, as a control measure, what they want must fit with standard policies and guidelines. With any changes to the process workflow or any new introduction of processes, they would make sure that the internal audit department was involved in the process. This was to ensure the validity and the completeness of the newly developed process. It was hoped that upon conforming to standards and guidelines, this newly developed system could be applied to other universities or educational institutions. Another major aspect during the business requirement sessions was the level of user involvement. The arrangement of the users according to smaller groups had enabled them to go into the details of each process. In addition, the involvement of the clerical staff had enabled process detailing and catering system usability. But their involvement was only through their assistant accountants, who represented them and acted as a mediator to table their requirements during the working committee meetings.

Whilst detailed requirements were discussed at group level, a higher level discussion tabled their entire requirements together with the process flow. It was at this level that all integration issues were to be solved. Typically, when initial discussions only involved group members, their requirements were isolated to their own processes. When being tabled, sometimes these requirements contradicted other units‟ processes. This sometimes created a heated debate in determining the applicable processes – reaching deadlock where no-one was willing to compromise. This was where the finance project co-ordinator had to play his part in bringing everyone back into perspective. If this also failed, the matter had to be brought to the chairman of the finance working committee. Considering all arguments, she had to make her decisions. And her decision represented what was best for the organization rather than the individual units. It was during these multiple level meetings that the requirements of the lower level staff or the clerical staff faded away. Since their mediator had to defend their own processes in the meeting, failing to understand the importance of their requirements, the mediator gave way to others. It was during the system roll-out that the users identified that something was missing.

The process of requirement gathering flowed smoothly without major hiccups. Based on the users‟ work process and their system-based requirements, the vendor managed to develop their system requirement specification (SRS) in a timely manner. With the system process all in place, the vendor started developing the working prototype. The steering committee had decided that the project would be a joint development effort where the internal ICT department would join forces with the vendor team to develop the system (P2).

Within the stakeholder analysis, the expectation of a joint development approach was to ensure smooth development through joint development. The steering committee decided that the ICT developers would assist in the development. The reason was mainly to reduce the heavy reliance on the vendor once the project had been completed and it was expected that the ICT developers would be in charge of the enhancement and modification. The ICT developers agreed to this idea, with the expectation that it would

further improve their skills on system development. At the same time, the vendor was expected to transfer their knowledge and skills on development to the ICT developers.

But as development progressed with the vendor only allowed 12 months for development of all finance systems, the development pace was rapid. The vendor did not have spare time to dictate things that needed to be done by the IT developers. With the ICT developers‟ lack of knowledge on the tools used, they were left out of the development, thus no transfer of knowledge occurred. This consequently created a gap between people and structure, where the IT developers failed to grasp the technology, and between people and task, where the ICT developers were not able to assist in the project development.

Stakeholder Analysis

It was decided and agreed that the project would take only 12 months to complete. During these 12 months, the vendor was expected to transfer knowledge and skills to ICT developers. At the same time, the ICT developers were to absorb knowledge and skills from vendors. The joint development would ensure smooth development of the system. However, this limited project timeline created conflict between the vendor (people) and the project timeline (structure) in relation to the joint development scheme. Due to their packed schedule, the vendor was not able to teach or to transfer any knowledge to the ICT developers to enable them to jointly develop the system. As a result, another conflict arose between the ICT developers (people) and joint development (task) where the ICT developers were left behind and failed to assist in development.

Although it read perfectly on paper, there were constraints on the implementation side. The vendor team was working to a tight schedule of deadlines, thus there was no time to waste. Everybody had dedicated work to do and they were experts in their own areas. The ICT department developers, although there were three of them, were novices, especially with the vendor‟s development tools. Their experience did not help much during the development process. Failing to catch up with the vendor‟s team, the ICT team just assisted in co-ordinating the project meetings and other administrative tasks (P3). As the vendor did not have time to train them, it was up to them to learn by themselves.

For the data migration process, the users prepared a full ten years‟ worth of data from their legacy system. Upon checking in detail, it seems that there were differences in

Technology Structure Task Peopl e P3

terms of the data structure between the legacy systems and the new systems, as highlighted by the vendor‟s developer:

“The old system had its own structure. And we have our own system structure. Sometimes, their data structure is not able to be matched with our data structure. For example, the new system has company and branch field which is not available in the old systems. So it is not matched. There are instances where the old system has more data field than the new systems and vice versa… So we have to do data cleansing before it can be migrated to the new systems. We have to identify each field which takes a lot of time. It takes months for us to complete the data cleansing.”

Vendor developer, February 2009

As a result, the vendor had to do a data conversion to ensure that all data from the legacy systems were exactly mapped to the new systems and this took more time than expected (V4).

The process of data migration was not as smooth as the other earlier processes. The data provided by the user from the legacy system were raw data that needed to go through a cleansing process. This was due to the fact that there were differences between the legacy system data structure and the new system data structure. As a result, the vendor had to ensure all data structures were matched before the data could be migrated and this exercise took more time than it should have taken. Hence it created a gap between people and task being additional work to the vendor, and between task and structure, where due to the different data structure, additional tasks were required, which also affected the project timelines. This data cleansing exercise was a pre-requisite for the data migration process.

Stakeholder Analysis

Data migration was the most critical process to ensure project success. The user and the vendor had different expectations over the data migration process. To accommodate the data migration process, the users provided the vendor with the raw data taken from the legacy system and expected the vendor to migrate it. At the same time, the vendor would be required to match the data structure during migration. However, upon checking the raw data, the vendor found that there were discrepancies in the data structures between the legacy and the new system. This created a conflict between the legacy data structure (structure) and the new data structure (structure). This means that the raw data needed to be cleaned before it could be migrated to the new system. This additional

V4 Technology Structure Task Peopl e

process created a conflict between the vendor (people) and the data migration (task), where additional work needed to be completed before data could be migrated. This additional task (data cleansing) created further conflicts between the project timeline (structure) and data migration (task) due to the project‟s limited timeline.

The migration process that follows created a bigger gap between people and task and task and technology when the migrated data did not match the previous reports. Thus upon completion of the checking and reconciliation by the users, the vendor had to update the systems.

Stakeholder Analysis

The purpose of the data migration was to ensure smooth data transition from legacy to new database and in this case, the vendor was expected to ensure proper migration of data to ensure smooth completion of project deliverables. However, at the vendor level, the problems with the data migration process created more work than expected. A conflict arose between the data migration process (task) and the new system database (technology) when the data were not fully migrated into the new system database. Thus, in addition to the data cleansing process, which took time, the vendor had to update the new system database for all the reconciling items found by the users. This created another conflict between the vendor (people) and system development (task) due to more work and taking more development time, which was limited. As a result,