One of the difficult decisions of an ERP implementation is the implementation strategy: do you take the big bang approach and get it done with quickly, or do you slowly phase in new processes and technology over time?

The answer is that it depends. The appeal of the big bang implementation strategy is that it focuses the organization for an intense and relatively shorter period of time than if the project were phased. This often helps address long-term resource shortages. It also condenses the pain and difficulty of an ERP project into a shorter period of time, although the pain is typically more pronounced using this approach.

The downside of the big bang implementation approach is that the project is often rushed, details are overlooked, and changes to business processes may not be the best ones for the organization. And, as mentioned above, the pain is often more severe due to the hectic nature of this approach. More often than not, my experience has been that projects that implement an overly aggressive big bang approach are more risky and result in less satisfaction with the system’s abilities to meet important business requirements.

The other end of the spectrum is to follow a slower, phased approach. This can either by functional business area or geography. The appeal here is that is allows project teams to take their time in the planning, customization, and testing of the system while continuing with day-to-day jobs.

The downsides are that these types of phased projects often lack the urgency and focus of a big bang project. It can also lead to “change fatigue,” which can cause employees to become burned out on constant change. Instead of getting the project over with in a shorter period of time, these projects involve constant change over longer periods, which can be draining to employees.

So which approach is the best? Both approaches have their clear pros and cons. At the end of the day, it is important to find a balance between both that works best for your organization. Implementation schedules need to be aggressive, but not to the extent that they cause you to overlook important details or make sub-par decisions. It is often helpful to do the project in multiple (but aggressive) phases to help focus the organization and create a sense of urgency.

Posts You May Like:

Rebuilding Trust After a Failed Software Project

Rebuilding Trust After a Failed Software Project

Failed software projects often disrupt operations and erode trust among employees, stakeholders, and clients. Rebuilding trust requires transparent communication, accountability, and a comprehensive recovery strategy. Transparent communication, employee engagement,...