Many of the links in the following will now be broken due to changes in organisational systems

David Jones, How to live with ERP systems and thrive, Presented at the Tertiary Education Management Conference’2003, Adelaide


In the late 1990s many Australian Universities went through the process of chosing, acquiring and implementing Enterprise Resource Planning (ERP) Systems. This paper offers one example of how the Faculty of Informatics and Communication (Infocom) at Central Queensland University (CQU) has learned to live and thrive with CQU’s ERP system. This has been achieved through the use of an emergent development methodology to create a range of intermediary information systems that bridge the gap between CQU’s ERP system and the requirements of Infocom’s staff and students. Using specific examples the paper identifies a range of technical (bad technology, lack of technical knowledge, requirements mismatch and limited integration support) and organisational (system owner/user mismatch, organisational holes, organisational silos, developer/user distance, system/structural inertia) factors that help create this gap. The resulting intermediary information systems are used by hundreds of staff and thousands of students, offer significant advantages and enable further innovation. The paper suggests that the gap between institutional information systems and client requirements, exists in most Universities.


Over recent years the acquisition, implementation and use of Enterprise Resource Planning (ERP) Systems has become a standard feature of most Australian Higher Education institutions. To date most of the literature on ERP implementation in the Australian Higher Education sector has focused on the early stages of the ERP lifecycle: adoption decision, acquisition and implementation. This paper tells the story of how the Faculty of Informatics and Communication (Infocom) at Central Queensland University (CQU) has learnt to live (use and maintenance) and thrive (evolution) with CQU’s ERP system.

ERP systems are “commercial software packages that enable the integration of transaction-oriented data and business processes throughout an organization” (Markus, Axline et al. 2001). ERP systems provide cross-organisation integration through embedded business processes and are generally composed of several modules including human resources, sales, finance (Esteves and Pastor 2001) and, in the case of Universities, student administration. During the 1990s ERP systems were the de-facto standard for replacement of legacy systems in large companies (Parr and Shanks 2000).

The impact of ERP systems is so broad, touching many aspects of an organizations internal and external operations, that the successful implementation and use of these systems are critical to organizational performance and survival (Markus, Axline et al. 2001). Indeed, the failure of some ERP system implementations has lead to organizational bankruptcy (Davenport 1998; Markus and Tanis 2000).

In 1998, Central Queensland University issued a Request for Proposal (RFP) for the provision of a new administrative information system (Central Queensland University 1998). As a result of a selection process, the PeopleSoft ERP was adopted and implemented over a period of approximately three years. The final product consisted of the complete student system and most of the finance modules, excluding Accounts Receivable. While the original plan included the implementation of the Human Resource Modules, this phase has been suspended indefinitely. The implementation went over time by several months, was missing promised functionality and was over budget on completion. Under the traditional success/failure models, this implementation would be categorised as a failure (Standish Group 1995; Mahaney and Lederer 1999; Whittaker 1999).

This paper seeks to show that gaps exist between institutional information systems, like ERP systems, and the needs of the members of the organization. It starts by providing a brief introduction to Infocom, its web development team and the notion of institutional information systems. The main section of this paper describes four of the numerous information systems developed by the Infocom web team and uses these systems to highlight the gap between the relevant institutional information systems and the factors which create that gap. Lastly the paper briefly describes the process and technology used to develop the Infocom intermediary information systems.

Infocom and Institutional Information Systems

While ERP systems are the generally the most expensive institutional information system implemented by most institutions over recent years they are not alone. At most Australian Universities there are other information systems filling organisational needs that an ERP systems do not address. Course management systems (CMS), such as WebCT and Blackboard, are usually the next most expensive and far-reaching example. Other institutional information systems may include: timetable management software, assignment tracking software, bookshop management software, library catalogue systems and various infrastructure systems such as student and staff authentication. While the title of this paper mentions ERP systems the basic premise of this paper is that a gap exists between the functionality of all institutional information systems and the needs of the staff and students.

