Complementary Controls and ERP Implementation Success

International Journal of Accounting Information Systems
8 (2007) 17 – 39
Complementary controls and ERP

implementation success
Severin V. Grabski a,⁎, Stewart A. Leech b,1
a
Department of Accounting and Information Systems, Eli Broad Graduate School of Management,
Michigan State University, East Lansing, MI 48824-1121, United States
b
Department of Accounting and Business Information Systems, Faculty of Economics and Commerce,
The University of Melbourne, Victoria 3010 Australia
Received 15 March 2006; received in revised form 18 December 2006; accepted 30 December 2006
Abstract
Many organisations have sought to improve their competitiveness by investing in advanced information
technology, such as Enterprise Resource Planning (ERP) systems. They have implemented ERP systems
for a variety of reasons, including solving year 2000 issues, reengineering business processes, and
facilitating e-business. The implementation of an ERP system and associated changes in business
processes, however, is not straightforward. ERP implementation projects are but another example of an
information systems development project that needs to be controlled, yet the implementation of an ERP
system is significantly different than a traditional system implementation. Control can be exerted by both
formal and informal means [Kirsch, L.J., V. Sambamurthy, D-G. Ko, and R.L. Purvis. 2002. Controlling
information systems development projects: The view from the client. Management Science. 48(4): 484–
498]. Research has demonstrated that single modes of control are not sufficient, rather that a portfolio of
control modes should be utilized. We expand upon this concept and suggest that this need for a mix of
overlapping and redundant control mechanisms identified in the literature is explained through the use of
the theory of complementarity [Milgrom, P. and J. Roberts. 1990. The economics of modern
manufacturing: Technology, strategy and organization. American Economic Review 80: 511–528;
Milgrom, P. and J. Roberts. 1994. Comparing equilibria. American Economic Review 84: 441–459;
Milgrom, P. and J. Roberts. 1995. Complementarities and fit: Strategy, structure, and organizational change
in manufacturing. Journal of Accounting and Economics. 19: 179–208; Topkis, D.M. 1998. Super-
modularity and Complimentarity. Princeton University Press]. Surveys of chief information officers and
internal auditors were conducted to obtain data on the controls used in ERP implementations. We find that
⁎ Corresponding author. Tel.: +1 517 432 2922; fax: +1 517 432 1101.
E-mail addresses: grabski@msu.edu (S.V. Grabski), saleech@unimelb.edu.au (S.A. Leech).
1
Tel.: +61 3 8344 5314; fax: +61 3 9349 2397.
1467-0895/$ - see front matter © 2007 Elsevier Inc. All rights reserved.
doi:10.1016/j.accinf.2006.12.002
18 S.V. Grabski, S.A. Leech / International Journal of Accounting Information Systems 8 (2007) 17–39
groups of complementary controls need to be employed in the implementation of ERP systems to achieve a
successful implementation.
© 2007 Elsevier Inc. All rights reserved.
Keywords: ERP implementation; Complementarity; Control theory; Business risks
1. Introduction
As markets become more competitive, organisations seek new business opportunities to

