An Incremental Process for Software Implementation

Eighteen months had elapsed since New World Electronics began implementing an advanced software-based scheduling system for the factory floor.1 From the beginning, all the traditional elements were present for a smooth implementation: support of senior management, adequate staffing and funding, a good fit between the needs of the organization and the capabilities of the software, and a solid information technology (IT) infrastructure. Yet after a vigorous start, the project team had lost its way. What had seemed like a relatively straightforward task — configuring desired software functionality and specifying complementary organizational changes — turned out to be surprisingly burdensome. As the team engaged in cycle after cycle of analysis and configuration, it continually approached but never quite reached a complete and sound model tailored to the company’s manufacturing environment. Milestone dates passed; resources and attention drifted away. The team wondered how to refocus its energies.

New World Electronics’ conundrum is not unique.2 Gone are the days of turnkey packages — technologies that, at least in principle, could be physically installed, turned on, and used with minimal alteration by most organizations. Nearly all advanced production technologies today — CAD/CAM, executive support systems, digital imaging, work-flow management, enterprise resource planning, groupware — either have a substantial software component or come entirely embedded in software.3 The broad flexibility of modern software can be both the boon and bane of technology implementation. This flexibility enables new ways of working that amplify the potential benefits of IT investments, but can transform almost any implementation project into a potentially risky program of organizational innovation and change. It offers users an abundance of functionality, but demands that they choose well from this abundance to ensure that their chosen configuration is not only internally consistent, but also complements organization processes, policies, structures, and measures. Moreover, this flexibility is conducive to the application of new strategies for managing the process of implementation itself, but users must choose wisely from among alternative strategies.

The root of the problem at New World Electronics was not a poor endowment of resources or some other project factor, but rather an ineffective implementation process.4 Team members employed a traditional approach to software implementation, characterized by a lengthy period of off-line effort to select and configure software functionality, which would conclude with a “big-bang” finish — a concentrated interval when the complete system would be turned on. Intending to make a clean, one-time switch from the old systems and practices to the new, the big finish never occurred. Although “all-at-once” implementations are sometimes unavoidable — as in the case of a completely indivisible technology, this is usually not the case for technologies embedded in software.5

In this article, we present a strategy for guiding the implementation of advanced software technologies based on the principle of results-driven incrementalism (RDI). The inspiration for this strategy arose from observations of the problems experienced during traditional software implementations at New World Electronics and elsewhere.6 The strategy we describe bears little resemblance to the gradual pace and deemphasis on specific results commonly associated with incremental approaches.7 Rather, it specifies that a project be divided into a series of short, intensive cycles of implementation, each of which delivers a measurable business benefit. We have found that the RDI approach promotes organizational learning, maintains implementation focus and momentum, and negates the common tendency to overengineer technology solutions — all of which serve to substantially speed the realization of business benefits and reduce the risk of implementation failure.

Innovation researchers and software methodologists alike have long advocated incremental approaches to technology implementation (at least in the right circumstances), and we believe most managers accept the wisdom of incrementalism in the abstract. Yet it is rarely practiced on actual projects. We think this happens for many reasons: managers may not understand what incrementalism really means or how to use it, they may view it as providing marginal value, or they may believe it is infeasible in their specific case. Aside from presenting the RDI methodology itself, this article provides specific guidance on how to counter these kinds of inhibitors.

We begin by addressing why an explicit process model is needed to manage the implementation of advanced software packages and then present the main elements of an RDI strategy. We then describe a specific application of the strategy during the implementation of supply-chain planning and scheduling software at Herman Miller, a large manufacturer of office furniture systems. This example serves as a concrete illustration of the method itself and its typical challenges and benefits.8 Finally, we discuss two key issues raised by the specifics of the implementation at Herman Miller and elsewhere: (1) why the methodology is so often resisted, and (2) which factors are critical to achieving success with the methodology.

Evolving Nature of Software Implementation

Two elements still characterize many software package implementation projects despite being increasingly out of step with organizational realities. The first element is a narrow focus on the functions of the software itself, in which the goal of implementation is viewed as a straightforward delivery to the user population of some particular set of software functionalities. The second element is a penchant for all-at-once delivery scenarios, in which the implementation team conducts its work off-line, often for a year or more, and then endeavors to put the entire software configuration into use at once.

