Estudio Cranfield Sobre ERP PDF

Organisational Issues of Enterprise
Systems Implementation
Final Report
Information Systems Research Centre
Document No: ISRC-ES-200203
Cranfield School of Management
Copyright 2002
Prepared by: John Ward with contributions from Phil Taylor, Chris Hemingway,
Roger Elvin, Liz Daniel and Alan Wright
Date: November 2002
Contact: Professor John Ward

Cranfield School of Management
Cranfield, Bedford MK43 0AL, UK
Email: j.m.ward@cranfield.ac.uk
Tel: 01234-751122
Fax: 01234-752641
Organisational Issues of Enterprise Systems Implementation – Final Report
Organisational Issues of Enterprise Systems

Implementation
Final Report
Contents
1. Introduction and overview of the issues
2. Summary of findings from the literature review
3. Synthesis of models to enable interpretation and analysis

of the issues
4. Case Studies – evidence of the value of the models

a) Electrocomponents
b) Mitel
c) A Pharmaceutical Company (APC)
d) QinetiQ
5. Findings and conclusions from the case studies
6. Research conclusions
Appendices a) Initial questions

b) Checklists/diagnostic
c) Business models and implementation issues
d) Change management challenges and issues
Bibliography

A Research Programme at Cranfield School of Management 2
1. Introduction and overview of the issues
The objective of the research project which commenced in June 2001 was to understand:
“How best to deal with the organisational issues of Enterprise Systems (ES)
implementation, in order to maximise the potential for realising benefits and minimise the
risks of adverse effects”.
For the purpose of the study Enterprise Systems are defined as:
“Systems that allow an organisation to automate and integrate major business processes
and share information and practices, both across the enterprise and with trading
partners”.
This definition includes such systems as Enterprise Resource Planning (ERP), Customer
Relationship Management (CRM), Supply Chain Management (SCM). However, the
findings may be relevant to many aspects of e-business/e-commerce such as Enterprise
Portals.
This report should be read in conjunction with two previous ISRC reports to understand
fully the rationale for the work and the conclusions drawn. Those reports are:
1. “Beyond Enterprise Systems Implementation – Realising The Benefits”, December

1999 (ISRC-MEMBER-99031)
2. “Organisational Issues of ES Implementation – Literature Review”, July 2001

(ISRC-ES-200105)
The conclusions from the former were the basis for many of the detailed issues and
questions studied in this research. The conclusions from the latter are included in
summary here but readers should refer to the report to understand the development of the
arguments and a full set of references to the literature used.
The early workshops in the project defined an overall context model within which 5
themes of organisational issues were identified. The focus of the research was on the
business and IT management of ES initiatives and particularly the role and contribution
of senior management in ensuring the best approach is adopted, in terms of the
organisation being able to deliver the intended benefits of the investment. All the
literature concludes that ES projects rarely fail due to “technical issues”, especially when
proven enterprise software packages are used. It is usually organisational issues and
conflicts, based on different stakeholder interests and perceptions, that lead to failure or
disappointment with the benefits realised. Figure 1 shows the overall context model for
the research – the research was concerned with all the components of the model except
the IS/IT ‘box’.

Business Management
existing
Competence/ Management Learning/
capability processes adaptation
new
IS / IT Management
Enables or inhibits changes
Business Processes IS / IT
Organisation Business Technologies
Communications Hardware
processes
Roles Software
Relationships Data mgmt.
Rewards/controls Network
Skills IS / IT
Capacity etc.
Behaviours processes
Figure 1: Organisational Issues – ES Implementation
From the initial workshops, 5 themes of study were identified:
1. Business Models
2. Organisational Issues and Stakeholder Management
3. Implementation Approaches
4. Organisational Learning
5. ES Programme Management
For each a set of questions were developed to guide the review of the literature and the
identification of relevant material and case studies. These are included in Appendix A.
There has been a considerable volume of literature, books as well as academic and
practitioner papers and reports (mainly from consultancies), about ES and in particular
ERP in the last 5 years. As will be seen in Section 2, some of the questions were quite
well addressed by existing literature but others were not. The research concentrated on
filling the gaps in knowledge by building on previous writings and current best practice.
Equally importantly the research attempted to focus on the issues particular to enterprise-
wide projects, rather than reiterate ‘best practice’ for major IT-enabled change
programmes. As such, the work included relevant ideas, frameworks and results from
previous ISRC projects – Advanced Benefits Management and IT & Change (Phases I
and II) – that addressed the more general issues. Whilst much of the literature deals with
ERP and SCM implementations, where there is a considerable base of experience and
knowledge, the research has attempted to adapt that set of knowledge for emergent new
areas such as CRM.

The key characteristics of an ES implementation that the research has attempted to

address are:
- the breadth of scope across the business functions

- the organisation-wide impact, especially in multi-unit, multi-national, multi-cultural
businesses
- the complex relationship between the changes in systems, processes, roles,
organisational responsibilities and performance measurement that have to be
managed concurrently to deliver the benefits
- the issues that arise due to the long duration of the project during which the business
context changes and often key stakeholders (and their perceptions) change
- the relationships between the project team, the many line managers involved and
senior management (as individuals and a team), which will determine how the
project is conducted and the extent to which the project remains a business initiative
or becomes an ‘IT project’.
- the role of senior executives in ensuring that the intent of the investment is
appropriate, clearly defined and communicated throughout the organisation to
engage the required stakeholder behaviours during the project.
These are issues that need particular attention in an ES implementation, given the risks
involved, the potential benefits achievable and the normally high costs and implications
of the major deflection of resource use required, from ‘business as usual’ to the change
programme. At the same time organisations normally have a lot to learn, not only about
the ‘system’ but also about how their business actually works, and especially how it can
perform better when it is supported by integrated information and systems. They also
have much to learn about their capability to make major changes effectively, when the
outcome is often uncertain in terms of overall impact on the organisation and business
performance.

2. Summary of findings from the literature review
This section presents a summary of some of the main points from the literature review
“Organisational Issues of ES Implementation – Literature Review” (ISRC-ES-200105).
Readers should consult this document if more detail is required.
ES may be characterised by high levels of process, information and organisational

integration, with the potential for major benefits as a consequence of the integration.
However, integration implies change, and the way in which the organisational integration
is handled will have a profound effect on the ability to realise benefits from the
implementation e.g. how to move from functional working to cross-enterprise or inter-
enterprise working. A major theme within this ISRC research project was that the success
or otherwise of such ES-related organisational change will be profoundly affected by
management processes and competences, prior to, during, and post-implementation.
This viewpoint of management processes and competences being the key to success in
ES implementation received some support within the literature (Bancroft et al 1998,
Davenport 2000). However, most of the literature only acknowledged management issues
in terms of senior management commitment in relation to implementing the ES itself.
Whilst there was general agreement that active senior management commitment was
critical to success, there was much less recognition of how management addressed the IT
and business changes throughout the implementation affected the benefits delivered.
The existing literature was reviewed in relation to these five themes described in section
1, in order to find specific answers where possible, and to inform the overall research
question and themes. In addition, the literature review helped to highlight areas which
were considered important, but which were poorly covered by the literature, thus
requiring further research to be undertaken.
The following sections are structured in accordance with the five themes, with each
section presenting an overview of the literature in relation to that theme, with a summary
of specific answers to the research questions where such answers were available. A table
for each section shows how well (or not) the literature covered the detailed research
questions.

2.1 Business models literature
Literature coverage of the research questions within this theme:
How well does the literature

Issues address the issues?
None/poor/OK/good/exc.
1.1 What organisational attributes (e.g. management processes,
competences, organisational integration) are implied and assumed
to be present within the business models on which ES are built? OK
(Implies customer and supplier interfaces as well - How to carry
out a business model matching assessment?)
1.2 What are the consequences for an organisation which does not have
these attributes at the outset, and how to determine the level of
Poor
mismatch? (How to measure % fit and % non-fit – then how to
decide on trade off between benefits required and constraints.)
1.3 How can an organisation best take on these new business models in
order to take full advantage of the benefits which the ES package Poor
offers?
1.4 How will an ES enable or constrain organisational flexibility and

Poor
adaptation? (Flexibility – is relative to the existing systems.)
1.5 How does the understanding of the fit between the package business
model and existing business model at a) Executive Level &/or b) None
Operational Level affect success?
Overview
The assumption behind this section of the literature review was that ESs contain business
models which may or may not be a good fit for an implementing organisation, and
therefore there might be potentially serious consequences for an organisation if “misfits”
occur. Also, the assumption was that the business models within the ES may be based on
organisational and managerial attributes which may not be present in an implementing
organisation e.g. a co-operative information sharing culture, or a highly disciplined
management style. These issues were not well addressed by the literature, or they were
addressed in an indirect way.
At first glance, the comparison of ES business models with the current and required
business models for an organisation appears to be a straightforward exercise. Model the
current organisation, or required organisation, and compare this to the functionality
offered by the ES. However, the reality is far from straightforward. As Lee & Lee (2000)
point out from a knowledge transfer perspective, ES contain not only reference models
encoded in the software (explicit knowledge), but also assumptions about established
ways of doing business which are not made explicit (tacit knowledge). Difficulties have

also been expressed in IS and knowledge management literature in terms of eliciting tacit
knowledge from within the organisation itself. A further complication is the difficulty of
envisaging the required future organisational state in sufficient detail to be modelled. In
short, the situation is “not knowing what you don’t know” – either about the ES or about
the organisation itself.
Modelling business processes as a basis for selecting an ES is established practice (e.g.

Davenport, 2000). Decisions can then be made as to how to deal with mismatches in
business processes and/or functionality. Soh et.al (2000) explored the idea of “misfits”
between ERP package functionality and organisational requirements, against a
background of cultural differences. However, they did not look deeper at into the
underlying business models.
One aspect of business models is organisational culture, and Krumbholz et.al (2000) have
attempted to model both organisational and national cultures using the business process
modelling tools currently used within ERP implementation. They seek to establish how
differences in culture can influence ERP implementations, and are currently extending
the work to include cultural analysis of an ERP supplier.
Looking deeper at the organisational attributes which an ES assumes to be present,

Davenport (2000) offers some general guidance, starting with the ES presumption that
information will be centrally monitored and that there will be an organisational hierarchy
i.e. elements of “command and control” - despite modern management theories of
empowerment and decentralisation. He discusses the changes in management that are
likely to take place through ES implementation, leading to greater managerial discipline
and accountability. A big change in this respect is that managers can no longer hide poor
results, since other managers can get the same performance information, reported without
human intervention or manipulation. However, he does not discuss the consequences for
ES implementation of laissez-faire managerial practices.
Bancroft et.al also recognise that ES (SAP R/3) assume a top-down, centralised approach,
which may not be appropriate in all cases. They recommend that reengineering be
undertaken in order to model the “to be” required state of the business, preferably before
the implementation. They consider that misfits of the ES against business needs will
occur. They discuss how management practices may change as the ES is implemented,
especially in terms of changing business performance metrics and realigning personal
incentives.
Summary of specific answers to the research questions (where available)
2.1.1 What organisational attributes (e.g. management processes, competences,

organisational integration) are implied and assumed to be present within the
business models on which ES are built? (Implies customer and supplier
interfaces as well - How to carry out a business model matching assessment?)

Both Davenport and Bancroft note that ES such as SAP are built around a centralised
“top-down” approach to managing an organisation. An organisational hierarchy is
assumed to exist, with centralised monitoring of information. The further an organisation
deviates from this “norm”, the more problems may be expected, i.e. a highly
decentralised organisation with empowered, autonomous operating units.
According to Bancroft, management practices will need to change as a result of the ES

implementation. A new emphasis on performance management may be required, with
KPIs and performance measures aligned with incentives, rewards and recognition.
Davenport adds that greater management discipline and accountability may result from
the implementation, as information becomes more transparent and consistent, with “no
place to hide”.
In terms of modelling the organisation and the “to-be” state, Bancroft states that some
degree of re-engineering will have to occur, even just to accommodate the new system.
This warns against simplistic “systems replacement” projects. Inevitably, misfits between
the requirements and the system capabilities will occur.
Bancoft proposes that ES implementation skills may themselves become a unique

competence, even possibly leading to enhanced competitive advantage. Such
implementation skills will involve a complex mix of business, communications,
organisational and technical skills, and will result in a detailed knowledge of how the
business really operates.
2.1.4 How will an ES enable or constrain organisational flexibility and adaptation?

(Flexibility – is relative to the existing systems)
Flexibility is potentially a very vague concept, and Davenport suggests that a key
question should be “Flexibility – compared to what? – existing legacy systems or a future
ideal?” He notes paradoxical consequences, that whilst the tight integration of ES and
business may makes it difficult to implement further changes, there is only one system to
change, which is easier than having to change many legacy systems.
From the viewpoint of enhanced overall organisational flexibility, Davenport notes that
some organisations with ESs have found it easier to take on mergers and acquisitions, and
to exit businesses through spin-offs and divestitures.

2.2 Organisational issues & stakeholder management literature

2.1 What are the organisational issues which have to be dealt with in an
ES implementation, what are their levels of importance, and how
best to deal with these issues? (‘major’ issues that ‘always’ have to OK
be dealt with. - Which issues are ‘corporate’ and which are
‘local’.)
2.2 How best to reconcile differences in objectives, expectations and
perceptions amongst stakeholders? (ascertain and reconcile’ - OK
should include ‘measurement of performance’. When best to do
it?)
2.3 What are the drivers for integration, and is there potential conflict
over the importance of the drivers? E.g. common processes,
consolidated financials. (Why integrate? – what specifically is to
be gained by integration – not generalities.) Poor
2.4 What degree of integration and standardisation is being sought?
(How to be explicit about this so that the consequences can be
understood?)
2.5 What do senior management need to understand, especially at the
start of an ES programme? (how ‘senior management’ can have a
comprehensive understanding of the realities of what will happen)
2.6 What form should senior management commitment take, and how OK
should this be demonstrated?
2.7 How to ensure the full support of senior management in
implementing ES-enabled cross enterprise working?
2.8 How to deal with information, data and process ownership – when
there is only 1 integrated system? (Is a very important issue which Poor
is often ignored – too sensitive?)
Overview
The central theme of this research project is that success or failure of an ES and the
organisation using it is likely to be determined by the organisational issues surrounding
implementation, and on how they are dealt with, rather than the ES itself. Major issues
addressed within this section of the literature review include organisational issues in
terms of differences in objectives, expectations and perceptions amongst stakeholders,
and the role of senior management in ensuring the success of an ES implementation. ES
implementation will be accompanied by organisational change, to a greater or lesser
extent, and as such it will be seen as a political process by stakeholders within the
organisation. The ES literature was therefore supplemented here by a review of literature
concerned with organisational power and politics approaches to understanding IS

implementation. In this manner, preliminary answers to the questions posed above have
been gathered, despite the current lack of literature which directly addresses these issues.
Specific answers to the questions posed above are given in the next section, after a brief
review of the overall themes / strands from the literature.
From the ES literature, Davenport (2000) offers some general guidance on organisational
structure issues, centralisation vs. decentralisation, and data ownership. He provides
guidance on addressing ES-enabled organisational integration issues, and highlights the
roles of the senior executive sponsor. In a previous paper (1998) he stresses the need to
consider ES/ERP in primarily strategic and organisational terms, stressing the enterprise,
not the system. Wah (2000) stresses that managers must address the cultural side of
change when implementing ERP, especially managers “turf mentality” fears. Austin &
Nolan (1998) suggest that ERP initiatives should be managed as new ventures, not IT
projects, especially through risk sharing and incentive alignment amongst key
stakeholders, including senior managers, line managers, ES supplier and consultants.
Avital & Vandenbosch (2000) provide an unusual way of considering the organisational
issues of ES, in a case study written as a play. Bancroft et.al (1998) provide guidance on
how to deal with the organisational issues, especially senior management commitment
and stakeholder management.
Closely related to ES, Overton et.al. (1996) outline various political games which may
get in the way of EIS implementation, especially when senior management leadership
and commitment are lacking. Most of these political games appear to be directly relevant
to ES also. Moving into the domain of supply-chain management, Whipple & Frankel
(2000) explore the success factors for strategic alliances in co-operative supply chain
alliances. They conclude that the top 5 success factors are: trust, senior management
support, ability to meet performance expectations, clear goals and partner capability.
Though not directly from ES, these findings also seem relevant to ES implementation.
In the field of organisational power, politics and IS, Hislop et.al (2000) look at 2 case
studies of the early stages of ES implementation, from a viewpoint of networks,
knowledge and power. They note that the development and utilisation of networking and
knowledge resources were not only necessary for implementing change, but that these
aspects were also used as political tools within the process. Thus knowledge, networks
and power are inextricably interlinked in ES implementation.
Sillince & Mouakket (1998) studied an IS implementation in the context of university

management, an ES in its broadest sense, from a power and politics point of view. They
were particularly interested in the overt use of divisive and integrative political strategies
by the software developer. They distilled 5 theoretical perspectives on organisational
power, noting that not only could different interpretations exist, but also that stakeholders
may utilise different perspectives at different times. They suggest that holding such
multiple perspectives enables the generation of politically feasible ways of resolving
problems.

