Give us a Call +1 (720) 515-1377

Another Public Sector ERP Failure?

The ERP vendors and consultants appear to have experienced their share of ERP failures in recent months. For example, as recently as August, we blogged about the failure at the State of Pennsylvania, which publicized a $40 million budgetary overrun with a project that took 42 months longer than expected. If you take a moment to Google “ERP Failures,” you will find many more case studies of every CIO’s worst nightmare.

More recently, the State of Massachusetts announced that it too has experienced an ERP failure of sorts. The state’s unemployment system project went over budget by $6 million and is allegedly unable to make proper payments to job seekers as a result. When judging the success of this project on three criteria – budget, time to implement and benefits realized – it is clear that the State of Massachusetts, their system integrator and internal project team all left much to be desired.

These two examples are two of many. Our 2013 ERP Report reveals that a majority of ERP implementations fail to implement on time or on budget and/or fail to deliver the expected business benefits. This being the case, what are some of the things that both public and commercial organizations can do to mitigate the risk of ERP failure and optimize the chances of success? Here are a few lessons that will help your organization achieve better results than those outlined here:

Set realistic implementation expectations. Most projects go over budget and take longer than expected largely because there were unrealistic expectations to begin with. For this reason, it is important to recognize that when an ERP vendor or system integrator is selling to you, their job is to close a deal rather than to set realistic expectations. Benchmarking to organizations similar to yours to see how long they actually took to implement (versus expected) can be a reliable data point. In addition, you’ll want to make sure that your implementation plan includes all the internal project responsibilities and other activities outside the scope of your technical implementer.

Begin with a solid implementation project plan. Similarly, a solid implementation project plan is a prerequisite to realistic expectations. During the planning phase of your project, meticulous attention should be paid to project assumptions, roles and responsibilities and scope to ensure your plan is a realistic representation of what is required to support the end solution you desire. As mentioned above, your technical system integrator is often going to provide an incomplete and myopic version of a project plan, which will need to be augmented with other critical project activities. For example, organizational change management, business process reengineering and project governance are three items that are commonly omitted from the scope of most system integrator and ERP consultant implementation plans.

Know when to pull the ripcord on your project, consultants or system integrator. ERP implementation failures do not happen overnight so most large-scale and highly publicized ERP failures did not properly recognize or respond to warning signs along the way. A good consultant or system integrator will help you recognize warning signs along the way but if they don’t, it’s just as important for you, the implementing organization, to make changes where needed. In some extreme cases, this may even mean pulling the plug on the project so you’re not putting good money after bad. One common mitigation strategy in this area is to hire a third-party independent verification and validation (IV&V) consultant to oversee your consulting firm, which will serve as another mechanism to recognize warning signs along the way.

The bottom line is that while ERP failures are more common than they should be, most can be avoided with the appropriate level of planning, expectation-setting and risk mitigation. Regardless of whether you are a government entity or commercial organization, simply employing the three tactics above will help dramatically increase your chances of success.

Learn more by downloading our free, on-demand webinar, Lessons Learned From Failed ERP Implementations.

The Pros and Cons of ERP System Customization

The Pros and Cons of ERP System Customization

“No customization” is one of the most common mantras we hear about ERP systems among our global client base. As ideal as a zero-customization ERP implementation may sound, the unfortunate fact is that most organizations customize their ERP systems – at least to some degree. While most executives want to manage their implementations by simply using basic configuration, setup and personalization of the software, an overwhelming majority end up making fundamental changes to the source code.

Two things are clear: most organizations fear customization yet most fail to implement ERP software without customizing it. Below are just a few thoughts to keep in mind as you find yourself navigating the slippery slope of ERP system customization:

ERP customization can create problems during implementation. Most executives have read the horror stories of ERP failures largely attributed to over-customization of ERP systems, so it’s only natural that they would err on the side of “no customization” to mitigate the associated risks. Customization is hard to manage, can break your implementation budget and can indicate that employees are refusing to change their processes. Perhaps most concerning, customization is also sending your organization down a path of relying less on proven, out-of-the-box functionality, which should be a big concern for any CEO, CIO or implementation project manager.

ERP customization can create problems after implementation. Upgrades become more difficult since the code often needs to be rewritten to support newer versions of the software, which often leads organizations to defer upgrades – sometimes indefinitely. When we look at trends of our newer clients, most are looking to replace their old ERP systems largely because they’ve customized the software so much that they can’t (or aren’t willing) to take advantage of newer versions of the software because of the associated risks.

Vanilla ERP systems can create strategic disadvantages. As much of a no-brainer that “no customization” may seem given the above two points, the main challenge is that no matter how good any ERP software may be, it is not going to address 100% of your organization’s needs. ERP systems, by nature, involve tradeoffs of flexibility versus standardization, tradeoffs of one single system for all functions and departments versus a best of breed approach, and a host of other compromises. Once you add your organization’s areas of competitive advantage to the mix, you suddenly have some pretty compelling reasons to customize at least a handful of areas in your ERP system.

Vanilla ERP systems can create even more organizational change issues. Each and every ERP implementation involves fairly significant organizational change management issues, but these challenges are even further magnified when the organization is making little to no change to the software to accommodate the current realities of the business. While this pure vanilla approach may be the best route to pursue for a minority of organizations, it is a reality that needs to be addressed via more dedicated focus on a comprehensive organizational change management plan. A good rule of thumb is that only areas of competitive advantage should be even considered for customization.

Unfortunately, there is no black-and-white answer to this issue and there are very compelling reasons on both sides of the argument. We find that most mid-size to large organizations need at least a minor amount of customization to protect areas of competitive advantage and mitigate change management risks. This, in and of itself, isn’t a bad thing, provided those organizations are able to contain and isolate the level of customization via effective project management and governance, while effectively addressing change management issues.

Schedule a Free 30-minute Consultation with an ERP Project Management Expert!

Reporting Back: The Importance of Closed Loop Feedback in ERP Implementations

Successfully implementing ERP software requires two-way communication. This is not only important between an ERP project team and end-users – it is also applicable to the project manager and team members. Once duties and roles are assigned, the ERP project manager should clarify expectations for how team members should communicate status updates and results as well as respond to questions and feedback). Many project managers have an expectation of closed loop feedback – a concept based on the premise that accountability motivates improved performance.

Put simply, when a project manager presents a team member with a task, the team member has the responsibility to complete that task and report back to the project manager regarding progress and results. This cycle continues throughout the ERP implementation until the team has achieved stated goals and objectives. The concept of closed loop feedback should be applied to every project deliverable whether it relates to business process reengineering, organizational change management or some other component of the initiative.