In years past, software packages tended to incorporate more rigid assumptions about organizational structures and processes. However, in recent years, all this has changed. No longer a tool to simply automate and speed up current ways of working, advanced software is now seen as a means to enable fundamentally new policies and work organizations.9 A consequence of this conceptual shift has been to complicate the task of software-package implementation teams. Never an easy task, software implementation has now taken on more of the character of technological process innovation (sometimes revolutionary, other times evolutionary) — with the attendant risks and challenges of such initiatives.

Many have noted that the implementation of technological process innovations inevitably involves learning and adjustment costs, the magnitude of which often exceeds the raw purchase cost of the technology itself.10 These innovations can rarely be implemented “as is,” so to achieve desired results, adopters must engage in cycles of adaptation when the technology and organization are fit to one another.11 The software configuration challenge consists of a process in which implementers develop an understanding of the software itself and the organizational design options enabled by it, after which they strive to actually configure, deliver, and continuously evolve the software and corresponding organizational changes.

It is easy to understand how organizations might systematically underrate the magnitude of this challenge. Many organizations turn to packaged solutions in the first place because of the not unreasonable belief that the difficulties associated with software development and implementation have been “packaged up” by the software vendor. Ironically, as software packages have become more sophisticated and flexible, the act of configuring and implementing the software has begun to assume some of the complexity formerly associated with developing a customized system. Advanced software packages typically provide hundreds or thousands of discrete features and data items that may or may not be used, and when used, can behave in multiple ways. Technical writers and implementation consultants can describe these features outside the organizational context, and they might be able to summarize a few standard or typical configurations. However, they cannot anticipate —from the seemingly infinite number of possible combinations — the most effective configuration to achieve particular results, and they cannot anticipate how any given configuration will interact within a particular organizational context. As a result, organizations implementing advanced software packages need an effective model that guides the process of discovering and implementing an effective initial software configuration.

Software Implementation Strategies

One of the authors, Scott Moses, and other implementation consultants developed the RDI strategy after observing the pitfalls of more traditional functionality-driven, all-at-once implementations. (For the traditional implementation strategy, see Figure 1.) The traditional approach not only delays the achievement of business benefits until the end of the project, but has other important pitfalls as well. It allows and, in fact, encourages implementers to focus on the technology itself instead of on the corresponding organizational changes required to actually derive value from implemented functions. In addition, the absence of clear linkages to business value invites overengineering, that is, implementing functions that may never be used or adding excessive details that are not necessary to attain the desired business results. Overengineering obviously wastes resources, but perhaps more importantly, it produces a proliferation of complexity as team members must figure out how each feature works and anticipate how it interacts with other software features and with the policies and procedures of the adopting organization. As an operations vice president at Herman Miller put it:

“When the difference between where you are going and where you are now is great, it is painful for the production floor. If it gets out on the floor and people choke, they will say: ‘We can’t get orders out to customers. Turn it off.’ Usually they are choking on something that people who designed and implemented the system hadn’t anticipated.”

The RDI strategy stands in stark contrast to the traditional approach because targeted business results drive the entire implementation process, that is, articulation of goals, tactical decision making during implementation, and evaluation of project outcomes during and after implementation. Implementers devise a plan that divides system delivery into a series of short (i.e., two- to three-month) increments, each of which delivers a combination of software functionality and organizational change. They define each increment so that intended business results will be achievable, even if no further increments are completed. (This requires that the underlying technology possesses at least moderate divisibility, which is true of most software technologies.12) For each delivery increment, they define specific measures to gauge improvements in business performance. These measures guide operational decisions throughout implementation depending on how they affect the targeted improvements. (See the RDI approach to software implementation contrasted with the traditional approach in Figure 2.)

The most obvious advantage of the RDI approach —one shared by incremental approaches in general — is simply that the stream of business gains is realized much sooner (see area A in Figure 2). However, implementers following the RDI approach report that it not only speeds the achievement of some benefit, but dramatically shortens the time to complete the entire initial implementation and increases the overall level of project benefits. These additional benefits (see area B in Figure 2) arise from combining incrementalism with a strong focus on business results — a combination that has startlingly positive effects on organizational learning and implementation momentum.

We now present some specifics of a methodology that achieves a harmonious pairing of these two elements and then describe how Herman Miller, a manufacturer of office furniture systems, used this methodology to guide a major implementation of manufacturing software.

