The "What's in it for me" principle
08/04/13 23:45
Time and time again the question stands in the room what makes a project successful. And while most people agree today, that a simple "On schedule, in scope, in budget" is not good enough anymore, the term "customer satisfaction" still sounds very tempting. If the customer is happy, what else than success could it be?
But one thing gets easily forgotten - in most cases the customer and the user is not the same entity. The customer is usually a manager, a committee or an overseeing group. But the users, who are most impacted by the change, can be found some levels below. So what if they are not happy - is the project still a success?
Very good examples are Customer Relationship Management (CRM) solutions. These implementation projects have a failure rate of breathtaking 80%!! And I would bet in most cases the management was quite satisfied once the project team presented them the final solution. So what went wrong?
The problem in most of these cases is, that the users – the sales people - hate the software. They feel that it takes more of their time than it brings them value; they think that the sole purpose of this software is to monitor them. And so they will rather not use the software and if they are forced to, they will use it in a way that is neither of value for them or the business. Similar situations exist in a lot of implementation projects - be it a software, a process or even a methodology. So how can we overcome this issue?
The secret is the "What's in it for me" principle. Whenever we implement something, we have to sell it to the user. And what users primarily want to know is, what the new "thing" will do for them, resp. how they will benefit. In a second priority they also care, how the tool will help their company. But what they absolutely can't cope with, is why they simply have to do something, without understanding what value it brings.
The highest priority must hence be given to communicate to the users, why and how they will benefit from the new deliverable. And the more specific this is, the better. A simple: "It makes you a better salesman" does not cut it. But showing in a training to a salesman, how he can easily identify the customers, who are most likely to buy his product, might do the trick.
If there are things, which users have to do, which do not bring them any direct value, but which will bring value to the management or the company, it is key to show the users how this value is created, for example the specific report that will be generated out of all the data they enter and then to explain specifically, how this report creates value to the management. Nothing is more frustrating than to enter data and to assume, that it will not be used.
The "What's in it for me" principle might sound very obvious – but the multitude of projects which still fail today because of the missing end user buy-in proves that also obvious things do get easily overlooked. Including end users from the beginning into the project team, keeping the “WIIFM” question during the whole project in mind and to start early informing the end users about all the benefits that soon come their way can make the whole difference between rejection and endorsement and hence between failure and success of a project.
Tweet
But one thing gets easily forgotten - in most cases the customer and the user is not the same entity. The customer is usually a manager, a committee or an overseeing group. But the users, who are most impacted by the change, can be found some levels below. So what if they are not happy - is the project still a success?
Very good examples are Customer Relationship Management (CRM) solutions. These implementation projects have a failure rate of breathtaking 80%!! And I would bet in most cases the management was quite satisfied once the project team presented them the final solution. So what went wrong?
The problem in most of these cases is, that the users – the sales people - hate the software. They feel that it takes more of their time than it brings them value; they think that the sole purpose of this software is to monitor them. And so they will rather not use the software and if they are forced to, they will use it in a way that is neither of value for them or the business. Similar situations exist in a lot of implementation projects - be it a software, a process or even a methodology. So how can we overcome this issue?
The secret is the "What's in it for me" principle. Whenever we implement something, we have to sell it to the user. And what users primarily want to know is, what the new "thing" will do for them, resp. how they will benefit. In a second priority they also care, how the tool will help their company. But what they absolutely can't cope with, is why they simply have to do something, without understanding what value it brings.
The highest priority must hence be given to communicate to the users, why and how they will benefit from the new deliverable. And the more specific this is, the better. A simple: "It makes you a better salesman" does not cut it. But showing in a training to a salesman, how he can easily identify the customers, who are most likely to buy his product, might do the trick.
If there are things, which users have to do, which do not bring them any direct value, but which will bring value to the management or the company, it is key to show the users how this value is created, for example the specific report that will be generated out of all the data they enter and then to explain specifically, how this report creates value to the management. Nothing is more frustrating than to enter data and to assume, that it will not be used.
The "What's in it for me" principle might sound very obvious – but the multitude of projects which still fail today because of the missing end user buy-in proves that also obvious things do get easily overlooked. Including end users from the beginning into the project team, keeping the “WIIFM” question during the whole project in mind and to start early informing the end users about all the benefits that soon come their way can make the whole difference between rejection and endorsement and hence between failure and success of a project.
Tweet
blog comments powered by Disqus