Do Not Pass Go…Before Setting Yourself up for ERP Project Success
The world is rife with ERP how-to books and launch checklists, many written by consultants, software companies, or implementation service providers. While I don’t aim to discredit the value of any of these tools, I am always reminded of something my father used to say: “Ask the man who owns one.” While I never knew the origin of this line as a kid, I certainly understood the intent. It turns out, by the way, that this phrase originated in 1900 when J.W. Packard replied to a spectator at an auto show who asked “Is the Packard car a good one?” They went on to build an entire ad campaign on his one line response.
Having been responsible for delivering a number of large-scale ERP projects, some very successful and some not so, I have certainly been in the trenches as it relates to first-hand experiences – the “man who owns one.” My opportunities to observe the full project lifecycle have also enabled me to see the common themes and elements that set a company up for success or failure prior to kick-off and more importantly prior to making any financial investment.
Ten Signs You Are Set up for Success
1. Full business alignment on project ownership and roles
I’m certainly not the first to state that an ERP implementation is not an IT project. The problem is that these are often empty words with weak support. I’ve been there. The CEO will address the company waving the “we’re all in this together” flag, only to turn around at the boardroom table and identify it as an IT initiative to the rest of the executive team. They, more than anyone, need to see it as a business-driven undertaking. Ensure clear project ownership and role definitions exist and that people truly believe in both.
2. A dedicated team of empowered, and back-filled, experts
Do you know how to be sure you have identified the right project team members? When the C-level executives state that you cannot possibly have “insert name here” because “we have a business to run” and “we couldn’t possible back-fill their skill set.” Bingo! That sounds like a skilled, empowered, and respected individual who can make solid decisions on the fly without spending valuable days seeking approval and second-guessing the organization’s ability to adapt to change.
Now you’ve got the best person, but what about their current function? Do not move forward until your entire project team is fully back-filled with trained replacements and an organizational design plan exists for both team members and back-fills upon project go-live. Delay the start if necessary, but don’t try and manage the impossible situation of people trying to perform two jobs; you can’t dance at two weddings with one “behind.”
3. Full executive and board-level support
An ERP implementation is a major transformational project that will impact the entire business and nearly every employee. Having senior-level leadership questioning the importance, doubting the success, or having their own agendas is a showstopper. A large-scale ERP project will test the mettle of the most seasoned CEO. If they can’t get people genuinely committed and aligned, sound the alarm bell and put on the breaks.
4. A clear and structured communication plan
“We’ll figure out the communication part as we go.” No! Keeping the entire organization involved, aware, and excited about what is coming is critical. It they’re not bought-in during the configuration and training phases, odds are they won’t be committed when you throw the switch at go-live. ERP systems are very complex interconnected systems. It doesn’t take too many non-believers to sabotage a well-orchestrated plan. Ensure that your communication design is structured at all levels: board, CEO, management, team leads, and employees. Each should have their own level of focus.
5. Dedicated change manager(s)
I have been involved in projects with and without full-time change managers and I can tell you that you can minimize your pain and increase your odds of success greatly by getting this role in place prior to beginning the project. An experienced change manager is well worth the investment. They can anticipate issues within the business, help to formulate the communication strategy, facilitate difficult decisions and most importantly, calm executives’ fears and concerns about business acceptance.
6. A short project timeframe
When many people lay out large-scale ERP project plans they have visions of grandeur around what they, the project team, and the company are able to accomplish. A big-bang launch of every module across multiple business units in different countries? It sounds too good to be true because it is, no matter what the software vendor or implementation partner promise you. Unless you are a company with very mature processes and deep support for the project across every single function, this is a recipe for failure. The real goal should be to just get live. Pick your easiest areas, simplest and most sound processes, best functioning plants, whatever it is – just get live. Putting the anxiety of an initial launch behind you will allow the company to ease into the substantial amount of transformation gently. There will be lots of time to tweak and improve moving forward.
Projects that drag on and on lose momentum deflate team members, increase the concerns of board members, and arm sceptical employees. If you can’t go live with some functionality within one year of kick-off, it’s time to rethink your plan.
7. Training, training, training
There is no such thing as too much training when it comes to an ERP launch, nor should it ever be a tacked on as an afterthought to the original plan. Good, well-thought-out training is critical to a successful launch. Not only does it equip people with the skills and knowledge they need to do their “new” jobs, it gives them the confidence they need to buy into, and support, the project.
It is only natural that people get uneasy given the typical magnitude of change that an organization needs to absorb. Successful ERP plans deal with this upfront, ensuring that people are aware and comfortable with the detailed plan to train them.
You should read this next line twice to ensure it sinks in: under no circumstances should anyone be given log-on credentials to a production ERP environment unless they are trained and can demonstrate competency with what is expected of them. Read that again.
8. A clearly defined scope and commitment to project change management; no scope creep
I don’t have statistics to back this up, but I would wager that the number-one reason for projects falling off the rails is due to a lack of understanding of project scope. This is often within the business units themselves where ignorance turns into awareness that turns into doubt and, ultimately, rejection. Usually this process leads to a demand for a change in scope to meet a business function that is perceived to be “different” or “more complex” than what the ERP product can deliver. I can say with great confidence and experience that nine times out of ten, these assumptions are not valid. If the majority of companies in your industry are able to operate with the core functionality supplied within the product, then you are too.
The second issue with scope is related to your implementation partner and sometimes the ERP vendor themselves. Do they really understand the scope they are agreeing to? Is it clearly documented in painful detail? Has everyone signed off on it? Do you have a legal position when, not if, they come back and say that you are demanding functionality that wasn’t part of the original scope? This will be an issue in both fixed-bid and time and materials engagements. Either way, a lack of clear understanding and disagreement on scope will lead to budget overages, extended timelines, and strained partner relationships.
9. A very strong project manager
Many people feel they can manage projects. The truth is, I have seen accomplished, well-seasoned project managers with all the necessary credentials after their names, fail in the face of a large-scale ERP initiative. I can also tell you, from experience, that changing a project manager midway through is less than desirable and bound to cost you substantially more money and time. Ensuring that you’ve got the best possible person prior to beginning is critical. How many projects of this size and type have they successfully managed? Do they understand your industry? Are they familiar with the corporate culture? Are they skilled at dealing with a third party, particularly when tensions are high? Are they comfortable standing up to senior executives when requests or demands are unreasonable?
10. Understand the corporate culture
Every company is different. Corporate cultures are driven by a long list of influences: senior leadership, geographic locations, industry type, market, size, public vs. private, involvement of founders, organizational structure, work environment, compensation model, etc. Clearly understanding a company’s culture is essential prior to spending money on a large-scale project. To what extend will the executives be involved? Does the culture support the typical demands of a large project: long hours, separation from coworkers, working weekends, and high levels of stress? Building a project plan around different cultures is not impossible, but will alter your approach and potentially your costs and timing.
Bottom Line: Maximize Your Odds of Success
Success is difficult to predict, but the more you can stack the odds in your favor, the more likely you are to deliver a quality project somewhere close to the original budget and timeline and with your sanity intact. The tendency is always to try and do more with less and to cut corners wherever possible. I would suggest that there are areas within an ERP implementation where you could take the minimal viable approach, however, these ten are not them. Make sure these are sound and you will certainly build the foundation for victory in a field with many casualties.
Want to Know More
Info-Tech has substantial research, blueprints, and expertise in the area of enterprise resource planning. There is no need to go it alone.