Cavaye and Christiansen (1996) outline a way of estimating the power of various groups
within an organisation, prior to and during an IS implementation. This is based on old
theory, but may be useful as an extension of stakeholder analysis. Knights and Murray
(1992) examine the power, identities and career implication of those involved in IS
implementation, from a socio-political viewpoint. They suggest that the manipulation of a
socially constructed reality is part of the tools of politics, through which individuals gain
a sense of reality, meaning and identity in relation to technology and the market. Within
this viewpoint, ES must be comprehended through the organisational and political
realities of managers, who at the same time can (re)construct and manipulate those
realities. Coombs et.al (1996) take the ideas further, and suggest that culture, control and
competition are concepts which highlight the key dimensions of the social processes of IS
implementation.
Kumar et.al (1998) studied the underlying rationalities of IS within (and between)
organisations, providing a viewpoint which provides insight into the organisational issues
of ES implementations. They note two opposing rationalities from the IS literature:
system rationalism (all stakeholders subscribe to the goal of maximising economic
efficiency and effectiveness) versus segmented institutionalism (individuals and subunits
work to achieve their own objectives i.e. a political view) They then contribute a third
rationality of relationships and trust. Within an ES implementation, all three perspectives
may exist, in different strengths and at different times.
Robey and Boudreau (1999) seek to extend the theoretical basis underpinning IT related
change, going beyond the simple deterministic logics of “IT enables org.change”. They
propose a logic of opposition as more appropriate – forces promoting and impeding
change, and review 4 theories within this context: organizational politics, organizational
culture, institutional theory and organizational learning.
2.2.1 What are the organisational issues which have to be dealt with in an ES
implementation, what are their levels of importance, and how best to deal with
these issues? (‘major’ issues that ‘always’ have to be dealt with. - Which issues
are ‘corporate’ and which are ‘local’
A comprehensive listing of the organisational issues which have to be dealt with in an ES

implementation has not been compiled from the literature. There are many differing
viewpoints on what the issues are, and it was felt that a better approach was to identify
the issues through analysis of real-world case studies in the research programme.
A useful high-level summary of the organisational issues is provided by Bancroft,

quoting from an SAP R/3 implementation team at Monsanto, as follows:
- Leadership enrolment
- Communications
- Training

- Organisational roles and structure

- Performance management
- Management practices
2.2.2 How best to reconcile differences in objectives, expectations and perceptions

amongst stakeholders? (ascertain and reconcile’ - should include ‘measurement
of performance’. When best to do it?)
Bancroft states that agreement on the future operating model for the business must be
obtained before an ES implementation may proceed further. Such agreement may be
facilitated by executive briefings with question and answer sessions, helping to clarifying
the underlying issues and dealing with any concerns.
Overton, writing about the implementation of executive information systems, recognises

that a variety of “political” games are likely to ensue within an organisation if the
organisational issues are not properly managed. He suggests the following ways of
recognising & dealing with political games:
For senior managers:

- analyse the political situation
- pinpoint resistance
- proactively obtain or compel support from resistors
For EIS implementors:

- maintain a tactical & operational political inventory
- be aware of politics & turf issues
- obtain co-operation or non-interference
- use senior management influence if necessary, but with care
Austin and Nolan propose a novel approach to ES implementation, treating the ES in a

similar manner to a new business venture. In accordance with such an approach,
differences in perceptions and goals amongst stakeholders should be managed through
risk sharing arrangements, and by incentive alignment for all parties.
2.2.3 What are the drivers for integration, and is there potential conflict over the
importance of the drivers? E.g. common processes, consolidated financials. (Why
integrate? – what specifically is to be gained by integration – not generalities)
2.2.4 What degree of integration and standardisation is being sought? (How to be
explicit about this so that the consequences can be understood?)
There was generally very little material within the literature on specific drivers for
integration. The unquestioned assumption in much of the literature seems to be that
integration is a “good thing”, to be pursued in its own right.
Davenport notes that organisational integration, or lack of it, is a common organisational

problem in ES initiatives. ES initiatives often fail to achieve the desired level of

organisational integration, in many cases due to a simple misunderstanding that having an

integrated system does not bring organisational integration on its own. He suggests the
following ways of addressing problems with ES-enabled organisational integration:
- Education – managers need to know the implications

- Obtaining consensus on the need for & pace of integration
- Developing a strong sense of “who we are”, and linking this to questions about “what
will integrated organisation look & feel like?”
- High level executive support and strong commitment
Bancroft notes that “There may be a major disconnect between the strategic intent of a
decision to implement a certain system and the resulting actions that must be completed”.
This is particularly true where the strategic intent is to achieve greater organisational
integration. He suggests the following ways of avoiding such a disconnect:
- strategists need to understand the detailed implications

- implementors need to understand the overall strategic context
- political expertise will be required by both strategists and implementors
- expectations must be managed
2.2.5 What do senior management need to understand, especially at the start of an ES

programme? (how ‘senior management’ can have a comprehensive
understanding of the realities of what will happen
2.2.6 What form should senior management commitment take, and how should this be
demonstrated
2.2.7 How to ensure the full support of senior management in implementing ES-enabled
cross enterprise working
According to Davenport, the executive sponsor for an ES implementation should be a

senior business executive, in many cases the Chief Executive, rather than an IS manager
or director. Senior business executives need to learn the implications of ES for strategy,
organisation, business process and competitive capability. Roles of the executive sponsor
include:
- relate the system to the overall strategy of the organisation

- communicate value & importance of project to rest of organisation
- develop & advertise performance improvement objectives
- enforce inevitability of system & related processes
- create necessary organisational changes
- ensure implementation proceeds on schedule
Overton proposes the following guidelines for senior management, in order to avoid
political game playing by managers in an EIS implementation:
- committed sponsorship – visible / demonstrated

- empower EIS developers – appoint a powerful, competent operating sponsor, clear

responsibilities / authorities
- define clear specifications – clear, specific, enforceable objectives & progress
- political awareness – be prepared to deal with organisational politics & resistance
Bancroft notes that senior management commitment and support can be actively
demonstrated through the steering group for the implementation. This steering committee
should include the major stakeholders, and members should be given suitable ES and
change management training.
Dong (2000) notes two different types of commitment from senior management. The
first, top management commitment to resources (TMCR) describes the extent to which
top management is determined to provide enough financial and technical resources. The
second, top management commitment to change management (TMCC), depicts the extent
to which top management will support the necessary business changes.
Knights and Murray (1992) do not provide a direct answer, but they imply that the
implementation of systems such as ES are themselves part of the politics of organisation.
An important role for senior management, then, is to create an official “ideology” within
which the ES makes sense of the members of the organisation.
2.2.8 How to deal with information, data and process ownership – when there is only 1
integrated system? (Is a very important issue which is often ignored – too
sensitive?)
Davenport discusses data ownership and management. In his view, the key issue is not
who can make changes to the data, but rather who has accountability for those changes.
He also briefly discusses centralised vs. distributed data management, though most ESs
assume a centralised database.

2.3 Implementation approaches literature

3.1 What are the current implementation approaches being practised,
what are their strengths and weaknesses, and how are they being
applied?
OK
*Need to be clear about what is different about ES
3.2 What is their coverage of the people and organisational issues, and
do they explicitly identify and deal with them?
3.3 What roles and competences are required by the approaches?

Poor
(see also ES Programme Management – Q4)
Overview
This section of the literature review sought to find out to what extent current
implementation approaches address organisational issues, rather than just dealing with
the technical implementation. Literature in this area tends to fall into two groups, the first
group dealing with practical implementation issues (e.g. Bancroft et.al,1998), and the
second group proposing theoretical approaches (e.g. Deloitte,1999). However, neither
group provides strong evidence for what approaches are actually being practised. This
information may come from case studies or from consultancy organisations.
Bancroft et.al.(1998) provide specific guidelines for implementing SAP R/3. Much of the
content deals with technical issues, but the authors also stress that a focus on technical
implementation alone is not sufficient for successful implementation and they provide
guidelines on dealing with the organisational issues. Davenport (2000) provides some
advice on implementation, especially a need to focus on outcomes and benefits.
Austin & Nolan (1998) argue that traditional IT project management is not a good fit for
ES implementation, and they propose that it should be treated more like a new business
venture. Deloitte consulting (1999) propose that “going-live” is not the end of ERP, but
rather a beginning, and they advocate undertaking a “second-wave” of activity post-
implementation to gain further benefits. The Impact (1998) guidelines, written for
software package implementation, propose that an implementation should be broken
down into a succession of cycles or “interventions”. Wilcocks and Sykes (2000) focus on
the role of the CIO and IT function in ERP, and they propose a set of nine core
capabilities which must be present for successful ERP implementation.

Wentworth/Gartner (2000) looked at CRM implementation, concluding that an

incremental approach is required.

2.3.1 What are the current implementation approaches being practised, what are their
strengths and weaknesses, and how are they being applied
2.3.2 What is their coverage of the people and organisational issues, and do they
explicitly identify and deal with them
Though several implementation approaches are proposed in the literature, there is little
evidence of what approaches are actually being used in practice.
Bancroft outlines an overall approach which explicitly addresses the organisational

issues. However, the use of an explicit methodology is also recommended to address the
implementation details. Critical success factors within the overall approach are:
1. Understand your corporate culture in terms of readiness and capability for change.
2. Begin business process changes prior to implementation. Make the hard decisions
early and stick to them.
3. Communicate continuously with all levels of new users in business, not technical
terms. Set reasonable expectations. Then communicate again.
4. Provide superior executive championship for the project.
5. Ensure the project manager is capable of negotiating equally between the technical,
business and change management requirements.
6. Choose a balanced (IS and business) team, and provide it with clear role
definitions. Expect to shift to non-traditional roles.
7. Select a good methodology with measurements.
8. Train users and provide support for job changes. Don’t forget to train the project
team.
9. Expect problems to arise: commit to the change.
Deliotte Consulting advocate a “second wave” of effort to maximise the potential

benefits, following on from the actual implementation of an ES. This approach offers 12
“best practices”, as follows:
1. Focus on capabilities and benefits, not just on going live.

2. Align the organisation on the true destination.
3. Achieve balanced people, process and technology changes across all areas.
4. Use the business case as a management tool.
5. Apply planning and programme management practices throughout the programme
lifecycle.
6. Transition project roles into a way of life.
7. Build and leverage process expertise.
8. Extend capabilities beyond the ERP foundation.
9. Promote post-implementation commonality.
10. Teach the organisation to use the new capabilities.
11. Assign clear ownership of benefits.
12. Define metrics and manage to them.

The Impact programme looked particularly at software package implementation,

including examples of ERP implementation. They redefine such implementations as
“software package enabled business improvement projects” (SPEBI), and advocate the
following critical success factors:
1. Define the project intent, and design the project to optimise the short and long-term
benefit/cost/risk trade-offs.
2. Construct the project management organisation to provide strong leadership and
ensure clear accountabilities for all aspects of the project.
3. Get to know the package and the vendor very well before the buy decision and
build a close but commercial relationship with the vendor.
4. Select, direct and motivate a team that has the right mix of business and technical
competencies (i.e. skills, experience and interpersonal attributes)
5. Manage the politics of the project, especially the expectations and challenges posed
by choosing to use a package.
6. Deploy a range of effective management and technical processes during the life-
cycle of the project.
Austin & Nolan consider that ERP initiatives are more like new business ventures than IT
projects, due to their size, cost and risk profile. They propose that three key principles
from the management of new business ventures should be adopted for ES
implementation:
- Make the investment in stages

- Sharing risks amongst stakeholders
- Focusing on the creation of a talented, high-performance team
2.3.3 What roles and competences are required by the approaches?
The roles required for ES implementation are outlined within some of the literature, but
the underlying competences are generally not dealt with. Bancroft notes that a mix of
generic business, communications & organisation skills, will be required, in addition to
knowledge of the unique and specific technologies. Willcocks and Sykes explicitly deal
with the competences required by the CIO and IT function, and suggest that the following
nine competences are required:
1. IT leadership
2. Business systems thinking
3. Relationship building
4. Architecture planning
5. Technology fixing
6. Informed buying
7. Contract facilitation
8. Contract monitoring
9. Supplier development

2.4 Organisational learning literature

4.1 How best to foster organisational learning, within and subsequent
to an ES implementation? (overall question)
4.2 How to take advantage of new and emergent capabilities?
&/or how to know when/how to adapt the system/processes to

emergent needs?
Poor
4.3 How to embed this learning into business operations?
4.4 How to embed this learning into future change management,

thereby reducing the risks of further phases of ES implementation?
4.5 How to achieve significant learning by senior management, quickly,
at the start of the project? (see 2.5 - May be critical factor in
causing more attention to be focussed on learning?)
Overview
This section of the literature review was concerned with organisational learning in its
widest sense – ultimately learning how to improve business performance through ES.
Whilst training was acknowledged as important by many authors, fostering overall
organisational learning was hardly covered at all in the literature.
Davenport (1998) points out that an enterprise system is not a project, but a way of life,
imlpying that the organisation will have to learn to live with it, and with further changes
and updates. In another 1998 article he argues that few organisations are focusing on
gaining useful management information from their ES, again implying that learning is
required to use the information available in order to add value to the business. Bancroft
et.al (1998) recognise that even within the implementation project, training is not enough
in itself, and that the project team should be given time to learn by experimentation.
Lee and Lee (2000) take a knowledge transfer perspective, suggesting a two stage process
of implementation and internalisation. However, they do not explicitly link internalisation
with organisational learning. Robey and Boudreau (1999) suggest that organisational
learning is one way of conceptualising IS implementations, and that IS can both enable or
disable organisational learning. Perhaps we may expect similar effects from ES
implementation – both enabling and disabling organisational learning.

There was not enough material within the literature to be able to provide specific answers
to the questions posed.

2.5 Programme management literature

5.1 How to bring separate ES initiatives together and manage them as
None
an overall programme? e.g. CRM, ES, SCM.
5.2 How to break an ES programme down into suitable stages/phases –

to maximise speed of benefit delivery?
OK
5.3 How to start up an ES programme, taking into account different
generic “starting points”?
5.4 What adaptation needs to take place over time to respond to

None
changes in needs, organisation and team composition?
5.5 What are the risk factors which must be managed in order to realise
the potential benefits and avoid the potential downsides in an ES
OK
implementation, in particular risks arising from organisational
issues?
5.6 How to ensure a continued focus on benefits realisation, and not be

Poor
distracted by events etc?
5.7 How to develop a communication strategy which reduces the risks

OK
of problems during implementation?
Overview
This section of the literature review sought to address issues which are best considered
under the broader theme of managing ES as a programme of business and technological
change initiatives. This area was not well covered by the literature, which in most cases
tended to treat ES as a single implementation project, albeit with a series of stages or
phases.
Boddy and Macbeth (2000) studied supply-chain partnering projects, and concluded that
many commonly recommended prescriptions for managing change were insufficient to
ensure success. They found that the four areas which did positively influence project
success were: ensuring agreement with goals, creating structures to manage the change,
ensuring adequate resources, and setting up adequate controls.
Markus et.al (2000) studied multiple dimensions of success within the different stages of
ES implementation. They concluded that success within one phase e.g. the project phase,
was not a guarantee of success within later stages e.g. onwards and upwards. Also, lack

of success within the project phase did not necessarily prevent success in the onward and
upward phase. They acknowledged the importance of an initial chartering phase, to deal
with pre-existing organisational challenges.
Sterling (1999) suggests that program management should be used when implementing
ES, rather than project management. However, little detail of the process was given.
Sumner (2000) studied the risk factors which should be taken into account within ES
projects, based on generic IS project risks, and on the risk factors present within case
studies of ES implementations.
Bancroft et.al considered that the major risks come from the organisational issues which
have to be dealt with. One section of their book is titled “Mitigating the risk”, and deals
exclusively with organisational issues. Communications issues are explicitly dealt with.
2.5.2 How to break an ES programme down into suitable stages/phases – to maximise

speed of benefit delivery
2.5.3 How to start up an ES programme, taking into account different generic “starting
points”?
Several authors propose classifications of the stages of an ES implementation, with

Markus providing the clearest set of project phases as:
- Chartering (planning) phase

- Project phase
- Shakedown phase
- Onward & upward phase
Within these phases, guidance is given as to the major activities, implications of phase
activities for success in phase and later, common problems, and phase success measures
(see the literature review for details)
This classification provides an explicit acknowledgement that immediately after the “go-
live” part of an ES project, there are usually problems to be sorted out. The extent of
these problems and the duration of the shakedown phase may well be dependant on how
well the organisational issues have been dealt with in the chartering/planning and project
phases. Markus notes that there may be pre-existing organisational challenges which can
threaten the success of an ES implementation, and that these challenges should be
addressed by senior executives at the chartering/planning stage, including:
- Lack of results orientation in the business

- A culture resistant to change
- Top management not buying in to the goals and plans of the ES project

Davenport discusses the phasing of an ES implementation in terms of geographical,

process based, and business unit phasing. He also discusses the merits of “big-bang”
implementation versus a slow roll-out of features, or a mixed approach.
2.5.5 What are the risk factors which must be managed in order to realise the potential
benefits and avoid the potential downsides in an ES implementation, in particular
risks arising from organisational issues?
In Bancroft’s opinion, the risks in an ES implementation are synonymous with the

organisational issues. Mitigating the risks therefore equates to dealing with the
organisational issues. Sumner sets out the risk factors which should be taken into account
in ES projects (see literature review). However, this study focused on risks from a project
point of view, rather than overall business and operational risks.
2.5.6 How to ensure a continued focus on benefits realisation, and not be distracted by
events etc
Benefits realisation was not well covered within the literature. Davenport recognises the
central importance of focusing on outcomes and benefits, and provides the following
guidance:
- Treat ES as a business project, not a technical one.

- Clearly defined (business) objectives
- Monitoring achievement of (business) objectives
- Business executives in charge
- Make organisational changes necessary to achieve benefits
Deloitte proposes that benefits realisation should be the major focus of a “second wave”
of effort, recognising that in many cases the initial implementation is focused on getting
the technology implemented, rather than on realising benefits.
2.5.7 How to develop a communication strategy which reduces the risks of problems
during implementation?
Bancroft deals with the communications issues, starting with the need to develop an
overall message that people in the organisation can relate to and buy in to. This may be in
the form of a mission, a vision, or a set of guiding principles, which will help to focus the
steering & project teams, and become the essence of communications with user
community. Communications messages should come from the highest level project
sponsor, as well as the management chain responsible for individual members of staff.
The communications effort should cover:
- Overview and rationale for the project.

- Explanation of the business process changes.
- Explanation of the implications of these changes
- Demos of applicable modules if possible

- Briefings of change management issues.

- Establishment of individual’s contact person.
- Testing of scripts and scenarios as they are made available.
- Periodic updates.
- Type of and schedule for training available

3. Synthesis of models to enable interpretation and analysis of the issues
From the literature review and previous ISRC projects, a number of useful models
emerged which were directly relevant to the issues and questions being studied. Through
an iterative process of testing and examining the potential inter-relationships of the
models at project workshops, a potential pattern of how they could be used together was
synthesised. The models were then used as the basis for collecting and assessing
evidence from the case studies (see section 4) to determine whether or not they were of
practical relevance. Could they explain why organisational issues were addressed
successfully in some cases and not in others? The purpose of this section is to explain
how the models can be brought together to understand how to address the organisational
issues and the consequences of failing to deal with them adequately.
In each case the original concepts have been slightly adapted to provide consistency in
language, sufficient to enable a comprehensible synthesis. Each model is briefly
explained and depicted to aid understanding and the synthesis considers how the models
can be brought together.
The overall structure of this section can be considered using the following flow chart:
From literature
3.1 ES Stage From ABM
Model (Markus et al)
3.2 Modes 3.3 Managing

Conflict of interest
of IT Behaviour
(Kumar
et al)
3.4 Synthesis of From

models of 3.2-3.3 IT&C
3.5 Overlay 3.5 Change Process

synthesised model Management
and relate to stages
(Simon) From ABM
3.7 Summarise & 3.6 Perceptions of

conclude change and project
negotiations

3.1 Stage Model
ENTERPRISE SYSTEMS - STAGE MODEL (after Markus et al)
Overall
Future
Business
Business
Strategic
Vision
Intent
Initial
ES Vision
New
Business ES -
Baseline Revised Revised
Problems Strategic
“without Intent ES Vision
& Constraints Intent
problems”
IMPLEMENT RE IMPLEMENT
PLAN SHAKEDOWN
Phase I PLAN Phase II
ONWARDS & UPWARDS
‘PROBLEM BASED’ ‘INNOVATION BASED’
Figure 3.1
The model in Figure 3.1 is derived largely from the work of Markus et al (2000), but
many others have proposed or observed the ‘2 phase’ approach but with a varying
number of stages (e.g. Deloitte’s model has 5 stages).
The overall rationale is as follows:
1. At the start of the initiative the main issue is to be sure how the ‘vision’ of the ES
implementation fits with the future business vision, with a clear understanding of how
the business strategy will produce the vision. There are two extreme possibilities in
relation to the ES
a) it is the implementation of the ES that will provide a new business model on which
the vision is based – this probably implies major business and organisational changes
are needed.
b) the business model to match the vision is known and the ES is required to make it
operational – implying that there will be trade-offs between the ideal model and the
business model provided by the ES.
However, most implementations are likely to be a mixture of the two, but clarity is
needed concerning where the ES business model and associated functionality will

drive organisational change and where the organisation’s business model cannot be
compromised.
A cause of some ES failures is that the ES business model is not understood and the
organisation adopts processes and systems which do not fit its business model. This
will tend to produce changes to the ES software during the implementation in order to
reproduce the old business model.
Issues at this stage that need to be resolved involve the current and future business
model and how well the ES business model fits with both. Unfortunately, often, “the
devil is in the detail” and current business problems and constraints to achieving the
ES vision are overlooked. As Bancroft et al (1998) state “There may be a major
disconnect between the strategic intent of a decision to implement the system and the
resulting actions that must be completed”.
2. As planning commences, often the problems to be resolved and constraints to be

overcome become more apparent and the intent has be scaled back to become ‘a new
baseline’, where the existing problems and inhibitors to more innovative change have
been removed. This accepts the logic of others that it is difficult to operationalise a
new vision when surrounded by current problems. Equally, different stakeholder
groups will be at different stages of development in terms of the capabilities of
existing systems. Those with excellent existing systems will have a different
perspective on the need for and nature of the changes required compared with those
with poor systems who have much to gain simply by replacement to remove problems.
How these stakeholders resolve such issues is considered later, but the compromise
usually errs on the side of bringing the weaker areas up to the new baseline and
deferring the riskier and more innovative changes.
Another key issue is clarity of the need for and benefits of systems integration, where
again different stakeholders have more to gain or lose from the change and the
compromises made often postpone changes to take advantage of integration of systems
and processes.
One aspect which should determine the extent of compromise to reduce change
complexity or the reassertion of the need for one off major change are points a) and b)
above. If the ES itself is the source of the required business model, compromise to
reduce the intent due to current constraints etc may well lead to complete failure of the
investment. If b) is the case then compromises etc at this stage may be essential if the
organisation is going to achieve the changes successfully, even if it takes two steps.
3. Problem driven implementation is actually easier to manage than creating innovation

through IT, when more is uncertain and existing knowledge may be inadequate. It is
also easier to measure the success: even if the benefits are more limited they are
probably more visible soon after implementation. Again, the ability to measure the
benefits may reduce the ambition to those than can easily be identified, agreed on and
measured. However, such a compromise may well lead to overall disappointment that

so much expense and elapsed time was needed to achieve (apparently) so little. The
benefits achieved by problem removal rarely justify the expense of an ES. It is
therefore important that the new baseline is achieved as quickly as possible to enable
the more strategic value from the ES to be realised.
In the “worst cases” the compromises are so severe that few, if any, business changes
are made so that the organisation has essentially the same systems running on different
software. Of course this is compounded if the software has been amended to become
a unique version, rather than change business practices.
4. Following any ES implementation there is some form of shakedown phase, which may
involve resolving serious problems if business performance has been adversely
affected, or merely tuning the system and business processes to achieve the expected
performance levels. Any implementation should anticipate and plan for this stage,
ensuring resources and procedures are in place to deal with the consequences of
implementation. Once the ‘baseline’ benefits have been delivered, the organisation
needs to define a revised intent for the ES, in terms of future business change (and
further ES investment if necessary) to deliver new business options, available
following systems and process integration and/or having common systems across the
business units. In many cases no further action may be taken for some time and any
change-based benefits available are postponed or even foregone. 50% of
organisations who implemented an ES as part of the Y2K strategy, have waited 1-2
years before ‘re-implementing’ to obtain more comprehensive benefits.
5. Having established a new or revised intent in relation once more to the business
vision, which may have changed during the period of implementation, a new stage of
planning and implementation, often in smaller steps, focused on specific business
processes can be carried out. This onwards and upwards stage, being more innovative
and requiring more business change, is only really feasible in discrete steps, if
business risks are to be avoided. It is important that organisational knowledge gained
during the first, often large scale implementation is retained and transferred to this
second phase.
This model forms the overall structure within which the other organisational modes,
behaviours and approaches are described in the following sections.

3.2 Modes of IT Behaviour
Based on the work of Kumar et al (1998) three types of organisational modes of

behaviour in relation to IT can be identified. Given the enterprise wide effects of an ES
and the long implementation period, different organisational stakeholders are:
a) likely to perceive the implementation differently and adopt different behaviours and
b) some stakeholders are likely to change their perception during the project and hence
their behaviours.
Two distinct and extreme modes of behaviour were identified from earlier literature –
rationalism, whereby all stakeholders subscribe to the same organisational goals and
segmented institionalism where stakeholders engage in activities (often political) to
protect their private interests. Clearly it is unlikely that in a large organisation all
stakeholders subscribe to the same goals, in this case the objectives and benefits of ES
implementation. It is also unlikely that an organisation where segmented institionalism is
completely dominant would ever either embark on an ES or succeed with it!
A third behavioural mode emerged from the work by Kumar et al, which they describe as
relationships and trust, which accepts that different stakeholders will have different
interests but some existing relationships of mutual trust amongst stakeholders enables
some agreement to be reached within a rational overall approach.
The introduction of new IT can provoke each of these behaviours depending on its impact
on different groups and can exacerbate existing behaviours. In essence the behaviours
with respect to IT are:
1. Rationalism – all stakeholders subscribe to the same organisational goals and focus on
achieving those goals through effective and efficient use of IT.
2. Relationship and Trust – a willingness of (some) stakeholders to act in concert to

ensure mutually supported organisational goals can be achieved through IT without
serious detriment to any stakeholder interest.
3. Segmented Institutionalism – stakeholders pursue their personal agendas/interests and

use IT to protect their positions, often constraining the organisational use or even
undermining it.
For ease of understanding these will be referred to in the rest of the report summary as:
1. Rationalism – Rational
2. Relationship and Trust – Trust
3. Segmented Institutionalism – Self Interest

It is important in an ES implementation to recognise that all three of these modes will

exist, probably concurrently, amongst the stakeholders. Whilst senior management are
more likely to subscribe collectively to the rational view, they have to accept there will be
those who have vested interests to protect and also that existing relationships amongst
some stakeholders are a source of power for either beneficial change or resistance.
Existing relationships are likely to be a result of the existing business model, hence the
extent of change to the business model caused by the ES – the less change, the more
existing relationships are a positive attribute and vice versa.
If significant change to the business model is required, new trusting stakeholder

relationships need to be formed early in the project, based on the business model
envisaged. Otherwise it is likely that as existing relationships and trust are broken up by
the anticipated changes, all the stakeholders revert to self protection and segmented
institutionalism becomes the dominant behaviour. Alternatively, those relationships that
survive the change in business model will form a coalition to maximise its net benefits
from the ES at the expense of others!
It must be recognised that stakeholders exist as individuals, structural groups,

communities of interest etc but there are inter-relationships amongst stakeholders and
stakeholder groups that can be either a major enabler or inhibitor of an ES
implementation.
In relation to the stage model this view would suggest that:
a) During the planning stage an overall rational view of the business and ES models and
benefits expected should be behind the process but that more detailed planning will
naturally be affected by existing trust and relationships amongst stakeholders. What
must be avoided is a rapid descent into self interest when ‘individual’ stakeholders
will defend the status quo normally by adding to the “constraints”.
b) Whilst the rationale for the changes must be re-inforced throughout the
implementation by re-iteration of the benefits, the management of the changes will
inevitably be localised to a large extent. There will be a continuous balancing of local
and shared interests based on the relationships amongst stakeholder groups.
c) Following implementation the duration and issues in the shakedown phase will be
partly dependent on how each stakeholder group has fared in terms of actual and
perceived benefits in relation to the changes undergone and disbenefits. There is
likely to be a period of self protection if the implementation has not gone well and loss
of trust, as relationships are stressed. The stakeholders at the ‘sharp-end’ where the
business operations can suffer most if the new system “doesn’t work” are likely to be
the most protective – they are also the ones who probably individually or collectively
resisted change during implementation, to avoid bringing the business “to its knees”
for a period.

d) Before the onwards and upwards innovation stage can proceed not only does a new
rationale for the future vision have to be in place but also:
i) new relationships and trust amongst key stakeholder groups need to be in place to
operationalise the vision, and
ii) protective behaviours based on local interests need to have ceased, either through
attention to the specific issues causing the behaviour during the shakedown phase or
by other compensatory changes to mitigate the negative effects.
See Figure 3.2
ES IMPLEMENTATION & CHANGING

ORGANISATIONAL MODES?
Rationalism
(altruism, aspirations,
benefits)
Create new relationships
Trust & Existing based on the new business
Relationships Innovation based on the new
model and balance changes & model & relationships
benefits to individual
Segmented stakeholders
institutionalism
(constraints, self protection)
Project stage Implementa- Onwards &

Planning Shakedown
tion Upwards
Strategic
Intent
Figure 3.2

3.3 Management Approaches
A Basic Process for Managing a Single Interest Group
At its simplest, we can describe the management of an interest group in terms of three
stages:
Identify Identify the groups whose opposition/support will play a significant role in
determining the success or failure of the project. Analyse the interests of
each of these groups
Influence Communicate with the members of each interest group to alter their
understanding of how their interests are affected by the change project and
what courses of action are available for implementation
Involve Secure sufficient involvement of the interest group in the change project to
ensure its success
Whether we are aiming to get minimal compliance or active support for a change project,
the same basic process applies, using different techniques for influencing and involving
groups and individuals.
Although the process described here focuses on the management of conflicting interest
groups, it is essential to bear in mind that supportive interest groups are also vital to
project success and can be managed according to the same process, albeit in a more
positive way.
Identify and influence
An interest group consists of one or more individuals who will be affected by a change
project and, consequently, may take action to support or oppose it. Any large scale
change, such as an enterprise systems project, is likely to affect many diverse interest
groups. Unfortunately, the scale of change often makes it impossible to involve every
member of every interest group in designing and implementing change. It is, therefore,
necessary to prioritise efforts to communicate with interest groups and to balance their
involvement in the change process against the practicalities of completing the change
project within a reasonable timeframe. A useful starting point for prioritising interest
groups is to consider their attitude towards the change project and their importance to
project success (see Table), as a basis for how to influence their perceptions and hence
actions regarding the project.

Importance to project success
Low High
Keep informed, in order to Keep well-informed, particularly if
retain their support but keep there is a problem with the project,
Supporting
their involvement in the project to retain their confidence. Involve

limited in aspects of project most directly
Attitude towards change project
affecting their interests.
Get them on board if only Engage in dialogue to develop more

limited effort is required to favourable attitude towards the
persuade them. Pay more project and to limit the influence
Persuadable
attention to them if their support that groups opposing the project

will encourage other supporters might have on them. Discuss how
and/or help to manage opposing they might become involved.
groups.
Usually require more effort to Require substantial time and effort
change their attitudes than is to develop a positive attitude to the
worthwhile. However, may be project and to manage their
necessary to counter their demands. Effort may also be
Opposing
negative influence on important needed to counter their impacts on

groups. other groups.
Prioritising and influencing interest groups
The modes of behaviour described above represent three general ways in which interest
groups might interact to influence the outcome of an ES project. Depending upon the
stage of a project, the different modes of behaviour will be more or less conducive to
success (Fig 3.2). In order to maximise the likelihood of successful project outcomes, it is
not sufficient simply to hope for the most desirable behaviours to manifest themselves.
ES project managers need to encourage the behaviours appropriate to each stage of the
project and adapt their management approach to reflect the kinds of behaviours they
observe.
The Harvard Project on Negotiation (Ury, et al., 1993) distinguished between three types
of involvement of interest groups:
Interests – Groups try to understand each other’s interests and find ways of partially or
fully satisfying them all
Power – Interest groups use their authority, control over resources, social connections,
etc to force their preferred solution on others
Rights – A framework that defines rights or ‘due process’ is used to make a decision

Both interests and power approaches are commonly used by managers and are referred to
here as ‘management approaches’. The rights approach, typified by the judicial system, is
rarely found in business outside of legal disputes and is not considered here.
Power and interest strategies can be adopted at various stages in an ES project. A CEO,
for example, may use his power to mandate that SAP will be implemented company-wide
or he may ask representatives of several key interest groups to discuss the issues and
make a recommendation. Clearly, the management approach used can have a major
impact on people’s reactions to a decision and their support for a change project.
Within an organisation, the power approach usually takes the form of a person in
authority imposing their decision on others and is, therefore, referred to as the ‘top-down’
approach in this report. The interests approach can be considered along a spectrum from
win-lose to win-win. In the context of change projects, the most common form of win-
lose activity is the emergence of temporary coalitions that support or oppose particular
decisions and actions - referred to here as the ‘coalition’ approach. Win-win activity is
most commonly experienced as collaboration between different groups in an effort to
negotiate a solution that will benefit them all – referred to here as the ‘negotiation’
approach.
Strengths Weaknesses
Top-down Quick and effective. Secures compliance not co-

Solution imposed by senior operation. Future impact.
manager
Coalition Effective for fixed term Exposure to risk of others

Offer support for group’s issues but not for permanent making demands, including
other key interests changes. project supporters.
Negotiation If resistance to project was Risk of reducing

Negotiate changes to justified, may give commitment/clarity of those
project plan improved project plan. already on board.
When to use top-down approaches
The top-down approach is essentially a way of coercing interest groups into accepting
something they would otherwise reject. In organisations, it most commonly takes the
form of managers requiring their decisions to be implemented by more junior employees.
Decision-making authority is not the only form of power, however. Other sources of
power include control over information or other key resources, and the combined power
of coalitions of weaker interest groups.
The top-down approach will almost certainly result in a win-lose outcome, where the less
powerful groups feel they gain less than they lose and tend to believe they have been

