informs ®

Vol. 36, No. 5, September–October 2006, pp. 458–469 doi 10.1287/inte.1060.0203

issn 0092-2102
eissn 1526-551X
06
3605
0458 © 2006 INFORMS

Achieving Success in Large Projects:

Implications from a Study of ERP Implementations
Thomas W. Ferratt
Department of Management Information Systems, Operations Management, and Decision Sciences,
School of Business Administration, University of Dayton, Dayton, Ohio 45469-2130, ferratt@udayton.edu

Sanjay Ahire
Moore School of Business, University of South Carolina, Columbia, South Carolina 29208,
ahire@moore.sc.edu
Prabuddha De
Krannert Graduate School of Management, Purdue University, West Lafayette, Indiana 47907-2056,
pde@purdue.edu

Executives in charge of large projects must decide how to spend their energies, even though typically they are
not trained to manage such projects. We have derived two implications for managers based on prior research:
adhere to the fundamentals of project management and unearth the best practices for large-project success.
Through a study of more than 70 enterprise-resource-planning (ERP) projects, we have investigated our hypoth-
esis that greater success in implementation is related to greater adoption of the best practices. For most of the
participants in our study, our hypothesized model holds. For some, however, careful deviation from this model
also proved successful. Additional implications we have derived include recommendations to specify a model
of the project outcomes, understand the factors that make a project large and risky, and include a focus on
managing large projects in executive education and development.
Key words: information systems: management; project management.
History: This paper was refereed.

M anaging large projects is challenging for execu-

tives. In the networked economy of the future,
executives will have to conduct business by man-
aging projects that require multiple alliances (Parise
and Casher 2003). For example, in some current
large projects, companies outsource major organiza-
tional functions, such as information technology (Lee
et al. 2003). Other large projects, such as implementa-
tions of enterprise-resource-planning (ERP) systems,
require organizational transformations. Executives
will increasingly have to manage large projects to con-
duct normal operations and facilitate adaptation.
What is considered a large project varies from one
context to another. Factors that determine project
size include complexity, duration, and budget. In
ERP projects, for example, the complexity depends
on the project scope, including the number of busi-
ness functions affected and the extent to which
ERP implementation changes business processes and
the ways people work. ERP projects achieving real
transformation average one to three years in duration
458
(Koch 2002). Resources required include hardware,
software, professional services, and internal staff,
with estimates of their cost ranging from $0.4 million
to $300 million, with an average of about $15 mil-
lion (Koch 2002). We have studied ERP projects, but
a number of authors examined other types of large
projects, sometimes called jumbo or megaprojects
(Bent 1988, Miller and Lessard 2000). Large construc-
tion projects, like large ERP projects, take years and
many person-hours, costing from eight to 50 million
dollars (Bent 1988). Miller and Lessard (2000) stud-
ied even larger engineering projects, which took about
10 years and cost nearly $1 billion.
How to manage large projects is not typically a
focus of MBA and executive education programs. So,
to supplement on-the-job experience, we offer sugges-
tions for achieving success in managing large projects
based on our review of the literature and empirical
study of ERP projects. We begin by presenting two
major lessons derived from the literature on man-
aging projects. Because much of the prior literature
Ferratt, Ahire, and De: Achieving Success in Large Projects
Interfaces 36(5), pp. 458–469, © 2006 INFORMS
does not focus on large projects, we go beyond it
to empirically investigate a general model of success
determinants, which we have developed based on
our interpretation of accumulated wisdom. Based on
our findings, we provide three additional manage-
rial insights for how executives can achieve success in
managing large projects. We conclude with a final rec-
ommendation that is equally valuable for executives
and educators.
Managerial Implications Based on
the Literature
Managerial Implication 1: Adhere to
the Fundamentals of Project Management
The many sources of wisdom regarding the foun-
dations of successful project management include
various texts (for example, Meredith and Mantel
2003), journals (Project Management Journal, Interna-
tional Journal of Project Management), and educational
programs (for example, the master-of-science pro-
gram in project management at George Washington
University and seminars offered through the Project
Management Institute). Prior researchers have iden-
tified project success factors (Baker et al. 1988; Pinto
and Slevin 1987, 1988; Shenhar et al. 2002). Cooke-
Davies (2002) studied 136 mainly European projects
and described factors fundamental to on-time perfor-
mance (factors 1–6), on-cost performance (factors 7–8),
and project success (factor 9):
(1) Adequacy of companywide education on the
concepts of risk management,
(2) Maturity of an organization’s processes for
assigning ownership of risks,
(3) Adequacy with which managers maintain a vis-
ible risk register,
(4) Adequacy of an up-to-date risk-management
plan,
(5) Adequacy of documentation of organizational
responsibilities on the project,
(6) Keeping project (or project-stage) duration as
far below three years as possible,
(7) Using a mature control process to limit changes
in scope,
(8) Maintaining the integrity of the performance
measurement baseline,
459
(9) An effective benefits delivery and management
process based on the cooperation of project managers
and line managers.
Managerial Implication 2: Unearth the Best
Practices for Large-Project Success
Managers commonly determine the best practices in
particular situations or areas and follow those prac-
tices. However, determining the best practices for
succeeding in large projects can be difficult because
little research has been conducted on managing large
projects.
Researchers have investigated large engineering
projects, such as projects for constructing subways,
tunnels, and power plants costing hundreds of mil-
lions of dollars and spanning many years (Miller and
Lessard 2000). The motivation and funding sources
for such projects may differ from those for the large
projects typical executives face. But the development
of shared project governance arrangements among
those working on such projects should interest exec-
utives in networked organizations.
For most organizations, ERP projects are the largest
and most complex organizationwide projects they
have undertaken. These large projects cause major
changes to information systems and software. Con-
currently, they often drastically alter the organiza-
tion’s underlying operations and business processes.
Our attempt to unearth the best practices for suc-
cessfully managing projects to implement ERP sys-
tems has shown us why executives managing large
projects may have difficulty finding the best practices.
Early adopters of ERP systems could not identify the
best practices because they had no prior adopters
from whom to learn. We broadened the search for
the best practices, however, by viewing the imple-
mentation of ERP systems as projects in general.
That broadened search led us to our first manage-
rial implication: adhere to the fundamentals of project
management. Beyond that, though, we found that
with widespread implementation of ERP systems,
researchers have identified the best practices for ERP
projects (Table 1). We also found reasons why com-
panies abandon information-systems projects (that is,
the reverse of the best practices), significant software
project risks (under the assumption that the best prac-
tices involve ameliorating risks), and critical success
factors for projects in general.
 Ferratt, Ahire, and De: Achieving Success in Large Projects
