Ensuring Success for Projects Driven by User Needs


I have many times seen the problems caused by asking a Project Sponsor, Product Manager, or even Subject Matter Expert (SME) to represent the end users.

  • Completely wrong requirements because the Project Sponsor had never been a user.
  • A solution not useful to most end users because the SME was extremely senior and designed a solution that worked for her.
  • Product releases that no one wanted because the Product Manager depended on market research and big data instead of talking with actual users.

Even when the Project Sponsor, Product Manager, or SME is knowledgeable, we often find unexpected problems with our solutions when we show them to actual end users.

Agile rightly addresses this with a demonstration every iteration. But this demonstration is typically targeted to the Product Owner, who is most often someone in a role similar to a Project Sponsor, Product Manager, or SME. This person is seldom the actual end user. Granted it may be difficult to get actual end users into the building for a demonstration every iteration, but when you can, the results are well worth the effort.

We face larger difficulties when the number of users is in the hundreds, thousands, or even millions. The small number of end users you invite to demonstrations represent their own opinions. Without care, you may find that the users you have been working with do not really represent the larger population. You also need to change the people you invite every iteration to avoid the situation where the user knows what you are doing so well you no longer get unbiased feedback.

The Need for Solution Anthropology

For all these reasons, it is important to include in our projects a set of responsibilities called Solution Anthropology. Solution Anthropology is a blend of practices from:

  • User Experience
  • Business Analysis
  • Anthropology
  • Solution Design

The purpose of the Solution Anthropology practices is to create solutions that delight the end users and that reduce the possibility of problems attributable to human error. Solution Anthropology focuses strictly on the needs of the end users in their native environment.

When the requirements of a project are driven by the needs of the end users, you need this focus on the end user to prevent late, unexpected problems. This can save you considerable money and time as you drive out bad assumptions early in the project.

A few years ago I watched a couple of real end users work with a new voice activated mobile app for the first time. The Agile team had developed a Minimum Viable Product (MVP) in close cooperation with the Product Owner and were now testing it out with some real users. Unfortunately they discovered show-stopping problems with their approach that would require a significant redesign to fix. The sad part was that they could have gotten that information well before a single line of code was developed by using practices from Solution Anthropology, thus avoiding a big rework. It was good they got users involved before the end of the project. It was bad that they waited until well into the project to get that feedback.

Go to the Users’ Native Environment

Solution AnthropologyBut Solution Anthropology goes beyond getting user feedback. Like other Anthropologists, the Solution Anthropology team goes to the end users and observes them in their native environment. Using a solution in an observation room at corporate headquarters is often far different than using that same solution in a noisy warehouse, or a library, or in the car while driving children to their soccer game. The success or failure of our solutions, be they websites, mobile apps, software, business processes, or devices, often depends as much on the user’s environment where the solution is used as it does on the quality of the solution itself.

I once worked with a team creating new software for data entry clerks at a large insurance company. The data entry clerks were still working on green screens on a mainframe and the company wanted to retire the mainframes. The team was all excited that they were going to give the data entry clerks a nice, modern, graphical user interface making use of the mouse as well as a keyboard.

Then I sent them down to the area where the data entry clerks were doing their job just to look. There were rows and rows of desks. Each clerk had a stack of papers, a keyboard, and a monitor. No one looked at the monitors. No one took their hands off the keyboard except to turn to the next form to enter. They typed unbelievably fast.

The team returned to their office, tore up all the designs, and started over with a completely keyboard driven solution and one with much greater focus on performance than they had previously considered. They were surprised to find that their modern system might actually slow down the data entry clerks, which was not acceptable to the clerks who got paid for speed and correctness of data entry.

If you really want to know the real users and their real needs, nothing beats going to their site and observing them working or playing in their own environment. This is truly the key to ensuring success for user-driven projects.

All Business Analysis Skills are Important in Solution Anthropology

User feedback is vital for any project where a person interacts with the system, and observing the users is one important way we can get that feedback. Observation is not all. We continue to get feedback in other ways, including surveys, interviews, and cognitive walkthroughs. In addition, Solution Anthropology is very aware of the possibility of bias, and so takes care that the practices are done in such a way that the feedback we get is truly representative of our target user base.

Agile initially wanted the implementation teams to work directly with the end users. Get rid of anyone in between such as Business Analysts and let a real user sit right with the team. Except in very few cases, this has proven to be infeasible and unworkable. We do need people with the responsibility and skills to:

  • Find out what the end users really need
  • Work with the business to ensure the proposed solution provides business value
  • Work with the implementation team to develop a solution that meets those needs
  • Ensure that end users do provide direct feedback to the implementation team

Solution Anthropology encompasses the work of anyone who works directly with the end users so the work is coordinated and consistent. Therefore Solution Anthropology is not one role, but a team of people with the responsibility to delight the end user and a broad skill set to accomplish just that.

Author: Geri Schneider Winters discovered the power of Solution Anthropology seven years ago and has been a fervent devotee ever since. Frustrated with widespread poor user experience, winters is advocating for Business Analysts to bring users (not customers) to the forefront of product development. For more information: http://www.solutionanthropology.org. Join our LinkedIn Group: https://www.linkedin.com/groups/Solution-Anthropology-8240840

Like this article:
  3 members liked this article


Ryan Milligan posted on Monday, July 27, 2015 11:12 AM
I totally agree that the users need to be consulted when designing a solution, but the flip side needs to be considered as well. It's certainly possible that, over time, the way users perform tasks start to veer away from the company's evolving goals. Just because a user initially doesn't like something that has changed, it doesn't necessarily mean the change wasn't a positive one for the long-term. If anything, it's good to get both sides involved (users and management), and for a number of reasons. For one, it reveals to management how things are done today, which they may not be completely aware of. Secondly, it helps drive discussion as to which user "needs" are actually "wants" - perspective does matter. And finally, it can result in an intuitive solution that allows users and management alike to get what they want, and depending on the project those two can be equally important.
Geri Schneider Winters posted on Monday, July 27, 2015 1:10 PM
I absolutely agree that the needs of the business have to be considered. This is the real balancing act for those designing solutions - we have to have what the market wants or we will not be able to sell our solution. At the same time, there are business goals and product visions that must be addressed for the long term benefit of the company.

Ideally we find a solution that suits both needs.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC