In a previous Sikich blog post, “Thinking About a New ERP? Top 5 Readiness Factors,” I concluded by suggesting that if you have successfully completed some key readiness challenges you would then be prepared to engage implementation partners to assist in the heavy lifting of an ERP project. I’d like to expand on that guidance in this post.
Few organizations have the ready resources, the “arms and legs,” available to implement an ERP system on their own. Knowledge and experience of such an endeavor may exist in a few people on staff but the preponderance of resources needed to execute the project will likely need to be acquired externally. Consulting partners such as Sikich can provide skilled staff during planning and execution, train your own staff to adopt process changes, provide post-deployment support, and move on if/when they are no longer required. In fact, the sign of a job well-done by a competent consulting partner is your firm’s ability to move on without them at the conclusion of a successful project.
Treating ERP Implementation like a Blueprint
During my first experience as a team member on an ERP project way back in my career, our leadership brought in a fellow named Tom DeMarco to help us get our minds around managing a large-scale software implementation. DeMarco told a story that has stuck with me for many years; that his father was a construction engineer who built bridges, buildings, and such but could not understand what his son did for a living. An ERP implementation is indeed a construction project with functional requirements, technical specifications, and a “blueprint” to guide construction and deployment. In my experience, the work required to develop this blueprint can constitute up to a third of the project’s total effort and cost and will set clear expectations for what the project is to deliver. And a failure to meet expectations is the primary reason many projects are viewed as failures.
Consulting partners know business processes and ERP applications just like architects and construction engineers know function, principles of construction and materials. And preconfigured solutions like HeadSTART from Sikich can provide a “prefabricated” framework to begin your blueprint. But to get something that better meets your functional requirements it’s very likely that you would want to choose “options” that will make your solution a better fit. Your consulting partners won’t immediately know what options you would choose to meet your businesses particular functional needs any more than an architect or construction engineer knows what a client requires in a bridge or a building before starting the job.
Defining the Scope of the ERP Project
So, once a consulting partner has been chosen, the first phase of an ERP project should consist of a joint process of discovery and scope definition. You might think you can complete the discovery and definition phases on your own without a consulting partner but the process and methodology the partner brings to the task are just as important as the final result. This is because the ERP system’s functional and technical specifications, and the conclusion relative to the software platform chosen, should be agreed to jointly by partner and client. And the documentation and the blueprint created during the discovery and definition phase will guide implementation and establish expectations for project success.
I’d like to highlight two key factors to consider regarding the discovery and definition phases of an ERP project.
It’s important to develop accurate use cases.
The first thing I would like to highlight is the importance of developing and documenting realistic and accurate use cases that represent your desired business processes. Well-conceived and documented use cases help define how system functions and people will be expected to work within the context of the new ERP environment. They provide a common frame of reference and expectation for how the new ERP system will handle specific situations and tasks, provide a means for demonstrating how different system functions will perform, and are the basis for functional specifications. Use cases will also help refine earlier documented business processes, identify and highlight which current processes are broken, and help to candidly evaluate processes established based on deficiencies in personal or current/ancillary system constraints.
I have been subjected to many software vendor “demos” in the past that were decoupled from meaningful business processes relevant to my business. Nothing can be less instructive or helpful. This is not always the fault of the vendor but is oftentimes the fault of the customer who is ill-prepared and has not yet gone deep enough in the discovery and definition phase. Help your suppliers and partners to help you by having good use cases developed early in the process.
Avoid budgeting the ERP Project before finishing defining the project scope.
Secondly, the temptation to fund and budget the entire ERP project prior to completion of the discovery and definition phase should be avoided. Estimating the entire cost of the project on a rough-order-of-magnitude (ROM) basis is clearly necessary for planning and financial place-holder purposes. But the accuracy of cost and time estimates for the development/configuration and deployment phases will be suspect without concise definition, use case analysis and specifications. Remember, the discovery and definition phase sets expectations for project success, and not just relative to function and capability but relative to project cost as well.
As Mary Poppins said, a job well begun is a job half done. Choose carefully and work with your implementation partner diligently, create a solid “blueprint” during discovery and definition, fund in phases and your ERP project will have a greater chance of meeting expectations.
Ready to talk with an experienced ERP project partner about your own ERP implementation? Please contact us at any time!
