Technical Discovery: The What and Why of It

Requests for Proposals (RFPs) have long been the bane of my existence. Not because I’m lazy and don’t want to write. Nor solely because I’m philosophically opposed to the notion that we should give away our 12 years of experience (over 100, cumulatively) for free. For the record, I don’t think any experts in our industry should do so.

My deeper issue with RFPs is that they often tell me precisely the desired solution and its cost. Which means either the client is self-diagnosing or has hired a consultant of sorts, very rarely the person, or persons, qualified (great–if they are) to implement the work. This is bad. For everyone.

The problems presented in an RFP – and their solutions – require an in-depth understanding of the client’s business and operations. We are no longer building websites. We are building businesses.

What is an RFP?

Let’s take a step back, identify what an RFP is, and what it typically consists of in the digital industry.

The Request for Proposal is a document put forth by a company looking for a particular service or services. The company articulates their problem (and too often what they perceive as their solution) and asks vendors to submit a document in return that details how they are going to solve that problem and at what cost. The document is usually expected to contain a host of other information about who the vendor is and their credibility, case studies, references, and usually a detailed timeline for the project.

All of this is expected to be done for free, as some sort of investment in the hope of winning the project. When you go to the doctor, even if it’s for a referral or consultation, you still have to pay for the office visit. Why is it that creatives are so often expected to give their work and their experience away for free?

The problem

I understand that we, in the digital industry, are selling more than a commodified, cut and dry, relatively the same, service or product. That as a company seeking a vendor, there’s a lot on the line and more than just a few bucks. But doesn’t that, in and of itself, make the case for an alternative process that would better ensure the outcome is more along the lines of what’s hoped for?

I have used this response before, more than once:

“To respond to this RFP with a proposal for this project would mean that we have to essentially put in as little time as possible, to get enough of a sense of what this project entails. And throw a number at you that will cover our bases amidst the inevitable and significant unknowns that are a result of not having a thorough technical discovery and strategy in hand. And, I guarantee you that is what every other agency you are getting bids from, is doing.”

It’s harsh and there’s a risk of losing the project right off the bat, but by some sort of grace, I have reached the point in my career in which doing things of value that I’m philosophically in alignment with, has outweighed pushing dollars and other numbers through the door. That is not to say that taking this approach has weakened the financial or cultural health of my agency in any way shape or form, it hasn’t.

The problem is that so many of us are just accustomed to doing things the way we’ve seen them done before. This is human nature and I get that. But this is a challenge, a call to action, to the digital industry, paving a whole new industry one day at a time, to rise above what’s been done before and do something the right way, the better way, the fairer way that elevates us all.

The solution

The right way is a paid technical discovery. By paying for expertise up front, by paying to have several firms dig deep into your business and the potential ways to solve your problem, you are acknowledging what is true: that there is no one way in today’s technological landscape to solve any particular problem.

The more complicated the problem, the more variable, plausible solutions. By spending the time and money to do this up front, to study the ins and outs of your unique operations and to compare various options different teams come up with (by being paid to dig deep and be diligent), you are taking out an insurance policy on your investment. It is the wise investor’s way of getting the best possible outcome.

We have been evolving our technical discovery process over the past several years, and will continue to iterate on it each time we do it. We break the process down by phases according to the scope of work at hand.

The technical discovery process

In the first phase of a technical discovery, we want to establish a framework for the project. This includes clearly defining the overarching goals of the project. For example, one goal might be something along the lines of: “To determine the fewest number of integrated third party tools that address all of our core operations at the lowest cost.”

This means that our job is to take a thorough inventory of the client’s operations. To do so, we identify each of the project stakeholders—everyone that participates in the operations—and interview them to get an understanding of their daily tasks and the most important parts of their job. It’s important to note the distinction between “must-have” and “nice-to-have” features.

We prepare documentation outlining what we’ve learned and send that back to the client to confirm we’ve got it right. We then compile what we’ve learned in each interview into one final document that addresses the comprehensive goals of the project, along with each component that we’ll need a third party tool to address. It is best to have an unbiased third party (such as ourselves) perform this discovery process.

At this point, we are in a position to begin researching and consulting with third party providers. This includes, but is not limited to, providers that address inventory management, POS systems, 3PL, shipping, etc. We will setup demos of each piece of software we’re considering, in order to have the client get a first-hand feel of the tool and ensure that it will work for them.

This process narrows down the potential right fit solution. Ultimately, the client needs to choose what’s best for them, but we see our role as helping to make that possible by cutting through technical jargon, and identifying loopholes or gaps from an unbiased perspective.

Once the client makes a decision as to what software is best, we are then in a position to put together a clear scope of work and assess costs. A typical RFP either leaves out the expert until the solution has been determined, or asks the expert to put in all of this work and do a good job at it without getting paid, which leaves very little incentive for the thoroughness this process requires.

The benefits of the discovery process are threefold:

1. The client dramatically decreases the likelihood of selecting the wrong platform(s).
2. A plan for the project is fully articulated up-front, lowering the chances for oversights down the line. This usually also shortens the timeline for implementation and gives the development team a clear scope of work to quote, eliminating price inflation for unknowns.
3. The foundation of the relationship between both parties is built prior to engaging in a six figure contract. This is only good.

Answers to questions like these should be expected as the outcome:

1. What will my minimum viable product (MVP) look like? What will be the solution and integrations with that solution to solve my core problems, without over spending on assumptions before I have real, live customer data?
2. How does the solution fit within my budget and timeline? Are there pieces of the project that can be phased in to get to market quickly and on budget?
3. Have I considered all stakeholder and administrator needs in the solution?
4. Does this solution create a solid foundation for my longterm business goals?
5. Have I considered the technical limitations and possibilities of all software I am choosing to align my business with?

I will say it again: We are no longer building websites. We are building businesses.

It’s like this

To take it back to the medical field one more time, most projects I see that are the result of a flawed RFP reflect this scenario: I have a toothache. I go the dentist, they tell me that I might have a cavity, need a root-canal, or need to have a tooth pulled. They tell me they need to do some further examination into the tooth, probably an x-ray, in order to determine what specifically is the cause of my pain. And, I have to pay for that further examination (in addition to the office visit).

But instead, I just tell the dentist that it is a cavity, even with my limited knowledge because I am not a dentist, but rather just a human that has a problem. I choose not to acknowledge this and have the tooth filled. A few months later, I’m back at the dentist and paying for root-canal because the wrong problem was fixed based on my unwillingness to pay for a thorough examination up front. And now, I’ve paid twice-as-much to fix my problem.

This is precisely the issue I take with RFPs and the motivation behind our technical discovery process.