POC beats RFP: Optimizing resources for an investment decision

How many of us would be willing to purchase a car without taking it for a test-drive or having it inspected by a mechanic? Who would buy a house without walking through the property and getting the home inspected? How many CEOs would risk their business by taking on a new acquisition without auditing them first?

Each of these scenarios shares a common thread: we're actively investing our time and resources gaining firsthand knowledge and experience of what we're getting into before committing to a large investment with ramifications that will last for some time. Why should buying software be any different?

With that in mind, we know how difficult it can be to invest in a new software tool for your business. When evaluating this kind of software investment decision, we've found that turning to a more formal proof of concept (POC) leads to easier evaluations and better outcomes.

This is because POCs are one of the best ways not only to gain in-depth knowledge about the platform and its capabilities but also allow your stakeholders to evaluate the tool based on real-world examples that align with your particular needs and requirements. Most importantly, it's one of the only ways to evaluate the time and resources required to actually implement the solution, especially when the time comes to customize the tool to your needs. 

By the end of this post, you'll understand why I think the current software procurement process is broken, you'll see why you can't afford not to invest in a POC, and most importantly you'll have the knowledge you need to ensure that your next POC goes off without a hitch.

Traditional software procurement is broken

I don't want to sound like an alarmist, but over the past couple of years, I've come to believe that the current process of procuring software is fundamentally flawed. To illustrate my point, let's take a look at the current process most organizations use when procuring software, most typically a Request for Proposal (RFP).

1. Start with a group of stakeholders who create a giant list of requirements that the software should be capable of executing. This list of requirements is almost always a reflection of the current business processes, regardless of whether or not those processes are the ideal solutions to the underlying business needs.

2. A handful of vendors are asked to respond Yes/No to the list of requirements, eliminating any nuance in their responses so as to not create confusion. If the answer is no, customization is offered by the vendor as a solution in an attempt to remain in consideration for procurement, often with little to no clarity on how that will impact the overall timeline and budget.

3. Based on the scores from their responses, the top vendors are asked to demonstrate their software so a vendor of choice can be chosen. Often, the quality of these demonstrations is more closely tied to the abilities of the presenter than the actual software capabilities.

4. A procurement team is brought in to negotiate the final contract and ensure that any regulations, standards, and compliance needs are met. This process can take anywhere from a few weeks to many months as both parties hash out the details and final contractual terms. 

If you've gone through this process before, you know how many pitfalls there are in each of those steps, and just how much time it can take to get through the whole process. Whether coordinating calendars, collecting feedback, or writing questions and responses, it's almost as if the process is purposely built to extend timelines and consume as many resources as possible. Additionally — everyone involved brings their own set of biases, assumptions, and interpretations, so finally coming to a decision requires countless meetings, emails, and comment threads. 

The worst part of this, sadly, is that even after all that time and spending vast amounts of resources, you can still get saddled with software that doesn't actually solve the very real business challenges that caused you to start the procurement process in the first place. At that point, you're stuck either trying to customize the software to fit your business needs (regardless of the time or expense) or starting the entire process all over again.

What should we do instead?

If you're reading this, you and I have something in common: we live in the real world. Sometimes, a business has to make a decision to skip this type of knee-deep evaluation. That tends to happen when teams don't have the time to commit to this approach and the risk of procuring the wrong platform is low, either because the cost is minimal, the tool can easily be swapped for another, or the business already has resources they can tap into who have direct experience with the chosen platform. 

In almost every other scenario, getting hands-on with the software is the best way not only to evaluate the capabilities of that software, but also to determine whether or not it aligns with your overall business processes (or maybe can be a pivotal tool in significantly changing and improving your business processes). It's also a great way to evaluate the software vendor itself and whether or not you want to do business with them before making any long-term commitments.

From my own experience, in order to effectively evaluate any software tool you want to integrate into your technology stack, you need a chance to test it out in the real world.

I think of it as being similar to buying a home: before I fork over a few hundred thousand dollars for the next 30 years, you better believe I'm going to go check out the property myself and simultaneously consult with other experts to ensure there aren't any hidden skeletons before making this investment. Even though it's going to cost me some time and money, I do it because it will give me critical information when making my final calculations on whether or not it fits my needs and is worth the commitment.

The elephant in the room

Here's the catch that no one wants to admit: no software — no matter how well vetted — ever perfectly aligns with the needs of the business. If the business is lucky, it can configure the software to match its needs very closely, but the much more frequent outcome is that the business either has to live with software that doesn't fully address its needs, or it has to customize the software to fully align with its unique business requirements. 