460 Interfaces 36(5), pp. 458–469, © 2006 INFORMS

Success factors for ERP implementation

(Akkermans and van Helden 2002, Reasons companies abandon IS Software project risks Success factors for project
Somers and Nelson 2001) projects (Ewusi-Mensah 1997) (Keil et al. 1998) management (Pinto 2004)

—Top-management support —Lack of agreement on project —Lack of top-management commitment —Well-defined mission
—Project team competence goals and objectives —Failure to gain user commitment —Top-management support
—Interdepartmental cooperation —Weak or problematic project team —Misunderstanding requirements —Detailed project plans and
—Clear goals and objectives —Poor project management and control —Inadequate user involvement schedules
—Project management —Limited technical know-how —Failure to manage end user —Client participation
—Interdepartmental communication —Unsatisfactory technology base or expectations —Skilled personnel
—Management of expectations infrastructure —Changing scope or objectives —Capacity to accomplish
—Project champion —Lack of senior management —Inadequate knowledge and skills technical tasks
—Vendor support involvement —Changing requirements —Client acceptance
—Careful package selection —Escalating project cost and time of —Introduction of new technology —Monitoring and feedback
—Data analysis and conversion completion —Insufficient or inappropriate staffing —Clear communication
—Dedicated resources —Conflict between user departments —Troubleshooting
—Steering committee
—User training
—Education on new business
processes
—Business process re-engineering
—Minimal customization
—Architecture choices
—Change management
—Vendor partnership
—Vendor’s tools
—Use of consultants

Table 1: These four lists represent alternative perspectives on the best practices. The first list is based on a broad
literature review followed by a rating of the factors by 52 senior managers from US firms that had completed ERP
implementations. The second list is based on surveys of canceled projects in Fortune 500 companies in the US,
case studies of abandoned projects in southern California, and published reports in the literature. The third list
is based on a Delphi study of experienced software-project managers in Hong Kong, Finland, and the US. The
fourth list is based on a study of over 400 projects.

