Your Software RFP is Broken – Here’s How to Fix It

Have you ever been involved in a software purchase that failed to meet the stated objectives? That ran way over budget? That launched months or years later than planned? Of course you have. Research shows that only about 30% of digital transformations are successful.

One of the main reasons for this is the way enterprise software is often purchased: through an RFP (request for proposal). On paper, it seems like an RFP is a strong approach: define your goals clearly, evaluate solutions side-by-side on objective criteria, pick the best fit with input from all stakeholders. Unfortunately this approach is fundamentally flawed. It makes a number of incorrect assumptions.

Flawed assumption 1: You fully understand the requirements up-front

You spent weeks building your buying team. You spent months interviewing users. You did your research on the market. You even brought in consultants to help you identify and document your requirements. Surely you know everything you need to know to specify exactly what you need and what you want to buy! Right?

Wrong. You will definitely identify additional requirements – sometimes extremely critical ones! – during implementation. If the project is complex enough to warrant an RFP, then it is too complex to fully document up front. It will affect too many people, touch too many systems, and modify too many business processes for anyone to understand the full impact ahead of time.

Flawed assumption 2: You are picking a static solution

An RFP implies that you are looking for a software solution that will not change. You want to buy a done deal – something that you can install, turn on, and forget about.

In reality, even the best enterprise software solutions are constantly evolving. They have to in order to keep up with the rapidly changing needs of users and the rapidly changing technology landscape. The best enterprise software vendors are constantly innovating and releasing new features and functionality.

And remember: you will miss key requirements in the RFP. Therefore, in order to be successful, the solution you select must be flexible, if only to accommodate the inherent imperfection of the requirements gathering process.

Instead of thinking about a static solution, you should be identifying a partner and platform that can adapt when your own understanding of your needs changes.

Flawed assumption 3: A feature list can define the solution fit

In an RFP, you are essentially comparing feature lists. Yes, you will ask about customer references, support, security, and so on. But to compare functionality, you’re going to ask about a long list of features.

However a feature is not a solution. A feature is just a tool that might or might not be helpful in solving your specific problem.

The challenge is figuring out how all of the features fit together to provide an overall solution that meets your needs. This can be extremely difficult to do in an RFP, because you are not actually seeing the software in action. You are just reading about it.

The only way to really understand how well a solution fits is to see it in action and use it yourself. This is why trial programs are so important (more on that later).

Flawed assumption 4: You can evaluate user experience from a demo

A demo is not the same as using the software. In a demo, you are seeing a pre-planned, rehearsed, and polished presentation of the software. The vendor controls what you see and how you see it. They are carefully selected to show you only the very best parts of the software. Even when you think you have dictated the demo script to the vendor, it is the vendor that is ultimately constructing and driving the demo, not you.

In reality, enterprise software is complex. It is used by lots of different types of users for all sorts of different purposes. There are bound to be areas that are confusing or difficult. The only way to really understand the user experience is to try the software yourself in a real-world setting.

Flawed assumption 5: User experience shortfalls aren’t important

You made your product comparisons. You thought about information security. You considered vendor financial viability. You saw a great demo. You got pricing that you’re happy with. So you make your selection. And most surprising of all, implementation goes right on schedule and according to plan! Then you go live and… users revolt.

What happened?

In the last section I talked about not being to evaluate user experience from a demo. You might have read it and thought to yourself “So what if it’s a little clunky to use? If it does everything we need at the right price it will still be worth it.”

Here’s the thing: User experience shortfalls kill user acceptance, and low user acceptance kills IT projects.

Think about it this way: you can have the most technically perfect, feature-rich, and secure software in the world. But if people can’t figure out how to use it, or don’t like using it, they are not going to use it. And if they’re not using it, you’re not going to get any value from it.

User experience should be one of your top priorities when selecting enterprise software, not an afterthought. And user experience is impossible to evaluate in an RFP.

There is a better way to buy enterprise software

The good news is that there is a better way to buy enterprise software.

