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.
Factor: Risk
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.
Summary
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.
Join the community! 10k followers across 100 countries!
First – I love the dynamics you demonstrate in the complexity of the implementation. You have captured the essence of the complexity of ERP. There are 3 distinct projects in play – that must be in sync but must also be managed independently as they are generally different interaction points. So that is great. The thing that would be good to show – is how that starts way back in the initiation – which is where I believe the failure begins. If you do not distinctly engage an implementation plan that is both stand-alone and integrated for those distinct swimlanes then you will have issues with ERP implementation. And you will not get the results you seek. I am going to ponder this and expand upon it – as you have captured somethign I believe is quite critical to success of any project – but most especially ERP projects.
Wanda – thank you for the response. It would be great if we could partner to elaborate on how to better initiate and interweave these different disciplines in an ERP implementation. Looking forward to your response.
Brett
I would agree on the general points that project team buy-in is more important than the actual methodology used, that’s not to say different methodologies do not suit different situations. If you have everyone ‘singing from the same hymn sheet’ this is vital for success to any project/work-stream/task.
regards
Nigel
Nigel – thank you for your feedback and insight. I totally agree with you that different methodologies suit different situations. What additional areas/factors do you analyze in order to select the right methodology?
Very well said Brett!!! Nice piece of document
Great article. I’m busy with the deployment of an Integrated Public Debt Management System which integrates SWIFT payment instructions to banks. I’d like to enquire from the bloggers whether anyone has done SWIFT integration before and which is the best option to switch over; parallel running with the old system (non-swift) or Big bang. My email: mwithukia@gmail.com