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 decided 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.

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.

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?