The General Model and Our Method of
Investigation
Once executives unearth a list of the best practices,
they must decide which ones to follow. A general
model for succeeding in managing large projects is
that success is proportional to the number of the
best practices adopted and the degree to which each
practice is implemented. Following all of the prac-
tices may take far too much time and money. By
choosing some, executives may still be successful.
We wanted to see whether the general model was
valid across a number of organizations. To investi-
gate the model, we needed to study large projects for
which researchers had identified the best practices.
ERP projects fit these criteria.
Prior researchers developed lists of the best prac-
tices for ERP projects by searching through published
studies and asking project participants to identify
success factors. However, we could not find an
empirical study investigating whether adopting more
of the best practices improved outcomes. We have
addressed this gap in the literature.
From the lists of the best practices, we selected
a set to investigate. We developed a survey that
included questions on nine best practices (Somers
and Nelson 2001). The response scale for each item
ranged from 1 to 7, where the anchor for 7 (for exam-
ple, Comprehensive) represented the best practice and
the anchor for 1 (for example, Limited) represented
the opposite. We used the following nine items and
anchors (1–7):
—Project planning (Limited–Comprehensive)
—Top-management support (Limited–Compre-
hensive)
—Software-selection efforts (Limited–Compre-
hensive)
Ferratt, Ahire, and De: Achieving Success in Large Projects
Interfaces 36(5), pp. 458–469, © 2006 INFORMS
—Training of project team and end users (Limited–
Comprehensive)
—Project team composition (Narrow–Broad)
—Team member participation (Limited–Extensive)
—Information-systems-area participation (Limited–
Extensive)
—Primary consultant’s capability (Limited–Strong)
—Primary consultant’s support (Limited–Exten-
sive)
We chose items that would be attended to early
in the project: project planning, software selection,
project team composition, and primary consultant’s
capability. We also included some that would be of
concern late in the project: training project team mem-
bers and end users, team member participation, and
primary consultant’s support—and we included some
that would be pertinent at all stages: top-management
support and the information-systems-area participa-
tion. Because we found no universally accepted list,
we assumed, based on the systems principle of equi-
finality (that different starting conditions can lead to
the same end result), that a number of different sets
of the best practices would promote success. Thus, by
using a reasonable set of the best practices, we could
test the model that adopting more of the best practices
would improve outcomes.
We also included questions on outcomes. The
response scale for each item ranged from 1 to 7, where
the anchor for 7 (for example, Drastic increase) rep-
resented the best outcome and the anchor for 1 (for
example, Drastic decrease) represented the opposite.
We used the following five items and anchors (1–7):
—Change in information integration capabilities
(Drastic decrease–Drastic increase)
—Change in information quality (Drastic decrease–
Drastic increase)
—Change in process and product quality (Drastic
decrease–Drastic increase)
—Change in competitive business performance
(Drastic decrease–Drastic increase)
—Overall satisfaction with the project outcomes
(Very dissatisfied–Very satisfied)
Success in ERP projects may be evaluated on tra-
ditional project-management metrics, such as on-time
or on-budget performance; or based on business
outcomes, such as information-processing benefits,
effects on business operations, or impact on business
461
performance (Pinto 2004). Our first four questions
focused on these delivered benefits rather than tra-
ditional project-management metrics. We based our
choice of questions on the assumption that deliv-
ering business outcomes is what is important for
assessing executive success in managing a large ERP
project. Our question on overall satisfaction encom-
passes the business outcomes delivered. It might not
represent how well the project-management metrics
were met. Satisfaction might be justifiably high if the
ultimate project deliverables were strong even though
the project had been completed behind schedule and
over budget, and it might still be low if the ulti-
mate project deliverables were weak even though
the project had been completed on time and within
budget.
We also invited respondents to share the lessons
they had learned from their experience.
We mailed survey forms to 4,549 individuals
identified as top information-technology executives
on mailing lists obtained from the Society for
Information Management (SIM) (216 names) and
Applied Computer Research (ACR) (4,333 names).
We included an endorsement letter from SIM. Of the
120 surveys returned (12 from the SIM list and 108
from the ACR list), 69 were from individuals who
answered most questions about the best practices and
outcomes of the project (six from SIM, 63 from ACR).
Two factors might have limited the response rate:
(1) We solicited responses only from those who had
been involved in ERP projects, and (2) We asked par-
ticipants to complete this survey and also to indicate
whether they were willing to participate in a subse-
quent, more-detailed survey. The high perceived time
commitment might have dissuaded some recipients
from participating.
For over half of these respondents, the business
unit implementing ERP was the entire organiza-
tion, while for most of the others it was one or
more locations or divisions of a larger organization
(Table 2). We cannot claim that our respondents rep-
resent a random sample of organizations, but they
come from a range of service and manufacturing
industries and organizations of various sizes. Of the
120 participating organizations, 69 (58 percent) have
implemented, are implementing, or have abandoned
ERP, 28 (23 percent) did not even consider ERP,
 Ferratt, Ahire, and De: Achieving Success in Large Projects
462 Interfaces 36(5), pp. 458–469, © 2006 INFORMS

Median Frequency Percent (%) “Do not underestimate resources needed for the
project. Backfill or get replacements for project
Number of employees resources.”
4,000 Less than 2,000 20 33 “Don’t set overly aggressive deadlines unless able to
2,000–5,000 22 36 commit resources.”
More than 5,000 19 31 “Communicate expectations. Clearly and frequently
Annual gross sales (millions) communicate to management staff what will be occur-
$800 Less than $500 16 28 ring during the project.”
$500–$2,000 23 40 “Change management. Put the right people on the
More than $2,000 18 32 project. Phased approach. Active project cost manage-
Industry ment.”
Service 21 48 “Test, test, test. Train, train, train. Put the best and
Manufacturing 23 52 brightest on the project team.”
Software “Expect lost momentum. Implementations are an
Package 60 87 extensive project. Expect team to lose momentum and
Custom 5 7 inject resources or challenges during that time.”
Package and Custom 4 6
Implementation approach
Location-division at a time 26 38 Additional Managerial Insights
Entire organization-module at a time 10 14 Our respondents rated all but one of the nine best
Entire organization-all modules at once 25 36
Other 8 12
practices and all five outcomes 5.0 or better on seven-
Status
point scales, indicating that they generally used the
ERP project in progress 35 51 best practices and judged their ERP implementa-
ERP in use and no ongoing project 31 46 tion efforts to have been effective (Table 3). They
ERP aborted or abandoned 2 3
gave consultant’s capability, consultant’s support, and
Table 2: The 69 respondents who had worked on ERP projects reported on software selection effort the lowest scores. These
the characteristics of the business units that implemented ERP and the scores also had the greatest variability. They reported
approach and status of the implementation. that information integration and information qual-
ity showed the most drastic increases and that com-
petitive business performance showed the lowest
and 13 (11 percent) had considered ERP but decided
increase.
to delay or not to initiate an ERP implementation
project. Some of the remaining eight percent had
adopted ERP but did not yet have enough experience Standard
Mean deviation Number
with ERP to answer the questions about the best prac-
tices and outcomes or did have experience with ERP
Best-practices questions
but chose to provide written comments rather than Project planning 6.1 1.3 68
answer the questions. Top-management support 5.9 1.3 69
Software-selection efforts 5.2 1.7 67
Training of project team and end users 5.4 1.2 69
Lessons Learned That Support Project-team composition 5.8 1.1 69
Team-member participation 5.9 1.0 69
the Project-Management Literature Information-systems-area participation 6.2 1.0 69
Participants provided an abundance of lessons Primary consultant’s capability 5.0 1.5 69
Primary consultant’s support 4.9 1.6 69
learned that emphasize the importance of adher-
Outcome questions
ing to project management fundamentals. Comments Change in information-integration capabilities 5.9 0.9 68
included the following: Change in information quality 5.8 1.1 68
Change in process and product quality 5.5 1.2 65
“Good project management is always important.” Change in competitive business performance 5.1 1.1 62
“Project planning is critical.” Overall satisfaction with the project outcomes 5.5 1.1 60
“Find a strong project manager. Avoid scope creep
whenever possible. Involve employees from all areas Table 3: Mean scores represent the extent to which a best practice was
as team members.” implemented or an outcome achieved, from low (1) to high (7).
Ferratt, Ahire, and De: Achieving Success in Large Projects
Interfaces 36(5), pp. 458–469, © 2006 INFORMS 463

