• Ei tuloksia

MANAGING INFORMATION SYSTEMS

In document Procurement in Project Implementation (sivua 154-158)

6. GENERAL PLANNING OF INFORMATION SYSTEMS

6.1. MANAGING INFORMATION SYSTEMS

This section gives an overview of managing information systems. It is useful to discuss managing information systems in order to understand the development of information systems. The managerial view gives a wider picture of developing, using and terminating software.

Three complementing views of managing IT systems are represented. First, expanded systems development life cycle (ESDLC) is used to describe the entire course of the software. Second, implementing software is inevitably a change process from the old to the new solution. Together, they describe the behaviour of the solutions used in the same environment. Third, the technochange approach is introduced to explain organisational behaviour before, during and after IT projects.

238 Prahalad and Hamel: The Core Competence of the Corporation (1990) Harvard Business Review, Vol. 68, No. 3, pp. 79-91.

239 Piccoli and Ives: IT-Dependent Strategic Initiatives and Sustained Competitive Advantage: A Review and Synthesis of the Literature (2005)

MIS Quarterly, Vol. 29, No. 4, pp. 747-776.

Expanded System Development Life Cycle

The expanded Systems Development Life Cycle (ESDLC)240 illustrates modern emphasis on planning, assessing and evaluating systems. While the systems development life cycle (SDLC) consists of the system development stages, the ESDLC includes also strategic planning, integration planning, evaluation and divestment stages, as illustrated in Figure 49. The additional stages serve to extend the SDLC, which is applied to a single system, to a broader organisational context.

Figure 49. Expanded Systems Development Life Cycle

The strategic planning phase involves the development of an IS strategy. It is intended to derive from, and it is directly intended to support, the business strategies. Strategic planning consists of two major elements: (1) translation of organisational goals and strategies into data, applications and technology, and (2) assessment of “product-market” opportunities that may be supported by existing and planned information resources. Strategic planning affects in two opposite directions. The translation of organisational goals and strategies has effects on the information systems. On the other hand, information systems have influence on the business goals and strategies.

The system integration planning primarily involves the system integration functions. The need for integration was originally recognised because companies had developed information systems independently and the systems were found to be incompatible. The systems might operate effectively individually, but they could not be integrated together to provide information for other systems. System integration planning may well be carried out in the form of “information system master plan”. The “information system master plan” demonstrates the intended relationships among the various systems and subsystems, which the organisation operates or plans to develop.

The two phases after the traditional SDLC - evaluation and divestment - reflect the growing attention paid to the formal evaluation of systems and the need to terminate systems. It has been widely recognised that an information system, like any complex system, has a finite useful life span.

Planning is needed for the shutdown, replacement and phasing out of the system. In the evaluation phase, the information system is evaluated. The traditional cost, time and technical performance measures are commonly complemented with user satisfaction and business value assessments.

Change Process

A successful information system project moves a system from its current state to a desired new state241. This movement involves passing through three system stages: (1) unfreezing, (2) moving, and (3) refreezing, as illustrated in Figure 50 on the next page. The efforts needed to accomplish a stage depend upon the nature of the system, the developers, the end-user organisation, and the management actions used in the transition. Implementation involves all the project stakeholders, i.e.

240 King: Planning for Information Systems (1998)

In Cooper and Argyris (eds.): The Concise Blackwell Encyclopedia of Management, pp. 485-486

241 Chervany and Brown: Implementation of Information Systems (1998)

In Cooper and Argyris (eds.): The Concise Blackwell Encyclopedia of Management, pp. 282-283

The Concise Blackwell Encyclopedia of Management, p. 486 (adapted) SDLC

System Evaluation Divestment

Strategic Planning Integration Planning

all the people inside and outside the organisation whose work will be affected by the project; not only the developers. In addition, there are project stakeholders whose actions can change the project outcome, but whose work is not directly affected by the project.

The change process, described here from a system (or project) point of view, can also be utilised on lower levels of the information system. Instead of the application, the subject of the change can be a functional area of the application (a group of programs), a program, or a subprogram.

Figure 50. Change Process

The unfreezing stage involves gaining recognition and acceptance from the project stakeholders that the information system needs to be changed. When unfreezing a system successfully, the reasoning must be acceptable on all organisational levels. The business reasoning revolves around projected improvements in organisational performance and increase in value that the project will bring to the organisation. They can comprise increases in sales, gains in market share, reduction in costs and improvements in quality. In the individual reasoning, the interest focuses on what benefits and costs the project will produce for the individual personally, not for the organisation in general.

The moving stage involves changing the functionality of the system, which is likely a software development process in case of information system development. The specified functional requirements are implemented in hardware, software, management policies and procedures. Later, the new system will be taught to users. A successful system development project achieves the projected benefits and costs which were used as evidence in the unfreezing stage. It is not rare that the system implementation will bring with some unforeseen benefits and costs.

The refreezing stage involves ensuring that the new system becomes institutionalised. The new system creates new standards for work behaviour. The focus is on demonstrating the benefits and costs which are delivered to the project stakeholders. These benefits were projected in the unfreezing and captured by the analysis and design efforts in the moving stage.

