Project management materials always discuss things in the problem-solving methodology:

1. Define successful criteria, constraints, and release criteria. (Define and understand the problem.)
2. Write a plan, define tasks, identify risks, and estimate costs. (Develop a plan.)
3. (Try the plan.)
4. Record actuals and estimates. (Collect data.)
5. Evaluate at milestones. (Evaluate data to determine if plan succeeded.)

This is all pretty good stuff, but I think it leaves out some pretty basic stuff which no one really quite cares is involved in any major software implementation project.

1. Adequately staff the project. You are more likely to underestimate the amount of resources needed not overestimate. It would be better to overestimate as those resources can be applied elsewhere.
2. Buy-in of the affected. The people who are going to be affected by changing software are the ones who most need to approve the decision to change and provide the information about what it will need to do. A high level manager in Finance probably does not know what the day-to-day needs are in Marketing. Yet all too often, someone without any understanding of what the business processes are makes the decision to go with one product or another because it fits his or her vision.

   This is asking for causing a massive amount of complaints, retro-fitting later, or even abandonment of the implemented product. The more objective and detailed view the decision makers have regarding the actual needs of everyone affected, the better match that can be made between prioritized needs and solution. No, not everyone’s problems can be solved. However, making no effort will result in the decision makers shrugging their shoulders in confusion as to why so many people are upset. They have no strong justification for why they picked on solution or another.

3. Pilot tesing allows those truly masochistic souls to experience the learning curve and bleeding edge while the normal people are safe. Nothing will create more havok than a roll-out full of bugs and problems no one knows how to resolve.
4. Transparency in the decision making process may not eliminate all complaints, but it sucks the wind out of rumor. The more people who know the hows and whys decisions were made, the less finger pointing there will be. When decisions are made in secret meetings and never disclosed to the affected parties, rumor mills have the fuel to burn down a project.
5. Some people need a long exposure to something new to get used to the experience. Not everyone can “get it” the first time. The more complicated and difficult a program is to use, the longer people need to work with the program.
6. Train, train, train, and train some more. Some people are going to need to attend training (more than once). Some people are going to want to just play with it. Some people are going to refuse to learn the new program. There needs to be available assistance with every aspect of a process in a formal instructor to class setting, one-on-one setting, and self-help materials.
7. Every individual understands each nuance differently. The more diverse the affected users, the more diverse the approaches to helping them understand what it does and how it works. Users ultimately want to know, “How does this affects me? I just want to do my job and not get yelled at by my boss or anyone else.” Using Economics jagon in talking to a Graphic Designer may be the least effective approach. Essentially consider every individual as… an individual.