Abstract

This paper considers the development of information systems within UK Universities, and the demands that this places on business process managers and computing professionals for staff development and training. The focus will be on the implementation of SCT’s integrated BANNER 2000 Student System at the University of Greenwich (UoG). The system is rules based and driven by end users. It empowers the process manager and removes overall control from the computing professionals. The project has highlighted the progression of technology, the need to reassess UoG’s business processes, information needs, and most significantly, human resource requirements and the way people work together.

Implementation issues

Having identified a replacement student system through a systematic and structured approach (see Appendix 1) the University then had to address a number of implementation issues:

Technical: delivering BANNER onto the individual desktop with Network and infrastructural support to optimise and deliver robust performance and in a structured fashion.

Political: variability in institutional and managerial commitment and "ownership" of the Project: a simplistic perception that BANNER will deliver the existing services the same, but faster.

Functional: additional gaps in functionality not previously identified found during evaluation and testing. Solutions were often reliant upon satisfactory conclusion to problems in other categories.

Cultural: a perception that the system is "forcing" change, rather than recognition that the introduction of any system requires organisational and process review. Furthermore, and critically, a lack of recognition by senior managers that the information systems are business critical: intrinsic to the management function and not simply automation tools. There has been a tendency for senior managers to divorce themselves from the information systems that support and deliver the functions for which they are responsible. With a rules-based system, where validation tables and rules are controlled by the end-users, this is no longer a viable approach. Functional/service managers will require a new breed of staff who are functional and technical "experts". These users will be responsible for managing the data infrastructure, coding, menus and workflows, etc.

Resources: institutional cutbacks on project budget and resources dedicated to implementation, both in people and hardware/software terms.

Staff Development and Training: an acute "Development and Training Paradox" was identified: the mapping of business processes from legacy systems to BANNER identified a major shortfall in skills requiring development and changes to roles and responsibilities. At one level managers recognised and accepted the logical outcome of this: that significant staff development and re-training of staff was required. Operationally however, managers (and everyday users) were reluctant to accept that such change requires effort in terms of time, people and facilities. The University had a poor history in delivering training and development in operational systems. BANNER highlighted the need for staff development which goes beyond simply "training".

A critical task for the Student Team was to apply their institutional knowledge to evaluate the product functionality within a University of Greenwich model and use its flexibility effectively. This ‘evaluation phase’ was an iterative process: proposals for management of a given business function using BANNER often had to be re-evaluated. The initial point of reference for the Team members was the University’s existing legacy system and consequential processes. However, over time the point of reference for analysis and proposal became BANNER. This enabled the development of a collective and individual ability to review University business processes in a more reflective and objective manner: to develop innovative and practical solutions divorced from cultural and historical constraints. For BANNER to be implemented effectively, this paradigm shift has to be achieved in the general user and staff environment through a ‘learning culture’. Training only was insufficient.

Organisational development: changing boundaries and roles: The move to a rules-based, user-led system turns the traditional relationship between the Computing Centre and the service departments on its head. Coding structures, validation tables and workflows are now the responsibility user departments, rather than the Computing Department. Furthermore, the business process rules are also user-defined. This requires different management skills and roles. The role of the Computing Department has shifted to one of technical enabler: ensuring effective network communications, technical infrastructure and database management are in place. Formal programming work has ceased to be the core function or raison d’être of the Computing Department. Computing Departments in such a relationship have to accept that they are a support department: in place to enable and support systems largely controlled in functionality by end-users. Desktop support and help-desk functions require a re-focusing on the softer "people" skills and a "customer" orientation.

Timescales: A relatively long development schedule reflected the order in which modules needed to be learnt, taking account of module relationships, practical numbers involved and the complexity of individual modules. For example, the creation of live data on the production database for courses and programmes structures, etc commenced in Feb1998, some 7 months in advance of registering the first students into BANNER. Most importantly, the timescale was designed to give sufficient time for users of the new system to make the mental shift required. This needed to be done for the University and users to allow proper process improvement and innovation, rather than simply automation of existing processes. This can be represented as an innovation curve.
 
 

Implementation methodology

The focus of discussion of the implementation methodology will be with the Student System, and in particular the staff development component for end users. This was identified as the most significant factor likely to influence success or failure. Appendix 2 gives an overview of the overall Project Management Structure and deliberative mechanisms.