Before analyzing the relationship between the best not been listed in prior studies of ERP and software
practices and the outcomes, we conducted factor anal- projects; however, they do consider technical know-
yses and scale-reliability analyses on the best practices how and technology infrastructure (Table 1).
and the outcomes separately. These analyses indicated Based on cluster analysis, we identified two com-
that the best-practices questions grouped together binations of the best practices the less effective orga-
to form four best practices: (1) top-management nizations were using and two the more effective ones
support, planning, training, and team contributions, were using. We use the mean of all five outcome mea-
(2) software-selection efforts, (3) information-systems- sures (Table 3) to distinguish between low and high
area participation, and (4) consulting capability and effectiveness. Analysis of variance shows that the dif-
support. Organizations whose top management sup- ference in the effectiveness of the two pairs is statis-
ported implementation efforts, for example, also had tically significant
p = 0000 (Figure 1). Three of the
comprehensive planning and training and had high configurations, (1) (no best practices), (2) (moderate
team contributions, but they might or might not have best practices), and (4) (all the best practices) pro-
devoted much effort to choosing software. The anal- vide support for the general model of success. They
yses also indicated that the outcome questions were show that the greater the extent is of best-practice
correlated and should be combined to form a single adoption, the better are the results. One configuration,
outcome factor, effectiveness (Table 4). (3) (unconventional), challenges the model. This con-
Some factors, such as top-management support and figuration follows two of the best practices, having
project planning, are identified in the general project- strong top-management support, planning, training,
management literature as well as in the ERP and and team contributions, but it has limited software-
software literature (Table 1). Factors specific to ERP selection efforts and limited consultant capability and
projects, for example, software-selection efforts and support. Relative to configurations 2 and 4, the two
consultant’s support, have been identified in the ERP most effective of the three conventional configura-
literature (Table 1). To our knowledge, information- tions, configuration 3 is comparable to 4 in its effec-
systems-area participation, a factor we identified, has tiveness and significantly more effective than 2, even
though it has lower software-selection efforts and
lower consultant capability and support than either 2
Standard or 4.
Mean deviation Reliability Number
The existence of this unconventional but effective
configuration raises questions about the linearity we
Derived best-practices factors
Top-management support, 5.9 1.0 0.89 69 hypothesized in our model, that is, that increasing the
planning, training, and extent of best-practice adoption improves outcomes.
team contributions We conducted separate regression analyses using the
Software-selection efforts 5.2 1.7 — 67
Information-systems-area 6.2 1.0 — 69
derived outcomes factor as the dependent variable
participation and the derived best-practices factors as the inde-
Consulting capability and 4.9 1.5 0.85 69 pendent variables for the 60 cases in configurations
support
1, 2, and 4 and the 67 cases in all four configura-
Derived outcome factor tions. We found significant linear relationships in both
Outcomes (mean of 5 5.6 0.9 0.85 69
outcomes questions) analyses, but the relationship is stronger without the
unconventional configuration (Table 5). These analy-
Table 4: Mean scores represent the extent to which a derived best practice ses reinforce our judgment that the unconventional
was implemented or the derived outcome factor achieved, from low (1) to
third configuration raises questions about the linear-
high (7). Reliabilities are Cronbach alpha coefficients. The first derived
best-practice factor has two items. The first item is top-management sup- ity of the general model.
port. The second item is the mean of the following four items: project We conducted several analyses using such con-
planning, training of project team and end users, project-team compo- textual factors as size, industry, and implementation
sition, and team-member participation. The reliability of the latter four
items as a scale is 0.81. The second and third derived best practices have approach (Table 2) to determine whether the con-
no reported reliability because each is based on a single item. text makes a difference in the relationship between
 Ferratt, Ahire, and De: Achieving Success in Large Projects
464 Interfaces 36(5), pp. 458–469, © 2006 INFORMS

Low effectiveness High effectiveness

