DEVELOPING AN IT MASTERPLAN: THE IMPLICATIONS FOR
LOCAL SYSTEMS DEVELOPMENT
Robert Moreton, Phil Range and Jane Caddick
School of Computing & IT, University of Wolverhampton, Wolverhampton, WV1 1SB, UK
Keywords: Local systems development, IS masterplan.
Abstract: The paper reviews the issues of developing a policy for local systems development and how this policy
impacts the corporate IS masterplan. The key elements of the policy are presented and the benefits that this
‘light touch’ approach can engender are presented. The process recognises that there needs to be some level
of knowledge and management of such systems by the central IS/IT service although functionally and
operationally they ‘sit outside’ formal IS management structures.
1 INTRODUCTION
In 2005 the university of Wolverhampton
established a Steering Group to undertake work to
create a Masterplan for Business, Learning and
Information Systems (BLIS). This was in response
to a discussion paper from the Director of IT
Services and followed completion of a series of
Business process modernisation projects. The
discussions involved managers of all the major units
in the institution (academic schools and service
departments, university executive). This agreement
recognised the limitations of the existing approach to
the development of processes and systems within the
University. There are many processes and systems
that need attention and rationalisation and typically
these have implications beyond a single department
and require a variety of cross-University skills and
resources. Many of the issues have a parallel with
buildings projects and it was accepted that adopting
a similar structure and process to that adopted for the
university’s major building programme would help
the University to understand and prioritise its work
on Business, Learning and Information Systems.
The BLIS Steering Group was formed with a
balanced membership from the senior management
team, plus working members from IT Services and
the Project Office.
Through an extensive interviewing process, BLIS
working members gathered information about
systems currently in place, work in progress and
requirements not currently satisfied by systems. This
will continue to be an ongoing process. In
particular, whilst the Deans of School on the
Steering Group have helped to identify issues with
systems within Schools, it has not been possible with
the resources available to carry out extensive
interviewing with Schools and further effort will be
expended to comprehend the ‘ever-changing’
picture.
Over 100 systems have been identified and
documented to date (March 2007). Approximately
half of these are unsupported or supported by the
owner. One-third are commercial packages with the
remaining two-thirds comprising in-house systems
using tools such as Microsoft Access, Excel
spreadsheets and paper forms. The team found that
some critical business functions are well supported
by systems and some inadequately supported. Data
is frequently duplicated and different versions of the
same data may be in existence at any one time.
In producing the Masterplan, it is recognised that
creating structures and categories around systems is
not an exact science and that there is a degree of
fluidity around it. Common sense is applied
throughout to bring a degree of sense and structure
to a large and complex picture.
As part of the initial work to create a Masterplan for
Business, Learning and Information Systems, the
University carried out a brief survey of systems in
375
Moreton R., Range P. and Caddick J. (2007).
DEVELOPING AN IT MASTERPLAN: THE IMPLICATIONS FOR LOCAL SYSTEMS DEVELOPMENT.
In Proceedings of the Ninth International Conference on Enterprise Information Systems, pages 375-379
Copyright
c
 SciTePress