enhance their competitiveness. Often, organisations focus on improving their agility, i.e., the
speed at which they can respond to consumers, improve service, enhance product quality and
improve production efficiency. It is commonly accepted that information technology should be
used to fundamentally change the business (Davenport, 2000). Many organisations, therefore,
seek to improve their competitiveness by utilizing advanced information technology, such as
Enterprise Resource Planning (ERP) systems.
The implementation of an ERP system, however, is not an easy task. It is a major project and as
such requires the organisation to pay attention to a variety of stakeholders (e.g., management,
information systems professionals, line workers, consultants, and trading partners) and the
management of their motivations and expectations (Sambamurthy and Kirsch, 2000). Without
sound management and control of both the implementation process and the organisational
changes, an ERP system implementation can be a difficult and risky process (see, for example,
Cameron and Meyer, 1998; Davenport, 1998; Deutsch, 1998; O'Leary, 2000).
ERP implementations differ from traditional systems analysis and design projects in scale,
complexity, organisational impact, user participation, cost and business impact (Bagchi et al.,
2003; Grabski et al., 2001). ERP implementations typically impact the entire organisation and are
generally associated with business process reengineering (Davenport, 2000). Traditional analysis
and design projects generally minimized business process reengineering, with the software
written to match current business processes; whereas in ERP implementations software
modifications are generally minimized, resulting in significant process and organisational
changes. Costs associated with ERP projects are significantly higher than traditional projects, and
failure can be devastating for an organisation (for example, the FoxMeyer Drugs bankruptcy
(Hyde, in press; Scott, 1999)). Finally, the dynamics of user participation in the implementation of
ERP systems are different than user participation in traditional systems development projects
(Bagchi et al., 2003).
Even though ERP implementations are different than traditional systems design projects,
creating this new enterprise information system requires technical processes, social processes, and
controls similar to those utilized in traditional systems development projects. The acquisition,
management and control of the technical skills and relationships among the diverse group of
stakeholders are required (Beath and Orlikowski, 1994; Kirsch, 1997). Control of information
systems development projects is different than other control environments (Kirsch, 1996).
Evidence exists that client liaisons to systems development projects utilize a variety of control
modes over the project leaders and teams depending upon the measurability of outcomes and
understanding of the development process (Kirsch et al., 2002). There is also evidence that a
portfolio of control modes is used in systems development projects (Boland, 1979; Orlikowski,
1991; Henderson and Lee, 1992; Kirsch, 1997). Unfortunately, the theory of portfolios of control
modes does not completely explain the control portfolios utilized (Kirsch, 1997).
S.V. Grabski, S.A. Leech / International Journal of Accounting Information Systems 8 (2007) 17–39 19
We propose that an alternative theoretical foundation from economics, complementarity,

provides a more robust explanation of the use of the various control modes. We do not predict
which controls are used; rather, we specify that in firms that implemented ERP systems,
successful ERP system implementations are associated with multiple controls, and that these
controls could be used in a variety of modes. We explain why all the controls are used in a
complementary fashion rather than having controls be substitutable, which is a possibility based
upon Kirsch (1997). We also develop a theoretically grounded framework that assists in
understanding the major risk factors and associated control procedures related to the successful
implementation of ERP systems. This theoretical framework expands on control theory and is
developed from economic theory, the literature on ERP systems and the literature on system
development risks.
This study is motivated by a lack of theoretically grounded empirical research into the risk
factors and control procedures that are critical for the successful implementation of ERP systems.
Recent empirical research has provided some insights into ERP implementation, ERP use, user
acceptance of the ERP system, and the role of the CIO (e.g., Bagchi et al., 2003; Bingi et al., 1999;
Clemons, 1998; Holland and Light, 1999; Kremers and Van Dissel, 2000; Kumar and Van
Hillegersberg, 2000; Mabert et al., 2001, 2003; Markus et al., 2000; Markus and Tanis, 2000;
Scheer and Habermann, 2000; Soh et al., 2000; Umble et al., 2003; Willcocks and Sykes, 2000;
Nah et al., 2003). Other studies identified factors that are critical to the success of ERP
implementations, such as top management support, the implementation team, organisational-wide
commitment to the system, and fit between the ERP systems and the organisation (e.g., Hong and
Kim, 2002; Murray and Coffin, 2001; Ross and Vitale, 2000; Scott and Vessey, 2000; Somers and
Nelson, 2001, 2003; Stephanou, 2000). Researchers have observed that the critical success factors
appeared to be highly correlated, and changes in any one of them would influence the others
(Akkermans and van Helden, 2002). Several researchers have focused on stage models that
categorized firms that implemented ERP systems along a continuum (Holland and Light, 2001;
James and Wolf, 2000; Peterson et al., 2001). However, none of these studies focused on controls
need to guide the organisation from one stage of implementation to the next. Thus, a further
motivation was the understanding of the control procedures critical for the successful
implementation of ERP systems.
The study also provides a much-needed foundation for further understanding the assurance
services required during the implementation and subsequent upgrades of ERP systems (or other
complex organisation-wide systems). Such insights are vital to providing practical advice to
management, consultants and auditors on how to facilitate a successful ERP system
implementation (or re-implementation). It is vital to understand the controls critical for the
success of an ERP system (re-) implementation; and also how complementary control
procedures can minimize business risk. Additionally, ERP migrations, due to either acquisitions
or ending of support by the vendor are occurring with increasing frequency. These migrations
may be as complex as the original implementation if significant modifications were made to the
originally installed software, or if the vendor has made significant changes to the original
software.
The paper proceeds as follows. In Section 2, control theory is reviewed and the theory of
complementarity is explored as the basis for the theoretical framework. In Section 3, we
examine control procedures used to mitigate risks in the implementation of ERP systems and
develop the hypothesis. The research method used and the results are discussed in Section 4.
The final sections discuss the findings and limitations of the study, and propose ideas for future
research.
2. Theoretical development
2.1. Control theory
Control is implemented and exercised through various mechanisms which results in the
regulation of behaviour (Kirsch, 1997, p. 217) and it can be implemented through formal and
informal mechanisms. The formal modes of control are behaviour and outcome (Ouchi, 1979;
Eisenhardt, 1989; Kirsch, 1996, 1997) and formal control mechanisms are generally associated
with performance evaluation. The informal control methods are group (clan) control and self
control, and are based on social and people-related strategies (Eisenhardt, 1985; Jaworski, 1988;
Kirsch, 1997). The informal control mechanisms allow the introduction of some type of self-
regulation rather than the formal control mechanisms that are based on organisational and agency
theories.
When formal control mechanisms are used, the actions of the controllees are observed, and
rewards are distributed based upon some evaluation rubric. In behavioural control, the rewards are
based upon the match between the observed actions and the pre-specified allowed behaviour.
Behavioural control is appropriate when known behaviours and observable behaviours are
present (Eisenhardt, 1985; Snell, 1992; Kirsch, 1996, 1997; Kirsch et al., 2002). The more
controllers understand the systems development process and the more observable the project
manager's steps, the more likely it is that controllers will use behavioural controls (Kirsch, 1996).
Outcome control does not focus on behaviour; rather, the focus is on the accomplishment of a
measurable goal, with reward distribution based upon the degree to which the goal was attained.
Again, to be effective, objectives must have been enumerated and outcomes must be observable
and measurable (Eisenhardt, 1985; Kirsch, 1996, 1997). The more measurable the project
outcomes, the more likely that pre-specified goals exist and that the controllee will be evaluated
on these goals (Kirsch, 1996, 1997; Kirsch et al., 2002). With respect to an ERP implementation,
an incentive can be based upon meeting a go-live date, with some reduction (or elimination) of the
bonus if the go-live date is missed, or missed by more than a specified period (Brown and Vessey,
2000).
Informal control mechanisms are based upon adherence to some type of group or individual
norm. For example, group (clan) control is based upon common values, beliefs, etc. within a
group of individuals who share a set of common goals or are dependent upon each other (Ouchi,
1980). The group is able to disseminate the values, goals and objectives through a process of
socialization and member selection (Boland, 1979; Ouchi, 1979; Orlikowski, 1991). Acceptable
behaviour results from the socialization process. In an ERP implementation environment, the
project team is a readily identifiable group that possesses shared values and beliefs. Also, in an
ERP implementation, task forces (normally led by a project team member and required to
interface with the project team) are often created to accomplish specific tasks (e.g., development
of the chart of accounts). This results in employees of the organisation becoming inculcated with
the goals and objectives of the project team. Group control is implemented when outcomes are not
measurable or appropriate behaviour is unknown (Ouchi, 1979). In situations where behaviours
are observable to clients who have little knowledge of systems development processes, the clients
will implement some form of group control (Kirsch et al., 2002). The alternative informal control
mechanism is self-control, which is a function of an individual's objectives, standards and
intrinsic motivation (Manz et al., 1987; Jaworski, 1988). Individuals define their own goals and
means to accomplish those goals (Kirsch, 1997). Task complexity, ambiguous performance
appraisal, unspecified/ambiguous rules for task completion, individual endowments and desire to
exert self-control are antecedents of self-control (Greenberger and Strasser, 1986; Manz et al.,
1987; Kirsch, 1997). Managers with more knowledge of the systems development process were
more likely to induce more self-control in the project leader (Kirsch, 1996). Further, when
behaviour is not easily observable to the client, or when outcomes are highly measurable, project
leaders will use self-control; that is self-control is akin to the concept of professionalism or
professional pride (Kirsch et al., 2002).
Control theory, as formally developed, predicts that the different control modes will be used in
a singular fashion, i.e., that they are substitutable based on the environment (Ouchi, 1979). In the
domain of systems development, control theory has provided much guidance related to the usage
of controls in complex systems development projects (Kirsch, 1996, 1997; Sambamurthy and
Kirsch, 2000, Kirsch et al., 2002). However, control theory has not been able to adequately
explain why multiple control modes are used. An alternative approach is to view controls from the
perspective of the theory of complementarity, which allows for the integration and interaction of
the various control and organisational modes.
2.2. Complementarity
The economic theory of complementarity provides a basis for understanding how various
elements of organisational strategy, structure, and process are inter-related (Milgrom and Roberts,
1990, 1995). The concept behind complementarity is to provide some substance to the intuitive
notion of “fit” for interpreting the need of having strategy and structure fit one another, just as the
IT structure must fit the corporate strategic plan (the mathematical derivation of complementarity
is provided elsewhere (see Milgrom and Roberts, 1990, 1994, 1995; Milgrom and Shannon,
1994; Topkis, 1998) and not repeated here). Complementarity among sets of practices or parts
implies that the adoption of one practice has externalities for the adoption of other practices
(Athey and Stern, 1998). The importance of the fit of the information system to the organisation
has been addressed by numerous researchers using a variety of methods (e.g., Kanellis et al.,
1999; Iivari, 1992; Raymond et al., 1994). Complementary human resource management
practices have been found to have large effects on productivity, while changes in individual work
practices have had minimal or no impact on productivity (Ichniowski et al., 1997). Evidence of
complementarities between information generated by activity based costing systems and
employee incentives has been reported (Drake et al., 1999).
Managers independently directing different activities select decision variables to maximize
profit, and act on the assumption that the other choice variables are fixed at their present levels.
The result is a systematic under-response to environmental changes relative to their outcomes had
they coordinated their choices (Milgrom and Roberts, 1995). This has implications for
organisations that seek to move to new software applications, where a coordinated move should
result in higher gains than a series of uncoordinated moves. In addition, returns to scale is a source
of strategic complementarity such as reflecting returns to scale in matching processes and shared
technologies (Milgrom and Roberts, 1995). For example, complementarities exist between the
flexibility of production equipment and the breadth of the production line (Milgrom and Roberts,
1995). If an organisation adopts a strategy that is not consistent with its complementary
relationships, it would likely suffer a reduction in profitability. This is similar to an organisation
which does not have its information technology aligned with its strategic objectives.
Organisations that do not have their information systems aligned with their strategic objectives
are less successful than organisations that have aligned their information technology and strategy
(Davenport, 2000).
In order to attain a superior organisational architecture, firms must recognize complementary

relationships presented among various organisational factors, (e.g., manufacturing system
flexibility, marketing strategy, control systems, the information system; customer and supplier
relationships, etc.). All of these complementary factors need to “fit” with each other to form a
coherent operational system and maximize profitability (Milgrom and Roberts, 1990, 1995).
Given that multiple complementary relationships must be orchestrated to move together, multiple
control activities and control modes will need to be in place in order to ensure that the objectives
are obtained. Contrary to control theory, which traditionally predicted that control modes would
be used in a singular, substitutable fashion (Ouchi, 1979), complementarity predicts that multiple
control modes will be used simultaneously because multiple control activities that can be mapped
into multiple control modes are employed (in fact many control activities can be utilized in
different control modes). Complementarity, not control theory, can explain why multiple control
modes are used in complex systems development projects (Kirsch, 1996, 1997; Sambamurthy and
Kirsch, 2000; Kirsch et al., 2002). We propose, based on the theory of complementarity, that the
success of a given ERP implementation is the result of multiple controls, all of which are
necessary; yet by themselves, none are sufficient for the successful implementation of an ERP
system.
Complementarity has not been used before to analyse the control procedures critical for the
success of an ERP implementation, nor has it been used in the examination of other internal
business controls. Rather, typical audit and control procedures look for compensating (or
substitutable) controls, not for complementary controls (see, for example, Arens et al., 2003). We
next utilize complementarity to develop a framework for identifying how control procedures can
work together to ensure the success of an ERP system implementation. We first review the control
procedures most often utilized in ERP implementations, and then classify these into control types.
3. ERP implementation control procedures
Much research has focused on the identification of risk elements that threaten the success of
information systems projects (Cafasso, 1984; Ives and Olson, 1984; Jiang and Klein, 1999; Jiang
et al., 1996; McFarlan, 1981; Zmud, 1980). Markus and Tanis (2000) propose a process theory of
enterprise system success. They note that a variety of things can go wrong in each phase of
implementing enterprise systems, and that not all errors are immediately detectable and
correctable. Consequently, each subsequent phase inherits these unresolved risks. In order to have
a successful ERP implementation, one must understand the risks and implement the appropriate
associated controls.
A risk that is repeatedly identified in the literature is the lack of alignment between the
organisation strategy, structure, and processes and the chosen ERP application (see, for example,
Davenport, 1998, 2000). Both the business process reengineering literature (Hammer, 1990;
Hammer and Champy, 1993) and the ERP literature suggest that an ERP system alone cannot
improve the company performance unless an organisation restructures its operational processes,
and this is generally accomplished through business process reengineering (Bingi et al., 1999;
Davenport, 1998, 2000).
An ERP implementation project must be a business initiative. Microsoft succeeded in
implementing an ERP system when the project was led by the corporate controller rather than by
the IT group (which had failed in two previous attempts) (Bashein et al., 1997). The requirement
of having the ERP implementation be viewed as a business initiative requires the organisation to
gain strategic clarity (i.e., know the business, how it delivers value, etc.) as well as attain a
constancy of purpose (Davenport, 2000). Failure to do so will result in the cessation of the ERP
project. In fact, the most frequently cited reason for abandonment of ERP projects is the
realization that the system cannot support the business processes (Koch, 1999).
A detailed requirements specification for ERP software selection increases the probability that
the ERP system will meet the organisation's requirements and support the newly redesigned
operational processes. While the detailed planning is occurring, baseline metrics on current
processes can be obtained for the subsequent evaluation of the project's outcomes (Davenport,
2000). System testing prior to system implementation and monitoring of the system after
implementation are critical to ensure that the ERP operates smoothly and is able to provide
adequate support for the organisation's redesigned operational processes (Callaway, 1997;
Davenport, 2000).
Project escalation and loss of control are also major risks in an ERP implementation. Loss of
control can arise in at least two ways: the lack of control over the ERP project team, and the lack
of control over employees once the ERP system is operational. Risks associated with controlling
major projects existed prior to the development and implementation of ERP software, and much
has been written on project escalation (see, for example, Brockner, 1992; Kanodia et al., 1989;
Keil, 1995; Sharp and Salter, 1997; Staw, 1976, 1981; Staw and Ross, 1987). The lack of control
over the project team results from the decentralization of decision-making and subsequent
ineffective ratification of decisions. In order to ensure the co-location of knowledge with decision
rights, it is common for an organisation to form an ERP implementation project team. Decision
rights are then assigned to the team. However, when the project team has complete control over
the ratification of its own decisions, a potential business risk is created, that the project team acts
in their own interests rather than in the best interests of the organisation. The operational ERP
system almost always results in the devolution of responsibility and empowerment of lower level
employees. A lack of adequate controls over this increased responsibility, either within the ERP
system itself or in the processes followed by the organisation, is a potential business risk. A failed
implementation of an ERP system could result from the granting of too much responsibility to
employees that results in uncontrolled spending, orders, shipments, and so forth.
In ERP implementation projects, senior managers are often involved via appointment to a
steering committee (Cameron and Meyer, 1998; Clemons, 1998; Davenport, 2000). A steering
committee enables senior management to directly monitor the project team and control project
escalation. The steering committee can monitor the decisions made by the project team and retain
ratification and approval rights on all significant decisions. This ensures that adequate controls over
the project team's decision-making processes exist (Davenport, 2000; Whitten and Bentley, 1998).
Senior management's direct involvement in the system implementation project also increases the
project's perceived importance within the organisation (Raghunathan and Raghunathan, 1998),
which encourages employees, system users and the IT department to be actively involved in and
support the ERP implementation. Senior management commitment is needed because of the
organisational changes that result from the implementation of the ERP system (Bingi et al., 1999;
Davenport, 2000; Holland and Light, 1999). Through the appointment an executive-level
individual with extensive knowledge of the organisation's operational processes to be the project
sponsor, senior management is better able to monitor the ERP implementation. The project sponsor
is directly accountable for the project (see, for example, Cameron and Meyer, 1998; Clemons,
1998; Davenport, 2000; Whitten and Bentley, 1998) and often is responsible to secure funding
(especially when more funds are needed than originally budgeted).
Internal audit's involvement in the ERP implementation also helps ensure the adequacy of
controls and that all parties are performing the appropriate tasks in a timely manner (Glover et al.,
1999). While often overlooked in the ERP implementation literature, internal audit has extensive
knowledge about an organisation's control environment, business operational process and the
weakness present in the current internal control system (Grabski, 1986). At a minimum, auditors
need to stay informed throughout the system implementation process, which enables internal
audit to be aware of the changes due to the new system and to adjust the audit program
accordingly (Glover et al., 1999). Other research has found that internal auditors also provide
additional control procedures utilized by top management through the tracking of actionable
items that need to be ratified by the steering committee, and by providing monthly reports on
project risk items to the steering committee (Lu, 1999).
In order to retain control over the project, many organisations develop a detailed system
implementation plan that provides direction for the project team by setting out the project goals
and targets (Davenport, 2000; Deutsch, 1998). The detailed system implementation plan (which
includes performance metrics for subsequent evaluation) assists in the identification of potential
risks resulting from identified delays in a timely manner (Bingi et al., 1999; Deutsch, 1998;
Holland and Light, 1999). The detailed requirements specification forces the organisation to
identify, in advance, the project specifics and understand the level of complexity associated with
the project. Project management is crucial to the success of any large endeavor, and this is
especially so in an ERP implementation that can span years and cost millions of dollars
(Davenport, 2000). The identification of the skills and knowledge of the project team is important,
as is the employment of consultants to provide expertise in areas where team members lack
knowledge (Barki et al., 1993; Cameron and Meyer, 1998; Clemons, 1998). It is critical for the
project team and consultant to be assigned to the project on full time basis to ensure they focus
completely on the project (Deutsch, 1998).
Lack of project team expertise has often been associated with software development risk
(Anderson and Narasumhan, 1979; Barki et al., 1993; Holland and Light, 1999; Jiang and Klein,
1999). An ERP implementation project requires a wide range of skills (i.e., change management,
risk management, business process reengineering) in addition to technical implementation
knowledge (Davenport, 2000; Glover et al., 1999). Organisations often lack change management
skills and business process reengineering (BPR) skills required for an ERP implementation.
Further, an ERP is often based on programming languages and concepts that are most likely new
to existing IT staff (Kay, 1996).
Consultants are thought to be able to use their previous ERP implementation experiences;
consequently, they can act as knowledge providers who lower the knowledge deficiency existing
within organisations (Arens et al., 2003). Consultants are effective in the configuration and
integration aspects of an ERP implementation (Metrejean and Stocks, 2005). An organisation,
however, cannot completely rely on consultants to implement an ERP system, as consultants have
limited specific knowledge of the organisation's detailed operations. Thus, a close working
relationship between consultants and the organisation's project team can lead to a valuable skill
transfer (Bowen, 1998), and control over the consultants. Furthermore, training that is available
through the consultants, vendor or through some third party provides a valuable resource to
develop skills that are lacking in-house. A knowledge transfer framework has also been advocated
for not only keeping, but also leveraging the knowledge that is created during ERP
implementations (Clark, 2000).
When an organisation moves to a complex ERP environment, changes in staff relationships
may occur. Employees may need to create new working relationships, share information among
departments, acquire new skills and assume additional responsibilities (Appleton, 1999). These
changes can lead to resistance, confusion, and fear among users of the new system (Glover et al.,
1999). Unwilling users increase implementation risk (Anderson and Narasumhan, 1979). Staff
turnover and other types of users' resistance create additional business risks associated with an
ERP implementation. The clan norms (controls) that had been in existence are no longer
applicable.
User resistance has been associated with most any type of systems change, and even more so
for ERP projects that are combined with BPR (since the users are worried that their job may, at
worst be eliminated, or at best be changed from their “comfortable” way of doing things).
Workers who are reengineered out of a position and are subsequently redeployed within the
company may enter a grieving process resulting in low productivity (Arnold et al., 2000).
Consequently, organisations often implement some risk management strategies to minimize
users' resistance. The managerial skills of communication and team building are among the most
important skills required for a successful ERP implementation (Appleton, 1999). Users'
involvement in the ERP implementation was also identified as important to gain the users “buy
in” for the project (see, for example, Cameron and Meyer, 1998; Clemons, 1998). Involving users
in the project enables the project team to be aware of users' requirements and address users'
concerns (Best, 1997). In addition to involvement, user training enables users to acquire the
requisite skills to utilize the ERP system. To ensure that users are aware of the impact the ERP
system will have on their responsibilities, many organisations develop formal communication
plans and issue regular reports (Cameron and Meyer, 1998). Finally, when users perceive that top
management really supports a particular project (and is willing to provide adequate resources),
they will have a higher level of project acceptance.
Based on the preceding review of the literature and also on the research by Akkermans and van
Helden (2002), Grabski et al. (2001), and Somers and Nelson (2001), we developed a list of
Table 1
ERP implementation controls
Business process reengineering
Consultants' involvement
Top management support
Active steering committee
Knowledgeable project team
Close working relationship between the project team and consultants
Detailed requirements specification
Detailed implementation plan
Frequent communication with the users
Managing people
User involvement
Training
Involvement of internal audit
System testing prior to implementation
Close monitoring after implementation
Change management and transition management
Develop users' project ownership
In-depth, up front project planning
Project management skills
Project sponsor from top management
Clearly identified objectives
Specified measures of success
Ways to manage risk
Detailed tracking of actionable items by internal audit
Monthly internal audit reports on project risk items to steering committee
control procedures utilized by organisations for an ERP implementation. Table 1 summarizes

