com3053 case study

8/7/2019 COM3053 Case Study

1/19

IT Help Desk Implementation 241

IT Help Desk Implementation:

The Case Of An

International Airline

Steve ClarkeUniversity of Luton, UK

Arthur Greaves

London Borough of Hillingdon, UK

Copyright 2002, Idea Group Publishing.

EXECUTIVE SUMMARYThis case study concerns IT help desk management within an international airline. The core

of what is described relates to attempts at implementing help desk procedures in practice, and

illustrates the problems of treating these both as predominantly technology systems and

predominantly human systems.

From the failures outlined in the case, an alternative approach is proposed, based on the

application of methods drawn from an understanding of critical social theory. The practical problems

and theoretical issues are discussed, and a theoretically informed framework is applied retrospectively

to the case.

This allows conclusions to be drawn which, it is argued, strongly support the value of a critically

informed approach to human-centered IT help desk issues.

BACKGROUNDThe international airline on which this case is based was formed in 1984, and operates scheduled

freight and passenger air services.

Sales have historically been divided fairly evenly between the United Kingdom and overseas,

with transatlantic travel providing much of the overseas income. As can be seen from the information

on the next page, both turnover and profit have climbed consistently since 1995, with the latest figures

available showing turnover in excess of 900 Million, and profit over 100 Million.The company employs almost 6,000 peoplea relatively small number for such a large

organisation, pointing to the efficiencies expected in its operations. The almost doubling of

employees in the last five years gives some indication of the training and business continuity

issues requiring ongoing consideration.

With the exception of 1997, control of current assets has been strong: the company pays its debts

on time and collects funds owing efficiently.


2/19

242 Clarke & Greaves

1999 1998 1997 1996 1995

'000 '000 '000 '000 '000

8 Months 10 Months

Turnover:U.K. 491709 453107 365426 193383 228000

Overseas 423329 369124 313030 189658 220000

Total Turnover 915038 822231 678456 383041 448000

Profit (Loss) before Taxation 105227 75601 45172 34437 32000

Table 1: Sales Differences

This is clearly a successful enterprise, and that success has meant that the organisation needed

to grow as the service provision expanded, placing a strain on, amongst others, the informationtechnology (IT) department.

This growth wasthrough the 1980s and 1990s, and in common with other major international

organisationsaccompanied by an expansion in the use of computers, particularly networked PCs. To

facilitate this, a help desk was established to deal with user issues and problems. The evolution over time

of this help desk from being a multi-skilled base of generalists to a more complex and diverse team providing

support activities across a broad range of systems, forms the core of the subject of this case study.

1999 1998 1997 1996 1995

Number of Employees 5913 5183 4256 3525 3405

Table 2: Number of Employees

Sales and Profit

0100000200000

300000400000500000600000700000800000900000

1000000

8 Months 10 Months

'000 '000 '000 '000 '000

1999 1998 1997 1996 1995

'000

Turnover:

U.K.

Overseas

Total Turnover

Profit (Loss) before Taxation

Employees

0 1000 2000 3000 4000 5000 6000 7000

Number of

Employees

1995

1996

1997

1998

1999


3/19


The Information Systems DepartmentThe Information Systems (IS) Department was run by the IS General Manager who had nearly

125 people working for him, of which 47 were contractors. During the time covered by this case, there

were approximately 10 unfilled posts. The department was split into four sections:

Systems and Networking

Applications Development

Consultancy

Overseas

The largest section was Systems and Networking of which Operations formed the biggest area.

The case study was mainly involved in this area.

At the time of the study, the Operations area had 42 members of staff of which 13 were contractors.

The cost of this area was in the region of 3 million, including provision for facilities (desk, chair and

desktop computers) although not for the computer room, for which there was an additional budget of

2 million. There was a target set for contractor staff of 25 per hour, but in practice the lowest paid

contractors were paid more than this, with top rates of 55 to 60 per hour.

A key objective of the IS General Manager was to move towards a charge out rate for all work,

and thus become budget neutral. The Consultancy and Application Development areas already

operated in this manner.

SETTING THE STAGEThe background to this case can be traced to 1995, when external consultants were commis-

sioned to review the help desk operation. This resulted in four documents, produced in April 1995

under the banner of Help Desk Best Practice Procedures:

Service Request Management

Service Reporting Problem Management

Change Management

These documents outlined the role of the help desk and the help desk manager within IT. In

Service Reporting, for example, there are suggestions of how to report progress to increase help desk

visibility and credibility, including the use of a monthly telephone survey. However, one thing that

is conspicuously absent from these studies is any mention of user meetings or user agreement. What

1999 1998 1997 1996 1995

Net Current Assets 73707 33263 5430 24393 38000

Working Capital 48031 50468 42019 32448 40000

Table 3: Control of Assets

Liquidity and Working Capital

0

20000

40000

60000

80000

1999 1998 1997 1996 1995

'000 Net Current Assets

Working Capital


4/19


is also very clear from these studies is a complete absence of any evidence that the findings were

implemented. Instead, the existing help desk system was replaced by a product called Help Desk for

Windows from a packaged software supply company.

Following this initial development, the situation seemed to become somewhat confused. An

example of this is the release (in draft) in December 1997 of an internal document called managingreleases and other outages. This document makes no mention of the earlier procedures or documents

and does not appear to have been released in a final version. It is couched in very technical language,

and, unsurprisingly, there is no evidence of it ever being implemented. Again, a key issue here is that

the document was produced without the involvement of any help desk staff.

As the organisation continued to grow, the methods used in the help desk area became further

strained, and at the start of 1998 a new IS general manager was appointed. It was this manager who

commissioned a Health Check of the current IS support service in order to recommend an appropriate

way forward which satisfied the business needs and at the same time retained core strategic and

business skills in-house; this case study begins with that Health Check, a report which was issued