RDI Methodology

Before employing the RDI approach on actual projects, implementers must tailor a step-by-step procedure, or methodology, to the specifics of the technology to be implemented. In this section, we describe an RDI methodology developed to guide the implementation of supply-chain planning and scheduling software.

The RDI methodology incorporates five key principles:

1. Use targeted business results to drive decision making throughout the implementation process.
2. Divide the implementation into a series of non-overlapping increments, each of which enables measurable business improvements even if no further increments are implemented.
3. Ensure that each increment implements everything required to produce desired results, that is, software functionality and complementary changes to organizational policies, processes, structures, and measures.
4. Size the increments so that each can be implemented in a short time (ideally three months or less).
5. Use the results of each increment as a basis to flesh out and adjust the plan for subsequent increments.

In the RDI methodology, the incremental segments of an implementation are referred to as business releases. This term derives from the idea that, just as software vendors will typically deliver packages to the market as a series of software releases, an implementation of software at a particular customer site may be viewed as a series of “releases” of software-enabled business results. Each business release consists of an integrated set of software functionality and organizational change that enables a specific, measurable business improvement in some key performance indicator (KPI). Typical KPIs for sites implementing supply-chain planning software include due-date performance, planning cycle times, order lead times, throughput, and inventory (raw, work-in-progress, and finished).

Business releases are short and do not overlap. A typical time frame appropriate for supply-chain planning software is two or three months, although this may vary depending on the nature of the software being implemented. Some organizations may be tempted to pack most of the implementation into one release or to compensate for delays on a current release by concurrently initiating the next one. However, long or overlapping segments defeat the purpose of the methodology. Long segments invite the same problems that accompany all-at-once implementations; overlapping segments work against the goal of providing isolated, cumulative episodes of learning.

The methodology begins with a business analysis that defines the contents of the first few business releases. In the business-analysis step, the project team seeks to answer the following questions: Which KPIs should be targeted? Which key constraints limit each KPI? What are the software functionalities and corresponding organizational changes that would improve each KPI? How much improvement is possible? The result is a description of each business release, which should cover the following elements:

• The targeted business result (e.g., improved due-date performance)
• A list of software functionalities to be implemented (e.g., automated capacity optimization)
• A list of complementary changes to organizational policies, procedures, measures, and structure (e.g., revision of the relative priorities on due-date performance versus machine use)
• A metric for measurement of business results (e.g., on-time order percentage)

The team uses a template to capture the high-level contents of each business release (see Figure 3). The various implementations at Herman Miller each required four to six business releases; this has been typical of RDI implementations in general. The business-analysis step identifies the first few business releases at a high level and defines the first business release in detail. The details of subsequent releases are defined in “just-in time” fashion following completion of the previous release.

An important consideration in devising the contents of each business release is the expected sequence of implementation. The ideal sequence promotes multiple objectives: (1) it starts in an area where conditions are most favorable to success; (2) it provides for a pattern of experimentation and learning that is most cumulative; and (3) it addresses opportunities with the highest potential payoff earlier rather than later. Naturally, these objectives will often be in conflict, thus requiring trade-offs based on management priorities at the site.

Following the business analysis, the implementation team begins the process of completing the specified business releases. When a work group is using the software functionalities in actual production, organizational changes have occurred, and measurement of results has begun, the release is finished. All three elements are essential. Without production use, implementation has not truly occurred; without complementary organizational changes, the software is (at best) automating outmoded practices; without measuring results, objective evaluation is not possible.

After completing each business release, the project team performs a number of activities: it reviews the results of the business-analysis step for validity, it defines the content of the next business release in detail, and it adds a new business release to the queue to maintain a rolling set of business releases. In this way, the methodology achieves the goal of maintaining an overall plan while providing for the incorporation of new information as the implementation unfolds.

Implementation Process at Herman Miller

To further illustrate the RDI approach and its potential benefits, we describe the application of this methodology at Herman Miller, Inc. The second largest office furniture manufacturer in the United States, the company processes more than 3,000 customer orders per week. Approximately 80 percent of the company’s business is project-based, and fulfilling orders requires complex coordination among multiple raw materials and assembly plants. It is not unusual for a single order to involve five different plants. The product lines have many options with large swings in product mix.

