UNDERSTANDING SUPPORT - LESSONS FROM A CASE STUDY

Chris Sauer
Fujitsu Centre for Managing Information Technology and Organisation

Australian Graduate School of Management
University of New South Wales

Kensington
NSW Australia

ABSTRACT

Support from top management and others is agreed to be an important factor in information systems
success and failure, but little is written about how it has its effect and how it might be managed to a
project's advantage. A recently developed conceptual framework is described. It covers the nature and
forms of support, the way support affects project outcomes, the bases on which support is provided, and
the strategies by which support may be managed. The framework is used to analyse a case study in
several stages. At the end of the analysis of each stage, the framework's utility is assessed in terms of its
explanatory value and the practical advice it suggests. Areas for further research are identified.

INTRODUCTION

Top management support has long been recognised as an important factor in information systems
success (Ackoff 1960, Ginzberg 1975 cited in Keen & Scott-Morton 1978, Walton 1989, Jarvenpaa &
Ives 1991). Some writers have recognised the need for support from other sources such as the senior
MIS executive (Morgan & Soden 1973), user managers (Argyris 1971, Lucas, Ginzberg & Schultz
1990), and the organisation itself (Lucas, Ginzberg and Schultz 1990). For reasons that remain
unclear, despite apparently widespread agreement on the importance of support, there has been
relatively little research into its role in information systems projects (Ein-Dor & Segev 1981).
Assuming that support does function in ways which are of benefit, it follows that project managers
would be advised to consider how to ensure that they receive the support they need. Support, then,
needs to be managed just as does the technical effort of building and maintaining a system.
Sauer (1993a) has started the process of constructing a conceptual framework for theorising about
support and support management. This will allow us to employ a richer conceptual vocabulary, and,
in the longer term, to increase our understanding through a better appreciation of the ways in which
support works and how it can be managed to the benefit of a project organisation. As it stands,
Sauer's conceptual framework is unrefined. It is a pudding awaiting proof. It is the aim of this paper
therefore to test it out on a case study. This will do three things. One, it will allow us to observe its
applicability - how useful is it, what does it help explain, what does it not explain? Two, it will raise
some interesting research problems. And three, it will suggest some practical morals for project
managers.
The next section of this paper summarises Sauer's framework. It is followed by a section which
briefly introduces the case study. The case can be readily divided into temporal segments, and so is
analysed segment by segment In the final section the outcomes of the analysis are summarised and
conclusions drawn.

THE CONCEPTUAL FRAMEWORK

Sauer's conceptual framework has four main aspects. The first is constitutive and originative - it says
what kind of resource or behaviour constitutes support and indicates its possible sources or origins.
The second is functional: it begins the task of showing how support works. The third identifies the
bases of support. Then, equipped with knowledge of the way support helps a project and the bases on
which it may be provided, it becomes possible to start to identify and analyse the elements of the
fourth aspect of the framework, namely those practices and strategies by which support may be
managed by a project organisation.
Starting with the first aspect of the framework, what constitutes support? Sauer (1993a) defines it
recursively as follows:

September 1993 63



1) the supply of resources, services, and assistance (in controlling contextual
contingencies) which contribute to the innovation process conducted by a project
organisation, or

2) activities which generate support

Anything satisfying the first part of the definition counts as primary support. Thus, the provision of
resources (funding), the control of organisational contingencies (fixing), and the technical effort that
goes into the innovation process of developing, implementing, operating, and maintaining a system
(normal technical work) are all forms of primary support. Sauer also proposes that as system use is
usually regarded as critical to success (Lyytinen & Hirschheim 1987), it also be regarded as a
primary form of support. Behaviours which satisfy the second part of the definition count as
secondary support. There are three forms of secondary support. Mediation between a project
organisation and another source of support counts as power-broking. Activities which promote the
social legitimacy of the system or project is another form of support. Commitment is the third.
The framework identifies two types of source of support - internal and external. It is quite apparent
that much support will be external to the project organisation - from managers, users and others. The
purpose of this distinction is largely to raise awareness of the fact that internal support is a crucial
variable too. It should not be overlooked.
How does support work? Plainly, its ultimate value lies in providing necessary inputs to a project.
The value of secondary support comes from facilitating this. Support also works by helping the
project organisation cope with flaws in the innovation process. This can either be by solving the
problem that constitutes the flaw (for example, correcting a bug) or by absorbing the flaw (for
example, by 'working around' it). Such support has two possible modes. It can be anticipatory in
being ready for activation when required - budgets are anticipatory in this sense. Or, support can be
reactive if it is mobilised only in reaction to the appearance of a problem.
What is the basis for support? Why is it provided? Sauer (1992) argued that support was given in
exchange for system benefits. Sauer (1993a) views this as too limiting, and suggests that structural
and cultural factors are also significant. Where there is an exchange of benefits for support, the
benefits may be direct when enjoyed by the supporter or indirect if they are enjoyed by some other
party in a network of relationships whom the supporter wishes advantaged. When support is supplied
by virtue of some standard organisational arrangement (for example, the organisation's software
group maintains system software common to all projects) then it can be said to be structural. When
support is supplied because of values shared by a supporter and the project organisation or where
certain values are implicit in the system (for example, a believer in organisational decentralisation
might support a networked system because it advances the philosophy of decentralisation even
though it does not offer her any direct benefits) then it can be said to be culturally based support.
The final component of the framework asks what kinds of support management strategy and practice
are available to a project organisation. The support management practices are divided into the
structural and non-structural. The structural are those which attempt to institute organisational
practices which will assure certain forms of support. They are likely to be the most systematic. The
non-structural consist of those activities which attempt to manage support from a single individual
and those which are more general in their purpose. Thus, practices such as cooption will be in the
former category while attempts to make an organisation's culture more generally supportive will be in
the latter category.
Support management strategies will combine various kinds of management practice to achieve a
particular emphasis. Four are listed in the current framework. The targetted strategy singles out a
small number of important/powerful supporters. The sprayshot approach tries to win support from as
many sources as possible. The capture-a-champion strategy involves finding an appropriate
stakeholder to champion the project. The decoupling strategy involves trying to reduce the project
organisation's dependence on its innovation efforts by finding a sponsor who is less interested in the
system's benefits - a central government granting agency might fit the bill (see Kraemer et al 1989 for
examples). This taxonomy of strategies helps organise the different ways in which support
management practices may be employed.
The framework described in this section is summarised in Table 1. It is valuable both for before-the-
fact analysis and planning for information systems innovation, and for after-the-fact understanding
and explanation. It is therefore both a research tool and an aid for the practitioner. An assessment
can be made of what support is needed in terms of the different forms of support, its different