in May 1998, and which contained many recommendations for improvement. The report suggested

a four-phased approach:

Phase 1Quick wins, to: Address those areas of the service most visible to the users.

Address some of the internal issues needing minimal effort to resolve.Put in place service measurement.

Phase 2 Infrastructure set up, to: Establish an improved support environment with better tools

and knowledge base. Improve processes. Undertake initial preventive maintenance initiatives.

Agree and implement trial service level agreements (SLAs).

Phase 3 Effecting the change, to: Restructure the support service in order to improve the user-IS

interface and service and to offer IS staff the opportunity to develop strategic skills. Put in place SLAs

with the business. Establish back-to-back SLAs between the help desk and other support teams.

Phase 4Continuous improvement, to: Develop the proactive aspects of service delivery to

improve the stability of the infrastructure and systems. Further improve and adapt the service

to meet business requirements. Maximise the use of technology to improve the service.

Ensure the cost-effectiveness of the service.

As a result of this Health Check, a contract was awarded for the first phase of a project aiming

to achieve the quick wins and to get a better working relationship with the staff in the IS area.

Phase 1 Quick WinsThis phase did not deliver as many benefits as was hoped for at the initial health check, and

highlighted weaknesses in a number of areas:

Help desk management weaknesses in the collection and production of statistics as a result of

no overall-working pattern.

No local knowledge in the use and development of the Help Desk for Windows product.

Weakness in product management identified in the rollout of the new network.

Overall a lack of communication between the different duties (or sub-departments) of the IT

department.

All of this is a precursor to the main case to be described here, which starts at Phase 2:

Infrastructure Set Up.

CASE DESCRIPTIONAs a result of the weaknesses highlighted in Phase 1, it was decided that this task should now

be revised to Help Desk Supervisor Support. The primary driving force for this decision was the

organisation bringing in additional resources to assist the help desk supervisor in her role.


5/19


Help Desk Supervisor SupportThe Systems and Networking Department consisted of 53 staff, of which 19 were permanent

and 34 contractors. In the help desk area, morale was low, owing to concern that the help desk

was about to be outsourced. Initial terms of reference for this study were drafted and agreed by

the help desk supervisor.The first priority was to produce the statistics for the previous month. These had not been produced

before, and there were no targets in place. Since recording of information could be achieved through the

automatic call distributor (ACD) and the help desk software, it was agreed that 80% of calls received would

be logged, and that a target of calls being answered within 20 seconds would be set. The results were

disappointing, with only 25% of the calls answered being logged, 19% of the calls remaining unanswered

and the number of calls outstanding rising by 44 to 139. What was even more disappointing was that the

information pack containing the results was only issued to other IS managers there were no plans to issue

any performance statistics to users. However it was decided to review the statistics on a weekly basis with

each individual help desk analysis. The results were as follows:

0

10

20

30

40

50

60

70

80

90

100

Week 1 Week 2 Week 3 Week 4

Calls Looged

Abandoned Calls

Figure 1: Results of Phone Calls on a Weekly Basis

Week 1 Week 2 Week 3 Week 4

Analyst 1 47% 44% 68% 99%

Analyst 2 52% 72% 61% 95%

Analyst 3 8% 28% 48% 98%

Analyst 4 41% 80%

Analyst 5 22% 22% 26%

Analyst 6 49% 71% 85% 125%

Analyst 7 23% 26% 72%

Table 4: Percentages


6/19


The number of calls logged rose steadily over the first three weeks, corresponding with a drop

in the number of calls that went unanswered. The 80% target was still not being met, with a number

of operators logging less than 30% of calls. It appeared that the reason for this was that the message

had not been delivered in a consistent manner. For example, there were two new starters during Week

2: one of these did not log any calls even though he sat with another analyst for a day. He suggestedthat at his previous company they did not log calls but just solved them. In an attempt to remedy this,

the help desk supervisor spoke to the analysts on the Friday of Week 3 and made it clear that

improvement was essential.

This led to extraordinary behaviour, with one analyst going sick, and another finding calls from

previous weeks that had not been logged. In addition, three analysts each took a days leave during

the week with the result that the number of unanswered calls also rose during the week. The consultant

produced an information pack for the current month; this was now expanded to include month by month

comparisons and trends in addition to the monthly data. The consultant also wrote a procedure to

show how the information pack was produced. Yet again the information pack was not issued outside

the IT department, although some of the graphs were placed on a notice board by the managers office.

Some Early ConclusionsWhat are we to deduce from this situation?

The results over the month proved to management that the help desk supervisor needed

additional support and assistance. However, the problems were seen to be deeper than this. The over-

emphasis on technical issues had effectively led to the human problems being treated as secondary.

Within the IT domain there is a wealth of empirical and theoretical evidence to suggest the problems

likely to result from such an approach, a short summary of which is given here before moving on to

the practical measures taken to improve the situation.

Technology-Based Approaches to Information Systems

The literature on information systems reveals a strong adherence to pragmatism, with little or

no explicit recognition of underlying theory. Following on from this adherence to pragmatism is the

treatment generally of information systems as a technical, problem-solving domain. This adherence

to pragmatic problem solving leads to tensions when the system to be implemented or managedrequires significant user input. Just as most of the information systems literature stresses a project

management, methodological, pragmatic approach, so it also emphasises the need for discovering the

requirements of users, basing this view on the observation that systems frequently fail to meet user

needs (Clarke, 2001 p.89ff). Most commonly, the incorporation of user requirements into information

systems development (ISD), for example, is achieved by including a user analysis stage within the

existing problem solving approach (Clarke, 2001 p.8), with advice on how to undertake this user

analysis often addressed only weakly. The argument for an alternative to these technology-based

approaches is supported by the findings from a number of studies of systems failure. Boehm (1989,

p.2) cites examples of such failures, and considers that, directly or indirectly, they contribute to as much