Student Project Team structure and working methodology: The team comprises competent users of the legacy system who additionally have knowledge and experience of the University’s business processes. Staff were initially seconded on a voluntary pro rata basis providing a total of 3.3 full time equivalent members for the team. The Deputy Academic Registrar was assigned as the Student Team Leader on a 0.6 fte basis. It was agreed that the Team should meet regularly two days per week in a designated project location. Over the course of the implementation, the demands of the project have made it a fulltime commitment for the Project Team members.

After pure functional training from the product supplier (SCT) the Team were allocated six months to an Evaluation Phase. The purpose of this phase was to allow:

Familiarisation – navigation skills and understanding of principles and processes within the system.

Mapping of University Procedures – modelling University processes within the system.

Consultation with key University Staff – identifying any functional gaps.

Generation and Testing of Possible Solutions – Considering all the possible solutions

Basic Documentation of Solutions – Documenting solutions for audit and distribution.

Staff Development and Training approach:The first decision was that the scope of development and training should initially cover core users only. This was primarily Registry staff. Consultation with managers identified the training requirements of the staff involved and the commitment in terms of staff time/attendance. The Project Team undertook the initial core training. This ensured consistency of delivery and the development of functional experts within the Team available to support end users, and in whom they had confidence. The first assessment identified 119 staff requiring retraining and development. Staff Development sessions were divided into ‘chunks’, relevant to working structures and functions, so that staff could develop skills at an even pace. It was decided that their needed to be two levels of training:

Intermediate – designed for users needing to understand the principles of how a particular part of the system works, interrogation of data and how it interacts with other modules.

Advanced – designed for users requiring all the intermediate skills, but in addition needing to enter and manage the data in a particular part of the system.

The system was broken into 13 sections, each to be delivered as individual training sessions of differing length (see Appendix 3). A training suite was developed by the Student Project Team, in addition to a facility available on another campus. The provision of a dedicated training environment was considered essential to provide trainees with the opportunity to develop skills away from the pressures of the office environment and to focus solely on the training in hand.

Development and production of Training Materials: One of the problems highlighted with the University’s legacy system was the lack of user documentation and training provided to functional users. It was agreed therefore to adopt a formal, structured approach to development and training, with supporting materials, presented in a professional manner. This would assist in establishing the credibility of the system with end users. It also aided the decision-making process, forcing decisions to be made on UoG specific issues, so that they could be committed to print. Development of the training material followed an agreed protocol that outlined the design, structure and content requirements.

Two members of the team were assigned to produce each document, based on experience of current procedures used by the University that will effect the use of the module to be documented, and experience of the specific BANNER module. The production of the documentation was split into three phases:

Production - six working days were allocated to each document.

Review - one day was allocated to this task

Editing - four working days were allocated to complete the document with all amendments agreed at the review day and produce all the additional training materials for the session to be delivered.

At a Registry Staff Development Launch day, each trainee was provided with a training folder prior to commencing training. Trainees were to use this to build up a comprehensive personal resource folder detailing the use of the new system and relevant to their working tasks.

Delivery, content and monitoring: Two trainers were allocated to each session. One trainer generally led the session with the other facilitating and assisting the trainees as they progressed through the session exercises. The number of trainees was limited to a maximum of eleven per session, reflecting the available training space and allowing trainers to provide a more personalised training session.

The contents of the sessions were designed so that they were developmental in nature. Many trainees were experienced members of the University’s administration and it was important to allow these users to make comments on the methodologies demonstrated in the session. This was achieved by providing practical sessions with the opportunity to question the methods explained. Feedback was requested from each trainee at the end of the session in the form of an evaluation questionnaire. This was used to enhance further sessions and enable the team to constantly critically evaluate the training provided. The trainers were also required to analyse their own performance and highlight any important issues (technical, functional, procedural, policy) by completing a trainer’s feedback form.

General awareness: In addition, to the structured development and training, it was essential to ensure that the new system did not become the property of the one department (Registry) that was developing it. A series of presentations to University Management Groups (Academic and Administrative) as well as all School Staff meetings was agreed and delivered.

The critical survival factors: what has the University learned?

