We have tremendous respect for CIOs and business leaders who take on an ERP project. After all, it’s easy to avoid such massive undertakings in favor of quick wins or incremental IT transformation. ERP projects require a ton of perseverance, time, resources, and flexibility. They’re hard, and there’s no getting around it.

There’s also no way of getting around the fact that companies tackling an ERP project need help. Whether they completed one 10 years ago or never, businesses simply don’t specialize in ERP. Sure, they can hire a few experienced people and talk to their fellow colleagues. They can attend training and scour the Web for insight but businesses are not and arguably should probably never be ERP experts. That’s not why they’re in business. Instead, smart businesses need to look to others for help. They need experts to provide guidance and in-the-trenches know-how gained through the pain of previous ERP projects. Ah, but it’s not just a little help that’s required, as we’ll cover later.

ERP projects represent a massive balancing act, too. In project management circles, it’s common to talk about the two trade-offs to a successful project: time and scope. To stay on schedule in the midst of timing problems, remove scope. To retain scope in the midst of scope problems, add more time. However, there are two other dimensions that are much more commonly traded off or worse – ignored: quality and cost. Combined, these four dimensions (all with ever-present risk management) work together to form a “scope house” (Figure 1).

Figure 1

The scope house depicts the relationships between time, cost, quality, and scope

In some cases, it could be perfectly acceptable to reduce quality in light of cost constraints. Newfound ERP reporting and business intelligence capabilities can be so appreciated by a user community accustomed to nothing and grateful for something that they accept low quality for starters. Some amount of ERP regression testing may be intentionally sacrificed, too, in the name of sacrificing quality to hit an aggressive regulatory-mandated go-live date. However, in the same way that life-saving hospital systems must operate at near perfection, sacrificing quality with regard to data migration or transformation, or integration testing, or vital business process regression testing is more often just plain irresponsible.

Just as Martin Cobb’s decades-old paradox (“We know why projects fail; we know how to prevent their failure – so why do they still fail?”) continues to ring true, it’s not surprising that we continue to see ERP project teams engaging in practices known to be harmful to success. Teams and individuals alike often find themselves mired in tactical details, lifting their heads only now and again to think about the future, all the while hoping for the best. And like real life, ERP projects are too complex to leave to fate.

In the following pages, we walk through a top 10 list of ERP project practices to avoid, practices that surprisingly have survived despite years and years of “don’t ever do that again!” lessons. To keep things current, only practices we’ve seen in the last several years have made the list. To keep things anonymous and organized, we’ve avoided naming names and have employed a simple framework for our top 10 structured around program/governance, project/staffing, and solution/technology (Figure 2) practices, analogous in many ways to the widely overused process, people, and technology frameworks.

Figure 2

A simple framework for organizing ERP

Program/Governance Practices to Avoid

Worst Practice #1: Executives, Feel Free to Waver in Your Commitment

We spoke with a colleague recently who told us about the huge investment his team made in a brand new ERP project. After spending three years and $50M USD, the company pulled the plug a month before go-live. Why? Because new company executives were tired of spending money, and it seemed that the project would require more maintenance and upkeep than they realized. The lesson here is that ERP projects require ongoing executive commitment despite their ups and downs and despite a set of revolving doors in the executive suites. Pay attention to executive commitment warning signs. A changing of the guard is the biggest red flag. Others are more subtle, including a lack of pushing real changes in organizational behavior, a loss of focus in the project’s expected benefits, cancelled sponsorship and stakeholder meetings, and even changes in how executives are compensated. If ERP projects were as controlled as cigarettes, we’d see warnings like “ERP can cause a slow and painful death,” “ERP seriously harms health,” and our favorite, “ERP causes facial aging.” However, ERP projects don’t come with such obvious warnings. When discussions of ERP transformation and expected value decompose into regular conversations about this week’s ERP budgets and the need to cut scope and staff, you’re in trouble. Do what you can to highlight the project’s already-realized value and continue to socialize the longer-term business benefits with executives and other stakeholders, all the while proactively and aggressively balancing your “scope house.”