Step 1: Use short RFIs to reverse-engineer requirements and eliminate poor fits

An RFI (Request for Information) is a common first step in an RFP process. It is usually a short questionnaire that vendors fill out to provide information about their products.

You can use RFIs to do more than just gather information, though. You can also use them to help reverse-engineer your requirements.

Start by taking a close look at your current pain points. What processes are you trying to improve? What problems are you trying to solve? Then, translate those into broad requirements. Once you have a list of requirements, you can use RFIs to eliminate vendors that are obviously not a good fit.

For example, let’s say you have a requirement that the software must integrate with your existing CRM system. You can use an RFI to ask vendors if their software integrates with CRM systems, and if so, which ones. This will help you quickly eliminate any vendor that does not support your specific CRM system.

There’s a benefit on both sides: Vendors don’t have to fill out lengthy evaluations where they could have qualified themselves out in a couple of questions, and you don’t have to process long, complex responses where a critical mismatch is buried away in hundreds of questions.

Step 2: Run a lengthy trial program with simple user feedback

After you’ve used RFIs to eliminate the obviously poor fits, it’s time to start evaluating the remaining vendors. The best way to do this is with a trial program.

A trial program will give you a chance to try the software in a real-world setting and get feedback from actual users. To make sure you get meaningful feedback, make the trial long. “Long” will vary depending on specific solution you’re looking for – it could range from several weeks to several months, or even a full year if it needs to capture a full financial cycle. And be sure to include a meaningful cross-section of future users in major and minor roles, not just a handful of “power users”.

Throughout the trial program – not just at the end – ask each user to fill out a simple feedback form. NPS (Net Promoter Score) is a great option, but you can also use a short custom form with questions about specific pain points and whether or not they were addressed. Whatever form of feedback you use, make sure it is painless for the end user to provide and easy for the buying team to process – the most important thing is to gather feedback from as many people as possible, even if it’s basic.

Also, the trial isn’t just about you! You’re giving your prospective vendors the opportunity to work with you and develop a much deeper level of understanding of your needs than they could get by looking at a requirements document in an RFP.

Step 3: Identify a very small set of finalists for infosec and pricing evaluations

After you’ve collected feedback from the trial program, you should have a good idea of which vendors are the best fit. From there, you can identify a very small set of finalists to move on to the next stage of evaluation.

At this point, you’ll want to do a more thorough evaluation of information security and pricing. You should also have a much better idea of what you need, so you can make sure the finalist vendors are able to meet your specific requirements.

You’ll also get better responses from your vendors at this stage than you will by opening with a lengthy RFP! The remaining vendors will have a much clearer understanding of your needs thanks to the trial, and since they know they’re on the shortlist they will be willing to invest more time in thoroughly answering your questions and also putting their best foot forward on pricing.

Take the plunge

If you’re still using an RFP to buy enterprise software, it’s time to ditch it. The RFP process for enterprise software is broken. It just doesn’t work in this space. While RFPs not the only reason a majority of digital transformation projects fail, it definitely doesn’t help.

The good news is that by following the steps outlined above, you’ll be able to avoid the most common pitfalls of the RFP process and give yourself a much better chance of selecting best partner for your enterprise software needs. Give it a try on your next project!

Biggest challenges in eSourcing

4 Biggest Challenges in eSourcing

For a long time, procurement managers were focused on one thing—reducing costs.

Through the years, however, business needs have evolved such that cost efficiency, while still important, is now joined by a whole new list of concerns that can similarly impact a company’s bottom line.

Given this, procurement teams are now seeing their roles expand beyond simply finding the most affordable sources for materials or services. Procurement teams must also consider the broader relationship, including whether their chosen supplier reflects their own organization’s brand values and whether it’s a working relationship that will spur innovation or yield other less tangible benefits for the company.

Fortunately, eSourcing has proven to be an effective tool to help manage these concerns. eSourcing software offers robust tools and applications that facilitate traditional procurement processes with more efficiency. Still, to truly maximize what it can do for your organization, the following challenges should be addressed:

1. Declining value of cost-savings

Cost reduction has long been the primary driver of eSourcing. But often, focusing too much on affordability – especially after significant savings have already been achieved – leads to declines in quality or in service level, leaving businesses feeling unsatisfied with their suppliers despite achieving excellent pricing.

Of course, the ability of eSourcing to deliver cost efficiencies for businesses still remains very relevant, no matter how significant the gains made in the past. However, communicating to suppliers and upper management the importance of other factors in supplier selection is just as critical. At some point, this requires a significant shift from a business’s tendency to focus on year-over-year savings instead of considering the annuity value of past savings achievements.

2. Lack of support for eSourcing’s other benefits

This is the corollary to the declining value of cost-savings outlined above. To maximize the benefits of eSourcing, management and procurement teams must fully buy into the idea that there is much more to strategic sourcing than simply gathering the lowest bids for a project.

Ideally, eSourcing is designed to deliver high quality and relevant proposals for a particular project. This means bids must strike a good balance between cost and quality. Often, upper management is unable to recognize the relevance that quality plays into the whole procurement process—they’re too focused on the costs. Ultimately, this can serve to be detrimental to the success of any project, but especially when savings have already been achieved and the company is enjoying the ongoing dividends of those savings.

3. Insufficient understanding of objectives

With an eSourcing platform, it’s easy to host bidding events and send out requests for proposals (RFPs). However, to attract the attention of quality suppliers and ensure quality bids from them, you need to give them something solid to work on.

Knowing how to create an effective RFP and sending it out means understanding the reasons why you need to do it in the first place. This goes back to your objectives. If the team behind the whole initiative is not provided a clear understanding of what they’re looking for, it will ultimately lead to poor results.

4. Lack of insight into effective decision-making

Related to the previous point, an underappreciated aspect of finding the right suppliers is the proper evaluation of proposals. If procurement teams don’t fully understand their objectives, this also means they won’t be able to create reliable criteria for evaluation. This could result in a business basing their decisions on something that might not be completely relevant or sustainable for a long-term working relationship.

Having identified these challenges, you can take a closer look at your procurement process and reassess how you can maximize your eSourcing platform to deliver the best results.

If you want to learn more about how Vendorful can help address these challenges to improve your procurement process, contact us today.

What to ask before purchasing RFP management software?

7 Questions to Ask before Purchasing RFP Management Software

At this point, you’re convinced that your purchasing process bears the hallmarks of the problems that come from manually-managed RFPs. You’re shopping around for RFP management software to streamline your process and gathering information just as you would for any other purchase that your team makes. (Maybe you’ll even get meta and run an RFP to find an RFP Management solution!) No doubt, you have your own questions that need answering, but here are seven questions you absolutely need to ask in an RFP presentation before purchasing management software.

1. Does the product have features that will address the 

problems I’m experiencing?

Obviously, collating and scoring responses are  critical components of understanding the RFP process and any solution that merits consideration should makes those processes easier. It’s also going to be helpful to ponder some of the less obvious challenges that you might encounter when running a sourcing event. For example, how about all of the requirements gathering, vendor discovery work, and documentation that occurs before the RFP is even crafted, much less sent out? And have you considered showing that inbox of yours a little respect? Does the solution help reduce monstrous email chains and manage attachments?

2. How easy would it be to implement this solution across the team?

There are at least two different parts to consider when thinking about what’s involved in an implementation. First, there is the deployment of the software solution itself. Is it a turnkey SaaS setup or is implementing the software going to take coordination and time? Second, you have to think about how long it would take to bring your colleagues up to speed. How much time will need to be invested to train your procurement team? What about subject matter experts who are unfamiliar with procurement? A strong solution should work for all of the stakeholders who get involved in sourcing, whether they work in the procurement department or not.

3. How do I think about calculating ROI when considering an RFP management solution?

Are there certain thresholds in terms of spend or the number of RFPs that must be reached before a solution makes financial sense?

