In my years at Case/CNH, I was involved in three major system integration projects. These projects were similar in timeframe (one to two years) and cost ($5 to $10 million), but the results were much different. Inspired by the classic movie with Clint Eastwood, I call these three projects the "good, bad and ugly" of project management. The following is a brief review of these three projects and the valuable lessons that we learned.The first project was necessary as a result of Case Company purchasing the agricultural division of International Harvester(IH) in the early 1980s.The goal of the project was to load all the IH data into the Case parts system and operate with a common parts system for both Case and IH. There was little advanced planning and no additional resources were assigned to complete the project.
There was no project manager assigned and little management oversight and review. Since Case personnel initiated the project, there was little understanding of the features and requirements of the IH system and customers. The data load program and new programs were being written hours before the systems were merged without testing. The merged system had crashes, wrong data, and errors. Not surprisingly, for months following the merger customers, managers and employees were dissatisfied with the results of this project. It was ugly.
The second project involved adding a new forecasting and distribution requirement planning (DRP) system to the existing parts system. A team was formed that identified the required features and did a make/ buy analysis for the new system. After review the team decided to buy the software from ASI and build interfaces with the existing system. A project manager was established and a project team attended several training programs to learn how the ASI module operated.
The new system and integration to the existing system was tested and debugged thoroughly in advance. The system implementation went smoothly, but the system didn't contain the features the users needed. It was discovered that several of the required features didn't work as expected. Forecasts could be only adjusted monthly, monthly forecast buckets were used where weekly buckets were expected, and the system parameters were difficult to adjust. After five years of struggling with the new system it was deactivated and a new system was established. This project failed, because the planning and software investigation at the front end was faulty. I classify the ASI project as bad.
The third project was to establish one global part systems to replace numerous stand-alone systems in various countries. A dedicated project team was established and they identified key features such as: different languages and currency, country/region designations and country of origin codes. The project was planned and the scope approved by management in regard to cost, time, and quality (features) of the new global system. A global project team was established with leaders identified for each country and functional area. There were frequent project updates and project plans were changed as needed. Before implementation users tested each segment of the new project. Testing provided the chance to learn the new system and doubled as user training. Documentation and training manuals were completed. After implementation a "war room" was established to identify and fix unexpected problems. This was a project that I'd classify as "good".
Lessons learned - I learned several lessons from these good, bad and ugly projects.
1. Good planning is the key - The most common reason projects fail is because of poor planning. It is critical to understand: what is going to be done, the goals, what the customers want, how much can be spent, when the project needs to be done, who is available to work on the project, and what are the risks are. Good projects must be well planned.
2. Get management approval of the scope - Once a project plan has been established, management must approve the scope before it can be started. The scope involves time, cost, and project features. Often with management review, the scope of the project is changed. Cost and time are the two areas that are reviewed most closely.
3. Find a management champion - Projects with strong management champions thrive. Identify a company leader who will assist with resources; status reviews and helps identify risks.
4. Establish a dedicated project team - It is very difficult to manage a project with part-time resources. A dedicated team is more expensive, but much more effective in completing the project successfully. A key issue that must be addressed with a dedicated project team is ensuring the project team will have jobs once the project is completed.
5. Track and control scope creep - Scope creep is adding features and requirements to the project after the scope has been established. No projects are truly frozen, but scope creep must be tracked and managed or it will spin the project out of control. One of the axioms of project management is: "What does a frozen project schedule and the abdominal snowman have is common? They are both fictional characters."
6. Provide frequent updates - Project managers often resist giving updates, but it is critical to avoid surprises. Murphy's Law dictates that circumstances will change and frequent updates allow you to identify these changes and adjust the plans.
7. Include training , testing and documentation - It is key that users are trained and the system documented. Having the users do the testing is an excellent way to achieve two objectives at once.
8. Audit your Project - Do a project audit after implementation to identify what went well and what improvements are needed. Even if the last project was bad or ugly a project audit will help you make the next project good.
- Companies create change through project management. Examples of typical projects are establishing new products, merging with other companies, building new facilities, improving processes, and implementing new systems.
- Companies that consistently manage their projects will have a competitive advantage.
- To avoid project management mistakes:
2006 (c) Mark S. Miller, CPM, CIRM
Associate Professor, Carthage College