1 2 3 4
No best practices Moderate best practices Unconventional All the best practices
n=2 n = 26 n=7 n = 32
7.0 7.0 7.0 7.0
6.0 6.0 6.0 6.0
5.0 5.0 5.0 5.0
4.0 4.0 4.0 4.0
3.0 3.0 3.0 3.0
2.0 2.0 2.0 2.0
1.0 1.0 1.0 1.0
1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5

Figure 1: We found four different configurations of practices and effectiveness. The horizontal axes repre-
sent best-practice factors: top-management support, planning, training, and team contributions (1); software-
selection efforts (2); information-systems-area participation (3); consulting capability and support (4); and effec-
tiveness (5). Scores on the vertical axes represent the extent to which a best practice was implemented or
effectiveness was achieved, from low (1) to high (7). Analysis of variance shows that the difference in the effec-
tiveness of the two more effective and two less effective configurations is statistically significant
p = 0000.

the derived best practices and the outcome factors.
None had a strong enough effect to suggest that some
configurations were more effective in different con-
texts. Additional analyses of whether different con-
textual factors by themselves were related to higher
or lower outcomes showed that effectiveness varies
only by ERP status, with the lowest effectiveness (3.2,
based on the derived outcomes factor) for those who
aborted or abandoned ERP and the higher effective-
ness for those with a project in progress (5.7) or those
with ERP in use with no ongoing related project (5.6).
None of these analyses support conclusions that
contextual factors make a difference, except the
obvious conclusion that aborted or abandoned ERP
projects are less successful. For example, they fail to
support a conclusion that some approaches to imple-
mentation (such as one location or division at a time)
are more effective than others (such as the entire orga-
nization at once) or that large organizations benefit
Cases included in regression analysis N R2
Those with conventional configurations
1 2 4 60 0.275
Those with any configuration, including 67 0.232
unconventional (1, 2, 3, and 4)
Table 5: We conducted two regression analyses with the derived outcomes
factor (that is, effectiveness) as the dependent variable and the four
derived best-practices factors as the independent variables. All of the
regression coefficients were positive in both regressions.
from ERP systems more than small organizations. Per-
haps with larger or random samples, we might have
obtained different results. Based on our results, we
can make no specific recommendation about what
works in a specific context or what outcomes to expect
other than really low outcomes if you abort or aban-
don ERP implementation (or low outcomes lead to
aborted or abandoned implementation).
For 90 percent of the organizations in our broad
sample (those in configurations 1, 2, and 4), the gen-
eral model of success holds. Top managers responsi-
ble for managing large projects in general and ERP
system implementations specifically should identify
best practices for similar types of projects in their own
organizations or in other organizations and follow
them extensively and intensively. Because our sam-
ple is not a random sample of large projects or ERP
projects, managers should generalize from our results
cautiously. Because we are the first to investigate this
general model, our results are only suggestive. Execu-
tives should recognize that our hypothesized model is
Sig.
a valuable guide: A general model of success in man-
aging large projects is that greater success is related
0.001
0.002 to greater adoption of the best practices.
Managerial Implication 3: Deviate, but Carefully,
from Following the Best Practices
The third configuration from our cluster analysis (Fig-
ure 1) challenges the model that increasing the extent
Ferratt, Ahire, and De: Achieving Success in Large Projects
Interfaces 36(5), pp. 458–469, © 2006 INFORMS
of best-practice adoption improves outcomes. One
of the best practices not followed in this configura-
tion is obtaining strong consulting partners, includ-
ing vendors, to help implement ERP software. Some
participants in the conventional configurations (1, 2,
and 4) recommended working with strong consulting
partners:
“Put extra effort into selecting implementation
consultants.”
“Use of a consultant with specific package experience
was essential.”
“We had a collaborative approach with the vendor,
which ensured the project to be ‘On time, under
budget’.”
Others had uneasy relationships with implementa-
tion partners:
“Don’t believe anything the vendor says till you prove
it yourself.”
“The consultants were at times helpful and at other
times a hindrance.”
“Use of contract help is very expensive.”
“Don’t be afraid to question the consultants—they
aren’t always right.”
Some questioned how much consultant support is
ideal:
“Use of contract help loses the knowledge needed later
to run the system.”
“Ensure consultant support is minimal; internal
resources must be trained and must do the bulk of
configuration work. Better quality and long-term bet-
ter support.”
Two participants (A and B) who followed the
unconventional configuration commented on their
relationships with consultants. Respondent A’s large
organization implemented ERP across the entire orga-
nization one (or a few) module(s) at a time, using
packaged software, and currently uses the system.
“We ran two concurrent projects, one for finance and
one for HR. The HR project went well. Positives were
joint efforts from businesses, IT, and consultants, phys-
ical location of the joint team (who shared the same
office), and mixing the training. Negatives were solv-
ing system performance issues. Challenges were meet-
ing the Y2K deadlines and concurrently merging two
similar organizations. The key benefit was a single
integrated system for the entire organization. For the
finance project, the positives were combining over 20
systems into a single corporate system and meeting
the Y2K deadlines. Negatives were the ‘rotating door’
465
of staff and management of the procurement business
unit and reliance on consultants to provide IT and
business unit training. The key challenge was concur-
rent reorganization of business units.”
Respondent B’s small service organization is currently
implementing all (or most) modules together for the
entire organization, using packaged software.
“Planning is critical. Make sure your in-house ERP
team members are part of any add-on projects. Make
sure you have excellence in application architecture to
make sure interfaces planned are actually feasible.”
Respondent A had mixed success with consultants,
and respondent B was emphatic that in-house peo-
ple were critical resources, implicitly downplaying
consultants.
Our participants indicated that achieving an ideal
relationship with consultants can be extremely diffi-
cult. External partners are likely to be essential on
other large projects, and thus, the challenge of devel-
oping a productive relationship with implementation
partners is not limited to ERP projects. The uncon-
ventional implication for an executive in a networked
organization involved with a number of external part-
ners may be the following: Instead of relying on exter-
nal partners as much as the best practices would
suggest, rely on your own understanding of your
business and capitalize on your internal resources.
An implication arising from configurations 3 and 4,
the effective unconventional and conventional config-
urations, is that effective organizations develop dif-
ferent approaches to work with external partners.
An organization might undergo trial and error and
tumult to acquire the internal capabilities for com-
pleting the project and operating successfully after-
ward, based on the comments of respondents from
some unconventional organizations. More conven-
tional organizations might collaborate closely with
carefully chosen consultants and vendors. Other
researchers (Miller and Lessard 2000) report that
some organizations develop shared governance struc-
tures when their relationships with consultants or
vendors go beyond traditional customer-supplier
relationships.
Managers will encounter challenges when applying
our general model for success. Specifically, the best
practices they unearth may provide unclear or con-
flicting advice or may not be viewed as universally

