Tag Archives: transformational change

Post navigation

So the decision comes down, your company is moving forward with new ERP. Congratulations on your decision; just remember, a year or so from now, that ERP implementations are potentially the next great, bloody spectator sport. They are not for the weak or those lacking determination. Decision made, presumably based upon a business case that documented the expected benefits and how you are going to get there. If so, continue. If not, then you’d probably better back up a bit and get all of your bunnies in a row because, in either case, now you have to communicate why you are doing this project.

So whom do you have to communicate with?How about: anyone who will be impacted by this project. Certainly that includes directly impacted end-users and their supervision and management. It also includes people in other organizations that may not be included in the initial project, this might be HR or some other organizaton. Why communicate with them? Because they will hear about the project and will naturally have questions about it, including why they are being included in the scope of the change, especially if they are unhappy with current systems and processes.

What needs to be communicated at this early stage?Frankly, it does not have to be complicated. It almost always begins with “We are moving to new ERP because…” and then you simply fill in the blank. This is also a good time to develop a good 15-20 second answer. Why? To get the key points across quickly. That said, you absolutely MUST be ready to provide details regarding what specific goals exist, by area/location, and how you expect to get there. Elevator speeches can only go so far – it takes details to calm people who are fearful of change.

We actually get asked frequently, “why do we have to communicate so early about the reasons for our new ERP project?” Our answer is pretty simple: because if you don’t, people will fill in the blank themselves. And you won’t believe what they will come up with, most of it from the depths of fear, distrust, or native suspicion. Here’s what we’ve heard people come up with:

So, why are they doing this to us (again)?

To get the company ready to sell (and all of us are going to lose our jobs)

To increase automation and efficiency (and all of us are going to lose our jobs)

Here we go again, more churn, churn, churn and someone else gets the butter (and we are all going to lose our jobs)

Get the point? If you don’t provide a good answer in advance, people will answer their own questions in the most negative possible way.

Your communication of the reasons or rationale for moving to new ERP is merely the start of a good communication strategy and plan – not the end of it. Oh, yeah, if you don’t have a comprehensive communication strategy and plan, it is most definitely time to get one. And for pity’s sake, if you don’t know how to do this, call someone who does. Everyone who depends on the future ERP system will eventually be grateful.

Lack of concerted communication to end-users about the reasons behind the implementation, the anticipated benefits stemming from successful adoption and the ways in which each individual end-user and executive are impacted will affect project success or failure.

I suggested in my previous post that unmet business benefits, make ERP initiatives fail even when they are on-time, on-budget, and on-scope. If we spoke previously about failure, then let’s start here talking about success.

So when we talk about redefining success – hitting your goals – in people terms, what does that mean? Defining where you intend to end is important, but so is defining how you expect to get there. Defining success in people terms means we also have to define how something will be made successful and who will do it.

Here are some of the “goals” customers have given us for implementing ERP:

To improve business performance and automation

To replace an old or legacy system

To better support the business across multiple locations

To better serve customers

To position the company for growth

Admirable reasons; terrible goals.

Why?

They can’t be measured and they give no clue how they could be achieved. They look good, but are sort of neutral and unobjectionable, actually saying very little.

When a client tells us they want to move to new ERP to improve business performance, it is the beginning of what becomes a very long – and critically important – discussion that looks like this:

What areas need improvement? Why? What would the improvements, by area, look like? What changes (people/org, role, process, system, or data) are required to achieve it? How will ERP enable this? How can we state this in measurable terms? What about timeframes for realization?

Starting with “improve business performance,” we can end with goals like this:

Through updated standards for purchase orders enforced in the Purchasing module at the field level, and through improved training of Buyers and weekly monitoring of conformance with these standards, we will eliminate 90% of incomplete purchase orders from flowing through the supply chain within three months of go-live.

By eliminating non-conforming purchase orders, we will reduce the effort of Accounts Payable clerks matching POs to vendor invoices which will be sufficient to eliminate three temporary clerk positions.

Granted, this would be but one of many, many goals that would be documented to achieve “improved business performance.” But that is what it means to truly document goals within a business case and to define success in people terms.

Arriving on-time, on-budget, and on-scope are valid goals on any ERP implementation project. Anyone working in this business knows those goals are themselves hard enough to achieve. While they may be necessary when viewing ERP through the lens of an enterprise software implementation project, they are woefully inadequate when viewing ERP as a business transformation initiative.

If you want to really get your hands around how to make ERP successful, you have to spend the time, energy, and effort defining your goals more completely and concretely. They should enable and guide your implementation. If they don’t, head back to the whiteboard and lock the right people in the room until you get what you need. And if you don’t know what you need, get help defining it.

ERP isn’t just big business, it’s huge business, projected by those who know to break $50 billion yearly by 2015 in software sales, maintenance, development, and services. Thousands and thousands of companies undertake ERP investment and implementations yearly. There are millions of pages on the Internet about how to make ERP projects successful. And hundreds of firms and thousands of people exist whose life-blood is implementing ERP solutions.

So why does ERP so often fail to deliver? According to some, you’ve got a fifty-fifty chance to satisfy half of your goals for the investment. So, if I plan to drive to Dallas and only get half way there, is that a successful trip or a failure? I may have enjoyed the journey while it lasted, but then I ended it in Abilene, not Dallas. That is not a successful trip. It is a sure ride to the Desert of Disillusionment.