treated unfairly. As a result, it often creates a desire for groups to resist future actions
taken by the same powerful groups.
Although the top-down approach might best be avoided, there are times when it is
appropriate, including:
• When implementation of change is time critical and negotiating with interest groups
will cause delays;
• When an interest group is refusing to discuss the change project and how its interests
are affected; and
• When, despite every effort of the project team, an interest group is refusing to provide
an essential contribution to the change projects.
Although powerful groups, such as a senior management team, can simply impose
change, the potential damage of this approach can be limited when dealing with single
interest groups by designing two factors into a power-based threat to the group. First, a
refusal to co-operate must be met with consequences that damage the group’s core
interest (without harming other groups). Second, the group should be offered some
concession, relevant to their interests, if they agree to co-operate. Such a concession,
although it may not compensate for the negative impacts of change on the group, will at
least allow them to avoid losing face in front of their colleagues. Allowing then to portray
this concession as a success, will reduce the risk of a group refusing to co-operate simply
because they have told other interest groups that they are opposed to the change. A final
point to bear in mind is that the aim of the top-down approach is to avoid carrying out
threats that damage a group’s interests. Once a group has already lost out as a result of a
change project, they have even less to gain from further co-operation.
When to use coalition and negotiation approaches
The coalition approach is a relatively risky option where the outcome will often be
uncertain. Group A supports Group B on issue 1, even though this means that Group A
will lose out. In return, Group B supports Group A on issue 2, even through Group B will
lose out. Obviously this will only work beneficially when there is a degree of trust across
the groups that each will stick to its promises. Also the trade-offs being made have to be
well understood and well-balanced across the groups. Coalition formation can also be
used as a strategy for getting certain key groups on-board at stages where their support of
the project is critical. Coalitions are clearly limited by each group’s ability to offer
something valuable to the other group. It is also important to note that coalitions are
fragile when there is a general lack of trust between the groups and the possibility that the
actions of another group will affect the agreement that holds the coalition together (e.g.
Group C might force a different outcome on issue 1). There is also a risk that groups
previously to support the project will realise that there is something to be gained from
being less co-operative.
The negotiation approach is a high trust solution that aims improve the outcomes for
everyone involved. Its win-win approach tends to result in solutions that are more stable

over the long-term. The purpose of the negotiation process is to clarify facts about the
nature of change and its likely impacts on different groups, as well as to understand each
group’s needs, concerns and preferences (Lytle, et al., 1999). In the context of a change
project, this is likely to mean reconsidering at least some parts of the change plan. The
main drawbacks of this approach are that it is time-consuming and can lead to complex,
‘fuzzy’ solutions, which themselves can limit the pace of change. This combination of
advantages and disadvantages make the negotiation approach most suitable for the later
stages of an ES project, where the focus is on extracting benefits over the duration of the
systems useful life.

3.4 Synthesis of Organisational Modes of Behaviour and Management

Approaches
There is always a danger of oversimplification in bringing models from different sources

together, but there is an obvious linkage between the organisational modes of behaviour,
described in section 3.2, and the management approaches, described in section 3.3. To get
an ES project off the ground, for example, requires a clear statement of how it relates to
the business’s strategic vision. Such a statement is most likely to arise from working in
the ‘rational’ mode where those involved perform an explicit analysis of how the ES can
deliver towards stated objectives (e.g. by drawing a benefits dependency network). In
terms of management approach, a clear statement of strategic vision and the objectives of
strategic projects is best articulated by senior managers and accepted by the rest of the
organisation (i.e. a top-down approach). In contrast, during implementation, when
stakeholder groups are most concerned about the immediate effects of the project on their
work (i.e. self interest), a top-down approach is likely to be perceived as ‘heavy-handed’
and may create more problems than it solves.
Understanding changes in the mode of behaviour from the perspective of key interest
groups and choosing a management approach that encourages an appropriate level of co-
operation is a key facilitation role of the ES project manager. Figure 3.3 combines the
modes of behaviour and management approaches and suggests a likely result of each of
the 9 possible combinations. The rationale for each is described and the implications of
different ‘paths’ through the matrix in terms of the evolution of an ES project are
considered.

SOME RESULTS OF THE INTERPLAY OF ORGANISATION

MODES & MANAGEMENT APPROACHES
Management Approach
Organisational TOP DOWN COALITIONS NEGOTIATION

Mode (Power) (Interests) (Facts)
1 2 3
Clear vision of Mutual benefits from Agreement on
potential benefits – changes and shared timescales, resources
Rational Business Case and learning – but tends and local benefits
Overall Plan to reduce scope to
agreed changes
+++ ++- +--
4 5 6
Shared vision of Co-operative change Trade-offs in
potential benefits and management to resources, benefits
Trust
acceptance of the achieve the mutual and changes can be
need to change benefits agreed
+-- +++ ++-
7 8 9
Localised view of Trade-offs between Detailed ‘contracts’
benefits only – coalitions to on all aspects of
resistance to change minimise negative implementation –
if no local benefit affects (and probably benefits resources,
Self Interest reduce benefits) changes etc. with
Senior Management
and other parts of
organisation
--- +-- +++
Figure 3.3
The use of + and – signs in each of the boxes indicates the extent to which the
management approach and organisational behaviour mode are complementary and self
reinforcing (+) or contradictory and therefore problematic (-). The overall conclusions
from this in terms of potential paths through the matrix are discussed later.
1. Rational / Top Down
At the start of the ES project it is essential to get agreement at the senior executive
level of the intent in relation to the business vision and strategy as explained earlier.
The most probable way of gaining consensus at this level is via rational discussion of
the strategic benefits intended and the overall business case. Senior executives are
more likely to agree to and support a well argued business case, linking ES benefits
to the business strategy than for any other reason. Equally it is the ‘quality’ of that
business case which enables senior managers, individually and collectively to
persuade others of the need for change. However, as had been said earlier, it is likely
that the senior management team will be unaware of some serious issues that may
prevent delivery of all the benefits and they will want the benefits delivered by
minimum resources and change effort. The business case also provides a ‘mandate’
for the project manager and team.

2. Rational / Coalitions
From the mandate for change, the project team supported by senior management
needs to establish the appropriate relationship with and amongst the coalitions of
interest in line with the required future business model and business case. Based on
the rationale of the business case, there is still some learning to achieve to create the
changes to deliver the new business model and benefits. The rational view will tend
to assess the change effort in relation to the benefits, leading more often than not to a
reduction in scope that delivers the majority of benefits within an acceptable
timescale and manageable change plan. Given that coalitions are ‘fragile’ and need
to see the mutual benefit from their agreements, they cannot be expected to work
successfully over a long period.
3. Rational / Negotiation
The project team’s relationship with the business managers will tend to focus on
“rational negotiation” about the ‘facts’, i.e. timescales, schedules, resources and the
most obvious benefits. The more complex issues such as change implementation and
new working relationships require more subtle types of negotiation to resolve. Again
the project team will use the business case to argue the need for other changes etc to
deliver the benefits, but the line managers will argue it is ‘their job to deliver the
benefits’ and the project teams job to deliver the necessary technology at the right
time and cost. This again leads to a focus on the project and the systems rather than
the business changes and the ‘easy’ local benefits will be delivered, but little change
effort made to obtain other benefits.
4. Trust / Top Down
When senior management attempt to impose ‘their’ plan without allowing time and
effort for understanding how the changes will be made, existing relationships
amongst stakeholders based on ‘who trusts whom’ will be reinforced. They may
well agree with the benefits, but the attitude to change will be ‘acceptance’ rather
than commitment to make it happen. As said earlier the project team will be faced
with existing stakeholder groups who represent the current model and senior
management’s inability to delegate or empower the groups will inhibit achievement
of consensus about the change plan.
5. Trust / Coalitions
This is the best combination for moving from ‘intent’ through planning and into
implementation when major business and organisational changes are needed. It
requires the same actions by senior management and the project team as in 2 but also
a recognition of the existence of current relationships and a facilitated process in
enabling those stakeholders to determine the changes in relationships related to the
new model. It is important that senior management allow the project team and line
managers time and discretion to build new working arrangements and resource

strategies to achieve this and then, probably, accept that either more resources are
needed, or not all the changes are worthwhile in relation to the benefits. However, it
should mean that the intent has been converted into a viable plan, in that the majority
of benefits can be achieved and that the changes will actually be made.
6. Trust / Negotiation
This enables the more complex ‘negotiable’ issues to be included (of 7 above) since
the existing trust amongst stakeholders will enable a degree of trading off between
both benefits obtained and changes needed, as well as the resources and timescales
required to achieve implementation. Again, the effect overall will probably be to
reduce the overall benefits delivered to those where well balanced trade-offs can be
agreed. The nature of the trading process however is likely to slow up the
implementation since the trade-off arrangements may well produce a non-ideal
implementation schedule in terms of the project team resources.
7. Self Interest / Top Down
When senior management attempt to impose a ‘solution’ without reference to

existing issues and constraints or trust their line managers to achieve the plan using
their knowledge and resources the worst possible combination can occur. This is
often compounded by a project team that has only focussed on its relationship with
senior management and has become complicit in the imposed solution, having paid
little or no attention to line managers change and resource issues. In effect the line
managers will only accept the need for change in line with the specific benefits they
will obtain and will not co-operate in changes to benefit others or the organisation
overall. This more often happens in multi-unit, multinational implementations where
a corporate solution is imposed without consultation and involvement in the initial
planning. When the project team consists primarily of ‘head-office’ staff and does
not have balanced representation the problems are compounded!
8. Self Interest / Coalitions
This is a problem when the coalitions required for the future model and the project
team, usually implicitly supported by senior management, have little confidence and
trust in each other, or at least in each other’s motives. Behaviour closer to self
protection can occur, especially if those outside the new coalitions have more to lose
than gain. Trade-offs with the project team and amongst the groups will occur to
ensure minimal negative impact but this will reduce the benefits to those achievable
by minimal change. It is this box that often turns the ES implementation into a
‘software project’ to avoid contention between groups and the project team, who
achieve what they can with the resources they actually control.

9. Self Interest / Negotiation
At the point of implementation and change over to the new system, processes, roles
and ways of working and particularly new performance measurement systems, each
individual line manager has to be clear about the ‘contract’ they and their staff have
in the new business model. This will enable the ‘shakedown’ phase to be addressed
quickly and objectively in terms of how well the new model and system is working,
whether the benefits are being realised and/or where problems have resulted that now
need to be corrected. The project team also needs clear criteria as to priority areas of
business concern and to have clear contingency plans for any actual deterioration on
business performance during the shakedown phase. It is more likely that the
conditions for constructive negotiations will exist at this point if the segmented
institutionalism mode has been avoided until it naturally becomes appropriate, close
to implementation.
Routes through the matrix – leading to differing degrees of success
ROUTES THROUGH THE MATRIX
Management Approach
Organisational
TOP DOWN COALITIONS NEGOTIATION
Mode
+ positively
re-inforcing
Rational +++ + +- +- -
B
- contradicting
1 2 3
A
Trust +- - +++ + +-
4 5 6
C
Self Interest --- +- - +++
7 8 9
A = best route to achieve overall success

B = route to achieve benefits but reduced scope/intent
C = route to achieve technical implementation but reduced business benefits due
to lack of business change
Figure 3.4
Figure 3.4 suggests three main routes through the matrix leading to varying degrees of
probable success. All avoid Box 7 (Self Interest/Top Down) which at best will cause
major setbacks and delays, increase risk and may even derail the whole project. Each
route is workable and will produce success to a degree, but routes B and C are likely to
deliver less benefits in the first implementation and may produce limitations to what can
be achieved later.

The best route (A) is the best combination of approaches to match the organisational
behaviour as it will change, and needs to change, during the project. Box 1 is essential at
the start of the Planning phase to establish the project intent, benefits, success criteria,
business case and project structure. But, during the planning phase a move to Box 5 is
needed to develop an achievable plan – one which will deliver the majority of the
benefits via a manageable change programme. This needs to continue through the early
stages of implementation but change to Box 9 close to final implementation to enable the
effective management of the shakedown phase. In reality, the combinations will
undoubtedly overlap, particularly in a complex, large roll-out across the organisation.
If, following the project set up the purely rational view prevails it will move the project to
Box 2 (Route B) - the project will probably be redefined to some extent to reduce the
scope and consequently some benefits, to enable changes to be managed with less
problems. The focus will be on the interests of some stakeholders, those who will
‘prosper’ in the new business model. If agreement amongst these players is not reached
in Box 2, the project will decline into more detailed negotiation about ‘facts’ – the system
specification, project timescales and resources – not the more judgemental and
organisational aspects, with a tendency to reduce any risks (and therefore change scope)
and again reduce the benefits to those that result directly from IS/IT delivery (Box 3).
Another danger in this box is that the negotiation focuses on the system functionality and
leads to significant customisation to meet users more idiosyncratic needs, rather than
change processes and procedures. If Box 3 can be avoided the project negotiations, based
on a more comprehensive understanding (now normally during implementation) will
make necessary trade-offs to achieve the more important business changes provided
resources are available (Box 6). Again, the project needs to enter Box 9 just prior to final
implementation. Obviously because the project passes through more combinations of
approach and mode there are likely to be delays due to the ‘trading’ and consequent
slower route to agreement plus potential iterations in design and planning. However, this
route is likely to lead the achievement of significant benefits, probably more local than
corporate, but slower and at higher costs.
The third route (C) is likely to produce a successful IT project in terms of moving the
organisation onto a new suite of software and associated technologies but due to the
destructive approach (top down) in Box 4 and the ‘early’ protectionism introduced during
planning (Box 8), few of the benefits apart from the ‘low hanging fruit’ will be delivered,
probably after considerable delay and higher than expected cost. In this route all the
project team can do is deal with aspects under their direct control (usually the system)
and accommodate the diverse stakeholder interests by meeting the basic requirements
only.
In essence, in route B the project can develop a ‘life of its own’ and become somewhat
separated from mainstream business activity and in C the organisation essentially rejects
the ES project as a business initiative and it becomes primarily an IT project. Only in
route A does it remain an integral part of the organisation’s strategic intentions.

Based on the evidence from the case studies (sections 4 and 5) the model proved an
accurate diagnostic of the issues that arose, depending on the routes taken through the
matrix during the projects. Whilst only the most successful project followed the ideal
route (A), attempts were made at various stages of all the others to bring the projects back
closer to this route as issues emerged. The model is helpful in understanding the reasons
why a project is subject to particular problems/issues in terms of the causes, enabling the
project team, senior and line management to adapt the approach to implementation.
The model and the routes do not imply that once a route is being followed the outcome is
inevitable, nor that routes B and C produce ‘failure’ overall. The evidence from the cases
confirms that either benefits achieved are reduced and/or project timescales are extended
and/or costs are increased when the organisational approach project becomes ‘stuck’ in
an element of the matrix where the management approach and mode of behaviour are
contradictory rather than re-inforcing.
As described in section 3.3, it is vital to identify the different stakeholder interests and
appreciate how each of them and associations amongst them can impact the project and at
which stages. Guidance is given in section 3.2 and also in section 3.6 about how to bring
different groups with different perspectives closer to the best route (A) through the
model.
Some overall conclusions are:
• Given the scope, complexity and timescale involved in ES:

a) all 3 management approaches will be needed at different stages of the project
(Planning, Implementation, etc.)
b) all 3 organisational modes will influence the ES implementation and must be
accommodated
• Ensuring that the appropriate combination of mode and approach is in place at the
right stage of the project will increase the chances of overall success
• Over-zealous ‘top-down’ management can destroy existing trust and relationships,

creating resistance based on self interest (or unholy alliances!)
• The existence of coalitions is the main source of the ability to change beneficially
• If the ES approach increases self interest behaviours, implementation becomes a ‘war
of attrition’, hiding the real issues which explode in the shakedown phase, which will
not be resolved until new trust based relationships are established
Understanding, reconciling and managing different stakeholder interests is a key issue for
the project team, especially in terms of ensuring the business and organisational changes
required to deliver the benefits are identified and achieved. Experience of many ES
projects (ref. Alan Wright’s presentation) shows that the most commonly underestimated
area in terms of complexity, resourcing and senior management involvement is change
management. It always scores high on “in retrospect I would have given more attention
to ….”. Even when the change management issues are recognised, either the approach

adopted is often inappropriate to the intent of the programme or different approaches are
adopted in different parts of the organisation (or even both!). There are sound change
management methodologies available which do work. The next section discusses one
well known basis for determining the best organisational approach to managing change
programmes depending on the purpose and complexity of the changes. It is not particular
to IT or ES, but comes from the organisational change management literature.

3.5 Change Process Management
Although matching the change management approach to the organisational mode of

behaviour will help to ensure that an ES project is successful, the specific approaches to
managing relationships between interest groups operate in the broader context of the
organisation’s control systems. The analysis so far suggests that both mode of behaviour
and management are more appropriate at different stages of an ES project, it seems likely
that the same is also true of the broader control systems in which change is generally
managed. Research by Simon (1995) proposes four types of control system to be used in
different circumstances, depending on whether senior management wish to encourage
performance, initiative, innovation or contribution.
The characteristics of Simon’s four control systems are summarised in figure 3.5:
CHANGE PROCESS MANAGEMENT (Simon, 1995)

CONTRIBUTION Discretion/Empowerment INITIATIVE
BELIEF BOUNDARY
SYSTEM CONTROL
ES - will require all

four types of
Tacit Explicit
management in different
Knowledge Knowledge
aspects of
(Vision) (Detailed)
implementation and at
different times
INTERACTIVE DIAGNOSTIC
CONTROL CONTROL
INNOVATION Prescription/Control PERFORMANCE
Figure 3.5: Control in an ES Project
In a project context, the classification of these four control systems can be related to a
combination of two issues in the minds of the ‘owners’ of the project (in the case of an
ES the owners include, at least, the senior management team and the project team/task
force/steering group):
• their ability (or willingness) to contribute their knowledge of the detail of the context,
process, content and outcome of the change required;
• their willingness to empower people in the process of change.
The four segments of the matrix in figure 3.5 represent four styles of project
management, which should be applied in different circumstances.

Diagnostic Control
If the required outcome can be specified in detail and confidence in delivery is high, then
the process can be controlled by setting output measures and targets. This is the
traditional domain of project management whose principal paradigm is to plan
thoroughly, to monitor progress against key performance variables and to use this
feedback to take any necessary corrective action. This form of control is used when
achieving performance is the main objective but relies very heavily on the ability to
prescribe in detail at the outset what has to be delivered and how it will be done.
It works best for projects that are content driven and where there is a high degree of
confidence that the planned content will deliver the desired outcome. In terms of an ES,
this would mean an intent to reach the new baseline and does not involve any radical
changes to the business processes or structures.
Boundary Control
This is used when the objective can be stated clearly but senior management are
indifferent as to the means by which it is achieved within some stated parameters. The
owner is effectively saying: “This is what I want and I don’t care how you do it but don’t
spend more than £X and/or take longer than Y days and don’t violate any company
rules”. Within these constraints, people are empowered to use initiative to achieve the
stated objective.
Boundary control is most likely to be appropriate for the components of any ES project,
such as Finance, HR, Purchasing which may not be critical to achieving the benefits
which depend on high degrees of integration.
Interactive Control
This is appropriate when the owner is not able to state in detail what he/she wants beyond
some vision or concept and wishes to remain in control of the activity. In this case the
owner has to share his/her knowledge by facilitating and supporting a joint learning
process. In this way the owner can monitor the development of the activity and apply the
appropriate “hands-on” control whilst encouraging innovative thinking and creative
behaviour.
Innovation will most often be required in the ‘strategic’ aspects of ES projects that are
defining new business processes or models or for key operational aspects conceived to
deliver an existing process in a significantly improved manner. Interactive control, with
the owner’s active participation and hands-on control is appropriate in these
circumstances.

Belief System
If the owner wishes to encourage contribution and to empower people to create

something radically different then the owner must establish a “belief system” to instil a
set of values to ensure that whatever is produced is congruent with the strategy and
culture of the organisation. Organisation-wide technology projects sometimes exemplify
this form of control. The owners do not have the depth of understanding to control the
design of the solution and the project team cannot provide a simple cause and effect link
between change and improved results of the organisation. In this case the owners are
making an act of faith and their only means of control is through everyone adopting
behaviours in line with the belief system they have established. This is more commonly
used in conjunction with a degree of boundary control so that there is freedom of action
only up to a certain point such as a limit on expenditure.
Projects responding to either pressures or opportunities from the business environment,

are appropriate for this type of control. High potential aspects of ES projects seeking
new opportunities or some strategic elements led by the owners’ vision would fall into
this category. This style is an essential ingredient of any ES project where the intent is to
deliver in one stage a new business vision based on the ES capability.

Application to Enterprise Systems
For a complex project such as an Enterprise System (ES) implementation, the above
analysis, although helpful, is somewhat too simplistic. An ES project will consequently
need to apply all four control systems at various stages of the project. Overlaying
Simon’s four control styles on the organisational modes and management approach
matrix they are aligned with different combinations of approaches and behaviours and we
would expect to see an evolution of control styles across the project phases as depicted in
figure 3.6.
OVERLAYING CHANGE MANAGEMENT STYLES
INT
ERA
CTI
VE
Rational CON
TRO
L
BELIEF
SYSTEM
BOUNDARY
Trust/ CONTROL
Relationships
DIAGNOSTIC
CONTROL
Segmented
Institutionalism
Represent the expected evolution in managing change

as the project proceeds from planning through implementation,
as emphasis evolves from overall contribution of ES to
achieving required performance improvements
Figure 3.6: Evolution and Application of Control Styles
The planning phase will be concerned with establishing a clear purpose for the project
and agreeing feasible ways and means to achieve the agreed purpose. During this phase,
senior management should use their position of power to engage key stakeholders in a
debate to gain a consensus position on the project’s objectives and the future business
vision. Senior management behaviour during this process of gaining consensus should be
participative and empowering with a focus on motivating the key stakeholders to
contribute to the future business vision. A Belief System control style is therefore
appropriate to this phase.
The future business vision emerging from the planning stage can be relatively vague and
will require a great deal of detailed design activity to translate the vision into practicable
ways of working. This will require a broad constituency of stakeholders to pool their
understanding and commitment to agree the new business model. Moreover, since many
things will be seen to be changing across a broad front, stakeholder benefits will need to
be shared out if the problems of self interest domination are to be avoided.

Senior management cannot be expected to remain actively participative throughout this

process. A more delegating style of control is therefore required. Those participating in
the design will need to be empowered to think outside of current organisational norms.
Boundary Control is the appropriate form of control for this phase. The tendency of this
control strategy towards risk avoidance should help contain the tendency of the design
phase to expand in scope as more people contribute their ideas and wants. This will be
particularly so if a two phased approach consisting of ‘problem solving’ followed by
‘shakedown’ is adopted. The boundaries of the problem-solving phase will need to be set
– and held – tightly. Those keen to gain benefit deferred to the shakedown phase may
well attempt to push back the boundaries.
Once the design has been agreed, the project can move into implementation. Provided
that the integrity of the overall design can be maintained, implementation can proceed on
a more localised basis. At this point, however, the style of control will need to change.
Thus far, creativity and innovation will have been valued and encouraged but once the
way ahead has been agreed, achievement of outcome and efficient performance become
the primary goals. Senior management will want to see firm plans and budgets and be
able to monitor progress against key performance variables, such as milestone trends,
budget consumption and benefits realisation. They can be expected to delegate
responsibility to a project management team and direct them to achieve performance
against plan. This is a Diagnostic Control style of control.
Referring to figure 3.6, we can see the evolution of control styles moving from Belief
System to Boundary Control to Diagnostic Control as the project progresses from
conception through design to implementation. However, this assumes that relatively little
innovation is expected and/or that the organisation has explicit knowledge of how to
achieve the objectives. There are therefore dangers for senior managers in only using
Boundary Control in the design and planning phase and only Diagnostic Control in the
implementation phase as both are essentially “hands-off” strategies.
Boundary Control is an empowering approach, which, if over-played, can give rise to, at
worst, an initiative that is not congruent with the organisation’s strategic purpose or, at
least, the need to re-work the planning when the results are finally exposed to senior
management. To avoid these scenarios, senior management need to complement
Boundary Control with the organisational learning characteristics of Interactive Control
to ensure that their own ideas and knowledge are input into the design thinking. This is
especially important when the major part of the benefit set results from innovation in
business processes.
Similarly, during implementation, over-playing delegation can result in a project that

continues to pursue an intent that has become out-of-date as a result of changes of which
the project team are unaware or whose significance they have failed to appreciate. It is a
senior management responsibility to monitor the ‘strategic uncertainties’ surrounding the
project to ensure that its goals remain a relevant contributor to the organisation’s strategic

purpose. As in the design and planning phase, this implies that senior management
maintain an element of Interactive Control.

3.6 Perceptions of Change and Project Negotiations
As the discussion so far as shown, ES implementation involves the management of many

diverse interest groups and the adoption of different approaches to the management of
project activities and changes. By considering modes of behaviour, management
approaches and control systems, senior management and ES project managers can direct
the various groups to increase the likelihood of project success. This ‘interventionist’
approach assumes that the interest groups are fixed in their views about what the want
and what the ES project can deliver. In reality, people’s views tend to change as they
learn more about both the nature of change and how the change affects other people. This
creates another option for managing ES change – a ‘communications’ approach whereby
interest groups learn about each other’s interests and change efforts and, in the process,
the differences (i.e. sources of conflict) between interest groups become less severe. To
investigate the communications approach to managing change, we draw here upon further
negotiation research by Raiffa (1982) that complements the work on management
approaches presented in section 3.3.
Why people see change projects differently
Within organisations, attitudes and perceptions tend to be influenced by four factors:
Roles and As a person moves, for example, from a middle to senior

responsibilities management role, he/she will need to pay attention to different
problems, information and people when framing problems and
making decisions.
Information People have access to different sources of information about

asymmetry change projects and, consequently, must form their views about a
planned change using information of varying completeness,
accuracy and reliability.
Professional Inevitably, professional background and expertise have a major

background bearing on how individuals perceive change. An IT professional,
for example, will appreciate an IT project’s technical complexity
more than a typical accountant or HR manager.
Personal interests The impacts of a project on personal interests will also affect how
an individual perceives a change process. A software engineer, for
example, may see a project as an opportunity to develop
marketable skills and, consequently, argue in favour of using novel
hardware and software.
These factors, combined with group interests, can result in both individuals and groups
having very different views of how a project will affect the organisation during and after
implementation. From a change management perspective, it is particularly useful to
consider how these factors affect people’s perceptions of the resource demands a project

will place on the organisation and the change effort required for successful
implementation. Although many other factors will need to be considered during a change
project, these provide a good illustration of how different perspectives arise and how they
can be managed by the project team.
The planning of an enterprise systems project often occurs top-down. Senior management
identify organisational problems they believe will be addressed by an enterprise system.
A project manager is then appointed to plan and implement an ES project. Finally, line
managers and end-users are consulted regarding the design and roll-out of ES
components in their business areas (see figure 3.7).
Senior managers Strategic Plan
Enterprise
Project manager systems project
plan
Line managers and Adopt technology