as 50% of total systems cost.

In all of these instances, the systems development life cycle emerges, implicitly or explicitly, as

the prime control element, resulting in a methodology which adheres to the functional engineering

model, taking a structured, problem-solving approach: human complexity in the system is seen assomething which can be analysed, and toward which a specification can be written. Beath and

Orlykowski (1994), focusing on a three-volume text by Martin, mount a convincing critique of the

interaction between users and systems professionals in information systems development (ISD),

concluding that the commitment to user participation is revealed as ideological rather than actual, with

users frequently shown to be passive rather than active participants in the process.


7/19


Through a thorough review of the information systems development literature, Lyytinen and

Hirschheim (1987) make a compelling case for the argument that few information systems can be

considered a success. The reason for claiming success is, they argue, largely based on an erroneous

classification of how such success should be measured, which usually focuses on the extent to which

the completed system meets the requirement specification laid out in advance. Lyytinen andHirschheim promote the notion of expectation failure, or the failure of the system to meet the

expectations of the key stakeholder groups, as conveying a more pluralistically informed view, and

forcing a dynamic perspective of information systems development.

If technology-based approaches to information systems provide an impoverished view of the

domain, perhaps the solution is to be found in human-centered methods.

People: The Human-Centered MethodsThe human-centered approach to information systems has given rise to the so-called soft

methods. It is argued that traditional engineering approaches are hard or functionalist, being based

on a view of the world which sees it as composed of deterministic, rule-based systems, in contrast to

which the soft methods take an interpretivist, ideographic stance.

An early attempt at incorporating human issues into what was seen as a technical domain was

the ETHICS methodology. ETHICS (Mumford, 1985) was developed in the 1970s as a socio-technical

methodology (Effective Technical and Human Implementation of Computer-based Systems), which

follows an essentially problem-solving approach. More recently, Stowell and West (1994) have

promoted the client-led design (CLD) methodology, which takes the position that, since the informa-

tion system results from social interaction, participants in that interaction ought to be central to

systems analysis and design. In their view, information systems development needs to be driven by

interpretivism, and not, at the technical development stage, engulfed by functionalism (Stowell

1991). Consequently Stowell and West are critical of methods whereby soft, interpretative approaches

such as soft systems methodology (SSM) are used to front-end a technological development, arguing

that once the soft analysis is passed to the technical specialists, the benefits of that soft analysis are

largely lost.

Reflection on the activities carried out so far within this study from the perspective oftechnology-based versus human-centered analysis seemed to point to a need for the human-centered

side of the work to be given more prominence. Considerable thought was given to this, before deciding

to use focus groups of relevant participants to throw light on the issues.

Focus GroupsDuring 1998, a number of focus groups were set up in an attempt to arrest the ever-worsening

situation in help desk support. The groups identified were:

Service directory and targets: responsible for the development of service targets.

Support processes: responsible for the identification of tasks and activities needed within the

support processes.

Team relationships: responsible for reviewing the draft support processes and the implemen-

tation of those processes.

Help desk/field feedback meetings: responsible for the operation and the development of thesupport processes.

Support cross feedback meetings: responsible for monitoring of support processes and

identification of improvements.

User review meetings: responsible for the review of the IT information pack, service level

agreement (SLA) monitoring and identification of new requirements.

The membership of each group was carefully determined, linked to individual and team skills.


8/19


Attendance and Expectations of Group Members

Attendance at the meetings varied from five to eight. Lateness was a common problem, owing

largely to: a lack of time management within the IS teamthe informal culture of the organisation

exacerbated this; and opposition to the changes likely to flow from the meetings this also surfaced

in actions from meetings being ignored, and poor response to other requests.There were different feelings and expectations from the group participants at all of the meetings

and in particular at the process model meetings. The detailed findings below relate to the key attendees

(names anonomised).

AB was the most senior participant at these meetings in terms of position and length of service,

although perhaps the youngest. He had his own ideas about what needed to change, but tended not

to articulate them other than to defend his position. His discipline within IS department is Networks,

and he had a reputation for not completing projects. Frequently late for meetings, AB never responded

to emails or reports from the meetings. He was very polite although was never available at other times

for informal or formal chats.

While it was difficult to get a clear view of what his feelings or expectations were, he seemed to

favour small personnel adjustments rather than large-scale changes. He was also aware that the new

manager was looking to outsource some of the operation to reduce costs and improve quality, so was

perhaps concerned about his future within the organisation.CD worked for AB. He had no formal management training, and had a number of problems within

the network team, seemingly related to his attitude to other IS colleagues. Although he appeared open

and ready to accept change, he did not speak at all at the meetings and did not responded to emails

or reports from the meetings. Although informally he ventured a number of opinions and ideas as to

how he would like to see the organisation changed, these were at no time formally expressed in the

group meetings. The impression was that CD would like to see change, but did not expect it because

of the attitudes of his manager, and therefore did not want to be seen to be formally involved.

EF also worked for AB, and had been frustrated about the lack of developments in the IS area.

Her expectation from the process meeting was not only to identify what needed to change, but also

to gain a new position in the organisation as Change Manager, which would report to the new IS

manager. She expected the consultants to be able to implement change by removing the Help Desk

supervisor and outsourcing the Help Desk.

EF had trained as a manager but had little experience in this field. She seemed unhappy about

the lack of commitment and involvement of others in this process.

GH worked for EF and was keen to get involved, though he did not talk in any of the sessions

and preferred to put his ideas in writing to the consultants. He was aware of the tensions within the

organisation and seemed to feel intimidated by management. His expectation was that change would

happen and he would get a new job providing that he did not rock the boat. He expected the

consultants to be able to change the organisation.

IJ was at the same level as AB and was responsible for Application Development. Her

expectations were that the work being done by the consultants would not be implemented while AB