Before implementing a new ERP system, an organization should ensure that it has a fully-staffed ERP project team and adequate resources to manage each deliverable. All project team members, from the business process analysts to the system trainers, should be held accountable for their individual duties, and regularly communicate with each other about their progress.

Requiring team members to report back to their project manager is a powerful way to influence results. When project managers provide regular project updates, it acts as a strong motivator for the project team to continue moving the same direction or backtrack and make improvements.

Following are three tips for maintaining a closed loop feedback system among your ERP project team:

1.   Define who team members need to report back to. Usually, the project manager will serve as the main point of contact. If any questions arise as to the actual status of the project, the project manager should always have the most accurate and up-to-date answers. The project manager should also be in charge of identifying and correcting performance issues as they arise.

2.   Continue the feedback loop. As team members perform tasks, the most accurate way to measure their performance is to have them report back to their project manager on their progress.

3.   Share performance measurements on a regular basis. Whether through a meeting or a memo, team members need to be informed about overall performance as well as individual performance. Providing information about current performance and comparing this to ideal performance can prompt team members to adjust their behaviors to come closer to achieving project goals.

Throughout implementation, two-way communication is the foundation for achieving project goals and objectives – and it must start with the project manager and implementation team. Clear, concise and correct communication is the most effective way to maintain a closed loop feedback system and motivate team members (and end-users) to continuously improve their performance.

Learn more about how to build a successful project team by visiting our ERP Staffing page.

Scope Creep: The Kudzu Vine of ERP Implementations

Kudzu vine is an invasive species that spreads out over buildings and fields, suffocating all in its path in a soulless quest for domination. It’s kind of reminiscent of ERP implementation scope creep in that regard. Given the opportunity, ERP scope will push and push to erode governance structures, project management strongholds and even the most diligent core teams. So let’s examine the reasons, the impacts and the ways to overcome it:

Reasons Behind ERP Implementation Scope Creep 

Simple: everyone wants something different and they’re not afraid to ask, cajole, beg, borrow, steal, threaten or manipulate to get it. Maybe that’s a bit cynical, but people who care about their jobs are often heavily invested in ERP projects in some way or another. If they feel that their functional area’s requirements weren’t properly gathered during the ERP software selection process, or that they don’t have a voice to express their needs and concerns, or that management is moving full steam ahead on a misguided project with no real benefit, then they will push back. It’s a reasonable reaction and to be expected.

Impacts of ERP Implementation Scope Creep

So what does this pushback look like? Also simple: extensions to deadlines, failure to stick to budgets, unwillingness to change processes, absolute certainty that the project cannot move forward without extensive customization in a specific functional area, and so forth. As their doubt, fear and uncertainty coalesces, the project starts to bloat. The governance structure cannot hold. Decisions and compromises are being made without proper approval. The sunlight is blocked; no fresh air is allowed in. And thus the withering begins.

Ways to Overcome ERP Implementation Scope Creep

Consider your ERP system initiative as locked down, regulated and tight as a military operation. Everyone knows their rank, the procedure for change requests, the proper channels to navigate and the expectations of their mission. Much like a kudzu vine, challenges to the scope are acknowledged, cut down and disposed of (unless, of course, they make it through the change request process and are incorporated into the “landscaping”). The goals are clear. The priorities are clear. The project architecture is clear. No one has any doubt about who’s in charge, what the end-game is and how to raise questions and get answers. The scope stands. The kudzu is vanquished!

Are you struggling with scope creep in your ERP project? Learn more about the science of managing people during complex IT initiatives at our webinar, Organizational Change Management: A Critical (and Often Overlooked) ERP Implementation Success Factor, on January 31 at 12:00 p.m. EST.  Also learn how to evaluate third-party ERP consultants to help you navigate the waters and get control of your scope in our latest white paper, the Guide to Choosing an Implementation Partner.

What Your Project Manager Really Wants for Christmas

In my last blog post, I mentioned that to ignore project governance is a very quick way to make your project manager (PM) curl up in a corner and cry – and that is especially important during an ERP implementation.

Although that might be very amusing for a minute or two, we’ll assume that you really are a good person at heart. I’m sure that you want to show your PM how much you appreciate him or her this holiday season and also make sure your organization achieves ERP success. I’ll let you in on a little secret – all you have to do is read one document and then ask them a few questions about it. It’s something you can do for free!

So what should you read? I’d like to suggest your ERP project charter. Your PM probably invested a lot of time into developing it and it will thrill them to no end if you respond and react to all the hard work that went into it. The ERP project charter takes into account information collected and developed during the executive-level strategy sessions and contains the following:

  • A validated ERP project vision
  • A validated list of objectives that support the vision
  • A list of the expected business benefits that the ERP implementation will bring about
  • A clear depiction of what constitutes success for the ERP project
  • A high-level scoping statement, timeline and budget
  • A high-level list of project variables
  • A high-level list of assumptions and anticipated risks
  • A roles and responsibilities matrix
  • A list of standing project meeting schedules, agendas, and reports
  • Governance procedures that address how changes to budget, scope and time are to be treated

A great project manager will take the project charter very seriously. Their deepest desire is to have the ERP project team take it seriously too. You can make their holiday great by reading and understanding the project charter. While I can’t guarantee that it will lead to peace on earth, it will certainly generate a lot of goodwill and warm their cold, little PM heart.

Written by Bobby Green, Senior ERP Consultant at Panorama Consulting Solutions.

Easy Ways to Drive Your ERP Project Manager Crazy

Does your project manager (PM) seem to enjoy their job a little too much? Are they whistling while they update Microsoft Project with plans for the organization’s ERP implementation? Do they bring in doughnuts for everyone “just because”?  If you see these signs, you are witnessing something rare: a happy project manager.

