A customer just sent me a request for proposal (RFP) from a government agency and asked my thoughts before they respond. Here are some basics of the RFP:

• Government agency
• Wants a custom-developed software package
• Described application requirements in the RFP
• Want a fixed-price bid

As with most government RFPs, potential respondents are allowed to submit questions. Many of the questions were attempts to clarify the needs. Here are some general examples

with responses:

• Q: What are your technology platform requirements (database, server, programming language)? A: We don't publish those. We'll share with the winning bidder.
• Q: What are the security requirements for the application? A: Will be worked out in design after award.
• Q: You say the system must interface with other systems. What are the interfacing requirements? A: See attached spreadsheet (the spreadsheet contained a generic list of field names (IDNbr, SysRelCode, DeptFileNbr, etc.) with no explanation of what they were, what they contain, business rules, how often to interface, the mechanism, etc.

Real-Life Equivalent

Remember, this bid calls for a fixed-price - the vendors must say what their price will be to develop this system when they submit their bids. For anyone who doesn't live in the custom-software world, I'll use the "building a house" analogy, describing what I want and then the same sort of Q&A to illustrate what's going on:

• I want a 3-bedroom 2-bath house with about 2,500 sqft.
• Must have a garage
• Fixed price bid to build this for me

Q&A

• Q: 2 or 3 car garage? A: Will decide after we award the bid
• Q: Where is the lot? A: We don't publish the address. We'll tell the winning bidder
• Q: Besides the 3 bedrooms, what other living space needs do you have? A: Will work with winning bidder to define those details.

Results

My response to my customer was that if they couldn't get any better/detailed requirements from the agency (and sometimes you really can't in the RFP process), they were better off not bidding.

Here's what this agency will get in response from vendors:

• Bids with astronomical fixed prices. Reputable software development companies know that the information in the bid is nowhere near enough to define the requirements and hence, the price. So if the agency demands a fixed-price, the vendor has to submit something very high to accommodate all the final requirements and changes the agency will ultimately define.
• Bids with ridiculously low prices. Some providers will bid low, knowing that there is no way they can deliver a final finished product at that price with the spare information they've been given. But during contract negotiations, they'll hope to ask many more questions, get a much better idea of what's needed, and then say, "In our bid, we assumed XX. In our discussions, you've stated YY so we'll have to adjust our original pricing." The final price to the agency will likely be much higher and if price was a major determining factor, they might have chosen the wrong vendor.
• Less bids than they should get. Experienced custom software developer shops, recognizing that they don't have enough information to submit a realistic fixed price just won't bid. That could leave the agency with a lot less alternatives and force them to select from companies that either bid way high or unrealistically low.

Know what you're asking for....

It could be that the agency knows who they want to work with and didn't put a lot of detail into their requirements. More likely though, whoever put together the requirements didn't know enough about custom software development to realize that getting a fixed bid on the little information they published would be very dangerous.

Using the house analogy again, if you want a builder to build a truly custom house - one that you drew on a napkin - that he's never built before, it's going to be very pricey; he might be able to give you a ballpark pricing range, but you won't know until the end what the price will be. If you use pre-built plans with a materials list, construction drawings, and know the location, the builder can give you a better idea of price even if he hasn't built that specific plan before. If you buy a house from one of three model homes in a subdivision where the builder is building all the houses, they can tell you right up front what it will cost.

It's really the same with anything that's a custom build - custom electronics, a custom assembly machine, complete restoration of a rare antique car, and custom software.

If it's never been built before, you're going to have to sit down with your software company and define every single requirement. They can make suggestions as you go but until they know every requirement - you won't know the final cost.

Agile and iterative

One of the reasons that agile development has caught on so quickly is recognition that price, schedule, and effort can't be known until the final product is defined. But that final product often changes during development meaning that resources, schedule, and price change.

Custom software projects are alive and well but today's reality is that everyone wants faster delivery and an ability to be reactive to changing requirements as the business environment changes.

Organizations who require fixed bid prices up front with little product specificity may be satisfied with their project the odds are they that will be disappointed in the project overall at the end.

Final thoughts

If your organization looks at custom development projects, it's a good idea to select a custom software house that has a good reputation and then work with them in a series of small projects leading up to development - projects like "needs requirements", "ux/ui design", "prototyping", etc. Each of those smaller projects has deliverables that you can apply to the next project and they all lead up to the development phase. By building incrementally, you'll narrow down what's to be delivered as well as targeting your price.