Worst Practice #2: The Business Strategy Can Wait

Another customer of ours invested a huge amount of effort into figuring out its business strategy, which in turn needed to be reflected in the ERP instance strategy and a set of immutable technology constraints. They wavered between establishing a global instance to satisfy creating a “single version of the truth” around financial reporting, to deploying multiple local instances to accommodate specific business unit needs, back to a single instance for simplifying technology support requirements, to deploying multiple instances to accommodate network latency issues, and more…. Back and forth, back and forth, all the while marching closer and closer to an unmovable go-live date. Emergency meetings were held, strategies were developed and ripped apart and re-developed, and tens of people literally spent the better part of six months working through instance strategy pros and cons. Language support problems, perceived issues with maintaining data in certain countries, system performance and remote business realities, the impact of deploying fat clients versus giving portal access to end users, unknowns around the company’s mergers and acquisitions strategy, the desire to close old datacenters and centralize around a new one…. All of these and more diverted attention away from the real go-live issues centered around configuration, master data management, and testing, and ultimately proved disruptive to the business and its desire to transform through ERP.

Worst Practice #3: Business Requirements Can Be Easily Changed Despite Contractual Commitments

Under-scoping the very functionality required by an ERP project is fairly common but solvable. However, under-scoping that functionality in the context of a fixed-price contract can be a finger-pointing disaster. We have a customer who needed more capability than the standard Human Capital Management functionality would provide. Instead of connecting the business with a systems integrator, partner, or ISV to provide a reasonable pre-sales specification based on actual business requirements, the systems integrator simply took a stab at how much some additional functionality might cost. And then they won the deal! In the world of fixed-priced ERP implementations, low-balling an estimate only works in the customer’s favor (and even then it doesn’t really “work” at all, as one party postures and positions to push a change order while the other stands firm on price and effort). The systems integrator mis-scoped by a factor of 5X from an implementation perspective, and perhaps worse never really considered ongoing maintenance and support costs. Such a huge miss resulted in a horrible set of kick-off meetings, a disruptive display of behaviors, and cost-cutting measures from day one (including trying to staff the project with cheap inexperienced resources), showcasing that “bolting on” new business requirements as an afterthought can prove to be an ongoing problem at many levels. No one wins. Companies need to be careful hiring an integrator, of course, but more importantly need to continue asking questions during the project’s scoping and design phases. Verify that the integrator’s work is borne from experience with similar customer projects, for example, and be sure to be involved in the consultant on-boarding process.

Project Management/Staffing Practices to Avoid

Worst Practice #4: Minds Don’t Need Downtime

It’s not uncommon for customer project schedules to be affected by multiple unforeseen circumstances. We’ve seen such things cause go-live dates to slip as more testing cycles are added or resource constraints are re-balanced. Sometimes, though, in order to meet go-live demands and keep a project timeline moving, ridiculous hours may be required. Everyone knows that at some point fatigue can and often will affect decision making, increasing the likelihood of mistakes. We recall late nights at 3 am being afraid to kick off critical long-running processes because we were so tired we could not think clearly. Surely we’d forgotten something despite our checklists! In an ERP project there can long sets of steps that must be run sequentially and without error in order for a particular overall technical process to succeed. Any small mistake can cause a major issue down the road, requiring rolling back, starting over, re-work, and unhappy project teams. Pushing people so hard for so long that they become fatigued is more common than ever. When tasks are deemed important enough to put business and budgets at risk, consider bringing in a fresh set of eyes. Ensure key players have backups and get the rest they need. In these days of lean ERP project teams where people often wear many hats and burnout is nearly unavoidable, simple plain old fatigue can be enemy number one.

Worst Practice #5: Cleanliness and Orderliness Have Nothing to do With Downtime

