IT-based process change

OVERVIEW

IT has become a significant part of every person’s working life. According to US economic analysis figures, companies are now spending an average of 30 per cent of their capital expenditures on information technology compared with 5 per cent in the 1960s. It is viewed as a critical resource.

However, despite the sophistication of the IT equipment available and the range of IT tools and techniques that have been devised and in many cases heavily promoted, organizations are still failing to gain the business value they hope for when they embark on IT-based change. It seems that while the promise of IT is high, the reality of what we actually experience is disappointing. It is as if the capacity of IT to deliver great things has overtaken our ability to use it effectively within our organizations.

Data gathered by Wharton Management School in 1996 reinforces this gap between expectation and reality. The research indicates that although 72 per cent of company executives asked say that it is critical for their organization to use high-tech tools such as IT to be competitive, only 17 per cent of respondents say that the benefits of these tools are being realized.

So what goes wrong in the process of realizing the benefits? Why do organizations have trouble with IT-based change? This chapter looks at the particular difficulties of achieving successful IT-based change and offers advice on how to overcome particular obstacles associated with this type of endeavour. The topics addressed are:

• strategy and IT;
• the role of IT management;
• the need for IT change managers;
• achieving process change;
• changing the information culture;
• new rules for a new age.

The potential gains of successfully implementing IT-based change are many and varied. Organizations are attracted by the idea that they will gain the capability to do a range of highly desirable things. Some of the potential gains concern innovation and development:

• to achieve flexible responsive production of customized goods;
• to segment the market place in new ways through analysing information, and then create new products for those segments;
• to serve customers in new ways by creating access via the Internet;
• to create new forms of partnership and new types of organization.

But many of the potential gains concern achieving efficiencies to:

• reduce the need for agents and intermediaries by providing employee or customer self-service facilities over the Internet or intranet;
• achieve sophisticated functionality at reasonable cost (for instance by introducing standard packages such as ERP);
• allow globalization of operations;
• enable choices to be made about how the company is structured while retaining the necessary level of central control;
• produce better information, with a greater level of detail than was possible before, and make it available faster to allow better decisions to be made;
• enable 24-hour working to maximize the ability to serve the globe and make best use of resources;
• encourage greater staff involvement by making information available to more people in the company;
• increase the opportunity for flexible working on the road or at home;
• reduce staff costs;
• increase the value of skills and knowledge by sharing information well.

Consider the growth in the use of SAP systems as an example of how companies are responding to the need to realize some of the potential gains listed above. SAP is a company that provides enterprise-wide applications that can satisfy most of a business’s activities. SAP global sales have seen phenomenal growth from US$500 million in 1991 to US$2,400 million in 1996. Companies are obviously impressed by the powerful system, but there are many stories of the painful struggles that people have to go through before they achieve optimum usage of the software. It is certainly not an easy ride to move from strategy to implementation.

IMPLEMENTING IT WORLDWIDE – WHAT’S IN IT FOR THEM?

It all started in the Head Office in the United States. We developed a strict plan of action. We had a very clear timetable for the coming 18 months. A series of conference calls with the financial directors in each region made it clear what the time frame was for rolling out the system, and what needed to be done in preparation for this. However, when the moment came, they just were not ready, despite continuous reassurances that it would be done in time.

At the last minute we had to call in some consultants to work through the readiness checklist with the various regional teams. This cost us quite a bit of extra money that we had not budgeted for.

I don’t think I have ever met such silent resistance. Until then, the regional offices had been allowed to report financial information in their own way. To them, the requirement to use the new system seemed very intrusive, and of no practical value. I guess we had only really seen and explained the advantages from a central point of view. If I did the same process again, I would take more time to go through the ‘What’s in it for them?’ angle.

Financial projects manager, IT company

STRATEGY AND IT

