Telesoft

In this article:

Top 10 ERP Project Management Headaches

Successful Project Manager Characteristics

Managing Risk on ERP Projects

Enterprise Resource Planning (ERP) systems have fundamentally changed the work of IT organizations. The sheer size and complexity of ERP implementations makes managing these projects difficult. There are really two basic sides to ERP management, people and technology. An ERP package touches the entire organization and can affect nearly every employee. And in some cases, an ERP project manager may not be able to know who will be affected, which can lead to some nasty surprises. One mismanaged ERP implementation left a southeastern electronics manufacturer unable to accept deliveries and nearly closed a plant.

It's also difficult to get a clear vision of the technological portion of the implementation because of the vast combination of hardware and software involved. The project manager must cope with thousands of parts. Whether you are implementing one module or multiple modules, you must ensure consistency and full integration across the various subprojects, which is an enormous effort, even for an experienced system architect.

I did an informal survey of experienced ERP project managers from various corporate IT departments and Big 5 consulting companies, and assembled an unofficial list of the major problems faced by ERP project leads and managers. Almost everyone mentioned size first. Staff problems and organizational politics also ranked in the top ten.

Top 10 ERP Project Management Headaches

According to the Eden Prairie, Minnesota Gartner Institute (a spin-off of the Gartner Group), the gap between the promise of an ERP system and the business value actually delivered once the project has been deployed is great. Enormous cost overruns, deadlines missed in some cases by years, and even abandoned implementations make clear that managing ERP projects is a complex task.

Successful Project Management
Perhaps the single most decisive element of ERP success or failure is the knowledge, skills, abilities, and experience of the project manager. An ERP project manager must understand both the business and the technology. To avoid customization, businesses frequently change their business processes to fit the new software. An ERP project manager must understand the impact of the ERP implementation on the business, and work with business managers to ensure a smooth transition from the "as is" to the "to be" business operating environment.

To help educate project managers, The Gartner Institute created a project management certification program that includes an ERP specialty. The program and its courses focus on the critical issues that make ERP projects different from typical application development projects. This includes planning for the unusually large risk and complex cross-functional issues that accompany most ERP projects.

Using the findings from an on-going Gartner Institute research study, which involves brainstorming sessions with experienced project managers, the course provides the core project management techniques that account for the success or failure of ERP projects. Some core topics include gathering business requirements, blended workforce project organization, entry-, exit-, and acceptance criteria issues, change control and closure. The Gartner Institute also includes risk management, project planning, and scope management as major tasks for project managers.

A project manager must be flexible enough to roll with the changes as the project progresses, and not lose it when unpleasant surprises pop up as they always do during ERP implementations. They must be able to work with nearly every individual in the organization, from the most technical IT staffer or plant engineer, to the mailroom and building maintenance staff. They must also possess the ability to learn extremely fast, because they will need to understand business issues in areas of the organization with which they are unfamiliar.

An ERP project manager must also be highly disciplined. They must be able to clearly envision the project end game, and then hold the entire organization to the road that leads to that successful end. This means bringing other team members back on track when deviations occur or distractions arise. They must also be willing to make tough decisions, and understand that those decisions will upset some and please others. A thick skin is certainly an asset.

Successful Project Manager Characteristics

A successful ERP project manager…

• is flexible
• is disciplined
• is a quick learner
• is a good decision maker
• has ERP experience
• has business experience
• has political clout
• has a good formal education
• is well liked
• motivates staff

Source: Gartner Institute.

Deciding On Project Scope
Scope management procedures must also be created and enforced to prevent "never ending project" syndrome. Constant scope changes, whether increases or decreases, cause confusion among project team members. The primary focus of scope management is on defining and controlling what is and is not included in the project. The project manager must work with other departments to clearly define the project scope. If the project scope is not defined properly, required work is missed, jeopardizing the project success. On the flip side, work outside the scope of the project may be done, hurting the budget.

The scope of an ERP project has several components. The ERP project team must decide which business processes will be included in the implementation. This decision, in turn, effects which ERP functionality will be implemented. If an organization has more than one business unit or line, the team must decide which divisions to include in each phase of the rollout. The IT organization must determine which technologies will be replaced and upgraded, and which will exchange data through interfaces, until the rollout is complete.