these ERP implementation controls. The list is primarily based upon Grabski et al. (2001) since
they focused on control-related items. Their list matches relatively well to the critical success
factors (CSFs) identified by Somers and Nelson (2001) and used by Akkermans and van Helden
(2002). We next classify these controls utilizing control theory into outcome, behaviour, clan and
self-controls, and then predict how these control modes would be used (at most through a
portfolio of control modes (Kirsch, 1997)). Several of these controls are classified into more than
one control mode because of the differential manner in which they can be used.
3.1. Relationship among ERP control activities and control modes
Business process reengineering is an outcome control, a behaviour control and a clan control.
Prior to undertaking a reengineering project, an organisation should determine what its
reengineered processes and structure will look like. This change provides the outcome control to
compare the planned to the actual reengineered processes. Reengineering can also be a
behavioural control. Project managers can be, and are evaluated based upon the known and
observable behaviours. Further, individuals who are required to adapt to new processes can be
evaluated based upon their behaviour and compliance to the new procedures. Business process
reengineering can also be a clan control. The project team has a set of shared values and the team
members are dependent upon each other for the accomplishment of the reengineering project.
The use of consultants can be both outcome and clan controls. Consultants are often hired to
accomplish a particular task. Whether the task is successfully accomplished can often be
objectively determined, and hence is an outcome control. From the perspective of clan controls,
the consultants are often dependent upon each other; however, they possess skills and quite often
an approach to problem solving that is lacking in the organisation, or specific technical skills
needed to implement the ERP software. The clan control is the dissemination of the values, goals
and objectives from the consultants to the individuals within the organisation with whom they
have a close working relationship, and from these individuals to others in the organisation.
Top management support and a project sponsor from top management are informal controls
designed to empower the project team and others involved in an ERP implementation. It can
result in self control since behaviour may not be readily observable, there is significant task
complexity, and there are unspecified or ambiguous rules for task completion (antecedents for self
control). Since top management support empowers the project team, clan control can also result.
On the other hand, an active steering committee can result in formal control. The steering
committee can hold the project manager and project team accountable for the completion of
explicit tasks at specific times and review whether this has occurred. In addition to outcome
control, behavioural control can be exerted. An active steering committee results in more
observations of the behaviour of the project manager, and the more control that the steering
committee has over the project manager.
Project management skills can result in behaviour, outcome, clan and self-control. A project
manager is able to break down a complex project into small manageable parts and associated
deliverables against which team members can be evaluated. Further, the project manager will be
able to observe the behaviours that are practiced and result in behavioural control. The project
manager is also the team leader and is responsible for the development of the “team spirit.” As
such, this results in the clan controls that are employed by the project team during the ERP
implementation. Finally, the project manager is able to empower individuals to accomplish their
tasks, which at times may be ambiguous. This, along with the knowledge possessed by the project
manager could result in self-control by team members. Finally, a project manager can develop
individual team members' skills in such a fashion that the result is the development of self-control
within those team members.
A knowledgeable project team will definitely result in clan control, as should the close
working relationship between the project team and the consultants. A knowledgeable project team
can also result in outcome and behaviour control. Further, it should result in self-control by the
project manager. Clan control results from the shared values and dependency of the group upon
each group member (i.e., “us” versus the ERP project). Outcome control can result from the
project team exerting control over individual task forces that need to be mobilized for specific
tasks, such as the creation and verification of bills of material for product families. Self-control for
the project manager is likely to be induced by managers who are knowledgeable (Kirsch et al.,
2002). Clan control can impact the consultants as they adapt to the norms of the organisation. In a
reflexive manner, the values, goals and objectives of the consultants will impact the project team.
Self-control may also result in project team members working in close relationships with the
consultants due to the belief that the consultants are knowledgeable, similar to the impact of the
project team on the project manager.
The generation of clearly identified objectives, specified measures of success, detailed
requirements specification, in-depth, up front planning, and a detailed implementation plan all
result in outcome control. The objectives for the ERP project provide the overall guidance for the
up front planning that results in the future vision for the organisation, and the steps needed to
accomplish the ERP implementation. This should also result in specified measures of success that
can be used to evaluate the outcome of the ERP implementation. The requirements provide the
checklist as to what needs to be accomplished and what needs to be embodied in the ERP software
itself, and the implementation plan provides the actual steps to be performed. The project team
and project manager can be evaluated against these outcomes.
Frequent communication with users, user involvement, managing people, developing users'
project ownership, change and transition management, and training all could result in behavioural
and clan controls. The communication, managing and training all could set up expectations upon
which the users will be evaluated. Further, all result in some type of inculcation of the users into a
new way of doing something and the development of project ownership. The change and
transition management helps to develop the group norms. The users are all going through a
change process together and are all adapting to the new group's norms. As the users acquire
ownership, they develop their set of clan controls as to the proper use of the ERP system.
The involvement of internal audit, detailed tracking of actionable items by internal audit and
monthly reports by internal audit on project risk items to the steering committee can result in both
outcome and behavioural controls. Depending upon how internal audit reviews the ERP
implementation, outcome controls result when comparing what has been accomplished relative to
a plan or relative to a prior audit. This is also the case with the tracking of actionable items and
risky items. Behavioural controls can also exist since the internal auditors can observe the
behaviour and can report on whether the appropriate actions have been taken, especially on risky
and actionable items.
Different ways to manage risk in an ERP implementation can result in outcome, behaviour, clan
or self-control. The control used will be dependent upon the risk management approach employed.
For example, time boxing is a risk management technique for controlling the length of time a given
task should take. It results in an outcome control of whether or not the task was completed in the
allotted time period. Clan control can result from the project team all striving for completion of the
project at a specified date, and all within the clan will do whatever it takes to achieve this goal,
resulting in the reduction in risk of a “runaway” project. Behaviour control can result from risk
management techniques that focus on appropriate behaviours, such as ensuring that team members
communicate with users, reducing the risk that the ERP system will not meet the users' needs. Self-
control can result from professionalism instilled in individual project team members and their own
innate need to succeed and complete a large, complex project in a timely manner.
System testing prior to implementation and close monitoring after implementation are both
outcome controls. The testing provides evidence as to what should happen when the ERP system
is in use and this is then compared to the planned outcomes, whether they relate to accuracy,
timeliness, or any other metric. The same is true for post-implementation monitoring; it results in
a comparison of actual to planned outcomes.
3.2. Hypothesis
Many ERP implementation control activities can be used as both outcome and behavioural
control modes. Further, only the combined effect of all the controls used is observable, rather than
a single implementation control or control mode from control theory. Since we cannot a priori
classify the controls into overarching “ERP implementation control factors” as there is no
established theory of “ERP implementation controls,” we take an exploratory perspective and use
factor analysis to extract the overarching control factors. We do not expect that the extracted
factors will neatly align into the four control modes as the individual controls can be associated
with different control modes, and depending upon how the control is used, it may be a clan control
in one organisation and an output control in another. Following Milgrom and Roberts (1990,
1994, 1995), we argue that the complementary relationships between the extracted, overarching
control factors are all part of a supermodular function. While supermodularity does not require a
compensatory model (i.e., all factors must be present for success), we argue that based on the
reviewed literature, all factors are required. That is, we expect that these control factors (and
therefore all four control modes) are all necessary but that none are sufficient by themselves. This
leads to the following hypothesis:
H.The extracted control factors will interact in such a manner that the marginal benefit of any
factor in attaining a successful ERP implementation is a function of all the other control factors.
4. Research method
4.1. Respondents
Chief Information Officers (CIOs) and Internal Auditors were selected to be the participants in
this study. These respondents were chosen because of the types of responsibilities that they are
charged with during ERP implementations. Also, asking the same questions of two respondent
groups who have different responsibilities should provide some triangulation on the actual results
obtained. CIOs were selected to participate because they are specifically tasked with the
responsibility for the information system of the organisations and should be able to assess the
success of the implemented system. They should also be able to reflect the opinion of top
management since they are a member of the top management in organisations.
Internal Auditors were selected because they should be able to provide an objective perception
as to whether the system was a success compared to top management and other users. Due to
internal pressure, top management may perceive a project to be a success because they initially
supported or proposed the project. If the project were to fail or be perceived as less than
successful, the board of directors might remove them. Further, if an individual is very closely
associated with a project, they are sometimes less likely to observe or identify shortcomings.
Internal auditors are often required to provide critical performance evaluations and project review
to top management and users.
4.2. Instrument
A questionnaire was created and distributed to the participants. It was broadly based on a
questionnaire developed by the Institute of Internal Auditors — United States. The questionnaire
was specifically expanded and significantly modified to include the controls identified as
important in the literature (see control procedures discussion above), and it also included questions
specific to internal audit activities during the implementation phase. The questionnaire was pilot
tested with three experts in auditing (a partner, director and manager from major accounting firms)
and three expert consultants with ERP system implementation experience. The questionnaire was
revised as a result of the pilot tests before being sent to the internal auditors. Prior to distributing the
questionnaire to the CIOs, the internal audit task specific items were eliminated.
4.3. Survey administration
The Institute of Internal Auditors — Australia (IIA-A) provided a list of internal auditors by
title and organisation. Since ERP implementations are more likely to be associated with medium
to large firms, an organisation was included in the sample if it had at least two members of the IIA-
A. This yielded 211 organisations. The questionnaire, a letter from the National President of the
IIA-A, an Information Sheet explaining the reason for the survey and a reply postage-paid
envelope were mailed out to the highest positioned internal auditor in that organisation (that is,
only one survey was mailed out to a given firm). The IIA-A would not disclose member names;
consequently, the IIA-A conducted the mail out. A follow-up letter from the National President
was sent one month after the first mail out, again with the IIA-A conducting the actual mail out. A
third follow-up was made in which the complete instrument was again mailed to all potential
respondents by the IIA-A. From this survey, a total of 76 responses were received (36% response
rate), of which 36 had implemented (or were in the process of implementing) an ERP package
(respondents who had not implemented an ERP package were not included in any further
analysis). This response rate is comparable to other mail surveys (Raho et al., 1987; Yap, 1990).
Due to missing data, a total of 29 useable responses were obtained. To address situations where
the internal audit function in an organisation is outsourced to a public accounting firm, the
national partners in charge of the major international accounting firms were contacted, and
agreed, where possible, to have the questionnaire completed by the partner/manager in charge of
the outsourced internal audit function. After several follow-up telephone calls, 8 responses were
received from two of the firms, of which 6 were complete. These six were added to the responses
received from the IIA-A survey, making a total of 35 usable responses. There were no significant
differences ( p b .05) in the responses from the outsourced internal auditors and the in-house
internal auditors.
The CIO questionnaire was sent out to CIOs of the same 211 firms in the internal auditor
survey. From this survey, a total of 58 responses were received (27% response rate), of which 33
had implemented (or were in the process of implementing) an ERP package (consistent with the
17% response rate reported by Bernroider and Koch (2001) for ERP selection process research).
There was no difference in firm characteristics between the CIO and internal auditor responses
for either total assets (t = 1.14, 66 df, p b .256) or in the number of employees (t = .54, 66 df,
p b .589). Further, there was no difference between early and late respondents for the CIOs for
either total assets (t = 1.01, 22 df, p b .324) or number of employees (t = .39, 31 df, p b .695). Nor
was there any difference between the early and late respondents for the internal auditor for either
total assets (t = − 1.16, 26 df, p b .257) or number of employees (t = − .68, 38 df, p b .500). In all,
the largest firm had sales of $40 billion (all dollar amounts are in Australian dollars) and the
smallest had sales of $700,000. The average (median) sales were $2.77 billion ($800 million).
Given that there were no differences between the organisational characteristics and receipt of
questionnaires, the data from all respondents was pooled for all subsequent analyses. Ideally, a
matched-pair comparison between CIOs and internal auditors research design would be
employed, however, this was not feasible due to the confidentiality restrictions imposed upon the
researchers by the IIA-A during the data collection process.
4.4. Data analysis and results
The respondents were presented the list of controls contained in Table 1. For each control, the
respondent indicated the level of its presence in their organisation during the ERP implementation
on a seven-point Likert scale anchored at 1 (no presence) and 7 (significant presence). In the
questionnaire, the term New Information System (“NIS”) was used rather than ERP system. This
was done to ensure that the respondents were thinking about the new system that was
implemented and to avoid any positive (negative) connotation associated with ERP by the
respondents. NIS was defined in the questionnaire as referring to “the new information system
that has just been/is in the process of being installed. Common NIS vendors include (but are not
limited to) SAP, BAAN, Oracle, QAD in larger organizations and Platinum, Banner, Prophesy,
CFACS in smaller organizations.” Respondents specified the software implemented and all were
identified as ERP packages.
To obtain information on whether the respondents believed that their organisation's ERP
implementation was a success, they were asked, “Do you believe your organisations' NIS project
was a success?” with the anchors of very unsuccessful (1) and very successful (7). Additionally,
they were asked, “In your opinion, how has the implementation of the new NIS affected your
organisation?” with the anchors of very negative (1) and very positive (7). Finally, they were
asked, “Do you believe that the business processes of the organisation are aligned with (or fit) the
NIS?” with the anchors of (1) very poor fit and (7) very good fit. The descriptive statistics for
these responses appears in Table 2. There was no significant difference in the responses obtained
from the CIOs and internal auditors. The second question (affect on the organisation) is not
exactly the same as asking whether the ERP implementation was a success since organisational
Table 2
Descriptive statistics for dependent variable responses
Internal audit mean (SD) CIO mean (SD) t-test Sig.
Believe the project was a success 4.821 (1.221) 5.103 (1.145) .283
Implementation of the NIS affect on the organisation 4.342 (1.214) 4.700 (1.208) .231
Believe that the business processes of the organisation 4.643 (1.243) 4.562 (1.076) .291
are aligned with (or fit) the NIS
Scale anchored at 1 = very unsuccessful/negative/poor fit and 7 = very successful/positive/good fit.
Table 3
Rotated extracted principal components
Component
1 2 3 4 5
Business process reengineering .086 .140 .643 .247 − .104
Consultants involvement .015 .006 −.264 .164 .841
Top management support .850 .183 −.062 .141 − .018
Active steering committee .553 .205 .266 .498 .159
Knowledgeable project team .580 −.141 .450 .194 .365
Close working relationship between project team and consultants .042 .197 .207 .185 .786
Detailed requirements specification .545 .006 .398 .169 .467
Detailed implementation plan .453 .340 .421 .102 .394
Frequent communication with users .288 .815 .029 .170 .253
Managing people .230 .790 .216 .175 .170
User involvement .067 .802 .213 .259 .078
Training .054 .731 .401 .299 .110
Involvement of internal audit − .018 .140 .284 .847 .206
System testing prior to implementation − .149 .269 .585 .383 .341
Close monitoring after implementation − .041 .386 .598 .324 .205
Change management and transition management .278 .466 .547 .229 .179
Develop users' project ownership .484 .536 .284 .269 .190
In-depth project planning .515 .387 .338 .146 .400
Project management skills .604 .421 .383 .122 .286
Project sponsor from top management .764 .284 .047 .281 .185
Clearly identified objectives .574 .193 .359 −.042 .476
Specified measures of success .404 .251 .537 .069 .434
Ways to manage risk .449 .320 .459 .295 .287
Internal audit tracks actionable items .191 .114 .211 .778 .102
Monthly internal audit reports .161 .211 .022 .859 .127
Percentage variance explained 17.30 16.60 13.96 13.31 12.20
Cumulative percentage of explained variance 17.30 33.90 47.86 61.17 73.37
Eigenvalues 11.68 2.26 1.68 1.46 1.26
Extraction method: Principal component analysis. Rotation method: Equamax with Kaiser normalization.
Rotation converged in 28 iterations.
impacts or affects of an information system can be much broader than simply asking about
success. A respondent could believe that the implementation was a success, but that the turmoil
engendered during the implementation had a negative affect on the organisation. We include this
question since it does provide another perspective of ERP implementation success. Finally, if an
organisation's business processes are not supported by the ERP system (or vice versa),
considerable disruption will exist and users will find it difficult to obtain the needed information
in an efficient and economical manner. This will result in frustration and a resultant dislike and
perceived failure for the ERP system. Again, this question is expected to provide another
dimension of ERP system success. Note that this question is not the same as asking whether
business process reengineering has occurred. Rather this question is an output measure of the
correspondence between the business processes and the ERP system.
Data analysis followed a two-step process. First, a factor analysis of all the control items was
performed, as well as a factor analysis of the three dependent variable questions related to the
success of the ERP system implementation. The extracted independent factors were regressed on
the extracted dependent variable. The factor analysis is described next, followed by the regression
analysis.
4.5. Factor analysis — independent variables
The questionnaire control items were factor analysed using principal component analysis with
Equamax rotation and Kaiser normalization. With Equamax rotation, the number of variables that
load highly on a factor and the number of factors needed to explain the variable are optimised,
rather than having the eigenvectors remain orthogonal as they are rotated while obtaining the
maximum sum possible of the variances of the loadings. The results of the factor analysis appear
in Table 3. Control items with a loading of .400 or greater are in bold and are considered to load on
Table 4
Moderated factor regression analysis-ERP success extracted factor
R square Adjusted R square N
Model .775 .542 62
Model Y = a + b1x1 + b2x2 + b3x3 + b4x4 + b5x5 + b6x1x2 + b7x1x3 + b8x1x4 + b9x1x5 + b10x2x3 + b11x2x4 + b12x2x5
+ b13x3x4 + b14x3x5 + b15x4x5 + b16x1x2x3 + b17x1x2x4 + b18x1x2x5 + b19x1x3x4 + b20x1x3x5 + b21x1x4x5
+ b22x2x3x4 + b23x2x3x5 + b24x2x4x5 + b25x3x4x5 + b26x1x2x3x4 + b27x1x2x3x5 + b28x1x2x4x5 + b29x1x3x4x5
+ b30x2x3x4x5 + b31x1x2x3x4x5
Parameter β Std. Error t Sig.