64 AJIS



possible sources, and the modes in which it will need to operate. Analysis of a project organisation's
access to support can be achieved via an assessment of the actual bases of support. The map that this
analysis provides of the organisational terrain can be used to guide and critically assess the selection
of a support management strategy and the practices by which it is to be implemented. The
framework will be tested on the case study by using it for explanatory analysis.

What is support? Primary - funding, fixing, normal technical work, use
Secondary - power-broking, promotion of social legitimacy,
commitment

How does support work? Provides necessary inputs
Copes with flaws - overcomes them, absorbs them
Modes - anticipatory, reactive

What are the bases of support? Exchange of benefits for support, structural arrangements,
cultural norms

What types of support management Structural, non-structural
practice are there?

What support management strategies Targetted, sprayshot, capture-a-champion, decouple system from
are there? support

Table 1: Summary of a framework for understanding support and support management

THE CASE STUDY

The case to be used was researched by the author through interviews and extensive file research
mostly between 1985 and 1988. The intention was largely to explore the problem of information
systems failure. One of the insights it threw up was that support had played a major role in the
project's life. A more thorough account of the research method can be found in Sauer (1992).
The organisation that sponsored the project was the office of the Australian Public Service Board
(referred to here as the Public Service Board). The Public Service Board was directed by a formal
board consisting of a chairman and two commissioners (referred to here simply as the Board). Its
general responsibility covered all matters to do with employment, industrial relations, training and
the like for the Australian Public Service.
The system, called Mandata, was intended to automate the administration of personnel and
establishments processes for the whole of the Australian Public Service. The project ran throughout
the 1970s before being finally terminated in 1981. What makes it particularly interesting for our
present purpose is that support for the project varied considerably over its lifetime. At one stage the
project was given a new lease of life by an injection of support while its final demise can be seen to
have resulted in part from a chronic haemmorhage of support.
The project's history can usefully be divided into a sequence of temporal segments or stages. The
first was an extended initiation stage which involved the gathering of support. The second was an
initial development stage that was bedevilled by resource problems. This ended in a review which
resulted in a major reorientation of the innovation strategy and a reinjection of support. During the
subsequent consolidation stage the innovation strategy began to give way under the strain imposed on
it while the project as a whole was subjected to a barrage of criticism. A further review was
instituted resulting in a partial abandonment of the project, trimming it back to a minimum viable
system, an outcome which left it vulnerable to the environment of public spending cuts. The
abbreviated analysis given here necessarily simplifies and finesses much of the project's complexity.
However, the full details are not critical to this paper. A far fuller account and analysis is given in
Sauer (1992).

September 1993 65



ANALYSIS OF THE CASE

The analysis of the case tests the conceptual framework as an after-the-fact aid to explanation. It is
also expected to identify problems for research and useful lessons or principles for practice. Each
stage of the case will be analysed in turn through the following eight questions:

1. What support was needed?
2. What was the support management strategy?
3. What support did it generate?
4. Did the support generated match the support needed?
5. What was the outcome for the project of the answer to 4?
6. What explanations does the framework yield?
7. What further research is needed on the framework?
8. What practical advice is suggested?

Stage One - Initiation

