Chicago Software Process Improvement Network
AT&T Center Campus
AT&T Institute 2501 W. Eagle Way at
Lakewood Blvd and Eagle Way, Hoffman Estates, IL 60192
Be sure to check the C-SPIN website (http://c-spin.net/) to confirm details.
Wednesday, May 6, 2009
6:00 - 7:00 PM – Atrium: Registration, Networking, & Light Refreshments
6:20 - 6:40 PM – Birds-of-a-Feather Topic - [To be announced prior to meeting]
7:00 - 8:30 PM – Auditorium: Presentation
8:30 - 9:00 PM – Auditorium: Additional Q&A and discussion
Program: Why ERP Projects Fail
Presenters: Jack Frano, PMP, Principle at Adaptive Growth, Inc.
Jon Fred, Adaptive Growth, Inc.
Abstract The failure rate of ERP projects is worrisomely high and persistent. The apparent causes of failure are widely and consistently reported, and tend to be classified into a few subjective categories that don’t lend themselves very well to the usual methods of practical risk management (e.g., what is a specific corrective measure for “inadequate top management involvement”?) We find that most of these commonly stated categories of ERP failure can be restated as some aspect of a general failure to meet users’ expectations for the project, which we find are often entirely undocumented, let alone stated as explicit, formal system requirements.
We use this observation as an opportunity to restate the general problem of ERP failure in terms of the question, how does it happen that system requirements are often not met in ERP projects? We find that productive, specific conclusions can be drawn when ERP failure is viewed in this light, which we then explore.
We find that the full set of requirements is nothing more or less than the set of all conditions which must be met for the project to be considered successful. Therefore, the full set of requirements must include every user expectation which, if not fulfilled, will cause the project to be viewed as unsuccessful. Often some (indeed, many) requirements go entirely unstated.
Often some requirements that are included in the formal project documentation are not stated in their original business terms. This excludes the requirements’ actual process owners from effective participation in the project, deprives the technical implementers of needed insight into what should be their true goals, obscures the measurement of actual progress achieved by the project team, and perverts the process of acceptance testing.
The solicitation of wish lists often passes for requirements gathering. This is a deplorable practice in many ways. It virtually demands a politicized competition for project resources. It destroys morale, because few of the wishes solicited will make it into the final system. It obscures most of the real conditions of success, especially the minimum conditions of success, which must fully express the company’s day to day operations in full detail.
Often, foreseeable future changes to the company’s operations are not considered when setting requirements. This happens most often when these future changes are seen as management’s strategic prerogatives, but system requirements are seen as having only a limited, tactical scope.
The project team will always work toward meeting some set of goals. When they aren’t working toward the true requirements by which their success will eventually be judged, they will be working toward hypothetical surrogates for these requirements. These alternative targets may well seem to be met, only for the eventual results to be rejected when the true conditions of success are finally applied at the end of the project. When implementers are not presented with a well defined set of true requirements that they agree to work toward, they will resort to an alternative set of surrogate requirements that they carry with them from one implementation project to the next. The user company’s management will often accept these surrogate requirements as not only valid but, indeed, as especially valuable, believing that they represent the distillation of practical business experience and technical know how. Implementation companies are not quick to argue with this view, for obvious reasons.
Of all the many reasons why the full set of requirements is often not embedded into the project plan, the most important are that (1) the project is deemed to start after the point where the gathering and embedding of actual requirements could have happened, (2) user company management buys into the misconception that the true requirements are technical or ERP-package-specific in nature and (3) user company management lacks faith in its ability to name its actual requirements. Of these three reasons, the second and third are easily overcome, but the first is a significant challenge to almost every ERP implementation.
After exploring these points, we present a sample case showing how requirements can be gathered and embedded within an ERP project for a hypothetical manufacturer. The details of this case would differ significantly for ERP projects in other types of organizations, but the underlying ideas should be clear enough to emulate.
About the Presenters
Driving and Parking Directions
From I-90 Northwest Tollway, exit North on Barrington Road. Take Barrington Road to Lakewood Blvd (2nd light) and turn East (right) onto Lakewood Blvd. Turn right into the AT&T Campus Center’s West Employee Entrance (the first entrance past Eagle Way) and follow the signs to the West Parking Structures.
Parking in covered lot W3 is recommended. Look for parking spaces near the west entrance/exit of parking structure W3. Then walk west from the parking structure to the Institute Building to the main door, which has a big ENTRANCE sign over the door. The Institute is approximately 100 yards from the parking structure--back across the road you came on. Visit http://www.c-spin.net for a map of the AT&T Campus Center. (Additional parking is available in covered lot W2 as well as upper level parking lot W1.)
C-SPIN is a leadership forum for the free and open exchange of software process improvement experiences and practical ideas. We promote achieving higher levels of process maturity, software quality, and mutual respect. Companies, academic institutions, government organizations, and individuals are invited. For more information regarding this meeting, C-SPIN or the steering committee, contact Karen Mermel at firstname.lastname@example.org.
To receive future announcements electronically, register your e-mail address (include name, personal email address, company, and phone number) http://c-spin.net/newsletter/