It used to be that managers could delegate IT decisions to the organization’s resident computer experts and they would simply go away and decide how to design and build a solution. But now, the decisions being made can affect the whole business in terms of service and product possibilities, smooth running of day-to-day operations and opportunities for sharing information. Is it sensible to leave these decisions up to technical experts who do not always have a full understanding of the organization’s vision and purpose? Companies can and frequently do end up with a range of incompatible systems that may never achieve an optimum configuration. This can take years to sort out. Or even worse, a significant component system may be unable to fulfil management’s long-term plans for organizational change, which may necessitate being able to segment data in different ways.

But there is a problem with senior management getting closer to the IT decision-making process. Davenport (1994) says, ‘General managers … usually don’t know much about computers. They may like the idea of using information technology strategically.… But they seldom know how to translate their wishes into specific IT investments.’ How can this situation be managed?

IT strategic grid

First, it is important to decide what sort of contribution IT makes to the organization’s strategy. This enables the senior management team to gauge how much and what sort of attention the development and running of IT systems should be given by themselves and by others.

To make this decision it is necessary to look at two factors: strategic impact of application development and strategic impact of existing systems. For some organizations, the development of new innovative IT systems has a significant strategic impact; for others, they are more focused on installing off the shelf packages to enhance some aspect of internal performance. Similarly, some organizations are 100 per cent dependent on IT to maintain operational performance, such as manufacturing organizations. For others, it might take quite a period of time before a disruption in IT services would create a significant performance dip.

The grid in Figure 8.1 is useful for assessing the organization’s current IT strategic position and thus deciding how much senior management attention needs to be spent on IT issues, and how IT should be managed. It is worth noting that the organization may change its position on the grid over a number of years.

Figure 8.1: IT strategic grid
Source: adapted from Cash et al (1992)

‘Support’ organizations may spend a lot of money on IT, but they are not totally dependent on IT systems for operational success day to day, minute to minute. Neither do they gain strategic advantage from innovative application developments. A doctor’s surgery would qualify here. In this case, senior management can be quite distant from the IT planning process.

‘Factory’ organizations are completely dependent on the smooth running of their IT systems. For instance, a manufacturing unit might grind to a halt if the IT systems were to fail. However, with this type of organization, innovative applications developments, although important, are not crucial to the organization’s ability to be competitive, except when its performance starts to lag behind competitors, and a move to the ‘strategic’ quadrant occurs.

‘Turnaround’ organizations are those in which innovative applications developments are crucial to the firm’s strategic success, but the day-to-day running of IT systems is not so critical. This might for example be an organization developing e-learning packages. The other classic examples are DHL, UPS and Fedex, who all offered customers the ability to go online and check the status of packages that were being dispatched. This gave them tremendous strategic advantage. In this case IT planning needs substantial effort, and needs to be linked closely to organizational strategy.

‘Strategic’ organizations such as banks and insurance companies are those in which innovative applications development brings significant competitive advantage and day-to-day processes are highly dependent on the smooth running of IT systems. In these types of organization, there is a very tight link between business strategy and IT strategy, and the head of IT normally sits on the board of directors.

Developing guiding principles

How do senior managers ensure that IT investment decisions are in line with the organization’s long-term strategy? The answer may be to develop a set of guiding principles which govern IT investment decisions.

The ‘principles’ approach to IT is advocated by Davenport. He recommends that a task force is set up comprising from 5 to 10 senior managers, including a senior information systems person, together with a small group of IS managers. This group should begin to devise a set of guiding principles that link strategy to IT investment decisions. The senior managers act as sponsors later in the process, endorsing the principles devised by the group.

The IS managers create the initial set of principles which convey the basic attitudes of the company towards technology, the overall direction the business is taking and the use to be made of existing technologies. These principles should be good for two or three years, or until there is a major shift in strategy. They should cover infrastructure, applications, data and organization. Examples of such principles are given by Davenport:

On infrastructure: We are committed to a single vendor environment.

On applications: IS will provide applications that support cross-functional integration of business processes.

On data: Data created or obtained within the company belongs to the corporation – not to any particular function, unit, or individual. It is available to any user in the company who can demonstrate a need for it.

On organization: The user-sponsor of a systems project will be responsible for the business success of the system.

Once this amount of time and effort is spent aligning the thinking between senior business managers and IT managers, the strategic course for IT progress is set, and decision making becomes much easier.

