When ERP methodologies go wrong
October 25, 2010 15 Comments
Webster defines a methodology as a body of methods, rules, and postulates employed by a discipline: a particular procedure or set of procedures. Methodologies add tremendous value to the implementation team by providing a process to guide the team through the implementation. Methodologies have inherent assumptions, risks, and constraints. For an ERP implementation multiple methodologies are involved.
Now I believe that methodologies are not the issue; it’s how they are applied that is the issue. Following are typical problems I’ve observed with applying a methodology to an ERP implementation:
- Try to use one methodology for all disciplines.
- Execute methodologies in silos.
- No taking into consideration the inherent advantages and challenges associated with a methodology.
With several methodologies for each discipline to choose from the question becomes “Which one should I choose?” Following is a list of the key factors you should consider as part of your methodology selection.
Factor: Size of the implementation
What is the size of the ERP implementation? When considering size we need to look not only at the financial perspective (cost) but also from an organizational perspective (users impacted).
Factor: Personnel Capabilities
A methodology is only as good as the people using the methodology. It is very important that the people on the project team (Business, internal IT, Implementation Partner) have the necessary abilities and training to successfully apply a selected methodology to an ERP implementation.
What are the risk(s) associated with the ERP implementation? How risk-tolerant is the customer? Does the customer have experience with ERP implementations? If there is a high level of risk associated with the ERP implementation then you may want to select a methodology that is more risk-adverse (ex. iterative).
Factor: Business IT Relationship and Culture
The customer should perform a realistic assessment of the relationship between the business and the internal IT organization. If the relationship does not foster effective collaboration or there is a known alignment challenge then an iterative approach should be considered.
Iterations provide a dramatic increase in feedback over sequential software development, thus providing much broader communication between customers/users, and developers.
Factor: Business Model Dynamic
The more dynamic a business model is the greater opportunity for evolving requirements. A dynamic business model requires a method that is rapid and flexible. Traditional approaches that focus on a reasonable stable set of requirements may not be the best choice for this environment.
Factor: Assumptions for a Methodology
As stated earlier every methodology is based upon an “environment”. It is very important that you understand the basis for the methodology as well as determine the assumptions made. Making an objective evaluation of the methodology will determine its advantages, challenges, and assumptions made.
The first step of effectively using the required methodologies for an ERP implementation is first understanding the methodology integrations.
The second step is to consider the key environmental needs that the methodologies must support. Implementation size, personnel capabilities, risks, and relationships are factors that will have a material impact on how successful a methodology can be applied to an ERP project. In addition, Implementation Partners should be able to support multiple methodologies in order to provide the best approach for the customer‘s unique implementation.