The Use of Consortia in the Development of Information Systems .
Gray Southon and Phil. Yetton
Fujitsu Centre for the Management of Information Technology in Organisations
Australian Graduate School of Management
UNSW
The development of software is often a very difficult process, and there
are many examples of systems that have been carefully designed, yet fail
to provide any value to the organisation. One of the most difficult
aspects of development is the involvement of the user.
This talk addresses the situation in which there are a number of users
with similar needs, but working largely independently in different
locations. This is an important problem in the health industry, as there
is often unnecessary fragmentation and duplication of effort amongst such
users.
Let us look at the ways systems are normally developed. In the traditional
method the developer starts by obtaining all the requirements from the
users, and formalising the structure using data flow diagrams and similar
processes.
When there is agreement of the final requirements with the users, the
development begins. In providing their requirements, however, users are
put in the position of having to imagine what their requirements would be
in a new environment some time in the future. This is difficult, because
they have to work in a foreign world of data flow diagrams and formal
specifications. Further their future work patterns are likely to be
substantially changed by the system itself. It is quite common for
developers to find it very difficult to get effective requirements
specifications, and for the users to be unhappy with the result when the
system is implemented one or even two years down the track.
This approach can be modified by prototyping, which provides a mock-up of
the system for the users to see, or evolutionary development, by which the
system is developed in steps. While these measures may help, there are
still problems.
Another approach is to find an enthusiastic user who will work with a
developer to work up a complete system before providing it to other users
to use. The problem here is that the enthusiastic user is not a typical
user. They probably have rather special requirements that they are keen
on, and are usually very much more tolerant of the peccadilloes of
computer systems than their colleagues are. When the system is released,
the average user is likely to be considerably less enamoured of the
benefits of the system, and greatly more frustrated by its deficiencies.
A third approach - called end-user computing - leaves it up to the user.
This is very time-consuming for the user, and is even less likely to be of
any use to other users.
Presented to the meeting of the Health Informatics Association of New
South Wales, Feb 1994.
Acknowledgements: The authors thank the staff interviewed, Graham Jenkins
for his support, and Rajeev Sharma for field work.
None of these processes are very effective in addressing the needs of this
distributed set of users that we are interested in. This case study
describes a system of development that has demonstrated the potential of
being very effective in this environment.
The case is a situation that occurred within the NSW health department a
few years ago. The central state IS group had been promising a human
resource management package for a long time, but any prospect of one
eventuating was a number of years away. In the meantime, the Areas were
coming under increasing pressure to control expenditure, and to control
staff costs in particular. They saw the provision of accurate and timely
staff information to cost centre managers as an important component of
this.
It so happened that the payroll contractor had seen this need, and had
developed a PC based system that provided staff information which was
derived from data downloaded from the payroll system. While the Areas saw
the value in this model, they wanted the system to be on their central
computers. They also wanted it to be flexible. So a group of Areas got
together, in conjunction with the payroll contractor, and hired a
developer to write a VAX version. This development had a number of
interesting characteristics:
1. The first version was designed to be very basic. Only a few simple
functions were provided, with little security etc. However, it gave
something useful to the HR managers, and was delivered to all Areas within
a few months.
2. A second version was to be delivered not long after the first, and
subsequent versions provided in spaces of 4-6 months.
3. The developer, a contractor, believed in this style of development and
was committed to making it successful.
4. The users met regularly, and decided on the future developments by a
priority system. The developer acted in an advisory role.
5. The development was controlled by a group of users from different Areas
who had similar roles and were on similar levels of the hierarchy.
While this process does have elements of other methods of development, the
combination of elements lead to a number of important results:
1. Benefits were gained early on, so users were positively disposed
towards it.
2. All users were using the same system, so had a common base of
information and experience.
3. This common information and experience provided a basis for:
a. an exchange of information and ideas between users across areas.
b. users to take advantage of each other's innovations.
4. The incremental development gave users small changes that they could
easily understand and rapidly make decisions on.
5. Users were in a good position to work out how best the system could
further assist in their work.
6. Users were able to develop an understanding of the contribution that
computing could make to their work.
7. Users were able to give clear guidance to the developer about what they
wanted.
8. The rapid response meant that planning could be done with a minimum of
formality and paperwork, and thus more efficiently.
9. The ability to use the system as it was growing allowed other
organisational processes to be accommodated to the system, and a better
understand of the overall needs developed. There was a "symbiotic" growth
of the computer system and the organisational processes.
10. The common interest in the system promoted the development of common
procedures.
11. An interest group was developed that was able to negotiate with the
Department of Health.
12. While many people had input into the design of the system the
management of the technical issues remained in the hands of the developer.
In all, these factors added up to very significant benefits. Amongst those
that were centrally involved in the development, there was an enormous
sense of satisfaction and achievement, and an opinion that it had been
done at a very low cost. The had got what they wanted, quickly, and they
also had a chance to influence its future development. The system has
continued to grow, and is now in use in nearly all Areas.
A key factor in the process was that the working group was made up of
similar users. However, the complexity of the application meant that there
were several different types of users involved, and consequently, some
variation in requirements. This was handled in several ways:
1. There were several disciplines represented amongst the principal users.
Those that used it quite extensively included staff in human resource,
payroll and finance. Different committees were set up for each of these,
with an overall co-ordinating mechanism.
2. There were many secondary users who did not use it extensively.
Although some were consulted in the design, they were not well
represented, and some felt that there interests were not being met.
3. Where requirements did necessarily vary between Areas, switchable
options were allowed in the software. These were kept to a minimum, and
integrated into the same software version.
While the achievements of this system were remarkable, it is certainly not
a panacea. There were problems with flexibility, and the involvement of a
wide range of users. The limitations require careful consideration. It is
also worthwhile looking at the requirements for getting such a process
going. The major requirements are:
1. A number of semi-autonomous people or groups with similar tasks and
responsibilities.
2. Minimal barriers for communication (competition, rank etc.)
3. A feasible basic application that can fulfil a real need relatively
simply at an early stage.
4. The likelihood that further development of the application would be
valuable.
5. The availability of suitable development support and the resources
required.
6. The technical viability of a common development (e.g. common or
compatible technology).
While this may seem to be a formidable list of requirements, it is
worthwhile looking at the ways some of them they might be satisfied. For
instance, communication barriers would be very much influenced by the
structure established, and the policy established by top management. The
base application may be provided by an existing or a commercially
available system that is open to modification, or that could be used as a
basic model. Then there is the support, which could feasibly come from a
central computing group, enabling tighter integration with other systems.
Finally, it is important to look at what the nature of the system that is
being developed here is. While there is a computer system involved, that
is not the only, or even the major component. It is very important to
recognise that the system consists of the users, their skills and their
ways of operating, as well as the computer. For instance, merely
transferring the computer does not guarantee a useful system. In fact,
probably the most important component of the system is the network of
people, their understanding of the way computers can contribute to their
work, their ability to develop the system to their advantage, and their
willingness to learn from each other. For instance, the consortium could,
if it wanted, adopt another program, abandoning the current one. It could
then continue to function in much the same way as it is currently, making
use of the skills and networks established.
It can be seen, then, that under suitable circumstances, a consortium of
users managing an evolutionary development can establish a powerful
process for developing systems that serve the users and the organisation,
and in the process, promote an environment of innovation and learning.
-----
Host's Note:
The internet has a way of reformatting lines longer than 80 characters,
usually an unpleasant result. This occured in Gray's message, and I have
re-justified the text to 80 chars for readability. I hope I have not
introduced any errors myself in this adjustment.
-- Rick Karash, rkarash@world.std.com, host for learning-org