In the mid-1990s, when Herman Miller first began looking for planning and scheduling software, the company had been facing an increasingly competitive business environment. Expected order cycle times had dropped from twelve to four weeks, and discounting was on the rise. Policies and operating procedures that had been adequate in the past were now causing deteriorating due-date performance and excessive cost of goods sold. Batch processing of orders led to loss of customer identity in production — managers could not see the impact of changes or disruptions on one order or on all orders together. As a result, it was not unusual for late availability of a small component to cause hundreds of thousands of dollars’ worth of production to sit in inventory. Consolidation of orders in distribution centers before shipment added to cycle-time delays and inventory costs.

In the end, the Herman Miller search team chose the planning and scheduling software package provided by i2 Technologies to address the above problems. Within two years, Herman Miller implemented the software at six sites.

When pitching the idea of using an RDI approach, implementation consultants found a receptive audience in key managers who had personally witnessed the pitfalls of functionality-driven, all-at-once implementations at Herman Miller and elsewhere. Nevertheless, several Herman Miller employees resisted using the methodology. An implementation project manager commented:

“The methodology differs from what most people are used to. The initial planning sessions can be very frustrating. People do not always want to think through their operational goals and opportunities. They want to jump right in and start configuring capabilities in the software. Staff feel uncomfortable thinking in terms of business goals rather than software capabilities. They feel safer thinking in terms of activities rather than in terms of achieving business results.”

Ultimately, managers favoring the methodology were able to persuade team members to reserve judgment until completion of the first incremental portion of the implementation. Positive results on this first increment swayed the resistors. An operations vice president remarked: “It’s like it created ‘draft’ — you know, how this happens in racing — it created draft and pulled people in.”

Implementation Results

The implementation at Herman Miller delivered new software capabilities, including retaining customer identity throughout the manufacturing process, use of constraint-based scheduling at the plant level, and global synchronization of all the plants involved with an order. (See Table 1 for a summary of the implementation at Herman Miller’s chair plant.)

A striking element of the Herman Miller implementation was the willingness to embrace complementary process and policy changes. An implementation project manager commented:

“We’ve seen improvements in almost every key operational metric at Herman Miller. But I want to clarify that the results have been driven by major process and policy changes, as well as by the [software] implementation. Don’t ever think that just plugging in the software by itself will do it for you.”

These changes included radical modifications to their order-change and cancellation policies, discontinuation of certain product lines that were most responsible for excess raw materials inventory, changes in lot sizing and the consolidation of orders before shipping, and perhaps most importantly, changes in their whole philosophy of measurement. Before the implementation, Herman Miller had a measurement-averse culture, and those few performance measures that did exist conformed to such traditional objectives as maximizing machine use. Over the course of the implementation, the software enabled defining and implementing a new and pervasive set of measures. According to one implementation project manager:

“It’s been really interesting watching the change take place over the last couple of years. Before people wanted to celebrate good effort and were not as focused on the idea that good results are truly worthy of celebration.“

Having completed several implementations using the RDI methodology, Herman Miller has become a strong proponent of the approach. With the exception of one site where resistance to the methodology was particularly high, each site completed the first increment within six months and the entire implementation within a year. (At the site that resisted the methodology, implementation took eighteen months.) The full implementation across all six sites was completed on time and within budget. In terms of KPIs, Herman Miller reported achieving a 75 percent reduction in planning-cycle time, a 22 percent decrease in lead times, a 79 percent increase in inventory turns, and a decrease in missed due-dates from 30 percent to 1 percent.

Employees at Herman Miller attributed their positive software implementation experience to a large extent on the organizational learning and implementation momentum that the RDI methodology fostered. This emphasis on learning and momentum is consistent with prior research on technology implementation, organizational learning, and the management of task-focused teams.

Impact on Organizational Learning

As with complex technological innovations in general, the burden of organizational learning represents a fundamental challenge to the successful implementation of advanced software packages. With traditional approaches, crucial mechanisms for effective learning — those based on everyday use of the technology — are either absent or are deferred until a year or more into the implementation effort.

Organizational learning theorists have argued that effective learning tends to be incremental, intensive, immediate, and action-oriented. It is incremental because new knowledge is most easily absorbed when it can be layered on top of existing knowledge.13 It is intensive, because learning usually does not “take root” until concepts have been mastered, and intermittent, interrupted efforts rarely lead to such mastery.14 It is immediate, because learning is elusive when effects are separated from causes by space or time.15 It is action-oriented, because only through action do people build up the vast storehouses of tacit knowledge that form the foundation of any skilled performance — whether playing the violin or operating a transformed organization in the wake of a major software implementation.16 All these mechanisms are present in an RDI implementation.

