The ownership cost of building software
Photo by Sharon McCutcheon on Unsplash
Many organizations with large or complex application portfolios struggle with prioritizing development on existing solutions. It seems difficult to justify effort and resources particularly if the system is actively serving its purpose. The expectation to keep these systems operational without a long-term plan becomes difficult to manage and outright demoralizing. Years of modifications, workarounds, and unused code begins to take a toll. Communicating the reality of these challenges is often misinterpreted or ignored due to the inherent complexity.
The Problem:
The root cause of the conflict is buried in how business have traditionally approached development/implementation of systems. The “project” approach promotes set time, cost, and materials. After the “objective” has been completed attention moves elsewhere and stakeholders assume the solution will solve the problem for the next [x] number of years. There are several issues with this line of thinking:
· The process changes · Infrastructure changes · Bugs wait to reveal themselves · Hackers find new exploits It Gets Worse:
With the progression of technology things are always changing and the cracks in the project philosophy are showing. In an era where customers expect instant value and tailored experiences, growth of technology must become a continuous effort. You either need to continue investing or apply a modernization strategy. Ignoring this over time can impede an organizations ability to compete.
The Answer:
The answer is a change in mindset. Organizations that realize that every technical solution comes with a long-term cost are better equipped to focus on what makes sense. When decision makers start thinking in terms of delivery streams vs projects it becomes possible to start managing a portfolio in a reliable and predictable way.
How is a delivery stream different from a project? 1) Delivery streams are managed by permanent teams aligned with specific platforms and/or processes.
The key term is “permanent”. The technical solution doesn’t magically disband and disappear, so it is curious that organizations seem to think the teams should.
2) Delivery streams prioritize all aspects of a solutions lifespan:
Long after the solution has been delivered it will require attention. Maintenance can be broken down into life-cycle, break-fix, and enhancements. Life-cycle work could be defined as work that is required to keep the application operation and manageable (such as tech debt and security fixes). Break-fix is the effort required to troubleshoot and fix issues that have stopped the system from functioning. Enhancements are new functionality or a change in existing functionality.
3) Delivery streams require regular collaboration between IT and business stakeholders
This doesn’t work unless both IT and the business stakeholders are fully committed to managing the stream long term. This also means the aligned team gets say in what needs to be prioritized. Its up to the aligned team to help the stakeholders understand the risks of not prioritizing non-business objective work and it’s up to the stakeholders to help the team understand the risk of not doing the added-value work.
4) Delivery streams require everyone to ask the difficult question “do we need this?”
If the solution to a problem isn’t worth continual investment of time and resources then one must ask themselves: is the problem important enough to be solved. This becomes clear when an existing solution within a work stream becomes problematic and time consuming. If it prevents the team from accomplishing the more important work — everyone begins to see the impact.
Originally published at https://7samurai.dev on December 29, 2020.