Given that this is highly abnormal (and is very likely making folks a little uncomfortable), you may want to take some immediate action. Here’s a list of things that are guaranteed to bring a little rain to your PM’s sunny disposition and bring him or her back down to earth:

  • Ignore Project Governance Project governance refers to those processes that provide support for project sponsors, decision-makers and stakeholders. You can think of it as the PM’s moral compass. The best way to upset your project manager is to go directly to your application developers, order up some changes to the ERP system or implementation based on a random requirement, and “forget” to inform the PM.  It may take a day or two to get a reaction but it’ll be a good one!
  • Disregard Project Team Performance – Performance management ensures performance issues are identified and corrected quickly. If you ignore these issues, you can be sure that the project team will soon bear resemblance to the cast of 1984. But hey, PMs love herding those cats!
  • Ignore the Project Schedule – Schedule management identifies project-level milestones and the resources required to meet those milestones. Effective PMs aggressively integrate the work of the resources into detailed project schedules, monitor schedule variances and recommend corrective actions to keep the project on track. If you simply ignore the schedule, you negate the work of your PM and you will be sure to restore them back to the appropriate level of grumpiness.
  • Make Arbitrary Changes to Scope, Timelines and Budgets – Some of the most common reasons ERP projects fail are related to poor management of risks, issues and scope. Good PMs identify, evaluate, mitigate and communicate the impact of changes – if they have time to plan. So if you’d like to get under your PM’s skin quickly, just make a few random changes to the budget, compress the timeline without warning or tell them that the budget just got sliced 18-percent to pay for new iPads for the marketing department.
  • Ignore Project-related Communications Communicating the project status, as well as risks, issues and organizational change management initiatives, is key to keeping the project team and stakeholders aligned and on track. Just set the auto-delete function for emails coming from your project team and you’ll be sure to upset the PM’s applecart.

Of course, I offer the suggestions above in jest. I hope you see them as your PM sees them: guaranteed ways to torpedo an ERP project that was destined for success.

To learn more about ERP project management and how not to drive your PM crazy, consider attending Panorama’s 2013 ERP Boot Camp in March. Also be sure to read some of Panorama’s white papers for more information on ERP success.

Written by Bobby Green, Senior ERP Consultant at Panorama Consulting Solutions. 

Got PM?

While PM sounds like something terrible that you get once a year – like the whooping cough or a bad case of the itchy-scratchies –if your company is implementing an ERP system without a dedicated, experienced PM (project manager), it’s pretty likely that your project is not going as well as it should. In fact, and to be blunt, it’ll probably be an ERP failure.

ERP implementations can be incredibly expensive in terms of raw dollars, time and your staff’s emotional and mental investment. Organizations pay a lot of money for complex software and hardware as well as for the human resources to install and configure the system. Further, ERP implementations disrupt business operations and place huge demands on the time and attention of company leadership, functional area leaders, subject matter experts and the IT staff.  Who coordinates all of the work?  Who’s the referee? Who is the “single throat to choke”?  If you can’t close your eyes, picture him or her clearly, and hear his or her voice in your head, you’ve got one of two problems – serious short-term memory issues or, more likely, an ineffective (or undetermined) project manager.

A project manager performs several key functions that help ensure ERP success. His or her task is to manage the following project-related functions:

  • Project Governance – Project governance refers to those processes that provide support for project sponsors, decision-makers and stakeholders. You can think of it at the PM’s moral compass.
  • Project Team Performance  – Project team performance management leverages status checks and reporting to ensure performance issues are identified and corrected quickly.  It also enforces consistent performance reporting guidelines.
  • Project Schedule Management – Schedule management identifies project-level milestones and the resources required to meet those milestones. Your PM should be your single “keeper of the truth” when it comes to the status of a project, and the impact on the project resources. Effective PMs aggressively integrate the work of the resources in detailed project schedules, monitor schedule variances and recommend corrective actions to keep the project on track.
  • Management of Risks, Issues and Changes to Scope, Timelines and Budgets – Some of the most common reasons projects fail are related to poor management of risks, issues and scope. Good PMs identify, evaluate and communicate risks, issues and the impact of change requests to affected stakeholders. PM’s should routinely facilitate leadership reviews, and help to coordinate and document solutions.
  • Project-related Communications Every project and program requires a great communications plan to be effective. Communicating the project status, as well as risks, issues and organizational change management initiatives is key to keeping the project team and stakeholders aligned and on track.

It is worth noting that tracking the actual spend-rates and forecasting future project costs can be a full-time job. Your PM’s ability to report cost variances and adjust program forecasts should be based on documented change control procedures (contained in the Project Governance Document). The lack of well-crafted and well-understood project controls usually equates to scope creep, delays in the schedule and cost overruns.

In addition to budgeting, a large amount of the PM’s time is spent in resource management (RM). The point of RM is effective utilization. The PM will establish an RM model and track utilization, which will help stakeholders make better decisions for project prioritization. It’s important for the PM to both gather and maintain accurate project data.

In summation, it’s clear that in order to be successful implementing ERP or any other complicated, company-wide initiative, any organization needs someone to ensure things stay on track and that changes to the project status are effectively coordinated and clearly communicated.  Before your ERP or IT project kicks off, it’s well worth asking yourself if you’ve “Got PM?”

Written by Bobby Green, Senior ERP Consultant at Panorama Consulting Solutions. 

Best Practices to Manage End-to-End Business Processes in Your ERP System

It’s no secret that most ERP systems fail to deliver the business benefits anticipated by the organizations implementing the software. More specifically, our 2012 ERP Report reveals that 50-percent of organizations fail to receive at least 50-percent of the expected business benefits from their investments in enterprise software. Adding insult to injury, and as outlined in our blog last week, is the fact that most organizations experience a misalignment between their business operations and ERP systems, which typically worsens over time as the companies go through acquisitions, international expansion, supply chain reorganizations, and other changes.

The reasons for the failures to achieve business benefits as well as operational misalignments with ERP software often point to business processes. As opposed to incorporating process best practices in their ERP systems, most ERP vendors and system integrators use the flawed practice of designing and configuring the software to handle a hodgepodge of transactional workflows in the system, most of which do not integrate in a cohesive end-to-end business process. Despite all the talk about best practices, order-to-cash and procure-to-pay business process workflows, and all the other buzz terms in this area, the ERP industry is still sorely lacking in its ability to develop, institute and manage business processes effectively as part of an ERP implementation.

So what can a company do to take more of a business-centric approach to its ERP system? Here are four best practices, proven through our years of independent experience, research, and expert witness work related to ERP lawsuits:

1. Define your ERP business blueprint. The common industry best practice favored by most system integrators, software vendors, and ERP consultants is to force the implementing organization to adopt the software by ignoring the “as is” processes and focusing on how to design the various transactions in the system. However, this methodology is flawed (as is proven by years of ERP failures), and doesn’t take into account the holistic, end-to-end business processes required to run the business. A technology-agnostic business blueprint, on the other hand, looks at the end-to-end workflows, organizational responsibilities, and metrics required to drive the business. In addition, this business blueprint approach defines how non-ERP processes and hand-offs will happen and, more importantly, focuses the implementation team’s attention on eliminating non-value-add activities and re-engineering broken business processes. The traditional and outdated approach of simply adopting the industry best-practices in the out-of-the-box software fails to address these critical issues.

