As I mentioned in my previous post, most contracts attempt to transfer all risk to the supplier by locking in the scope, price, and timescales. What you’re actually doing here is locking in project failure from the outset. Your costs will almost certainly rocket as you get hit with change requests with hefty price tags. We have learnt over the past couple of decades that building software is a high risk creative endeavour subject to many forms of influence and change. As our assumptions of what we think we need to build gets validated and challenged we often end up with a product different to what we set out to deliver (the detail not the essence).

Building a product or providing a service?

When considering the engagement of an outsourcing partner, who will own the intellectual property (IP) rights to the software at the end of the engagement? I think this is a really important consideration in deciding what kind of contract is appropriate:

• Supplier owns IP – if this is the case then it would appear you’re buying an off the shelf product (however customisable). T&M probably isn’t appropriate in this case and the supplier should bear most of the risk. If this is your interest then you might as well stop reading now. This blog isn’t about this contractual situation.
• Client owns IP –  if the supplier is building a product on behalf of the client, or extending an existing product for which the supplier can’t repackage or resell as a product then they are clearly providing a service, not a product. Risk must be shared between the parties with the majority of the risk lying with the client – as (to put it bluntly) they’re the party wanting to develop the software. Of course the supplier can help them to drastically reduce their risk through specialist skills that may not be available at the client site, but ultimately it is the clients endeavour. 

How should risk be fairly apportioned?

As per a previous post on Agile governance the three areas of governance also align nicely to risk:

Building the right thing

The risk for this must fall squarely at the doorstep of the client – but not entirely. In most engagements I’ve experienced, the product owner is from the client. They are the ones prioritising stories (in consultation with all stakeholders) and pulling release plans together. The supplier must also contribute here to ensure enough feedback loops are in place through daily stand-ups, showcasing, user testing, and retrospectives to validate “are we building the right thing”.

Building it right

This is the responsibility of the supplier – but not entirely. The supplier should be capable and able to demonstrate as part of the tender process what techniques they use to build it right. All the usual stuff like Test Driven Development, Automated Testing, Continuous Integration, Continuous Delivery, and the like are all practices that contribute to building the product right. In a later post I’ll go through specifics on how you might set out an invitation to tender (ITT) doc and how you might go about comparing suppliers.

Integration with client systems beyond the remit of the software being built is common. This can pose a risk to the overall quality of the product when the remote system is flaky, or the client hosting platform is constrained. This is where the client needs to bear some risk.

Building it fast enough

Wouldn’t life be so much easier if there was some constant by which all developers could be benchmarked against? But as we’ve learned from Kanban it’s not just about the developers it’s about everyone in the delivery pipeline.

This is the area where risk has to be shared by both parties. Kanban for software delivery is extremely good at surfacing impediments – the things slowing the team down and even blocking them. If the team could unblock it themselves then they would. Therefore, the majority of the blockers found on card walls are external to the team. Examples of common blockers I’ve come across include:

• Dependencies on other teams to provide API’s or services
• Infrastructure teams providing dev, test, uat, live environments
• Connectivity issues with 3rd party sites or services
• Issues with group security policies that need some centralised team to modify (log a call)
• Awaiting sign-off of something to comply with regulatory requirements
• Release dependencies with other teams

Many of these impediments are systemic to the organisation. The delivery team need to be really hot on raising blockers, rallying the client, and swarming to remove impediments. How quickly you can deliver will depend on how much organisational drag you have. This is where the Agile Governance piece is critical in determining if the business case for building the software still stacks up.

Time & Materials

I believe a critical element for both parties to achieve success and minimise risk all round is to engage on a T&M basis. A T&M basis raises a number of obvious concerns from a client perspective – how do we control this? We don’t have an open ended budget! How do we know the supplier is going fast enough so we get value for money? How is poor supplier performance dealt with? In the next post I’ll discuss how to procure the indefinite.