When is the end user part of the project? On many projects, the end user is the one who needs the solution and gets the solution and that’s the total of their involvement.
I read a quote the other day that applies to this concept: “A user is somebody who tells you what they want the day you give them what they asked for.” This can be taken to mean that the user often does a poor job telling us at first what they want and then gives us a better definition once the project is over and the solution doesn’t really meet their needs.
End User Input is Minimal
For this article, I’m going to look at this from another perspective. This quote can also mean that the project was derived from the users’ wants/needs, created without their full input, and then handed to them only to find that it doesn’t really meet their needs – and they’ll tell you that. I’ve seen frustrated users before who are forced to use a newly deployed system that doesn’t really meet their needs…because they weren’t consulted when the requirements were being defined at a more detailed level leaving the company with a solution that doesn’t get them where they need to be.
From my experience, often the true end user is involved in the project only at these points:
- A need is expressed
- A developed and implemented system is handed to them to utilize
In my opinion, the end user should – at a minimum – be involved with the project at these points:
- Pre-engagement during business process definition
- Pre-engagement and early engagement during requirements definition and for some drill down to more detailed requirements
- Training
- User acceptance testings (UAT)
- Deployment
Another quote brings to life how critical it is that we pull the necessary information from those that will ultimately be using the developed solution: “A user will tell you anything you ask about, but nothing more.”
The End User IS the Customer
The end user knows their job…and sometimes that is as far as their company knowledge takes them. They may even be performing some fairly mundane tasks within the organization. But they are critical tasks – otherwise, there would be no project. In essence, the end user is the true customer – the one who will actually be using the solution. It is the organization’s responsibility, the subject matter expert’s (SME’s) responsibility, and the delivery team’s – if access is granted – responsibility to pry the right information from the final end user of the solution.
They can’t tell you how to develop the solution. They don’t always know how what they do relates to everything else that is happening within the organization. But they know their job and they know what frustrates them and what doesn’t seem to be working. It goes back to the concept that often the customer doesn’t really know what they want – it’s our job to ask the right questions so that we don’t end up developing a system that misses the mark.
I covered this to some degree in the article “When the Customer Doesn’t Know What They Want.” In that article, I stated, “it is up to the Project Manager and the delivery team to ask the right questions, drag the ‘real need’ out of them, and help them to form it into a vision of the to-be processes and application.”
Summary
Developing the solution for the true end user is critical. They aren’t the ones paying the bills, signing the checks, approving the change orders. But their needs and wishes must be addressed and a successful and useable solution is much more likely if they are part of the project at key points rather just at the time of the request and at the time of deployment. They provide very valuable information and can make or break the project in terms of usability.