There are companies that spend billions of dollars per years on suppliers just as there are companies that spend thousands. Likewise, there are organizations with robust procurement teams and sourcing specialists along with other organizations where divisional leaders are tasked with doing their own sourcing. As such, there are no hard-and-fast criteria for rationalizing the expense of RFP management software in absolute terms. Instead, it’s advisable to consider ROI in relative terms. A good solution will likely promise to help your organization recover time and reduce supplier spend, both of which should — directly or indirectly — fall to the bottom line. Measured as a percentage of your spend, how much money will you have to recoup in the form of person hours and reduced costs to justify the expense of RFP management software? 5%? 2%? 1%? Figure out the number that makes sense and then work through some scenarios to determine if it’s achievable.

4. Did you skip the RFP process even though you probably shouldn’t have?

Chances are, your current RFPs are a pain. If they weren’t a pain, then you wouldn’t be looking for a solution and probably wouldn’t be reading this article. And pain, at least in this case, costs money. The pain results from bad process; the bad process requires much more time that it should; the time spent belongs to people; those people earn wages. While it’s possible that you’ve elected not to run a proper sourcing event out of pure frustration, you might also have avoided them on occasion because of cost. For example, if you had to spend $10,000 (primarily in person hours) to run a process for a $20,000 product, you would have an ROI challenge with the product before the ink was dry on the contract. The math is pretty damning. Simply take 8 people x 40 hours x $30/hour and we get to $9600. As you can see, it’s not hard to spend five figures on an RFP. Bottom line: if you’re evaluating RFP management solutions based on how many RFXs you run, and how much spend you manage, you need to contemplate the costs of the RFXs that you didn’t run because your process has been a problem.

5. What are your stakeholders looking for in a solution?

What is your procurement team looking for?

While sourcing software is typically going to end up being the procurement department’s bailiwick, they will not be the exclusive users. Indeed, part of the rationale for licensing an RFP Management solution is to streamline the process for stakeholders outside procurement. It’s helpful to have some potential stakeholders — preferably from different departments — sit in on a demo for a sourcing solution and weigh in with their opinions. Ultimately, their “buy in” will be helpful when you begin using the chosen solution.

6. What is the development approach of the company from which you are licensing the software?

Do they push out annual releases? Or do they quickly iterate on requested features?

In evaluating a solution that works best for your organization, you should think about how your needs will evolve over time. Rarely is software static, but the frequency of updates as well as the method of applying them can vary considerably. On the one hand, you might be looking at classic enterprise software that is deployed on your servers. A common model is for the software provider to offer quarterly patches amid larger upgrades, which might occur every few years. The evolution of SaaS-based solutions has changed that model. Those providers run the solution on their own services and offer subscription-based access to it. Release cadences vary, but there is a strong bias towards much more frequent, iterative releases. This allows for a high degree of responsiveness to customers that advocate for the addition of specific features. Finally, there is a hybrid-model whereby a solution that is usually offered as SaaS can be deployed on the customer’s server infrastructure. When implemented thoughtfully, this approach can allow for the same frequent iteration as its pure SaaS counterpart while allowing customers to control the infrastructure. Ask your prospective vendors about their deployment models and development methodology.

7. Is it easy to use?

If the demo you receive is 90% Powerpoint presentation and 10% product focused, you might not walk away with much confidence that the solution will be easy to use. Remember, the scope of a sourcing product extends beyond the procurement team. Stakeholders from different departments — some technical and some not technical at all — could be included in sourcing events that you run. So ask yourself, “Does it look as smooth, simple, and helpful as promised?” And more importantly, “Does it address many or most of the problems I’ve identified with our RFX process?” Modern solutions shouldn’t generally require days of training sessions. Ask if you can run a practice sourcing event. The software provider should stand behind its product. If you can’t try the software before you buy it, there’s a good chance that the software is confusing to use or might be complicated to implement.

We have invested lots of time and money in simplifying what has traditionally a complex process.. Indeed, Vendorful was created from the ground up with usability in mind. So give it a whirl…. You can knock out question number 7 by signing up for Vendorful and trying it for free.