Intended Audience

Before we get into the depths of this blog post I think it’s important to define what type of procurement I’m talking about and who this approach is appropriate for. Each procurement scenario has it’s own nuences and challenges and one size certainly does not fit all.

In this series of blog posts I outline an approach which is applicable to organisations seeking to engage a supplier to build a bespoke software application, that is, the building of software for which they don’t have the capability or capacity to do internally and so need to bring in an external supplier. Scenarios for this could be:

• A government department issuing a tender for the building of their website
• A government department issuing a tender to build a custom software app
• A major retailer looking for a software house to build a supply chain software component
• A dotcom company outsourcing the development of a bespoke CRM system

The industry standard default approach to sourcing a supplier is to seek a fixed priced/scope supplier engagement, often resulting in a tender.

Fixed price fixed scope VS time & materials

The biggest hurdle I’ve found is moving the current fixed price fixed scope procurement model to a model more appropriate for bespoke software development. But why does it need to change? What’s wrong with the current approach?

There are many flaws in this approach when dealing with bespoke software development. It essentially attempts to transfer all risk to the supplier which usually results in the wrong kind of tradeoffs, i.e. degraded quality, late delivery, hefty change request costs and cost overruns. I’ve often heard the statement “well if you’re not willing to take on the risk then there’s plenty other suppliers who are”. Although this may initially seem attractive you need to think carefully about how these risk taking suppliers will deal with the risks – the risks don’t go away they are still there. Any delivery risk will still impact you as a customer if it turns into an issue so there’s no such thing as transfering risk on a bespoke software development. Attempting to transfer risk is giving you a false sense of security.

The root cause of this issue is fixed scope. So, if we cannot have fixed scope it raises a big question for traditional procurement thinking – how to procure the indefinite?

When faced with an indefinite situation how can you possibly apply a fixed price? Which leads to how can you openly and fairly compare potential suppliers if you don’t base your selection criteria on either price or scope?

The final nail in the coffin for procuring Agile software delivery services are templates. Yes, that’s right I said templates. I’ve often found myself in a situation dealing with procurement folk when they reach into their filing cabinet and the only contractual model they have is fixed scope fixed price. There are no alternative contractual models for time and materials based approaches in most procurement template libraries for the delivery of bespoke software.

How do you safely and confidently procure dev services on a T&M basis?

Over the next series of blog posts I’ll attempt to dig deeper into this subject and share my thoughts.