The Faculty of Informatics and Communication (Infocom) is one of five faculties at CQU and includes disciplines as diverse as Mathematics, Information Technology, Information Systems/ECommerce Each faculty consists of a number of schools, is led by an executive Dean and has reasonable freedom in its allocation of funds. CQU’s students study via a number of different modes including:

  • CQ Campus – traditional on-campus study at CQU’s Central Queensland campuses in Rockhampton, Bundaberg, Gladstone, Mackay and Emerald.
  • Distance Education/Flexible Learning – mostly print-based distance education supplemented with online learning and a small number of residential schools.
  • Australian International Campuses (AIC) – CQU’s “campuses in a building” in Brisbane, the Gold Coast, Sydney and Melbourne servicing primarily full-fee paying international students.
  • Overseas ventures – a range of ventures in Hong Kong, Singapore, Malaysia, Fiji and China.

Over recent years Infocom has taught about 30% of all CQU students. Table 1 provides a summary of Infocom’s student/course enrolments in 2002.

Mode Student/Course Enrolments


2496 (13.62%)


3813 (20.81%)


1835 (10.02%)


10178 (55.55%)



Table 1 – Infocom 2002 student/course enrolments

Since 1997 Infocom has had a small web team responsible for the development of information systems, mostly web-based, designed to support Infocom’s complex operations. That team has grown from a webmaster and a part-time developer (1997 to 2001) into a team with three permanent developers, 1 developer contracted until the end of 2003 and a webmaster. The work described in this paper is based on the activities of the Infocom web team.

Problems, Solutions and the Gaps

The basic premise of this paper is that there exists a gap between the functionality provided by institutional information systems and the needs of students and staff. The paper proposes that the development of intermediary information systems can help overcome this gap and provide significant advantages. This section describes four of the many intermediary information systems developed by the Infocom web team. Table 2 provides a summary of some of the other major intermediary information systems developed by the Infocom web team.

Title Purpose CQU System Usage


teaching, research, administrative and marketing needs of Infocom

Limited CQU
website – no faculty space

avg 1.5m+
requests per week


assignment submission and management

support from WebCT/Blackboard

students, 79 course offerings

Copy Detection

detection of plagiarism in essays and programming assignments

None available

assignments, 16 course offerings


reporting to meet ESOS compliance requirements

No equivalent

200 requests,
17 users

Student Portal

student interface to Infocom

No equivalent

requests, 10,000+ users

Staff Portal

staff interface to Infocom

No equivalent

requests, 800+ users


process to supplement processing of final results

Difficult to
use, location dependent peoplesoft process

300+ courses,
600,000+ results, since 2001

Online quiz

online quiz provision


students, 1.1million quiz attempts

Course groups

Method to
allocate and manage student groups for T&L


5 courses

Course Jump

Simple method
to find course websites

No equivalent

146,563 users
in 2003

Table 2 – Other Infocom Intermediary Information Systems

The examples discussed below are:

  1. Web-based Student Records – provides staff with access to student records data including course lists, student photos, and student enrolment details.
  2. Timetable generator – a web application that allows a student or staff member to generate a personal timetable.
  3. Minimal course presence – the provision of a consistent minimal web site for every course offered by Infocom independently of academic staff and as early as possible.
  4. Informal Review of Grades (IROG) – web-based processing of student requests for an informal review of a final grade.

Each example will include four common sections: requirement, CQU system, Infocom System and Sources of the Gap.

Student Records


Both academic and general staff need regular access to the data contained in the student records system for a range of purposes including: checking enrolment and graduation status, viewing student photos to match name and face, generation of CSV files for storing assessment results, accessing student contact information and many more.

CQU System