business users to improve
performance
Figure 3.7
In the majority of cases, this top-down approach is not satisfactory and project managers
can find themselves under considerable pressure to complete implementation rapidly,
whilst also receiving demands from users for systems changes and encountering many
obstacles to the realisation of the strategic ideal of seamless integration. The results are
illustrated in terms of their perceptions of resource demands and required change effort in
figure 3.8.

Perceived
Project
resource
manager Imple
demands me
conf ng raises
ove ntatio
urce r
ove
r sc n ra
s
op
e o ises c
licts
f ch on
ang flict
ni
reso
Actual e s
Plan
resource
demands
Line
Senior manager
manager
Required Perceived
change effort change effort
Figure 3.8
Senior managers typically have two key concerns: financial performance and ensuring
the business will be competitive for the future. They also have limited exposure to the
complexities of day-to-day operations. Consequently, senior managers tend to focus on
keeping costs and resource usage to a minimum, whilst having limited awareness of the
practical barriers to translating their high-level strategic change plans into reality.
Project managers appreciate the complexity of large change projects and are most aware
of the uncertainty surrounding implementation. As they expect to encounter unforeseen
difficulties, they will tend to overestimate resource demands, to give themselves margin
for error. Depending on the professional background of the project manager, his/her
initial estimation of the change effort is likely to be quite low, as project managers will
also have limited awareness of the practical constraints on project implementation.
Line managers are the most familiar with their part of day-to-day operations. Their time
is consumed keeping things running smoothly and tackling operational problems as they
arise. Any attempts to change operations are likely to be seen as increasing their already
heavy workloads. Thus, they see large change efforts, such as enterprise systems, as
required a considerable change effort. Like senior managers, however, they usually have
little awareness of the costs of buying, maintaining and operating information systems
until they are made explicit.
As shown in figure 3.9, the differences in roles, professional expertise and personal
interests are likely to give senior, project and line managers very different perceptions of
ES change projects. The top-down approach to defining ES change places the project
manager in a difficult position, being pulled in different directions by different
individuals and (if we consider an entire organisation) multiple interest groups. These
differences can make it almost impossible for a project manager to implement a change

project without encountering significant opposition, which is extremely difficult to

resolve.
If, in addition to the top-down process for planning an ES project, senior managers
consult line managers, the nature of communication can be quite different (see figure).
Line managers can gain a better understanding of the intended business outcomes of
change, whilst senior managers can modify their strategy to account for practical
constraints on strategic change. Discussions can take a richer form, in which managers’
perceptions of the change process and outcomes begin to converge. Although this will not
resolve conflicts entirely, as groups will have particular interests to protect, it may reduce
the scope for conflict arising from misunderstanding and a lack of communication.
Perceived
Project Pro
resource je
manager bo ct and
demands t h p line
roj m
ding
res ect a anag

ning
our nd e
ce o rs
dem perat discu
impr nderstan
and iona ss
plan
s l
Actual
oves
resource
ed u
demands
Shar
ers de velop more Line

Senior Senior manag , line managers manager
strategy
manager relevant nded strategi
c
te
understand in
outcomes
Required Perceived
Figure 3.9
The Added Complexity of Enterprise Systems Projects
The above discussion of differences between managers assumed, for illustrative purposes,
that there were only three managers involved in a change project. With an enterprise
systems project, the reality will be much more complex. The many affected line
managers will inevitably differ in viewpoint and there may also be considerable
differences amongst senior management (see figure 3.10), all of which need to be
carefully managed throughout implementation.
During a change project, some or all of these groups will interact, affecting each other’s
perceptions of the change process. In some cases, individuals or groups within similar
perceptions of the project may form a coalition to combine their efforts at defending their
interests (see figure). There are several possible ways is which a project manager might
attempt to develop consensus amongst these groups in order to reduce the risk of conflict
and resistance to change.

Perceived
Project
resource
manager
demands
Actual
resource
demands
Line
Senior managers
managers
Required Perceived
Figure 3.10
Two key considerations for the project manager are: (a) the order in which
individuals/groups communicate and negotiate with each other; and (b) the role of the
project team in influencing communication and negotiations. To illustrate the impact of
the order of communications, consider the two alternative approaches shown in figure
3.11.
Figure 3.11
In example (a), the project manager has chosen to develop a consensus about the change
project amongst senior managers and amongst line managers. After ensuring that each

group (of individual or groups) has a fairly common understanding of the issues, an
attempt is made to establish consensus between line and senior managers regarding the
strategic value and practicability of the change project. The main benefit of this strategy
is that it can be achieved with relatively little effort. It could be achieved, for example, by
holding separate series of workshops for line managers and senior managers to help them
develop a shared understanding and form ‘coalitions’ of line and senior managers. As
these groups both have common viewpoints, the project manager can then focus on
addressing the key differences between the two groups. There are, however, two risks to
this approach. First, the discussions could lead to the coalitions developing even stronger
views on their common interests, making it more difficult to resolve differences between
the coalitions at a later stage. Second, if the initial discussions do not go well, they could
result in line and/or managers separating into multiple coalitions, which begin to compete
with each other. In this case, the use of win-win approaches to negotiating change is less
likely to succeed and the project manager may have to rely more on making trade-offs
during implementation.
In example (b), the project manager has chosen initially to focus on developing senior
management consensus regarding the change project. Having achieved this, a ‘divide and
conquer’ approach is taken to working with line managers. Single interest groups,
coalitions, or small groups with similar views are separately engaged in discussions with
senior management. This approach has the benefit of working with smaller groups, so
each stage of communication (e.g. workshop or meeting) is more manageable. However,
the approach is more time-consuming and can be seen by line managers as a way of
senior management getting their own way, rather than paying serious attention to the
views of different interest groups. It is also important to recognise that the groups
targetted by senior management will talk to each other. If the messages from senior
management are not consistent across groups, line managers may become increasingly
suspicious of political manoeuvring and become less co-operative.
The above examples have been greatly simplified to illustrate some useful change
management and negotiation concepts. Clearly, the reality of an enterprise systems
project will be much more complex and ambiguous. However, analysing interest groups
and the dynamics amongst them, may help to make some sense of this complexity and
uncertainty.

3.7 Summary
A number of models from a variety of sources, some specific to ES, some more general
about IT in organisations and managing organisational change and associated
communications issues were described in this section and then synthesised with respect to
ES projects. Each offers some insights into addressing specific issues:
1. the stage model recognises the realities of planning and implementing an IT based
change programme which is integral to the future business vision, and enables an
understanding of why initial intentions may take two stages of change to achieve.
2. the modes of behaviour enable an appreciation of the attitudes and implications of

different perspectives on how the IT-enabled change will effect difficult stakeholder
groups and how perceptions may evolve and change during a large programme of
change. They also help explain why, since different stakeholders start from different
situations with respect to the ES, they have to be addressed differently in the project
such that the most beneficial behaviours develop over the duration.
3. an ES will undoubtedly expose, and possibly create, conflicts of interest amongst

stakeholder groups and particularly between the project team and the line managers
who have to continue to operate whilst the changes are happening. Engaging senior
management to help resolve conflicts is a double-edged sword – they may exacerbate
problems by the wrong approach, rather than solve them.
4. the conclusions and synthesis from the above can be aligned with models of business
strategic change management which describe appropriate project control approaches,
depending on the business intent of the change. The four control systems can be
overlaid on the earlier model to describe both which approach will be the most
appropriate to achieve the overall intent – base line to strategic innovation – and also
explain why some approaches, wrongly applied, cause project problems.
In particular the best route (A) through the earlier matrix suggests a sequential
change from belief system via boundary control to diagnostic control as the project
proceeds. However, if the ‘second-best’ route (B) is followed a different style –
interactive control – needs to be introduced if the project can eventually be
completed successfully – to address the problem of the learning required by the
coalitions who have to create the new business model without destroying the current
organisational capabilities and hence make the changes too complex to achieve.
5. the combination model of organisation modes and management approaches,

recognising the inherent potential conflicts and need for negotiation and transition
management amongst the different stakeholders offers an explanation of why some
combinations facilitate effective ES implementation. Whilst other routes through the
stages can deliver some degrees of success they will probably be slower, more
expensive, produce less benefits and may reduce the organisation’s ability to build

on the ES to achieve further benefits based on innovations available following the ES

implementation.
6. three critical sets of relationships between key stakeholders – senior management,

line managers and the project team – will affect the success of the ES
implementation. A unique feature of ES is the potential disonance amongst the
senior management team and between their perspective and the view of individual
(and groups of) line managers about the feasibility of a major change programme and
the resources required to implement change, whilst maintaining business as usual.
The project team can easily be caught in the cross-fire or become isolated if they are
unable to bring together, and reconcile as far as possible, these different perspectives.
These models were used to analyse the case studies and interpret and understand how the
projects had evolved and why.

4. Case Studies
4a) Electrocomponents
Introduction
This case study presents an analysis of the Electrocomponents Enterprise Business

System (EBS) project, involving the implementation of SAP across the organisation,
based on material gathered in a meeting on 25th January 2002. The purpose of the
meeting was to review the EBS project, using models and material from the research
project. This review was informal, and was intended to both gather information about the
EBS project, and to test out the research models against a real-world project. It was not
intended as a critique of the project.
Those present in the discussion were:

Julian Starling, Electrocomponents
Nicky McDermott, Electrocomponents
John Ward, Cranfield School of Management
Phil Taylor, Cranfield School of Management
and David Morgan, General Manager IT, joined the meeting at the end to consider
the conclusions.
The situation within the EBS project is described in the following sections by reference to
the models which have been identified and developed in the research project, followed by
an overview of how this may inform the organisational and management issues model
which was proposed at the start of the research project.
Electrocomponents
Electrocomponents is a UK based multi-national that via the company’s group of RS

Components subsidiaries distributes electronic, electrical, mechanical, and health and
safety components, products, and tools worldwide. RS Components’ giant catalogues –
distributed under the “RS Components” and “Radiospares” names – feature more than
300,000 products and same-day order processing. Products are distributed to over 1.5
million engineering and other professional customers in more than 160 countries.
Customers can order from paper and CD-ROM catalogues and on the Internet. The
company also offers technical advice at trade counters worldwide. Revenues in 2001
were £824 million.
Electrocomponents is pursuing growth on three fronts. The company continues to

broaden its product lines and has moved into such areas as health and safety products. It
is also refining delivery and marketing, including online ordering and catalogue/CD-
ROM combinations, to reach more customers. Using acquisitions and new start ups to
grow globally, Electrocomponents is intensifying its push into the US and Asian markets.

A major investment programme in IS was started in 1999 with e-commerce developments

and continued through the EBS project to provide common, integrated systems across
most countries. The implementation, of EBS using SAP, is intended to improve the
performance of the core business model and supply chain as well as reduce the costs and
complexity of multiple systems.
Staging/phasing
In terms of the stage model (see Figure 4a.1), the EBS project is nearing the end of the
“Plan” stage, with France being the first planned implementation site, later in 2002.
“Planning” has so far taken 18 months. This apparently cautious approach is due to a
desire to ‘get it right’ to ensure a low risk of business problems following
implementation. The main downside of this approach is perceived to be that benefits will
as a result be limited to those at a local level only, until the UK and other sites come on-
line at a later stage of the programme. The EBS implementation plan as originally for
consecutive implementations in the various sites. However, some parallel running
between phases will occur to speed up the overall implementation.
In terms of the ES and business vision, the future business model is considered to be
clear, based on the ‘high service’ core business models and group processes. These
group processes are already in place, as a result of previous changes to business structure
and unit/central responsibilities. However, these changes were made without common or
fully integrated systems which would enable the full benefits to be realised. The EBS
project will address the need to put these systems in place and reduce the scope for local
variations from the core business model. The current focus of the EBS project is
“problem based”, with the ES vision being limited to removing the current problems
caused by lack of comprehensive systems support for group processes. The future vision
is therefore one from the past, i.e. to enable the core business model to be fully
implemented across all units. There does not seem to be a longer term future business
vision for ES. It is acknowledged that the business is risk averse, and is therefore not
seeking further ES-related innovation, at least in the medium term.

STAGE MODEL
Expansion based
on core-business
Overall
Future
Business model & Business
Strategic acquisition At this stage no plans Vision
Intent Implement EBS to for innovation based
remove performance & on EBS
Multiple systems growth constraints due
supporting single to ‘old ‘ systems Initial
business model ES Vision
New
Business ES -
Problems Strategic
problems”
PLAN SHAKEDOWN
Current Stage Plan to implement in ONWARDS & UPWARDS

France, then
elsewhere …..
Figure 4a.1
Structure and Processes
Electrocomponents operates a matrix structure – each country being a profit centre

responsible for sales and marketing, supported by ‘group processes’ such as Supply
Chain, Product Management and IS. Potential areas of conflict between local and
corporate priorities and benefits from EBS are well recognised and the need for trade-offs
or compromises is understood. For example, inventory management is part of the Supply
Chain process but affects country performance and how the common, integrated EBS will
change responsibilities between product managers, supply chain and local
marketing/sales and how the benefits will be ‘shared’ is still not clear. Overall, there will
intentionally be a reduction in local autonomy as processes and systems are consolidated.
Project Structure
The project is led by a business manager with a team of business representatives, change
managers and IS staff plus SAP implementation consultants. The aims of the project are
clearly understood, based on the core business model and the need to implement
appropriate systems to improve performance. However, the problem of a centrally
managed project that has to deliver benefits both locally and centrally is recognised, as is
the danger that the project becomes a ‘systems project’.
By the time the first implementation, in France, happens late in 2002 the project will have
been running for 2 years. It is likely that further implementations will have to occur in
parallel to achieve the 3-4 year transition plan and contain the costs.

An overall project management methodology, based on a change management approach,

to minimise disruption to the business operations is in place. However, both time and
cost have escalated, so far, and there is some concern that the control elements of the
methodology are not as strict as they need to be (e.g. no time sheets for project staff).
Another concern was that the project team members were not fully representative of the
international nature of the organisation and project and lacked experience in major
projects. This will need to be addressed before the roll-out to all countries.
Organisation and management issues
Management processes
On the overview “key challenges” slide, points noted were the need to change business
models in order for ES to succeed, and to change local autonomy. The former has been
taken care of by the process working and group processes which have already been put in
place, but the latter aspect on changing autonomy has begun to take on greater
significance within opcos as the project progresses.
A major “boundary” for the project has been “don’t change the organisation” – made
possible because of the previous changes to e.g. group processes. Another major
implementation goal has been to ensure that the end customers don’t see any change in
service.
Benefits management work has highlighted that in order to obtain the full potential
benefits, further organisational changes would be required. Country management would
need to move towards regional management, managing across product management,
supply chain, and suppliers. Greater customer focus would also be needed, building from
the previous emphasis on product and service focus. To make all of these changes work
would require significant role changes, and this will not happen in the near future.
Activity changes are being considered, but organisational changes will not be considered
until at least both France and UK are on-line – making regional planning possible.
Competence / capability
Current change management efforts are focused on activity building blocks and job roles.
There is a recognition that the role of product managers will change from that at present.
Great efficiency through using the new system will mean that product managers will need
to spend less time on admin, giving them more time to manage suppliers better. A
greater level of negotiation skills will be needed in this changed role for the product
managers. Future changes in roles may take place within the supply chain when all
implementations are complete, though there is no move to increase people and roles
within the supply chain at present. There have been some changes in logistics, but these
have been overt.

Learning / adaption
In terms of knowledge transfer / learning capture of implementation knowledge, there

will be a work package which addresses this. Knowledge transfer from the
implementation consultants is not considered to be important at present, as the project is
being treated as a business project, with the consultants providing all the system
configuration expertise. The view is that keeping the consultants through the project will
reduce potential risks. The configuration skills for on-going support will also be
outsourced. An opinion was voiced that knowledge transfer from consultants may be
better on fixed price contracts, where there is an incentive for the knowledge transfer.
Interpretation using the frameworks
Management Approach/Rationalities (see Figure 4a.2)
In terms of the management approaches / organisational modes of behaviour in relation to

the EBS project the general view is “rationalism” with a strong senior management drive
for change(1). But a degree of “segmented institutionalism” has evolved especially in
finance as they already have SAP and are not keen on further systems changes(2). Many
of the further benefits in finance accrue centrally rather than in the opcos. Other business
functions are keen, realising that they need systems support for group processes – they
can see the potential benefits. Marketing can see something in it for them, that fixes their
problems of working on a cross European basis. There is a recognition that being
“further back” than finance, they have most to gain(3).
In considering the interplay between management approaches and organisational modes

the following pattern emerges. The start point for the project was in the top left box –
“top down / rational mode”, with a very clear plan and benefits. However, the emerging
view as the project progresses is towards the bottom left, with a realisation the opcos
(business units) will lose autonomy and risk becoming “part of the machine”(4). Work
has been undertaken with the French opco – building relationships and working through
trade-offs in scope, resources and benefits. This has moved the French opco up to
“negotiation / trust and relationships”, although this may lead to overall reduction in
project scope(4b), a sector concerned with managing scope. Overall, of the 4 business
change groups, 2 are considered to be in the middle box(3a). The project team itself is
driving the project from the top left – “top down / rational”, focused on timescale,
resources and benefits(5).
There is a danger that the implementation will be polarised between groups, the process
groups being more willing to change for mutual benefits and opco functions, seeing fewer
benefits, attempting to minimise the negative effects. The ‘common ground’ may be a set
of ‘negotiations’ regarding implementation details between group process managers and
opco management. This is likely to further delay the full implementation, unless the
project team can engage the business managers collectively in decisions rather than have
to deal with them all separately.

Management Approach
Organisational PARTIAL
TOP DOWN NEGOTIATION
Mode COALITIONS
3
Clear vision of 1 Mutual benefits from Agreement on
potential benefits – changes and shared timescales , resources
Rational
Business Case and learning but may and local benefits 5
Overall Plan 4b
reduce scope
Shared vision of Co-operative change Trade-offs in 4a
Trust/ potential benefits management to resources, benefits
Relationships and acceptance of the achieve the mutual and changes can
need to change benefits 3a be agreed
Localised view of Detailed ‘contracts’
Trade-offs between
benefits only – on all aspects of
resistance to change coalitions to implementation –
Segmented if no local benefit minimise negative benefits resources,
Institutionalism affects (and probably changes etc. with
reduce benefits) Senior Management
4 and other parts of
2 organisation
Figure 4a.2
Perceptions of change capability (see Figure 3)
The early project discussions had been between project management and senior
management, based on scope and resources(1). Later project discussions have taken
place between senior managers and line managers(2). Senior management perceptions of
resources and change capability were considered to be closely clustered, rather than
widely varying. In terms of resources for training, line management have offered 50%
more trainers than were proposed by the project team(3).
In terms of managing conflicting interest groups it was noted that the change impact on
different groups within the business was being carefully considered. Benefits
management work has been undertaken, but opinions seem to be divided on the value of
formal stakeholder analysis, on the basis that “the project is going to happen anyway”.
On the “what often happens” slide, the “I really want to support the global initiative but
…” bullet provoked recognition and discussion. Much time and effort has been expended
on negotiations concerned with getting around the problems in this area.
Benefits management work has been undertaken with the process managers to understand
the enablers, changes and benefits, mapping out benefits dependency networks.
However, the benefits have not been “signed up to” by the business units yet. Some
major benefits cannot be considered at present, e.g. overall supply chain, until all the
business units are using the new systems. From the “experience from many projects”
slide, the point was made that huge benefits are expected from increased stock turns as a
result of the new system.

Competences
One aspect to come out of this discussion was a recognition that one of the key skills that
would be required within the EBSC support centre would be negotiation skills, as well as
suitable processes and procedures. It is recognised that the EBSC support centre will
need to move from its current systems / technical focus as the project progresses.
Currently they are fielding requests for system changes, thus helping to control scope at
this stage.
Project
Perceived Manager & team
resource 2 groups:
demands 1 3
(a) a) Opco Managers
b) Process Managers
who have potential
Actual 2 overlap of interests &
resource Line (b) benefit/change ratios
Senior managers
demands
management
Clear
agreement on
scope &
and want to minimise required
changes to avoid benefits of
business discontinuity change
Required Perceived
change change
effort effort
Figure 4a.3
Change process management (see Figure 4a.4)
In terms of the “change process management” model, it appears that there have been
changes in emphasis over time. The early ES studies were essentially in “belief system”
mode, taking the initiative for progress. However, the resulting proposals were
considered too expensive, and the boundary for control became the project budget. The
initial approach was to move from top down / rational “belief system” management into
“boundary control”, taking the initiative forward through partial coalitions / trust and
relationships. However, this approach was also seen as potentially too costly and risky.
The project has since followed two paths, partly through “interactive control” involving
rationalism / partial coalitions, between the project team and some (mainly process)
groups and partly via diagnostic control, largely through negotiation involving building
trust and relationships in order to deal with and accommodate local opco and functional
issues.

PARTIAL
COALITIONS
Rational INTERACTIVE CONTROL
BELIEF
SYSTEM
BOUNDARY
Trust/ CONTROL
Relationships
DIAGNOSTIC
CONTROL
Segmented
Institutionalism
Figure 4a.4

4b) Mitel Networks
Introduction
The case study describes two distinct phases in the implementation of an ERP system at
Mitel Networks. This first phase, which occurred between late 1998 and April 2000, saw
the implementation the SAP ERP system across the two operating regions of Mitel
Networks, North America and the EMEA region (Europe, Middle East and Africa). The
second phase, which occurred between 2000 and 2001, saw the implementation of a
Service Management (SM) module in the EMEA region alone. The ERP
implementation, although not viewed as unsuccessful, was four times over budget as took
twice as long as expected. Even more importantly, however, few if any business benefits
from this implementation can be demonstrated. In contrast the SM implementation was
both on-time and on-budget and, most importantly, considerable financial benefits and
performance improvements from its deployment have been realised and can be
demonstrated.
Those present during the case study interview were:

Cenydd Burden, Mitel Networks
Peter Acreman, Mitel Networks
John Ward, Cranfield School of Management
Elizabeth Daniel, Cranfield School of Management
Mitel Networks
Mitel Networks provides software and hardware for networking within and between
businesses. Their systems are based on broadband IP communications and allow
businesses to integrate their voice and data networks. They currently serve the education,
hospitality, healthcare and government markets. In the case of large companies, sales are
made directly to customers whilst sales to smaller companies are made through resellers.
The company also provides equipment and software to original equipment manufacturers
(OEMs) for inclusion into their own products.
In addition to the hardware and software associated with the direct operation of such
networks, Mitel has applications in the fields of speech recognition, contact centre
management, wireless mobility and advanced messaging.
Mitel is headquartered in Ottawa in Canada and has operations in 71 countries around the
world. The European headquarters are based in Caldicot in South Wales. Revenues for
Mitel Networks in 2001 were in excess of £300 million and they employ approximately
3,000 staff.

Phase 1: Project Genesis: A Global ERP Implementation
In late 1998, the EMEA region of Mitel Networks began exploring the deployment of an
ERP system. This exploration included the development of a benefits case, facilitated by
John Ward from Cranfield School of Management, but no decision on a preferred vendor
was made.
About this time Mitel also acquired Plessey Semiconductors. They were already
operating a SAP ERP system. SAP subsequently became the vendor of choice for the
Mitel ERP system as it was assumed consistency of systems throughout a business would
offer advantages. Although that is often true, in this particular case, the need for
integration between the businesses was not high. The traditional network business and
the newly acquired semiconductors business are very different – networks tend to be
bespoke for each customer whilst semiconductors are made in bulk. The businesses
therefore had distinct products, customers and processes. (Note: The semiconductors
business has since been divested.)
The N. American region of Mitel became interested in ERP deployment and put together
a business case arguing the improved return on investment of a single ‘global
deployment’ throughout all regions of the organisation. Once this was approved, a large
global team was formed, led by staff in N. America, who took over responsibility from
the earlier team in EMEA. The scale of the new project seemed overwhelming, as one of
these former team members commented ‘we were overtaken….they started to turn up
over here and ‘do’ SAP to people’.
Rather than focus on the business benefits of the ERP deployment, the global team
developed a highly technical approach and the whole project became dominated by
technical issues. The project was dogged by schedule delays. These were caused by
constantly shifting priorities and conflicts between project management approaches.
Some of the key issues that took stranglehold of the schedule were:
– single or multiple SAP clients (one for each of the two regions or one for each of the
different businesses, such as networks and semiconductors)
– should it be one project with one project team or should it be a separate ‘semi and
systems project’
– appropriate implementation methodologies (ASAP or the Deloitte & Touche
methodology)
– an insourced or outsourced solution
– should UK or N. America go live first
These issues became ‘highly political’ and took considerable time to resolve
(approximately 9 months). One of the interviewees suggested that ‘with a business
benefits approach – that is a clear set of objectives for the project – then the answer to
many of these issues such as the number of clients would have become obvious and we
wouldn’t have taken so much time over them’.

A Plain Vanilla Solution
A decision was made to implement an identical SAP solution in Mitel to the one installed
at Plessey Semiconductors. It was assumed that the learning and experience gained in
Plessey could be transferred to Mitel and the majority of project leaders for the project
were selected from Plessey to try and facilitate this transfer of knowledge.
The Plessey solution was also viewed as standard implementation – termed plain vanilla
– and therefore would be simple to copy across to Mitel. However, the system had, in
fact, been modified by Plessey and was therefore no longer standard.
The modules that were implemented in the first phase of deployment were all those
involved post receipt of an order, that is: finance and control; purchasing; materials
management; production planning; and sales and distribution (including warehousing and
shipping). It was initially intended that a business reporting module would be
implemented but this was not undertaken.
Cross-Functional Project Teams
Project teams for the implementation consisted of both IS and business staff. Although
the teams worked well together, a gap seemed to open up between the team and the rest
of the organisation. This gap was compounded by the perception that those in the project
team were the ‘best’ people, seeming to form an elite that was somewhat at a distance
from those in the rest of the business.
Don’t Screw the Business Up!
External consultants were hired to help with the implementation. As the project started to
take longer than expected, this resource became increasingly expensive and pressure was
put on to get the system implemented as soon as possible. Due to this time pressure, the
system was not prototyped and only shown to users three weeks before the go-live date,
at which point it was too late to make any suggested modifications.
This pressure also de-motivated many of the staff in the organisation – they felt that the
implementation was being ‘done to them’, rather than they were part of it. Training was
given to all staff who would be using the system, but this focussed on how to operate the
system.
With the pressure to get the system in quickly, the over-riding success factor for the
project became – don’t screw the business up – rather than a focus on what benefits or
improvements in performance were expected to arise from the system.

