The simple reason those tech rollouts yo work so hard on fail is a lack of appeal to the users' (or their management's) self-interest.
Perhaps the worst IT project to be involved in is not the long difficult struggle, but the successful implementation that is released to the users, only to quickly languish due to lack of user buy-in or complaints of insufficient training. Spending hundreds of hours to ultimately deliver something that is a success or a failure usually feels better than spending the time to deliver something that quietly gets deemed irrelevant.
So how does one avoid this fate for their newest IT project? The cause is conceptually quite simple: a lack of appeal to the users' (or their management's) self-interest. While you may be tempted to cite lack of training or insufficient "change management," at the end of the day people will do what is in their best interest, and if there is not a compelling benefit that appeals to that interest, they are unlikely to change. While there are voluminous treatises on change and a raft of tired bromides about it, it really is as simple as appealing to one's interests. I personally do not believe humans are innately resistant to change, rather that we weigh the pros and cons of each change in light of our personal situation, and often the effort required to change does not outweigh the benefit.
So, how do you "tip the scales"?
If we agree that people will not change unless there is a compelling impact to their self-interest, an interesting shift happens. Rather than viewing an IT project through abstract notions like business benefit or technical elegance, we start looking at it from the perspective of the people who actually have to use the thing as we try to identify their interests. This shift can change the attitude of those performing the implementation, and if it is embedded from the start of a project you will not have to worry about things like training, as the users will be clamoring for knowledge about how to ease their transition to the new system.
Appealing to this self-interest is surprisingly easy. I am often asked how a project team can identify the interests of key players, and the simple answer is to speak with them frequently and listen. This is yet another one of those conceptually simple ideas that is somewhat difficult to implement. IT may have an adversarial relationship with users or be too focused on the technical aspects of a project and see this relationship building as a waste of time. However, usually the projects that end up languishing are the ones where IT rarely communicated with the user community, and for many, the first time they heard of the project was when their inbox was flooded with demands to participate in training.
If you ignore self-interest, you will likely end up with a user community that is nonplused by your project and largely ignores or resists training. They have made the conclusion that the project does not benefit them, and thus training or spending the time to learn a new system holds little or no appeal.
Sometimes the only way to remedy this scenario is to use a "big stick" approach to self-interest and employ threats to jobs or, in the case of compliance-type project, threats of fines and government action. While most of us have little self-interest in paying our taxes, the government uses a very large stick to ensure compliance and tips the scales of self-interest in their favor.
While an appeal to self-interest may sound trite or appealing to the basest aspects of human nature, our survival instinct drives us to do what holds the most personal appeal. While your project may have used months of your time and be technically brilliant, think about all the appeals you receive on a daily basis to learn about some new corporate policy or an internal survey that you have ignored and realize you are one of many cries for the self-interest of your colleagues. If you approach your IT projects with this in mind, you will find training, system adoption, and change management to happen almost automatically.