When ERP methodologies go wrong

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.

Methods, Disciplines required for ERP implementations
Disciplines for ERP projects

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:

  1. Try to use one methodology for all disciplines.
  2. Execute methodologies in silos.
  3. 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. 


The first step of effectively using the required methodologies for an ERP implementation is first understanding the methodology integrations.

Methodology integrations for ERP projects
ERP Methods

 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!






18 responses to “When ERP methodologies go wrong”

  1. Wanda Burgamy Avatar
    Wanda Burgamy

    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.

    1. Brett Beaubouef Avatar

      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.

  2. Nigel Rushby Avatar
    Nigel Rushby

    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.

    1. Brett Beaubouef Avatar

      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?

  3. Nisha Avatar

    Very well said Brett!!! Nice piece of document

  4. […] the success of a business solution.  Funny how it is interesting to note that the majority of ERP implementations mostly focus on products and technology.  Let’s dig a little deeper and spend some time speaking about each business solution […]

  5. […] have observed two areas that slow down ERP/COTS implementations: customizations and evolving requirements (even with a predefined scope). From my experience my […]

  6. […] for gathering ERP requirements.  However, the challenges I see today are due to how project teams apply requirements gathering strategies to their ERP implementations.  Project teams typically confine themselves to only one approach and do not account for the […]

  7. Richard Chege Avatar
    Richard Chege

    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

  8. […] is important to note that Cloud ERP is only one component of a business solution.  There are still multiple disciples required for a Cloud ERP implementation – especially organizational change management.  Cloud ERP […]

  9. […] Approach section details the viable methods available to implement the solution.  The approach section should not be a theoretically […]

  10. […] Bron : ERP the Right Way! Lees meer… […]

  11. […] allow me to state that the above methods are valid and have their inherent advantages and disadvantages.  The challenge I observe is that is there is limited effort spent on understanding how the […]

  12. […] how BPR, BPM, and ERP should relate to one another can be a challenge.  Some believe that it is an “either or” proposition.  I do not subscribe […]

  13. […] often I see project managers jump into the details (WBS, Risks, Issues, CPI, SPI, Cost) without first understanding the context.  You cannot be […]

  14. […] we take a stroll down memory lane we can recall the standard testing approach we learned from the Waterfall Software Development Lifecycle […]

  15. […] implementation of a business solution requires multiple methodologies to be employed (project management, software development, organizational change management, business […]

  16. […] we take a stroll down memory lane we can recall the standard testing approach we learned from the Waterfall Software Development Lifecycle […]

Leave a Reply

%d bloggers like this: