When you have a good idea, you want to get it on to customers asap. For years, marketing, customer service and product teams have been pushing for ever faster processing.
IT departments also want to increase speed, but are often hampered by the way they work.
I recently spoke to the head of delivery for an organization who said they wanted to move to agile releases. He has pushed his teams to break large projects into smaller releases so value can be delivered quickly, but the cost of delivery has increased and has become “prohibitive” according to him.
The problem is that cost is only measured in one way – the cost of delivering a single project. However, nothing happens in isolation. To measure actual costs, you need to consider costs across the portfolio. That brings me to the 6 hidden costs of large projects.
1. Build the wrong thing
We will start with the greatest cost. Yes, it might cost a little more to publish more often, but how much could you save learning that you are on the wrong path and shifting your focus before building the wrong thing?
Up to 66% of the functions do not deliver the expected value. Even without the other hidden costs, this is enough to justify the additional investment.
2. Holding costs
Hold cost refers to the revenue / value the company loses if it doesn’t release product features or fixes that are ready to be released.
When a project is approved, it usually has a return that is many times the investment – the business value far outweighs the cost of implementation. Even if you need to add a marginal increase in delivery costs, posting early will likely mean business is doing better.
3. Merge costs
Projects do not take place in isolation. For example, the company I’m currently working for has over 60 projects running at the same time. This means that code changes from projects that are now being deployed must constantly be merged into long-running projects.
Every merge carries a risk, but larger merges have an exponentially greater risk, which means that the merge cost increases exponentially with project size and duration.
4. Delay costs
Another problem that can arise is the premature enforcement of dependencies. Suppose you want to start a new project and believe that it will take 6 months to complete.
Another project is already in flight that will go live in 5 months. So it makes sense to base your changes on a branch of the previous project code. This will reduce the above merged costs, but if the previous project is delayed, you will be delayed too.
5. Block costs
With monolithic architectures, which are still the norm, there is only one configuration of code and infrastructure in production, so only one project can be on its way to production at a time.
This means that other projects have to be behind it. Larger projects have longer paths to production times that prevent other projects from being released.
6. Planning costs
When companies run many projects, they are often planned very close together in order to take advantage of the limited release windows across the portfolio.
As a result, project postponements have a cascading effect on subsequent projects. I refer to the resulting chaos as cycle planning; Align all the variables to generate a plan that works. If a dependency slips off, start over and keep repeating the process until you finally release it.
Once you’ve taken into account the number of projects in the portfolio, as well as the planning, resource management, and communication overhead, the cost of a single project loss quickly multiplies.
7- (ish). Change requests
Change requests are obvious, but controversial. The bigger the project, the more change requests are needed along the way. This is so accepted that many companies include the contingency of change requests in their project planning.
The problem with this cost is that it’s not just the change request, it’s also the analysis time, the approval time, and the rework time. While this is significantly more expensive for waterfall projects, I left it out because agile projects are also experiencing changes.
How can we reduce these costs?
Most of the costs depend on the size of the project. Smaller projects reduce these costs because features are released as they are developed, merges get smaller, the risk of delays is reduced, and the pipeline remains open.
The counter-argument is that the cost of regression testing increases because you need to make sure that you test everything on every small version.
Given the many advantages of small releases, there is a need to focus on fewer projects (and therefore fewer regression testing) to reduce the cost of regression testing.
The challenge is that the processes that are anchored in many organizations are geared towards large projects, as is the case with the company I mentioned at the beginning. If we want to push through smaller projects, we have to introduce “enforcement functions” that break old habits. There are two types of forcing functions that we can use:
Imagine if you could only spend a week on your way to production. What impact would that have on your projects? To complete your regression tests, you need to invest in automation or run risk-based testing. As soon as these improvements are in place and everyone adheres to the one-week limit, you can reduce the time limit to 2 days and trigger further innovations.
Basically we have to make the costs of our way of working visible, otherwise they will continue to be ignored. Taxes are a great way to achieve this goal. A tax that increases exponentially with the length of a project brings the cost of delivery more in line with its real cost. The result will be that people will start asking about smaller projects, or in those cases where you need to do a large project, the “tax” will fund the necessary technology and work improvements to keep future projects from going that way expensive. Both results enable smaller projects.
The curse of getting what you ask for
When projects become smaller and easier to share, the industry can be shifted to product teams across the industry, essentially removing the concept of projects entirely.
The teams are constantly releasing small iterations and constantly improving the systems they oversee. This is a much better structure for business results because you can quickly test ideas and rotate them if necessary.
The downside is that this is far more important to the marketers or other company representatives. You can’t just pass beautiful ideas on to others to implement.
You need to share your goals with the product teams and work with them continuously as you try new experiments to see what works and what doesn’t. While there is a lot more investment on your behalf, it is really invigorating to see ideas turn into reality quickly.
To learn more, visit UXDX, which is helping companies move from traditional waterfall projects to cross-functional product teams.