You want customers to know about your good ideas as soon as you can. Marketing, customer service, and product teams have pushed for faster turnarounds for years.
Although IT departments desire to improve speed, they often find themselves in a rut because of the way they work.
Recently, I spoke to a Head of Delivery in an organization who 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 that the delivery cost started rising and “became prohibitive”.
Problem is, the cost is only measured in one way: the cost of delivering a single project. 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.
1. 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.
2. Holding Cost
Holding cost is the loss of revenue or value that the company suffers by 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.
3. 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.
4. 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.
5. Blocking costs
Monolithic architectures are still the norm. There is only one configuration code and infrastructure in production so 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.
6. Plan Costs
Organizations that manage many projects often schedule them very close together to maximize the few release windows in the portfolio.
Any project slippage can have a cascading impact on other projects. The resulting chaos is called circular planning. Align all variables to create a plan that works. If one dependency falls, you can start over again and continue until your release.
When you add in the number of projects in your portfolio, the planning, and overhead communication, the cost of one project’s slippage quickly multiplies.
7-(ish). Change Requests
Change requests are not only costly but also obvious. More change requests are required for larger projects. Many companies incorporate change request contingency in their project planning.
This cost doesn’t include the change request. It also includes the analysis time, approval time, and reworks time. This is a significant cost in Waterfall projects, but I have left it out since agile projects are subject to change.
How can we reduce these costs?
The project’s size is a major factor in determining the cost. Because features are released immediately after they are developed, merges are smaller and there is less risk of delays.
Contrary to popular belief, regression testing is more expensive because every release must be tested.
Because of the many benefits of small releases, it is important to focus on fewer projects and therefore less regression testing to reduce the cost of regression testing.
Problem is that many processes in organizations are biased toward large projects. This is what I was referring to in my company. We need to create “forcing functions” to break old habits if we want to force smaller projects. We have two options for using forcing functions:
1. Regulation
Imagine spending one week working on your production path. How would this impact your projects? You will need to either invest in automation or risk-based testing to complete regression testing. After these improvements have been made and everyone has adhered to the one-week limit, the time limit can be reduced to two days to allow for further innovation.
2. Taxes
We must make the costs of our work visible, or they will be ignored. This goal can be achieved through taxes. The cost of delivery will rise exponentially if the project is long. People will ask for smaller projects or, in cases where large projects are required, the tax will pay for the technology and methods-of-working upgrades that will make future projects less expensive. Both outcomes allow for smaller projects.
The Curse of Getting What You Want
The industry shift to product teams allows for smaller projects and easier releases. This effectively eliminates the notion of projects.
Each team releases small iterations, making improvements to the systems that they oversee. This structure is better for business results because it allows you to quickly test your ideas and pivot when necessary.
This is a problem because it is more complicated for marketers and other business representatives. It is not possible to just hand over your ideas to someone else for them to put into practice.
It is important to communicate your goals with product teams. You should also work continuously with them as you experiment with new ideas to find out what works. It is very rewarding to see your ideas become reality, even though it requires more investment.