I’ve recently been thinking about a number of experiences in my career where organisations who have a bias for delivery have uncovered options that were not previously available to them. I’ve also seen others who had a tendency to delay delivery (or at least deployment) to when their customers are “fully ready” for it.
This predominantly happens in organisations that have traditionally had long lead times for delivery. Often the transaction costs for delivery are quite high, but other times it may be that the process and thinking over time has solidified such that the delivery managers don’t consider other options.
Some of the arguments I’ve heard include the following (along with my counter arguments):
“That’s the way we’ve always done it” – That’s a Kodak moment waiting to happen. You can bet you’re bottom dollar that if you’re not looking to improve, then your competitors are. How long do you think that will last?
“It will cost too much” – This is often in the context of the cost of deploying without delivering – there is a run cost to have the hardware / systems there earlier. However, I would counter this by saying the hidden costs you’re not considering are:
- Lifecycle vs Project costs – if you deploy regularly during the project, you can test the deployment automation mechanism and be confident that it works at the push of a button. Delaying this often means costs are pushed into BAU where later releases are still manual and are longer, costlier and riskier
- Opportunity cost – by sticking to long cycle times, you are cutting yourself off to potential other opportunities that you’re not aware of yet
- Transaction costs are high – well, if we don’t do something about it earlier they will always be high. Maybe there are some ways that you can start to reduce these transaction costs that you haven’t thought of – perhaps start here.
- Have you fully considered the overall cost of delay if you get into a “large batch death spiral“? This is quite likely if you stick to this.
“Our users are not ready for it yet” – Perhaps, but have you considered all of your user groups? I’ve seen opportunities where you can do early releases to your staff / operations team often referred to as “Eating your own dog food” (a common practice at Microsoft). This is a great way to reduce overall delivery risk – particularly if you have a large delivery footprint.
What are some of the results we’re likely to see?
Some of what I’ve seen before are a combination of things, the key one is:
New opportunities – This is often not thought of and the value here can be enormous. I’ve seen organisations try to release a new product and it doesn’t go exactly as expected. However, by getting something out earlier, it’s given them a new capability / offering that has allowed for exaptation / transforming into other products or parts of products. By getting something out early they have created a new foundation for future revenue.
Other reasons for taking a bias to delivery include:
- Reduced delivery risk – particularly around timeline. Getting things out early and regularly so at least someone can use it helps validate if you’re really on track (even if it’s not your final target user group).
- Reduced costs – In some instances I’ve seen clients say “This often takes 12 months and can often fail – let’s see if we can get something out in 3 months”. It gets really hard to spend a lot of money in a smaller timespan.
- Stopping – There’s often an OPEX / CAPEX problem if you haven’t actually produced a usable asset. Some organisations, are reluctant to stop the large batches because it will switch spend to date to OPEX from CAPEX which will have deeper ramifications for the organisation and their customers.
- CAPEX depreciation – If you can start depreciating an asset in 3 months rather than 12, there are potential financial benefits to this that you otherwise wouldn’t have
How do we get started?
In a word – Leadership. By this, I mean someone has to have the vision and courage to see what is possible and make a change. This does not necessarily have to be done at the top level – I would encourage all Delivery Managers, Project Managers etc to consider this on their project.
If you’re working in a space and see this happen, try arguing with some of the reasons above and probe to understand why people might not wish to try it. It may just be “too different” to what they’re used to. You may need to break through any fear there in some way – you might want to create a greater fear in maintaining the status quo with the reasons above to create that movement.