The goal of this stage was to obtain a strategic decision to proceed to develop the Mandata project.
Formally this was to be a decision by the Cabinet of the Commonwealth Government to fund
equipment and system software. To obtain this, a feasibility study had to be launched and funded; its
report had to be helped through a lengthy consultation and approval process; a revised proposal had
to be funded; and the process of preparing for system development had to be started. The feasibility
study report indicated a particular timeframe for this stage which was expected to result in a
submission to Cabinet for funding in September 1972. As well as needing support for these essentials
of the initiation stage, the project ideally needed a supportive context to be established (Walton 1989)
anticipatory of future support needs.
The strategy adopted for winning support in this stage was targetted although it had elements of the
sprayshot approach as well. Its central concern was to navigate a path through a sequence of formal
decisions. The Board and then various specialist committees had to approve before a proposal could
be put to Cabinet. These approvals were substantive decisions which would affect primary support,
particularly resourcing. So, the formal decision process imposed a degree of targeting. The strategy
was also sprayshot in that some degree of verbal support was required from the permanent heads of
Public Service departments and statutory authorities and from the staff associations. This aspect of
the strategy was geared to assuring a measure of secondary support for the project, especially social
legitimacy, but not to developing primary support.
Initially, the Public Service Board's head of Management Services was a champion for the project.
He was able to persuade the Board to support a feasibility study through funding and obtaining
secondments. In February 1972, just after completion of this study he retired to be replaced by a less
actively supportive manager in approximately the same gatekeeping role. From then on during this
stage support had a largely structural basis in that it was obtained by virtue of passage through a
formal decision-making process. The ADP Departmental Systems Branch of the Public Service
Board received passive support insofar as it was able to persist with the initiation process even
though it had no special funding to do so and was required to maintain a full workload at the same
time. The formal process of consulting the permanent heads and the staff associations yielded some
enhanced legitimacy for the project in the form of a number of statements of support although some
responses were qualified or hesitant. For example, one said, 'In our experience, the development of
an organisation of the size envisaged would take many years before producing a worthwhile output'.
And, one reason given for delays in putting forward the Cabinet submission was the tardiness of the
staff associations. However, by mid-1973, the Board was sufficiently convinced that the project
would go ahead that it agreed to resource twenty-eight new positions for Mandata in the financial
year 1973-74.
The strategy of targetting key decision-makers through the formal decision process ensured that the
project received a measure of primary and secondary support sufficient to meet the goal of a
favourable Cabinet decision. However, the lack of earmarked funding for initiation between the end
of the feasibility study and mid-1973 combined with the loss of the project's champion meant that

66 AJIS



there was no individual or group with sufficient status, access to the Board and time available to
enable them to meet the schedule laid down in the feasibility study report. Moreover the formal
approach of seeking approval from permanent heads and staff associations yielded only an increase in
perceived legitimacy for the project. In not seeking any primary support or even any formal
commitment this approach failed to build up a supportive context for future stages. Perhaps most
damaging to the project's future was the precise form of the strategic decision. It was a decision by
Cabinet to resource Mandata's equipment including some software. It was not an explicit decision to
provide either adequate staff or accommodation.
The outcome of this stage was success insofar as the project was approved. However, it was success
bought at a price that could not have been easily foreseen or avoided. Because of limited support the
project was delayed by nearly eighteen months. This had three undesirable outcomes. First, it set up
a situation in which the project's broader context was to be particularly damaging - it was to be
caught by funding restrictions as a result of changing national economic and political circumstances.
Second, the delay was to be used later as a criticism when the project became subject to external
scrutiny. Third, it had not been possible to build up a strongly supportive context. No agreements
had been obtained for primary or secondary support beyond the general approvals from permanent
heads and staff associations. No special level of commitment had been built up nor had primary
support been promised. Thus when the project found itself squeezed it had no reserves of support to
call upon.
The lessons of this stage are several. In terms of explaining the project's later difficulties, it is
important to understand that limitations to the support available after the feasibility study generated
delays which were to subject the project to very damaging contextual circumstances which it lacked
the capacity to combat completely. Apparent success in initiation masked what was to become a
more deep rooted problem.
In terms of the researcher/theorist's interests a number of problems emerge. First, there is a problem
with assigning a strategy type to a set of management practices. In this case, the strategy has been
assumed to be largely targetted in that it pursued a formal decision and approval process in which
primary support was explicitly asked for from Cabinet alone. The support sought from the other
parties appears to have been nominal. However, this may be influenced by the acuity of hindsight.
Was it truly a targetted support management strategy? At the time it would have been difficult to
estimate what support had in fact been garnered by the initiation process. This constitutes a second,
more general problem for work which uses the concept of anticipatory support. How can support be
identified in advance of its being called upon? This appears to be a major problem in advancing
from the explanatory use of the current conceptual framework to its use predictively to guide
practice. It plainly warrants further research.
There are several lessons for the practising manager. The first is that most projects need a variety of
forms of support, and apparent success in obtaining that form of support which has most visibility
may hide shortfalls elsewhere. Second, it is worth noting that delays can be damaging for more
reasons than that benefits are deferred. Uncertainty about the future increases with distance - the
further into the future a project is delayed the less certainty there can be about the difficulties likely
to arise and therefore about the support that will be needed. A third point related to the second is that
it is usually easier to keep established funding than to win new funding. The earlier in a project that
support can be won, particularly funding, the better. Consequently, obtaining funding should be a
very high priority for most projects. Fourth, as Walton (1989) has proposed, it is important to build
up a supportive context. But, that support needs to be balanced. It is not sufficient to have, say,
strong legitimacy but no fixers or power-brokers willing and able to help out with unforeseen
difficulties. Because some of the effects relating to support developed in this stage only emerged
subsequently, further practical morals arising out of initiation will be drawn in the next section.