2. Develop a business case and benefits realization plan. Simply put, your business processes won’t stick within the organization without the appropriately defined metrics to drive those business processes. In addition, without a benefits realization plan, expected business benefits will not be realized. It is no coincidence that most projects fail to create a full business case and benefits realization plan and most of those same projects also fail to realize the business benefits potential of their new ERP systems. In order to succeed and fully optimize your business benefits, your team will also need a comprehensive plan outlining how exactly the organization will achieve the planned business benefits. For example, the plan should include details of the specific measures used to drive business benefits, the exact business intelligence required to measure the benefits, the person(s) responsible for managing to the performance and so forth.

3. Create an organizational change management plan. Defining the software and business processes is the ante to stay in the game, but the organizational change management (OCM) component of any ERP implementation is the variable that will ultimately determine whether or not business processes “work” and whether or not people actually adopt those business processes. While most ERP system integrators and consultants think of OCM as a synonym for “training,” that is only one minor component of a successful organizational change plan. In addition to end-user training, an effective organizational change management program will include organizational impact analysis, employee communications plan, project branding, organizational readiness, and several other key components that we have proven to be the differentiators between ERP success and ERP failure.

4. Create an ERP Center of Excellence (COE). Once your ERP software is installed and “live,” it is important to manage it to mitigate the operational misalignments mentioned above. An effective COE should focus not simply on how to “fix” the software should it break or require upgrades, but more importantly, on the steps an organization can take to ensure that the software keeps up with evolving business needs and requirements. In addition, an effective COE will enable you to identify training needs, potential areas of organizational resistance, and broken business processes that can be continuously improved via better use of the ERP software. Most organizations and their system integrators define the finish line of their ERP implementations at the time of “go live,” but they should also be ensuring a framework and plan to create an organization that continuously improves its business processes and use of ERP software.

These four best practices are critical areas that we have seen in effective and successful ERP implementations, but which are typically absent in troubled or failed ERP projects. These are some of the remediations we often bring to the table when clients hire us to clean up their ERP implementations and constitute the core of the some of the best practices we implement when clients hire us to manage their implementations from the start.

For more information, download Ten Tips for a Successful ERP Implementation and join us for our upcoming webinar, Tips on How to Build a Business Blueprint for ERP Systems on March 22 at 10 a.m. MT.

Pinch Hitters’ Guide to Six Sigma and ERP

Six Sigma is a term companies equate to resource overload, too much money, and time consumption, which can certainly act as a deterrent for companies focused on the bottom line. However, because ERP software is often used to improve business processes, it can be of great functional and financial benefit to use Six Sigma to understand where the business processes are inefficient as well as the pain points associated with them. This will lead to a better understanding of the overall improvements and business benefits enabled by the software package.

Six Sigma principles can be applied to ERP implementations without the investment of additional resources, training or extended timelines. Using a Six Sigma quick hit approach throughout an ERP project can provide all of the benefits of Six Sigma and ensure your ERP system is designed with the highest level of efficiency. It also will capture overall cost savings and help create the business case for the project.

The Six Sigma ERP Project Quick Hit Approach

Six Sigma is a methodology that consists of five basic elements: Define – D; Measure – M; Analyze – A, Improve –I and Control – C. Each phase contains specific tasks, or steps, be completed to move into the next phase of the methodology. By performing the simple tasks outlined within each phase below, you can incorporate Six Sigma into your ERP project and realize the benefits of using the methodology. 

Define

During the define phase, it is critical to identify the problem statement and project overview. The problem statement describes the current state of the project and is an overall summary of the problem. One must identify a specific metric that is observable, measurable and manageable. Similarly, it is important to identify the project goal. What is the desired performance for the identified metric? Again, this should be a SMART goal – specific, measurable, attainable, relevant and time-bound. Once key metrics are identified, a baseline must be established to measure the success of the ERP software. Similar to all projects, a timeline must also be established. This measures the performance of the team and allows management to understand the time commitment associated with the ERP implementation. It also is critical to calculate the ROI for the project. Although specific data points may not be known, making a conservative, educated guess will help obtain executive support and buy-in for the project. These costs and savings can be used to develop the ERP business case.

Measure and Analyze

To appropriately measure and analyze a process, the ‘as is’ process must be mapped using generic flowchart shapes and symbols. The mapping phase is when pain points within a process or processes are identified. Pain points can be anything within a process that causes pain for the individuals performing the tasks, or bottlenecks within a system that result in inefficiencies. Once pain points are identified, it is critical to understand their root causes. This will help put the appropriate ERP solution in place to reduce the pain and improve process efficiencies. There are many Six Sigma tools that can help identify root cause including, cause and effect diagrams, fishbone diagrams and regression analysis. A personal favorite is the 5-Why Analysis. This approach asks the question ‘why’ five times to help uncover the true root cause of a problem. Once root cause is determined, recommended actions can be discussed and put in place. Often, ERP projects have multiple processes that require improvement; these processes are typically critical to the business and provide the business with its competitive edge in the market place. The mapping step can facilitate the ERP business blueprinting process to ensure there are no areas of the business, which if lost during ERP software implementation, could result in a catastrophic business disruption.

Improve

When solutions have been identified and put in place, it is important to revisit the original ‘as is’ process map and redesign it with the revised actions put in place; this becomes the ‘desired’ process state. The desired process will no longer display the original pain points and will represent a more efficient process. A new ROI calculation can be completed putting in actual data to realize and confirm actual financial impact and savings of the improvements. This data can be used for the ERP business case.

Control

When improvements are in place and have been measured, it is necessary to complete a control plan. A control plan tracks the targeted metric goals and identifies the actions to take place if the metric falls below its goal. A chart that tracks metric performance daily, weekly or monthly should be put in place to validate and continue to measure ERP project success.

Six Sigma is a simple method companies can use in conjunction with their ERP selection and implementation projects. Not only can the business apply Six Sigma principles throughout a project and gain process improvement efficiencies, but it also allows the business to measure the overall success of the project at both the business metric and financial levels. Learn more about how Panorama’s Six Sigma and Value Stream Analysis service offering can help your organization achieve ERP success.

Written by January Paulk, Senior ERP Consultant at Panorama Consulting Solutions.

Can Traditional Project Management Keep Its Place in the IT World?

Revelations about the IT failures of the new millennium suggest not!