The system went live in both regions and both business streams on April 1st 2000. It had
been intended to have a staged go-live, but the delays incurred caused pressure to bring
all the systems on by the financial year-end.
Perceived Benefits of the System
The system implementation was a technical success in that all modules were up and
running at the go-live date and any glitches were ironed out within a few days. However,
in some cases business reporting from the system was actually more limited than that
which had been available previously. This led to a perception amongst some staff that
the implementation was less successful than they had expected it to be. For example,
salesmen began to believe that the time taken from placing an order to the goods being
shipped had increased post implementation. This was indeed true for a couple of days
whilst a problem with the system was rectified, and thereafter this time period was
reduced. However, the original perception that the system was slower than the original
systems persisted.
The original benefits case, made out in late 1998 by the EMEA team, was re-assessed by
this team post implementation. Many of the benefits identified had indeed been realised,
although not always due to the implementation of the ERP system. The N. American
team was unable to do such an assessment as they had not developed a benefits case prior
to the implementation of the system.
Overall the system is viewed as a moderate success in that the business continued to
operate without a hitch - but with a feeling that more could have been achieved, as
described by one interviewee ‘its our old business on a new system – but the new or extra
benefits that we expected have not been realised’.
Phase 2: Service Management Implementation in EMEA
The second phase of the ERP implementation covers the deployment of SAP Service
Management and Business Warehouse modules within the EMEA region alone. These
modules were intended to support the operations of the Mitel service engineers (120
staff), third party service engineers (30) and technical staff within the centre (80).
Supporting elements from the HR module, such as a database of service staff
maintenance skills, were also deployed as part of this implementation.
Although the geographic scope and the number of business activities covered in this
second phase are less than in the first phase, there is still a considerable challenge to the
organisation. The SM module covers the most complex area of the business and the
version of the software installed was the newest to go-live in the UK.

A Benefits Approach
A number of successful benefit management workshops were held with relevant staff in
the early days of the project. This helped to gain their understanding and commitment to
the project. The project sponsor was particularly keen on the benefits management
approach and encouraged and reinforced its use on the project.
The original business case was prepared in May 2000 although this not approved until
nearly a year later in February/March 2001. The intervening period was used to
undertake prototyping work and to develop a business blueprint that showed how the
system would support the activities of the service engineers.
Many of the benefits associated with the system are around assessing contract
profitability. Prior to the system deployment, salesmen would sell a service contract to a
customer without knowing if it was likely to be profitable. The new system provides
complete and up-to-date information on the actual use of service engineers’ time and
parts installed, allowing the true cost of serving individual customers to be assessed and
service contracts priced accordingly.
The benefits management approach also identified the need to make organisational
changes if the desired benefits were to be realised from the system. Twelve key business
change requirements were identified and action plans developed in order to achieve these
changes.
Learning by Doing – The Benefits of Prototyping
The delay in obtaining approval for the SM module was spent building a prototype for
the system which proved valuable in demonstrating the use and benefits of the system to
users and other stakeholders. The early creation of a prototype allowed users feedback to
be collected and incorporated into the final system. In addition to highlighting system
changes, the early prototype allowed additional organisational changes necessary to be
identified and addressed.
Improved Management of Consultants
The adoption of the benefits management approach led to an improved use of consultants
compared to the genesis project. The allocated spend for consultancy assistance was
clearly set out at the start of the project. If additional resource was necessary, the impact
this requirement had on the benefits realisation was examined.
There is always pressure to use more consulting days but we needed to keep within the
budget and focus the consultants on the main delivery areas. In Cranfield speak this is
‘IT investment which is sufficient to do the job’.

The consultants were fully briefed on the benefits approach including the benefits
expected from the system. They were therefore fully aware of the priority of tasks
associated with the project and could address their work accordingly, without being
constantly monitored by Mitel staff.
In the Genesis project, most of the SAP skills resided with the external consultants
engaged to assist with the implementation. In the SM deployment, transfer of such skills
to Mitel staff was specified as an important aspect of the project at its outset. Acquisition
of such skills would ensure that the organisation reduces its dependency on external
consultants in the future.
A Staged Deployment
Unlike the big-bang approach to go-live adopted for the genesis project, the SM project
was rolled out in a series of smaller stages. The first deployment was for a large service
contract with Glasgow schools. Although this was a fairly large and important contract,
it was relatively self-contained and allowed the system to be tested out in isolation from
other parts of the service function. This contract also involved only half of the process
covered by the system. Once again, this allowed testing of the system in stages.
The second deployment of the system was with EDS at Telford. Here the remaining half
of the process covered by the software could be tested. Learning from the first
deployment was incorporated in the second deployment.
Timing of the roll-out of the system was based around the needs of the customer. In the
case of the Glasgow schools project, go-live was organised for a week before the school
term started, so users could familiarise themselves with the system in a quiet period. In
contrast, the go-live date for project Genesis was determined by the finance function
rather than the staff who were to use the system.
Full roll out to all 1200 other sites with Mitel service contracts was undertaken in
November 2001, seven months after approval had been given for the project.
On-going Developments: Business Warehouse
Subsequent to the SM implementation, a business warehouse implementation is being

undertaken and, at the time of writing in May 2002, is still ongoing. This project aims to
collect data on service activity by Mitel staff and those of third party service providers at
individual service contract level, in order to allow information on the service provided
and the profitability of individual contracts to be determined. As Mitel moves away from
selling products, to increased sales of service contracts a system to help the provision of
this service and provide and understanding of its pricing and profitability is increasingly
important to the company. Even the ability to easily access complete and up-to-date
information on service contracts will provide benefits to the organisation. For example,

knowing the renewal date of contracts will allow sales staff to ensure contracts are
renewed promptly and not allowed to lapse. The data captured and its analysis may also
allow the identification of new service packages to be sold to customers.
This project has been broken down into three stages, prioritised according to the needs of
the users and the benefits that they will derive, accordingly:
1. Reports to customers on the service that they have received
2. Key measures of service activity for management
3. Measures to demonstrate benefit delivery from SM project – such as contract
profitability, performance of third party service providers
The warehouse is a key element in deriving the full benefit of the SM module. Without
the implementation of this module ‘we would just have had the old business on a new
system - the business warehouse changes this’. The need for the business warehouse
module was identified through adopting the benefits management approach.
Cranfield Frameworks
Following the discussion of the two phases of the ERP implementation, a set of
frameworks developed by Cranfield School of Management as part of the research
project were presented and their applicability to the experience of Mitel was discussed.
STAGE MODEL
Overall
Future
Business
Vision to add benefit Business
Strategic EMEA original ERP
implementation to business Vision
Intent
Vision limited to ‘don’t
Project Genesis: Global
screw the business up’
ERP Implementation Initial
ES Vision
New
Business ES -
Problems Strategic
problems”
PLAN SHAKEDOWN
Project Genesis became a key ONWARDS & UPWARDS

operational/support project due to Very short after Project
its focus on technology delivery Genesis - project team
disbanded immediately

- Canada could not do benefits review as they had no original
benefits case
- EMEA undertook benefits review and identified service
management as a future opportunity
Figure 4b.1

Figure 4b.1 illustrates how the original ERP implementation envisioned by the EMEA
region commenced with an identification of the benefits to the business of such a system.
This approach allowed EMEA to articulate a vision of how the implemented system
would operate in the future and importantly, how it would support their future business
plans.
Project Genesis expanded the original, region specific implementation to a global

implementation, increasing its size by approximately a factor of three. The increased
complexity associated with this increase in size, resulted in a emphasis on technology –
ensuring the system went in and was working. Rather than a concentration on how the
system could support future business plans, the size of the implementation resulted in the
objectives of the implementation being scaled down to ‘don’t screw the business up’.
The shakedown phase after project Genesis was very short, with the project team being
disbanded almost immediately. The N. American region could not undertake a benefits
review or ensuring benefit delivery, as they had not prepared a benefits case prior to
implementation. EMEA undertook such a review and identified service management as a
future opportunity for phase 2 of their ERP vision.
Project Genesis: Global ERP Implementation
Management Approach
Organisational
Mode
In
potential benefits – EMEA changes and shared timescales , resources
Business
Rational agenda
Business Case and
learning and local benefits
Overall Plan
Shared vision of Co-operative change

Trade-offs in
Trust/ potential benefits management to
resources, benefits
Relationships achieve the mutual
and acceptance of the and changes can
benefits
need to change be agreed
3 4
benefits only – Trade-offs between on all aspects of
2
Segmented if no local benefit minimise negative benefits resources, IT
Institutionalism affects (and probably changes etc. with agenda
and other parts of
organisation
- caused focus on technology

- system fully implemented and operational but few business benefits realised
Figure 4b.2
Figure 4b.2 shows the evolution in the organisational and management approaches during
Project Genesis. The project commenced in EMEA with a clear vision of what the
organisation wanted to achieve (1). As the project expanded to a global implementation
groups started to form to represent or protect their local interests, as described by one

interviewee; ‘it became very political’ (2). In order to make progress, trade-offs then
need to be made in order to make progress (3). However, the only common ground is
that of technology implementation and so the focus of the project became entirely on
technology aspects, as described by one interviewee; ‘there was a lot of discussion about
how many SAP clients there should be – should it be one for each region or one for each
product line, that is semiconductors and networks’ (4). The result was a system in which
the technology was implemented, if late and over-budget, and that worked, but from
which few if any business benefits are realised.
EMEA Service Management Implementation
Management Approach
Organisational
Mode Vision
In
potential benefits – EMEA changes and shared timescales , resources
Business
Rational agenda
Business Case and
learning and local benefits
Overall Plan
2 Planning
Shared vision of Co-operative change
Trade-offs in
resources, benefits
Relationships achieve the mutual
and acceptance of the and changes can
benefits
need to change be agreed Implementation
3
benefits only – Trade-offs between on all aspects of
Segmented if no local benefit minimise negative benefits resources, IT
Institutionalism affects (and probably changes etc. with agenda
and other parts of
organisation
Figure 4b.3
The evolution of the organisational and management approaches during the SM module
implementation in the EMEA region is shown in Figure 4b.3, and can be seen to have
followed a very distinct path. The project commenced with a clear vision of what the
organisation wished to achieve from the system from the development of a benefits plan
(1). As the project moved to the planning stage, co-operation was fostered between the
stakeholders to achieve mutual benefit. For example, the go-live date was chosen as one
that was achievable for those implementing the technology solution but also matched the
requirements of the users as being deployed outside of a high-risk busy period (2). As
implementation progressed further detail was agreed by continued discussion with those
stakeholders affected.

Project Genesis: Global ERP Implementation

Project Managers - multiple
4 project managers project managers didn’t work
- 2 Mitel staff together and spent time GAP
- 2 consultants acting negotiating with senior
as project managers management for resources. This
caused a gap to open up with the
Perceived line managers who became
resentful resulting in a feeling of
resource Project ‘SAP being done to them’.
demands manager
Actual
resource
demands Senior Line
management managers
Required Perceived
change change
effort effort
Figure 4b.4
Figure 4b.4 shows the relationship between the business (line managers), the project
managers and the senior managers during the two phases. In project Genesis, there were
four separate project managers, two Mitel staff and two external consultants.
Considerable time was spent with these four individuals attempting to reach agreement
between themselves. This resulted in them negotiating with senior management for
resources for their particular aspect of the project and a gap resulted between these two
groups and the rest of the business. This resulted in the feeling, expressed by one
interviewee as ‘to those in the business, it felt like SAP was being done to them, rather
than they were involved as part of it’.

Project
Perceived manager
resource
demands
Project
Genesis Project Manager
Actual - was a senior business manager who had
good access to resources therefore did not
resource EMEA SM need to negotiate for them
demands Implementation
Line manager
Senior management
Required change Perceived change

effort effort
Key Project Genesis : Global ERP Implementation

Q EMEA Service Management Implementation
Figure 4b.5
The relationship between these three key stakeholder groups for project Genesis and the
later SM implementation is shown in Figure 4b.5. In project Genesis, there were
considerable gaps in the perceived resource requirements and change capabilities
between these three groups. The project manager for the SM implementation was a
senior manager from the business. His seniority gave him good access to necessary
resources and therefore there was no need to spend considerable time with senior
managers negotiating for these. This allowed him to keep close to the business and
ensure that the project was meeting their needs – of which he already had good
knowledge from his own experience of the business. The difference between the views
of these three groups was minimised in the SM implementation and hence potential
conflict was avoided.

4c) A Pharmaceutical Company
Introduction
The pharmaceutical company concerned preferred that its name was not used in the
report. It is therefore referred to as APC throughout the rest of the report.
This case analysis is based on a telephone interview by Phil Taylor with the Exploitation
Manager, ICON project, June 2002.
Background
APC is one of the world’s top pharmaceuticals companies with pro forma 1998 sales of
over £10bn. Headquartered in Europe it has R&D, manufacturing, distribution and
marketing companies spread around the globe.
Starting in 1997, the Supply Chain Programme (SCP) was due to replace 17 legacy
systems with one integrated system, based on SAP R/3. The SCP was designed to be a
replacement project and not a re-engineering project, although some business process
improvements were being made as part of the programme – taking advantage of easy
benefit opportunities presented by SAP (Figure 4c.1).
Overall
Future
Business
Sustain future Business
Strategic business growth Vision
Intent
Reduce business risk
Improve regulatory compliance Initial
ES Vision
New
Business ES -
Problems Strategic
problems”
17 legacy systems
pose risk to future
business
PLAN SHAKEDOWN
(SCP) - ICON project Commissioning project ONWARDS & UPWARDS

billed as a systems to “embed” the new
replacement project systems & processes, deal with ‘INNOVATION
organisationalproblems & move BASED’
‘PROBLEM BASED’ towards process based working
Figure 4c.1

The SCP project was renamed ICON, and went live in two phases in 2000. The first
phase, in July 2000, was for bulk drug production. The second phase in September 2000
was for the rest of manufacturing, sales and marketing.
From a systems / technical point of view the implementations went well, however,
significant “people” related issues surfaced throughout the implementations and
afterwards. In Feb 2001 a decision was made to initiate a “commissioning” project to
“embed” the system and associated processes. This project ran up to the end of 2001. In
effect, the ICON project has moved from a “shakedown” phase following go-live,
through to “exploitation” (“onwards & upwards”) as the new systems and processes have
become fully bedded in and people have become comfortable working with them.
The ICON commissioning project
Whilst the systems / technical implementations went well, there was an unanticipated
impact on people within the business, which was considerable in some cases. An impact
on production had been expected, and production had been “ramped down” prior to
implementation. However, the reality was much worse than expected. A general “slow
down” was the overall result of needing to spend time getting people up to speed on the
new system / new processes. Particular problems occurred where “exceptions” needed
work-arounds, and where lack of knowledge of the new systems / processes held this up.
There were customer service “issues” for several months.
In Feb 2001 a decision was made to initiate a “commissioning” project to “embed” the
system and associated processes. This project ran up to the end of 2001. The project
started to address four main areas:
1 The system itself

2 Training & knowledge transfer/management
3 Data management & ownership
4 Business processes / behaviours / ways of working
Areas 2, 3 & 4 were significant, and started off with a “gaining control” phase, getting
the issues out and prioritising them in order of importance high/med/low. Two major
strands of the project were:
- Engaging with the organisation and business management, discussing what the
new systems & processes really meant to them.
- Transferring ownership of the new system & processes away from the project to
the business itself.
This work flushed out areas where the process understanding had always been weak, and
where the new system had compounded such weaknesses e.g. areas where people didn’t
fully understand why things were done the way they were in the old system, leading to
difficulties in understanding what needed to be done in the new system. This had not

been helped by people who had been involved with the implementation project moving
on to other things post project, and taking their knowledge with them.
Embedding the new systems and processes
The commissioning project has helped the organisation move towards process
management. In some areas, however, the organisation is predominantly organised on
functional lines, and the old legacy systems were based on functional management.
Process ownership and governance were important issues which surfaced as a result of
the implementation. and which had to be resolved before further progress could be made.
Process based measures of performance are now used more widely with the impacts on
other groups better understood, e.g. time to process, confirm & complete an order,
despatch on time etc.
Initial user training on the new systems was perceived to have been well run. However, it
tended to focus on the system operation from a functional point of view. What was
lacking was a process-based awareness of how their work fitted into the overall process
context. Such process-based guidance has been addressed through a knowledge
management website. This website also contains hints, tips & how-tos, and is generally
considered to be a success.
Perceptions of operating problems in relation to the new systems and processes have
changed over time. In the early stages of implementation, problems were perceived in the
stability of planning. The response to such problems was to blame the new system.
However, as experience was gained in operating, planning and re-planning with the new
system, the focus shifted from blaming the system to blaming individual groups when in
many cases there was a need for several groups to work together. In essence, the
underlying problems in some cases were due to poor relationships, lack of understanding
of the impacts of actions on other groups, and even lack of mutual trust between groups,
leading to poor communications. The integration and process based working required for
the new system magnified any such difficulties.
Management approach and organisational modes
This research model provides insight into how the management approach to the project
and organisational issues has changed over time, in relation to changes in the underlying
viewpoints “organisational modes” concerning the new systems and processes (Figure
4c.2).

Management Approach
Mode COALITIONS
Rational
Business Case and
Overall Plan 1
learning 5 and local benefits

Relationships and acceptance of the achieve the mutual 4 resources, benefits
and changes can
need to change benefits
be agreed
benefits only – 2 coalitions to
on all aspects of
resistance to change
minimise negative 3 implementation –
Segmented if no local benefit benefits resources,
Institutionalism affects (and probably
changes etc. with
and other parts of
organisation
Figure 4c.2 - Management approach & organisational modes

1. Prior to go-live, throughout the SCP project, the predominant organisational mode
was rationalism, with an overall top down centralised approach to managing the
project. However, due to the nature of the organisation, “top down” imposed
management was not the traditional style of working, with business functions
having considerable autonomy.
2. Immediately after implementation / go live, the predominant organisational mode

shifted considerably, into “segmented institutionalism”. This reflected the way that
the organisation was functionally orientated. The response to the new system was
that it was being imposed upon them – “no benefits for me”. There was a feeling
within the project team that a stronger top down approach at this stage was required
in order to move the project forward.
3. Much of the time and effort within the commissioning project has been spent on
moving the organisation from a segmented, functional viewpoint into a process
based way of working. This change has required new levels of trust and changed
relationships between groups within the business. A significant amount of time has
been spent learning through living with the new systems and processes and
understanding impact of process working.
4. The commissioning project has been working on “co-operative change

management”, and has helped with some relationships. The knowledge
management website is an example of how mutual benefits can be gained through
shared learning.
Resource demands and perceived change capability
Typically, discussions between project management and senior business management

focus on obtaining sufficient resources for the project in order to balance the perceived
resource demands and perceived organisational change capability. The ICON project was
no exception, and both project management and senior management overerestimated the
actual change capability of the organisation in terms of its impact on operational line
management and hence did not consider the resource implications outside of the project
fully.(Figure 4c.3)
Project
Perceived manager
resource
demands
Planning focused
on resources mainly Line managers
Actual perceptions of the
resource Senior change impact varied
considerably
demands management
Line managers
Senior managers
underestimated
the change impact
Required Perceived
change change
effort effort
Figure 4c.3 - Resource demands & perceived change

Senior management also failed to recognise the extent of the changes that the ICON
project would bring for the organisation. The (SCP) ICON project had been specifically
billed as a “systems replacement project”, implying minimal change to the organisation.
There was also an unwillingness to consider further business process re-engineering,
following on from negative experiences some years earlier. The project manager had
tried to help senior management to understand the impact of change that the ICON
project would bring. However, without having first hand experience of “living with” the
new systems and processes, it was difficult to get over what they would actually mean in
practice.
Line management perceptions of the changes that ICON would bring were also varied.
Some line managers had thought through the impact very carefully, and implementation
in these cases went very smoothly. These cases tended to be where the manager had
realised that the particular function or department would be unable to function without
the new system. In contrast, other line managers had not thought through the impact of
changes that the new system would bring. They considered that the new system would
just be “background” to their operations, and were subsequently surprised when
inevitable problems hit during implementation.
Change process management
Knowledge management provides a clue as to how difficulties in implementation could

be predicted and avoided. In departments where the operational knowledge was explicit
e.g. detailed work instructions, implementation tended to go smoothly. However, where
other departments relied much more on tacit knowledge, i.e. not proceduralised, problems
were encountered in the implementation. Not only was the existing knowledge difficult to
make explicit, also the impact of new systems and procedures could not be predicted.

New beliefs & BELIEF BOUNDARY Traditional style for

“softer” measures SYSTEM CONTROL APC - taking
initiatives within
functional boundaries
ICON project has used
all four types of
Tacit Explicit
Knowledge Knowledge
aspects of
(Vision) implementation and at (Detailed)
Implementation different times Implementation
problems where smooth where
knowledge tacit knowledge explicit
Watching out CONTROL CONTROL Process based
for “icebergs” performance
measures
Figure 4c.4 – Change process management
In terms or controlling the organisation, the organisation has in the past tended to use
“boundary control” – taking initiatives within functional boundaries (Figure 4c.4).
However, to implement and exploit the new systems and processes needed everyone
pulling together. Moving to process working required more emphasis on process
measures and an orientation towards overall business performance. Within the
commissioning project a further subtle change then began to take place. A firm reliance
and insistence on performance facts, figures and statistics began to be supplemented with
“softer” measures of contribution. Through living with the new systems people started to
trust new beliefs, and these were tracked with various groups e.g. “how does it feel? – is
it getting better or worse?”. Interactive control also now has a place, with an official
“icebergs list” – watching out for up and coming big issues. A further level of control is
in the number and scope of business improvement initiatives. The number of such
initiatives has been significantly reduced, from many functionally based initiatives to a
focused list based on real contribution to the organisation.

Some reflections
Knowledge management may indicate where problems are likely to occur in an ES

implementation. A high degree of reliance on tacit knowledge within business operations
is likely to lead to implementation problems, unless specific steps are taken to make the
knowledge more explicit, and to highlight how tacit knowledge may need to change by
giving early experience of “living with” the new system.
The “size of the shakedown box” i.e. the extent to which post-implementation issues will
surface and have to be dealt with, is actually under the control of the project and the
organisation. It will be based on how willing the organisation and its management is to
face up to the real organisational challenges – accepting the issues and being willing to
address them.

4d) QinetiQ
Introduction
This report records discussions held on 11th July 2002 between Amjad Farooq (QinetiQ
Ltd) and Roger Elvin (Cranfield SOM) at QinetiQ’s offices in Farnborough. Further
significant, part-time contributions to the discussions were made by Dave Brockman
(Consultant, employed by QinetiQ) and John Durrent (QinetiQ). The purpose of the
discussions was to record the history of QinetiQ’s FISP (Future Integrated Systems
Programme) project as a case study for the Cranfield ISRC’s “Organisational Issues of
Enterprise Systems Implementation” research project.
Background
“QinetiQ is a new science and technology powerhouse formed from the major part of
DERA, the British Government’s elite defence research and development organisation.
With an unrivalled track record in applied science and technology, it is poised to become
a world leading business solutions provider.” (From www.QinetiQ.com)
QinetiQ has emerged from a series of mergers and re-organisations of the bodies
responsible for Defence research and evaluation in the UK. Prior to the early 1990s,
there existed a large number of independent, research laboratories in the UK, each with
its own budget. In the early 1990s, these were consolidated to create the Defence
Research Agency (DRA). As a government agency, DRA took on a supply-side role with
a part of the MoD holding the demand-side budget and acting as customer to DRA.
Around 1996/7, the MoD’s testing and evaluation facilities were added to DRA to create
DERA (Defence Evaluation and Research Agency). This was an organisation of some
12,000 staff. In July 2001, QinetiQ was established as a limited company, wholly owned
by the MoD. In response to opposition from the USA to dealing with a limited company,
part of DERA was split off from QinetiQ and retained as an MoD agency (DSTL).
The final step (to date) in QinetiQ’s evolution came in April 2002 when a ‘commercial’
organisational model was adopted which involved the establishment of organisational
sub-units called “Channels”. These have responsibility for customer-facing activities and
‘own’ customer relationships.
In the DERA structure, the key organisational sub-unit was the ‘Sector’. Sector Directors
were responsible for around 1000 staff and were very powerful politically. These
reported to a small Head Office group of Directors. In the QinetiQ structure, the old
DERA sectors have been consolidated into a smaller number of ‘Divisions’, each
consisting of about 3000 staff. The Divisions are grouped around technologies and place
a great emphasis on technical expertise. The ‘Channels’ are positioned to provide a
counter-balancing market focus.

Over the last two years during the establishment of the QinetiQ structure, a gentle power
shift from the Head Office to the Divisions has taken place.
The QinetiQ IS Function is headed by the Chief Information Officer (CIO) who reports to
the Chief Financial Officer (CFO).
The QinetiQ culture still reflects its DRA/DERA post. The senior management group
(grades 8 and 9) is populated largely by long serving members of staff who have
followed QinetiQ’s evolution from a set of public sector bodies into an integrated,
commercial entity. The management style tends therefore towards negotiation and
consensus rather than top-down direction.
Systems Evolution
At the time of the formation of DRA, a number of applications (e.g. FAMUS, ALASIS)
were developed to support the consolidated organisation. By 1995, these were perceived
to be limiting the development of the organisation. They were individual, non-integrated
solutions with “messy” interfaces. Moreover, they had been developed for a DEC VAX
platform, which was reaching the end of its life.
The STAR (Strategic Analysis and Review) project was an IT-led initiative to respond to
these issues. STAR was a ‘requirements capture’ project to identify a completely
integrated system to support DERA. STAR took most of 1995 to complete. It was a
SSADM project that encompassed “a lot of systems analysis” and suffered from ‘scope
creep’. It produced “lots of paper”. Little organisational change was being proposed –
the requirements were largely an enhancement of the status quo. On the basis of the
STAR requirements definition, a shortlist of potential suppliers was identified. When the
business case was produced in March 1996, it was rejected for a number of reasons. Not
only was it perceived to be too expensive but there was a lot of change occurring around
IT at that time. DERA IT services had been outsourced to a management buy-out of the
in-house IT function and this was in turn being sold to the Amey group. It was deemed
inappropriate to undertake a major IS project in these circumstances.
With the business case for the STAR implementation rejected, the requirements were
split along functional lines and a number of point solutions and existing systems
enhancements were developed to support the organisational development. This
continued until the summer of 1998.
Future Integrated Systems Project (FISP)
At this time, the DERA Board decided to purchase an ERP system. This decision was
prompted by a number of drivers. The issues that had prompted the STAR initiative were
still around. Moreover, there was significant doubt about the Y2K compliance of the
DEC VAX based applications. Already at this time, a more commercial future was being
envisioned for DERA and there was a desire to integrate the whole of DERA’s
commercial project lifecycle, from prospect to post-installation maintenance. Lastly, the

concepts of knowledge management were beginning to take root in the organisation,

leading to the desire for an integrated commercial database.
The STAR requirements were used as the basis of package selection and late in 1998,
PeopleSoft and Siebel were selected. There was, in addition, the need to develop a
custom-built Time Recording System.
Phase 1 (Late 1998 – Christmas 1999)
With the urgency dictated by the Y2K issue, a major project was launched. The Board
stipulated that the ‘vanilla’ ERP system was to be used and, where necessary, business
processes were to be changed to suit the ERP system. Accordingly, business experts
were seconded to the project team.
A Project Board, chaired by the Financial Director with the Chief Information Officer
and Sector Heads, was set up and met regularly during the project. However, this was
poorly attended by the operating units of the organisation.
The business refused to co-operate with the Board’s direction to the project team. They
didn’t want to change and rejected the project as “an IS initiative being done to them”.
The project lacked senior business sponsors and as a result business processes did not
change fast enough.
To achieve its tight timescales, FISP adopted a Rapid Application Development (RAD)
approach to configure the PeopleSoft package. Each module had its own implementation
team, which reinforced the DERA culture of separate functional groups.
Because the businesses were refusing to change (or at least were being too slow to do so),
a highly customised (50%) version of the ERP system was developed. As this was the
largest PeopleSoft implementation in Europe and the timescales were very tight, a team
of 150 people (including many consultants) was involved.
In spite of the difficulties, the system went live on time at Christmas 1999.
Shakedown
During the period January-March 2000, the call centre was overwhelmed, with about
25% of calls being associated with the ERP system. Calls were being passed directly to
the FISP team leaders. Some calls were associated with system faults but the principal
problem was inadequate user training. As the ERP implementation had been modelled on
the systems that had been replaced, system usage should have been intuitive once the user
was passed the initial log-on. Although a lot of training material had been produced, no
formal training needs analysis had been carried out. The training material had been
written from the perspective that the users knew nothing about the system. It was
daunting and they quickly became bored with it. It had been deemed not possible to give
classroom training to everyone, so a training database was set up with a series of

exercises (a “sandpit area”). Unfortunately this was not used, the users preferring to
“blunder around the live system”. Training was not enforced by the business. The cost
of training was to come off local budgets. A review of the amount actually spent showed
it to be very small.
A ‘mentoring’ scheme was part of the training strategy. Training of the mentors went
well - implying that the training material was satisfactory - but there was a lack of
political will to give the mentors the “space” to do their coaching. Moreover, the right
person was not always chosen. Some group heads wanted to know how the system
worked so elected themselves as the mentor. When it came to the crunch they did not
have the time available to carry out the role.
Re-organising the Help Desk
By April 2000, the evidence of the volume of calls to the help desk gave senior managers
the impression that the ERP system was not working. To address this perception, action
was taken first of all to get the help desk under control. During April 2000, the number
of calls was around 3500 per month with a response time about 5 days (from notification
to closure). By the 4th quarter of 2000, the introduction of monitoring and control
systems supported by a logging database had brought the response time down to between
1-1.5 days. The number of calls per month had remained at around 2500-3000. The
logging database showed that around 50% of these were ‘knowledge’ calls, i.e. the user
was using the help desk to ask “How do I …?” questions, instead of talking to the local
‘mentor’. This is taken as a compliment to the help desk. No action is planned to reduce
this load as it is seen as an efficient way of staff learning to use the system.
Outcome (Phase 1)
At the end of 2000, FISP was seen to have delivered a successful outcome. A very fast
implementation had delivered an integrated system that was supporting the whole
business. The users had been able to make it work (although they would have liked it to
be easier to use and more intuitive).
The ERP System was now ready to be put to the test – and two major organisational
changes during 2001 and 2002 have provided the challenge.
QinetiQ Ltd
In forming QinetiQ Ltd, a major complication arose when it became necessary to

demerge DERA into QinetiQ Ltd and DSTL, the MoD controlled agency. This involved
creating two versions of all DERA systems. The process consisted of:
§ cloning all hardware and software

§ splitting data
§ checking data
§ 3 months dummy trading

§ 6 months real trading (to show that QinetiQ and DSTL were viable businesses in their
own right)
All of this had to be completed before the formal split in July 2001.
The ‘Commercial’ model
Overlapping the formation of QinetiQ and the demerger of DSTL was the restructuring of
QinetiQ and the introduction of the “Channel” concept and new organisational sub-units.
This involved restructuring the embedded organisational hierarchy within PeopleSoft and
the installation of some new applications.
Each new application has produced a surge of help desk calls before falling back to
previous levels. At the time of writing (July 2002), response times are beginning to
lengthen and the number of open calls has increased. Both are associated with the new
Channel mode of working. This is because the business rules have not yet been fully
defined and calls are having to remain open while difficult business issues are thrashed
out.
What has been achieved?
QinetiQ now have an integrated system that supports the whole business. It has proven
itself robust in coping with two major organisational changes against the backdrop of an
evolution from the ‘old’ DERA sector structure to the QinetiQ Division/Channel
structure.
The FISP project team has become highly competent and comfortable with RAD
implementations. It is able to respond rapidly to changing business needs. The downside
is that FISP has consumed all the man-days available. As a consequence, a lot of ‘quick
and dirty’ builds have not yet been polished. The evidence for this is the large number of
outstanding requests for modification along the lines of “… wouldn’t it be easier if …”.
Resource has not been available to fulfil these requests.
QinetiQ has, however, ended up with a complex situation both in terms of the way the
business works and its technical architecture. It is now in a position to address these
issues and take cost out of the business.
Onwards and Upwards
QinetiQ’s IS function has three immediate opportunities to address. Firstly, the COMEX
outsourcing contract is coming to an end. This presents the opportunity to review and re-
organise its supply-side arrangements to create a flexible response capability to what is
seen as an inevitable state of change.
Secondly, the complexity of QinetiQ’s technical architecture needs to be simplified to

reduce support costs and to increase adaptability.

Thirdly, there is the opportunity to exploit the ERP system to build enhanced
organisational capability and to take cost out of the business. To this end, four working
groups have been set up to review QinetiQ’s business processes (“to build a value chain
that works”). This review process is beginning to deliver results as evidenced by
previously sceptical senior managers who have increased their interest and participation.
Using Cranfield’s Models
1. Stage Model (Figure 4d.1)
The determining ‘Future Business Vision’ that formed the backcloth to the FISP project
was the intended transformation of DERA into the commercial entity, QinetiQ Ltd. To
support this vision, the ES was required to provide integrated IS support for a coherent
internal value chain that encompasses the whole commercial project lifecycle.
STAGE MODEL
Overall
Transform DERA into QinetiQ Future
Business
Business
Strategic
Vision
Intent
Integrated, commercial project lifecycle
Initial
ES Vision
New
Business ES -
Problems Strategic
problems”
“Trusted Groups” formed
to re-design business
Y2K Individual applications Accommodate: processes
messy interfaces QinetiQ formation
Commercial Model
PLAN SHAKEDOWN
Tight timescales (Y2K) 50% Major help desk problems while ONWARDS & UPWARDS
package customisation Little users overcome training
business process change Huge deficiencies
project
Figure 4d.1
The starting point was a set of individual applications with messy interfaces that were
believed not to be Y2K compliant. Given the proximity of Y2000, this objective
dominated the project. Resistance to changing current ways of working (see figure 2)
caused the initial Board directive not to modify the ES package to be overturned. It was
deemed easier and faster to change the software than overcome the resistance to change.
The consequence was a hugely expensive project but one which delivered on time.

Implementation was followed by a period of user uncertainty caused by inadequate

attention to training on the part of the users. As the ES package had been extensively
modified to appear like the applications being replaced, learning new functionality was
not a key issue. Once the help desk had been re-organised to handle the volume of the
“how do I?” queries from the users, they adapted quickly to the new system.
Having solved the initial problems, the ES was positioned to accommodate two major re-
organisations to handle the formation of QinetiQ Ltd, with the demerger from DSTL, and
the establishment of ‘Channels’.
Having established the new organisational form, the FISP project can now look to
address the internal inefficiencies that have built up during the transformation. A re-
designed value chain will create a new vision for FISP, allowing QinetiQ to take cost out
of its major business processes.
2. Stakeholder Perspectives (Figure 4d.2)
Initial communication on the project was a directive from the Board to the project team
(formed essentially from the IS function) to implement an ES package. The directive to
install a ‘vanilla’ version of whatever ES was selected implied that business processes
would change to adapt to the ES package. Line manager buy-in to this approach was not
obtained prior to the directive to the project team and when they tried to enforce the
Board’s directive, they found it impossible to do so. A gap opened up between the line
managers and the project team who, without the political backing of senior management
or the time available to persuade line managers, found it easier to change the software
than entrenched resistance to change.

Time pressure of Y2K issue

forced the project team to
concede to the line managers and
customise the ERP package,
GAP
leading to huge resource
requirements
Perceived “IS project being done to them”
resource Project Refusal to adapt to package
demands manager
“Vanilla” ERP implementation
Actual Adapt business processes
resource
demands Senior Line
management managers
Required Perceived
change change
effort effort
Figure 4d.2
3. Stakeholder Relationships (Figure 4d.3)
Stage 1 : The STAR project had built up trusted working relationships to define a set of
requirements for a new, integrated information system. However, these were based on
‘old’ ways of working and existing coalitions.
Stage 2 : The Board issued a directive to the IS function to implement an ES. Based on a
vision of a commercial future for the organisation, this lacked a detailed business case or
an overall plan.
Stage 3 : The project team, composed mainly of IS staff supplemented with some
‘business experts’ accepted the challenge set by the Board.
Stage 4 : Business managers resisted the need to change and argued for local benefits
based on existing ways of working. The ES system was required to ‘mimic’ existing
applications.
Stage 5 : Individual functional teams were formed to implement the chosen ES. Senior
managers constrained by the impending Y2K issue provided the necessary resource.
Stage 6 : Post-implementation and post-shakedown, new coalitions have been formed

deliberately to design new business processes. Senior management interest and
involvement in this process is increasing.

Stage 7 : It is hoped (as this step has yet to occur) that the new coalitions will become
fora of trust, which will enable QinetiQ to re-align its business processes to remove
internal inefficiencies.
Management Approach
Mode COALITIONS 6
Clear vision of Mutual benefits from

potential benefits – changes and shared Agreement on
Rational timescales, resources
Business Case and learning but may
Overall Plan 2 reduce scope and local benefits
Project 7
Team 1
Trust/ management to
3 potential benefits resources, benefits
Relationships and acceptance of the achieve the mutual and changes can
need to change benefits be agreed
4 resistance to change minimise negative implementation –
Segmented if no local benefit affects (and probably benefits resources,
Institutionalism changes etc. with
reduce benefits)
Line Senior Management
Managers and other parts of
organisation
Figure 4d.3
4. Control Systems (Figure 4d.4)
Perhaps more so than might have been expected from consideration of comparable
organisations, boundary control represented the dominant form of control exercised by
senior management during the FISP project. This is, however, less surprising if one
considers the history of QinetiQ Ltd and its dominant culture at the time, combined with
the amount of time senior management were necessarily devoting to the transformation of
DERA into its commercial successor.
Having used a ‘Belief System’ about the future direction of QinetiQ to instill into the
project team the purpose of the FISP project, senior management allowed the project
team the freedom to use its initiative to achieve clear project goals driven by the Y2K
deadline. Senior management relaxed their initial directive and provided whatever
resources became necessary to achieve the deadline.
The project team reinforced the boundary control approach by organising itself into semi-
autonomous project groups aligned to functional areas of the business. Some degree of
diagnostic control was applied to ensure overall co-ordination in managing dependencies
between the project groups. With senior management attention elsewhere, they did not
participate actively and interactive control was not employed in phase 1. However, there

are signs that senior interest and participation is increasing and interactive control can be
expected to be applied to a greater extent in future phases.
Rational
INTERACTIVE CONTROL
6 7
BELIEF
2
SYSTEM
Trust/
Relationships 3 1
BOUNDARY
CONTROL
4
Segmented 5
Institutionalism
DIAGNOSTIC
CONTROL
Numbers (eg (1)) relate to the stages in Figure 4d.3
Figure 4d.4

5. Findings and Conclusions from the Case Studies
This section summarises the findings and conclusions that can be drawn from the 4 case
studies (5 projects) in the previous section. The findings and conclusions are considered
in the light of the models described in Section 3 and also where relevant the content of
the presentation by Alan Wright at the November workshop (3 of the cases are
international).
Three of the cases are post-implementation and include “shakedown” and “onwards and
upwards” components and one is pre-implementation. In all 4 cases the stage model with
2 major phases, essentially problem based/new baseline and innovation/new business
model, seems to fit. Even where original intentions were to link the ES as a new business
model, the eventual implementation, either by consciously accepting the constraints or by
an inability to achieve major change in one step, defaulted to the new baseline target. In
both Mitel and APC, following a shakedown phase, further extensions of the system to
Service Management in the Mitel case and process changes to take advantage of the
integrated system in APC, were undertaken to achieve innovation based benefits. In both
cases, though for different reasons, the learning gained during the first implementation
was of benefit in achieving greater success in the subsequent phases. In the QinetiQ case
the original intention was a ‘vanilla’ implementation to match current requirements; the
intention was to change business processes as necessary but this did not have business
support and did not happen. The ERP package was consequently highly customised.
It was clear in all these cases that key challenges1 to be successful, i.e.
a) change business models, and

