You want customers to know about your good ideas as soon as possible. For years, marketing, customer service, and product teams have pushed for faster turnarounds.
Although IT departments desire to improve speed, they often find themselves in a rut because of how they work.
Recently, I spoke to a Head of Delivery in an organization which stated that he wanted to shift to agile releases. His teams have been trying to break up large projects into smaller releases to deliver value quickly. But, he said the delivery cost started rising and “became prohibitive”.
The problem is, the cost of a project is only one measure of the cost. However, nothing is ever done in isolation. To measure the true cost of a project you must include all costs in the portfolio. These are the hidden costs associated with large projects.
The Wrong Thing is Being Built
We will start with the largest cost. It might be more expensive to release more often, but what could you save if you realized that you’re on the wrong track before you start building the wrong thing?
66% of features fail to deliver the expected value, so even with any hidden costs, this is enough to justify the additional investment.
Holding Cost
Holding cost is the loss of revenue/value due to not releasing new features or fixings that are available.
A project that has been approved typically returns more than the amount invested. The business value is far greater than the implementation cost. Even if delivery costs are slightly higher, early release is likely to be a better option for the business.
Combine Costs
Projects are not always done in isolation. For example, I currently work in a company that has over 60 concurrent projects. This creates a constant need for code changes to be merged from projects that are delivering right now into long-running ones.
Every merge comes with risk, but larger merges are more likely to be a disaster. This means that merge costs will rise exponentially as a result of increased project duration and size.
Avoiding Costs
Premature dependency enforcement is another issue. Imagine that you are planning to start a new project, but you believe it will take six months to complete.
It is possible to build your changes using a branch from an earlier project that is in development. This will allow you to go live in five months. The merged cost is lower, but you will be delayed if the earlier project is delayed.
Blocking costs
Monolithic architectures are still the norm. There is only one configuration code and infrastructure in production, so that only one project can be moving forward at any given time.
This means other projects will need to wait behind it. Other projects may be unable to release because of longer production times for larger projects.