Technochange Approach

Markus242 has studied situations in which IT projects have triggered major organisational changes.

She calls them technochange (for technology-driven organisational change). Markus claims that the technochange approach is fundamentally different from both IT projects and organisational change programs. Unlike the technical-minded IT projects, technochange involves great potential impacts on people, processes and organisational performance. On the other hand, technochange differs sharply from traditional organisational change programs, because information technology and technical methodologies are so prominently involved in it.

Technochange projects are expected to improve organisational output significantly, such as process efficiency or cycle time. Organisational change programs may have performance improvement goals,

242 Markus: Technochange management: using IT to drive organizational change (2004) Journal of Information Technology, Vol. 19, No. 1, pp. 4-20

Current Information System

Change Process

New Information System Unfreezing Moving Refreezing

The Concise Blackwell Encyclopedia of Management (1998), p. 283 (adapted)

but many are diffusely expected to enhance organisational culture or “effectiveness”. IT projects usually have narrower goals than technochange initiatives: they focus on improving technical performance (e.g. reliability, speed, functionality) and decreasing the costs (total cost of IT ownership, maintenance costs, etc.). IT projects do not necessarily require much effort from the IT users; upgrading a server might improve response times remarkably without any participation of the end-users. The differences of the approaches are summarised in Table 16 on the next page.

The technochange process includes idea generation, solution design, solution implementation and benefit capture. The process can be structured as a life cycle of sequential phases with no iteration loops. Alternatively, the process can be described as iterative series of many small cycles, indicating prototyping approach coping with limitations of the designers’ foresight. The prototyping approach can be loosely understood as trying something and using the results of the experiment as a basis for deciding what to do next. Some describe prototyping as a “plan, do, check, act” -cycle (or “design, implement, evaluate, correct” -cycle), which is repeated until satisfactory results are achieved.

Markus states that it is useful to think of technochange in terms of what happens before, during and after an IT project. Before the project, an idea of technochange is proposed, reviewed, approved of and funded. During the project, the solution is developed and technology is acquired or built. After the project, technochange efforts can be divided somewhat arbitrarily into two stages:

shakedown and benefit capture. In the shakedown stage, the start-up problems are attempted to be eliminated. The goal is to reach stable operations and make them routine. In the benefit capture stage, the expected and the unanticipated benefits are sought for. They might occur considerably after the shakedown stage when the employees learn to use the technology and fine-tune it. Not all initiatives reach the shakedown or benefit capture phases. Quite a few projects have been terminated because of shakedown problems. Also, an organisation might “declare a victory” for a technochange but stabilise operations at a lower level of performance improvement than expected.

Merely combining IT projects and organisational change management approaches does not produce the best results. First, the additive approach does not address the many failure-threatening problems effectively. Problems are likely to arise over the lengthy technochange process. Second, the additive approach is not structured to produce a good technochange solution. The technochange process means a complete intervention to business processes consisting of IT and complementary organisational changes. The technochange should provide an implementable solution with minimal misfits with the existing organisation. Finally, the organisation must be primed to appropriate the potential benefits of the technochange solution.

Markus claims that proper project management is important, but it has little to say about managing the risks associated with people’s “resistance to change”. Organisational change management believes to have the solution to the problem of resistance, because their efforts focus on the people affected by the change and the problem. Redesigning jobs or organisational structures and involving employees in the planning stages of the change are seen to benefit the change. On the other hand, organisational change management has little to say about how IT alters organisational problems.

With hard work and care, the combined IT project management with the organisational change approach can be made to work. However, an iterative, incremental approach to implementing technochange might be a better strategy in many cases. Markus claims that the essential characteristic of the technochange approach is prototyping. Each phase involves both new IT functionality and related organisational changes, which are tested in real situations. Based on the gained experience, the next prototype is created and tested, to see if it would match the requirements better.

Table 16. Technochange versus IT Projects and Organisational Change Programs

IT projects Technochange situations Org. change programs Targets Performance, reliability, project

in schedule and budget; cost of operation and maintenance

Organisational performance

improvement Improvement in performance and/or organisational culture Solution New IT solution New IT applications, often with

complementary organisational

Reduces the need of ad hoc reports requested by business

approach IT project led by Project Manager and possibly start the project by identifying the needs and

IT specialists carry out most of the work including project lead and staff the IT project meshing with other changes.

technology and suppliers Co-ordination of stakeholders in organisational change program

“Well planned is half done”, says an old wisdom. The more complicated the task is, the more planning is needed. Ultimately, the planning for information systems is expected to follow the overall business objectives. It takes place at a number of different levels in the organisation and different stages of the expanded system development life cycle. This section focuses on the general planning stages in the ESDLC, i.e. strategic planning and integration planning.

Markus: Technochange Management: Using IT to Drive Organizational Change (2004), p. 6 (adapted)

In document Procurement in Project Implementation (sivua 154-158)