I  found the solution to pricing agile projects. It has been staring me in the face for ages. You see it mentioned by lots of people: Anderson, Gilb, Cohn, Poppendieck, etc. It’s obvious really when you think about it. However, it took Alan Shalloway, Guy Beaver and James Trott to spell out the answer in their latest book. The short answer is: ROI. As Alan et.al, argue in their new book Lean-Agile Software Development: Achieving Enterprise Agility that, assuming you need to work up a RFP where scope, budget, due date and quality are locked, then you can respond and point out how iterative releases will ensure the project stays focused on business needs and enables a faster return on the investment of the project.

With this in place you break up the project into at least two releases, assuming that this is possible (you’re not building an air traffic control system as Allan et al mention), and determine the most business useful features to put into the first release and then get feedback on that while working on the remaining features of the product. If you can break this product development project down into more releases, then their is more possibility of greater feedback and an even earlier return on the investment. Needless to say, you use the usual agile approaches to improve quality, and handle scope.

Using this approach you can make a compelling proposal. First, you can deliver more functionality sooner. This helps to ensure the project achieves it business goals, by ensuring useful feedback earlier from real users. Second, you can provide a faster return on investment for the project, which releases funds back to the firm sooner. This enables the capital to be put to other uses sooner. Third, you may finish the whole project sooner than their planned date because you’re focusing on the needs of the business, and yes, you committed to deliverying all of the scope in the project, but this should happen faster due to your agile and lean approach to the project. This assumes that the scope mentioned in the RFP is still relevant at the end, and hasn’t been changed too much during the life of the project. In any case, you can assume to be able to delivery the completed project early, which opens up new possibilities for both you and the client. They can start another project, they can add more features, whatever.  As for you, your team can move onto a new project or continue with this one depending upon what the client decides.