THE ROLE OF IT MANAGEMENT

IT management skills are critical to an organization’s ability to incorporate the technologies that are ‘out there’ and use them to best advantage. However, IT staff are often left out of the core decision-making processes and treated as implementers rather than strategists. The solution, we believe, is to ensure that IT management skills are present not only with IT departments, but all over the organization (see box).

Sambamurthy and Zmud (in Sauer and Yetton, 1997) say:

In our experience the most valued IT management skills tend to require lengthy development periods as they are heavily dependent on local – for example organization-specific – knowledge. We have also found that not all firms are equally endowed with the most valuable IT management skills. Furthermore, in order to be effectively applied, a firm’s IT management skills must be intricately woven into the complex milieu of an organization’s structures, roles, processes, culture, and the many relationships among a firm’s business and IT managers.

In today’s organizations the responsibility for managing IT is widely dispersed. It no longer sits solely with the IT director, but is shared amongst group-level IT people, business-level IT people, business line management, vendors, partners, consultants and contractors. This web of interconnected individuals somehow needs to sustain the organization’s ability to innovate, plan, design, develop, implement, integrate and maintain IT systems.

So what are the unique skills and knowledge areas required by an organization collectively to ensure that IT is used to improve business processes, enable changes in organizational structure, add value to its knowledge base and create or support the development of new products and services? Sambamurthy and Zmud carried out a four-year research programme in the early 1990s, out of which emerged seven categories of IT management competencies:

• Business deployment. The key competences in this area are the ability to examine, visualize and communicate the value offered by emerging IT. This needs to be coupled with the use of multi-disciplinary teams, with a good shared understanding of IT, to rapidly implement innovative IT solutions.
• External networks. This area of competence refers to the need for the organization to develop close partnerships with external parties to increase their awareness of emerging IT.
• Line technology leadership. Users such as line managers and senior managers need to participate actively in championing IT initiatives. This area of competence concerns the ability to take technical leadership, which line managers may delegate rather too quickly to IT people through lack of understanding of the technology.
• Process adaptiveness. This competence refers to the ability of all employees to relate to IT and the way it can transform business processes. It is also about the organization’s track record in restructuring its processes, and the existence of an environment where employees can discover and explore the functionality of IT systems. This means anything from the existence of a help desk, to online tutorials, to devoting time to training. For instance Deloitte and Touche has an innovation centre where employees can experiment with new technologies such as Web services to decide whether or not they could be useful.
• IT planning. This competence concerns the ability of managers within the organization to link strategic plans with IT plans, and to plan and execute individual projects.
• IT infrastructure. This competence is about the appropriateness and flexibility of the underlying infrastructure which allows innovative IT practices to emerge and to be capitalized upon.
• Data centre utility. This competence concerns the ability of those within the organization to build, maintain and secure fundamental information processing services.

We would add one competence to this list, as many organizations have completely outsourced IT operations and development, just leaving themselves with project managers and business analysts:

• Managing outsourced services. This concerns the ability to evaluate potential service options, manage the transition to outsourced IT services and manage service levels and service evaluation.

Sambamurthy and Zmud asked 230 senior IT executives to assess the levels of these competencies in their own organizations and to rate their organization’s success in deploying IT successfully. This research revealed a strong link between the level of these competencies and the organization’s level of success with deploying IT in support of its business strategy and work processes. The organizations in the group of respondents characterized by the highest level of IT management competency were also those demonstrating the highest success rate in deploying IT.

We offer the following three-stage process for moving towards better IT management.

Step one

Bring together a task force including senior management, line management and IT people. Start a discussion about how IT strategy will link to organizational strategy over the next five years. Select the IT management competencies that you think will be most important.

Step two

Conduct an audit of the key IT management competencies, involving as many people as possible. Use internal (good development for them) or external (better access to benchmarking data) consultants for this process. Feed back the results and identify hot spots where competence is low, but importance is high.

Step three

Plan how to raise the level of the most significant competences, allocating resources, responsibility and defining a specific timescale.

