Note: This blog post was originally written when I was a consultant for OpenSource Connections.
Scott Ambler wrote a very interesting article for Dr Dobbs Journal recently entitled «RFPs the Agile Way — or — Fear and Loathing in the Procurement Department.» I first came across the article when Deborah Hartman Preuss wrote an excellent commentary on InfoQ about Scott’s article, entitled «Using the RFP Process to Hire Agile».
As Ambler points out, the use of a formal RFP often implies that the client uses a traditional development method like Waterfall. Procurement writes an RFP, and then the consultant responds with a detailed proposal dictating timelines and cost estimates, and perhaps an up front design. All before ever meeting with the client.
The RFP process is a necessary evil of the consulting world, particularly in government contracting. But RFPs don’t lend themselves well to the very collaborative discussions you can have with a client when you are using an Agile process, or if you are securing the contract in person rather than electronically.
This topic relates somewhat to my upcoming presentation at Agile 2009, «How to sell a traditional client on an Agile project plan.» Although a lot of the advice I give in that talk can be done in proposals, most of it works better in person. And so I think that’s a real challenge to accurately respond (in an Agile way) to an RFP that assumes a waterfall development model.
At first I didn’t quite find the answers I was looking for in Ambler’s article. I don’t say that as a knock against the article at all, because it is well worth the read and I think it frames very well the problems with RFP processes. However, Ambler is mainly encouraging procurement people to change the way they structure RFP’s so that Agile people can respond to it better.
I’m not sure the procurement people are going to read his column or see the incentive to do so (which he acknowledges, and asks readers to send this article to procurement people they know). And so while I believe my Agile 2009 talk offers some strategies for how to positively discuss Agile in a proposal, I’m still in search of the holy grail. How exactly do you respond to an RFP «the Agile Way»?
But after reading Ambler’s article again, perhaps he does lay out some of the answers I’m looking for. He just does it from the opposite perspective. He suggests this advice for what procurement people should look for in an Agile response to an RFP:
(rather than lift all his text, I’ve just included the highlights below. I suggest you read his article for the full explanation)
The supplier should provide resumes Follow a reasonable set of rights and responsibilities for both the customer and the supplier to adhere to … how they will collaborate together. Propose how they will work with the customer. Produce potentially shippable software to the customer every X weeks. Allow the customer to monitor their work and work products. Follow the customer’s corporate development guidelines. Do full regression testing throughout the lifecycle. Provide a minimal set of deliverable documentation, particularly user documentation, operations documentation, support documentation, and high-level systems overview documentation. The customer should provide examples of such documentation if they’re available. Shared-risk strategy [for payment] which is fair to both customer and supplier. Indicate rough estimates and schedules, in the +/- 30% range.
That’s a great list of ideas for consultants to incorporate into proposals, even if the customer is not looking for them. I’m glad to see that we already do many of them in our standard proposal template at OpenSource Connections. In particular, we always talk about our «Open Approach» to projects, ie, the highly collaborative and open way that we work with our customers using Scrum.
This is all a sign of the increasing maturity and adoption of Agile processes, and if nothing else, that’s a good thing. Perhaps the procurement people will sign on eventually after all.
Recent Comments