Macadamian Blog

Issuing A Software Development RFP

Scott Plewes

Think Twice Before Issuing a Software Development RFP – If you Want a Great User Experience

Issuing a Software Development RFP

Issuing an RFP to design and build software seems like a pretty good idea if you are looking for expertise outside your company. It clearly lays out requirements, options, and ensures an “apples to apples” comparison of vendors. What could go wrong? While there is some truth to all of this, there is a still a strong likelihood that you will end up with a poor software application experience – regardless of the vendor you select.

Here are four common reasons why RFPs are a risky way to select a UX design and development partner.

Missed Opportunity for a Better Approach

A great product user experience takes into account three crucial elements: business, technology, and UX. This combination ensures a compelling UX in a product that fulfills the needs of both the business and the users while leveraging the correct technology.

In many typical RFP processes, the product design lead is not involved in defining success, scoping work, prioritizing functionality, or even setting timelines. This means that defining the engagement with the vendor is done without an understanding of how the design experts will interact with the team, what their contribution will be, and when and how this will be most effective. It is difficult to recover from such a less-than-ideal start.

This is true even when you already have a UX expert in house. There is always an opportunity to learn something new from those with different experiences and insight. This same concept applies to bringing in technical experts. In fact, the greatest value can be found by bringing senior level expertise (UX or development) into the process as early as possible to help with defining the approach and not just executing it.

Deciding how to approach a project is where innovation and excellence starts. By the time the RFP is written you may have missed that opportunity. And, organizations are often “reluctant” to (many times due to a process requirement) back track to a more successful approach.

Vague UX Priorities

Recently, we had a client say, “Our UX requirements are the usual cliché requirements – easy, intuitive, wow factor.” He recognized these requirements were vague and not really requirements at all – at least not specific enough on which to base a design. They were just a starting point for a conversation. Although there is nothing wrong with using them as a starting point, there is a problem if these types of “requirements” are formally used in RFPs and assume a prioritized scope, functionality, and timelines. The reality is that they are not nearly specific enough to accurately scope the design effort.

It is rare to see very specific user experience goals such as an increase in productivity, or improvement in conversion rates for product adoption. These goals can help you achieve a much closer understanding of the true priority for the UX design and business. Even if user experience goals are included in an RFP, have they been developed with the input of the product design team? If not, they may not be fully thought out or optimized. And, have they been connected to different usage scenarios and prioritized from an overall business and user perspective?

Budget Becomes More Important than Value

By specifying an engagement in terms of functionality and timing, the resulting focus is on ensuring that all the functional requirements are completed within budget. However, features alone do not necessarily mean a great user experience or provide the required value to the business. For example, just because I can make a phone call with my smart phone does not necessarily mean I can do it simply or efficiently. And, when timelines become tight or budgets shrink, user experience is typically traded off. It is easy to lose sight of user experience as the project progresses and everyone is trying to find a way to stay within budget. Sometimes trade-offs are necessary, but by not involving the UX experts and specifying user requirements up front, the trade-offs are based on reacting to constraints on time or money instead of being based on the value to the business. To balance budget and business value in a way that will lead to business success, you must bring in early the technical, business, and UX design teams. Otherwise, you will “pay” for it later in the project.

You get a company that has spent its time perfecting RFP writing

Many companies are fantastic at writing RFPs and some of them are likely great at design as well. To be fair, one could argue that there are design skills involved in writing an RFP, but design skills are not necessarily what your team is looking for.

I’ve also heard comments that suggest an RFP review process is not that much different from a job interview process. First, you receive the resume (like the RFP response). Then, you select take the top two or three for interviews which eventually leads to selecting the best candidate. Following this logic, why not write an RFP, select the top two or three, and then “interview” them.

In the case of a job interview, the job is typically well defined. In the case of creating software, the whole point is to bring in a company to help define the approach. The analogy sounds reasonable, but it is faulty. By the time you have interviewed the top two or three RFP responders, you may be looking at the wrong approach.

So What to Do?

It takes time to write and issue an RFP, review the responses, interview contenders, etc. Instead, take that time to be clear on the goals of the project and what you expect the role of the outside company / consultancy to be.

Then, instead of an RFP, talk to consultancies. If you intend to collaborate on the project, then start collaborating immediately. A company that is a good fit will collaborate with you to suggest an approach that will work with your goals, your culture, your constraints, and your vision. And, if you get two or three credible companies, there is a good chance you’ll get more options on how to execute successfully together. The end result is actually the high level content of an RFP at a level of excellence that you could not have achieved by yourself.

And, you will get to know your potential partner in the process. You will make your selection based on the same considerations (budget, goals, experience, etc.), but in the process you will achieve insights and uncover opportunities that were just not possible with an RFP.

So, invite candidates for a conversation first. Human beings achieve more through thoughtful discussion and collaboration than they ever can through paperwork.

Author Overview

Scott Plewes

As VP User Experience Design, Scott brings over 20 years of experience in understanding customers and how to incorporate their needs into software product design. He's put his skills to work on overseeing the user experience design of dozens of desktop, Web, and mobile applications. Scott holds a Master's degree in Science from Queen's University, and prior to Macadamian, he worked as part of Nortel's Usability Design Group. While Scott would have you believe he is an ardent NFL and NHL supporter, he is still a physics geek at heart. His secret passions include bad science fiction movies and even worse - action ones; and trying to understand Shakespeare… and failing badly. When Scott is not working he's either his kids personal chauffeur, or more likely sound asleep on the couch… the one hobby he has truly mastered.