The Lake of Unclear Benefits

lake of unclear benefits

Source: harrypotter.wikia.com

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.

Mitigation Step: Create and follow a comprehensive organizational change management plan – at the very least, get an expert involved to do an assessment of readiness and challenges.

Redefining Success in People Terms

Success in people termsI 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.

According to my dictionary, success is a noun with multiple meanings, yet the primary one is “the favorable or prosperous termination of attempts or endeavors; the accomplishment of one’s goals.” It’s not about the scope, timeline or budget, it’s all about the business GOALS.

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.

post-it-1Granted, 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.

Is ERP Success Really Such a Secret?

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.

ERP Enterprise Resource PlanningSo 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.

The bottom line is simply this: software does not drive a business. People do. And if you don’t empower and support people, all the technology in the world won’t move your business forward. This is something we’ll explore further in subsequent posts. But stay tuned as we drill into how to turn the discussion on ERP success on its head.

Why a PMO

shudder_homer_smallProject Management Office

The words make some shudder.  Of course PMOs have existed for a long timeThey grew as the discipline of project management itself matured and people recognized that project management was a distinct skill set that demanded training and experience, as well as certain natural talents.

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.

First, a PMO does not need to be focused on systems-related projects.  The real benefit of a PMO is its ability to bring a disciplined approach to how an organization approaches projects.  Any time an organization is contemplating a series of projects to introduce transformational change, a PMO can improve the odds of success.  Those projects can be systems focused, but they could also be focused on business process redesign, new product development, geographical expansion, acquisition, or reorganization.  Each organization can decide for itself what type of projects should fall under the auspices of 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.

How do you know when the gap is too big to jump?

SnakeRiverCanyonArrowEver 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?
  • Have you defined success in business terms, or are you just eager to “put in a new system?”

When considering anything unprecedented or record breaking, don’t put all your faith in science—and don’t devalue the many human factors that are very much a part of the art of success.

No one likes plain vanilla anymore

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:

  1.  All customization requests must be reviewed and approved by the steering committee.
  2. Potential process workarounds will be explored before any customization requests can be approved.
  3. There may be more business process changes than there are customizations to this application.
  4. We will provide training on both new business processes and new procedures for working with the new software.

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.