We use cookies. You have options. Cookies help us keep the site running smoothly and inform some of our advertising, but if you’d like to make adjustments, you can visit our Cookie Notice page for more information.
We’d like to use cookies on your device. Cookies help us keep the site running smoothly and inform some of our advertising, but how we use them is entirely up to you. Accept our recommended settings or customise them to your wishes.

The RFP Stage: distilling requirements and budget

Suppose you tell the builder of your prospective house: “The house must have a kitchen.”  

And suppose the builder replies, “I understand. I’ll make sure the house has a kitchen.” 


Do you really know what you’re getting? Does the builder really know what you want? Do you both know how much it’s going to cost? How long it will take? And if, in 6 months’ time, when the house is delivered and the kitchen doesn’t have custom cabinetry, European appliances and a stone benchtop, whose fault is it? If the builder asks for extra budget when he finds out you’re after a Gaggenau oven, is that fair? 


We’ve already discussed some of the traps and learnings in the project planning stage, including how to define a better scope of work, and the risks of cutting corners regarding requirements. We’ve also covered the challenges of working with estimates and agile delivery. Today we’re going to talk about the RFP, which is ultimately where the rubber meets the road and businesses and vendors first meet. 


In truth, the modern RFP “process” is actually more of a dance. Organisations want a service or product delivered for a price that’s locked in early, and so they try valiantly to write everything they can possibly think they might ever need down in an RFP, and then follow it up with a contract to etch it in stone. Vendors, on the other hand, know deep down that guaranteeing anything upfront is fraught with danger (if it’s even possible at all) but they play along anyway, because if they don’t then someone else will.  


Given the high stakes often involved in software development projects, with McKinsey reporting that 66% of them run over budget and 33% over time, a lot hangs on what is arguably a relatively cynical process.  


And so the RFP is actually the start of where most projects go wrong: one-liners like “the system must support workflow”, “the system must support multilingual” and “the house must have a kitchen” (as well as other, off-the-cuff statements that say both too much and not enough) are just the beginning.  


Suppose we go back to that kitchen again. You’re considering two builders for your kitchen. You might tell them it needs to be an “amazing” kitchen, but because you don’t want to get ripped off, you decide not to tell them your budget because you want it to be competitive (just like an RFP), and you feel like you shouldn’t share this too early on.  


And so one builder might allow $40,000 for what they think is an “amazing” kitchen, and the other (who has experience building in high-end suburbs) allows $100,000. Is the second builder going to deliver a better kitchen, or is it just overkill? How will those builders know what “amazing” really means, to you? Does the second builder have a right to be disappointed if you chose the former? After all, you asked for an “amazing” kitchen. Surely $100k will get you a far more amazing kitchen than $40k.  


Still, driven by price, you choose the first builder, but then you’re left in the lurch because what you actually meant by “amazing” was an 8m galley kitchen with custom-built cabinetry, stone benches and premium appliances and when the builder found out about this, the price went up from $40k to $80k. Perhaps you should’ve gone with the $100k quote after all. Should you be annoyed? Whose fault is it? 


And how would things have played out differently if you’d shared your actual budget up front? The first builder could have factored in a better view of what “amazing” meant to you; the second could have decided how best to meet your needs for that price, and perhaps crafted a better solution overall.  


Much like the kitchen metaphor, building any software solution is a balancing act between the cost of a given feature and how much you’re willing to pay (or, how much you should pay) for it. “Bang for buck”, it’s called, and you want to get the most for yours. 


But this is where the RFP fails you. Depending on your priorities and needs, you might be more than willing to spend more on some things and less on others to achieve an overall outcome. The problem is that the effort to do particular things is sometimes not well-known up front, nor are your particular areas of priority well-documented or known within the RFP process. The balancing act between one feature and another is also not assisted by the lack of transparency over budgets: how much time you spend on one thing depends only partly on how much that thing costs; it also depends on other factors like your priorities, your long term goals, what you’ve done before and your overall budget. And none of that is easy to know within the constraints of an RFP process. 


So, the biggest problem from the service provider’s perspective is the secrecy surrounding the budget, and that therefore translates into the biggest problem from the organisation’s perspective because it makes the whole process counterproductive. In the end, the expensive and complex RFP process can ultimately be boiled down to the service provider (a) deciding that if they put a number on every feature you’ve asked for it will be far too expensive (b) instead trying to guess what your budget is without you actually revealing it, and then (c) putting forward a solution that they hope aligns with what you were expecting to see, despite the fact it won’t actually do everything you’ve asked for. 


Perhaps counterintuitively, sharing an overall budget in this process might actually contribute to a better outcome. Knowing an overall budget would allow vendors to compete on value, not price. It would also allow them to use their knowledge and expertise in your favour, helping get you the most bang for your buck far more effectively than if they’re trying to guess how much you’ve got to spend. 


If you’re not comfortable sharing a number, then my suggestion is to consider a benchmarking case study response rather than (or in addition to) an RFP, and share a budget for that. In fact, such a process can be a useful activity regardless, because it will allow you challenge the organisation running the RFP to demonstrate the value in their process and their costing model without necessarily locking anything in stone when it comes to your actual RFP. After all, locking things in at RFP stage is generally a good way to end up missing your expectations and not much else. 


If you want to go down this path, come up with a scenario that can be relatively accurately costed but is still large enough to use as a yardstick and assessment exercise in dealing with ambiguity and unknowns, and allows vendors to demonstrate how they add value for a given (realistic) budget. Then give vendors time to work with you on “solutioning” a detailed design and sharpen their hypothetical pencils. This process allows you to “try before you buy” and to see the vendor in action, and from this hopefully extrapolate their process, costing model and people into larger scale approach to tackling your RFP as a whole, or alternatively, use this process to shortlist a “trusted” group to whom you reveal your actual budget and then move forward into a second round. 


Remember, nobody is trying to do a bad job, but output always varies depending on the resources you make available to deliver it, and sharing a budget is one of the best ways you can make your expectations clearly understood. A $100k kitchen will always conjure up a different image to a $40k kitchen. Ultimately, service providers will always try to offer you the best and most appropriate solution, based on your requirements and priorities, for the price you have in mind. Most want to help you get value for money, and the fact the market is competitive will generally ensure that. 


So step one is to make sure your budget is realistic. Step two is to ensure your RFPs have sufficient clarity and avoid “one-liners”, but also focus on what you really care about, not every feature you might possibly ever need: list some future considerations, but don’t get bogged down on them. Step three is to consider sharing some example compromises, to help guide vendor thinking along the same lines as you, and step four is share your budget, because it’s the most efficient and effective way towards helping the experts help you spend your money wisely.  



Christian Brenner has spent over two decades building enterprise websites for businesses and organisations. He is currently the National Head of Technology for Merkle Australia, the country’s leading customer transformation partner, empowering brands to create distinctly better experiences. 


This article is the fourth in a five-part series. Follow Merkle Australia on LinkedIn for more.