Intercept .008 .131 .571 .572
Factor 1 .503 .172 2.931 .006
Factor 2 .471 3188 2.505 .018
Factor 3 .206 .186 1.104 .279
Factor 4 − .002 .191 − .085 .933
Factor 5 .001 .163 .002 .999
Factor 1 ⁎ Factor 2 .127 .209 .611 .546
Factor 1 ⁎ Factor 3 .260 .280 .929 .361
Factor 1 ⁎ Factor 4 .357 .298 1.201 .239
Factor 1 ⁎ Factor 5 − .382 .234 − 1.631 .113
Factor 2 ⁎ Factor 3 − .199 .209 − .956 .347
Factor 2 ⁎ Factor 4 .106 .272 .390 .699
Factor 2 ⁎ Factor 5 − .235 .301 − .780 .441
Factor 3 ⁎ Factor 4 − .283 .276 − 1.026 .313
Factor 3 ⁎ Factor 5 .102 .364 .280 .781
Factor 4 ⁎ Factor 5 .407 .209 1.945 .061
Factor 1 ⁎ Factor 2 ⁎ Factor 3 − .144 .340 − .423 .675
Factor 1 ⁎ Factor 2 ⁎ Factor 4 .806 .431 1.871 .071
Factor 1 ⁎ Factor 3 ⁎ Factor 4 .199 .376 .528 .601
Factor 1 ⁎ Factor 4 ⁎ Factor 5 − .696 .552 − 1.261 .217
Factor 2 ⁎ Factor 3 ⁎ Factor 4 .601 .477 1.260 .217
Factor 3 ⁎ Factor 4 ⁎ Factor 5 .218 .553 .395 .696
Factor 1 ⁎ Factor 2 ⁎ Factor 3 ⁎ Factor 4 −1.590 .799 − 1.990 .056
Factor 1 ⁎ Factor 2 ⁎ Factor 3 ⁎ Factor 5 .710 .365 1.945 .061
Factor 1 ⁎ Factor 2 ⁎ Factor 4 ⁎ Factor 5 − .436 .413 − 1.057 .299
Factor 1 ⁎ Factor 3 ⁎ Factor 4 ⁎ Factor 5 − .205 .483 − .424 .675
Factor 2 ⁎ Factor 3 ⁎ Factor 4 ⁎ Factor 5 − .867 .798 − 1.086 .286
Factor 1 ⁎ Factor 2 ⁎ Factor 3 ⁎ Factor 4 ⁎ Factor 5 1.906 .902 2.113 .043
that factor. Five factors were extracted that had eigenvalues greater than 1.000. The total variance
explained is 73.36%.
4.6. Factor analysis — dependent variables
The three measures of the dependent variable of ERP implementation success (Table 2) were
also factor analysed using principal component analysis. A single factor was extracted
(eigenvalue of 1.958, 65.257% of the variance explained). All items had loadings exceeding .768
(the loadings were Affect .866, Success .786, and Fit .768). This extracted factor is used as the
dependent variable in the subsequent regression analysis.
4.7. Regression analysis
A regression analysis was performed utilizing the five factors extracted from the 25
independent variables as the independent variables, and the one factor extracted from the three
dependent variables as the dependent variable. The regression, utilizing the five extracted factors
and interaction terms (Table 4) resulted in an adjusted R squared of .542. As predicted, a
significant five-way interaction ( p = .043) was found. As prescribed by Cohen and Cohen (1983)
and Hartmann and Moers (1999) all simple effects and lower level interactions are included even
though they are not directly interpretable. This means that the five-way interaction is significant
after partialing out all simple effects and all other lower order interactions. The four-way
interactions are also not interpretable since an interval (not ratio) scale was used, and the variables
are not centered on their respective means.
A five-way interaction means that a four-way interaction is a function of a fifth variable
(Hartmann and Moers, 1999). Said another way, the interaction effect of the four extracted factors
is a function of the fifth factor. Further, because of symmetry, the five-way interaction also
simultaneously expresses the moderating effect of each variable on the interaction effect of the
other four variables on ERP implementation success (Hartmann and Moers, 1999). We are not
suggesting that the five-way interaction be interpreted or explained. Rather, the interaction is
evidence of the complementarities among the five factors of the model. It should also be noted
that the beta value for the five-way interaction term is larger than any other term. The observed
power of the five-way interaction term is .534, indicating a moderate effect. Given the limited
sample size (N = 62) and the relatively large number of parameters estimated that were partialed
out prior to estimating the five-way interaction, its effect seems to be pervasive. The five-way
interaction means that the success of the ERP implementation depends on the levels of all five
variables taken together, and since there is a multi-factor interaction single factors should not be
interpreted (Neter and Wasserman, 1974).
5. Discussion
Results of this research support the hypothesis. All the controls loaded onto factors, and a
significant 5-way interaction involving all extracted factors was found. This provides support
for a theory of control complementarity as applied to ERP (and other complex systems)
implementation projects. A single type of control is not used; rather multiple controls are used
and are used for multiple purposes. As evidenced by the factor loadings, twelve of the twenty-
five controls loaded on two or more factors, indicating multiple uses for those individual
controls.
The first extracted factor consists of controls related to project management. The controls
included top management support, an active steering committee, a knowledgeable project team,
detailed requirements specification, a detailed implementation plan, development of users'
project ownership, in-depth advanced planning, project management skills, project sponsor from
top management, clearly identified objectives, specified measures of success and ways to manage
risk. While each of the controls relates to project management, they would be classified
differently by control theory. Specified measures of success are most certainly outcome measures,
whereas development of users' project ownership and knowledgeable project team can be either
behavioural or clan controls. Finally, development of users' project ownership could be classified
as behavioural or self-control.
The second extracted factor consists of controls related to change management. The controls
included with this factor are frequent communication with users, managing people, user
involvement, training, change management and transition management, development of users'
project ownership, and project management skills. It is apparent that all controls are related to the
management of change in the organisation. Control theory would classify these as either
behavioural, clan, or self-controls. There are no apparent outcome controls present in this factor.
The third factor extracted seems to relate to the alignment of the business with the new system.
The controls associated with this factor include business process reengineering, knowledgeable
project team, detailed implementation plan, training, systems testing prior to implementation,
close monitoring after implementation, change management and transition management,
specified measures of success, and ways to manage risk. These controls could again be classified
by control theory as outcome (e.g., specified measures of success), behavioural (e.g., change and
transition management, training, and knowledgeable project team), clan (e.g., knowledgeable
project team), and self-control (e.g., training).
The fourth extracted factor seems to relate to internal audit activities. The controls included
with this factor are active steering committee, involvement of internal audit, internal audit
tracking of actionable items, and monthly internal audit reports. It makes sense to have the active
steering committee control associated with these internal audit activities since the internal auditor
normally reports to the steering committee. These controls could be classified by control theory as
both outcome (e.g., tracking of actionable items, monthly reports) and behavioural controls (e.g.,
internal audit can observe whether the appropriate actions have been taken).
The last extracted factor seems to relate to consultant and planning activities. The controls
associated with this factor are consultants' involvement, close working relationship between
project team and consultants, detailed requirements specification, in-depth project planning,
clearly identified objectives, and specified measures of success. Consultants are very often called
in during the planning stages of an ERP implementation and as such, the requirements
specification, objective identification, planning and success measure development all occur
during the early stages. From a control theory perspective, at least outcome (e.g., specified
measures of success) and clan (e.g., close working relationship between project team and
consultants) controls can be identified.
Based on the extracted factors, a model of the critical factors for ERP implementation success
can be developed and is presented in Fig. 1. All five factors are necessary, but none are sufficient
for the successful implementation (if they were sufficient, a 5-way interaction would not have
been found). The arrows between the individual control factors highlight their interactions, and it
is the interactions that are important, not the main effects.
The regression of the factors on the perceived success of the new information system resulted
in supporting the hypothesis of complementarity; the predicted high order interaction was
Fig. 1. Model of control factors critical for ERP implementation success.
found. This interaction provides support for the complementary nature of these factors.
Essentially, the impact of one factor on the success of the ERP implementation depends on or is
moderated by the levels of the other factors. In this research, all organisations appeared to have
reached a minimum level of use of the factors, and as result, the model appears compensatory. It
is not known, based on the data obtained, when this model changes (or if it changes) from
compensatory to non-compensatory. That is, if certain items are not done, it will not matter if
everything else is done perfectly; the missing items are a “fatal flaw” that cannot be overcome.
In a similar manner, the data do not allow the identification of trade-offs that would indicate to
management how to best spend marginal dollars to obtain the highest likelihood of ERP
implementation success.
This research provides an additional explanation of the use of controls, and sheds new light on
a troublesome issue based on control theory. Rather than the use of a single type of control
(behavioural, outcome, clan, and self ), this research examined a number of control activities that
apply to all control modes. For example, an active steering committee can be associated with
behavioural control, specified measures of success is most often identified with outcome controls,
a close working relationship between the project team and consultants is a type of clan control,
and a knowledgeable project team (and team leader) will induce greater levels of self-control. At
the same time, it is apparent that the controls are being used for a variety of purposes based on the
factor loadings. For example, specified measures of success loaded onto three of the five extracted
factors. The use of complementarity provides an alternative explanation to control theory in the
manner and combination and use of individual control items.
6. Concluding thoughts
Several limitations should be noted. The usual caveats related to empirical research and the
associated data analysis apply. The respondents are only those who chose to participate. A
survivorship bias may exist, that is only organisations that implemented an ERP system and
survived the implementation were included in the sample. The selection process also eliminated
small firms from consideration. While we would have liked to match responses from CIOs and
Internal Auditors from the same organisation, the restrictions imposed by the IIA-A precluded
this. All data was collected via a mailed-out questionnaire, so common method bias may exist.
Finally, while the sample size is relatively small, the response rates are consistent with prior
research and the results obtained are consistent with the theory developed.
Additionally, the limitations that are associated with perceptions of success and affect on the
organisation (that might not reflect reality) apply to this research. However, two respondent
groups, CIOs and internal auditors participated. Consequently, they should provide different
insights. Furthermore, internal auditors are trained to be skeptical, and they do not have a vested
interest in the project, nor are they afraid to tell management that a particular project is not as
successful as management would have desired. We believe that the perceptions of success,
affect, and fit (versus objective measures of success) are less of a limitation associated with this
study than with studies that use a single respondent group or a single measure of perceived
success.
Much research on ERP implementation success has focused on individual case studies,
proposal of theories, or examinations of selection processes. This research applies economic
theory and examines implementation controls and subsequent perceived success of ERP systems.
Two respondent groups, CIOs and internal auditors were chosen because of their diverse roles in
ERP implementation. Based on the responses obtained from those groups, this research provides
support for the theory of complementarity applied to ERP system implementations. Five factors
were identified and were then found significant in a five-way interaction on perceived ERP
system success and its affect on the organisation.
This research sheds new light on the use of controls. Rather than expecting a single control
mode to be used, a set of control activities is used, and the same control activity is often used for
different purposes. This is somewhat different than the idea of portfolios of controls (Kirsch,
1997), and helps explain some of the inconsistencies that have plagued researchers trying to
apply control theory to a complex task like the implementation of an ERP system. This research
demonstrated that managers must control all of the five factors if they desire to have a
successful ERP implementation. The good news is that these five factors result from a number
of control procedures, many which apply to several factors. Consequently, managers now know
what controls apply to the factors and where they may need to place increased emphasis in the
future.
Future research can examine whether the control factors identified here are also applicable to
the implementation of other large systems such as Customer Relationship Management (CRM)
systems. It seems as if many of the same issues of control and user acceptance exist. Future
research is also needed to determine which controls are relatively more important in given
situations. The current research has identified that all the factors are important, but it does not
specify the relative mix in a given setting. The discovery of when the controls and factors become
(non) compensatory will be very helpful. At this point we now know that all factors are critical
and necessary for a successful implementation.
Acknowledgements
We wish to thank Harrison McKnight, Brian Pentland, V. Sambamurthy, and Cheri Speier for
their insightful comments on earlier versions of this draft. We would also like to thank the
participants at the research seminar programs at Texas Tech University, The University of
Melbourne, University of Tasmania, Australian National University, University of Sydney,