Remember that people are your most valuable (and volatile) resource. Use your enthusiasts. Do not allocate team members on hierarchy, or existing organisational structures. Use the best people you have, from wherever they come within the organisation and at whatever grade.

Train the functional implementation team in the formal functionality of the system, then let them play with it in a structured way to test its potential in the context of your organisation, its structures and processes. Do this away from the normal working environment, together and in as free a fashion as possible.

Spread the awareness of the system as far and as wide as possible across the organisation via a "roadshow" approach: deliver presentations to deliberative committees, departmental and school management groups, etc. Target the staff who are influential and have a stake in making the system work. Consider if you were they, the question, "what is in it for me?" Place your presentations in this context.

Develop a formal training plan and development strategy, based on at least 25% of your functional implementation effort. Ensure a structured approach and common protocol exists for the delivery of the development/training: make the trainees feel special, and that they are engaged in something "different". Formalise attendance at, and feedback from, the training/development sessions. Make sure line managers know that staff will be invited and expected to attend; invite attendees individually, well in advance. Use the training/development strategy as a means of identifying requirements and generating solutions. Treat user sessions as development sessions rather than ‘training by rote’ sessions. ‘Enable’ the users to understand what can be different and lose the blinkers associated with their current ways of doing.

Cultivate a learning culture: staff need to change their mindset and recognise that in a rules-based system they have the power to change things. The skills they require to operate the system will be related to problem-solving and an understanding of the organisation and its processes, not just technical aptitude.

Manage expectations: senior management are likely to have unrealistic expectations of what can and cannot be achieved. Use training/development sessions and the roadshow to highlight the critical scope of the implementation, but with a view to the future and the medium/long term benefits. Focus on the critical processes and solutions to be delivered: business survival comes first and foremost and the project implementation team must take a corporate stance.

Be proactive in mainstreaming system ownership: People need to know who is leading the Project implementation. However, it is important to target small groups or enthusiastic key individuals to take on the development of data entry standards and/or rules protocols. Make the users make a choice.

Achieve empathy between your technical community and your functional user community: invite technical project development staff to functional training sessions so that they can gain a user context and conversely, make functional users aware of the technical scope in terms they can understand. Have regular cross-team meetings: share the pressures that are restricting or influencing your respective teams.

Pay attention to your project team morale: what motivates the team members? Can you reward them directly (financially) or indirectly (study release, working environment, future prospects)? Plan a contingency for loss of project team members.

Start with a consensus strategy: ideally, you should work in agreement with managers of staff on whom you will have to call for training/expertise. However, managers often want to know what the project implementation plans are, but are unwilling to ‘buy into’ practical support when it impacts on their area of work. Use the relevant management fora and communications to at least make sure people are aware of what is planned – then press on ahead and ‘do it’. Do not be deterred by either no feedback or negative feedback to these plans. Push it as far as you can until someone says ‘no’. This forces the institution to address priorities and make decisions.

Allocate a reasonable amount of your project management time to the political and communication areas: Senior management will expect and require regular progress reports with empirical data. The process of generating these can be a necessary precursor to understanding that you cannot meet the necessary objectives within the desired timescales! However, Senior management will want this form of ‘proof’.

Start people thinking as early as possible about radical change: introduce new technology and the possibility of changes to staff roles and responsibilities up front. Get the culture shock over with early and without engaging in wholesale process re-engineering, consider adapting your structures and/or processes.

Always have at the forefront of your mind the question "is this a system problem or a people/policy/ procedural issue"? Over 50% of the time, the problems raised by staff in relation to the new system will be tied in to organisational problems or lack of clarity/boundaries on particular functions/processes.

As part of the implementation process, develop a strategy for the future maintenance of the system: Make this transparent and move to get it in place before "going live" At Greenwich the future maintenance issues are represented in the diagram below.
 
 

Pick some winners: identify "high visibility" areas where benefits can be demonstrated even if this is only on a trial or pilot basis (at Greenwich, it is planned to pilot management of schedule and timetable information on one of the University’s major campuses).

Functional Managers need to understand (and commit to) the concept that information systems are fundamental to their service delivery: i.e. they are not simply means to simply speed up processes, they are methodologies and tools to fundamentally change such processes. The successful managers and services will be those that embrace effectively the use of their organisational information systems.