IT MANAGEMENT COMPETENCIES

• Business deployment:
  • examination of the potential business value of new, emerging IT;
  • utilization of multi-disciplinary teams throughout the organization;
  • effective working relationships among line managers and IT staff;
  • technology transfer, where appropriate, of successful IT applications, platforms and services;
  • adequacy of IT-related knowledge of line managers throughout the organization;
  • visualizing the value of IT investments throughout the organization;
  • appropriateness of IT policies;
  • appropriateness of IT sourcing decisions;
  • effectiveness of IT measurement systems.
• External networks:
  • existence of electronic links with the organization’s customers;
  • existence of electronic links with the organization’s suppliers;
  • collaborative alliances with external partners (vendors, systems integrators, competitors) to develop IT-based products and processes.
• Line technology leadership:
  • line managers’ ownership of IT projects within their domains of business responsibility;
  • propensity of employees throughout the organization to serve as ‘project champions’.
• Process adaptiveness:
  • propensity of employees throughout the organization to learn about and subsequently explore the functionality of installed IT tools and applications;
  • restructuring of business processes, where appropriate, throughout the organization;
  • visualizing organizational activities throughout the organization.
• IT planning
  • integration of business strategic planning and IT strategic planning;
  • clarity of vision regarding how IT contributes to business value;
  • effectiveness of IT planning throughout the organization;
  • effectiveness of project management practices.
• IT infrastructure
  • restructuring of IT work processes, where appropriate;
  • appropriateness of data architecture;
  • appropriateness of network architecture;
  • knowledge of and adequacy of the organization’s IT skill base;
  • consistency of object (data, process, rules) definitions;
  • effectiveness of software development practices.
• Data centre utility:
  • appropriateness of processor architecture;
  • adequacy of quality assurance and security controls.

Source: Sambamurthy and Zmud in Sauer and Yetton (1997)
Copyright 1997. Reprinted by permission of John Wiley and Sons, Inc

THE NEED FOR IT CHANGE MANAGERS

The days of the highly specialized in-house technical IT expert or ‘geek’ are probably numbered. Many IT solutions are off-the-shelf, and the teams of analysts and developers which used to occupy in-house IT departments are shrinking, or being outsourced, or simply not required. IT people with change management skills are needed now more than ever. Those IT people who can understand technology, be aware of what is ‘out there’ and what it can do for organizations, plus grasp how to create the changes desired by the organization are highly valuable.

IT courses and literature both tend to focus on the acquisition of IT skills and knowledge, or on the importance of good project management. The goal of IT work has traditionally been to deliver a piece of finished software to timescale and to budget, according to the specification. Much emphasis is made on getting the specification right, getting the right skills in place and controlling changes along the way. See Figure 8.2 which illustrates a typical IT roll-out process. There is precious little reference to stakeholder management or business user involvement, although it may be implicit.

Figure 8.2: Typical IT roll-out process

The emergence of rapid development techniques allows for real-time updating of software and flexible scoping of a project, but this approach involves a new way of specifying and managing development of IT systems which can be hard to establish and keep going.

IT people tend not to learn about change management. They learn to see their job as ending when the system is delivered. This is beginning to change in more forward-looking organizations, but is still an issue in many IT departments, and in many software development companies and consultancies too. IT people need to improve their skills in influencing and managing change, as well as their understanding of how organizational change works, and the nature of motivation and resistance in organizational systems.

The first aspect of the way the IT people work in organizations is the role that they tend to assume when working with business clients. Block (2000) offers a useful way of describing the three types of role that a consultant can have when dealing with a client. This is helpful when considering the ways in which IT people can choose to work with their clients. The three types of role are:

• expert role;
• pair of hands role;
• collaborative role.

The expert role

The consultant is the expert. The client has fully delegated the authority to plan and implement changes to the consultant. Decisions on how to proceed are made by the consultant on the basis of his or her expert judgement. The client elects to play an inactive role, and is responsive only when required by the consultant to respond. The client’s role is to judge and evaluate after the fact. The consultant’s goal is to solve the immediate problem.