A recent study of over 1,400 organizations reveals some startling new facts about mega-failures in IT, including huge overruns. Whilst the study found average overrun was 27-percent, one in six organizations actually overran their budgets by 200-percent and schedules by 70-percent! That is failure on a massive scale by anyone’s standards.

In the article Why Your IT Project May be Riskier Than You Think in September’s Harvard Business Review, Bent Flyvbjerg and Alexander Budzier explain the findings from Flyvbjerg’s Oxford University study of 1,471 IT projects, costing between $167 million and $33 billion. It makes for bleak reading, particularly the wide ranging impact of such failures. The authors cite Auto Windscreens as a prime example. In 2006 the UK company, which employed 1,100 workers, went into liquidation following a botched ERP implementation.

So is the popular approach to managing IT projects inadequate for the task or is there something more sinister at play here? Traditional project management has its roots in the construction industry and it still works for a house you can see or a bridge you can walk over. But IT is rarely a tangible artifact. People have difficulty imagining what it is they are getting (or going to get) from their new CRM or ERP system. And  this lack of understanding exacerbates the problem.

Another finding is the inherent blindness to blow-out. In a similar study in Germany led by Sascha Meskendahl of the Technical University in Berlin, 67-percent of companies failed to terminate unsuccessful IT projects. This is despite gateway reviews and governance maturing with the increased adoption of the International Standard for Governance of IT: ISO 38500. There’s no question it takes courage to stop a project when vast amounts of money have already been spent. The National Health Service, for instance, has finally called it a day on its e-health system which was set to electronically revolutionize health care in the UK. But it took nine years and a staggering £11 billion of investment to arrive at their decision.

Traditional project management makes some fundamental assumptions: everyone understands the scope, sufficient reserves have been allocated in the budget for contingency and governance groups are empowered to call a halt any time along the way. And of course, the biggest assumption is that the business case is accurate, realistic and regularly reviewed. But the complexity of IT, and in particular ERP roll-outs, demand much more than this.

Flyvbjerg and Budzier’s analysis of successful projects highlights some rigid rules adhered to by organizations that manage to avoid failure. First is to stick to the basics. As any football coach will explain after a win, get the basics right on the field and the excellence will shine through. According to the authors, IT project winners succeed when they stick to the agreed schedule even when big events like an unexpected merger have the potential to lure them away from the plan. They tend to focus on the readiness to go live and measure all activity against that yardstick. They resist scope creep and break down large programs into manageable projects. Successful organizations also invest in IT experts, paying enough to retain them for the duration of the initiative.

Whilst these basic rules lie at the heart of IT success, it is clear that the mammoth failures will continue if this study’s alarming findings are not taken to heart.

The authors maintain that some fundamental questions have to be asked before the business case is approved. Can a 15- to 50-percent non-realization of benefits be accepted without too much pain? If aggregated medium-sized projects suffer a 200-percent increase in cost estimates, will the organization be able to cope with that loss? How will the organization absorb a 400-percent blow out if the improbable happens? Regrettably the improbable is occurring with alarming frequency. Additional advice includes:

  • Scenario plan for the bleakest outcome. Before the business case is built, project leaders should brainstorm some worst case scenarios. Flyvbjerg and Budzier provides ideal material to kick-off the exercise. For example: K-mart’s investment in a $1.4 billion modernization of its supply chain management was cited as one of the reasons for its bankruptcy.
  • Review your success rates. If nothing changes, then nothing changes. Often a straightforward review of past business cases will provide an accurate forecast of success rates. Calculating the margin of error in the last tranche of  business cases against the cost and duration of projects subsequently delivered can be a revelation. If there is a pattern of significant misses then something fundamental has to change.
  • Build in a blow-out budget. This is not the same as contingency planning. Contingency planning more often is focused on costing what you know may go wrong. Blow-out budgeting is more about financing for what you don’t know. It is built from the bottom up assuming a 50-percent,  a 100-percent and a 200-percent blow-out.

As the complexity of IT expands beyond the intellectual capability of all but the most agile executive then financial management and project leadership has to at least keep pace if not move faster than ever before. The stakes are too high for any organization to do otherwise. But where does this leave the project leaders of the future? For starters they must tighten scope control, tenaciously pursue benefits and inscrutably validate business cases. And most importantly, engender a culture which will accept a no-go decision without recrimination. On the dollar front, Flyvbjerg and Budzier’s advice still leaves a lot to worry about. As the world grapples with volatile economies and the ever present threat of recession, organizations simply cannot afford to take the risk.

There is one significant risk mitigation that has proved its worth and that is the appointment of a specialist ERP consultancy like Panorama. Learn more about their ERP and IT services for ERP implementations of all sizes.

 

Note: The inclusion of guest posts on the Panorama website does not imply endorsement of any specific product or service. Panorama is, and always will remain, completely independent and vendor-neutral.

Project Leadership Versus Management in an ERP Implementation

Which is more important for the success of an ERP implementation: project/technical management skills or project leadership skills? Before getting into the answer, lets try to define both management and leadership.

There are various definitions for both. In its simplest form, management is about creating and maintaining a sense of predictability in the project. And that could be in either technical or non-technical activities. Management is about proactively identifying issues before they occur and then resolving or mitigating them so that the project can progress as planned. On the other hand, leadership is about producing changes. It produces changes for betterment, for opportunity and for a better overall direction in the journey of the ERP project.

Surprisingly, the definitions of management and leadership seem to contradict each other. While management is all about monitoring, controlling and problem-solving, leadership is all about establishing a direction, preparing for a bigger picture  (which requires aligning resources), aligning strategies, and aligning tasks and activities. In a very simplistic way, while management follows a goal through defined activities and paths, and thus removes obstacles towards the goal, leadership defines the activities/paths necessary to see what could be done to reach to the goal – an activity which is bigger than the project goal.

Now if managing a project is all about reaching the project goal why would project leadership be needed at all? There is no doubt that without strong project/technical management, the success of a project could be in jeopardy. But the success of the project is not only dependent on following certain well-defined tasks, whether technical or non-technical. Projects bring activities, people, and environments together, which creates dynamic conditions. However, managing – and taking advantage of  – this dynamism requires leadership to envision future opportunities, inspire and motivate people to contribute, and empower people to make tough decisions.

For an ERP system implementation to be successful, both qualities are needed. Success requires a fine balance between following predefined tasks in a disciplined manner and taking advantages of changes for both the betterment of the team and the project. Imagine a sports team: any member of the team can play the game but its the coach who not only makes sure the players can perform all the necessary tasks but also motivates them to contribute their best in a team environment, strategizes to bring out the best in everyone and sometimes even changes the direction and/or strategy to win the game. Ultimately it’s not about fighting the battle with management but about winning the war with leadership. A team of soldiers can win a battle but a leader can help them win the war.

