How NOT to implement a system

I've seen quite a few mistakes made when implementing a computer system, and made a few of my own. There are quite a few ways a business system owner can make an implementation fail. Let's take a humorous (please forgive the sarcasm) look at how to fail. Here are a few of the ones that really stick in my mind:

1. Since communications is so vital to a system's successful implementation, you want to minimize it. Assume everyone knows the goals and system processes. Make sure to keep the end users in the dark as long as possible and minimize any input from them.
2. Don't talk to the expert on the previous system. And don't look at the prior system. After all, it's being replaced so it can't be any good, right? Dodge any meetings the prior system users try to set up. If there is no prior system, don't learn any of the processes that are currently being used. Assume the new system will automatically address any issues and processes without any input.
3. Minimize training. Any new system is designed to be simple to use. Why waste your people's time sitting in a classroom or web meeting learning it? It should be obvious how it should be used. A corollary to this is to make sure there are no expectations set on how to use it or standards that need to be met. The data fields will be filled quickly and correctly by the users. You don't need to document anything for users.
4. If the system can be customized and needs changes, gather together a group of managers, as many as possible who did not use the prior system. Use them to design the customizations needed. Exclude any end users and make sure the managers needs are met first. After all, the end users will put in what the managers need without any need for training, documentation or incentives.
5. Minimize testing. It's a new system, so there shouldn't be that many bugs. Testing takes too long and adds to the roll-out time.
6. Believe anything the salesmen for the software says except for roll-out time. If he says the software can do “A” and that the software can do “B”, it stands to reason that, even if A and B are mutually exclusive you can do both. Any time estimate a salesman gives will be an average roll-out time. Your efficient organization can certainly cut that time down considerably.
7. After roll-out, make sure the managers never use the system and only look at information from the system in a brief overview. After all, if the data is entered wrong, we will be replacing it with a new system sometime in the future any way,
8. If a user develops some expertise with the system to the point that he is showing people how to use it, he obviously does not have enough work. Assign them more work to stop them from helping others. If users are making requests to change the system to be more useful, you have two options. Either approve every single request to keep the developers busy and make the system as complex as possible, or deny every request to discourage anyone from making any.

If you can do most of the above, you can certainly ensure that your system will be a failure and you can move on to other parts of your job that are more important. You can blame the users, the vendor and the developers for the failure.