Failing to deliver the desired business value means the project was a failure regardless of whether it was on-time, on-budget, or on-scope. It failed. Let’s hear that again. It failed. Sure, everyone got to keep their jobs because the project concluded reasonably close to the schedule and within some allowable contingency of the targeted budget. Success, right? Well, not if you wanted to get further it isn’t. It failed.

How can that possibly continue to happen? The ERP landscape is enormous. Almost every business – particularly those involved in manufacturing or distribution – use or want to use ERP software. Certainly people know better. There are thousands of really experienced, smart people guiding and informing these projects, yet they continue to fail to deliver fully against expectation and goals.

Is the problem that goals are too high? I sincerely doubt it, as companies engaging in ERP projects rarely agree to document their goals in writing or in measurable ways, paying only lip service to “productivity gains” or “improved efficiency”. So if the goals aren’t the problem, what is? You can read for years about better project management, better leadership, a better implementation process and still miss the boat.

While PMOs are often associated with larger firms which need to establish a standard methodology and approach for initiating, managing, and controlling systems-related projects, there are many reasons why a company might consider establishing a PMO.

Similarly, a PMO does not need to be focused on all aspects of project management – at least in its initial implementation. A PMO should address existing organizational problems. If the organization struggles with prioritizing project requests and deciding which projects to fund and staff, the PMO should be focused on this issue. If the organization struggles with keeping projects on track and resolving issues during project execution, the PMO should be focused on this issue. Simply implementing a PMO doesn’t bring value to an organization. Implementing a PMO so that it addresses the real-world issues that the organization is facing does bring value.

While PMOs take many shapes and flavors, they all seek to improve communication, collaboration, and consistency. Organizations face increasingly complex environments while striving to respond to customer demands. They often rely on a set of projects to drive the organization towards a new strategic vision of itself. These organizations can leverage a PMO to more effectively meet these commitments.

So why consider a PMO? If your organization is facing substantive change and needs to improve its ability to consistently and successfully deliver projects so that it can implement that change, a PMO can help.

Ever watched a motorcycle jump? Ever wonder how guys like Evel Knievel knew how far they could go? How fast they could make the jump? How to tune that motorcycle so it would support repeated efforts to break and rebreak records? Was the cycle the secret to success or was it more a matter of mind over matter, training and instinct?

Many businesses face the same challenges as they try to accelerate the pace of change, embarking on transformation initiatives that often demand that their people bridge frighteningly huge current-to-target state gaps. The price of failure is as catastrophic to a business as those motorcycle jumps are to the daredevils who attempt them.

Is technology the secret to success? Methodology? Only partly so — Objective measures of the size of the gap (a catalog of differences between the current and target states of process, technology, data, and business model) will only get you so far. Project phases can be designed to address this, and the classic stuff of project management can certainly help. I call this the hard science side of the equation.

However, for both the intrepid cyclist and the daring leader of an audacious business transformation, success is both an art and a science. Just as a jumper has to factor in the strength of crosswinds, the nuances of posture and the internal state of mind, transformation leaders need to address the following questions, which speak to the art of success:

Does your organization have a framework in place to foster change (communication, collaboration tools; a training framework)

Is there a formal framework for facilitating alignment among stakeholders with different needs?

What is the state of employee engagement at your company? Who is burned out, checked out, counting down the clock to retirement? And who is revved up and raring to go?

Are there wounded bodies still littering the canyon from your last attempt to jump a big gap?

Do you have realistic expectations of the business input required to support a technology-driven transformation? Do you have a backfill strategy?

More and more businesses are seeing the sense of trying to adhere to “plain vanilla” implementations of packaged software applications, without customization to the application code. It’s cheaper on the implementation side, and certainly cheaper to upgrade uncustomized package applications.

This guiding principle is often articulated in the kickoff slides, and all the key stakeholders and executive sponsors nod in agreement.

Here’s what usually happens next.

Analysis begins. Implementation team business analysts work with designated subject matter experts (SMEs) to gather the business requirements that will be used to configure the application. They are adamant that their job must be performed exactly as it is performed right now. The SMEs are like ravenous foodies, seeking to outdo each other with requests for ever more exotic ice cream flavors of the day, while your plain vanilla implementation is melting away, because no one really likes plain vanilla anymore.

How can you get this under control? Intervene early and police ruthlessly during the analysis phase. Add the following expectation-setting statements to your kick-off slides, right after you articulate your plain vanilla guiding principle:

Statement 4 becomes a difficulty if you have not assigned responsibility or budgeted for the effort involved in documenting new business processes, and building and delivering the process training. This is typically not part of the scope of the software implementation vendor’s responsibility.

To prepare for adherence to the full set of guiding principles, you need to develop internal business process/change management capability, or budget for outside help in support of any major system implementation. Failure to do so puts the success of your software implementation project at significant risk.

Last piece of advice: at your go-live party, serve two flavors of ice cream.

Plain vanilla for the team(s) who favored the process workaround route. If they were really good, give them a choice of toppings. For the others, give them exactly what they craved. They’ll fall into line on the next implementation.