was still employed by the organisation. She refused to attend the process meetings or send any of her

staff, although she did agree to meet with the consultants separately. She supplied feedback on the

reports produced following the process meetings, but did not see Applications Development as part

of the Help Desk process.

Service Directory and TargetsThis group consisted of the IT management team along with the consultant service manager.

The purpose of this group was to draft service performance measures and targets. The idea was to

set a number of performance indicators, set targets for each of these indicators and put procedures

into place to monitor them. The group had three months to put these into place before they were

discussed with users in an attempt to set up service level agreements. To be able to set realistic targets,


9/19


however, the aim was to implement the performance indicators as quickly as possible.

The group met on a weekly basis, and initial feedback was encouraging, with all managers

picking up actions. However, there were actions from two managers that were never resolved and

were carried over from meeting to meeting. Also there were problems with performance indicators

that could not be measured by existing software. The manager responsible for development wasreluctant to spend resources or to give priority to the work needed to create new software, and

to overcome this the service manager developed his own software using Microsoft Excel, at which

point the focus group stopped meeting.

Support ProcessesThere were a number of workshops to discuss the support processes.

Workshop 1 was set up to brainstorm call management and problem management. The technique

used at the workshops was to look at each process from the perspectives of:

Users

Doers (staff )

IT Management

The processes would then be drafted and reviewed by a group called Team Relationship, who

would also be responsible for implementation of the processes. Each department of IT was invited

to send a representative to the workshops, and most nominated the manager or supervisor. The first

workshop was without representation from development or business consultants and in fact started,

because of lateness, without the IS support and network manager (AB) or the network manager (CD).

Also, although those attending were representatives of their department and the relevant skills areas,

there were anomalies:

There were no representatives invited from the field or help desk areas of the organisations.

Therefore in addition to no user representatives there were no doer representatives either.

With the representatives who had turned up, there were organisational conflicts that could have

had career implications. CD and the IS support manager (EF) reported to AB and the database

administrator (GH) reported to EF.

The initial debate as to whether this was the right approach to take took place mostly between

AB and EF. AB suggested that the consultant, who had previous experience, should developprocesses and procedures without wasting the time of employees, while EF asked if users could be

requested to make an input to process requirements rather than relying on those present identifying

what they thought users would want. It was agreed that the draft processes which emerged from the

workshop would be circulated to user representatives by the IT management to seek feedback, and

that this would furnish input to the Team Relationship group. The debate continued with a lot of

requirements identified for all aspects; in fact, the management requirements were split between what

the help desk manager would want and what the rest of IT management seemed to require. However

the discussion was mainly between AB and EF, with occasional comments from CD but no comments

at all from GH. In the end AB made the comment that the problem was with the help desk: if they were

doing their job correctly, this workshop would not be necessary and that as professionals we all knew

what the users wanted.

At the end of the workshop, it was agreed that the consultant would write up the notes and send

them to all attendees. After feedback from the notes, the consultant would draft the processes for callmanagement and problem management. After the meeting a representative from development turned

up and explained that they had not come to the meeting because they felt they had nothing to offer

since both call and problem management was outside of their responsibilities. He did make three points

however:

How will calls from the United States impact the statistics, since there were time delays?

It takes a long-time for the help desk to answer the phone, and if the caller did not hang up

it would not be recorded as an abandoned call. Other measures were needed and he would


10/19


document these.

He thought it was important to conduct a customer survey to find out the views of the users,

and this should be made public.

There was no feedback from the notes from this first workshop, and the other measures

mentioned by the development representative were never received.Workshop 2 was scheduled to discuss change management. On this occasion a development

manager (IJ) asked if she could change the meeting, and when this was not possible, asked for a private

meeting. This was agreed and took place before the scheduled workshop; this was hoped to bring

any comments made into the discussion. However the meeting was quite negative and the following

points were made:

It was felt that development was outside of the phase 2 review and that the problems were in

the IS support and network area, and in particular with the help desk.

There was no desire to change current working practices at the company, the IT department and

been round this loop on at least two previous occasions without any differences other than the

loss of time.

There are a number of different release procedures depending on the application, and the help

desk was not included in these processes.

The help desk had refused to get involved with the bug report, which meant that the userhas to proceed to development directly, without problems being given any priority or

resolution being planned.

A tool was implemented to control change management but the rest of IT was not using this.

The workshop proceeded after this meeting with the same attendees as before and with the same

people, AB and EF, dominating the discussion. However on this occasion AB was keen to keep the

responsibility for change management and did not feel that the other areas of IS Support and Network,

including the help desk, needed to get involved in the process. By having a project database online

everybody would know what was happening and when it was happening.

The meeting managed to develop the requirements for the three aspects and the consultant

agreed to issue the notes and would seek feedback. On this occasion the comments from development

would be included.

Workshop 3 took place with a different group, and this time included representatives from the

help desk and field instead of AB and CD; development was not invited. This was an attempt to remove

the negative comments from the previous two workshops and to get comments from GH. The workshop

had the same purpose as the previous workshops, but in this case there was also an attempt to include

some aspects of the Team Relationships, i.e.:

Decide what asset management should cover, from a users, IS doers and managers viewpoint.

Decide who best should be involved in the process.

The first part of the meeting was concerned with the control of assets. There was a very negative

element when the field supervisor suggested that there were a number of users implementing their own

software and hardware. It was suggested the way around this would be to identify and publish the

Top 10 offending users, but the notes of meeting were more tactfully worded to suggest that this could

be considered in the future. The rest of the meeting proceeded without further negative comments

and yet again the consultant produced the notes from the workshop.

Workshops: ConclusionsA key element to emerge from all of these workshops was the extent to which the proceedings

were distorted by managers taking positions of power to force through their views. This issue will be

seen to be key in the conclusions to this chapter.

Team Relationships