Stage Two - Initial Development

The initial development stage concentrated on establishing the social and technical infrastructure for
the project and on setting in train the application design work. The former involved issuing a call for
tenders for a variety of hardware and software contracts, evaluating the tenders, managing the
contracts as they were let, building up a central mainframe facility, designing and installing a
continent-wide network, putting together the staff for a project organisation, and designing the
application system. The Cabinet proposal had indicated what resource funding would be needed -
principally, money for the technology, staff, and accommodation. Because of Public Service

September 1993 67



structures the project organisation was dependent on a number of other departments and agencies
such as the Australian Government Supply and Tender Board for management of the formalities of
the tender process, the National Capital Development Commission (NCDC) for provision of
accommodation, the Department of Housing for site works, and the Department of Services and
Property for fitting out and maintaining accommodation. Consequently, the project organisation
needed them to fix a number of tasks which were outside its own control. As the stage progressed
and it became apparent that not all the support needed was forthcoming, there became a requirement
for power-broking.
The support management strategy was essentially more of the same from the previous stage. It relied
on the Cabinet decision and assumed that that decision implied that support would be forthcoming for
all the other needs outlined in the proposal on which it was based. When it became apparent that
more support was needed than was provided the main target was the Board itself as both funder and
as power-broker. The approach to managing its support was structural inasmuch as it mostly
followed formal channels of communication with the Board through the head of the ADP Division.
One development in the management of secondary support during this stage was the establishment of
a consultative committee of middle managers from the user departments. This had the potential to
build support among staff at levels lower than permanent head by encouraging commitment, and
promoting legitimacy.
The support actually provided was variable. In some cases, such as the tender process, support
appears to have been satisfactory. But, in crucial ways it was less than was needed. The project
organisation lacked a champion with both access to and influence over the Board. The head of ADP
was slow to open the gate he kept. The Public Service Board and other departments were strongly
affected by stringency measures introduced by successive governments in response to difficult
economic circumstances nationally. For the whole period the staffing level was well below that
desired because of restrictions on establishing and filling new positions. In the financial year of
1975-76, the branch responsible for the system's technical development had a monthly average staff
of 32 as against 74 needed according to earlier estimates. In another instance, the NCDC stopped site
planning for the central computer because of funding restrictions. In this case, the project was able to
summon up sufficient support from the Board and, via it, ministers to overcome the problem, but the
result was a facility considerably less than originally specified.
The effects of the limitations to support for this stage were various. The support that was provided
was sufficient for some progress to be made but too little to avoid undesirable outcomes. The
shortage of staff when combined with contractual imperatives to service the establishment of the
technical infrastructure meant that the application design received a lower priority. As a result this
aspect of the system development was seriously delayed - by May 1976 the Board was being told that
pursuing the then current implementation strategy without a significant injection of resources no
implementation date could be promised. Project organisation morale, and hence internal support in
the form of technical work and commitment, was affected and the project became vulnerable to a
burst of external criticism from the Auditor-General (Auditor-General 1976) and the press. Such
criticism became a chronic problem over the following four years and provoked further external
scrutiny. The problem with the computer accommodation meant that the computer equipment took
longer than expected to accept and suffered continuing performance problems at least in part because
of its lack of adequate accommodation.
A particularly interesting outcome for the project was that the build up of all these problems for the
project created a political crisis for the Board. Faced with external criticism and no clear
implementation date, it had to make a decisive response. It either had to cut its support for the
project altogether and abandon it, or it had to revive it with an injection of support. It called in a
reviewer who proposed a strategy which would achieve early implementation of some application
functions. This strategy was to employ on behalf of a number of client departments the Department
of Productivity's existing personnel and establishments system. Initially, the system would be run on
spare machine capacity in several other departments' installations. Over time, the system would be
converted and ported to the Mandata mainframe. After that the original Mandata system would be
implemented. The strategy was agreed, and the reviewer was appointed project director at a level
more senior than that of the project's other managers, a position which gave him direct access to the
chairman of the Board, and concomitantly greater Board support. So an inadequate level of support
ultimately created the conditions by which more support would be generated. But this was only
possible because public criticism made abandonment potentially embarrassing and because an
acceptable alternative implementation strategy was found. The cost to the project was that the new

68