Conclusion

During the course of our implementation at Greenwich, we have learned that you need to have a formalised staff development strategy for staff related to business systems (rather than just computing skills). As systems move to form the core tool for delivery of administrative services, particularly in institutions which operate a complex curriculum, you need to consider the skills and roles associated with staff. A focus on students as clients with a direct financial stake in services necessitates greater speed, accuracy and transparency of information. This affects your staff recruitment strategy. Staff need to be developed to manage new tasks based on a different set of competencies and skills. For example, which users control functional rules and/or data items that have an institution-wide impact? Managerial accountability will be key as service managers are increasingly reliant on the information systems for the basic core delivery of their services. Thus wider understanding of systems functionality and the rules-base will be a necessary skill for such managers to manage their staff and perform effectively. Such a staff development model must be ongoing, high profile and supported at a corporate level.

Purchase of an integrated system has forced Greenwich to recognise and deal with organisational (artificial) boundaries, since processes and workflows do not respect these. The management of a rules-based system requires us to re-evaluate the relationship between central infrastructure and support and user departments. Technical and functional divisions will blur as the user departments are required to develop a breed of "technical generalists": hybrid staff who have good technical and functional knowledge, but which can be applied in a business process context.
 
 

University of Greenwich, Woolwich Campus, Riverside House, Woolwich, London, SE18 6BU

Email: a.d.higgins@gre.ac.uk, s.l.casey@gre.ac.uk
 
 

Appendix 1

The need to change

The University’s legacy student administrative system was a bespoke system built on a non-standard hardware and software. It had become increasingly difficult to maintain and/or develop this system to match the University’s business requirements. Technical staff with the required skills were difficult to find and had no incentive to move on as their skills were not marketable. The system offered inadequate functionality, security and access, having been developed without a long term design strategy. There was very limited strategic potential: WEB or voice response access options did not exist without wholesale investment and advances in PC operating environments were a major challenge for technical support staff. The development of a University Information Strategy in 1995 further highlighted the system’s inadequacies and the need for a replacement. Furthermore, the legacy system was non-2000 compliant.

The University of Greenwich adopted certain strategic principles to inform its tender exercise and purchase decision for replacement systems for Students and Finance administrative systems:

Supplier viability: the supplier would need to demonstrate investment in research and development, with a technical/management infrastructure able to support the product and University into the future.

"Out of the box" product functionality was not as important as the ability of the supplier and/or University to fill effectively, identified gaps in functionality.

Integration. An integrated solution was sought to remove the necessity for ad hoc databases and subsidiary systems within the University.

Leading edge technology: The successful supplier needed to demonstrate an awareness of new technologies, and evidence of accommodating IT/IS developments into product development.

ORACLE-based solution: the University had agreed that the successful product would be based on ORACLE as the worldwide industry standard platform.

Flexible functionality: the system should be rules-based with the emphasis on empowering end-users in the development and management of such rules.

Auditability: none-destructive update of data with transactions date/time stamped was a requirement.

Value for money. The initial and ongoing product cost was to be taken into account.

Proven track record. A history of successful product delivery and support to educational institutions.

Strategic vision. Where had the supplier forecast the product would be five years previously (and had the product met these forecasts) and what was the product forecast for five years in the future? The successful product would be one which would take the University through the next decade.

After a Tender exercise through the European Journal, the University agreed a list of nine potential suppliers. Using the above criteria, this list was reduced to four suppliers. After detailed product evaluation and demonstrations to end users by all four suppliers, the University arrived at a choice of two potential providers. Reference site visits and further detailed discussions resulted in a decision to purchase the BANNER Student System from Systems and Computer Technology (SCT).
 

Appendix 2

Overall Project Structure and Deliberative Mechanisms
 

Appendix 3: Staff development and training data

Session Name	Total Trainees	Number of Advanced Trainees	Number of Intermediate Trainees
Academic History		71	52
Admissions		47	45
Assessments		55	45
Class Schedule		95	24
Course Catalogue		63	54
Curriculum Advising and Planning		35	57
General Person		119
HESA (Government Reporting)		12
Navigation		119
Recruiting		31	7
Registration		65	54
Reporting		68	51
Student Accounts Receivable		42	12
Total person Training Days	1225