This group met on two occasions and consisted of more junior staff than had previously been


11/19


involved. The first meeting was to discuss the implementation of the problem management process,:

however not one member of the group had read or even looked at the document before the meeting.

In fact they were not aware of the change programme that was being implemented at the company, and

therefore it was necessary to explain what was being done and the current status. The participants

then received a presentation on the problem management process, which mainly consisted of workingthrough the process diagram. This sparked a lot of interest and the process was broken down into

three sections: incoming problems, problem resolution and preventing problems. For each of these

sections, different activities, and who should be responsible for these activities, were identified.

The second meeting was arranged to discuss the implementation of change management, but

attendance was disappointing. As well as no representative from the help desk, two of the people from

the previous meetings did not attend. However the people who did attend had read the change

management process document, although they did not identify any changes or errors. This meeting

succeeded in identifying problems with the current change management procedures, with quite a

number of areas that could be improved:

Identification of projects to be undertaken over the next six months: there is a project database

but it appears to be a speculative wish list with no plans for implementation or even project start

dates.

The need for more active project management to ensure that more direction is given. A need for standards.

In addition, a number of roles were identified during this process by employees. There were not

seen as an increase to the current establishment but to give responsibility to existing members of staff.

These posts are listed below.

Help Desk / Field Feedback MeetingsFollowing the support workshop, feedback meetings were held, according to the following terms

of reference drawn up:

To improve information logged by all duties.

To identify preventative maintenance or other strategies to reduce the number of incidents

Royal Blue Help Desk forWindows (HDfW) Administrator

More training was required in the use of HDfW, geared towards thecompanys way of working. Training was also identified as an

important requirement for the implementation of the Supportprocesses especially in Call Management.In addition it was identified that a new set of closure codes and amechanism for allocating codes are required. It was assumed thatthe Help desk supervisor or a HDfW Administrator could do thiswork.

Configuration manager There was a role for a configuration manager to control assetmanagement. This role is currently in the field team.

Tool for Change Management A tool to help record and control change was needed. Someone willneed to evaluate, select and implement an appropriate tool.

Standards and Procedures During change management discussions it was identified thatprocedures and standards were required. Also some procedures, and

perhaps a tool, for project management.

Document Control With standards, procedures and processes in place it was necessaryto have someone to take responsibility for document control - thisshould fall into the configuration management role.

Table 5: Part Time Roles Identified During the Team Relationship Meetings


12/19


and problems.

To coordinate the resolution of problems to improve cross-team cooperation and develop a

service culture.

In order to:

Provide a better service to the user. Help provide a support service that is responsive, knowledgeable, available, consistent and

appropriate.

This first meeting was well attended with resolutions being proposed to meet the existing

problems between the two teams. It was agreed to meet two weeks later to give time for all the nine

actions to be completed. However the next meeting began with participants arriving between 20 and

35 minutes late for a meeting scheduled to last one hour, and with no actions having been completed

from the last meeting. New completion dates were set which were about three or four weeks away, but

subsequent complaints by participants about the organisation, the management and the software

being used (in fact, very similar complaints to those being raised before phase 1 of this change process)

began to stall the whole operation.

After a discussion with EF, who was not present at this meeting, it was decided that it was perhaps

too early to hold meetings at this level since it was apparent that the necessary discipline was not

in place. It was decided to hold meetings at the supervisor level instead.

Support Cross Feedback MeetingsThese meetings were held on a weekly basis for three weeks, and although supervisors raised a

number of problems, there did not appear to be much enthusiasm for resolving them. At each of the meetings,

participants volunteered for actions to resolve the problems identified, but none of these actions was

completed. To assist in this the actions were issued within hours of the end of the meeting, in advance of

the minutes, but there were still 27 actions outstanding. The major concern was these meetings were

Responsible for the monitoring of the support processes and the identification of improvements. However

the support processes had not yet been implemented and a lot of problems being brought to the meeting

would have been solved had the processes been in place. There were no further meetings planned despite

all these difficulties since the timetable for phase 2 was coming to an end.

The first support procedures were issued (in draft form with a request for comments) within twoweeks after the first workshop. When none were received a follow-up email was issued asking for

comments or queries about the documents, and in particular:

Level of detail

Flow chart format

Omissions or lack of understanding

Still no comments were received, so it was decided to arrange one-to-one meetings with each

of the people the drafts had been issued to. These meetings took place but were no more successful

in eliciting comments. By the end of October, four support processes were issued:

Call Management

Problem Management

Change Management

Asset Manager

Consultation with users was raised in the workshops, but none was implemented, since it wasdecided that the processes should be in place before they are discussed formally with the user.

User Review MeetingsThere were a number of reviews with senior management throughout phase 2, to report on progress,

problems and issues. It was made clear at all of these reviews that there appeared to be a lack of commitment

to change and that the help desk was seen to be the root of all problems. Another factor which became clear


13/19


through these reviews was the deep divide between development and support. Development liked to do

things in a formal waythey used standards and methodologies; support liked to do things in an informal

manner, without standards at all. It was recognised that phase 2 would not solve this relationship, and as

a consequence, development were removed from any further involvement. However this did not solve the

problem of the implementation of the processes within the support area. It was decided to arrange aworkshop in an attempt to refocus the support managers in the need for change.

The workshop was arranged for the planned end of phase 2, the end of October. However

management had decided not to proceed with phase 3 but wanted to extend phase 2 for a couple more

months to allow the development of service level agreements. The service manager (JS) resigned at

this time, it being clear he felt that progress was not going as quickly as he would like and that issues

had not been addressed by management.

User Review WorkshopThe workshop was a full day with the participants being the same people involved in the support

process workshops, with the inclusion of the help desk supervisor (LW) in place of the DBA. The

workshop was facilitated by a member of the consultancy company who not been involved with the