When IT people choose this role (as they very often do) it means that they have the space to get on with the job in hand without interruption or interference, but it means that they can hide behind their expertise when things go wrong, much to the frustration of business managers. The other problem with this approach is that the client’s commitment to the technical solution is often rather thin. This means that when the client gets the end product, he or she is not always happy, having taken little interest until the finished item hits his or her desk.

The pair of hands role

Here the client sees the consultant as an extra pair of hands. The client retains full control. The consultant is expected to apply specialized knowledge to implement action plans towards achievement of goals defined by the client.

The consultant takes a passive role and does not question the client’s plans. Decisions on how to proceed are made by the client. The consultant may prepare recommendations for the client’s review and approval.

Collaboration is not really necessary and two-way communication is limited. The client initiates and the consultant responds. The client’s role is to judge and evaluate from a close distance.

When IT people take this type of role with their clients, problems occur because the manager may not have selected the best solution, and the consultant did not feel that he or she could question what he or she was told to do.

The collaborative role

In this case problem solving is a joint undertaking. Consultants working in this mode apply their special skills to help clients solve problems; they don’t solve problems for the client. The consultant and client work to become interdependent. They share responsibility 50/50 for action planning, implementation and results. Control issues become matters for discussion and negotiation. Disagreement is expected and seen as a source of new ideas.

The consultant’s goal is to solve problems so that they stay solved. Next time the client will have the skills to solve the problem.

In this mode, the relationship between consultant and client is creative, productive and responsibility is shared. This is the most appropriate role for IT people to take with clients in today’s complex organizations. However, it demands that IT people acquire skills beyond the technical. Some clients will see this type of relationship as slow, and may interpret collaboration as some form of obstruction. They will want to gain access to the quick results that the ‘experts’ used to give them, which will lead them to the problems highlighted above with the expert role.

What skills and knowledge might be required to enhance an IT person’s ability to work collaboratively with business managers? The intended outcome is to increase the possibility of implemented IT systems resulting in the intended behaviour change. We suggest that IT people involved in large-scale change initiatives need to acquire the following skills and knowledge if they are to become better agents of change:

• Knowledge:
  • How does organizational change happen?
  • What motivates people and how can that motivation be activated?
  • Where does resistance to change come from, and how can it be handled?
  • What change processes and what leadership styles are there to choose from, and what are the effects of each?
  • Wide understanding of different business processes.
  • Good understanding of organizational culture and its impact on change.
• Skills:
  • Coaching managers to solve change issues.
  • Facilitating multidisciplinary team workshops.
  • Influencing those outside your direct control.
  • Client and stakeholder management (saying no as much as you say yes)!!
  • Collaborative process mapping.
  • Ability to speak the client’s language (using their terminology).

If you are an IT person reading this, then your irritation level may now have reached an all-time high! You may be thinking, ‘I am already doing all this!’ We congratulate you, and offer our additional thoughts on the role of HR people in IT-based change. HR people suffer this syndrome in reverse. While they might focus on all the people-related aspects of desired changes, they often fail to grasp the nature of the technology involved. Again this is changing, but slowly.

Enterprise-wide applications such as PeopleSoft are now taking hold in many organizations, replacing many of the tasks that HR people have traditionally called their own (promotion, recruitment, arrangement of training). HR people need to be ready to understand and explore the possibilities offered by these systems so that they can think through how people will be affected, and orientate their internal structures and skills accordingly. This might mean setting up some quite different structures. Some central HR departments that we have worked with are now providing help desks and supporting users of IT, while offering HR policy guidance rather than taking on a full HR management role.

ACHIEVING PROCESS CHANGE

IT-based change is about process change. It involves people doing different things in different ways with different inputs and different outputs. New or improved IT systems are brought in to either increase efficiency or to allow innovation to occur, not to simply automate what is already there, so process change almost always occurs. But how is this best achieved?

In this section we compare two different approaches to process change. These are BPR (business process re-engineering) and socio-technical design. We look at the pros and cons of these two approaches, and investigate how these two approaches can be combined to offer a new way of successfully improving processes using IT as a lever.