Perhaps the oldest worst practice in the history of big ERP projects stems from a basic lack of cleanliness and orderliness. We’re sure you have seen these: magnificently well-groomed data centers. Pristine work places. Uncluttered desks and spacious nicely-equipped meeting rooms. Like showcases of excellence for business leaders and IT managers to show off to their customers and other visitors, these things do indeed exist. However, they’re the exception, and indeed that’s pretty understandable. What isn’t understandable is the depth of sloppiness and lack of order that can quickly consume a busy ERP war room, work space, or data center. We’ve seen our share of desks hidden by paper and food, or rows of sloppy computer racks stood up in the corner of a room that someone decided to call their data center. Recently though, we were visiting the facility of an especially large and well-funded project, looking into intermittent technical issues. As we were escorted into a poor excuse for a mission critical ERP data center, our first impressions would prove correct. It was a disaster. Meshes of random cables were draped across the room, nothing had yet been labeled, and no one seemingly had time to find order in the chaos. While we were there, a technician entered the facilities to replace a hardware component in one of the racks. Minutes after he’d pulled the drawer out of the front of the rack, developer complaints start rolling in. SAP was down (again!). And yes, he had managed to unplug a power cable from the back of a server lacking a redundant power source. We realize this is an old story for most everyone, but it’s as important as ever to remember that stupid and easily preventable mistakes happen today as much as ever. Take advantage of cable management, label data center gear, and insist on some level of order in the workplace. It might just help avoid a whole lot of unplanned downtime not to mention needlessly grumpy colleagues and customers.

Worst Practice #6: We Don’t Need Your Help, Thank You

Despite all the different skill sets required to navigate an ERP implementation, there are still project leaders who insist they don’t need much help. Or they realize their needs late in the project, and thus lose important time waiting for new team members to ramp up. When the very software responsible for running a company’s business is being reinvented, project teams need to recognize that help must come from every corner. Business, technology, and organizational change specialists need to work together in an orchestration typically lasting one to several years. That’s where systems integrators, software and hardware partners, and all manner of boutique subject matter experts with specialized knowledge in industry business processes, change management, data migration, software configuration and customization, testing, tuning, end-user training, disaster recovery solutions, and so much more are weaved together by program and project managers to navigate a company through its ERP project. It’s a big deal, with a lot at stake. Ask for help, staff appropriately, and staff in time.

Solution and Technology Practices to Avoid

Worst Practice #7: Design the New Solution to Avoid All Sense of Change

One of our colleague’s customers faced a dilemma with their end-of-life business application. In the end, they decided to pay a systems integrator to plan for, design, and deploy a new ERP solution that modelled their old minicomputer-based green screen solution. Seriously. And this was recently! After months of business process configuration workshops and ineffective attempts at introducing change, the customer found it necessary to pull the plug on the new system before it went live. Besides the millions of dollars and thousands of hours of wasted time, the failed project has made it nearly impossible to even try again. Without top-down pressure or bottom-up buy-in, it’s impossible to force a customer’s end user community into business process transformation.

Worst Practice #8: Happy Path Testing Saves Time and Money

Ever heard of “happy path” testing? It’s the most basic kind of light-touch testing known to man. The best (worst!) example of happy path testing would equate logging into the SAP system as proof that it is ready for production users. Over the years, we’ve had many customers engage in various levels of doing the easy testing rather than the right testing. What happens when an invalid entry is keyed in? What if we try to process 10 orders instead of just one? One of our customers took a year to build out an ERP solution only to leave a month to user-acceptance and unit-testing of what amounted to just their basic business transactions. Another introduced a tremendous amount of new functionality through an upgrade without adequate regression-testing of how the upgrade affected previously configured functionality. Many others customers have focused on the easily-scripted functional and performance tests at the expense of the highly complex custom code destined to fail under load. A few years ago, one of our customers grew tired of their antiquated ERP hardware platform and high support fees. They wanted to get to a newer, cheaper, faster platform and take advantage of SAP’s Unicode database for multiple language support. The end result was a new platform they were unaccustomed to supporting. As it turns out, the customer only did minimal spot checking of key transactions too, and never pursued full regression testing. While the go-live went relatively smoothly, custom batch job performance was later found to be far from desirable. An extra week of tuning helped a bit, but the mix of business and technical problems in light of their “happy path” ways caused headaches for months.