strategy introduced significant new problems because the system adopted was flawed and because
porting it to the Mandata computer proved significantly harder technically than was anticipated.
In terms of explaining the project's history an understanding of the problems of support during the
initial development stage show how the project reached that critical point at which the Board had to
take some radical decision about the project's future. The Board's decision in the face of crisis to
increase its support also helps to explain the continuing momentum the project maintained over the
next two stages in the following three years. The Board had now made a very visible commitment
and would need to justify its investment.
For the researcher, the problem of explaining why the Board decided to continue its support remains
outstanding. The best the current framework can offer, deriving from its account of the basis of
support, is the suggestion that the Board stood to benefit more from the project's continuation than
from its termination. This benefit might have been in terms of embarrassment avoided or political
damage from loss of face or a variety of other possible considerations. It might have been subject to
a form of escalating commitment (Staw & Ross 1990). What is clear is that research is needed to
refine the concepts which define the bases of support so as to better explain such decisions.
A second problem for the researcher is that the strategies and practices for managing support outlined
earlier in the paper do not address the problem encountered by the Mandata project organisation of
the withholding of support such as staff resources. How can it be avoided and how should it be dealt
with when it does occur? The strategy of decoupling the system from its supporters will only help if
alternative support is available. This issue warrants considerable further attention.
For the practitioner, several lessons emerge. Two relate back to the strategic decision taken by
Cabinet at the end of the previous stage. First, expressions of support cannot necessarily be relied on
to convert to substantive provision of that support. Second, one of the reasons for this is that there is
often ambiguity in the interpretation of what is promised. In this case the Cabinet only explicitly
supported expenditure on equipment. The project organisation drew the inference that the staff and
accommodation and other costs included in the proposal were thereby also sanctioned. However, this
left potential supporters such as the NCDC room for manoeuvre when economic restrictions were
imposed. They had neither promised support nor had the Cabinet explicitly instructed that they
should give it. A further related lesson is that support is contingent in that had economic
circumstances not changed it is quite likely that the staffing and accommodation resources would
have been readily provided.
Two further lessons concern the project organisation's ability to manage support. In automating
personnel and establishments record keeping Mandata did not constitute a strategic application for
any major stakeholder. It lacked leverage. It also lacked ready access to its most obvious source of
support, the Board, because its structural route was through a gatekeeper and because it had no
champion. Either of these conditions is likely to be enough to prevent a project organisation
maintaining its support in adverse circumstances.
The case of the Board's intervention to secure accommodation for the central mainframe when it was
endangered by the NCDC's decision to stop site planning is also instructive. That the project
organisation did not get what it really wanted serves to indicate that even where reactive support is
provided, it may not be sufficient to retrieve the situation fully. The outcome was consequential
problems with the both the equipment and its accommodation.
Finally, a practitioner faced with difficulties in managing support, in particular in obtaining promised
or expected support, would do well to dwell on the Mandata experience. Each effort to obtain the
desired support is costly to the project organisation. It is impossible to know and very hard to
estimate what the outcome will be. Will this effort be successful and yield all the desired support or
will it merely lead to another effort because it only yields some proportion of what is needed? This
uncertainty can be both debilitating and inhibiting to the formulation of some more rational project
strategy based on the limited support actually available.

Stage Three - Reorientation

The reorientation stage instituted a major change in project strategy in order to achieve earlier
implementation. For this it needed considerable support. All forms of primary support were needed.
It needed funding to get the project organisation to a size where it could implement, operate and
maintain a large application system for a number of departments at once. In adopting its new
strategy the project placed itself in the hands of the technical staff of the departments whose system it
was implementing and whose computers it was using. Being knowledgeable about the system the

September 1993 69



Department of Productivity's technical staff would be crucial fixers of applications problems.
Naturally, internal technical work was required to get this strategy off the ground and to subsequently
convert the system to run on the Mandata mainframe. With the new strategy emphasising
implementation it also became important that users actually use the system. Also all forms of
secondary support were needed. Power-broking was necessary to help manage the critical external
environment. The promotion of social legitimacy was required to combat criticism. And
commitment was needed because the new strategy, having been formulated quickly, was a calculated
risk and inevitably would require continuing support to help solve unimagined difficulties.
The new implementation strategy was in part a support management strategy as well. It targetted
three critical groups - the project organisation itself, the Board, and users. By bringing forward
implementation of an application, it disarmed the concerns of some staff internal to the project and
enhanced their morale. It gave the Board a response to the critics and a chance to avoid further
damage to its prestige. It aimed to win the support of users by involving them further, most
obviously by providing them with a service which would then serve as leverage for future support.
The project was mostly well supported during this stage. The new director was positioned to
command more Board support in the form of funding for more staff and power-broking to acquire
new office accommodation. The strategy itself served to win back support from disaffected members
of the project organisation. Users were mobilised to contribute resources to facilitate the
implementation and so increase the probability of active use. At the same time, though, the project
continued to be under resourced. It requested loans of computer systems officers from departments,
but all refused. The departments providing technical support for the operational system generally
contributed what was needed but their willingness to do so without compensation declined over time.
Mandata's public stock rose with the new momentum although not sufficiently to avoid some
continuing criticism.
The support provided was only slightly less than was needed. In consequence the new strategy got
under way with few hindrances. This met many of the political difficulties facing the Board. The
cost lay in the risk associated with the new strategy.
The lessons of this stage relate mostly to the possibility of the transformation of a troubled project
given sufficient support. This is not a matter which receives much attention in the traditional systems
development literature. In view of the number of projects that run into trouble it would seem that the
support perspective has something distinctive to offer. In this case it took a political crisis to create
the conditions in which such a transformation could occur. How necessary this is is unclear although
there is some evidence in other literatures that a crisis is an important precondition of radical change
(Pettigrew 1985 Child, Ganter & Kieser 1987). Although the point has not really emerged in the
above analysis, another lesson, if more minor, is that the improved image of the Mandata project
indicates that some problems and criticisms can be dispersed by a radical shift in strategy. By
eradicating the original basis for criticism, the critic is disarmed.
The other major lesson is that although a radical shift in strategy can be beneficial in terms of its
immediate effect on support it needs to be recognised that it is unlikely that the new strategy will be
as well thought out and its implications as well understood as if it had been the strategy followed
since the project's inception. When the decision to reorient is taken under political pressure this
danger will be acute.
Finally, a lesson which is apparent in the next stage, too, is that structural positioning is important in
managing support. The improved access of the new director undoubtedly benefited the project in
assuring improved support from the top. And this in turn benefited legitimacy with consequential
effects for commitment.