use in all schools and departments across the
institution. This identified a large number of locally
developed or purchased (IT) systems in use. The
process recognises that there needed to be some
level of knowledge and light-touch management of
such systems, which ‘sit outside’ formal
management structures.
The paper reviews the issues of developing a
policy for local systems development and how this
policy impacts the corporate IS masterplan.
– For purposes of the planning exercise, a local
system was defined as having the following
features:
– Is largely independent of other systems and
processes
– Has no significant data dependencies on other
systems
– Is entirely managed and used by a group of staff
within one section of the University.
2 PROS AND CONS OF
APPROACH
Every organisation or business has a set of activities
and associated data that are vital to its existence.
For the sake of simplicity we will refer to these as
critical business areas. Some are common to most
organisations, examples being managing financial
transactions and employing staff. Others will be
specific to the core business of the organisation. For
example, a distribution company will include in its
focus activities relating to customers, stock, order
processing and deliveries; a charity will have
activities relating to communicating with supporters,
money-raising and managing implementation
programmes. Organisations need to have systems in
place to deliver these critical business functions and
to manage the data that is created and used.
The systems and requirements identified in the
University have been themed to arrive at six of these
critical business areas:
– Students and courses
– Academic resources
– External activity
– Physical assets
– Money
– People
These elements broadly reflect different models
of the University – its student lifecycle, educational
offering, external activity, physical, financial,
organisational (human resources). Three are specific
to delivering the educational mission of the
University and three are concerned with managing
the assets of the University to deliver this mission
and ensuring that legislative requirements are met.
2.1 Primary Systems
Every core business activity requires systems to
support it. There will usually be one or more
primary system. Primary systems have the
following characteristics:
– Are used to capture and maintain the critical core
data that drives each core business activity (see
below for further explanation of core data).
– Provide the majority of the functionality to
deliver the core business activity.
– Are used and referred to by significant numbers
of users.
– Represent major investments for the University
to meet its strategic needs and require
considerable investment of resource to
implement.
– Link to other systems and processes within their
own core business area and with other core
business areas.
– Link to external systems such as the
Universities’ Admissions System (UCAS).
– Are used to produce mandatory returns, such as
HESA student and staff returns, and meet
legislative requirements such as production of
accounts, responses to Data Protection requests
etc.
– Are the main repositories of core data for
internal reporting and management.
Primary systems are the cornerstones of the
University’s BLIS provision and therefore merit the
application of a high degree of control over their
selection and implementation. They should be
subject to a formal review and possible replacement
cycle in the region of 10 years.
2.2 Core Data
The concept of core data source is a very important
one and is best illustrated by an example. The
primary system for the ‘Students and Courses’ area
is SITS. SITS is the original source of information
about a student and the data on SITS is used to
ICEIS 2007 - International Conference on Enterprise Information Systems
376

provide mandatory returns such as required by the
UK Funding Agency (HEFCE). It must therefore
hold complete and accurate data about students.
SITS is where you go to find out the status of a
student, the course they are enrolled on, their contact
details etc. Other systems may use this information
but the critical data about a student should not be
created or changed anywhere else unless it is
guaranteed to be in line with that held on SITS.
2.3 Major Systems
– Primary systems do not meet all the
requirements for delivering the University’s core
business and are complemented by major
systems.
– Major systems have one or more of the
following features:
– Have a strong relationship with the core data
held within critical business areas, for example a
system that uses data originating in one or more
primary systems. Timetabling is a case in point
as it combines data about students, staff and
rooms to build a timetable.
– Contribute significantly to the delivery of the
University’s core business. Examples are the
Accommodation system, Conferencing
(currently a manual system) and Student
Enabling Centre database.
– Have an impact not confined to one section of
the University. For example the Access to
Learning Funds database in Marketing needs to
connect with processes in Registry and Finance.
The important factor is that major systems do not
exist in a vacuum and therefore require a level of
control to be exercised over them. For example, it
would not be sensible to implement a timetabling
system that operated in isolation from the existing
systems, processes and data in Registry, Schools and
Facilities, neither would it be sensible to have
multiple timetabling systems.
2.4 Internal Systems
These are systems that are largely independent of
other systems and processes, with no significant data
dependencies. They are entirely managed within one
section of the University. Examples are the Postal
Franking system and the IT Services Facilities Loan
System.
It is acknowledged, however, that some Internal
Systems have been developed as “stop-gaps” where
existing systems have not provided, or not been
perceived to provide, some required functionality
and there has not been time or resource to develop a
corporate solution. An example is the
“Broker/Agents” Database in the International
Office.
As a result this major review of its systems and
their operational and strategic impact, the following
advantages and disadvantages of allowing local
development of internal systems were identified.
2.4.1 Advantages
–
Allows for more efficient or effective operation
of institutional units.
– Can ‘fill gaps’ in corporate systems and provide
useful information on future improvements to
such systems.
2.4.2 Disadvantages
–
Can divert staff from working on ‘Corporate’
priorities.
– Become local replacements for corporate
systems with a consequent danger of conflicting
information etc.
– Can become an inhibitor to changes in the IT
infrastructure. For example systems written in an
old version of Access may need rewriting for a
newer version.
– Can often be critically dependent on a member
of staff who has written the system, with
consequent problems when that person is
unavailable or leaves the University.
– The quality of systems is very variable. For
example due consideration may not be given to
system design or accessibility issues.
– Costs are often unclear. Typically no kind of
cost-benefit analysis is undertaken.
– Issues relating to data protection and data
security are often overlooked.
3 OPTION APPRAISAL
Given these pros and cons a number of options were
evaluated to determine the approach which would be
most beneficial to the university.
3.1 Do Not Allow Any Internal Systems
The positives are:
– No unplanned additional work for IT Services
– Concentrate on University priorities
– No contention with corporate systems.
DEVELOPING AN IT MASTERPLAN: THE IMPLICATIONS FOR LOCAL SYSTEMS DEVELOPMENT
377

