Have you ever heard someone say, “what we need is a button that can…”, and then continued on to describe some mystical all-in-one solution? Almost all of us have experienced something like this at some point in our careers. This kind of user feedback is extremely common, and often the first intuition of department leaders who are looking to streamline or improve a process inside of their division. Unfortunately, mitigating project risk for these types of endeavors can be tricky.

Recently — at a CRM users group meeting we were moderating— one of the most experienced IT Directors in the room claimed that 100% of their companies “button projects” were total failures. He went on to say that they used to spend a lot of time working with sales and operations to design “easy buttons” for their different processes. Unfortunately, what they found was that IT rarely got it right on the first try. This made these projects expensive and time consuming. To mitigate these project risk’s this problem they knew they needed to dive deep in to user feedback processes, and collect more than just the initial wants and needs of the team. They needed to get to the why behind the button.

Why 100% of button projects fail

Why are the button projects of the world so hard to execute? The reason is that the button itself is the solution, not the problem. Saying that the button doesn’t work right is counter-intuitive, because it’s essentially saying that the solution wasn’t right to begin with. Leading a process improvement project with a solution before the challenge or issue is fully mapped out is like putting the cart before the horse. So, why does this happen so often?

Many times sales and operations teams have a good idea of what they want to accomplish, but don’t have a deep enough system knowledge (or the technical expertise) to map out a best-case solution to the problem they are experiencing. This means these leaders will often come up with solutions that are not fully-developed, and/or may not be based in best practices. This leads to a solution that rarely accomplishes what it was intended to achieve.

This kind of thing drives IT development teams crazy. IT listens to what the department leaders say they want, then build it exactly as designed. Ultimately, we know where this is headed. Once the project is released and things still aren’t working the way the department leaders had imagined, the technical team is called and asked why it doesn’t work right. This leads to a common back and forth between these two states that centers around … “what I said was this, but what I meant was…”.

Fundamentally, the best way to mitigate project risk is to map, build, test, validate, and then deploy the proposed change. However, the steps that are often employed are simply building it and deploying it. To avoid this kind of scenario businesses must rethink how they approach user feedback, project planning, and execution all together.

The why behind the button

Going back to our IT Directors button project story, once the buttons were built it was extremely common for the users to declare, “That’s not what I wanted. What I wanted was something that …“. Wouldn’t you know, even on the second try IT usually failed to get it right. So, what’s going on?

As it turns out, rarely did any buttons that were created do what they department leaders wanted them to do. They learned over time that the last thing that was usually said before the solution was actually successfully implemented was, “what we’re really trying to do is…“. What someone want’s, and what they are trying to do, are two completely different types of conversations. One is taking an order, the other is creating a platform for conversation. Allowing department leaders to place orders with IT is a recipe for project risk. Unfortunately, these orders are often disguised as simple changes that seem rather benign until all the layers are pulled back, and then it’s too late.

The IT Director told us that they recently had done away with all button orders, and that they were now employing a dynamic user feedback practice that allowed them to better understand why the button needed to exist in the first place. They found that they had to ask the question, “why?” approximately 6 times throughout those feedback conversations to get to the root of the issue.

This whole thing should seem fairly intuitive, right? Unfortunately, it doesn’t usually work this way. With the way organizations are structured and how traditional IT departments operate, button projects are extremely common. However, companies should be doing less button order taking and more project planning meetings to discover exactly what is to be accomplished by implementing these buttons. Discovering the why behind the button can provide valuable feedback to developers and project team members that can allow them to think creatively about solutions that are likely better than some magic button.

Mitigating project risk with user feedback

How can you avoid button project failure? It’s simple. When department leaders have challenges or issues with the system and need to design a customization, module implementation, or software change implement a project strategy that can get to the core part of what they are trying to accomplish. By getting the root of what needs to occur, teams can collaborate around potential solutions and validate the build-out before implementing live on the system.

At Datix, our teams use use cases to determine how a user interacts or would like to interact with the system. These are living, breathing references for how the proposed changes should work. Once established, we employ a methodology we call Discover, Document, Review (or DDR). Our DDR’s help us collaborate around what’s being built, make changes as things evolve, and provide transparency to both builders and end-users throughout the process so that go live is a total non-event. This practice of gathering user feedback is one way that we help mitigate project risk.

During your next project, consider what we’ve talked about so far, and think about some of the processes Datix employs. They’re all designed to mitigate project risk by discovering the why behind the project. When meeting with end-users it’s critical to understand not just what they want to do, but why they want to do it. Understanding the why will give expert project teams more creative, flexible, and dynamic options to consider. After all, the department leaders are not software experts, so why should the business let them dictate implementation and solution practices?

Interested in best practices for user feedback, project implementation help, or enterprise software development? Contact the experts at Datix today. Our processes are designed to mitigate risk and can help transform your business.