b) change local autonomy
were not addressed in the first implementations. In each case the decision was conscious
not to change the business model significantly but in each case it appears that changing
the degree of local autonomy was ‘backed away from’ during the implementation, in
order to avoid undue conflict. Inevitably only local benefits were achieved and there is
little evidence that these were very significant in relation to the total cost. These issues
are also important in the Electrocomponents case and again the intention is not to change
the business model, but to reduce local autonomy and remove systems variations. This is
already creating issues for the implementation plan (process managers’ v opco managers’
priorities).
Overall from the evidence in these cases, the stage model reflects the reality of the
projects. In relation to the comments on the clarity of the vision (in Section 3.1), none of
the organisations attempted to introduce a new business model via the ES. Nor did any
have a new business model requiring an ES to operationalise it, although in all cases the
existing business model was not operating as well as it could and the ES was seen as the
means of improving performance by improving particular processes or combinations of
processes.
1
All notes are from Alan Wright’s presentation.

In all 4 cases, the project started as a top-down initiative strongly supported, often very
actively, by senior management. However, in the QinetiQ case the commitment at Board
level was not supported by the business heads who saw it as an IS initiative. In the Mitel
case the Genesis project became ‘top-down’ after its corporate adoption. On the other
hand the Mitel Service Management (SM) project was owned primarily by line
management with the business case endorsed by senior management.
Given the rational/top-down starting points and the lack of intent to create a new business
model, it is not surprising that, in all but the Mitel SM project, the projects generally
followed path c) through the 3x3 management approach/mode matrix. No coalitions
existed to drive through change, or even trade off change with the existing way of
working, hence existing relationships determined the overall scope of change that was
acceptable or, in the worst case, individual interests determined that only benefits
requiring minimal change would be realised. As a result satisfactory technical
implementations were achieved without causing major business problems – also the aim
at Electrocomponents. But limited benefits were delivered in the first implementation:
benefits that nowhere nearly justified the cost. In comparison with the key characteristics
of successful projects 2 all the projects, except the very successful Mitel SM project
(which did not have the ‘full corporate’ dimensions of the others), could be described as:
1. Not sustaining the project as a business initiative during execution, even if it was
initiated that way, and then
2. Compromising the business benefits to enable the new system to be implemented,
rather than focus on achieving the changes – process and cultural – that were required
to realise the benefits.
3. Not sustaining project principles (and probably not empowering the project team due
to its membership or remit) in order to achieve implementation without business
disruption.
However, following implementation, dissatisfaction with the overall outcome has enabled
new coalitions to form to gain further benefits through process and people changes,
implying a new starting point for further implementations closer to the Trust/Coalitions
‘box’, essential for effective Plan-to-Implementation transition. In the QinetiQ case the
demerger from DERA created the need for a new business model – a commercial model
– creating the opportunity to deliver new benefits in terms of reduced costs and new
business capabilities from the integrated ES. The key business managers are now fully
involved. In the Electrocomponents case, many of the potential conflicts of interest have
emerged during the planning phase and attempts are being made to bring the project back
to the ‘ideal path’ by a change in project control style from Boundary Control to include
aspects of Interactive Control (see Figure 4a.1 in Section 4a).
Overall the core 3x3 model in Section 3.5 offers an accurate diagnostic to explain the
reasons for project evolution and ultimate degree of success in implementation. When
used in predictive mode in the Electrocomponents case, it identified many of the issues
2

which the interviewees agreed were emerging and would need to be addressed and it
offered some guidance on the most appropriate choices and courses of action. It is even
more useful in combination with the change management control systems (described in
3.6) which match the overall intent of the initiative and how that intent changes as the
project evolves and explicit knowledge increases relative to tacit knowledge – as
described in the APC case.
Given the complexity of stakeholder interests in an ES project, the nature of the

relationships between the project team, senior management and line managers and the
focus of ‘project negotiations’ (as described in Section 3.4) have a significant impact on
the route the project will take through the 3x3 matrix.
Where the project team chooses first to develop a consensus amongst senior and line
management about the changes involved, it is more likely that new coalitions focused on
project scope, feasible change and the resulting benefits will emerge – either the
rational/coalitions or trust and relationships/coalitions segments. If, on the other hand,
the project team primarily consults senior management about the change plan the
resulting ‘top-down’ implementation plan will be seen as unrealistic by line managers
and the least successful route c) through the matrix will be initiated. This was the case at
QinetiQ where the entrenched resistance to change by line managers meant that the
project changed from a ‘vanilla’ ES implementation to a highly customised one to
effectively retain the status quo of local autonomy.
Equally much of the ‘negotiation’ with senior management will focus on costs, resources
and timescales which, once agreed, may well become (and be seen as) a constraint to
what can be achieved. In combination with the more protracted one-on-one negotiations
the project team will, inevitably, then have with line managers, resources and time will be
used up without commensurate project progress – leading to delays and overruns, but
with minimal benefit delivery. There is evidence of this in the Mitel (Genesis), QinetiQ
and Electrocomponents cases.
Not only will the duration and cost of the project be negatively affected by the non-ideal
routes through the matrix but the nature and duration of the ‘shakedown’ stage will also
be influenced and the potential for an ‘onwards and upwards’ stage may even be
precluded. If the project enters the self interest/top-down box, the shakedown is likely to
be difficult and extended given the lack on consensus on how to address problems and
make further changes. The ‘shakedown’ phase will be dealt with most effectively if new
coalitions of line managers have emerged who understand how to gain the available
benefits following the ‘baseline implementation’ stage, rather than the only effective
coalitions being those based on the previous (non-ES) business model. New ‘coalitions’
imply that some trade-offs amongst the individuals have been made in terms of benefits
and changes during implementation and no-one feels they have been disadvantaged (even
betrayed!) in the process. This in turn means that it is important that some changes (with
visible net benefits) are done during the initial implementation:

e.g. 3 process change in functional organisations

or, regional change in country based activities
or, changes in roles and degrees of autonomy of the units/functions.
Otherwise the ES implementation will merely reinforce the apparent risk of change and
consolidate existing relationships, making the onwards and upwards stage difficult to
initiate. Equally it is likely to ensure that an overall judgement of the success or
otherwise will be “why spend so much time and money on IT to achieve so little”? A
comment that was probably made in the first implementations at Mitel and APC.
3

6. Research Conclusions
Based on the literature on ES and current experience of best practice (from Alan Wright’s
presentation), success in Enterprise Systems implementation requires the organisation to
address a number of key issues, as shown in Table 6.1.
• It is the business changes enabled by the Enterprise Systems (ES), not the software,
that produces the major, and lasting business benefits.
• The technology is rarely the cause of failure, it is normally the result of organisational
or cultural issues being unresolved or a poor implementation process.
• To succeed business models will have to change and so will business and
organisational structures and relationships. The drivers and need for change must be
understood throughout the organisation.
• Poorly defined or ineffectively communicated business vision and strategy will

reduce the ES to a technology project only, owned by the IS function!
• Corporate IS/IT initiatives are often distrusted by the business units or functions due
to increasing control and loss of autonomy.
• There must be explicitly identified benefits both to the corporation and to most, if not
all, the units/functions involved, to enable the business changes to be made: - but
implementing an ES will rarely deliver sufficient immediate benefits to justify the
cost and effort. Exploiting the new capability will deliver further benefits, which
need to be identified at the start and actioned once the basic implementation is
completed.
• A strong, empowered, multi-disciplinary, business-led team using sound project

management principles is essential to success.
• Changing the performance measures (and even reward systems) to reflect the
interdependencies resulting from the new business model are essential, if behaviours
are to change.
• Most organisations realise (after the event) that more resources and expertise should
have been devoted to change management!
Table 6.1: Key issues in Enterprise Systems implementation

This research attempted to develop an organisational view of an ES project to understand

how an organisation can successfully address the complex combinations of issues across
the 5 themes described in section 1. That was not the original intention but from the
review of an extensive set of ES and non-ES literature, a combination of research-based
models was identified which enabled understanding of specific aspects of an ES project.
More importantly a synthesis of the models seemed to provide a coherent and consistent
explanation of why some organisations succeed with an ES and others are less successful.
Success has to be judged against the original intent and whilst many ES projects deliver a
successful technical implementation, the majority fail to produce the range of benefits
originally envisaged, at least at the first attempt.
Using case studies in 4 organisations the models, individually and in combination, were
used to ‘tell the story’ of the evolution and outcomes of the 5 projects, and provide
explanations of what happened and why. As described in Section 5, the models proved
very valuable as a diagnostic tool to identify why issues arose and why they were or were
not dealt with effectively, as well as explaining the reasons for the eventual outcome. As
far as could be tested, in one case, the models also proved useful in predicting whether
decisions made regarding the future project plan were appropriate, given the likely
consequences of the decisions.
Many of the key issues in Table 6.1 can be addressed by adopting ‘best practice’
methodologies in systems design and implementation, project, benefit and change
management. These are well known and well documented in books and consultants
methodologies. It is not the objective of this report to reiterate those, but merely to
restate that many ES projects fail because those basic methodologies and practices are not
adopted or not adhered to over the, often extended, project duration.
6.1 Enterprise Systems Objectives
Overall the generic objectives of ES, whether ERP, CRM or others are to, on an
enterprise wide basis:
- improve existing business performance

- innovate in aspects of business activities
- increase longer term business flexibility
Benefits will need to be identified against each of these, or as many as are relevant, to
gain full value from an ES implementation. Achieving each of the different types of
benefit will be affected by:
- the fit between the ES business model and the future vision and strategy for the
business
- effective implementation of the ES to enable benefit delivery
- effective change management to deliver the benefits

Benefit achievement will be impacted by the ability of the organisation to achieve one or
more of:
a) business process changes

b) changes in roles and degrees of autonomy of units/functions
c) changes in HO, regional and country based activities (in multi-national
organisations)
An example of how the intended business model determines the nature of the required
solution in a multi-unit organisation, in particular in terms of the degree of integration to
be obtained, is shown in Appendix C – from Alan Wright’s presentation. The second
table in Appendix C considers how the implementation approach is affected by decisions
on the extent of commonality and integration across the business units.
In multi-unit and especially multi-national implementations the scale and complexity of

the change management project is obviously increased (probably exponentially!)
Appendix D (again from Alan Wright’s presentation) considers the main change
management issues that need to be understood and addressed when implementing across
many units and in many countries. The dimensions of change management that the
project team has to accommodate and deal with are also described in the second diagram
in Appendix D.
6.2 Enterprise Systems – ‘best practices’
As stated above, many projects fail because of basic flaws in the approach through lack
of adoption of existing good practices or lack of effective application. The list of ‘health
check’ points in Table 6.2 can help determine whether the basics are in place or need to
be addressed before proceeding.
Yes Partially No
• Business Initiative
- Strategic objectives have been defined
- Critical success factors identified
- Success measures defined
- Project rationale and intent broadly
communicated
• Benefits driven
- Target benefits identified, quantified and
prioritised
- Benefits management process in place
- Benefits driving design and implementation

• Project Principles established

- Scope of core (thick or thin) defined
- Policy and procedures for process/country
variants agreed
- Policy for version control inc. scope agreed
- Policy for managing current initiatives agreed
• Business model driving architecture

- Future business model defined including “must
do” and “must be capable of doing”
- “To Be” business processes clearly defined
- Business model driving design and architecture
• Strong focus on Change Management

- Sufficient Change Management specialists
within project team
- Management understands are all delivering
their core responsibilities
- Formal CM methods and tools being applied
- Approaches, including communications
tailored to cultural groupings
• Project Team and project management

- Business led and managed
- Senior management including all key
stakeholders engaged and committed
- Strong, multi-disciplinary, experienced
international team in place
- Empowered project leadership
- Strong project management following clear
formal processes for planning, execution and
reporting
- Effective scope management and change
control
- Independent QA/risk management
• Holistic methodology
- Methodology covers all project
dimensions/phases
- Well supported by appropriate tools
Table 6.2: How will placed are you – a quick health check