Blog entry written by Ipsita Mitra, Director of ERP Selection and Implementation at Panorama Consulting Solutions.

Thirty-Five Guiding Principles for Every ERP Project Manager

Project Managers are leaders and managers. While their focus is generally centered on managing the actual ERP project, they always need to lead and manage themselves first. Over the years I’ve had a great deal of experience, dealt with a variety of clients, and managed a diverse group of projects. Over the years I have learned a lot about ERP software and myself.

Below is a list of thirty-five principles and reminders that I revisit before starting an ERP project. While I visit this list at the start of an ERP project, I’ve also found it wise to revisit the list multiple times throughout the ERP project’s life.

  1. As much as possible, get status and updates from everybody every day. Everyone is important. Everyone has been doing more than you know.
  2. Listen intently. Use deliberate eye contact. Give attention.
  3. Give a heart-felt effort to understand.
  4. As much as possible, make your communications a gift to others.
  5. Create order out of disorder.
  6. Give and give and give without needing to receive back.
  7. Try not to block the words of others. You don’t want to miss the good things that others have to share.
  8. Project Managers are leaders. Take the lead. Have a plan. Prioritize. Have an agenda. Anticipate. Be an example. Lead the way.
  9. Adapt to local terminology when you can. Create terminology and definitions when you must.
  10. Be curious within your need to know.
  11. Stimulate imagination and adherence to purpose to ignite and sustain vision.
  12. Re-frame and re-frame information and concepts until people “get it”. Aim to explain with new phrases, new diagrams, and whatever it takes.
  13. Keep team and end user involvement high to generate more buy-in and to keep progress moving.
  14. When there’s too much to do and you don’t know which step is best, just do the next thing that you see in front of you.
  15. Respect everyone’s time by being prepared.
  16. Remember that it’s the business processes that count. Technology provides the tools.
  17. Hi-tech is great but sometimes lo-tech, high-touch (as in touchy-feely solutions are a better fit).
  18. Sometimes it helps to plan backwards. Keep the end purpose in mind.
  19. Use simple tools when you can.
  20. Use posters, wall charts, white boards and projectors at times rather than email and file attachments.
  21. Applaud strengths and excellence. Applaud the overcoming of obstacles.
  22. Email is a great tool for communication but don’t forget that the phone and face-to-face will sometimes work better.
  23. When you reach important milestones, celebrate!!
  24. Celebrate the small wins too (even if you’re a party of one).
  25. Use all of the sincere confidence that you can muster.
  26. Be discreet.
  27. Be a cheerleader. Encourage. Avoid scorning and scoffing.
  28. Keep secrets and maintain your trustworthiness.
  29. Give honor where honor is due.
  30. Give gratefulness where gratefulness is due.
  31. Build relationships ahead of your need to ask for a favor. In some relationships, you will give more than you receive. In other relationships, you will receive much more than you give.
  32. Collaborative teamwork and working together is beautiful to behold and something to celebrate.
  33. As basketball Coach John Wooden said: “There is no substitute for work. Worthwhile things come from hard work and careful planning.”
  34. There exists science and there exists art. Both have their place.
  35. Pursue excellence. Pursue Kaizen (continuous improvement). Keep pursuing when the project is complete.

The complete list of principles may not apply to every project, so pick and chose those items that are relevant to your project and your project management style. They have helped me over the years and I believe they have provided a strong foundation for both me and my project teams.

Blog post written by Greg Griffith, a Project Manager at Panorama Consulting Group.

Overcoming ERP Project Fatigue

It’s inevitable. It’s often ignored as part of the ERP selection and implementation process. Yet ERP project fatigue jeopardizes the quality and timeliness of deliverables. It also decreases job satisfaction for some of your best and brightest employees who have been selected for your project.

What Should an ERP Project Manager Do to Reduce ERP Project Fatique?

  • Expect Fatigue – No matter how talented and experienced your team may be, plan for energy and enthusiasm to wane towards the middle of a project. The work seems endless, the end seems far away, and the work that has already been done feels long forgotten. The tough lingering questions about business processes may be hindering progress, and the necessary battles for progress are often thankless. Fatigue is inevitable. This is especially true with less experienced project members, who aren’t familiar with the phases and big picture. A wise project manager will be ready to respond to project fatigue before it begins affecting the performance of the project team.
  • Assess Fatigue – This is easier than you think. A good relationship with your project team goes a long way towards supporting the kind of honesty that keeps you in tune. Take the time to address a wide range of issues with your team, beyond the next deliverables and milestones. Survey questionnaires are a great way to solicit input and check attitudes. Surveys also demonstrate a manager’s willingness to hear complaints and acknowledge difficulties, promoting a culture of truth. Take stock of attendance, punctuality, deadlines, and engagement at the beginning of your project. If you have established expectations for punctuality and efficiency, it will be easier to spot observable behaviors that indicate problems. Think of the chronically late and double-booked folks, and consider whether they are fatigue candidates.
  • Acknowledge Fatigue – An integrated project activity calendar can illustrate when heavy demands are ahead. When fatigue becomes evident or suspected, acknowledge the reality and impacts of the problem. This is an opportune time to extend recognition for extra efforts, and make sure tangible rewards or encouragement is forthcoming.
  • Combat Fatigue – There are a number of effective ways to mitigate sources of fatigue. Expecting, assessing, and acknowledging the problem are critical starting points. Now what?
    • Incorporate project member’s wellbeing into regular status reports, adopt a scale which reflects the level of work load and required effort to meet demands.
    • Think about your rewards and recognition plan. Communicate it clearly, and follow through.
    • Don’t overlook the rejuvenation a fun break can provide. Search online (for example, www.training-games.com has 40 free ice-breaker activities) for quick activities that build the team while clearing the air with some lightheartedness.
    • Adjust timelines to workloads if needed.
    • Allow occasional work from home days for appropriate tasks.
    • Consider “role sharing” and encouraging teams to rotate tasks.
    • If project members have competing demands on their time (ie. being still accountable for operational duties), advocate to the highest level needed for additional resources. The effort will be appreciated, even if the request is denied.
    • Get more mileage by communicating your efforts to combat fatigue.

Stress and fatigue are inevitable in an ERP project. Being a leader who actively combats them better positions your project for an on-time delivery. Take the time and effort to plan your combat approach, so both you and your project team will benefit.

