So you have brought your project in on-budget, on-time and it meets the requirements as documented and approved by the stakeholders. But the end-users are not happy and do not consider the project to be successful. The business department for which the project was carried out will now only sign-off the project if a new plan is put in place to add a whole series of enhancements to the original project.
You are probably asking yourself how did this happen? It could just be that that’s life, stuff like this happens and there is nothing you can do about it. But stop right there, a simple solution may be close at hand.
There are many reasons why end-users may not be satisfied with a project that seems to be a success on paper. The most common ones are:
- Poorly defined Business Requirements
- Lack of involvement of key people
- Business imperative pushing through a pre-determined but unrealistic deadline
- Poor communication between all involved parties throughout the project
- No prototype
- Lack of, or poor, training on the new system/process
- Human resistance to change
If you are a project manager and have ever been in this situation, or fear you might be soon, then I would recommend that you look first at training and resistance to change. These are areas that can be rectified fairly easily and may resolve the problem. The simplest and most effective way to do this is to speak to the people who are the end-users.
Let’s take as an example a project that involved delivering a new software system for administrative staff in a multinational corporation. Previously they had been using their own local versions of software developed over many years that very specifically targeted and met their local needs. But the global heads of the corporation wanted all their reports to look the same and present data in the same way so a new, common system has been introduced with this aim.
Each local department now feels they haven’t quite got a system as good as the one they used to have. They’re probably right from their perspective but from the perspective of the “powers that be” the project is a great success.
But your reputation is at stake if the system gets a bad reputation in the early stages of implementation so you need to do something about it.
So talk to the users and find out specifically what their gripes are. A little bit of hand-holding and encouragement may be all that is needed. If not, you will have a better idea of the enhanced requirements to ensure the system is eventually accepted. Very often, in my experience as a project manager the people given my time and attention in the early stages of implementation became great advocates of the new systems and even became “expert users” over time.
Good communication with all parties involved in a project is vital to a project’s success, which I have said many times before. But I still regularly hear about projects in difficulty when simple, honest, face-to-face communication would have prevented the problems arising in the first place. So never underestimate its importance and if you get to go on some project management courses in the near future take a special note of the tips and techniques they will teach you about the importance of communication in a project environment.