One operations vice president remarked: “Business releases create a solid, concrete framework in which people must achieve certain results. Those targeted results then drive what they try to learn. You can show people examples, but I think that until you have affected their work directly you get the reaction: ‘Well, that’s really interesting.’ But after these people actually started to see that they were shipping orders and that product was flowing through the plant better, we then had disciples. They were convinced.”

A large portion of the implementation effort consists not of physically configuring software functionality, but of learning which business-process options are enabled by the software tool. Typically, users do not truly understand advanced software until they have attempted to use it to solve real problems with live data. An implementation project manager said:

“It is easy to tell someone ‘You don’t need that inventory buffer.’ Many consultants have told them that they don’t need the buffers, but until they could see it for themselves, they were not willing to make the change.”

The individual increments of the RDI methodology provide recurring episodes of organizational learning. Each increment also lays a foundation of knowledge for subsequent increments and often results in identifying alternative approaches that may alter the direction of remaining increments for the better. Traditional implementations, by contrast, attempt to aggregate all hands-on learning into a single, massive delivery cycle. As a result, all the inevitable bugs and mismatches between the technology and the organization that were accumulated during the off-line portion of the process are encountered simultaneously.17 Traditional implementations can therefore be likened to a medical study in which many different treatments are applied to subjects at the same time.18 The RDI approach, by contrast, can be likened to a series of single medical treatments, in which the result of each treatment is evaluated separately. According to an implementation project manager:

“It allows key concepts to be tested in isolation. You’re talking about specific actions that you believe will achieve specific results. They won’t get lost in all of the other things that are happening at the same time [in a traditional implementation].”

In summary, the RDI methodology (and the RDI strategies more generally) provide the following learning-related benefits:

• The use of multiple increments provides an expected sequence of learning and divides learning into discrete, manageable segments.
• The explicit performance targets help the implementation team determine which learning is relevant (i.e., which features of the technology and organization must be investigated) and thereby reduces the tendency to overengineer the solution.
• Direct observation of results occurs regularly and soon after the actions that produced the results.
• The implementation team intensively learns what they need to know about each increment due to the short time frame for each increment.
• The completion of each increment lays a foundation of knowledge for subsequent increments.

Impact on Focus and Momentum

As any project manager (or participant) knows, the intensity of effort on a project increases as the deadline approaches. Informally, this is called the “deadline effect.” Conversely, when slack time exists in a schedule, work usually will expand to fill the available time rather than the project or task being completed early (Parkinson’s law). A recent simulation study by IBM shows that when reasonable assumptions are made about the magnitudes of the deadline effect and Parkinson’s law, teams of software developers will exhibit similar levels of schedule conformance on a particular task when given the same milestone dates — even when the teams differ significantly in terms of staff productivity.19 Similar ideas run through Gersick’s classic study of the effect of time awareness on group behavior.20 Specifically, she found that task-focused teams exhibited bursts of energy and progress at the approach of two temporal milestones — at the completion date of a project and, more interestingly, at a point precisely halfway through a project. In between, project teams exhibited periods of inertia characterized by sporadic, unfocused effort. She concluded that a team’s progress is triggered “more by an awareness of time and deadlines than by completion of an absolute amount of work in a specific developmental stage.” These studies suggest that timing and the nature of temporal milestones may be as important in terms of maintaining implementation progress as the absolute magnitude of staff resources devoted to the effort.

The RDI methodology calls for a schedule of concrete milestones at two- or three-month intervals, namely, the deadlines for delivery of each increment. Care must be taken to ensure that the amount of work to be done during each increment can be accomplished within the given time frame. Just as allowing too much slack time invites wasting of resources, schedules that are too aggressive invite cutting corners and other counterproductive measures. An unexpected result of using the RDI approach is the positive effect the business-release deadlines had on implementation focus and momentum. Periods of inertia that characterize typical projects simply did not occur. An implementation project manager remarked:

“In the past at Herman Miller, I have seen people mentally ‘check-out.’ They continue to show up every day. They show up at meetings, but they have mentally and emotionally checked out. They are not working to drive change any more. That’s what I’ve seen in the past, but we didn’t see it this time, because people were getting a sense that this project was moving. Because people feel the results so much more quickly and so much more often, they don’t fall into a lull partway through the implementation when it feels like nothing is happening. It really does help to keep the focus.”

In addition, the short duration of each business-release increment promoted voluntary “scope control” by all team members. Furthermore, the methodology empowered the project manager to resist outside influences to expand the scope of a business release. She commented:

“This has been really key for me as a project manager. The more people find out about the software the more excited they get about the different capabilities, which are all very tempting. But I refer to the business release and ask: ‘Does this have anything to do with decreasing raw material inventory?’ That’s what we are focusing on right now. What you’re asking for is probably tied to one of the business results that we’ll pursue in a later step.”

The traditional approach to software implementation, of course, may also include intermediate milestone dates for the completion of project tasks, and these may be of short duration. However, these milestones tend to be abstract, task-oriented deadlines designed to suit management’s control objectives. While better than having no checkpoints, such milestones do not serve the same psychological function as completion of an implementation increment. Traditional implementation milestones do not provide a concrete target to shoot for, they do not provide immediate feedback on results, and they do not encourage the team to seek the most efficacious means to achieving given ends. Part of the problem is that the milestone dates on a traditional project are too open to interpretation. A manager remarked:

“On a traditional implementation, the goal is defined by some sort of functionality, and when you are talking about functionality, it is easy for people to twist the scope.”

In addition, the team understands that the most relevant milestone date is the one at the end of the implementation, when the software is scheduled for delivery to users. If this date is met, no one will likely care if intermediate milestone dates were missed. When using an RDI implementation, by contrast, all milestones call for the delivery of a tangible result, namely, putting some portion of the software system into everyday use and tracking progress toward the realization of targeted business benefits. As a result, the first delivery milestone counts as much as the last one. And, unlike the abstract milestones in a traditional project, the intermediate business-release completions in an RDI implementation represent tangible accomplishments, permitting observation of the new technologies in action. This often serves to recharge energy levels and build momentum for the work ahead.

To summarize, RDI strategies provide the following benefits related to maintaining implementation momentum:

• Multiple, concrete deadlines with short time frames avoid periods of inertia that afflict traditional projects.
• Using business results as the driver allows the team to control the scope and resist “scope creep” (i.e., expansion of project mission) originating outside the team.
• The prompt, recurrent achievement of visible results promotes confidence and feelings of accomplishment that energize the implementation team.

Other Favorable Factors

While Herman Miller implementers saw the RDI methodology as a primary contributor to overall project success, there were several other favorable elements. The company was facing a genuine crisis of competitiveness in the marketplace, thus leading to a general willingness to embrace change. With the full support of top managers, the company employed a small team of implementers dedicated full-time to the project rather than having a larger staff of part-time implementers. And perhaps most importantly, the team felt it was important to “own their own outcome” by taking the initiative in driving the implementation through, rather than relying on external consultants to set the direction and tone.

Even so, evidence from other sites spanning a wide variety of organizations and settings suggests the RDI methodology does not require the presence of all these favorable elements to be effective. An analysis of twenty-eight comparable software implementations initiated between May 1995 and December 1996 found that sites employing RDI reported a 40 percent shorter median time to initial benefits, a 50 percent shorter median time to project completion, and twice as many business goals achieved within eighteen months of project initiation (see Table 2).21 No site that used RDI experienced implementation failure, an event that occurs occasionally under the traditional approach.

Examining Resistance

As just described, the RDI approach to software implementation has many potential benefits. Nevertheless, consultants employing the RDI approach have found that although the approach appeals to most executives, implementers often resist it. Even at Herman Miller — the first company to use the methodology and now one of the approach’s strongest advocates — considerable resistance existed among project team members.

We observed five reasons for this resistance. The first stems from the results orientation of the approach. Often team members are not comfortable with the idea of having to define — and then being held to —specific, measurable goals. Instead, they would rather be judged on the more straightforward process of delivering functionality. Being measured on functionality limits team accountability to activities under the team’s direct control.

The second cause of resistance is that incremental implementation historically has been associated with a gradual, deliberate pace of change. Therefore, to many, the notion of rapid incrementalism, as called for in the RDI approach, seems paradoxical. In fact, more frequent feedback creates momentum and learning that positively effects the overall rate of implementation.