466
applicable. Our third implication indicates that they
will need to use judgment to apply the best prac-
tices. Two additional managerial implications arise
from our analysis of the participants’ responses that
may help managers achieve success in large projects.
Managerial Implication 4: Understand
the Characteristics That Make a Project
Large and Risky
Top managers are accustomed to being responsible
for large capital budgets and the risks associated with
them. When a project’s scale and risks dwarf those
of other projects, however, that project demands top-
management attention. Given the low success of some
projects in our study and the low support top man-
agers gave these projects, we wondered why top man-
agers failed to give these projects the attention they
needed.
We found answers to this question in our partici-
pants’ comments: These managers apparently did not
fully understand the complexity, size, and risks of
ERP projects. We developed a broad framework to
help managers understand these aspects of ERP and
similar projects (Table 6). Managers of other large
projects may be able to use this framework or one
tailored to their situations. This framework has three
major factors: changes in business processes, changes
Changes Scope Risk
Business processes Extent of processes Uncertainty of successful
affected change
Technology Extent of changes to Uncertainty of successful
essential technologies change
Amplifier
Business goals Degree of difficulty associated with meeting
and ambitions goals and ambitions
Overall risk index = [(Scope ∗ Risk of business processes)
+ (Scope ∗ Risk of technology)] ∗ Degree of difficulty
associated with meeting business goals and
ambitions (based on their scope and risk)
Table 6: This organizational risk-analysis framework for large projects
has three major factors: two major characteristics of a business that
an ERP project affects—changes in business processes and changes
in technology—and a third factor corresponding to the drivers of these
changes—business goals and ambitions. The columns represent how
widely these changes will affect the organization and how risky these
changes are likely to be. Scores of 0–5 on each scale would result in a
minimum overall risk index of 0 and a maximum of 250.
Ferratt, Ahire, and De: Achieving Success in Large Projects
Interfaces 36(5), pp. 458–469, © 2006 INFORMS
in technology, and an amplifier, consisting of the busi-
ness goals and ambitions, which provides the busi-
ness context.
One participant clearly appreciated the risk asso-
ciated with redesigning the organization’s business
processes:
“Expect resistance to business process changes. As we
move forward in our project, we find this to be the
most difficult issue because of our history of allowing
manufacturing plants to operate autonomously.”
Although a few participants emphasized that ERP
had a much greater impact on business processes than
on technology, others said that changes in technology
also contribute to the complexity of ERP projects:
“Don’t underestimate complexity of the system.”
“   technology is very difficult.”
“Developing common corporate coding schemes and
data dictionaries is a major obstacle.”
Many participants reported that their ERP projects
included replacing legacy systems with new systems,
which required huge efforts on the part of consul-
tants, vendors, primary project teams, and end-users.
Changes in business processes and technology may
be intertwined. Research on the process of devel-
oping large software systems shows that, besides
the obvious technology issues, it includes behavioral
issues, such as learning, communicating, and nego-
tiating (Curtis et al. 1988). Similarly, ERP projects
generally require changes to both business processes
and technology. These changes also require learn-
ing, communicating, and negotiating. Hence, manage-
rial assessment of the risks associated with changes
in business processes and technology should include
the behavioral challenges of implementing changes in
business processes and technology.
Overlaying the changes in business processes and
technology are the business goals or ambitions asso-
ciated with an ERP project. The reasons organizations
adopt these large, complex systems have included
Y2K compliance, replacing legacy systems, support-
ing process reengineering, integrating or consolidat-
ing multiple sites or operations, supporting growth or
acquisitions, improving reporting and decision mak-
ing, and facilitating regulatory compliance (Robey
et al. 2002). Because such goals drive change, the
degree of difficulty in meeting these goals multi-
plies the risks associated with changes in business
Ferratt, Ahire, and De: Achieving Success in Large Projects
Interfaces 36(5), pp. 458–469, © 2006 INFORMS
processes and technology. Thus, one can compute the
overall risk index of a project by adding the risk
index of business-process changes to the risk index
of technology changes and multiplying that total by
the degree of difficulty associated with achieving the
goals and ambitions driving the project (Table 6).
This risk-analysis framework provides top man-
agers with a tool that can help them understand
the overall risk of an ERP project. They could adapt
it to other large projects by identifying pertinent
sources of risk for such projects. In building a risk-
analysis framework for a specific project, the man-
ager may find it helpful to consider detailed lists
of risks and processes for analyzing and managing
risks (Barki et al. 2001, Chapman 1997, Keil et al.
1998). Ideally, the framework would be built to yield
a risk index for each project competing for the atten-
tion of the executive, who could compare the result-
ing indices in assessing project priorities. The lesson
here is to go beyond the obvious and think deeply
about the characteristics that make a project large
and risky. The tool would ask, does this project have
the same nagging risk as other projects vying for
top-management attention or does it also have the
brain-busting, business-killing risk that really requires
top-management dedication? Our framework should
help executives determine where to spend their time
and energy among such competing projects.
Managerial Implication 5: Develop a Model of
Project Outcomes
Desirable outcomes for any project are to meet the
budget and the schedule. However, these traditional
project-management metrics are not the primary out-
comes that determine a project’s success, whether it
is an ERP implementation or another large project. As
one participant succinctly noted,
“Business case is critical.”
Traditional project-management metrics are impor-
tant but not sufficient. Furthermore, building a busi-
ness case for a large project is not a new idea. Any
business-systems analyst understands that organiza-
tions undertake even small-systems projects to satisfy
business objectives. Nevertheless, our study partici-
pants insisted that one of the lessons learned was the
importance of the business case, which suggests that
467
specifying a model of project outcomes is essential.
Additional comments indicate that even though man-
aging expectations is a common project-management
activity, the complexity of large projects requires spe-
cial attention to developing a model of what the out-
comes will be and when they will occur:
“   business benefits are not achieved for a long time.”
“Selling the business reasons for changing the
processes and user interfaces, which affect every
employee, cannot be underestimated.”
“Integrated systems often have negative effects on
performance of systems and information delivery   
Businesses with effective and efficient processes see a
major negative effect if the ERP system doesn’t fit the
business.”
“Expectations of users also start to wane because they
expected 100 percent functionality out of the box.”
These comments suggest that a complex set of out-
comes is associated with implementing an ERP sys-
tem. It is important to develop and communicate a set
of shared expectations among key stakeholders about
the outcomes and when they are likely to be achieved.
As another participant described a lesson learned:
“[Set] expectations regarding the time line to realize
the full benefits of implementation.”
Delayed or negative results are a possibility. For
example, 40 percent of the respondents in Betts’s
(2001) study said their ERP project failed to achieve
business objectives even a year after the system was
completed. If achieved, the benefits may take six
months longer than expected because costs may go
up, not down, for the first six months after implemen-
tation. One explanation for the delay is that project
managers are under pressure to go live quickly, and
then they must scramble to fix deficiencies.
Achieving desired outcomes is difficult. For exam-
ple, to achieve user satisfaction, project managers
must inform all affected managers and employees
clearly and frequently of process changes. As man-
agers and employees cope with the difficulties of
adopting new processes and technologies, project
managers can attempt to manage their expectations
about delayed or negative outcomes by explaining
what the outcomes will be and when they will occur.
Our participants reported that their organizations
were generally satisfied with the outcomes of ERP
implementation. The best results were related to infor-
mation integration and quality, while the weakest