CQU’s ERP implementation does provide both academic and general staff with access to CQU’s student records system. However, this system suffers a number of problems including:

  • Time consuming.
    As documented in the relevant user documentation the process for retrieving a single course list involves a 26-step process requiring the use of two separate applications. One application, a Microsoft Windows application, is used to request the class list (report). A second application, a Web browser, is used to access the report architecture and retrieve the list. The entire process is reported to take some staff close to 20 minutes.
  • Confusing and difficult.
    The need to use two separate applications for a single task is confusing to many staff. The process is made more difficult due to the requirement for staff to be aware of various “codes” which are specific to the technology and not in normal everyday use.

    One example of this is the use of four digit code to represent a particular term (see explanation below). There are at least three other parts of this process that require users to bridge a similar semantic distance.

    Terms and the 4 digit term code.
    CQU currently has five terms which are known by staff and student as: summer (T1), autumn (T2), winter (T3), spring (T4) and spring/summer (T5). CQU’s student record system uses a 4 digit code to indicate both year and term. The 4 digit code uses the format CYYT where

    • C – is a single digit representing the century (1 – 1900, 2 – 2000).
    • YY – are two digits representing the year.
    • T – a single digit representing the term.

    As a result, 2032 = Term 2, 2003. 1995 = Term 5, 1999.

  • Geographic Restriction.

    The Microsoft Windows client used in the first step can only be used from computers located on the CQU network. This poses problems for CQU’s overseas commercial partners and staff travelling outside CQU. Any new commercial ventures based outside CQU’s network are unable to easily access CQU’s student records system.

  • Platform restriction.
    Users of alternate computing platforms (e.g. Apple, Linux etc) are generally unable to use the Windows client. In addition, due to limitations in the Peoplesoft tools only a certain limited range of Microsoft’s Windows operating systems are supported. As a result decisions about new computing platforms is being restricted by a single application.
  • A step backwards.
    The locally produced student records system replaced by Peoplesoft provided staff with Web-based access to student records data. This system addressed all of the above problems. In adopting Peoplesoft this functionality was lost and as a result many staff perceive Peoplesoft as a step backwards.

Due to the above problems most academic staff do not make direct use of CQU’s student records system. Any requirements for information from student records are sent to support staff, employed by the faculties, who do use the student records system.

Infocom System

Since late 2001 Infocom has provided a Web-based interface to student records as part of its staff portal, MyInfocom. The system provides quick and simple access to student and course information that can be accessed from any location and any computer platform where there is a Web-browser and an Internet connection.

The Infocom systems takes between 2 and 4 steps to generate a class list depending on whether you are using the Infocom specific or the generic CQU version. This is because the Infocom specific system is able to draw upon the Infocom teaching responsibilities database to automatically show Infocom staff details about courses they are teaching. There is no CQU database that tracks teaching responsibilities.

As Infocom’s staff portal MyInfocom also provides access to other information systems including: online assignment submission and marking, results processing, minimal course sites and informal review of grades. Use of MyInfocom, or MyCQU it’s Infocom produced CQU cousin, requires little or no training. Experience has shown that the most difficult step in using MyInfocom has been in learning how to download a CSV file form the system and get it into Microsoft Excel.

In late 2002 Infocom produced MyCQU a version of MyInfocom without the Infocom specific features. MyCQU was designed to be used by staff in faculties other than Infocom. Table 3 summarises usage of both MyInfocom and MyCQU since 2002.


Statistic 2002 2003 *

















Table 3 – Usage Figures for MyInfocom/MyCQU

* Until 17th August 2003

Sources of the Gap

Contributing factors to the gap between the CQU system and the requirements of the clients include:

  • “Bad” technology
    CQU’s systems reliance on a client/server application demonstrates all the problems of that approach including platform and geographic restrictions. In addition the design of the client application is poorly done in that it requires staff to provide information they don’t normally know and requires a significant number of steps and time. The poor quality of this design is due in part to a lack of technical knowledge but the largest factor is the restrictions placed by the nature of the technology.

  • Technological inertia.
    By 1999, and arguably much earlier, the IT development world had recognised the limitations of the client/server model and the fact that Web-based systems addressed these problems. However, due to the complexity of ERP systems, and the inertia that brings, Peoplesoft was only starting to develop Web-based versions of their product at the time of CQU’s ERP implementation. In addition, the complexity of implementing the ERP at CQU means that there must be a long period of use of the client/server system in order to recoup costs before migration to Peoplesoft’s web version.
  • Organisational holes.
    CQU currently does not have a central database that tracks which staff are teaching which courses. Parts of CQU (e.g. Infocom) and some of CQU’s commercial campuses, have filled this hole.
  • Developer/User distance.

    There exists a large geographic and organisational distance between the users and the developers of the CQU system. This means that it is very difficult for the developers to develop a true understanding of how their system is being used and whether or not there are problems to fix. This distance has been increased by the negative feelings amongst CQU staff about the ERP implementation and the resulting defensiveness of the staff involved in the implementation and support of the CQU ERP system.

  • Organisational inertia through band-aid solutions.
    It was obvious to most CQU staff that there wasn’t going to be any quick solution to the problems discussed above. As a result CQU staff developed alternate methods for solving these problems. Infocom developed intermediary information systems. Other sections of CQU allocated support staff the task of retrieving data from the student records system in response to organisational needs. Once these workarounds began to function they were accepted as part of normal operation and feedback to the developers of the CQU system declined. This has led to the situation where the developers believe that there are limited problems with the system and thus the chances of future improvement are further reduced.