A third common source of resistance is the mistaken belief that full implementation can be achieved quickly and easily. If the entire implementation can be completed in six months, this argument goes, why bother with the task of defining multiple implementation segments?

The fourth reason is that an incremental approach often requires the development of work-arounds destined to be discarded in later increments. These work-arounds take the form of “throw-away” interfaces to existing information systems as well as interim organizational policies and procedures. Despite the low cost of these work-arounds when compared to the cost of managing the additional complexity of an all-at-once implementation approach, work-arounds are more directly observable and therefore seem wasteful.

A fifth reason for resistance is fear that the use of multiple increments may increase the chance of a mid-project termination, either because the intermediate results have been disappointing or because intermediate completions provide a discrete opportunity for project resources to be deployed elsewhere. This is not an unreasonable fear. Incremental implementations do allow an organization to discover an implementation is in trouble much sooner — in fact, this may be viewed as an additional benefit of the approach from the perspective of senior managers. (In contrast, by the time an all-at-once implementation is clearly in trouble, a year or more may have elapsed.) A project team may view early problem detection differently, preferring a scenario in which they have more time to get a project back on track before provoking the scrutiny of senior management.

Overcoming Resistance

Much of the accumulated wisdom for overcoming resistance to change also applies to RDI. This includes enlisting top management support, educating stakeholders about the methodology and its benefits, providing concrete examples of successful applications of the methodology, and setting up a trial application of the methodology in a favorable setting. At Herman Miller, for example, “buy in” for the approach was only accomplished after a senior manager asked key stakeholders to suspend judgment till completion of the first business-release increment.

Also, the specific reasons the method is often resisted suggest additional tactics to promote its acceptance. For example, a cost-benefit analysis may put in perspective the development of temporary work-arounds by offsetting their expenditures with the benefit of quicker implementation or reduced risk of failure. Resistance arising from fear of premature project cancellation can be countered by working with stakeholders in advance to define appropriate governance mechanisms for the project. This should include contracting up front for mutually agreeable decision rules in the event of problems and setbacks. In addition, a steering committee can be charged with making decisions about the project along the way.

Critical Success Factors

Aside from the obvious requirement that managers must overcome resistance and ensure faithful adoption of the methodology, three additional factors are critical to ensuring success with the RDI approach.

1. Technology Divisibility

First and foremost, the RDI implementation strategy requires divisibility of the technology itself. Divisibility is crucial because it allows a special sort of incrementalism, in which each segment enables a measurable business result even if no further segments are implemented. Divisibility depends on the nature and design of software-package components and on the level of ingenuity that managers bring to bear on how the components are selected and sequenced for implementation. Therefore, before committing to an RDI approach, managers must carefully evaluate the divisibility of a software technology (e.g., how granular are the components and to what extent are the product components designed to accommodate “stand alone” operation) and then assess alternative approaches to implementation sequencing allowed by the technology.

We see divisibility as taking two alternative forms: one in which successive increments involve the same software modules but at different levels of detail and a second in which successive increments involve different modules. Supply-chain planning and scheduling products (and modeling or decision-support-style information systems more generally) naturally permit divisibility of the first sort, which might be likened to applying layers of paint to a canvas. The second sort of divisibility, which might be likened to slicing up pieces of a pie, may be a more natural approach for larger transaction-processing-style systems.

For other kinds of software, a hybrid approach might be feasible. In the case of groupware software such as Lotus Notes, for example, an organization might follow these steps for deployment: (1) use the software for workgroup calendaring and e-mail, (2) create databases with fairly static and standard information, (3) produce more specialized databases with dynamic information, (4) allow users to create their own databases, and (5) implement automated work-flow processes. In fact, Lotus Consulting has developed a methodology called the accelerated value method, which shares the basic principles of RDI.22

We feel that most technological innovations embedded in software — or those having a large software component — can be made at least moderately divisible by the project team, even in cases where divisibility has not been designed into the product from the start. Temporary work-arounds may be required, but the cost for these should be considered in relation to the total implementation cost. However, not all technologies possess the inherent potential for divisibility, because it is not always possible to decouple modules for serial implementation. This is sometimes the case for real-time or embedded software systems (such as air traffic control) where the smallest unit of coherent implementation exceeds the scope of an individual increment.