Blog entry written by Lena Laakso, Manager of Organizational Change Management at Panorama Consulting Group.

Limited ERP ROI – Technology Versus Business Focus

The majority of large ERP software implementations are executed as IT projects rather than strategic business initiatives.  An IT budget is established, an ERP implementation team is assembled, significant investment is made, and a “go-live” date is embarked upon.  The measurement of success: the project is on-time and on-budget and the ERP system is being used.  True return on investment, or ROI, is an afterthought.

As companies begin to scrutinize their return on investment, many are recognizing that they have made a substantial IT investment and undergone considerable organizational change to, in effect, alter the face of their IT infrastructure, with minimal performance improvement in their core business operations. In many cases, ERP software configuration (aka flexibility) has allowed poor-performing, fragmented business processes to continue within the new ERP system.

The power of today’s ERP software packages is that they allow different parts of a company to operate more effectively by sharing information and workflows through a tightly integrated ERP system.  The enterprise software also helps to systematize and reinforce discipline around what were previously ad hoc and disparate business practices.

The challenge is to define and implement new process and organizational designs, enabled by the ERP software solution, to rapidly produce measurable business value. This emphasis on integrated business transformation, in lieu of a narrowly defined ERP implementation, is critical for achieving business goals and maximum return on investment.

Blog entry written by Terry Delaney, Senior ERP Project Manager at Panorama Consulting Group.

Charting The Course

Launching an ERP Implementation means clear communication about the purpose and expected benefits. A Project Charter is a good way to clearly and concisely make a statement about why it’s important. Here is a sample Project Charter that fits the bill.

Project New Biz Charter

ABC Company is undertaking a major initiative to upgrade its business systems through the implementation of ERP XYZ. Driven by anticipated changes in the way business will be conducted in the future, as well as increasing ABC CO’s competitive advantage, ABC CO has selected ERP XYZ to serve as its business system.

ERP XYZ will enable ABC CO to achieve the following major benefits:

  • Agility to improve and change business processes and practices as prompted by new business requirements or as improvement opportunities are identified
  • Standardized data structures and transaction processing across ABC CO’s business
  • Improved communications among and visibility across ABC CO’s operations
  • A technological platform that will facilitate interfacing with customers and suppliers
  • Continuous enhancements of software functionality through future vendor releases, which will help keep ABC CO in pace with technological advancements

As part of the implementation process, ABC CO desires to leverage Project New Biz as an opportunity to rethink ABC CO’s current operations and processes. The objective is to take full advantage of the software’s built-in functionality, while maintaining and improving systems in support of ABC CO’s businesses.

In summary, ABC CO is focused on operational excellence; the foundation for achieving this is Project New Biz. Project New Biz should be considered a significant strategic step for ABC CO in preparing for the future.

Three Things That Cause ERP Projects to Fail

As we outlined in the four-part series of our 2008 ERP Report, most ERP projects go over budget, take longer than expected, and fail to deliver expected benefits. Based on this research of 1,300 ERP implementations across the globe, there are three common things that are likely to cause an ERP projects to fail:

  1. Choosing the wrong ERP software. Companies with failed ERP initiatives often try to force fit an ERP solution that isn’t right for their organization. Many organizations incorrectly assume that there are only a handful of viable options in the marketplace. There are dozens of viable ERP solutions, some focused on specific industry verticals that may be able to handle your specific business requirements more effectively than the better known packages. In addition, even for organizations that are considering only Tier I solutions, it is important to clearly define business requirements and have a thorough understanding of the solutions’ ability to meet those needs. These activities should be an integral part of your ERP software selection approach.
  2. Setting unrealistic implementation duration and cost expectations. As we often tell our clients, vendor sales reps make a living by selling software, not by setting realistic implementation expectations. The successful ERP initiatives in our study were much more likely to leverage internal and/or external expertise to help define a realistic and customized implementation plan and budget rather than rely on canned materials from a sales proposal. This should be a key part of your ERP selection and planning process.
  3. Failure to manage the ERP software vendor and ERP project scope. Once an ERP solution is selected, the real work begins. It is ultimately up to the implementing company – not the ERP vendor – to ensure the project is a success. Although the vendor and other third party consultants will bring valuable expertise to the project, organizations need to manage them as they would any other vendor or employee. This includes effectively managing project controls, customization requests, project scope, implementation strategy, etc. The ERP implementation planning process is an important first step, but the implementing company needs to carefully manage all aspects of the project throughout implementation.

Companies that successfully address the above three areas are much less likely to experience failed ERP implementations. More importantly, these three steps will get your organization started on the path to ERP success and benefits realization.

Four Reasons Why ERP Projects Take Longer Than Expected

During the ERP software selection process, it can be difficult to know exactly how long the chosen software will take to fully implement. While software sales reps will typically provide optimistic scenarios, they often do not take into account key activities and other considerations that can materially affect the implementation duration. In fact, according to Panorama Consulting’s 2008 ERP Report, 93% of ERP projects take longer than planned.  With that in mind, it is important to go into the software selection and implementation planning process with eyes wide open.

Four Key Reasons Why ERP Projects Take Longer Than Expected

  1. Unrealistic expectations. The first and most common problem is with unrealistic expectations. When an ERP project team underestimates the time it will take to complete the implementation, they tend to skimp on important activities such as organizational change management or process design, which then creates more risk and delays as the project progresses. Given the snowball effect that it creates, misaligned expectations is often the first domino to fall in a failed ERP project.
  2. Not adequately accounting for business-oriented activities. ERP is about much more than the software. While it is relatively straightforward for an ERP software vendor to estimate how long it will take to install and configure the software, it is much more difficult to predict activities that are not directly related to the software. For example, defining business processes, making decisions about how the software should be configured, and facilitating conference room pilots are key activities that are important, yet difficult to predict.
  3. Lack of resources to dedicate to the ERP project. It is important to have clear assumptions in your project plan about how many internal and external resources will be supporting the project. We see many companies agree to a project plan with their chosen vendor, only to find that the two parties have differing expectations of how many and what types of people will support the project.
  4. Software customization. An overwhelming majority of clients we work with intend to implement their chosen ERP software out of the box with little to no customization. However, once implementation begins, project teams will inevitably find at least a handful of functionality gaps that they would like to address by changing the software. In fact, Panorama’s ERP Report found that only 18% of companies implemented their chosen ERP solution with limited or no customization. So while it may not be realistic to suggest that there will be zero customization to the software, it is important to prioritize and limit the amount of customization to help contain costs and time.