BPR

BPR is one of the best known approaches to achieving IT-based change in organizations. It was first set out in a book by Hammer and Champy in 1993, entitled Reengineering the Corporation: A manifesto for business revolution, and was received with much enthusiasm from the business community, appearing to offer the answer to how to achieve radical change and maximize effectiveness. The tenets of this approach are:

• Rigorous focus on business processes that deliver value to the customer.
• Radical process redesign from scratch, leading to radical transformation.
• All unnecessary process detail is eliminated.
• Old processes are obliterated.
• Redesign produces processes that give significant strategic improvements in competitive performance.
• Enabled by IT.

AN EXAMPLE OF BPR

A car leasing organization in the UK decided to completely redesign its customer service processes, with the goal of gaining competitive advantage over other car leasing companies by being much faster and much more responsive. It also intended to offer some self-service operations to customers via the Internet. A task force was selected from the existing customer service team, and these people worked alongside a team of specialized BPR consultants to radically redesign the customer service processes over a period of three to four months.

The new process designs looked excellent, but problems came in the form of resistance when teams had to work on implementing processes that were obviously going to lead to staff redundancies. The roll-out was done over an intensive six-month period, which was very stressful for managers and staff alike. Customers noticed a significant dip in service, so much so that two key accounts were lost during the roll-out period. Things are better now, with new teams in place and improved processes, but if anyone was brave enough to do a cost–benefit analysis, the results would probably not look good.

Unfortunately the number of BPR successes where expectations have been fully realized is said to be quite small. Advocates of BPR take some pride in this. They claim that the potential gains of this approach are so great, it is bound to be risky. However, Sauer and Yetton (1997) say, ‘Not only is the risk [of BPR] substantial, but the stakes are unusually high. The cost of failure for a project that involves organizational transformation is likely to be much greater than the simple loss of investment. The time lost in undertaking a project that fails may give competitors a lead that cannot be recovered.’

This is a mechanistic approach that spends little effort on the social or organizational side of the process. A typical BPR approach follows the steps seen in Figure 8.3. There might be some team work, some multi-skilling and some group problem solving; there is usually quite a strong prescriptive element to the IT solution. Also, although the impact on structures, skills, culture and standards is thought about, it is often not acted upon until the later phases of the programme of change, as an add-on. Many believe that this approach is not the most effective way of engaging people in defining what process improvements are needed, and in making them happen. Resistance may be encountered, which will waste effort, or cause the initiative to fail.

Figure 8.3: A typical BPR approach
Source: adapted from Davenport and Short (1990)

BPR therefore offers the very attractive prospect of radically transforming key processes by starting from a totally blank sheet. The downside comes during implementation, when resistance from those who have not been involved may be encountered. Radical process improvements which lead to staff redundancies are difficult to manage, and team performance will dip during the implementation period. Staff read the signs of a new systems implementation where redundancies will result, and are demotivated at an early stage in the lifecycle.

Socio technical design

The principles of socio-technical design are concerned with getting a balance between:

• the strategic vision of the organization;
• the technology and the tasks needed to provide the product or service;
• the needs of the staff.

This school of thought stems from a systems view of organizations, based in the organism metaphor (see Senge in Chapter 3), and is a much more incremental, evolutionary approach. The approach is less widely used than BPR, and seems more cautious and humanistic than traditional BPR processes, which have a rather macho feel to them, advocating throwing everything out and starting again.

The underlying principles of socio-technical design are identified in Mumford and Beekman (1994). These principles were originally developed by the Tavistock Institute of Human Relations in London in the late 1960s, but still appear to hold good today:

• The principle of minimum critical specification: tell people what to do but not how to do it.
• The principle of variance control: problems must be corrected as close to the point of origin as possible, and preferably by the group that caused them.
• The principle of multiskilling: give individuals a range of tasks including some routine and some challenging.
• The principle of boundary management: identify boundaries between groups or functions and ensure that these are well managed and that the people on them have the necessary information to pass the product smoothly to its next transformation stage.
• The principle of information flow: information systems should be designed so that information goes directly to the place where action is to be taken, or to the source that originated it.
• The principle of design and human values: an important objective of organizational design should be to provide a high quality of working life for employees, for instance to fulfil the need to feel the job leads to a desirable future.
• The principle of incompletion: the need to recognize that design is an ongoing and iterative process.