Managing Risk on ERP Projects

Managing risk on an ERP project is crucial to its success. What is a risk? Simply defined, a risk is a potential failure point. There are thousands, maybe even millions of potential failure points on an ERP project, in the form of untested technology (and untested staff!), political landmines, and even nature's fury. (A tornado during an ERP weekend go live? Yes, it's happened.) So, how do you keep the failures at bay? While various risk management books and methodologies offer variations on a theme, there are generally 5 steps to managing risk:

Project team members must rely on their experience and advice from others to find potential failure points or risks. Track through the entire project plan and look for areas of uncertainty. One of the easiest and most effective ways to find potential failure points is to talk to other organizations that have done the same projects. Cost estimates are probably the most common potential project failure point. Other potential failure points include lack of an executive sponsor, an underqualified project manager, and no clear objectives for the project.

The next step is to determine the severity of the potential failure on the budget, project timeline, or the users' requirements. Assessing the likely impact and the probability of the failure occurring is more art than science, requiring in-depth knowledge of both the ERP package and the business. A risk management team should be built that brings together those individuals that have the knowledge and experience to know what might happen. This team must have experience in implementing the specific ERP package for an organization approximately the same size and in the same industry as yours.

Based on the first two factors, prioritize the risks. Decide which risks should be eliminated completely, because of potential for heavy impact on critical business processes. Set up a monitoring plan for risks that should have regular management attention. Make the entire team aware of those risks sufficiently minor to avoid detailed management attention, but which the team should watch for potential problems.

You mitigate risks by reducing either the probability or the impact. The probability can be reduced by action up front to ensure that a particular risk is reduced. The project risk plan should include a set of steps to recover from each risk, should failure occur. The team must know the person accountable for recovery from each specific risk, and the action to be taken to resolve it. The team must know the symptoms of the impending failure, and act to prevent it from occurring if possible. An example is to test a particular operating system or hardware component to prove that works prior to go live. Doing a pilot implementation or prototyping the first set of ERP interfaces are both examples of risk mitigation.

To prevent scope problems, make sure a project charter or mission statement exists. Be sure to really nail down the project requirements, and have them documented and signed by the users and senior management. Clearly define change control procedures and hold everyone to them. Tight change control procedures may end up causing tension between the project team and those who do not get changes they want. Ultimately, though, the project can't be successful if the project team is trying to hit a constantly moving target.

Discovering Gaps
No software, no matter how big and sophisticated fits every organization perfectly. And although ERP vendors will tell you that their software will solve all your problems, there will still be gaps. These gaps may be small, or extremely large and problematic. ERP project managers frequently run into political minefields when doing gap analyses. The main problem is that each time a gap is identified that costs additional dollars to fix, someone, somewhere in the organization is going to ask, "Why did we spend all that money if the software doesn't do what we need?" This can cause the executive sponsors to look bad, and push back at the project manager to "make the gaps go away." This, in turn, leads to user frustration and dissatisfaction with the rollout.

To solve this problem, be extremely thorough in the package selection process, and make sure everyone at every level knows what the software can and can't do. Start creating a gap document early, because the gap analysis document is very useful for stakeholder management. It provides direction on project management, and provides a clear knowledge of what will need to be done. The review of gaps and design of the adapted implementation program should detail the change scope, cost, and benefit, as well as the adapted project plan.

The Right Staff
It's absolutely critical to get the right people involved early. Leaving out the wrong person has both project-related and political implications. A project manager must look at the scope of the project beyond the ERP software itself, and examine the interfaces to be built. Each business area with which the ERP software will communicate must be involved. There's often a tendency to develop "tunnel vision," where the ERP implementation team only works with those users and organizational staff immediately involved with the rollout. Invariably, the project team discovers that a critical piece of knowledge is missing because they didn't get the right person involved early.

Of course, one of the major issues with any IT project is the staffing issue. Good technology staff, particularly those with deep ERP experience are extremely hard to find. Since it's difficult to transition ERP team members on and off projects, it's a good idea to identify staff members that are critical but are high turnover risks early in the project. A project manager can develop recognition programs that help retention. ERP projects can be long and frustrating so it's also helpful to set up events for employees to communicate and vent about the working environment. Another trend is to implement flextime to allow employees greater flexibility in setting work hours within limits. Some studies show that flextime results in significant productivity increase and employee satisfaction.