Personal Timetable


At the start of each term both staff and students need to generate a personal timetable which indicates the time and place of each of their classes.

CQU System

Due to differences in CQU’s organisational structure there is no single CQU timetabling system. The timetable for CQU’s Central Queensland based campuses is currently managed using a commercial timetabling package. The timetable at CQU’s commercial campuses in Sydney and Melbourne use a locally produced Web application based on Access databases. CQU’s other commercial campuses, Brisbane, the Gold Coast and Fiji, along with its commercial partners in Singapore and Hong Kong use other locally specific methods, often based on Excel spreadsheets.

The Sydney and Melbourne campuses make timetabling data available via a simple web-based application that allows students to select individual courses and view the time, place and staff member involved.

Timetabling information at CQU’s Central Queensland campuses is made available as static HTML pages ( divided by campus and then by faculty. The web page for each faculty at each campus lists the details of all the classes for all the courses offered by that faculty at that campus in the given term. To generate a personal timetable it is necessary to know which faculty owns the course, navigate to the appropriate page, manually search amongst all of the courses for those of interest and manually transpose that to a personal form. The pages are also printed out and placed onto noticeboards by the various faculties. Many students make special trips out to the campus before the start of term to gather timetable details.

Problems with the CQU systems include:

  • No single source.
    Depending on their mode of study students must know to go to different places.
  • No integration with student records.
    So the system has no knowledge of each student’s enrolment details and thus can’t provide a personal timetable. Instead the student is forced into a manual process.
  • Absence of teaching responsibilities database.
    As mentioned above there is no central database which tracks which staff teach which course. Even if one were present the current CQ timetabling commercial system would be unable to use that data to generate a personal timetable for staff.
  • Requirement for additional knowledge.

    Many students, especially first years, do not understand the notion of faculties let alone know which faculty owns a specific course. The current CQ system requires students to know this information in order for them to generate their timetable.

  • Time consuming.
    The manual search and transpose steps make this process quite time consuming and error prone.

Infocom System

The Infocom timetable generator ( provides two different methods for generating a personal timetable.

  1. Manual Selection.
    After choosing their campus users can select courses from the list of courses at that campus and hit submit to see a weekly timetable.
  2. Automatic Selection.
    Selecting the link “Generate My Timetable” and entering their username and password will show staff or students a personalised timetable based on the enrolment or teaching responsibilities.

The Infocom system can generate timetables for students at all of CQU’s Central Queensland campuses and CQU’s Sydney and Melbourne campuses. It does this by extracting the data from the web pages and databases of these other systems, placing them into a single database and combining them with data in CQU’s student records system and Infocom’s teaching responsibilities database.

The Infocom Timetable Generator was first made available in 2001 and supported only the Rockhampton campus and manual selection of courses. The system was used over 3000 times in 2001. In 2002, due to workloads and changes in data formats used by the central timetabling pages the system was not actively supported. It was used 321 times. Support for all campuses and the automatic selection method was implemented in mid-2003. It has been used over 1500+ times up until July 27, 2003.

Sources of the Gap

Contributing factors to the gap between the CQU system and the requirements of the clients include:

  • Mismatch between system owner and users.
    The system owner of the CQ timetabling system is CQU’s student administration division. Their major timetabling role is managing the allocation of space and time. Distributing this information to staff and students is a secondary smaller task of less importance. As a result the choice and use of the supporting information system is driven more by the requirements of the management role than the distribution role.
  • Organisational Silos.
    Contrary to CQU’s “one University” approach there is significant distance between CQU’s commercial and CQ campuses. There is even distance between the two largest commercial campuses, Sydney and Melbourne, and their smaller cousins at Brisbane and the Gold Coast.
  • Organisational Holes.
    There is no central software developer allocated to helping support divisions like student adminstration support and implement systems like timetabling (unless they hire their own). Instead most rely solely on the features of commercial packages that are known for their inability to integrate with other systems..
  • “Bad” technology.

    The software used on the CQ campuses is not designed to integrate with other software and offers limited support for the distribution of timetabling information. The system used at the commercial campuses is based on infrastructure that does not scale well.

Minimal Course Presence


Students, both potential and current, spend time looking for information about the courses offered by an institution. Traditionally this has been through marketing brochures and handbooks. With the advent of the web many students seek this information through course websites. A minimal course web presence for all courses allows students to seek information about courses they may wish to undertake. To be of significant use such a minimal course presence has to be available as early as possible and contain as much information as possible. The Infocom minimal course presence also serves as the foundation on which more complex and specific online teaching activities activities is constructed. This includes support for both student learning and course management tasks.

CQU System

CQU, like many other Universities, has adopted commercial course management systems (CMS) to enable and support the provision of online teaching and learning. CQU’s history with CMSes includes a trial with Topclass, adoption and use of WebCT (1999-2003) and the adoption and use of Blackboard (2004-).

CMSes are designed and generally used by individual or small teams of academics and support staff developing individual courses in isolation of others. CMSes are generally not designed or used to support the automated generation of a minimal course presence for all courses. For example, towards the end of 2003 there were 141 existing WebCT courses that were to be converted to Blackboard. During 2003 CQU offered close to 1000 courses. Just over 10% of CQU courses had a course website.

For sometime two of CQUs faculties, Business and Law and Infocom (, have offered a minimal course presence for their courses. Since late 2002 there have been discussions at various CQU committees and working groups about the need for a minimal course presence for all CQU courses. There has been no visible progress.

Infocom System

Infocom has provided a minimal course presence and supported online teaching and learning since 1997 using its locally produced system, Webfuse (Jones and Buchanan 1996; Jones 1999). Webfuse is a term used to describe the technology and processes underlying all of the Infocom web team’s development. Webfuse was originally developed specifically for the support of online teaching and learning but has since incorporated a range of features beyond that original scope.

In mid-2001 the Infocom minimal course presence was significantly expanded due to previous experience and the adoption of Peoplesoft. The current minimal course presence draws on information from a range of sources including: CQU’s student records database, CQU’s online handbook, bookshop databases, databases from CQU’s commercial partners, course profiles and a range of Infocom databases.

The minimal course presence is generated by an information systems that is given the term and year and automatically generates the minimal course presence for all courses offered in that term. The minimal course presence is initially created a number of months before the start of term and slowly upgraded as additional information about courses is made available. For example, course profile documents usually become available at specific times prior to the start of term. As they become available the minimal course presence is updated to include links to the course profiles.

From mid-2001 to mid-2003 the minimal course presence used a consistent structure and appearance ( In mid-2003 support was added to allow the customisation of the structure and appearance of a minimal course site ( However, there is still a core set of features and content that are required of a minimal course site.

Teaching staff are able to extend the minimal course presence through a range of tools operating within the minimal course sites or they can create and maintain a completely different course website using a technology of their choice. These “real course sites” are linked to from the minimal course presence. Of the staff who chose to move outside of the minimal course presence a small number use CQU’s central CMS (WebCT or Blackboard) while most (usually staff teaching in Infocom’s multimedia degree) generate their own course website using their favourite web development tool.

Table 4 provides a summary of course site usage since 2001 including the total number of minimal course sites and the number of real course sites. Requests indicate the number of web requests made of the course sites, both minimal and real, in that year. Updates indicate the number of times a staff member has updated one of the pages on a minimal course site. Staff indicates the number of different staff who have performed the updates. Users indicate the number of users who have logged into the minimal course sites. It should be noted that by default a login is required for only a small part of each minimal course site.




Course Sites


















Table 4 – Usage figures for Infocom default course web sites
* Till July 27

Sources of the Gap

Contributing factors to the gap between the CQU system and the requirements of the clients include:

  • Differing requirements.
    At CQU, the use of CMSes is generally driven by academic and support staff who are primarily interested in tailoring the use of online teaching and learning to the specific needs of individual courses for the term the course is offered. The requirement for a minimal course web presence is to provide a fairly consistent, guaranteed minimum course website for all courses as early before the start of term as possible.
  • Organisational silos.
    The information used to construct the Infocom minimal course presence comes from a huge range of different parts of the organization. Gaining access to that data has been a difficult, time-consuming, and as yet, unfinished task. Success in this task has often owed more to ad hoc, personal contacts than official University structure and committees.
  • Organisational holes.

    Responsibility for implementing a minimal course presence doesn’t really fit well within the existing CQU structures. Courses belong to faculties and are delivered by academics who have significant freedom with how they perform this task. The responsibility for assisting with online delivery is primarily the role of the Division of Teaching and Learning Services (DTLS). DTLS is set up to respond to requests for assistance from individual academic staff rather than generate websites for all courses. Most faculties do not have the resources to generate a minimal course presence. Most academics are more interested in their individual courses than having a minimal default approach.

Informal Review of Grades


The release of final course results invariably generates anguish and questions amongst students who are unhappy with their results. Within Infocom these students can request an informal review of grade (IROG). An IROG usually involves the course coordinator performing an additional check of the result, changing the grade if necessary or providing additional information to the student about their result. In the two main terms of 2002 (Autumn and Winter) Infocom processed 809 requests for an IROG.

CQU System

The traditional CQU system for handling IROG requests is a paper-based process. With CQU’s geographically dispersed, multi-campus operation this can be somewhat problematic. For example, a student at the Melbourne campus will visit a staff member to discuss a result. If the student is still unhappy a form is filled out expressing the student’s concern. The form is then sent, either by fax or post, to CQU’s Rockhampton campus. At this stage Infocom support staff forward the form onto the appropriate academic staff member who may be at another of CQU’s campuses. On receiving the request the academic staff member considers the request and responds by filling out the form and returning the form. At this stage the form reverses it journey until it finally reaches the Melbourne campus staff member who contacts the student.

As a largely manual process this process is slow and prone to human error. This creates further disquiet for an often already anxious student.

The Infocom System

In July 2003, three weeks before IROGs would commence for CQU’s first major term in 2003, Teaching and Learning support staff approached the Infocom web team with interest in developing a web-based process for handling IROG requests for CQU’s autumn term from CQU’s commercial campuses. The following Infocom IROG system was designed, implemented and tested within the 3 week period and was available on time.

The online IROG process starts with a student visiting a staff member at a commercial campus to discuss their results. If the student is still unhappy after this discussion an IROG request is generated. To do this the staff member: logs into MyInfocom, enters the student number, views the student’s enrolment details, clicks the “Request IROG” link for the appropriate course, fills in the web-based form and hits the submit button.

When the IROG request form is submitted an email is sent to the academic staff member(s) responsible for this course and also to the IROG support team. The IROG support term receive copies of the emails so they can observe the process and take steps if there are problems. The email includes the detail of the IROG request and a link to a web page that academic staff can use to respond to the request. Responding to a request involves: clicking on the link, reading the request, choosing whether there grade stands or a new grade is awarded, filling out a rationale for the response and submitting the form.

When the form is submitted an email is sent to both the staff member who originally requested the IROG and the IROG support team. The email includes a link to a web page that details the response. The commercial campus staff member will click on the link, view the response, click on a “student version” link, print out the student version and provide it to the student. The student version of the response includes the student’s postal address so that it can be easily printed, placed in envelopes and mailed.

Commercial campus staff, academic staff and the IROG support team all have access to web pages that summarise the details of all the IROG requests that are of interest. Commercial campus staff can view all the IROGs for their campus. Academic staff can view the IROGs for the course offerings for which they are responsible and the IROG support team can view all the IROGs.

Table 5 provides a usage summary of the IROG system from mid July to early September, 2003.

Statistic Value

IROG Requests








No Response


Grade Stands


New Grade Awarded


Minimum Turnaround

0 days

Average Turnaround

3.6 days

Maximum Turnaround

28 days

Table 5 – Usage figures Infocom IROG system for T2/2003

Sources of the Gap

Contributing factors to the gap between the CQU system and the requirements of the clients include:

  • Organisational Hole.
    CQU’s student record system is designed primarily to serve the needs of CQU’s student administration support division. This division is mainly interested in what happens to students at the beginning (getting them enrolled, making sure they pay their money etc) and the end of a term (getting their final grade). There is little or no support for what happens during a term. IROGs are an example of a requirement that slips through the hole.
  • Developer/user distance.
    The IROG support team within Infocom were responsible for identifying the original need for a web-based IROG process. The organisational distance between that IROG support team and the developers of CQU’s ERP system is quite large (the geographic distance is one floor). The developers were not aware of this requirement. Making them aware would have required: raising the issue at a users group, waiting for the issue to become important enough to be scheduled, having a functional analyst being the requirements gathering process, have a developer scope the requirements, wait for a decision as to whether or not it was feasible, have it implemented, probably as a trial process.
  • “Bad” technology.
    In this context the technology used by CQU’s ERP developers does not offer a good match for this requirement. The technology is difficult to use (e.g. generating a course list example above), not web-based and is closely tied to existing business processes which do not include support for the IROG process.
  • Missing pre-requisites.

    The Infocom IROG system built on the existing MyInfocom structure and more importantly the familiarity of staff with that system. MyInfocom was a pre-requisite for this development and a similar system is not available to the rest of CQU.

How was it done

To succeed and add value to an organization it is believed that the development methodology use for its information systems must match the requirements of the organization. However, the aims and assumptions of traditional information systems development methodologies, the production of systems with long periods of stable operation, are ill suited to an emergent organization and will create long term problems (Jones 2000).

Underlying the approach described here is a belief that a modern Australian University is, or at least needs to be, an emergent organization. In emergent organizations, every feature of the organization, culture, meaning, social relationships, decision processes and so on, are continually changing as a product of constant social negotiation and consensus building (Truex and Klein 1999). The rapid development of technology and global markets contributes to a need for constant change where organizations are no longer stable and must continuously adapt to their shifting environments (Truex and Klein 1999). In Australian Higher Education the shifting environment is contributed to by such factors as changes in government policy, increasing commercial pressure, changing nature of knowledge and disciplines and changing client needs.

Many of the staff employed at Universities (e.g. academics, instructional designers, technical staff and managers) are knowledge workers with a considerable amount of autonomy. The commitment and motivation of these individuals are a critical success factor in the implementation of any information system. These staff can and will resist the imposition of new technology and changes to routine. Additionally, the existing organizational structures within which these staff operate can hinder convergent development (Jones, Stewart et al. 1999).

The information systems developed by the Infocom web team are implemented within a platform that goes by the label Webfuse (Jones and Buchanan 1996; McCormack and Jones 1997; Jones 1999). Webfuse began life in 1996 as a tool to aid solely in the delivery of web-based teaching and learning. In the time since then it has evolved into a collection of technologies used to deliver the collection of web-based information systems described above.

A brief technical overview of the components and characteristics of Webfuse include:

  • Apache web server (
    Apache continues to be used primarily because of the ability to modify the
    operation of Apache using Perl.
  • Perl programming language (
    Initially chosen because it was one of the few general purpose web development languages Perl continues to be used because of its extremely flexible nature and CPAN ( CPAN is a central repository which is used to distribute the large amount of freely available software contributed by Perl programmers through out the world.
  • Various external information systems and software.
    Webfuse is intended to be, where possible, a wrapper around existing information systems. The Infocom Timetable Generator described above wraps around CQU’s existing timetable information systems. The web-based discussion forum provided by Webfuse wraps around YaBB, an open-source discussion forum. Where possible we do not write software.
  • A consistent development metaphor.

    A frequent criticism of Perl is the variety and freedom the language provides. A fundamental tenet of the Perl ethos is TIMTOWTDI: There Is More Than One Way To Do It. This can cause problems with teams of developers doing it all their own way. Webfuse has a consistent metaphor for development of web-based applications that is used by all developers.

  • Over 570 classes.
    Webfuse uses an object-oriented development approach and consequently since 1996 we have developed over 570 separate classes to provide higher level services. Most of these services are CQU specific. For example, the following code excerpt will retrieve a list of all the Infocom courses offered in a particular term along with the number of students in those courses.

       use strict;
       use Webfuse::lib::People::InfocomCourses;
       my $courses = People::InfocomCourses->new(
                  PERIOD => "T2", YEAR => 2003 );
  • A disciplined development methodology.
    An emphasis on code reuse, flexibility, closeness to the user, a test-driven coding style and various other practices provides the foundation for a development methodology which allows agile development of information system.

A defining characteristic of the approach used within the Infocom web team has been its reliance on emergent or agile development practices. Some detail about how and why we have used agile development methodologies can be found in other publications (Jones 2000; Jones, Gregor et al. 2003; Jones, Lynch et al. 2003).


This paper has shown that it is fairly common for a gap to exist between the institutional information systems at Central Queensland Univeristy (CQU) and the needs of the students and staff of the Faculty of Informatics and Communication (Infocom). It has shown how the Infocom web team has developed a range of intermediary information systems to bridge that gap and offer significant advantage to Infocom. These intermediary information systems have not only allowed Infocom to live with its institutional systems they have enabled Infocom to thrive. The paper has briefly discussed the processes and technology used to develop these information systems.

The paper identified a range of issues that help create the gap between user needs and the functionality provide by institutional information systems. These include, but are not limited to: ‘bad’ technology, organizational holes, organizational silos, missing pre-requisites, developer/user distance, distance between system owner and users, a preference for band-aid solutions, and organizational and technological inertia. It is suggested that these factors are not unique to CQU and do exist in other Universities. As a result other Universities may find the Infocom approach interesting.


Davenport, T. H. (1998). “Putting the Enterprise into the Enterprise System.” Harvard Business Review 76(4): 121-131.

Esteves, J. and J. Pastor (2001). “Enterprise Resource Planning Systems Research: An Annotated Bibliography.” Communications of the Association for Information Systems 7(8).

Jones, D. (1999). Webfuse: An Integrated, Eclectic Web Authoring Tool. Proceedings of EdMedia’99, World Conference on Educational Multimedia, Hypermedia & Telecommunications, Seattle, Association for the Advancement of Computing in Education.

Jones, D. (2000). Emergent Development and the Virtual University. Learning’2000, Roanoke, Virginia.

Jones, D. and R. Buchanan (1996). The Design of an Integrated Online Learning Environment. Proceedings of ASCILITE’96, Adealiade.

Jones, D., S. Gregor, et al. (2003). An Information Systems Design Theory for Web-based Education. Submitted to WBE Syposium at CATE’2003.

Jones, D., T. Lynch, et al. (2003). Emergent Development of Web-based Education. Proceedings of Informing Science + IT Education, Pori, Finland.

Jones, D., S. Stewart, et al. (1999). Patterns: Using Proven Experience to Develop Online Learning. Proceedings of ASCILITE’99, Brisbane, QUT.

Mahaney, R. C. and A. L. Lederer (1999). Runaway information systems projects and escalating commitment. Special Interest Group on Computer Personnel Research Annual Conference, New Orleans, Lousiana, USA, ACM Press.

Markus, M. L., S. Axline, et al. (2001). Learning From Adopters’ Experiences with ERP: Problems Encountered and Success Achieved. Enterprise Systems: ERP Implementation and Effectiveness. Willcocks.

Markus, M. L. and C. Tanis (2000). The Enterprise Systems Experience — From Adoption to Success. Framing the Domains of IT Research: Glimpsing the Future Through the Past. R. W. Zmud. Cincinnati, OH, Pinnaflex Educational Resources: 173-207.

McCormack, C. and D. Jones (1997). Building a Web-Based Education System. New York, John Wiley & Sons.

Oliver, D. and C. Romm (2002). ERP Systems in Universities: Rationale Advanced for their Adoption. Enterprise Resource Planning: Global Opportunties and Challenges. L. Hossain, M. Rashid and J. D. Patrick, Idea Group Publishing.

Parr, A. and G. Shanks (2000). A Taxonomy of ERP Implementation Approaches. 33rd Hawaii International Conference on System Sciences (HICSS), Maui, Hawaii.

Standish Group (1995). The CHAOS report, The Standish Group International.

Truex, D. and B. Klein (1999). “Growing Systems in Emergent Organizations.” Communications of the ACM 42(8): 117-123.

Whittaker, B. (1999). “What went wrong? Unsuccessful information technology projects.” Information Management & Computer Security 7(1): 23-30.