Socio-technical design involves more forethought, planning and incremental change than BPR, which is faster, more risky and more exciting. As defined by the Tavistock Group, this process was facilitated by either a consultant or a manager, and followed the steps below. Some of these activities may look a bit quaint these days. When compared with BPR, the focus might appear rather ‘fluffy’ as much attention is given to the psychological needs of the workforce. See Figure 8.4.

Figure 8.4: The socio-technical design process
Source: Mumford and Beekman (1994)

Socio-technical design is still alive and well in some companies, but has been rather overtaken by the speed and promise of BPR. Although the incremental, developmental approach is seen to work well, it is often too slow for many environments where big results are sought quickly, without taking people off the job to do the research and take action.

Combination approach PROGRESS methodology

The PROGRESS methodology for process improvement is also offered by Mumford and Beekman (1994), and brings together the principles of socio-technical design and the technology focus and efficiency emphasis of BPR (see Figure 8.5). Key to this method is the belief that the future users of a system must play a major role in its design. Cross-group design teams must be set up, sponsored by senior management and facilitated by a skilled facilitator to achieve their goals.

Figure 8.5: The PROGRESS methodology for process improvement
Source: Mumford and Beekman (1994)

It is useful to illustrate the PROGRESS approach using a case study.

County planning office case study

The county planning department was overstretched and ‘in crisis’. Plans were stacking up, and a three-month delay was the normal experience of those submitting plans for approval. This was starting to become untenable, as people in the community wanted to get on with building work and could not do so without planning approval.

A consultancy firm using the PROGRESS approach was called in to work with the planning team. The planning process itself was identified by the team as being cumbersome and slow, but although they could see the problems, they had never had the time to sort them out. The consultants planned in some intensive half-day sessions with the planning team to map out the process and identify weak links. Although the impact of spending time in the workshop sessions caused even more backlog to build up for the team, they were confident that they could reduce the planning cycle time (from arrival of the application to sending out of approval) by 30 per cent if they focused on it for long enough and drew out some simple agreed actions.

Various core problems were identified:

• Seating arrangements were not optimal. The department was split between two buildings for historical reasons. Time was being wasted going to and fro, looking for people and searching for things.
• Lack of knowledge of different roles in the team was causing misunderstanding and friction.
• One administrator was particularly overloaded with tasks that she was finding extremely boring.
• Lack of a cataloguing system meant that time was wasted searching for paper-based items.
• The planning officers were often out of the office, but were not accessible. It was impossible to get messages to them, which was in turn holding up decision-making processes.

The following actions were agreed:

• The team was moved so that they could all sit in the same office.
• Four people were asked to learn more about each other’s roles by spending two hours a week together on joint projects.
• The administrator shared out her ‘boring’ tasks on a weekly basis.
• A simple computer-based cataloguing system was introduced.
• Planning officers were given a shared mobile phone, which they used to check every half-day for messages.

These simple measures resulted in a 27 per cent reduction in cycle time of the planning process. The department started to reduce the backlog, and life became less stressful for everyone.

CHANGING THE INFORMATION CULTURE

One of the difficulties with implementing new IT systems is getting people to use them in the manner intended. There are many horror stories of expensive IT investments that are never fully incorporated into daily organizational life.

Does the introduction of technology automatically change behaviour? Our experience says that this does not happen. In the worst case the new technology reinforces the habits and attitudes already present. (See the example in the box.) Organizations need to do more than simply change the IT equipment and systems available if they want to experience a radical shift in behaviour. A culture change may be required to create the shifts in information sharing required, because the introduction of new IT systems alone will not achieve this, suggests Davenport (1994). He says, ‘It shouldn’t surprise anyone that human nature can throw a wrench into the best-laid IT plans, yet technocrats are constantly caught off-guard by the “irrational” behaviour of “end-users”’. He says that what is important is how people use information, not how they use technology.

