Managing IT enabled change - A new approach
By Andrew Davies, Professor of Information Systems, Roger Elvin, Lecturer in
Information Systems, and John Ward, Professor of Strategic Information
Systems
It is a rare organisation today that is untouched by information technology (IT).
Indeed, many organisations could simply not function without IT -- we only have to
look at the world-wide alarm triggered by the ‘Year 2000’ problem to see this. Yet
despite its undeniable importance, IT remains the object of extreme cynicism in the
minds of many business managers. Getting value from IT investments is, for many
organisations, still a key management issue.
A common response has been to appoint an IT Director or Manager to head up an IT
function within the organisation and make her (or him) responsible for the value the
organisation obtains from its IT investment.
The problem is that actually the IT
function alone can no longer deliver value from IT. In previous IT eras, the function
was at least in with a fighting chance. There were many old, manual systems to
automate and the business environment was changing only slowly. The old-fashioned
systems analyst could identify the requirements for an IT application for a business
area simply by observing what was currently going on in it. This done, the task of
designing and building a suitable application was relatively straightforward.
This is no longer the situation. Most organisations have already reaped the benefits
available from automating old, manual systems. If we are to get value from IT
investments today, we must be prepared to adopt new ways of working. IT is the
enabler of change but it is the business change itself that delivers the benefits.
Accepting this simple truism is actually quite profound and requires us to adopt a
radically different perspective of the problem of managing projects involving IT
investment. It requires us to take a conceptual leap from managing the project as an
‘IT project’ to its acceptance as a ‘business improvement project’.
© Management Focus Issue 12 Summer 1999 (Cranfield School of Management)
More than semantics
This is far more than mere semantics. In a traditional ‘IT project’, the focus of
attention is on planning and constructing (or perhaps purchasing) an IT application.
The need to analyse requirements, to specify and design the IT application and finally
to procure or build it, drives the project. The project is likely to be managed by the IT
community with user considerations secondary to the needs of the IT development.
As a consequence, changes to working practices are often not thought through until
the IT application is ready for acceptance by the business community.
To adopt a ‘business improvement project’ perspective requires us to approach the
project in a radically different way. The IT component may still dominate in terms of
the effort and cost involved but it is now explicitly recognised that getting the planned
benefits is the overriding concern, and that this will not result until the business
changes made possible by the IT application are effected.
Implications of the ‘Business Improvement’ Perspective
0 The project should be owned and led by the business and not the IT function.
Within the project team, there should be close collaboration between the business
and IT team members.
1 The project objectives should be clearly expressed in terms of the business goals
being sought and the outcomes and benefits that need to be gained to satisfy them.
2 The design of the new working practices should be completely integrated with the
design of the IT application that enables them.
3 The project should consider explicitly how to implement the whole of the
integrated design.
4 The project scope should incorporate all activities needed to deliver the expected
benefits. This will include both change management and IT development.
5 The business must be motivated to release the necessary staff from the day-to-day
business to design and implement the business changes.
6 The management process of the project should recognise and accommodate the
inter-dependency of the project with the organisational context in which it is being
executed. This implies the possible need to modify the project’s activity, plan or
even objectives to react to unexpected and unplanned events.
7 As it is not always possible to do a complete design of the new working practices
early on in the project, the management process of the project may need to
accommodate an element of learning as it progresses.
© Management Focus Issue 12 Summer 1999 (Cranfield School of Management)
Adopting the business improvement perspective has a number of implications for the
way the IT investment should be managed (see box).
Although this has been
recognised for some years now, the methods used to manage IT investments have
continued to be dominated by current IT development methodologies that implicitly
embody the ‘IT project’ perspective. What has been lacking is a framework for
managing IT investments designed explicitly from the business improvement
perspective. Such a framework, derived from case study research with sponsoring
companies in the Cranfield Information Systems Research Centre, is shown in figure
1. This framework consists of eight steps organised into two major phases, ‘project
evaluation’ and ‘project delivery’.
Project evaluation
The purpose of this phase is to ensure that the project being considered is ‘right’ for
the organisation. A ‘right’ project is one with a clear purpose, an understanding of
what needs to be done to achieve that purpose, and the belief that the purpose is
within the reach of the organisation.
The five stages in this phase are designed to
ensure that the subsequent project delivery phase is set up with the right balance of
benefit, cost and risk and, most importantly, that this is understood and accepted by
the organisation at large.
The prime objectives of the five stages of project evaluation in summary are:
1. To determine the INTENT: to define the rationale for change and the nature of
the drivers in order to establish the objectives and initial success criteria for the
project.
2. To assess the CONTEXT: to understand the context within which the project’s
objectives have been set and identify factors which will affect the organisation’s
ability to achieve them.
3. To specify the OUTCOME: to define the particular benefits which will be
obtained by achievement of the objectives, who ‘owns’ them, how they will be
measured and to specify the types of business and enabling changes needed and
their relationships to the benefits required.
© Management Focus Issue 12 Summer 1999 (Cranfield School of Management)
4. To describe the CONTENT: to define the business and IT developments and
changes (and their interdependencies) that will have to be made in order to deliver
the benefits and to identify responsibilities for achieving the changes.
5. Complete the EVALUATION: to reconcile the implications of the outputs from
stages 2, 3 and 4 above and describe the nature of the project explicitly in order to
produce the full business case and a plan, which achieves the objectives in a
relevant timescale with an acceptable degree of risk.
Project delivery
As the name implies, the purpose of this phase is to set up a project that will carry out
the activities that will be needed to deliver the set of benefits that will realise the
objectives set by the organisation.
The principal difference between this and the ‘traditional’ IT project lies in the scope
of the activities involved. As figure 1 indicates, this encompasses not only the IT
activities (IT Content) but also the business changes (Business Content), measurement
of the benefits (Outcome) and explicit management of the Context. Furthermore, the
project in our framework is not deemed to be complete until the Intent has been
satisfied, ie the planned benefits have been realised.
The objectives of the three stages in project delivery are:
6. To construct the INTERVENTION PROCESS: to define the appropriate
approach to managing the project such that clear responsibilities are allocated for
each of the streams of activity and for co-ordinating those activities.
7. To manage the PROCESS: to carry out the activities of the project, to monitor
them and, if necessary, modify the activities within the four streams, so that they
converge to deliver the target outcomes in a timely and cost effective manner,
hence satisfying the intent, or an agreed variation of the intent.
8. To satisfy INTENT: to review the degree to which the intent has been satisfied, ie
project objectives have been achieved, both in content and outcome, and identify
reasons for any objectives not being achieved.
© Management Focus Issue 12 Summer 1999 (Cranfield School of Management)
Making the Change
The effective management of IT based improvement programmes should be a core
competence for every organisation. The new framework has already proven useful as
a diagnostic tool in making sense of behaviours and outcomes in a variety of real
projects.
However, although those senior managers, from both IT and business
functions, with whom we have discussed the new approach, can see its value, they
have usually expressed very strongly the view that attitudes will need to change in
their organisations before the benefits of the approach can be realised.
In most organisations, implicit acceptance of the ‘IT project’ perspective has guided
the conduct of IT based improvement programmes for many years. To adopt our new
approach effectively requires that the traditional distribution of responsibility and
ownership between the business and the IT function be challenged. We believe
strongly that success in exploiting the real potential of IT will go to those companies
prepared to accept this challenge head-on.
© Management Focus Issue 12 Summer 1999 (Cranfield School of Management)
© Management Focus Issue 12 Summer 1999 (Cranfield School of Management)