Worst Practice #9: A Non-Production Environment Doesn’t Need to Reflect Production

One of our hosted ERP customers was running a large upgrade project across a complex system landscape. In this case, the only environment using dedicated application servers was production. After spending months executing test runs of the upgrade in all of the environments, the production go-live weekend was finally upon them. After a long weekend and a troublesome upgrade, the upgrade was nearly complete. But wait! As it turned out, the application server operating system (OS) did not support the new system kernel. The OS needed to be upgraded to a new untested customer standard. After a series of follow-on delays, the new application servers were finally up and running. Two painful days of instability followed after the system went live. Had this customer deployed even a single application server in its non-production environment, this upgrade would have gone a lot more smoothly, finished earlier, and never experienced those confidence-robbing days of instability. Lesson learned? Beyond demanding more rigorous like-for-like testing, make sure you’ve got a non-production environment that truly looks like your production environment. The more similar, the less risk.

Worst Practice #10: Infrastructure Planning Has Become Unimportant Nowadays

Have you ever heard the term infrastructure creep? Not unlike scope creep, infrastructure creep causes your data center to grow in unplanned leaps and bounds. Servers grow like weeds, VM farms become overcommitted, and life just gets complex. One of our customers recently took on a full blown ERP re-implementation. The old ERP system had already been pretty large, but no one could have foreseen just how much SAP would explode in the new environment. As more and more projects spun up, and more and more systems and landscape components were spawned, we soon surpassed 100 SIDs. At the breakneck pace of the project, managers had to beg, borrow, and steal infrastructure to keep up with demand. The result was a sprawling landscape of SAP systems spanning multiple data centers, cloud service providers, and – get this – multiple OS/DB platforms. What a nightmare to support! To do a system refresh suddenly took weeks. Developing and adhering to an architecture and infrastructure plan would go a long way to curtail some of this creep, resulting in a cleaner, easier to support environment.

Conclusion

Countless successful SAP and other ERP implementations have yielded a host of best and common practices reflecting the right way to plan for, test, deploy, and operate these complex software solutions. As you have seen here though, despite the maturity of ERP software and  systems integrators, a number of lessons continue to be learned the hard way. If only IT and business leaders would follow up on the hard decisions made earlier. If you’re going to implement or upgrade your ERP solution, insist on doing things right rather than conveniently or cheaply. Balance your “scope house” while demanding authentic risk mitigation and contingency plans. Seek out help and protect your most important investment – your people. The savings in missed deadlines, damaged customer relationships, and system downtime alone will more than cover the costs. Dodging such avoidable battle scars might just save a few companies, too, not to mention everyone’s job and reputation.

George Anderson

As a senior director and global program executive for an arm of Microsoft's consulting business, Dr. George Anderson leads teams of program and project managers, architects, and enterprise consulting professionals tasked with deploying various ERP solutions and other business applications. He’s co-authored several books including SAP Implementation Unleashed and the Teach Yourself SAP in 24 Hours series, serves as an adjunct professor teaching various project management and systems analysis courses, and holds a number of credentials including PMI PMP and several SAP and Microsoft certifications alongside a PhD in leadership/organizational change, an MBA with a concentration in Human Resource Management, and a bachelor’s degree in computer science.

You may contact the author at george.anderson@microsoft.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

John Dobbins

John Dobbins is an independent senior SAP Basis architect, business consultant, and global project manager with 20 years of enterprise IT business experience. John supports multiple SAP customers and projects around the world, spanning new implementations, functional and technical upgrades, OS/DB platform migrations, and more. His passions for technology architecture and customer enablement intersect well with his customers’ needs to streamline business processes and create agile solutions.

You may contact the author at john.dobbins@outlook.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.