While ERP projects are always challenging, they don’t need to take longer than expected. Companies should begin by setting realistic implementation expectations during the ERP software selection process, then manage resources and customization to stay on schedule. Leveraging the assistance of an independent ERP consulting firm will also help create a realistic implementation plan that considers the project activities required for success and minimizes overall project duration and cost.

Pitfalls of the ERP Business Case

One of the biggest selling points that ERP or IT software vendors use is that implementing their product can result in a short payback period with a healthy return on investment (ROI). While there is some truth to this possibility, such an ROI is only achieved if you develop a realistic business case. This helps manage project expectations and manage business benefits after your ERP system is implemented.

Here are some commonly overlooked aspects of developing a solid business case that will drive measurable business results:

Identify Hidden Costs. Many costs associated with a large ERP implementation are obvious.  For example, software licenses, implementation services and data conversion are all direct costs that make it into most business cases. However, there are others that are not so obvious, such as internal resources required to support the project team, costs to backfill the day-to-day work of project team members, process improvement, hardware upgrades, training, and organizational change management. All of these costs should be included to accurately reflect the true total cost of ownership of your project.

Document Costs Associated with Benefits. In many cases, technology makes a company more efficient, which may ultimately result in an overall headcount reduction. However, there are costs associated with reducing staff, such as severance and reorganization costs. In addition, even though there are long-term benefits associated with making employees more efficient and effective as a result of the new system, there is usually a short-term decrease in efficiency as employees learn. These costs should be quantified in a business case as well.

Track Benefits After Implementation. Developing a business case is only half the battle; tracking and realizing business benefits is the other half. Prior to go-live, it is important to develop lower-level operational measures that directly relate to the dollars identified in the business case. These measures should then be assigned “owners” within the company who will be responsible for monitoring and tracking actual results. Then, after go-live, actual business benefits should be measured and compared to the business case on a regular basis to identify areas for improvement.

Obviously, there are many other aspects to developing a business case. By avoiding these common pitfalls, however, you are much more likely to have an air-tight business case that drives measurable business results and contributes to an overall ERP benefits realization program.

Open Source ERP Solutions, Ready For Primetime?

When we evaluate ERP solutions for our Perfect Fit clients we are sometimes asked for our opinion on Open Source ERP solutions. We are starting to see more Open Source solutions entering the ERP market and as they mature we expect to see them become more mainstream. The fit of an Open Source ERP solution would be based on the willingness of our client to assume a higher level of risk. Having said that, I recall the early days of Linux acceptance when some people felt it was heresy to consider an Open Source OS for business critical applications. My, how times have changed.

Here are a few Pros and Cons to consider about Open Source ERP solutions.

Open Source ERP Solution Pros

  • The initial cost of an Open Source ERP solution is usually far less than a comparable proprietary program since there are no license fees.
  • The TCO of Open Source ERP solution maybe less given the option of virtually free operating systems (Linux)and databases (MySQL) and potentially lower maintenance fees. One caveat being higher support costs if major customizations are made.
  • Open Source ERP solutions are infinitely customizable allowing for companies to mold them to meet specific business process requirements.
  • Open Source ERP solutions typically have a wide range of integration formats simply because they need to play well with other software components.

Open Source ERP Solution Cons

  • Finding implementation and support resources for Open Source ERP solutions can be difficult.
  • Some add-on software isn’t compatible with Open Source ERP solutions.
  • Proprietary software has more features.
  • Because Open Source ERP solutions are more customizable internal support requirements may be higher.
  • It is fair to question the longevity of Open Source ERP solutions given their immaturity.

If you are interested in more information on Open Source technologies I suggest you check out www.OpenSource.Org or some related blogs on IT Toolbox.

Seven Key ERP Success Factors

We recently conducted an ERP poll to identify the factors that ERP experts find to be the most important to successful ERP projects. Based on the findings of the study, here’s what percentage of participants find each of the following the most important success factor.

ERP Success Factors

  • Strong Program Management – 6%
  • Executive Support and Buy-in – 19%
  • Organizational change management and training – 13%
  • Realistic expectations – 8%
  • Focus on business processes – 5%
  • All of the above – 48%

The good news is that it appears that people in the industry realize the importance of each of these items. However, it’s obviously easier said than done since so many ERP projects ultimately fail.

Ways to Make Your ERP Project Successful

  1. Focus on business processes and requirements first. Too often, companies get tied up in the technical capabilities or platforms that a particular software supports. None of this really matters. What really matters is how you want your business operations to run and what your key business requirements are. Once you have this defined, you can more effectively choose the software that fits your unique business needs as part of your ERP software selection process.
  2. Focus on achieving a healthy ERP ROI (Return on Investment), including post-implementation performance measurement. This requires doing more than just developing a high-level business case to get approval from upper management or your board of directors. It also entails establishing key performance measures, setting baselines and targets for those measures, and tracking performance after go-live. This is the only way to realize the business benefits of ERP.
  3. Strong project management and resource commitment. At the end of the day, your company owns the success or failure of a large ERP project, so you should manage it accordingly. This includes ensuring you have a strong project manager and your “A-players” from the business to support and participate in the project. A strong project implementation plan and execution is key to ERP success.
  4. Commitment from company executives. Any project without support from it’s top-management will fail. Support from a CIO or IT Director is fine, but it’s not enough. No matter how well-run a project is, problems arise (such as conflicting business needs), so the CEO and your entire C-level staff needs to be on board to drive some of these
  5. Take time to plan up front. During the software selection process, an ERP vendor’s motive is to close a deal as soon as possible. Yours should be to make sure it gets done right. Too often, companies jump right in to a project without validating the software vendor’s understanding of business requirements or their project plan. The more time you spend ensuring these things are done right at the beginning of the project, the less time you’ll spend fixing problems later on.
  6. Ensure adequate training and change management. ERP systems involve big change for people, and the system will not do you any good if people do not understand how to use it effectively. Therefore, spending time on money on training, change management, job design, etc. is crucial to any ERP project. This should all be included in your ERP organizational change management plan.
  7. Make sure you understand why you’re implementing ERP. This is arguably the most important one. It’s easy to see that many big companies are running SAP or Oracle and maybe you should too, but it’s harder to consider that maybe you don’t need an ERP system at all. Perhaps process improvement, organizational redesign, or targeted best-of-breed technology will meet your business objectives at a lower cost. By clearly understanding your business objectives and what you’re trying to accomplish with an ERP system, you will be able to make a more appropriate decision on which route to take, which may or may not involve ERP.