2. Technology and Methodology Fit

The second critical success factor is the technology’s suitability for the RDI methodology, which was designed specifically to address organizational learning and implementation momentum challenges. While these barriers are pervasive in the processes of technological innovation, they are not always the primary barriers. For some kinds of technologies, the predominant concerns may be: (1) barriers related to achieving a “critical mass” of users,23 (2) coordination of a large number of interrelated implementation elements,24 (3) dealing with indeterminacy about what the organization can or should accomplish with the technology,25 or (4) properly aligning incentives in the wake of the implementation.26 In such circumstances, it is possible that an RDI approach will be of lesser benefit, although further research is required to determine the extent to which this is true.

3. Technology and Organization Fit

A third critical success factor is that the software technology and the adopting organization’s needs and characteristics must be a good fit. Leonard-Barton has noted that the “misalignments” that inevitably exist between a technology and a target organization can be large or small, requiring correspondingly large or small cycles of adaptation to resolve.27 We believe that the RDI strategy can be viewed as a way to rationalize and manage a series of small cycles of adaptation. However, if there are large misalignments — for example, that require a change to the core features of the technology or a major organizational restructuring —the approach will be less appropriate. In this case, a large cycle of adaptation will be needed, which will involve a time horizon and degree of unpredictability that obviate use of short, well-defined increments. Nevertheless, once the misalignment has been addressed, it may then be possible to use the RDI approach on the remainder of the implementation.

Suitability for Enterprise Resource Planning.

We have been asked whether this methodology can be applied to enterprise resource planning (ERP) offerings from vendors like SAP, PeopleSoft, or BaaN. We believe that except for the instance of a small company implementing a fairly well-understood module, the answer will usually be no. The componentization of these packages occurs mostly at the level of broad functional modules — human resources, financials, inventory management, production planning — and these modules, intended as they are to support entire business functions, are usually too large to be implemented in a single increment spanning two to three months. Because each module has not been designed as a combination of separable components suitable for serial implementation, the cost and complexity of establishing required intramodule interfaces and work-arounds would often exceed the benefit to be gained from incrementalism. Or in other words, the modules have not been designed to promote divisibility. Interestingly, the trend in these packages is towards finer granularity in the componentization of modules, so in the future, this barrier to using an RDI approach may disappear.

Conclusions

The trend toward ever increasing flexibility and sophistication in packaged software has magnified the challenges facing software implementation teams. A favorable set of project factors (top management support, appropriate staffing and training, etc.), while important, is insufficient to ensure project success. Organizations also need an effective implementation process for managing the journey of innovation and change that increasingly accompanies the deployment of advanced software. We have described one such approach, an RDI strategy for software-package implementation. By dividing implementation into a series of self-contained segments, each designed to achieve a specific business result, this approach counters the scope creep and overengineering that so often accompany traditional implementations. In addition, the approach acts as a focusing device that promotes organizational learning and maintains implementation momentum. The use of multiple increments with short horizons provides an expected sequence of learning, divides learning into manageable segments, and permits observing outcomes soon after instituting the actions that produced them. The prompt, recurring achievement of visible results repeatedly motivates members of the implementation team.

The typical view of technology holds that it is defined by its technical features — the “technology as designed.” We take an alternative view: a technology is bounded by its technical features along with the configurations in which it is typically delivered and used — the “technology in use.” While the technology as designed defines the range of possible uses of the technology, it is the technology in use that determines the immediate value to the individual customers and perhaps more importantly, determines the extent to which the technology succeeds in accumulating a critical mass of committed users.28 Designing an effective software delivery process is not easy. It requires an ongoing effort to develop systematic implementation processes, to measure customer outcomes, to document process variants for different customer situations, and to build more implementability into a product from the start (e.g., by increasing divisibility). It also requires an education and marketing effort to encourage implementers to adopt the methodology.

Determining the most effective delivery processes for a particular technology requires ongoing R&D by someone. It can be done by third-party consultants, although there is no guarantee they will choose to assume the task of defining a methodology tailored to a given product or that they will bring the degree of individual attention to the process that the product might require. It can be done by end users, but most end users are constrained by a sample size of only one. Or R&D can be done by the primary vendors themselves. We suggest that most technology vendors would be well served to view effective implementation processes as a crucial element of success and to manage investigation in this area as they would any other key area of R&D.