Agile acquisition and fixed price

I have been quite busy lately and not been very active with this blog. However, discussion about agile acquisition has become more acute because there are few failed purchases in public discussion. I mean AKE and TEO, who’s purchasing procedures have been questioned by Valtiontalouden tarkastusvirasto. See more (in Finnish)

General public and politicians typically react to problems by requiring more front-end design and rigor to the procedures. This makes the situation worse, because it increases unnecessary costs and bureaucracy.

At first we need to understand that hiring a designer is different than buying something that can be accurately defined before the purchase. When you buy design work minimizing the cost is not the only and not even the most important consideration. There are huge quality differences in the various solutions offered by the vendors. Comparing them is not straightforward and easy. One of them could propose a COTS solution, another something based on SOA and 3rd one a fully tailored solution. Obviously, it is not possible to define exact requirements without any idea of the implementation.

Actually defining the exact requirements is exactly what the development project is supposed to do. If I knew exactly what I want I would not need the designer. The designer is hired for contributing while we work together to create the forthcoming software. Because software development is a common endeavor with the buyer and the vendor, asking a fixed price is somehow skewed. I, as a buyer would probably get the maximum price with all of the risks included in the prise. If the competitive pressure keeps the cost too low, my vendor can very easily compromise the quality.

It is also useful for me that my organization has an interest to lower the costs by removing unnecessary features. Prioritization is rarely happening in fixed price projects. But I still have a budget, idea of return of investment. To keep the costs in bay I need to collaborate with the vendor to spend the money wisely. Monthly deliveries of done increments of functionality are a safe bet. If the vendor can not deliver, I have to stop the project (and have that allowed in the contract) and try something else.