How to Align Requests for Proposals (RFPs) with Agile Development

By now, most tech-savvy business professionals understand the clear benefits of agile development. Yet, most of the contracting and procurement folks have yet to align their practices with agile to leverage agile’s benefits.

Recently, I saw a request for proposal to build an enterprise level system for a quasi-governmental agency and in that proposal it asked for a firm fixed-price quote yet in the Project Requirements, the RFP stated that “this list of high-level project requirements will be supplemented by much more detailed requirements gathered during the Discovery work.” How can an agile organization possibly quote a firm-fixed price when the requirements have yet to be defined … unless you are simply buying a block of time or series of sprints?

The Agile versus Waterfall rub

The RFP author stated that the organization anticipates approaching the project through four main phases of work (waterfall) yet requests that contractors propose a methodology that uses an Agile approach.  Clearly, the organization has co-mingled agile development concepts with waterfall procurement and contracting concepts.

For agile to work effectively, organizations need to take the leap of faith and go all in.  When organizations do quasi-agile or semi-agile or partially-agile or force agile contractors to comply with waterfall contracts and procurement, failure is inevitable and people will use this failure as evidence that agile is simply a fad.

Fortunately, agile development can work with firm fixed price contracts.  However, the scope of work and acceptance standards must be flexible.  In other words, if an organization wants to buy a block of time, i.e., half a dozen sprints, then contractors can certainly guarantee a firm fixed price.  Simply multiply the hours in a sprint by the individual rates of the team times the number of sprints and you have a firm fixed price.

But, you can’t expect contractors to estimate how long something is going to take, how much work is involved, and the technical solution if the RFP only states high-level requirements and reveals that much more detailed requirements will be collected during Discovery.

Three sacred truths of Agile

As Jonathan Rasmusson so famously stated in his brilliant book, “The Agile Samurai,” there are three fundamental laws of software development:

  1. It is impossible to gather all requirements in the beginning of the project
  2. Whatever requirements are gathered are guaranteed to change over time
  3. We will never have enough time or money to do everything we want

So, if organizations want a firm-fixed price contract that’s fine.  Rule number 3 – money will be limited.  No problem.  But, requirements, scope of work, and acceptance standard must be flexible if you want to ensure that when time and money runs out, the most important and valuable features were delivered first.

For a deeper level of understanding about What it Means to be Agile, please see my Linkedin article.

Leave a Reply