Preventing Brain Drain
Another problem faced by ERP project managers is the need to integrate consultants with corporate staff and ensure a smooth knowledge transfer when the consultants leave. One large midwestern food producer solved the problem by pairing up consultants with corporate employees in both technology and business areas. The consultants and corporate staff worked side-by-side throughout the implementation. This helped ensure a nearly constant flow information from consultants to corporate staff, and prevented the "knowledge drain" that usually occurs when consultants roll off projects.

Project Scheduling
Scheduling and organizing ERP projects is like herding cats. You have lots of people, lots of subprojects, and many potentially conflicting political and organizational issues. It's extremely important to consider all of the issues and develop a clear, concise, and thorough project plan before starting the implementation. An expert project manager creates a plan that addresses the major issues, and is flexible enough to change as the project hits the inevitable bumps in the road.

One of the major problems with scheduling large projects is accounting for time issues with people assigned to the project. These must be identified in the schedule. The proper dependencies and human resources should be requested prior to creating and dating activities in the schedule. It's also important to account for vacations, sick days, and other leave that frequently takes people away from the project unexpectedly. A critical path analysis should also be performed on the project schedule, to determine any potential "show stoppers". A critical path analysis determines which resources absolutely must be present at certain times in the project for it to succeed. For example, if the database for a new ERP system will be built on Tuesday, then the database administrator (DBA) must be there on Tuesday to do the work. In this case, the DBA is the critical path person for the database build task.

Interfacing With Other Systems
An ERP system typically becomes the "center of the universe" for the organization when it's implemented. However, because of gaps in the functionality, time constraints, and political issues, there are usually many interfaces to other systems. Interfacing with legacy data may involve connections to all mainframes, Unix, Windows NT, and other systems. The interfaces must have the ability to handle complex data sources and legacy data types. Other client/server systems must also exchange data with the ERP system. The ERP software may interface with external business partners via electronic data interchange (EDI) or electronic funds transfer (EFT) protocols. With e-commerce on the rise, ERP systems must also be able to send and receive data over the web, particularly in those organizations involved with electronic commerce.

Managing the discovery, analysis, design, and implementation of interfaces can be a nightmare. The data translation and movement requirements alone can cost tens of thousands of dollars. One large midwestern food producer needed a team of 4 people for nearly 3 months to design a set of interfaces for one client/server system. Scope management can help here. The project manager can prioritize interfaces so that mission critical systems engaged in daily processing can exchange data when the ERP software is implemented. Interfaces to systems that do periodic processing- monthly or year-end-can be completed after the initial implementation. Work must be properly prioritized, and ERP team members must focus on immediate needs.

Typical ERP Interfaces

Monitoring Progress
"Riding herd on the cats" means using compassionate micromanagement. While it's generally a bad idea for project managers to try and do everything themselves, they must create very specific work assignments for software developers. Project managers should schedule technical and management reviews at least once a week and track progress carefully against the original plan. It's also important to do a project review at the end of each phase and the project as a whole.

Success criteria for ERP projects are frequently inadequate or even non-existent. The success criteria should be clearly defined in the procedures, methods, and techniques that are part of a high quality project control system. Standards and techniques for measuring the quality of performance expected from the new system should be defined early, and redefined as needed over the life of the project. If success measures are obsolete at the end of the project, then the project can't be evaluated as a success, and may be seen as a waste of money. And who wants to waste $50 million?

Managing Chaos
Managing an ERP project is unlike any other effort because of the huge number of variables, people and risks involved. The complete replacement of an organization's information systems has a tremendous impact on the people in the organization, the company, its suppliers and even its customers. An ERP project manager must guide the project with a firm, practiced hand that both encourages project team members to find new ways to innovate, and at the same time, ensures that everyone and everything is moving in the right direction. An ERP project manager must possess an intimate understanding of the business and how it will change when the ERP system is rolled out, and must also have a solid technical foundation. Anybody seen a cape and some tights around here somewhere?