Within the ERP industry, there is no common glossary of terms to describe various implementation processes, and there probably never will be. Most terms are marketing slogans coined by software vendors or consulting firms that imply their implementation methods are better than their competitor’s.
Over the years rapid deployment methodologies have evolved to address the age-old problems: ERP projects can take too long and cost too much. In its purest sense, rapid deployment focuses on compressing the project timeline by employing several project management strategies. While at times these strategies should be used when managing any ERP project, it is the degree and emphasis placed on them that sets rapid deployment apart from the more traditional approach.
Rapid Deployment Techniques
1. Cutting the project scope. This usually includes prohibiting (or severely limiting) any type of custom development such as software modifications, data conversions, and even interfaces. Furthermore, only implementing the software features and functions that are absolutely necessary to run the business. The concept is to later install the more advanced capabilities (that could actually be needed within the business today).
2. Skipping much of the discovery phase and jumping right into system design. Up-front activities such as formal project team software training, current process analysis / improvement opportunities, and maybe even prototyping are scaled back. The scope of project work is focused mainly on the activities directly related to getting the package up and running.
3. Expedite client decision-making and issue resolution processes.
4. Using pre-configured industry templates to drive the majority of the software set-up. The big assumption here is that companies within a particular industry operate (or should operate) more or less the same.
5. Utilizing a high concentration of software consulting resources (but planned for a short project timeline). The thought is when consultants do most of the project work this avoids “learning curve” delays that would otherwise result if the client fulfilled their typical project responsibilities.
6. Planning to address many of the known project issues after the initial system go-live.
Rapid Deployment Risks
Any methodology has its advantages and disadvantages. But rapid deployment can be appealing to many because the time and costs to implement the new system are always client hot buttons. However, if not careful, these fast track approaches may actually cost more and project benefits never materialize. Here are a few potential issues:
1. No ERP system is a turnkey solution. The myth that the software is “the” solution or all packages contain “best practices” is often the underlying assumption behind rapid deployment justification. In other words, there is a misguided belief that the software functionality will eventually deliver the “project quality”, even if we cut a few corners during the implementation.
2. Uninformed client decisions are worse than late client decisions. Since rapid deployment tends to result in less involvement of the client team, there is a much greater risk that clients will answer the consultant’s specific questions without a good understanding of what else the decision effects. Rework can be very costly and is as a project manager’s worst enemy.
3. At times, software modifications are easily justified from a business standpoint. While no one should encourage modifications, the alternative is to work-around major software limitations. Work-arounds can take more time to develop and compromise project benefits.
4. The client team does not understand how to use the software, let alone configure it. If the team does not understand the software, do not expect end-users to understand it either. With team training done mostly “on the fly” during the project (or really not done at all), this can result in a failure to leverage the software capabilities. Also, do not be surprised when expensive consultants are required for many years after go-live to make simple software set up changes required by the business.
5. Poor user acceptance of the system. Again, less client team and end-user involvement is often an unfortunate by-product of rapid deployment. This can lead to a system design that misses the mark or creates a let the system fail mentality within the user community.
6. With many software consultants working on the project, the hope is the implementation actually is faster. Otherwise, the project will cost a fortune.
7. A longer post go-live “shake out” period. At system go-live, it is usually not the “known system issues” that bring a business to its knees. Rather, it is the accumulation of many unknown issues that fell between the cracks. The additional consulting cost to address these issues on the backend of the project can really add up.
When to Use Rapid Deployment
Of course, this does not imply rapid deployment is never the right approach method. For example, potential candidates for rapid deployment included small-to-medium size organizations where there are only a few systems to replace or where business processes are mostly manual. Therefore, the automation of business processes or simply having one integrated system is considered a major leap forward from a business and end-user perspective.
Finally, lean toward rapid deployment in situations where the overriding business concern is to install the package as soon as possible. There are legitimate business reasons to implement a system quickly, but most tend to be strategic in nature (regulatory, customer compliance, etc.) and less based on immediate process improvements or a financial return on investment.
Looking for more info on ERP deployment?
You can find all of Business-Software.com’s exclusive content on ERP implementation tips, industry insights and product reviews by visiting our ERP resource center page. If you’re ready to begin comparing products, you can download our free Top 20 ERP Software report to find details on features, pricing options and deployment models of the leading ERP solutions.