company before, and had deliberately not read any of the previous documentation, including the

support processes. This meant that he would go over old ground again and give the participants an

opportunity to review the work that had been done.

It was divided into a number of sessions, both group and individual working sessions, and

there appeared to be plenty of enthusiasm. There were a number of actions identified including

some for immediate action.

These actions were never completed!

Human Issues Emerging from the Meetings

The Help Desk/Field Feedback meetings were held because of tensions between these two areas,

and there was an expectation that by having a formal meeting, these tensions would be relaxed. The

first meeting was polite, with a number of actions identified which the members of both areas were

expected to carry out. Following this meeting, however, problems began to surface, related to personal

relationships within the teams. In addition, tensions emerged between the field and help desk areasas a result of different employment contracts: the help desk operatives being contractors, and the field

being permanent staff. Help desk staff, for example, only worked contracted hours and took all their

breaks (very important in that role), while field staff worked longer hours and very rarely took breaks.

This resulted in a call for action from the senior management, and when this was not forthcoming, the

help desk staff closed ranks and began a work to rule.

Service Level AgreementsThe aim of this exercise was to improve the service to the end user, but before this could be done,

the service to be provided had to be defined. Phase 2 of this change programme was all about moving

towards this goal, the first activity, for example, being to produce IS Service Catalogue and Service

Targets. To ensure that this service could be provided, a disciplined professional team was needed

who were working to provide this service in a consistent manner. To achieve this required a well-trained

and motivated workforce, working with procedures and processes which allowed them to deliver therequired service. Unfortunately the processes developed were never implemented, although a number

of measures and targets were in place.

The next step taken was consultation with the user. The first stage was a presentation to

the user group representative by the IS support manager, outlining what had been done and what

was going to be done. This presentation was well received and plans were made for further one-

to-one meetings with individual users. The first one was with flight operations and it was clear

that the service being offered fell short of that required. The flight operations manager was not


14/19


happy with the service his department received, and the service targets confirmed his concern.

The IT manager suggested that rather than receive a budget for running support, it would be better

to get people to pay for it. A cost model was developed which calculated the standard service,

i.e., what was being provided now, and this could be supplemented by additional services

provided on a charge-out rate.The process for SLA development was developed and the plan was to implement these over the

first three months of 1999 ready for the new budget period from May 1, 1999.

This did not happen either.

CURRENT CHALLENGES/PROBLEMS FACING THE

ORGANISATIONA number of initiatives developed during phase 2 were never implemented; these included the

support processes, service level agreements and service measures. Phase 3 was not started, with the

consultancy organisation withdrawing from providing consultancy, and the airline wanting a period for

reflection on what had been done. The consultants had wanted an outsourcing agreement with the

company, and it seemed unlikely that this would happen. In addition during phase 2, because of a number

of network problems, the company commissioned the consultants to conduct a network server health check.This highlighted problems with the set up of the servers and recommended a number of actions; some of

these actions were called for immediate action. No action was taken to implement this report.

So why did these did these initiatives not get implemented? In a practical or pragmatic sense,

it might be seen that there could be many reasons for this:

The IS general manager was given additional duties shortly after the start of phase 2 and did not

have the time to champion the change programme.

A number of difficult staffing decisions were not made: in particular the decision not to replace

the help desk supervisor. She had expressed a desire to change her role. She left the company

early in 1999.

There were culture clashes between the consultancy organisation and the company.

The IT staff were concerned that the change programme was leading towards services being

outsourced, and they resisted this.

The change programme was not supported by all of the management team, so that staff gotdifferent messages dependent on whom they worked for.

Perhaps the help desk was doing a good job as far as the users were concerned and there was

no real drive to change this service.

The time scale was too ambitious and the consultants were making decisions based on

experience rather than on requirements and observation.

However, a more radical alternative is, rather than to consider the pragmatic issues raised by the

case directly, to look at the problem context afresh from an alternative perspective. The nature of the

case gives clear guidance on this, pointing to power or coercion being a key factor in the lack of success

of user-focused initiatives.

In seeking a way forward, the company might consider the following questions:

1. To what extent have the companys problems been caused by an over emphasis on technological

issues?

2. Given the inadequacy of the current meetings structure to address the human side of the

implementation, what could be done to improve this?

3. How has power distorted this implementation, and how might this problem be overcome?

Further questions, to be considered by the consultants and/or students of this subject, might be::

What is the value of theoretical support in determining a way out of the companys problems? How

might such theories be applied?

The following sections pursue this theme and offers a potential way forward.


15/19


CRITIQUE AND A POSSIBLE APPROACHOne possible analysis of this case would be that the problems were initially not adequately

addressed by technology-based or hard analysis, so a soft approach was taken, which had limited

success because of the coercive or power-based issues getting in the way. Power in organisational

intervention is a difficult issue to address, but some approaches do exist, and the rest of this chapter

aims briefly to introduce these to those readers who may be unfamiliar with them.

These approaches are drawn from critical systems theory, and the techniques which seem most

appropriate to this case fall under the general heading of critical analysis of the system of concern. Such

an approach is premised on the idea that, to be fully informed, a user system must be critically appraised

through the views of all those involved in and affected by it. In this case, this would lead to two methods:

1. Critical boundary judgments.

2. Surfacing coercive elements.

Critical Boundary JudgmentsThe system boundary is an issue to be settled before the intervention can proceed further. Whilst

the problem of system boundaries has exercised the minds of both academics and practitioners for

many years (for a summary of early work, see Jones, 1982), it is from Ulrich (1983, 1988, 1996) andMidgley (1992) that the recommendation to critically challenge what should or should not be

considered part of any system is drawn. Midgleys approach is to begin with a boundary definition

which is accepted as arbitrary, and progress by looking for grey areas in which marginal elements

lie that are neither fully included in, nor excluded from, the system definition. The critical choices made