Critically, if customization is the pathway forward (and from my experience, it usually is), you need to understand how feasible that customization is before you sign anything. If you wait until the contract has already been signed, your business's hands are now tied, and you're forced to adopt any standards or approaches implemented by the software vendor in order to continue to use the platform.

You should be looking for tools that balance out-of-the-box capabilities with ease of customization, and a proof of concept is the best way I know of to truly understand how a prospective software vendor balances those two ideals.

How to plan an effective proof of concept

While a small team of developers can often evaluate a software tool just using a free or trial account without a real deadline for evaluation (and if this is you, I'm jealous), a long-term investment in a fundamental software tool to build or grow your business requires a little more structure. 

When it comes time to gather your resources and commit to a POC, there are a few key things that you'll need to consider before moving forward to ensure that you're not wasting valuable time and resources.

1. Can you make a good decision without a formal POC?

While this may seem like a silly question, the first thing you need to evaluate is whether or not you have the time and resources to commit to a POC.

For small projects with little or no risk if they end in failure, you may find that it's a better use of your resources to commit what would have gone to building a POC to just creating the finished product instead.

If speed is of the essence, sometimes a short-term win is more important than the ideal long-term solution (especially if you can revisit the solution again in the future with little duplication of effort). 

2. What resources can you commit to the POC? 

Building a proper POC requires the time of everyone involved. You need to ask yourself who within your team has both the knowledge and capacity to conduct this evaluation. 

Critically, you need to ensure that you have representation from all of the key stakeholders who will interact with or have workflows impacted by the software. If you don't have those resources in-house, you'll need to evaluate whether or not a partner can be brought in to work with you.

Finally, you have to decide just how much of your time and resources you'll want to commit to a POC. A simple use case can often be validated and tested in a couple of weeks, but a more complex project — or an extensive set of stakeholders — may require months.

Since the appropriate timeline can be difficult to determine on your own, this is a great area to ask the software vendor or a partner their opinion based on your requirements. The more transparent they are about the overall process, the resources needed, and what factors impact the overall timeline, the more likely it is that their judgment should be trusted.

Important: a clear understanding of which stakeholders own which portion of the POC is key to ensuring there are no major blockers or slowdowns during the process. Some portions of the POC may be owned by your business and internal stakeholders, while other portions of the POC will be owned by the software vendor or implementation partner.

3. What is the scope of the POC?

Simply put, a POC is not your ultimate solution. It is a working implementation that proves the software can be used to achieve your desired outcomes. 

As such, you need to determine how much of the finished product should be represented in the POC. Also, recognize which elements of your finished product are directly owned or influenced by the software, and limit the POC to just those aspects of the ultimate solution.

To illustrate this concept, let's take an example of building a POC for an ecommerce web application using the Contentful Composable Content Platform. 

For this POC, you'd start by determining which portions of the final experience should be evaluated in the POC.

• If you only need to determine how easy it is to define a structure for the content and the editorial workflows, you might focus solely on the content model and editorial workflows. 

• If you need to evaluate end-to-end publication pipelines, you might add the build pipeline and web application. 

• If you're evaluating the customer checkout process, you would include the product pages and commerce transactions. 

• For each of these capabilities, integration with the influencing tools or software – such as an ecommerce platform, digital asset management tool or translation management system – should also be evaluated as part of the POC.

For each of the above capabilities, you don't need to fully flesh out the implementation. For instance, when you create the content model, a homepage, product page, and category listing page content types (and any corresponding child content types) may be enough to make an evaluation. 

Remember: You're not looking to build your ultimate solution, you're just putting the software through a rigorous enough test to validate that it can handle your particular needs.

4. What are your criteria for success?

Now that you've determined the responsible parties, the overall scope of the proof of concept, and the amount of time you'll be committing to the POC, the final piece of the puzzle is to determine the outcomes under which the POC can be considered successful.

Every POC has a slightly different set of success criteria, and it's crucial that everyone participating in it is aligned to the same outcomes. 

Most importantly, focus your success criteria on achieving the final outcome, rather than how that outcome is accomplished. When working with innovative tools and disruptive technologies, the process by which a task can be accomplished may differ from what you're used to, and that's not necessarily a bad thing. 

Very often, customers ask me how to accomplish editorial workflows where an entry requires approval from an editor or administrator before it can be published. There are many ways to achieve this with Contentful: our Tasks feature, our Content Workflows, a required field on an entry with restricted permissions, or even integration with an external workflow tool like Workfront or Jira.

By evaluating success based on the outcome, you may find that a new approach is measurably better than what you had originally envisioned! To illustrate this idea, let's continue with our example above: 

• For this POC, the development team may define a success criterion around creating a content model in Contentful that aligns to a pre-existing frontend implementation. 

• Content authors and editors may define success as publishing content or making layout changes without requiring a code deployment. 

• Success criteria could also exist around things like time to publish new content, time to deploy, or successful integrations with external tools and systems.  

A key aspect of defining your success criteria is to consider not only what the successful outcome is, but also who has the knowledge and experience to fairly determine whether that outcome has been achieved. 

For instance, making layout changes without a code deploy may need to be evaluated by both content authors and UI Designers to ensure both flexibility and ease of use while adhering to brand guidelines. Ensure that for each success criterion, all of your key stakeholders agree on who makes the final call.

One last note on success criteria: while it's easy to focus your evaluation on the capabilities of the software, another ingredient for success is how well your team and the software vendor were able to work together. 

When making an investment decision, it's not just about choosing the right software, but also making sure you're investing in a partner who's willing to invest their own resources and ensure you achieve your business outcomes.

How to identify potential POC candidates

As I'm sure you can see by now, a proof of concept can consume a fair amount of your time and resources, and when you're looking at procuring a new software tool, you're likely evaluating more than one option. 

Evaluating these options side-by-side with parallel POCs is one of the best ways to identify differentiators between tools, gaps in each of the solutions, and they can help you answer a variety of key questions when making a decision. 

That being said, building out too many POCs can quickly diminish the returns you're hoping to accomplish by making this upfront investment. Here are our thoughts on how to decide which tools you should invite to the party when running multiple POCs in parallel.

1. Screen your options

The first thing to do when evaluating multiple options is to ask the vendor to show you what their tool does. Ask them how the tool works, how they tend to work with customers, and have them show you demonstrations using the tool. 

During this time, have them explain their philosophy as a company, and how that philosophy manifests itself in the tool. 

By listening to what they have to say and how they respond to your questions, you'll be able to identify anyone who is obviously not well-suited to solving your business needs and working with your team.

2. Get your hands dirty

Wherever possible, try the product in a non-committal way. Most software vendors offer self-service free trials or have a freemium offering that will allow you to play around with the tool before building out a formal POC. 

Oftentimes free trials or freemium products offer limited capabilities and/or workflows, but it's a good way to see whether or not the tool tends to align with your business and its processes. 

Importantly, team members can try the tool on their own time and highlight who they think has the most potential to solve their problems. 

3. Ask a friend

Don't be afraid to tap into your network and ask around about the tools your former colleagues or business contacts are using. They’ll gladly tell you about tools they love or harrowing experiences they've endured. 

Importantly, try to cast as wide of a net as possible when gathering this type of feedback. Any individual implementation can only represent that team's opinions and recommendations, so try to gather multiple viewpoints.

A glowing recommendation could be an example of a great tool, but it could just as easily represent a simple workflow and talented individuals within the company. 

Make sure to ask questions about how they conduct their business to see how it aligns with your own processes, and try to get multiple opinions about each tool to see if poor experiences are a common trend or a single bad implementation.

4. Ask the vendor

Finally, before committing to a POC with any vendor, ask them to tell you how they’d want to work with you on it. See what resources they're willing to invest in the POC with you, and ask them for insight into what a POC with that company tends to look like. Ideally, it should be a collaborative exercise between both parties, and each should be invested in achieving a successful outcome. 

An end to the vicious cycle

As I look forward to the future, more and more competition in the market has led to technology vendors who are more transparent, open, and committed to enabling — and encouraging — people to try their products before making a large investment decision.

Additionally, the growth of microservices has led to the rise of software vendors willing to lean on one another to help businesses build the technology platform that will propel it into the future. (Side note: We recently spoke with Joe Cicman of Forrester about the future of digital experience platforms on this very topic, check out the recording of the discussion and the full report if you’d like to learn more.)

All of this means that the time is ripe to ditch outdated software procurement processes that require you to make a large financial investment before even determining if the tool is a good fit. All those in favor of building POCs and rapid prototypes that empower you to push the boundaries of innovation and experimentation, raise your hands.

I can’t promise that a POC will demand any less time or resources than an RFP, but I’ll guarantee you’ll be much further ahead when you start implementing. And in today’s rapidly changing market, that’s money in the bank.

Subscribe for updates

Build better digital experiences with Contentful updates direct to your inbox.