6.3 Stakeholder Management
However, many organisations who adopt and perservere with the methodologies still
realise fewer benefits than expected, often at greater cost than expected and timescales
often significantly exceed expectations. This is usually the result of either not
understanding the organisational issues surrounding and affecting the project or not
addressing them effectively. Given the breadth of scope and complexity of
implementation of most ES, adopting good practice is necessary but not sufficient to
ensure success. Whilst the project team is tasked with achieving effective
implementation the benefit delivery depends on the contribution from a wide range of
stakeholders, who will not necessarily share the same perceptions of the project.
Understanding, addressing and reconciling a wide range of different stakeholder interests,

both individual and group, is necessary to ensure many of the inevitable consequences of
an ES implementation do not reduce or even eliminate the benefits. Typical
consequences for line managers are:
a) increased accountability with less discretion/autonomy

b) organisational and functional performance is more visible
c) trust and reliance on others to achieve targets
d) extended learning curve to conduct business in new ways
e) recognition and reward structures reflect integrated activities
f) changes in the ‘power base’ of some managers
During the implementation line managers will undoubtedly have resource problems
created by the conflicting needs to maintain business as usual whilst resourcing the
change programme. In many cases they will be providing resources to implement change
largely for the benefits of others, or the ‘organisation’ overall.
It is the lack of recognition of these organisational or stakeholder issues that often

prevents the ES investment from delivering the expected benefits. Whilst the project
team must be aware of these organisational issues and accommodate them in the way the
project is managed, they can only be resolved with the active co-operation of senior and
line management. It is the causes and consequences of these issues in terms of their
effects on the project outcome that this research attempted to address in order to find
ways of avoiding the problems or dealing with them.
6.4 Synthesised model of organisational aspects of ES Implementation
From the research five sound models/frameworks, from prior research in ES and business
change management, were identified as relevant to the core issues. They were brought
together and their relevance was tested on five case studies, to determine whether they
could explain the relative degrees of success on real ES projects. This proved very
successful, both in diagnosing why projects had particular outcomes and in predicting the
issues that would arise and why.

These five ‘frameworks’ are described in detail in the report along with the synthesised
models used in the case research and they are summarised here. The five are:
i) A stage model that reflects the ‘best’ approach to ES implementation
ii) Modes of stakeholder behaviour with respect to IT related change that affect the
outcome
iii) Management approaches to initiating and achieving change
The frameworks from ii) and iii) were brought together as the key diagnostic tool
that helped understand the causes of issues and how they could be dealt with, using
(in part) the approaches from iv) and v) below
iv) Organisational processes for managing change programmes
v) How perceptions of change by stakeholder groups affect the nature of the

‘negotiations’ between the project team and others during the project

i) The Stage Model (after Markus et al, 2000)

(see pp27-29 for detailed discussion)
ENTERPRISE SYSTEMS - STAGE MODEL (after Markus et al)
Overall
Future
Business
Business
Strategic
Vision
Intent
Initial
ES Vision
New
Business ES -
Problems Strategic
problems”
PLAN SHAKEDOWN
ONWARDS & UPWARDS
Figure 6.1
Most ES implementations, in practice, occur in 2 stages, mainly because of the

combination of objectives : to overcome existing problems or constraints in order to
improve performance and to create new capabilities based on common/integrated systems
and processes. These two objectives imply different types of benefits and different
approaches to the changes needed to achieve them – it is often difficult to identify how to
create new options until existing problems and constraints have been removed. However,
the justification for an ES requires both to be achieved. This model, like many others,
suggests that within the overall plan the first phase should produce the ‘new baseline’ –
integrated processes, systems and information to overcome the problems and enable
future business innovations and strategic changes. Almost always a ‘shakedown phase’
occurs during which performance can decline whilst the new processes and systems are
optimised and the organisation comes to terms with the consequences – such as reduced
autonomy, greater interdependence amongst functions, new performance measurements,
new working relationships etc.
Following the shakedown phase the organisation, probably in a series of smaller, more
specific initiatives, is able to identify where, either by extensions to the core applications
or through further business changes (or both), innovations in business activities and
practices can deliver further long term benefits. It is important that this is recognised and
the project set up to address both stages over time. Evidence from other studies suggests
that the first stage should be thoroughly planned, even if this takes longer than expected,
but implemented quickly across the whole organisation. Extended implementation across
the organisation inevitably prolongs the shakedown phase.

In almost all the cases studied, even when the original intent had been to achieve “the
new vision” the project became a 2 stage implementation as proposed in this model.]

ii) Modes of Stakeholder Behaviour (after Kumar et al, 1998)

Given the enterprise wide effects of an ES and the long implementation period, different
organisational stakeholders are:
a) likely to perceive the implementation differently and adopt different behaviours and
b) some stakeholders are likely to change their perception during the project and hence
their behaviours.
The introduction of new IT can provoke each of these behaviours depending on its impact
on different groups and can exacerbate existing behaviours. In essence the behaviours
with respect to IT are:
1. Rational – all stakeholders subscribe to the same organisational goals and focus on
achieving those goals through effective and efficient use of IT.
2. Trust – a willingness of (some) stakeholders to act in concert to ensure mutually

supported goals can be achieved through IT without serious detriment to any
stakeholder interest.
3. Self Interest – stakeholders pursue their personal agendas/interests and use IT to

protect their positions, often constraining the organisational use or even undermining
it.
Whilst all these attitudes will probably exist at the start of the project, how the project is
set up in terms of leadership and involvement will have a significant influence on how
behaviours evolve. The changes that produce the ES benefits inevitably lead to greater
interdependence of business activities by removing the (logically) unnecessary
reconciliation and control activities across process and functional boundaries and requires
single sources of information to be used. The clarity of the business case for the ES, in
both operational and strategic terms – i.e. how rational it is – is critical to achieving buy
in both collectively and individually by key stakeholders. However, given the trade-offs
that will inevitably be required between different groups in terms of changes and benefits,
the degree of trust in existing organisational relationships must be maintained and utilised
in defining how implementation will be achieved.
At this stage, if the majority of stakeholders are only willing to pursue their self-interests,
the benefits will tend to be reduced to those that require minimal change. However, self-
interest also can prevent serious problems in the shakedown phase if, in critical business
activities, the emphasis is on preventing undue risks of business failure due to the affects
of changes being unknown or uncertain.
For the project team understanding which behaviours exist and emerge amongst the
stakeholder groups is important in deciding the approach to working with each group.

They must also be aware of the potential changes in behaviour the approach to managing
the project at each stage is likely to produce in key stakeholder groups. Section 3.3 in the
main report discusses ways of managing the relationship with different stakeholder or
interest groups in terms of their attitude to the project and impact on project success.

iii) Management Approaches (after Ury et al, 1993)

Strengths Weaknesses
Top-down Quick and effective. Secures compliance not co-

Solution imposed by senior operation. Future impact.
manager
Coalition Effective for fixed term Exposure to risk of others

Offer support for group’s issues but not for permanent making demands, including
other key interests changes. project supporters.
Negotiation If resistance to project was Risk of reducing

Negotiate changes to justified, may give commitment/clarity of those
project plan improved project plan. already on board.
The table above is largely self-explanatory in terms of the implications of each of the
three fundamentally different approaches. In terms of an ES implementation all three
will be required, but each is more effective at different stages and to address different
issues/stakeholder attitudes. Where the implementation is mainly problem based and
time critical the top-down approach where senior management assert their authority can
be very effective. However, it is likely to defer any further innovation due to the
imposition of a solution rather than agreement to it. Obviously, to make it work requires
continuous intervention by senior management often at a level of detail where they are
not necessarily knowledgeable.
Coalitions of interest will always emerge in a large project and it is essential to utilise the
agreements that groups can reach to bring about change, but also to recognise the “unholy
alliances” that can develop to prevent change. Understanding the coalitions of interest
that exist and form during the project and how they are enabling or preventing changes is
an essential attribute of the project team.
Equally, implementation will require detailed negotiations with those who have to
change, use the system and deliver the benefits, if everyone is to be clear about their
roles, responsibilities and the basis on which they will be held accountable. The danger
is that the project team is dragged into detailed negotiations with each and every
stakeholder group before it is clear what the benefits or changes are and how they effect
the organisation and individuals. ‘Negotiation’ is successful when the facts are not in
dispute!

Synthesis of Organisational Behaviours and Management Approaches

SOME RESULTS OF THE INTERPLAY OF ORGANISATION

MODES & MANAGEMENT APPROACHES
Management Approach
Organisational TOP DOWN COALITIONS NEGOTIATION

Mode (Power) (Interests) (Facts)
1 2 3
Rational Business Case and learning – but tends and local benefits
Overall Plan to reduce scope to
agreed changes
+++ ++- +--
4 5 6
potential benefits and management to resources, benefits
Trust
acceptance of the achieve the mutual and changes can be
need to change benefits agreed
+-- +++ ++-
7 8 9
resistance to change minimise negative implementation –
if no local benefit affects (and probably benefits resources,
Self Interest reduce benefits) changes etc. with
Senior Management
and other parts of
organisation
--- +-- +++
Figure 6.3
There is always a risk of oversimplification in bringing models from different sources

together, but there is an obvious linkage between the organisational behaviours with
respect to IT and the management approaches described earlier. Adapting the
management approach to accommodate existing behaviours to avoid failure or create the
required behaviours to deliver success is an integral aspect of managing a complex
project with multiple stakeholders. The 3 x 3 matrix above, using organisational modes
and management approaches, proved a valuable tool in diagnosing the organisational
reasons for the relative success of the project case studies and provided guidance on how
to address the underlying issues.
The use of + and – signs in figure 6.3 indicates the extent to which the management
approach and organisational behaviours are positively re- inforcing or potentially
contradicting and therefore problematic. Figure 6.3 attempts to summarise the main
consequences of the project being in each box – i.e. what is most likely to happen when
particular behaviours and management approaches coincide.
Rather than describe each of the cells in the matrix again (see pp39-42) it is more
important to understand the implications for projects as they progress through time and
across the matrix. In order to achieve a successful implementation and avoid major
problems in the shakedown phase, everyone involved needs a clear understanding of:
a) the benefits they are expected to deliver

b) the changes they need to make

c) the resources they need to deploy
i.e. a detailed ‘contract’ as per box 9. This inevitably focuses on the interests of each of
the stakeholders and the ‘contract’ will be a result of negotiations on the details with the
project team and senior management. If this is not in place, at worst the business could
suffer serious disruption due to lack of understanding or poorly executed changes; more
likely is some operational problems leading to disputes about responsibility and a
protracted shakedown phase while the problems are resolved.
To reach box 9 there are a number of routes that can be taken through the matrix. Three
main routes normally lead to varying degrees of success, in relation to the intent are
shown in figure 6.4. The case studies showed that many routes are possible! but they also
showed that the management actions were normally aimed at bringing the project back
onto one of the 3 routes when issues and problems arose.
ROUTES THROUGH THE MATRIX
Management Approach
Organisational
Mode
+ positively
re-inforcing
Rational +++ + +- +- -
B
- contradicting
1 2 3
A
Trust +- - +++ + +-
4 5 6
C
Self Interest --- +- - +++
7 8 9
A = best route to achieve overall success

B = route to achieve benefits but reduced scope/intent
C = route to achieve technical implementation but reduced business benefits due
to lack of business change
Figure 6.4
The most appropriate route through the matrix depends to some extent on the objectives
of the ES project. If the intention is improve performance, and innovate in some areas
and increase long-term flexibility, route A through the matrix provides the best balance of
stakeholder involvement. If significant business change is required to produce
innovation, and that is the main objective of implementing the ES, route B will generally
be appropriate. Where the intention is mainly to replace the existing systems with the ES
package, but not make significant business changes – i.e. if the ES business model is a

close fit with the existing model, then route C will satisfactorily deliver the majority of,
the albeit limited, business benefits.
The logic of the routes and the effects of the different combinations of behaviour and
approach over the project life cycle are as follows:
1. Any ES project should start in the Rational/Top-Down segment – top management

agreeing a clear set of intentions that align the investment objectives and overall
benefits to the business drivers and communicating them throughout the
organisation. It is this business case that provides the mandate for the project team
and sets the agenda for change to deliver the ES benefits. Key issues, such as
degrees of integration and commonality needed and changes to the levels of
autonomy and how critical they are to overall success should be clearly identified.
However, with most ES implementations “the devil is in the detail” and senior
management must delegate the next stage of planning to those closer to the issues.
2. To be successful the project needs to adopt one of three modes of interaction

amongst the stakeholders and with the project team. The appropriateness of each
depends on the nature and extent of change required to achieve the objectives and
the degree of certainty of how the changes will deliver the benefits.
a) If the implementation is largely ‘problem-driven’ – to make the current

business model perform better – the change requirements should be clear and
a top-down/trust approach can be adopted, whereby senior management
impose a change agenda but allow existing organisational relationships to
work out how best to achieve the benefits. This approach naturally tends to
limit the amount of change but can also protect the business from high risk
changes that could bring it to a halt at implementation. Equally, that may
reduce the benefits achieved in the first phase and preclude or limit the
organisation’s ability to leverage later benefits through more innovative
changes. If senior management tries to impose the changes and ignores the
legitimate concerns of key stakeholder groupings, individual self interest will
become important (see below).
b) If the implementation is largely ‘innovation-driven’, requiring significant

change in the business model and organisational processes, the
rational/coalition approach fits best to create the new ways of conducting
business and deliver the consequent benefits. Given the uncertainties,
considerable shared learning is required to identify the links between benefits
and changes and how the balance affects the key stakeholders. Areas of
mutual interest amongst groups need to be identified and the new coalitions
facilitated to agree how much change is feasible and whether the potential
benefits justify it. The tendency will be to reduce the overall scope to those
areas where benefit/change trade-offs leave the majority of the stakeholders
with a net benefit.

c) Where need for and benefits of change are clearly understood and especially
where a combination of problem resolution and innovation benefits can be
shared across the interest groups the ‘ideal’ approach to detailed planning and
implementation can be adopted. This is trust/coalitions , where after
agreeing how the problems can be resolved, the relationships adapt and form
new interest groups to define the value of further, more radical changes. It is
important that the project team ensures that the problems and constraints
emerge early in the project, and are dealt with by agreement, to enable the
more difficult, creative aspects to be addressed collectively.
If, inappropriately, the project is in box 2 or 4 rather than 5, the project team
must either involve existing stakeholder groupings more in looking at current
issues (2) or create discussion amongst the groups where innovation is
expected (4).
So far project initiation should be led by senior management and then more detailed
planning delegated to the project team, working closely with groups of stakeholders
to define the benefit and change plans. The remaining segments of the matrix
address the implementation and shakedown phases of the project.
3. If the project reaches the implementation stage without establishing acceptance of

the benefits of change across the existing organisation it is almost inevitable that
the project will end up in the top-down/self interest segment. Then either senior
management, or more likely the project team, will meet serious resistance to change
except where individual managers are in control of their own benefit/change
balance. This will inevitably reduce the changes made and often the project team
will come under increasing pressure to amend the software – usually to make
change unnecessary, the benefits being reduced to those delivered by improved
software that replicates the functionality of existing systems. Once in this box the
project can either proceed to a ‘technical implementation’ only or it should be
stopped and reviewed to revert the investment to an enterprise system rather than a
series of localised improvements.
4. A project that has been in box 4 would normally evolve into 8 where, as
implementation approaches, increasing concerns about possible business
performance deterioration reduce the change agenda – each key stakeholder
wanting to avoid suffering or being the cause of the poor performance. This can
have similar affects to 3 above, but since agreement by some groups has been
reached earlier regarding benefit/change relationships, the trade-offs will be across
groups rather than individuals. The danger is that the longer the project lasts, the
more fragile the coalitions become and the more individual self-interest re-asserts
itself. Reversion to box 7 can also occur if the performance measurement system
has not been revised to reflect the mutual interdependence of groups rather than
individual performance.

5. Boxes 3 and 6 involve different types of negotiations between the project team and
stakeholder groups and in the case of box 6 amongst stakeholder groups as well.
Where the rational/negotiation mode dominates, the negotiation is based on the
known ‘facts’ about the project – the schedule, resourcing and the more obvious
benefits. This can often lead to a reduction in the change programme, in order to
bring the project ‘in’ close to time and cost estimates. The more challenging
benefits, those requiring most change, are often deferred to a later stage. Often the
project team, under pressure to ‘deliver’ are keen to keep the negotiation to facts
rather than deal with the uncertainties and complexity of the business changes. It is
better to avoid this box and deal with the detailed negotiations nearer
implementation in box 9. Almost inevitably negotiations about schedules and
resources tend to increase both unless the scope of the project is reduced to allow
for the increasing constraints implied.
Box 6 – Trust/Negotiation
To include the change agenda in the negotiations, existing stakeholder groups need
to agree trade-offs amongst the benefits and changes in relation to the resources
implied by different options. This again may reduce the scope, but with less
emphasis on the project constraints, in relation to a clear understanding of the
importance of the changes vis-à-vis the overall organisational rather than individual
benefits. Following such negotiations the project can move into box 9 where final
‘contracts’ for implementation can be agreed as described earlier.
Many ES projects that have some significant innovations in the intent (requiring new
coalitions to be formed to agree the benefits and changes) suffer early setbacks when top
management try to impose changes on the existing relationships without understanding
the detailed implications, ‘forcing’ the project into route C, rather than routes A or B.
Overall, both routes B and C, because they involve the project team and line managers in
protracted discussions and negotiations to achieve clarity on all aspects of the project
relatively early in the planning stage, tend to extend the timescale for the project and
reduce the benefits to those that can most easily be achieved – often the localised
benefits. It is therefore important that the project team attempts through its dealings with
the stakeholder groups to bring the project back to route A as far as possible. How this
can be done is considered in the next sections.

iv) Processes for managing change programmes (after Simon, 1995)

CHANGE PROCESS MANAGEMENT (Simon, 1995)

BELIEF BOUNDARY
SYSTEM CONTROL
ES - will require all

four types of
Tacit Explicit
Knowledge Knowledge
aspects of
(Vision) (Detailed)
implementation and at
different times
CONTROL CONTROL
Figure 6.5
Four different types of control system are required in major organisational change
programmes depending on the main objectives of the change. In an ES project, as
described earlier, the objectives can be of 3 different types – improving performance,
innovation and developing a more flexible, responsive business capability. The four
change management control styles are likely to be needed where all 3 objectives are
being pursued, but where the intent is more focused on problem resolution a smaller
subset may be sufficient. Equally the change control style will have to be adapted over
the project duration based on the knowledge of exactly what is to be done and how.
Irrespective of the vision, successful implementation requires a detailed understanding of
how the benefits will be obtained from the changes made through improved performance
of specific processes and activities.
Briefly the characteristics of the 4 different control styles are:
Belief System : based on clear vision and organisation core values, individuals are
empowered and trusted to determine and manage changes that contribute to that vision.
What is required will evolve as what can be achieved becomes better understood.
Boundary Control : individuals are empowered and trusted to identify the most
appropriate means of achieving clearly defined objectives and targets for improvement.
What is to be done is stated, how to do it is discretionary.

Interactive Control : the reasons for the need to innovate and change must be clearly
understood and then individuals are expected to identify relevant innovations for review
and decision making, on the options, by senior management.
Diagnostic Control : where the aim is specific performance improvements, based on

known problems or options individuals need to ‘prove’ how the changes to be made will
deliver those improvements and they will be measured on how well they are achieved.
The project team and senior management need to appreciate that as the project proceeds
the control style needs to be appropriate to the overall approach being adopted and to the
behaviours that need to be encouraged or avoided. Figure 6.6 overlays the control styles
on the matrix that combines the management approach with modes of behaviour.
OVERLAYING CHANGE MANAGEMENT STYLES
INT
ERA
CTI
VE
Rational CON
TRO
L
BELIEF
SYSTEM
BOUNDARY
Trust/ CONTROL
Relationships
DIAGNOSTIC
CONTROL
Segmented
Institutionalism
Represent the expected evolution in managing change

as the project proceeds from planning through implementation,
as emphasis evolves from overall contribution of ES to
achieving required performance improvements
Figure 6.6
As more becomes clear about the benefits of the implementation and the changes needed
to deliver them the style becomes increasingly prescriptive in order to achieve success
and avoid risks. In the early stages the Belief System encourages stakeholders to
contribute to maximising the benefits within acceptable degrees of change. Once the
objectives and benefits are clear and agreed the project team and individual line managers
need to be trusted to identify the best ways of achieving them, such that in the final
implementation clear agreement and ownership of responsibilities and accountability for
success can be determined. Hence the move from Belief System through Boundary
Control to Diagnostic Control.

Where the main benefits rely on significant innovation (i.e. some parts of the
implementation only) the Interactive Control style needs to be included to enable
creativity to define solutions and senior management involvement in decisions on the
options available.
Considering how these styles were adopted in the case studies it was clear that where the
control style evolved or was adapted it was in response to issues and problems that
emerged during the project based on increasing understanding or changing perspectives
or behaviours. Equally in some of the case studies lack of adaption of the control style
created inappropriate behaviours that caused problems in relation to the prevailing
management approach. This usually resulted in conflicts of views amongst stakeholders,
the project team and senior management, leading to delays, compromises on benefits and
changes and overall both a reduction in the objectives that were achieved and a
significant increase in the cost of the project.

v) Perceptions of Change and Project Negotiations (after Raiffa, 1982)

DIFFERENT PERCEPTIONS OF CHANGE EFFORT & RESOURCING
Perceived
Project Pro
resource je
manager bo ct and
demands t h p line
ro m
plann nding
res ject a anag
our nd
ing
e
ce o rs
dem perat discu
a
and iona ss
impr underst
s l
Actual
oves
resource
ed
demands
Shar
ore Line
ers develop m s
Senior Senior manag line manager manager
t st ra te gy ,
manager relevan nded strategi
c
te
understand in
outcomes
Required Perceived
Figure 6.9
By considering modes of behaviour, management approaches and control systems, as

described above, senior management and ES project managers can address issues
affecting the project’s success. During the project various phases of ‘negotiation’ will
occur amongst key parties and as the project proceeds knowledge about what needs to be
done will increase. It is important that a communications approach is developed which
facilitates the learning and enables different perspectives to be reconciled during essential
‘negotiations’.
The majority of the organisational issues which will emerge during implementation will
be about two critical aspects of achieving the benefits – resources and change
management. As shown in figure 6.9 senior managers, line managers and the project
manager are likely to have different views of the resources needed and the effort required
to implement the changes. The purpose of the communication approach is to reduce the
gaps in these perceptions, ideally to achieve an accurate picture of the actual resources
and actual change effort required. Whilst the ‘right’ answer is unlikely to emerge,
reducing the gaps will produce more of the benefits for less resources.
Project Managers will be concerned that sufficient resources are available to cover all
eventualities, but will probably be unaware of the specific difficulties and hence effort
required to make the changes to business operations.

Senior Management are looking for cost effective implementation and are also less aware
of the operational complexity of making changes.
Line Managers have to bring about changes and ‘keep the shop open’ and are likely to
see the change effort as substantial. However, they may have difficulty estimating the
actual resources required or be unable to separate resources required for change from day
to day activities.
In each case, the different perspectives may become more polarised if effective 2 way
communication (informing and responding) amongst the 3 groups is not maintained
throughout the project. It is not sufficient for the project manager to have dialogues
separately with senior and line managers – senior and line managers must also
communicate directly. The case studies showed that it is often this link which is weakest,
putting the project team in a difficult position. The normal response of the project
manager is to make the link with senior management stronger and the team can become
distant from (even rejected by) the line managers who have to deliver the benefits via
changes. Figure 6.9 suggests the key issues to be considered within the communication
strategy amongst the groups.
THE ADDED COMPLEXITY OF ENTERPRISE SYSTEMS
Perceived
Project
resource
manager
demands
Actual
resource
demands
Line
Senior managers
managers
Required Perceived
Figure 6.10
Given the scope and implications of ES, there is additional complexity in that not all
senior managers will have the same perceptions of the project and almost certainly
different line managers will perceive the effects on their areas differently. Therefore, in
addition the project team’s efforts must include reducing the range of perspectives within
the senior and line management ‘clusters’ as shown in figure 6.10. This should be done
as early in the project as possible to avoid serious issues at implementation. It will not be

possible to achieve agreement on all aspects, but ‘coalitions’ of managers in both camps
can be encouraged to address the collective issues and agree some of the trade-offs
between achievable benefits and changes needed. As was seen from some of the cases
major gaps can open up amongst these groups, especially the line managers, if the project
team attends too much to the senior management agenda and/or senior management,
collectively, do not appreciate the variety of perspectives held by their line managers. In
this case the senior to line manager communication link has to be coherent, representing
the senior management’s collective views, rather than based on different personal views
communicated to the line managers who report to them individually. Otherwise line
managers’ views are likely to become increasingly divergent with self interest prevailing.
The importance of consistent, explicit communication throughout the project cannot be

over-emphasised – its absence is likely to increase uncertainty amongst stakeholder
groups, and even cause them to become suspicious of what is really happening (often
fuelled by an active grapevine!). The required trust and co-operation across the
organisation will not be easy to develop or sustain without effective communication, and
this will probably result in the project not following one of the ‘success paths’ across the
matrix described earlier. The project will inevitably be in many of the cells on the matrix
at the same time, leaving the project team with an extremely difficult job to bring the
project to a successful conclusion in any dimension – time or cost or benefits. Evidence
from the case studies demonstrates this very clearly.
A final comment
As was said earlier, ES projects ‘fail’ normally due to organisational issues rather than
technology. Even when best practice methodologies are adopted, success is not
guaranteed. Understanding how the organisation, in terms of the key stakeholders,
perceives the project and is likely to behave during the project is critical to defining the
best approach to managing the project overtime and in relation to emerging issues. In
particular the project team needs to understand ‘what’s going on’ and why, if it is to
establish the most effective working relationship between it and the key stakeholders and
amongst the stakeholders.
The findings of this research, we believe, offer a very effective set of tools and models,
which are soundly based in ‘theory’, to diagnose, explain, predict and then address many
of the critical organisational issues affecting ES success. In particular, it enables better
decisions to be made about the management approach to be adopted at each stage and
provides guidance on how to get ‘back on track’ if the project is deviating from the route
required for success.