at the boundary are of truth and rightness: truth being represented by questions of what is, and

rightness by questions of what ought to be. The starting point for the critique of boundary judgements

within this intervention is represented by the critique of the system boundary below.

The Wider SystemPrimary

IT Department Boundary SecondaryBoundary

Help Desk Help Desk Analysts

The IT System User IssuesPeople as part of

the systemOther stakeholdersAccommodation

Help Desk IT of ViewsSpecialists

Management

Critique of the System Boundary

(Clarke and Lehaney 2000)

Figure 1: System Boundary Critique


16/19


Critical assessment of the system boundary would be undertaken by a representative

sample of participants in the system, the approach working as detailed below, and expected to

yield the results outlined.

An arbitrary system definition should be presented, as, for example, in critique of the

system boundary. The primary boundary represents the main area of concern, whilst thesecondary boundary encompasses that which is seen to be marginal to that area. Beyond this,

all other issues are represented by the wider system. What immediately emerges from this

Question Is Mode Ought Mode

1 Who is the client? Whose purposes are served

by the system?

Users.

Who ought to be the client?

Users.

2 What is the purpose?

Timely satisfaction of user requests.

What ought to be the purpose?

Users happy with the level of service.

3 What is the measure of success?

Unclear, but premised on technologicalmeasures.

What ought to be the measure?

User Satisfaction.

4 Who is the decision taker?

Senior managers representing each

department.

Who ought to be the decision taker?

Managers, but informed by feedback from all

participants in the problem context all

involved in and affected by the system.

5 What conditions are actually controlled by the

decision taker?

Choice of solution.

What components of the system ought to be

controlled by the decision taker?

Controlled is not helpful. The decision taker

should determine the required approaches to

satisfy the changing needs of the participant

groups.

6 What conditions are not controlled by the

decision taker?

None.

What resources and conditions ought to be part

of the systems environment?

Everything within the system as defined by

critical boundary decisions.

7 Who is the systems designer?Unclear.

Who ought to be the systems designer?Complex combination of technical expertise

and user knowledge.

8 Who is involved as an expert, what is the

nature of the expertise, and what role does the

expert play?

IT and consultants.

What kind of expertise ought to be involved, who

should exercise it, and what should his/her role

be?

Expertise is lodged with all who participate in

the system. If this is not understood, the system

will fail.

9 Where is the guarantee of success? With

experts, political support, etc.?

With experts.

Where ought the guarantee of success be?

With participants.

10 Who represents the concerns of the affected

(but not involved)?

Users, but poorly represented.

Who ought to represent these concerns? Who

among the affected ought to become involved?

All those involved, and, with care,

representatives of those affected.

11 Are the affected given the opportunity to

emancipate themselves?

No.

To what extent ought the affected to be given

such an opportunity?

Power is clearly getting in the way of this

project. It needs to be addressed.

12 What world view underlies the system of

concern?

Command and control systems.

On what world view ought the design of the

system be based?

The system as a set of communicated

understandings between participants.

Table 6: Critically Heuristic Boundary Questions After Ulrich 1983)


17/19


analysis is the way in which the original conceptualisation of the system as shown within the

primary boundary is open to challenge. Once consideration is given to including help desk

analysts (initially excluded) and other users / those affected in the wider community, the reasons

for the failure of the original approach starts to become clear.

Surfacing Coercive ElementsOnce the system of concern is clarified, a brainstorming session (de Bono, 1977) might be set

up, attended by representatives of all the key participant areas. The purpose of the session would be

to enable participants in the system (those involved and affected) to conduct the critique on their

own behalf. The system should be critiqued within the brainstorming session by a combination of

Midgleys and Ulrichs approaches to boundary critique:

a) Midgleys (1992) approach to examining what is in the margin for elements which support the

secondary boundary or the primary boundary.

b) Ulrichs (1996) approach to challenging system boundaries through 12 critically heuristic

boundary questions which address issues of motivation, power, knowledge and legitimisation.

Our experience is that the approach outlined above, particularly the use of Ulrichs critical

boundary questions, both surfaces the necessary issues and gives some guidance as to how to

proceed. This reconceptualisation of the system is an important part of this kind of intervention,

through which it can be perceived not as a clearly defined technical or organisational problem to which

a solution is to be found, but as a complex interaction of all the issues involved in help desk operations

and management. This has the effect of changing the focus from technology or organisational

functions to the views and ideals of the stakeholder groups involved in the system. The task becomes

not one of how to engineer a solution to a known and agreed problem, but how to study and improve

a problem situation made up of complex interacting issues. People are not only part of the system; they

are the primary focus of study.

To complete this analysis, suggestions are given in Table 6 of the likely outputs from this

exercise. What emerges from this may be summarised as follows:

1. The system of concern is currently seen as a set of rules to be implemented, but if this were truly

relevant as an approach, we would be able to identify facts, or basic truths, to be set as goals.

Unfortunately, this in no way describes the system, which is actually determined by the normsof the organisation and its participants. The only way to surface norms is by asking normative

questionsthat is, oughtquestions not is questions.

2. Once this is understood, a scan of the answers to questions in the right hand column yields some

interesting results. The management task moves from one of control to one of facilitating others

in the performance of their jobs: the right of managers to make decisions is not challenged by

this approach, but the basis on which those decisions are made is!

3. The power or coercion which is currently causing so many problems is seen for what it is

a distortion of the problem context. As long as it is allowed to pervade all the issues, no solution

will ever be found.

CONCLUSIONSThis kind of approach offers many challenges to managers, but arguably all are concerned with

the true management task, which consists not of using authority to force decisions, but rather of

facilitating people to contribute all they possibly can to the success of the enterprise.

In practice, we have come across many objections to these views, but none that could not be

resolved by good managers working in a learning environment, whilst increasing their own under-

