5 ways to get buy-in on a software project

Software projects are notoriously problematic. Even the best ideas for custom software get waylaid by scope creep, budget overruns, and timeline delays.

Obviously, anyone who has a software idea wants the project that results to be a success.

But how do you actually do that?

Perhaps the biggest way is by getting buy-in from everyone involved, from your company’s executives to the customers who are impacted by the system.

At this point, we need to state the obvious—there is no one-size-fits-all way  to do this. A business leader’s primary goal is likely financial gain. A customer’s primary goal is saving time and/or money.

Here’s the good news—no matter who you need to convince, there are tools that you can use to do so.

Let us tell you about five of the tools we regularly use to gain buy-in, so you’re empowered to do the same.

Each of these things are part of our standard process for two reasons—they help gain buy-in, and they can also be used to create work product to move the actual software project forward. By serving both of these functions, these five steps are win/win propositions that create value as they help a project succeed. We’ll present these five things in the order that we usually do them.

Business Case Development

One of the most important things you can do when starting to envision a software project is to build a business case.

Begin by documenting things like:
* What money will this save (in dollars or time calculations)
* What revenue will this generate
* What customers will this acquire or retain
* How will conversions/sales increase

Obviously, these are business-centric questions that will help you establish an ROI calculation for the software. However, by answering these questions, you will also begin to define the benefits for your customers. You’ll want to keep both of these lists at the forefront of everyone’s minds as you begin the software project.

Workshop

A workshop session is a way to get all of the internal stakeholders in a room to discuss a project and how it will benefit your business. You should discuss things like:
* Expectations about timeline
* Scope of features and functionality
* Breakdown of phases of work
* Definitions of success and failure

We picture a workshop session as picking up rocks to see what’s under them. This should be insightful for every stakeholder in attendance, and help each person understand what’s important to people in other roles.

At the end of a workshop session, the team should have a unified view of what success for the project looks like, and of what kind of path will help to achieve it. There is still work and planning to do, but the general direction should be clear to everyone.

User Interviews

Every software project should have a user-centric focus. It should make life easier for lthe people who will actually use the web app, mobile app, website, voice-driven interface, or IoT device that you’re building.

To accomplish this goal, you need to actually talk to users and customers and watch them use your current software—or the Excel documents they’re using because software doesn’t work correctly.

Find out:
* What frustrates them
* What works well for them
* What they want to do but can’t* What they want to do faster
* What would make them more satisfied after using the software

User interviews and shadowing gather valuable information, and they also give the users you talk to confidence that you’re trying to make their lives better. This will build their excitement about the software that’s coming, and make them more likely to engage in the feedback loops and training necessary to get your software project to the finish line.

Wireframes

Wireframes are rough pictures that depict the features and functionality your software will have. They should make clear:
* What user flows the software will have
* What views will be in each user flow
* What functionality should happen on each view

These will give you a good idea of the breadth of your software, and explain what you’re building. This means they should assure different types of users that their needs are being addressed, and the software really will make things better for them.

One note here: Wireframes are conceptual documents, and not everyone is good at thinking conceptually. So while it’s important to use wireframes as a way to build buy-in, you may not see a lot of excitement or a-ha moments at this stage. That’s OK, because it’s the nature of wireframes. But it’s important to know so that you don’t lean too heavily on wireframes as your primary source of buy-in.

Clickable Prototype

Because wireframes are conceptual, many people need to see a realistic picture of what software is going to do. So it’s no surprise that this moment is the first time many users start to get really excited about the software that’s coming.

These designs should depict user interfaces, and also consider how user experience will work. They are more than pictures—they are expertly crafted tools for leading users of different roles through the system.

We traditionally displayed this using design files (PSD and the like), but over the past couple of years we’ve found that our clients are better able to understand how everything fits together when we put designs into a clickable prototype. This allows people to start to get the feel for how the software will work, along with how it will look.

We often use the Marvel prototyping tool to create a clickable version of a web app or mobile app. We’ve also used ProtoPie to create high-fidelity prototype of mobile apps.

The right tool depends on what you users need to see to get excited. If you’re trying to drum up investor money or Kickstarter sales, you may choose to spend the time on a high-fidelity prototype to show the bells and whistles. Either way, find the right level of detail to get everyone excited about the software that is to come.

In Conclusion

Each of these five tools helps you get ready for software development to begin. That’s important. But it’s just as important to get buy-in so that users will be eager to adopt the software that you’re building.

That buy-in will help you get to the finish line of your project, while keeping everyone on the same path along the way. The result will be custom software that serves your users, delights your customers, and benefits your business.

In other words, the kind of software that will become renowned, not notorious.

About Worthwhile Storyteller

We'll never tell you a lie, but we might tell you a success story that protects the intellectual property of our clients and partners. Our Worthwhile Storyteller is an amalgamation of all of our thoughts, experience, and expertise brought together to give you the facts about our relentless improvement in the software development space.