IMPROVING THE SALES PROCESS THROUGH THE USE OF IT?

We recruited George in January. He was a dynamic salesman, brought in to boost our capacity to develop major accounts. George had used this great IT system in his old company, and encouraged us all to come to a presentation about what this type of system could offer.

The proposed system would allow salespeople to share information about customers and contacts. He said this would boost our capacity to plan our sales visits, and partner with each other to work more creatively with existing and potential clients. It sounded good.

We bought the system in June. It was pretty simple to use, and everyone seemed in favour, so there should have been no issues. After two months, only George and two other salespeople were using the system and updating it regularly. This was out of a team of 12 of us. People just weren’t used to sharing information in this way, and as we were still measured on our individual sales targets, there was no incentive to help others by revealing our contacts.

George got really frustrated, and accepted another job by the end of November.

Sales executive in electronics company

Perhaps we need to forget about technology for the moment, and look at existing information sharing habits and develop some goals for behaviour change. But what are the rules governing information sharing behaviour? Davenport states the information facts of life:

• Most of the information in organizations – and most of the information people really care about – is not on computers.
• Managers prefer to get information from people rather than computers; people add value to raw information by interpreting it and adding context.
• The more complex and detailed an information management approach, the less likely it is to change anyone’s behaviour.
• All information does not have to be common; an element of flexibility and disorder is desirable.
• The more a company knows and cares about its core business area, the less likely employees will be to agree on a common definition of it.
• If information is power and money, people will not share it easily.
• The willingness of individuals to use a specified information format is directly proportional to how much they have participated in defining it, or trust others who did.
• To make the most of electronic communications, employees must first learn to communicate face to face.
• Since people are important sources and integrators of information, any maps of information should include people.
• There is no such thing as information overload; if information is really useful, our appetite for it is insatiable.

IT systems such as Lotus Notes and other forms of groupware are often readily taken up by employees because of the range of ways of sharing information offered. However, people need to have time to explore and learn about the possibilities of these systems so that they can make best use of them. E-mail is now taken for granted, but also has downsides such as ‘non-information overload’ rather than information overload. Non-relevant e-mails take time to scan, process and delete. It is almost too easy to share information via e-mail, and people will do it for their own reasons (such as covering their backs, making themselves look good, bringing network power into play and making others look bad) rather than for the benefit of the recipient.

IT systems are expensive to implement. Therefore, it would be beneficial if executives could start to see the difference between deciding to implement an IT system, and deciding to change the company’s information-sharing habits. Experience shows us that the first will certainly not guarantee the second, and the second often requires a culture change which requires energy, commitment, sponsorship and clear direction (see Chapter 8).

NEW RULES FOR A NEW AGE

As we were writing this chapter, we noticed an interesting article in the Harvard Business Review entitled ‘IT doesn’t matter’ (Carr, 2003). The writer suggested that IT is an infrastructure technology, rather than a leading edge one. This means that it is no longer a scarce resource that can give an organization an important competitive edge. It is now readily available at less cost, but companies are still investing.

For the last 25 years companies have been investing in IT systems to the point where they are now firmly built into the infrastructure of commerce. Compare this with the progress of the railway, or the electricity generator. At certain points during this progression there have been moments when companies have gained a competitive advantage from being the first to implement a particular technology; however this is now starting to level off, and so should investment plans.

The three new rules for IT management offered by Carr give some guidelines for those ready to review their IT investment strategy:

• Spend less. Carr says that companies with the biggest IT investments rarely post the best financial results. The focus should now be on ensuring that you do not put your company at a cost disadvantage, because the competitive gains will be minimal.
• Follow, don’t lead. The longer you wait to buy IT systems, the more you will get for your money. Carr says that it is unwise to be on the cutting edge, with the possibility that software or hardware is unproven.
• Focus on vulnerabilities, not opportunities. Companies need to pay more attention to security and network vulnerabilities, as well as systems reliability and minimizing downtime. IT spend should be carefully controlled, and resources managed in an economic way.