Stage Four - Consolidation

Where the third stage introduced a major change of direction, the consolidation stage aimed at
bringing the new implementation strategy to fruition. This involved implementation of the interim
system in many user departments and development of a new system along the lines originally
envisaged. The management of this stage was undertaken by a new project director.
Initially, the main needs for support were funding and technical work to maintain project momentum;
fixing by application staff in departments to get their personnel and establishments records into a
condition from which they could be computerised as well as continued fixing by the departments
providing system support; and, when implementation was achieved in a department, the system
needed to be used. Secondary support was also necessary to promote the provision of the primary

70 AJIS



support - legitimacy to combat criticisms from external sources and departmental users, commitment
to generate other forms of support, and power-broking to facilitate its provision where not
immediately available. A high level of anticipatory support was needed as the uncertainty arising
from the implementation strategy and contextual contingencies was high. As the stage progressed,
new problems emerged requiring previously unanticipated support.
The support management strategy continued to target key supporters but also included a greater
element of the sprayshot approach. The new director was known for maintaining a wide network of
contacts throughout the Public Service. At the same level as his predecessor, he was able to maintain
good links with the Board through regular formal and informal reporting sessions. He also
emphasised the continuing involvement of users at the management and supervisory levels in two
committees which met regularly. When faced with increased external scrutiny from the Auditor-
General and then the Public Accounts Committee, he called upon supporters to defend the project.
The support provided by the Board, the project's own staff, and by user departments was sufficient to
sustain the technical effort involved in implementing the system in twelve departments and to the
new development of several sub-systems. Conversion to the Mandata computer ran only a few
months late. But, there was not enough slack to allow the project organisation to compensate for the
flaws which persisted in both the converted system and in some newly developed sub-systems. These
same flaws caused user departments to continue to run clerical systems in parallel thereby
undermining much of the legitimacy their use of the system promoted. Under critical attack from the
Auditor-General (Auditor-General 1976, 1977, 1978, 1979, 1980), the Public Accounts Committee
(JCPA 1979), the press, and the staff associations, the Board gave considerable support in an effort to
counter the damage the criticisms caused to legitimacy and commitment. However, even this support
proved sufficient only to effect a rearguard action and to moderate the worst of the criticisms.
Overall, then, the support given to the project organisation was sufficient to sustain continuing
development, operation and maintenance, but it was not sufficient to permit eradication of all flaws
and shortcomings nor to generate the supportive context necessary to the development of the original
system.
The outcome was a situation in which a seriously flawed system was operational but for which there
continued to be a clerical alternative. Departments were, at most, only partially dependent on the
system. At the same time the project's legitimacy had been seriously damaged by the Auditor-
General's annual critique, by a severely critical report by the Public Accounts Committee and by
sensational press coverage. The project organisation's ability to leverage support for further
development to replace the flawed system was therefore seriously impaired despite the fact that the
Public Accounts Committee ultimately supported continued development of the project. The final
recognition that key flaws could not be rectified without redeveloping the core system and that there
was not support for that redevelopment forced upon the project organisation a scaling back of
ambitions while at the same time leaving it wide open to termination as part of governmental cost
cutting.
Analysis of the support management strategy and the adequacy of the actual support received helps
us to see how Mandata was able to continue as a functional project into the late 1970s but at the same
time how its prospect of surviving long into the 1980s was rendered poor. The crucial contrast here
is between the support needed and available to pursue a continuing implementation strategy and that
needed and available to rectify flaws in the strategy. The project organisation was unable to build up
a level of support sufficient for future needs. No doubt part of the reason for this was its inability to
satisfactorily manage perceptions of its performance. The critics were too vocal.
Thus one way in which the conceptual framework might be usefully extended would be to develop an
account of the factors which influence what support can be built up. How important is performance?
How important are criticisms? Then, the research might be extended to consider practices which
help combat negative influences on support.
Finally, the chief lesson of the consolidation stage for the practising manager is that however well
support may be managed in the present, negative perceptions of performance can undermine the
support needed for future efforts particularly if they involve any shift in type of activity. Where
performance is to be evaluated in terms of the quality of an implementation which has not yet been
completed it will not be known until that implementation is complete how support will be affected.
In other words implementation may cause a significant reduction in the support from a currently
satisfactory level to one which constrains future options. A subsidiary moral is that criticism is
important. It can be seriously detrimental even if there is considerable support to counteract it.

