Most responses to RFPs consist of a bid, a date, qualifications, prior similar engagements, development methodology to be employed, and a plan, with the plan usually presented in high-level and low-level Gantt charts. The plan is a demonstration of the work to be performed, as well as a staffing and workload cost estimating mechanism. To derive this information, the prospect’s RFP must be analyzed, with the requirements understood completely so that they can be decomposed into architectures and designs. When Scrum is used to bid on such a fixed-price, fixed-date RFP, these requirements would also be parsed into a new part of the bid, the Product Backlog. The Product Backlog would be used not only to show the prospect that all of the requirements were understood, but also to demonstrate that the bidding firm understood the priority of the requirements in generating value to the business. The most valuable requirements in solving the customer problems would be prioritized as high; the most irrelevant requirements would receive a low priority.
The firm making the bid would point out to the prospect that it had prepared a requirements list prioritized according to its assessment of the value and importance of the functionality to the prospect’s business needs. The bidding firm could then tell the prospect that it did this because its development process was different from most other professional service firms. Rather than delivering the system all at once, it would build the system increment by increment. The firm liked to work this way so that the team working on the system could show the prospect what it had built every month to ensure that it was on track and meeting the prospect’s needs. Every month, the firm’s team would get together with the prospect and review the functionality it had just built.
The bidding firm would then point out that this had some potential side benefits to the prospect. Because it was turning only some requirements into business functionality, if the prospect wanted to change some of the lower priority requirements because of changing business conditions, the bidding firm would be able to handle this with minimum fuss. It wouldn’t have put any effort into working on these later requirements, so nothing would be lost, nor would the prospect have spent any money on work that had not been performed.
As a concluding point, the bidding firm would also explain that its customers were often able to derive all of the business value they anticipated before all of the requirements were built. Following the 80/20 rule, many of its customers had been able to derive 80 percent of a project’s value from just 20 percent of the functionality. The lowest priority requirements were often unnecessary frills. If the prospect engaged the bidding firm, it would give the prospect the option of canceling the work early when enough business value had been derived and prior to the contracted end date. There would be a penalty, of course, but it would be less than having the unnecessary requirements developed and implemented.