Murdoch University, University of Adelaide, University of Newcastle, University of Connecticut,
The Open University Business School, Milton Keynes, England, The University of Birmingham,
Birmingham, England, The 3rd International Conference on Enterprise Systems and Accounting,
Santorini, Greece, European Accounting Association, Goteborg, Sweden and Universidad
Autonoma de Madrid, Madrid, Spain.
References
Akkermans H, van Helden K. Vicious and virtuous cycles in ERP implementation: a case study of interrelations between
success factors. Eur J Inf Syst 2002;11(1):35–46.
Anderson J, Narasumhan R. Assessing implementation risk: a technological approach. Manage Sci 1979;25(6):512–21.
Arens AA, Elder RJ, Beasley MS. Auditing and assurance services: an integrated approach. 9th edition. Upper Saddle
River, NJ: Prentice-Hall; 2003.
Arnold V, Hunton JE, Sutton SG. On the death and dying of originality in the workplace: a critical view of enterprise
resource planning systems' impact on workers and the work environment. Working Paper. University of South Florida;
2000.
Appleton E. How to survive ERP. Datamation; 1999. March.
Athey S, Stern S. An empirical framework for testing theories about complementarity in organizational design. Working
Paper, vol. 6600. National Bureau of Economic Research; 1998. June.
Bagchi S, Kanungo S, Dasgupta S. Modeling use of enterprise resource planning systems: a path analytic study. Eur J Inf
Syst 2003;12(2):142−1x.
Barki H, Rivard S, Talbot J. Toward an assessment of software development risk. J Manage Inf Syst 1993;2(10):203–25.
Bashein BJ, Markus ML, Finley JB. Safety nets: secrets of effective information technology controls. Morristown, NJ:
Financial Executives Research Foundation, Inc.; 1997.
Beath CM, Orlikowski WJ. The contradictory structure of systems development methodologies: distracting the IS-user
relationship in information engineering. Inf Syst Res 1994;5(4):350–77.
Best C. Integrated system builds on human foundation. Comput Can 1997;23.
Bernroider E, Koch S. ERP selection process in midsize and large organizations. Bus Process Manag J 2001;7(3):251–7.
Bingi P, Sharma MK, Godla J. Critical issues affecting an ERP implementation. Inf Syst Manage 1999;16(3):7–14.
Boland Jr RJ. Control, causality and information systems requirements. Account Organ Soc 1979;4(4):259–72.
Bowen TS. Committing to consultants: outside help requires internal commitment and management skills. Info World
1998;20(50):61, 64 [December 14, 1998].
Brockner J. The escalation of commitment towards a failing course of action: towards theoretical progress. Acad Manage
Rev 1992;1(17):39–61.
Brown CV, Vessey I. NIBCO'S “BIG BANG”: a teaching case. Indiana University; 2000.
Cafasso R. How to control risk and effectively reduce the chance of failure. Manag Rev 1984;73(6):50–4.
Callaway E. ERP: test for success. PC Week 1997;14(53):69 [2 pp.] [December 22/29, 1997].
Cameron DP, Meyer LS. Rapid ERP implementation — a contradiction. Manage Account (USA) 1998;80.
Clark LE. A stitch in time: creating a knowledge transfer framework for your ERP implementation can mean the difference
between losing and leveraging your most valuable asset. Intell Enterp 2000;3 [October 20; http://www.
intelligententerprise.com/001020/feat3.shtml].
Clemons C. Successful implementation of an enterprise system: a case study. Proceedings of the AIS Conference
Americans, Baltmore Maryland; 1998. p. 109–10.
Cohen J, Cohen P. Applied multiple regression/correlational analysis for the behavioral sciences. Hilldale: Erlbaum; 1983.
Davenport TH. Putting the enterprise into the enterprise system. Harvard Bus Rev 1998;76(4):121–33 [July/August].
Davenport TH. Mission critical: realizing the promise of enterprise systems. Boston, MA: Harvard Business School Press;
2000.
Deutsch CH. Software that can make a grown company cry. N Y Times 1998 [November 8].
Drake AR, Haka SF, Ravenscroft SP. Cost system and incentive structure effects on innovation, efficiency and profitability
in teams. Account Rev 1999;74(3):323–45.
Eisenhardt KM. Control: organizational and economic approaches. Manage Sci 1985;31(2):134–49.
Eisenhardt KM. Agency theory: an assessment and review. Acad Manage Rev 1989;14(1):57–74.
Glover SM, Prawitt DF, Romney MB. Implementing ERP. Intern Aud 1999:40–7 [February].
Grabski SV. Auditor participation in accounting systems design: past involvement and future challenges. J Inf Syst 1986;1
(1):3–23.
Grabski SV, Leech SA, Lu B. Risks and controls in the implementation of ERP systems. Int J Digit Account Res
2001;1(1):51–78 [January–June].
Greenberger DB, Strasser S. Development and application of a model of personal control in organizations. Acad Manage
Rev 1986;13,2:287–301.
Hammer M. Reengineering work: don't automate, obliterate. Harvard Bus Rev 1990:104–12 [July–August].
Hammer M, Champy J. Reengineering the corporation: a manifesto for business revolution. New York: Harper Business;
1993.
Hartmann FGH, Moers F. Testing contingency hypotheses in budgetary research: an evaluation of the use of moderated
regression analysis. Account Organ Soc 1999;24:291–315.
Henderson JC, Lee S. Managing I/S teams: a control theories perspective. Manage Sci 1992;38,6:757–77.
Holland C, Light B. A critical success factors model for ERP implementation. IEEE Softw 1999;16(3):30–6.
Holland CP, Light B. A stage maturity model for enterprise resource planning systems use. Data Base Adv Inf Syst
2001;32:34–45 [Spring].
Hong K-K, Kim Y-G. The critical success factors for ERP implementation: an organizational fit perspective. Inf Manage
2002;41(1):25–34.
Hyde W. Technology (A special report): working together — when things go wrong: FoxMeyer Drug took a huge high-
tech gamble; it didn't work. Wall Street J in press [November 18].
Ichniowski C, Shaw K, Prennushi G. The effects of human resource management practices on productivity: a study of steel
finishing lines. Am Econ Rev 1997;87(3):291–313.
Iivari J. The organizational fit of information systems. J Inf Syst 1992;2(3):3–29.
Ives B, Olson M. User involvement and MIS success: a review of research. Manage Sci 1984;30(5):19–29.
James D, Wolf ML. A second wind for ERP. McKinsey Q. 2000;2:100–7.
Jaworski BJ. Toward a theory of marketing control: environmental context, control type, and consequences. J Mark
1988;52:23–39 [July].
Jiang JJ, Klein G. Risks to different aspects of system success. Inf Manage 1999;36:263–72.
Jiang JJ, Klein G, Balloun J. Ranking of system implementation success factors. Proj Manage J 1996;27(4):50–5.
Kanellis P, Lycett MG, Paul RJ. Evaluating business information systems fit: from concept to practical application. Eur J
Inf Syst 1999;8(1):65–76.
Kanodia C, Bushman R, Dickhaut J. Escalation errors and the sunk cost effect: an explanation based on reputation and
information asymmetries. J Acc Res 1989;27(1):59–77.
Kay E. Desperately seeking SAP support. Datamation 1996;42(4):42–5 [February 15, 1996].
Keil M. Pulling the plug: software project management and the problem of project escalation. MIS Q 1995;19(4):421–47.
Kirsch LJ. The management of complex tasks in organizations: controlling the systems development process. Organ Sci
1996;7(1):1–21.
Kirsch LJ. Portfolios of control modes and IS project management. Inf Syst Res 1997;8,3:215–39.
Kirsch LJ, Sambamurthy V, Ko D-G, Purvis RL. Controlling information systems development projects: the view from the
client. Manage Sci 2002;48(4):484–98.
Koch C. The ABCs of ERP. http://www.cio.com/research/erp/edit/erpbasics.html#erp_fail1999.
Kremers M, Van Dissel H. ERP systems migrations. Commun ACM 2000;43(3):52–6 [April 2000].
Kumar K, Van Hillegersberg J. Enterprise resource planning experiences and evolution. Commun ACM 2000;43
(3):22–6.
Lu, B. 1999. An investigation of the successful ERP implementation. Unpublished Honours Thesis. University of
Tasmania.
Mabert VA, Soni A, Venkataramanan MA. Enterprise resource planning: common myths versus evolving reality. Bus
Horiz 2001:69–76 [May–June].
Mabert VA, Soni A, Venkataramanan MA. Enterprise resource planning: managing the implementation process. Eur J
Oper Res 2003;146(2):302−x.
Markus ML, Tanis C. The enterprise system experience—from adoption to success. In: Zmud R, editor. Framing the
domains of IT management: Projecting the future… …through the past. Cincinnati, OH: Pinnaflex Educational
Resources, Inc.; 2000.
Markus ML, Tanis C, Van Fenema PC. Multisite ERP implementations. Commun ACM 2000;43(3):42–6.
Manz CC, Mossholder KW, Luthans F. An integrated perspective of self-control in organizations. Adm Soc 1987;19
(1):3–24.
McFarlan FW. Portfolio approach to information systems. Harvard Bus Rev 1981;59(5):142–50.
Metrejean E, Stocks MH. The role of consultants in the implementation of enterprise resource planning systems. Mid-
Year Meeting, Information Systems Section-American Accounting Association, January, New Orleans, Louisiana; 2005.
Milgrom P, Roberts J. The economics of modern manufacturing: technology, strategy and organization. Am Econ Rev
1990;80:511–28.
Milgrom P, Roberts J. Comparing equilibria. Am Econ Rev 1994;84:441–59.
Milgrom P, Roberts J. Complementarities and fit: strategy, structure, and organizational change in manufacturing.
J Account Econ 1995;19:179–208.
Milgrom P, Shannon C. Monotone comparative statistics. Econometrica 1994;62:157–80.
Murray MG, Coffin GW. A case study analysis of factors for success in ERP system implementations. Proceedings of the
Seventh Americas Conference on Information Systems; 2001. p. 1012–8.
Nah FF-H, Zuckweiler KM, Lau JL-S. ERP implementation: chief information officers' perceptions of critical success
factors. Int J Hum-Comput Interact 2003;16(1):5–22.
Neter J, Wasserman W. Applied linear statistical models. Homewood IL: Irwin; 1974.
O'Leary DE. Enterprise resource planning systems: systems, life cycle, electronic commerce, and risk. Cambridge UK:
Cambridge University Press; 2000.
Orlikowski WJ. Integrated information environment or matrix of control? The contradictory implications of information
technology. Account Manag Inf Technol 1991;1(1):9–42.
Ouchi WG. A conceptual framework for the design of organizational control mechanisms. Manage Sci 1979;25(9):833–48.
Ouchi WG. Markets, bureaucracies, and clans. Adm Sci Q 1980;25(1):129–41.
Peterson WJ, Gelman L, Cooke DP. ERP trends. New York, NY: The Conference Board; 2001. Report 1292-01-RR.
Raghunathan B, Raghunathan TS. Impact of top management support on IS planning. J Inf Syst 1998;12(1):15–23.
Raho LE, Belohlav JA, Fiedler KD. Assimilating new technology into the organization: an assessment of McFarlan and
McKenney's model. MIS Q 1987;11(1):47–57.
Raymond L, Pare G, Bergeron F. Matching information technology and organizational structure: an empirical study with
implications for performance. Eur J Inf Syst 1994;4(1):3–16.
Ross JW, Vitale MR. The ERP revolution: surviving vs. thriving. Inf Syst Front 2000;2(2):233–41.
Sambamurthy V, Kirsch LJ. An integrative framework of the information systems development process. Decis Sci 2000;31
(2):391–411.
Scheer A-W, Habermann F. Making ERP a success. Commun ACM 2000;43(3):57–62.
Scott J. The FoxMeyer Drugs' bankruptcy: was it a failure of ERP? Proceedings of AMCIS 1999 Americas Conference on
Information Systems; 1999. p. 223–5.
Scott JE, Vessey I. Implementing enterprise resource planning systems: the role of learning from failure. Inf Syst Front
2000;2(2):213–32.
Sharp DJ, Salter SB. Project escalation and sunk costs: a test of the international generalizability of agency and prospect
theories. J Int Bus 1997;28(1):101–22.
Snell SA. Control theory in strategic human resource management: the mediating effect of administrative information.
Acad Manage J 1992;35(2):292–327.
Soh C, Kien SS, Tay-Yap J. Cultural fits and misfits: is ERP a universal solution? Commun ACM 2000;43(3):47–51.
Somers T, Nelson KG. The impact of critical success factors across stages of enterprise resource planning implementations.
Proceedings of the 34th Hawaii International Conference on Systems Science, January 3–6, Maui, Hawaii; 2001.
Somers T, Nelson KG. The impact of strategy and integration mechanisms on enterprise system value: empirical evidence
and manufacturing firms. Eur J Oper Res 2003;146(2):315−x.
Staw B. Knee-deep in the big muddy: a study of escalating commitment to a chosen course of action. Organ Behav Hum
Perform 1976;16(1):27–44.
Staw B. The escalation of commitment to a course of action. Acad Manage Rev 1981;6(4):577–87.
Staw B, Ross J. Behavior in escalations decisions: antecedents, prototypes, and solutions. In: Cummings LL, Staw B,
editors. Research in organizational behavior. Greenwich, Conn: JAI Press; 1987.
Stephanou CJ. The selection process of enterprise resource planning (ERP) systems. Proceedings of the Americas
Conference on Information Systems (AMCIS); 2000. p. 988–91.
Topkis DM. Supermodularity and complimentarity. Princeton University Press; 1998.
Umble MJ, Haft RR, Umble MM. Enterprise resource planning: implementation procedures and critical success factors.
Eur J Oper Res 2003;146(2):241−x.
Whitten JL, Bentley LD. Systems analysis and design methods. 4th edition. Boston, MA: Irwin/McGraw-Hill; 1998.
Willcocks LP, Sykes R. The role of the CIO and IT function in ERP. Commun ACM 2000;43(3):32–8.
Yap CS. Distinguishing characteristics of organizations using computers. Inf Manage 1990;18:97–107.
Zmud RW. Management of large software development efforts. MIS Q 1980;4(2):45–55.

Complementary Controls and ERP Implementation Success

Uploaded by

Document Information

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

Complementary Controls and ERP Implementation Success

Uploaded by

Copyright:

Available Formats

International Journal of Accounting Information Systems

Complementary controls and ERP

Keywords: ERP implementation; Complementarity; Control theory; Business risks

As markets become more competitive, organisations seek new business opportunities to

We propose that an alternative theoretical foundation from economics, complementarity,

2.1. Control theory

In order to attain a superior organisational architecture, firms must recognize complementary

3. ERP implementation control procedures

control procedures utilized by organisations for an ERP implementation. Table 1 summarizes

3.1. Relationship among ERP control activities and control modes

4.3. Survey administration

4.4. Data analysis and results

4.5. Factor analysis — independent variables

Parameter β Std. Error t Sig.

4.6. Factor analysis — dependent variables

4.7. Regression analysis

Fig. 1. Model of control factors critical for ERP implementation success.

Melbourne, University of Tasmania, Australian National University, University of Sydney,

You might also like