September 1993 71



Stage Five - Scale Back And Termination

In the first half of 1980 the project organisation, the Auditor-General's staff and the departmental
users independently of each other reached the conclusion that the existing core system was
inadequate as a basis for future extension. There was very little support for developing a replacement
even within the project. A consensus emerged that the project's ambitions should be scaled back to
whatever minimum was necessary to achieve operational viability.
In the short term, the project continued to need much the same level of resources because there
continued to be a large amount of work. The project continued to rely upon users to help it fix flaws
in the system. Public criticisms and their fall-out continued to command attention and responses. So
considerable support was still needed despite the decision to scale back.
The strategy for maintaining support, though still involving attention to the Board and users, now
centred on satisfying them through providing a valued service. This continued to yield the level of
resources needed for the new scaled back project. Moreover, users were now sufficiently supportive
that they could be coordinated into a joint rebuttal of the Auditor-General's most stinging criticisms
in his April 1980 report (Auditor-General 1980). Whether or not as a result of this or as a result of
continuing lobbying by the Board, a few months later the Auditor-General agreed to take the pressure
off the project. So, once again support was adequate for the project's continuing existence.
Crucially, though, in finally abandoning the original project objectives the project organisation could
no longer offer future benefits that would justify the total investment that had been made in the
project. In this it forfeited the basis for its funding. Thus, when funding became threatened by a
governmental cost cutting exercise it had no adequate ground on which to defend itself. Indeed, for
its chief sponsor, the Board, termination through the need for cuts was probably welcome. It gave a
face saving excuse for relieving the Board of a public embarrassment.
In an earlier section it was concluded that the conceptual framework exemplified in this paper might
be usefully enhanced by an elaboration of its account of the bases of support. The suggestion that the
Board might have supported the project because it could see no politically acceptable way out
underlines this. Support need not be based solely on benefits, structure and culture, but also may be
based on the avoidance of the disadvantages incurred by not giving support.
The experience of the termination of Mandata also highlights the contingency of support. Had
economic conditions been less straitened the cost cutting exercise might never have happened and the
strategy of bedding down a minimum viable system might have been successful. Clearly, context is
an important source of influence on support.
Analysis shows that the project was terminated because it no longer had a basis for justifying its
funding. The obvious lesson for practitioners is that the loss of a financial rationale may render
funding vulnerable although the decoupling strategy for managing support seeks to avoid this.
The other lesson is that partial abandonment (as in the decision to scale back Mandata) is a realistic
option when a project is in trouble (see Sauer 1993b). In this case, it did not manage to assure the
long term survival of the project. However, it did permit its continuance long enough for a face
saving resolution to emerge. This is not a negligible consideration. For members of a project
organisation concerned about the effects on their careers as a result of association with a failed
project or for supporters who have had long association with the project such an outcome may be
highly desirable.

CONCLUSION

Testing the conceptual framework on a case study was advertised as having three benefits - it would
demonstrate the framework's value in offering explanatory insights; it would highlight ways in which
the framework could be improved; and it would offer useful lessons for the practising information
systems project manager. At the end of each section analysing a stage of the case study conclusions
have been drawn. It is now appropriate to consider what more general conclusions can be reached.
First, the framework has demonstrated that it can help explain the ups and downs of the Mandata
project, in particular why it was able to continue when it encountered difficulties and why ultimately
it could not survive in its scaled down form. Indeed, in view of the fact that the project and system
were in better shape in 1981 than at the time when it was decided to scale back, it is only through
analysing the project's support that its termination can be understood. This is not to say that

72 AJIS