Appendix A
1. Business models
Q.1.1 What organisational attributes (e.g. management processes, competences,

organisational integration) are implied and assumed to be present within the
business models on which ES are built? (Implies customer and supplier interfaces
as well – How to carry out a business model matching assessment?)
Q.1.2 What are the consequences for an organisation which does not have these
attributes at the outset, and how to determine the level of mismatch? (How to
measure %fit & non-fit, and decide on trade-off between benefits required and
constraints.)
Q.1.3 How can an organisation best take on these new business models in order to take
full advantage of the benefits which the ES package offers?
Q.1.4 How will an ES enable or constrain organisational flexibility and adaptation? –

(flexibility, relative to existing systems)
Q.1.5 How does the understanding of the fit between the package business model at a)
executive level and/or b) operational level affect success?
2. Organisational issues & stakeholder management
Q.2.1 What are the organisational issues which have to be dealt with in an ES
implementation, what are their levels of importance, and how best to deal with
these issues? (major issues that always have to be dealt with – which issues are
corporate and which are local?)
Q.2.2 How best to reconcile differences in objectives, expectations and perceptions

amongst stakeholders? (ascertain and reconcile – should include measurement of
performance – when best to do it?)
Q.2.3 What are the drivers for integration, and is there potential conflict over the
importance of the drivers? e.g. common processes, consolidated financials. (why
integrate – what specifically is to be gained by integration – not generalities)
Q.2.4 What degree of integration and standardisation is being sought? (how to be

explicit about this so that the consequences can be understood)
Q.2.5 What do senior management need to understand, especially at the start of an ES

programme? (how senior management can have a comprehensive understanding
of what will happen)

Q.2.6 What form should senior management commitment take, and how should this be
demonstrated?
Q.2.7 How to ensure the full support of senior management in implementing ES-
enabled cross enterprise working?
Q.2.8 How to deal with information, data and process ownership – when there is only
one integrated system? (sensitive issue – often ignored?)
3. Implementation approaches
Q.3.1 What are the current implementation approaches being practised, what are their
strengths and weaknesses, and how are they being applied?
Q.3.2 What is their coverage of the people and organisational issues, and do they
explicitly identify and deal with them?
Q.3.3 What roles and competences are required by the approaches?
4. Organisational learning
Q.4.1 How best to foster organisational learning, within and subsequent to an ES

implementation? (overall question)
Q.4.2 How to take advantage of new and emergent capabilities?
Q.4.3 How to embed this learning into business operations?
Q.4.4 How to embed this learning into future change mana gement, thereby reducing the
risks of further phases of ES implementation?
Q.4.5 How to achieve significant learning by senior management, quickly, at the start of
the project? (see also q. 2.5 – may be critical factor in causing more attention to
be focused on learning?)
5. Programme management
Q.5.1 How to bring separate ES initiatives together and manage them as an overall
programme? e.g. CRM, ES, SCM.
Q.5.2 How to break an ES programme down into suitable stages/phases?
Q.5.3 How to start up an ES programme, taking into account different generic “starting
points”?
Q.5.4 What adaptation needs to take place over time to respond to changes in needs,
organisation and team composition?

Q.5.5 What are the risk factors which must be managed in order to realise the potential
benefits and avoid the potential downsides in an ES implementation, and in
particular the risks arising from organisational issues?
Q.5.6 How to ensure a continued focus on benefits realisation?
Q.5.7 How to develop a communication strategy which reduces the risks of problems
during implementation?

Appendix B
ES Checklists
These ES checklist questions have been developed both from the issues highlighted by
the literature in the literature review, and also from practical experience of ES
implementation. They are intended to inform and provide guidance by “asking the right
questions”, rather than by explicit direction. Additionally, the questions may serve to
highlight aspects which have changed, or need to change, when moving from one project
stage to another.
It may not be possible to provide satisfactory answers to a particular question at a

particular point in time for a project. However, if the issues which it highlights are
considered important for the project, then a decision may need to be made as to what
stage of the project answers should be available by. The research has indicated that many
of the problems which surface in the shakedown phase and which prevent further
progress in the onward and upwards phase could often have been avoided by asking the
right questions as early on as possible in a project.
Many of the questions are relevant to any phase of an ES implementation. However,

some are more relevant to particular phases. A table indicates which phase the question is
relevant to, by means of an asterisk in the relevant column for each of the phases; two
asterisks indicates the ideal time to address the question to minimise problems:
Pl – Planning, PR – Project, Sh – Shakedown, Ou – Onward & Upward.
1 Project established and executed as a business initiative
Pl Pr Sh Ou
1 Has the project been established and executed as a * * * *

business initiative with clear objectives and alignment
of business and IS strategy ?
1.1 Is there a clear statement of the strategic objectives driving ** * *

the project ?
1.2 Have the critical success factors been defined, both short * ** * *
and longer term ?
1.3 Have the overall measures that will be used to track * ** * *

success been specified ?
1.4 Have any constraints been identified ? ** * * *
1.5 Is the project seen to be a business rather than IS initiative? ** *

1.6 Is there alignment between the business and IS strategy ? ** * * *
1.7 Has the project rationale and importance been broadly and ** * * *
effectively communicated ?
2 Approach driven by business benefits
Pl Pr Sh Ou
2 Is the approach driven by business benefits – tangible, * * * *

intangible and strategic ?
2.1 Have the required business benefits been identified and ** * * *

quantified including timescales?
2.2 Is benefits realization driving scope, design and ** * *

implementation planning ?
2.3 Is a process in place to develop and track benefits ? ** * *
2.4 Is this process based on a clear understanding of “as is” ** * *

and “to be” KPIs reflecting those improvements which
must be achieved to deliver the target benefits ?
2.5 Is the benefits case being reviewed and refined at the * * * *

conclusion of each phase, and also when any significant
changes in the business or business environment occur?
2.6 Are responsibilities for benefits achievement defined ? ** * *
2.7 Is the business case and investment profile strong enough * **

to withstand any turndown in business performance ?
2.8 Are post implementation resources planned to ensure ** * *

effective solution exploitation and benefits realization ?

3 Future business model driving design decisions
Pl Pr Sh Ou
3 Is the future business model driving architecture and * * *

other design decisions ?
3.1 Has a "to be" business model been defined which shows ** * *
how the required capabilities including associated KPIs
will be delivered?
3.2 Does the "to be" business model define both what is * * *
required in the short term (ie life of this project) and
options that must be kept open for possible future
evolution ?
3.3 Does the “to be” business model include clear definitions * * *
of each business process including identification of those
aspects of process design which are critical to the delivery
of the required capabilities and benefits ?
3.4 Is the future business model being used to determine the * * *

required degree of process consistency ?
3.5 Does the "to be" vision include a holistic definition of the ** *
key concepts and implications in each area i.e.
organisation, ways of working, systems and data,
resources, performance management and culture and
values ?
3.6 Have principles and criteria been agreed for process ** * *

/systems variants from the standards supported by the
selected ES solution, including multi business/multi
geographic considerations ?
3.7 Is the future business model being used to determine the * * *

required degree of data standardization ?
3.8 Is the future business model being used to determine ** * *

required degree of integration ?
3.9 Is the future business model being used to determine the ** * *

required degree of consolidation ?

4 Strong focus on Change Management
Pl Pr Sh Ou
4 Is there a strong focus throughout on Change * * * *

Management ?
4.1 Has the balance between the extent of business change (to ** * * *
fit the solution) and solution change (to fit the business)
been defined and agreed ?
4.2 Has a full change impact assessment been completed and is * * * *

this refined and reviewed at the conclusion of each phase ?
4.3 Is the scale of organisation change significant ? ** * * *
4.4 Is the change to ways of working significant ? ** * *
4.5 Is the people impact significant and does it affect jobs and * ** * *
job roles ?
4.6 Does the organisational change extend across currently ** * * *

"independent" entities ?
4.7 Does this change need to be coordinated across functions ** * * *

or across business entities ?
4.8 Will the way personal objectives are set and performance * ** * *
is measured and rewarded need to change ?
4.9 Will successful implementation of the new business model ** * *

require a significant change in culture and values ?
4.10 Have key stakeholders/stakeholder groups been identified ? ** * *
4.11 Has a Stakeholder Management plan been developed that * ** * *

reflects their individual profiles ?
4.12 Is there a clear communications strategy and plan to ** * * *

explain the rationale and importance of the project and to
reflect the key issues identified in the Change Impact
assessment ?
4.13 Do senior management understand the scale and nature of ** * * *

the project challenge and the critical success factors to its
successful delivery and exploitation ?

4.14 Do senior management understand and accept their role ** * * *

and are they fully committed to driving the required
business change ?
4.15 Does the organisation have experience of successfully ** * *

managing the scale and nature of change required by the
project?
5 Strong, empowered, multidisciplinary, experienced, business led project

team
Pl Pr Sh Ou
5 Is there a strong, empowered, multidisciplinary, * * * *

experienced, business led project team ?
5.1 Has an appropriate, active senior business sponsor been ** * *

appointed ?
5.2 Has an appropriate project steering committee been ** * *

appointed with the necessary representation and authority ?
5.3 Has a business lead for each business process been * ** * *

appointed ?
5.4 Has a credible, respected project leader been appointed ** * * *

from the business ?
5.5 Has sufficient budget been allocated to the project * ** * *

including contingencies ?
5.6 Does the project team include all necessary roles eg ** * *

Business Processes, Applications, Data, Infrastructure,
Project Office, Change Management, Security/Controls,
QA/Risk management, Training, Communications,
Implementation and Operations/Support ?
5.7 Has an appropriately skilled and experienced, ** * *

multidisciplinary (multinational if necessary) project team
been appointed in line with project resource requirements?
5.8 Have personal objectives and rewards been aligned to * ** * *

project objectives ?
5.9 Are career processes in place to manage “reentry” of staff * ** *

drawn from the business ?
5.10 Are mechanisms in place to encourage and compensate ** * *

business functions making staff available to the project ?
5.11 Have non project business resources been anticipated and * * *

planned e.g. for workshops, design reviews, testing etc?
5.12 Have business skills and resources for implementation ** * *

been planned and identified ?
5.13 Have plans been made to develop and exploit the skills and * ** *
experience required for longer term solution exploitation,
support and enhancement ?
5.14 On multi phase projects has a plan been developed for staff * * *
rotation ?
5.15 Is there a succession plan for key roles ? * * *
5.16 Have sufficient external support resources been budgetted ** * * *

and made available based on the organisations competency
in projects of this nature ?
5.17 Are business responsibilities for implementation and ** * * *

benefits realization understood and accepted ?
6 Disciplined, holistic project and project management methodology
Pl Pr Sh Ou
6 Is a disciplined, holistic project and project * * * *

management methodology being used across the full
project life cycle?
6.1 Does the project methodology cover all phases from ** * *

strategy through to implementation, exploitation and
solution enhancement ?
6.2 Does it cover all required components in an integrated ** * *

manner eg Business processes, Systems and data,
Technical Infrastructure, Change Management, Programme
Management, Training, Operations and Benefits

Management ?
6.3 Have project staff been properly trained in its use ? * * *
6.4 Are effective processes in place for management of scope, ** * *

versions and change control ?
6.5 Do the project team have suitable tools to enable the ** * *

management and sharing of project information and
documents ?
6.6 Are suitable tools available to support testing including * *

integration ?
6.7 Have key project management principles been agreed and * ** * *

communicated eg enhancements/modifications to standard
software functionality ?
6.8 Has a policy for managing existing initiatives impacted by * * *

the project been agreed ?
6.9 Are effective QA processes in place ? ** * *
6.10 Are effective risk management processes in place ? * ** * *
6.11 Is there a disaster recovery plan in case of a major ** * *

implementation failure ?
6.12 Is the implementation approach phased and designed to * *

ensure early implementation ?

7 “Politics” - Coalitions / trust & relationships
Organisational power resides not only with individual managers, but also within
groupings and coalitions. An ES, though the integration which it provides, may affect the
power distribution and relationships between such groupings and coalitions. These
“political” questions are relevant to any stage of an ES project, and may serve to
highlight aspects which have changed, or need to change, when moving from one project
phase to another.
Note –This section is intended as “food for thought” – there are no yes/no right/wrong
answers here.
Pl Pr Sh Ou
7.1 What groupings/coalitions exist at present within the ** *

organisation?
7.2 How powerful (or not) are these groupings/coalitions? ** *
7.3 What are relations like between these groupings/coalitions? ** *
7.4 What levels of trust exist between these ** *

groupings/coalitions?
7.5 How will these groupings/coalitions be affected by the * ** * *

project?
7.6 How will patterns of communication between * ** * *

groupings/coalitions change?
7.7 How might the ES affect the balance of organisational ** *

power?
7.8 What new coalitions / levels of trust may need to be * ** * *

formed?
7.9 What strategies might various groups deploy to support or * ** * *

impede the ES implementation?
7.10 What might be the career implications for key stakeholders * ** * *

through the ES implementation?

8 “Politics” - Rationalities
ES-enabled integration may seem like a good idea for the organisation as a whole, when
viewed from a “rational” point of view. However, managers or groupings may hold other
perfectly rational viewpoints or rationalities within which it may seem to be a very bad
idea e.g. an overt or covert “political” agenda. The underlying conception of IS/IT within
the organisation may also affect the ES implementation e.g. IS/IT viewed as purely a
service vs. IS/IT as an agent of change. These “political” questions are relevant to any
stage of an ES project, and may serve to highlight aspects which have changed, or need to
change, when moving from one project phase to another.
Note –This section is intended as “food for thought” – there are no yes/no right/wrong
answers here.
Pl Pr Sh Ou
8.1 What is the offical “ideology” expressed by senior ** * * *

management (if any) within which the ES makes sense?
e.g. challenge for transformation, or threat to survival
8.2 What are the various predominant viewpoints / rationalities ** * *

concerning the ES implementation within the business?
e.g. rationality, its good for everyone, vs. “political
football”
8.3 What rationality(ies) is being utilised as underpinning the ** * * *

reasons for adopting the ES and associated organisational /
work changes?
8.4 What are the predominant viewpoints/rationalities ** * * *

concerning the business itself? (within the business, and
also within the IS/IT function)
8.5 What are the predominant viewpoints/rationalities ** * * *

concerning IS/IT within the business? (and also within the
IS/IT function)

Appendix C
Business model determines the nature of the required

solution
Consolidated
Local Autonomy Hybrid Single Business
Generate l Brands are planned and l Operational marketing at the BU l All aspects of a brand and
Consumer managed at the BU level, level but planning and management associated marketing
Demand including operational marketing is Europe - wide including brand operations are planned and
profitability and investment executed at a European level
Service the l Customers are owned and l Customers are owned and l Accounts can be managed at a
customer serviced by the individual serviced at the country level European level including ability
BU including, for example, one invoice, to take orders which cross B U s
shared logistics etc and countries
Supply l Supply planned and l Supply planned and managed at a l Supply planned and managed at a
Chain managed at the individual country level with factories European level with focus
BU level supporting multiple B U s + shared factories or contract
procurement, logistics etc manufacturers supplying all B U s
Finance l Finance organised to support l Finance organised as a shared l Finance organised as a European
individual BU service across B U s within a SSC with one COA providing
with local currency ledgers country financial information by country,
supporting local C O A s by category, by function
and accounting standards
LOW INTEGRATION HIGH INTEGRATION

“THIN CORE” COMMON SYSTEMS
“THICK CORE”

Impact on implementation approaches
Local autonomy Hybrid Consolidated single

business
Each business operates Retains country/business unit Plan, manage and execute as
independently independence in, for example, a single business
Business objectives sales and marketing
Tailoring of processes to local Some processes eg Supply, Pan European

Process vision requirements Finance operated at common processes
European level
Common core apps with Common apps for European Common apps, minimal
country variation core variations
System / data
Limited data standards Country variants for others Common data standards
Multiple local systems Standard core interfaced to Common customer interface

interfaced to data warehouse country/BU systems Single system, minimal
Technologies for consolidation of interfaces
information
Closer to current culture, Some central control but Centrally driven, large scale
Change management minimal change countries/BU’s retain a change
degree of autonomy
Multiple systems to upgrade Central core and distributed Single system, central
Post-implementation and maintain. Expensive systems to upgrade, maintain and maintenance, support
Implications interface maintenance. keep in sync. Moderate number of and change control
Change control complex interfaces

Appendix D
Factors influencing the scale and nature of the change

management challenge
LEAST CHALLENGING MOST CHALLENGING
LEVEL 1 LEVEL 2 LEVEL 3

INCREASING ORGANISATIONAL SCOPE
1. Organisa- l Single function change l Cross-functional change l Change across large complex
tional Scope l Multi-location change organisations
l Multi-country change
INCREASING INNOVATION AND UNCERTAINTY

2. Change l Well understood change l Largely predetermined change but l Complex, uncertain change
Complexity l Can be executed by line managers with some uncertainty and/or l Change solutions are not within the
without specialist support requirement for fresh thinking organisation’s experience or
l Requires specialist support/ knowledge
training
INCREASING RESISTANCE
3. Political l Little political resistance l Some political resistance l High political resistance
Resistance l Few if any perceived change losers l Significant perceived change losers l Large number of influential
perceived change losers
INCREASING CULTURAL CHALLENGE

4. Cultural l Change mainly consistent with l Change challenges culture to some l Change requires a radically
Challenge culture extent different culture to succeed
l Change may be blocked by cultural l The change challenges peoples’
forces willingness to change greatly
DECREASING MANAGEMENT CHANGE SKILL

5. Change l Managers have succeeded with l Managers have succeeded with l Managers have had little change
Capability difficult change programmes simple change but failed with success
difficult change

Change management must be central to the approach

and integrated into project teams
Leadership Change Strategy

l Link the success of the project to the l Pick implementation route that delivers
success of its leaders fastest benefits - not just fastest
l Define changes to leadership behaviour technology
l Plan for concurrent implementation and
live running
Change Vision Commitment

Ensure conference room l Build commitment to new ways of
l Define change
pilots prove the total strategy working, not just acceptance of the
system
vis ange
business system - not just
com
Structure conference room pilots to
Bu tment
l
the information system
ch
ion
mi
ild
ate
build commitment as well as test
Cre
solution
Deliver l Tailor help processes to user needs
Business
De
Benefits
sig
ces HR
no
HR Processes
ses
pro ment
Organisation
rga
l Recognise and reward new skills

nis
le
l Design for new
Imp
atio
management processes to and ways of working

n
Develop culture l Choose and implement new

exploit technology
performance measures to reinforce
l Design to reduce cost
new behaviours
Culture Benefits
l Define new values and l focus on business benefit - not just
behaviours required to exploit systems delivery
new systems l Make focus on benefits delivery a new
l Clarify behavioural changes way of working
required to deliver business
benefits

Bibliography
Austin R.D, Nolan R.L, “Manage ERP initiatives as new ventures, not IT projects”, 1998,
Harvard Business School working paper No. 99-024.
Avital M, Vandenbosch B, (2000) “SAP Implementation at Metalica: an organisational

drama in two acts”, Journal of information technology, 15, 2000, pp183-194
Bancroft N.H, Seip H, Sprengel A, (1998), “Implementing SAP R/3 – how to introduce a
large system into a large organization”, 2nd edn., Manning Publications, Greenwich CT.
Boddy D, Macbeth D, (2000), Prescriptions for managing change: a survey of their effect
in projects to implement collaborative working between organisations, International
Journal of Project Management, Oct 2000
Cavaye A.L.M, Christiansen J.K, (1996) “Understanding IS implementation by

estimating power of subunits”, European Journal of Information Systems, Dec 1996.
Coombs R, Knights D, Willmott H, “Culture, control and competition: towards a

conceptual framework for the study of information technology in organizations”,
Organization studies, 13(1) 1992, pp51-72
Davenport T.H, (2000), “Mission critical: realizing the promise of enterprise systems”,
Harvard Business School Press, Boston, Ma.
Davenport T.H, 1998, “Putting the enterprise into the enterprise system”, Harvard
Business Review, July-August 1998.
Deloitte Consulting, 1998, “ERP’s Second Wave – Maximising the value of ERP-
Enabled Processes”
Dong L, (2000), “A model for Enterprise Systems implementation: top management

influences on implementation effectiveness”, working paper presented at the Americas
Conference on IS, 2000.
Hislop D, Newell S, Scarbrough H, Swan J, “Networks, knowledge and power: decision

making, politics and the process of innovation”, Technology analysis and strategic
management, Abingdon, Sep 2000
Impact programme, 1998, “Achieving the benefits from software enabled business
improvement programmes”, Impact programme, 1998
Knights D, Murrray F, (1992) “Politics and pain in managing information technology: a

case study from insurance”, organization studies, 13(2) pp211-228

Krumbholz M, Galliers J, Coulianos N, Maiden N.A.M, (2000) “Implementing enterprise

resource planning packages in different corporate and national cultures”, Journal of
information technology, 15, 2000, pp267-279
Kumar K, Van Dissel H.G, Bielli P, “The merchant of Prato – revisited: Toward a third
rationality of information systems”, MIS Quarterly, Minneapolis, Jun 1998
Lee Z, Lee J, (2000), “An ERP implementation case study from a knowledge transfer
perspective”, Journal of information technology, 15, 2000. pp281-288
Lytle, A.L., Brett, J.M. and Shapiro, D.L. (1999), The strategic use of interests, rights and
power to resolve disputes, Negotiation Journal, January, pp. 31-51.
Markus M.L, Axline S, Petrie D, Tanis C, (2000), “Learning from adopters’ experiences
with ERP: problems encountered and successes achieved”, Journal of information
technology, 15, 2000, pp245-265
Overton K, Frolick M.N, Wilkes R.B, (1996) “Politics of implementing EISs”,

Information Systems Management, Summer 1996.
Raiffa, H. (1982), The Art and Science of Negotiation, Belknap Press, Cambridge, MA.
Robey D, Boudreau M.C, (1999) “Accounting for the contradictory organizational

consequences of information technology: theoretical directions and methodological
implications”, Information Systems Research, Jun 1999.
Sillince J.A.A, Mouakket S, (1998) “Divisive and integrative political strategies in the IS
adaptation process: the MAC initiative”, European Journal of Information Systems, Mar
1998.
Simon, R. (1995), “Control in an Age of Empowerment”, Harvard Business Review, 73,

2 (March – April 1995), pp80-88
Soh C, Kien S.S, Tay-Yap J, (2000), Cultural fits and misfits: is ERP a universal
solution?, Association for Computing Machinery, Communications of the ACM, Apr
2000
Sterling B, (1999), Installation doesn’t have to be painful, Computing Canada, Mar 26

1999.
Sumner M, (2000), “Risk factors in enterprise-wide / ERP projects”, Journal of

information technology, 15, 2000, pp317-327
Ury, W.L., Brett, J.M. and Goldberg, S.B. (1993), Getting Disputes Resolved, Jossey-
Bass, San Francisco.

Wah L, (2000), Give ERP a chance, Management Review, Mar 2000
Watkins, M. (2001), Principles of persuasion, Negotiation Journal, April, pp. 115-137.
Wentworth/Gartner, (2000), “Putting Customer Relationship Management to Work”,

Wentworth Management Program, March 2000
Whipple J.M, Frankel R, (2000), Strategic alliance success factors, Journal of Supply
Chain Management, Summer 2000
Willcocks L.P, Stykes R, (2000), The role of the CIO and IT function in ERP,
Association for Computing Machinery, Communications of the ACM, Apr 2000


Estudio Cranfield Sobre ERP PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Estudio Cranfield Sobre ERP PDF

Uploaded by

Copyright:

Available Formats

Organisational Issues of Enterprise

Information Systems Research Centre

Document No: ISRC-ES-200203

Cranfield School of Management

Date: November 2002

Contact: Professor John Ward

Organisational Issues of Enterprise Systems

1. Introduction and overview of the issues

2. Summary of findings from the literature review

3. Synthesis of models to enable interpretation and analysis

4. Case Studies – evidence of the value of the models

5. Findings and conclusions from the case studies

Appendices a) Initial questions

Information Systems Research Centre

1. Introduction and overview of the issues

1. “Beyond Enterprise Systems Implementation – Realising The Benefits”, December

2. “Organisational Issues of ES Implementation – Literature Review”, July 2001

Information Systems Research Centre

Figure 1: Organisational Issues – ES Implementation

From the initial workshops, 5 themes of study were identified:

Information Systems Research Centre

The key characteristics of an ES implementation that the research has attempted to

- the breadth of scope across the business functions

Information Systems Research Centre

2. Summary of findings from the literature review

ES may be characterised by high levels of process, information and organisational

Information Systems Research Centre

2.1 Business models literature

Literature coverage of the research questions within this theme:

How well does the literature

1.4 How will an ES enable or constrain organisational flexibility and

Information Systems Research Centre

Modelling business processes as a basis for selecting an ES is established practice (e.g.

Looking deeper at the organisational attributes which an ES assumes to be present,

Summary of specific answers to the research questions (where available)

2.1.1 What organisational attributes (e.g. management processes, competences,

Information Systems Research Centre

According to Bancroft, management practices will need to change as a result of the ES

Bancoft proposes that ES implementation skills may themselves become a unique

2.1.4 How will an ES enable or constrain organisational flexibility and adaptation?

Information Systems Research Centre

2.2 Organisational issues & stakeholder management literature

Literature coverage of the research questions within this theme:

How well does the literature

Information Systems Research Centre

Sillince & Mouakket (1998) studied an IS implementation in the context of university

Information Systems Research Centre

Summary of specific answers to the research questions (where available)

A comprehensive listing of the organisational issues which have to be dealt with in an ES

A useful high-level summary of the organisational issues is provided by Bancroft,

Information Systems Research Centre

- Organisational roles and structure

2.2.2 How best to reconcile differences in objectives, expectations and perceptions

Overton, writing about the implementation of executive information systems, recognises

For senior managers:

For EIS implementors:

Austin and Nolan propose a novel approach to ES implementation, treating the ES in a

Davenport notes that organisational integration, or lack of it, is a common organisational

Information Systems Research Centre

organisational integration, in many cases due to a simple misunderstanding that having an

- Education – managers need to know the implications

- strategists need to understand the detailed implications

2.2.5 What do senior management need to understand, especially at the start of an ES