But the negatives are:
– Individual staff become increasingly frustrated
by some aspects of corporate systems
– Local systems will happen anyway!
3.2 Allow Only Single User Systems
Making Use of Standard University
Software
The positives are:
– No unplanned additional work for ITS, but could
increase demand for staff development.
– Individual staff can improve their own working
practices.
But the negatives are:
– Staff misunderstand the difference between
having the skills to use software and being able
to design and support systems.
– Danger of duplication of core data.
– Danger that this will become an essential system
that has no proper support.
3.3 Allow Locally Developed (or
Purchased) Networked Systems
The positives are:
– A group of staff can improve their working
practices.
But the negatives are:
– Significantly more complicated to specific and
develop than single user system, with increased
risk of poor quality.
– May lead to the creation of duplicate data and
processes
– There is a high risk that this will become a
system on which people depend, but is not
properly supported.
– Will require some server space for which there
may be a cost. There will be consequent
implications for the IT infrastructure and ITS
support.
4 RESOURCING ISSUES
If either of the first two options are accepted as the
way forward, there is a potential decrease in IT
Services (ITS) demand as time will not be used to
advise on systems or set up servers etc.
If the third option is preferred, and needs ITS
input, this will reduce ITS staff time available to
corporate projects unless additional resources can be
provided which will need funding. Perhaps the users
should be asked to pay for this!
In all but the first option, there is a cost
associated with the work. Should there be a formal
process by which unit budget holders should
approve such work?
There is a further question here about use of
resources – if University staff members have the
time to do system development work, why can’t they
be used to accelerate existing priorities? This would
need an element of management and staff
development from IT Services, but the benefits
could outweigh the costs. This was tried in the early
stages of Business Process Modernisation work,
when a number of staff were trained to ‘do BPM’
and worked on a number of projects. Many of these
staff are still employed within the University, but it
is difficult to get their time to work on projects
outside their Service or School.
5 A POLICY ON LOCAL
SYSTEMS
Given the scale of the Masterplanning process,
clearly it is not possible to tackle all the
requirements identified at the same time. In
identifying and proposing recommendations for
projects, the BLIS Steering Group has been mindful
of the University’s strategic aims. This originally
includes reference to the Three Year Plan 2005/06 –
2007/8 and more recently the revised university
Strategic Plan for 2006-2012.
The BLIS Masterplan in seeks to prioritise system
development and integration across the University,
having due regard to affordability and strategic,
operational and infrastructure priorities.
Within the context of the masterplan, it was agreed
that:
– Local systems may be developed or purchased
where the issues of support have been addressed
and a clear understanding of the costs (including
IT costs) and benefits developed. This should be
via a simple business case which would be used
by the relevant budget holder to decide if the
proposed system should go ahead.
ICEIS 2007 - International Conference on Enterprise Information Systems
378

– All such systems should be notified centrally as
part of the information which supports the
Masterplanning process.
– Systems should be delivered and maintained by
local resources.
– Systems should use the current IT infrastructure.
– Systems should place no obligation on IT
Services time.
6 BENEFITS OF THIS
APPROACH
This ‘light touch’ approach delivers benefits in a
number of areas:
– The more that there is a central awareness of the
systems needs of staff within the University, the
more opportunity there is to incorporate these
needs into corporate solutions which have a
broader benefit.
– Saving of time, effort and cost of implementing
new systems where suitable systems may already
be available or planned.
– Opportunity to benefit from others’ knowledge
and experience.
– Assists budget management.
– Enables local needs to be met locally.
– Non-bureaucratic and does not prevent or delay
progress - helps you to do the things you would
have done anyway.
7 CONCLUSION
Through its IS masterplan, the University is seeking
to follow a sensible institution-wide approach to
systems and processes. The University is a complex
organisation with multiple systems, duplicate data,
patchy dataflows and inconsistent approaches to
return on investment in systems. In the past,
systems development and implementation has often
been approached locally and in isolation. The
masterplanning process has been put in place to start
to address this. However, there is much system-
related work going on, not all of which is yet within
the view of the central steering group.
This paper identifies the issues related to locally
developed systems and provides a recommended
way forward and identifies the benefits which can be
achieved by such a ‘light touch’ approach.
DEVELOPING AN IT MASTERPLAN: THE IMPLICATIONS FOR LOCAL SYSTEMS DEVELOPMENT
379