analysing support explains all facets of a project's history. The technical development of the
innovation is still important But, the support analysis perspective sheds light where otherwise
matters might remain obscure.
Second, the adequacy of the framework has been tested. All aspects of it have been used. One facet
which has not received much attention but which could usefully be explored is the linkages among
different forms of support. For example, visible primary support is likely to have a positive effect on
perceived legitimacy. Perceived legitimacy is likely to have a positive effect on other forms of
support. However, perceptions of supporters could influence these effects. Stakeholder X might
have a negative opinion of Y and view Y's support of a project as a reason for not supporting it. So,
to understand the likely influence of support we need a more sophisticated understanding of how
forms of support interact and how they may be modified.
This leads to further consideration of the bases of support. A better account of why supporters
support a project is needed. As noted earlier, it is more complicated than a rational exchange. In
addition to structural and cultural bases we have discovered that support may be given because the
alternative looks less attractive. The contingency of support has been noted. Even where a potential
supporter sees benefits from giving support there may be external factors which discourage or prevent
this from being converted into something usable. The framework has nothing to say about contextual
influences on support This needs to be rectified.
Another aspect that receives no attention in the framework is the matter of the balance of different
forms of support. Not only does the level of support vary over time, the levels of the forms of
support may differ at one time. It may therefore be useful to think in terms of a profile of support
To do this, and to make practical use of the matching of needs for support and available support it
will be necessary to attempt some kind of operationalisation of levels of support.
Third, various lessons have been drawn for the practitioner. The central lesson is that support is
crucial to projects. It is necessary in different amounts of its various forms at every stage. It is a
major reason that projects are able to continue even under adverse conditions. As the reorientation of
Mandata demonstrates, it can be used to radically change the direction of a project, perhaps saving it
from termination and loss of all potential benefits. The moral for the practitioner is that it is
important to attempt to manage support in order to smooth a project's path and enhance its prospects
of continuing when faced with adverse conditions. To manage only the technical development of a
system and to leave support to chance is to manage only half of an information systems project.
At present, then, although the conceptual framework presented and tested here has been shown to be
valuable in a number of ways, it has also been shown to be limited. Future empirical research on the
ways in which support works in projects and on the ways by which it is managed will contribute to a
more sophisticated conceptual framework. An improved framework will provide a basis for a theory
of support from which soundly based advice can be formulated. Until then researchers and
practitioners have at least a partial framework by which to think about support, and that is a
significant advance.

REFERENCES

Ackoff, R.L. (1960) Unsuccessful case studies and why, Operations Research, 8,4, March-April,
259-263.

Argyris, C. (1971) Management information systems: the challenge to rationality and emotionality,
Management Science, 17,6, Feb, B-275-292.

Auditor-General (1976) Report of the Auditor-General for the Year Ended 30 June 1976, AGPS,
Canberra.

Auditor-General (1977) Report of the Auditor-General for the Year Ended 30 June 1977, AGPS,
Canberra.

Auditor-General (1978) Report of the Auditor-General for the Year Ended 30 June 1978, AGPS,
Canberra.

Auditor-General (1979) Report of the Auditor-General for the Year Ended 30 June 1979, AGPS,
Canberra.

Auditor-General (1980) Report of the Auditor-General, AGPS, Canberra, April 1980.

September 1993 73



Child, J., Ganter, H-D. & Kieser, A. (1987) Technological innovation and organizational
conservatism, in Pennings, J.M. & Buitendam, A. (eds), New Technology as
Organizational Innovation: The Development and Diffusion of Microelectronics,
Ballinger, Cambridge, Ma..

Ein-Dor, P. & Segev, E. (1981) A Paradigm for Management Information Systems, Praeger, New
York.

Ginzberg, MJ. (1975) A process approach to management science implementation, PhD
dissertation, MIT.

Jarvenpaa, S.L. & Ives, B. (1991) Executive involvement and participation in the management of
information technology, MIS Quarterly, June, 205-227.

JCPA (1979) 775th Report of the Joint Committee of Public Accounts of the Parliament of the
Commonwealth of Australia: Use of ADP in the Commonwealth Public Sector - The

MANDATA Project, Australian Government Publishing Service, Canberra, September.
Keen, P.G.W. & Scott Morton, M.S. (1978) Decision Support Systems: an Organizational

Perspective, Addison-Wesley, Philippines.
Kraemer, K.L., King, J.L., Dunkle, D.E. & Lane, J.P. (1989) Managing Information Systems:

Change and Control in Organizational Computing, Jossey-Bass, San Francisco.
Lucas, H.C. Jr, Ginzberg, M.J. & Schultz, R.L. (1990), Information Systems Implementation:

Testing a Structural Model, Ablex Publishing Corp, Norwood, New Jersey.
Lyytinen, K. & Hirschheim, R. (1987) Information systems failures: a survey and classification of the

empirical literature, Oxford Surveys in Information Technology, Vol 4,257-309.
Morgan, H.L. & Soden, J.V. (1973) Understanding MIS failures, Data Base, 5, Winter.
Pettigrew, A.M. (1985) Examining change in the long-term context of culture and politics, in

Pennings, J.M. and Associates, Organizational Strategy and Change, Jossey-Bass, San
Francisco, 269-318.

Sauer, C. (1992) information Systems Failure: The Problem of Managing Support for a Rawed
Innovation Process, PhD thesis, University of Western Australia, Perth, WA.

Sauer, C. (1993a) Support and support management in information systems projects: building a
conceptual framework, mimeo.

Sauer, C. (1993b) Partial abandonment as a strategy for avoiding failure, in Avison D.E., deGross, J.
& Kendall, J. (eds) Information Systems Development: Human, Social and
Organizational Aspects, Proceedings of IFIP WG8.2 Working Conference,
Noordwijkerhout, 17-19 May 1993, Elsevier (North Holland).

Staw, B.M., & Ross, J. (1990) Behavior in escalation situations: antecedents, prototypes, and
solutions, in Staw and Cummings, L.L. (eds) The Evolution and Adaptation of
Organizations, JAI Press, Greenwich , Conn, 1990,191-230.

Walton, R.E., (1989) Up and Running: Integrating Information Technology and the
Organization, Harvard Business School Press, Boston, Massachusetts.

74 AJIS