standing of the nature of the task they face. But the real test lies with you, the readers. We argue that

this reconceptualised approach works why not try it!!


18/19


FURTHER READING

Material on the hard-soft debate may be found in the first instance in:

Key text:

Walsham, G. (1993). Interpreting Information Systems in Organisations. Chichester, John Wiley

and Sons Ltd.

Other texts/papers:

Checkland, P. B. (1978). The Origins and Nature of Hard Systems Thinking. Journal of Applied

Systems Analysis5(2): 99-110.

Checkland, P. B. (1994). Systems Thinking, Systems Practice. Chichester, Wiley.

Jackson, M. C. (1982). The Nature of Soft Systems Thinking: The Work of Churchman, Ackoff

and Checkland.Applied Systems Analysis 9: 17-28.

Lewis, P. (1994). Information Systems Development. London, Pitman.

For those wishing to delve more deeply into critical approaches, we would suggest:

Key text:

Jackson, M. C. (2000). Systems Approaches to Management. New York, Kluwer/Plenum.

Other texts/papers:

Ackoff, R. L. (1981). Creating the Corporate Future. New York, Wiley.

Clarke, S. A. and B. Lehaney, Eds. (2000).Human Centred Methods in Information Systems: Current

Research and Practice. Hershey, PA, Idea-Group Publishing.

Clarke, S. A. and B. Lehaney (2000). Human-Centred Methods in Information Systems Development:

Boundary Setting and Methodological Choice. Challenges of Information Technology

Management in the 21st Century, Anchorage, Alaska, U.S.A., Idea Group Publishing: 605-608.

Clarke, S. A. (2000). From Socio -Technical to Critical Complementarist: A New Direction for Information

Systems Development. The New SocioTech: Graffiti on the Long Wall. E. Coakes, R. Lloyd-

Jones and D. Willis. London, Springer: 61-72.

Flood, R. L. and M. C. Jackson (1991). Creative Problem Solving: Total Systems Intervention.

Chichester, Wiley.

Hirschheim, R. and H. K. Klein (1989). Four Paradigms of Information Systems Development.

Communications of the ACM32(10): 1199-1216.

Midgley, G. (1995). What is This Thing Called Critical Systems Thinking. Critical Issues in Systems

Theory and Practice, Hull, U.K., Plenum: 61-71.

Mingers, J. (2000). Combining IS Research Methods: Towards a Pluralist Methodology. Information

Systems Research.

REFERENCESBeath, C. M. and W. J. Orlikowski (1994). The Contradictory Structure of Systems Development

Methodologies: Deconstructing the IS-User Relationship in Information Engineering.

Information Systems Research 5(4): 350-377.

Boehm, B. W. (1989). A Spiral Model of Software Development and Enhancement. Software Risk

Management. Washington D.C., IEEE Computer Society Press: 26-37.


19/19


Clarke, S. A. (2001). Information Systems Strategic Management: An Integrated Approach. London,

Routledge.

Clarke, S. A. and B. Lehaney (2000). Human-Centred Methods in Information Systems Development:

Boundary Setting and Methodological Choice. Challenges of Information Technology

Management in the 21st Century, Anchorage, Alaska, U.S.A., Idea Group Publishing: 605-

608.

de Bono, E. (1977). Lateral Thinking. Aylesbury, U.K., Pelican Books, Hazell Watson & Viney Ltd.

Jones, L. M. (1982). Defining Systems Boundaries in Practice: Some Proposals and Guidelines.

Journal of Applied Systems Analysis 9: 41-55.

Lyytinen, K. and R. Hirschheim (1987). Information Systems Failures: A Survey and Classification of

the Empirical Literature.Oxford Surveys in Information Technology. Oxford, Oxford Univer-

sity Press. 4: 257-309.

Midgley, G. (1992). The Sacred and Profane in Critical Systems Thinking.Systems Practice5(1): 5-

16.

Mumford, E. (1985). Defining System Requirements to meet Business Needs: A Case Study Example.

The Computer Journal28(2): 97-104.

Reynolds, G. W. (1995).Information Systems for Managers . St. Paul MN, West.Stowell, F. A. (1991). Client Participation in Information Systems Design. Systems Thinking in Europe

(Conference Proceedings), Huddersfield, Plenum.

Stowell, F. A. and D. West (1994). Soft systems thinking and information systems: a framework for

client-led design. Information Systems Journal4(2): 117-127.

Ulrich, W. (1983). Critical Heuristics of Social Planning: A New Approach to Practical Philosophy.

Berne, Haupt.

Ulrich, W. (1983). The Itinerary of a Critical Approach. Berne, Haupt.

Ulrich, W. (1988). Systems Thinking, Systems Practice, and Practical Philosophy: A Program of

Research.Systems Practice1(2): 137-163.

Ulrich, W. (1996). A Primer to Critical Systems Heuristics for Action Researchers.Forum One: Action

Research and Critical Systems Thinking, Hull, UK, University of Hull, Centre for Systems

Studies.

BIOGRAPHICAL SKETCHESSteve Clarke received a BSc in Economics from The University of Kingston Upon Hull, an

MBA from the Putteridge Bury Management Centre, The University of Luton, and a PhD in human

centered approaches to information systems development from Brunel University all in the

United Kingdom. He is Reader in Systems and Information Management at the University of

Luton. His research interests include: social theory and information systems practice; strategic

planning for information systems, and the impact of user involvement in information systems

development. Major current research is focused on approaches to information systems and

strategy informed by critical social theory.

Arthur Greaves is a Computer Auditor at the London Borough of Hillingdon.

Previously he was a IT Consultant working on a number of assignmentsinvolving project management and service management. He has been working on computer systems

design for more than 25 years, and this work has been reinforced by Management training (MA in

Management) and in Management Accounting (Chartered Institute of Management Accountants).

com3053 case study

Documents