Technical debt. The term has been popular for a while and is used to refer to a lot of scenarios. In my experience, one of the most overlooked forms of technical debt is created when operational support requirements are excluded from the project life cycle.
In many companies, operational support is not considered part of the project life cycle. Operations and project are often completely decoupled at the lower and middle levels of the IT department, only dovetailing because both divisions report to the CIO or VP of IT. Often it’s this very component of the life cycle which delivers the most value to the customer.
This disconnect is created when communication between IT and the rest of the business is limited. When the business defines objectives and timelines for code project with limited or no interaction with the operations team, the operations requirements that are needed to support various projects are presented in an abbreviated form or left out entirely. The project team might not even know that operations requirements exist until the code is almost ready to go live, if then.
I recently participated in an emotionally-charged meeting that was scheduled to review the root cause of the failure of a client-facing system. The project team was angry with the operations team for not supporting their code in a highly-available (HA) environment. The operations team was defensive, stating that they didn’t have the time or resources to address their backlog, including the HA environment.
The project team specified an HA environment in their runbook as part of their handoff to IT operations. The HA system was acknowledged by the operations team as a requirement to adequately support the live code, prioritized and assigned. However, the HA system’s completion was not considered release-gating by the project team, so the project was declared complete as soon as the code was live.
The project team expected their live code to be considered part of the production system, with accompanying up-time SLAs. The IT operations group was working on the HA environment, but didn’t have dedicated resources on the project, so its completion was a long, drawn-out process. The same people working on HA were also doing regular maintenance tasks, working on systems for other projects, and putting out fires. Again, where in this dispute does the customer value delivery exist? Doe most IT departments consider customer value when negotiating this type of delivery?
Part of the miscommunication was created in the beginning of the project, when people from the operations team were not included in the project team. It was exacerbated when the code was permitted to launch without an HA environment. It really snowballed when the project team went on to the next project not fully delivering the value of the code in terms of the delivery life cycle. The operations team, with its own unique requirements pushed code live without ensuring that the requirements were completed, and then repeated the pattern all over again.
After just a few project lifecycles, it becomes clear that the decoupling of IT operations requirements from business requirements within consecutive projects creates a backlog for IT operations that can’t be
surmounted without drastic remediation efforts. Futhermore this lack of oversight often reveals a lack of understanding of value delivery life cycles. When domains are permitted to hand their delivery over the fence to the next group they tend to value less quality over quantity.
Fortunately, this problem has a simple solution. It’s not easy, because it requires being realistic about how many projects your company can complete in a given amount of time. If you have are in the habit of ignoring IT operations requirements, you might be surprised at how much paying attention to them will slow your project completion rate. You might have to be realistic about the number of operations people you truly need to support your project work. You need to understand the value your creating for your customer is not realized until what you have developed is fully implemented and the customer is finding the value in it. You have done nothing relative to value delivery if you’re not ensuring the product you’re delivering is delivered in full.
In summary, pay attention to three key aspects to prevent a buildup of technical debt as a side-effect of project work:
1. Make operations requirements release-gating
2. Don’t launch on temporary environments to get the product out. Deliver your product to deliver value not presence
3. Bring operations people into the project early and often in the life cycle. In fact make them part of the life cycle if you want to succeed early.
Projects are not complete unless the systems on which they live are complete and delivering value to the customer. Anything not providing value to the customer is considered waste. Be the change agent in your organization. Stop throwing anything out to the client to see if will work. This isn’t fishing.