468
results were related to competitive business perfor-
mance. The link between an ERP system and informa-
tion integration and quality is fairly direct, whereas
competitive business performance is affected by many
other factors, making the link more indirect and
tenuous. An ERP system is designed to improve
information flow across subunits through standard-
ization and integration of activities. It may reduce
information system maintenance costs and increase
the organization’s ability to deploy new information
system functionality. Changes in business processes
during implementation may enable a transformation
from inefficient business processes toward processes
that represent the best practices. Increased efficiency
and productivity may be embodied in such out-
comes as shorter cycle times or time to market, faster
or more on-time deliveries, or reduced inventory.
Improvements in competitive business results, such as
increased market share or return on investment, may
follow.
The complexity and timing of outcomes associated
with ERP implementations and the challenge of man-
aging expectations surrounding their achievement
imply that other large projects will face similar diffi-
culties. By developing a model of the outcomes that
takes this complexity into account, project managers
can think through and communicate the expected tim-
ing of project outcomes.
Managerial Implication 6: Executive Education and
Development Should Include a Focus on Managing
Large Projects
A final implication of our work and of our expec-
tation that executives will increasingly manage large
projects is that they need help in developing such
knowledge and skill. Large complex projects can
drain even the best of organizations and managers.
One of our participants, whose project followed the
best practices, offered this battle-weary comment:
“Even if successful, it is a very difficult, business-
impacting effort [such] that everyone who has gone
through it wants to avoid doing it again.”
If educators responsible for developing future exec-
utives endeavor to build competence in managing
large projects, they should produce executives who fit
the future environment. Executives with this educa-
tion may be able to manage large projects in such a
Ferratt, Ahire, and De: Achieving Success in Large Projects
Interfaces 36(5), pp. 458–469, © 2006 INFORMS
way that they view the experience as satisfying. They
may even look forward to the inevitable next large
project.
Conclusion
Executives managing large projects must decide how
to spend their energies. Our investigation provides an
instructive guide for making that decision. It suggests
that they should
—Adhere to the fundamentals of project
management;
—Unearth the best practices for their large project’s
success;
—Follow the best practices to as great an extent as
possible, while developing an understanding of the
major factors making their project large and risky and
developing a model of the project outcomes; and
—Recognize that deliberately and carefully deviat-
ing from the best practices may also be effective.
Our participants have provided numerous first-
hand insights concerning the challenges of success-
fully managing large projects. Although such projects
can be managed successfully, they can also lead to
disaster. Pragmatic managers who are facing large
projects will certainly benefit from the distilled wis-
dom of those who have preceded them.
References
Akkermans, H., K. van Helden. 2002. Vicious and virtuous cycles
in ERP implementation: A case study of interrelations between
critical success factors. Eur. J. Inform. Systems 11(1) 35–46.
Baker, Bruce N., David C. Murphy, Dalmar Fisher. 1988. Factors
affecting project success. David I. Cleland, William R. King,
eds. Project Management Handbook. Van Nostrand Reinhold,
New York, 902–919.
Barki, Henri, Suzanne Rivard, Jean Talbot. 2001. An integrative con-
tingency model of software project risk management. J. Man-
agement Inform. Systems 17(4) 37–69.
Bent, James A. 1988. Project control: An introduction. David I.
Cleland, William R. King, eds. Project Management Handbook.
Van Nostrand Reinhold, New York, 559–596.
Betts, Mitch. 2001. Never ending story. Why ERP projects cause
panic attacks. (Sept. 24). Retrieved March 29, 2006 http://www.
computerworld.com/managementtopics/roi/story/0,10801,64064,
00.html.
Chapman, Chris. 1997. Project risk analysis and management—
PRAM the generic process. Internat. J. Project Management 15(5)
273–281.
Cooke-Davies, Terry. 2002. The “real” success factors on projects.
Internat. J. Project Management 20(3) 185–190.
Ferratt, Ahire, and De: Achieving Success in Large Projects
Interfaces 36(5), pp. 458–469, © 2006 INFORMS
Curtis, Bill, Herb Krasner, Neil Iscoe. 1988. A field study of the
software design process for large systems. Comm. ACM 31(11)
1268–1287.
Ewusi-Mensah, Kweku. 1997. Critical issues in abandoned informa-
tion systems development projects. Comm. ACM 40(9) 74–80.
Keil, Mark, Paul E. Cule, Kalle Lyytinen, Roy C. Schmidt. 1998.
A framework for identifying software project risks. Comm.
ACM 41(11) 76–83.
Koch, Christopher. 2002. The ABCs of ERP. Retrieved March 7, 2002
http://www.cio.com/research/erp/edit/erpbasics.html.
Lee, Jae-Nam, Minh Q. Huynh, Ron Chi-Wai Kwok, Shih-Ming
Pi. 2003. IT outsourcing evolution—Past, present, and future.
Comm. ACM 46(5) 84–89.
Meredith, J. R., S. J. Mantel Jr. 2003. Project Management: A Manage-
rial Approach, 5th ed. John Wiley and Sons, Hoboken, NJ.
Miller, R., D. Lessard. 2000. The Strategic Management of Large Engi-
neering Projects: Shaping Institutions, Risks, and Governance. MIT
Press, Cambridge, MA.
Parise, Salvatore, Amy Casher. 2003. Alliance portfolios: Designing
and managing your network of business-partner relationships.
Acad. Management Executive 17(4) 25–39.
469
Pinto, Jeffrey K. 2004. The elements of project success. David I.
Cleland, ed. Field Guide to Project Management, 2nd ed. John
Wiley and Sons, Hoboken, NJ, 14–27.
Pinto, Jeffrey K., Dennis P. Slevin. 1987. Critical factors in suc-
cessful project implementation. IEEE Trans. Engrg. Management
EM-34(1) 22–27.
Pinto, Jeffrey K., Dennis P. Slevin. 1988. Critical success factors
in effective project implementation. David I. Cleland, William
R. King, eds. Project Management Handbook. Van Nostrand
Reinhold, New York, 479–512.
Robey, Daniel, Jeanne W. Ross, Marie-Claude Boudreau. 2002.
Learning to implement enterprise systems: An exploratory
study of the dialectics of change. J. Management Inform. Systems
19(1) 17–46.
Shenhar, Aaron J., Asher Tishler, Dov Dvir, Stanislav Lipovetsky,
Thomas Lechler. 2002. Refining the search for project success
factors: A multivariate typological approach. R & D Manage-
ment 32(2) 111–126.
Somers, T. M., K. Nelson. 2001. The impact of critical success factors
across the stages of enterprise resource planning implementa-
tions. Proc. 34th Hawaii Internat. Conf. Systems Sci.
HICSS-3,
CD-ROM, Maui, HI, January 3–6.