Top 4 Problems in Technology Delivery Today
Through our work with organisations with large and complex digital delivery ecosystems, we see a pattern of common problems that tend to manifest.
Anecdotally the feeling in the delivery organisation may be that delivery teams are overloaded, people are working long hours trying to keep up, but the demand is unrelenting. Leaders and stakeholders are frustrated, and this is manifesting in bad behaviors and a low trust environment. Key people are leaving, which only ratchets up the pressure on those that are left behind.
In this article, we will articulate the problems,
Problem: Extended lead time
Firstly a definition. Lead time is the time it takes for customer requests to be completed. Applying an everyday analogy, when you order UberEats, it would be the time between your order being confirmed and the food arriving at your door. Lead time is a key selection criterion for customers and one of the leading indicators of whether a service is satisfactory.
The customers in your delivery ecosystem could be various stakeholders in your organisation. Their requests might be to produce a new product feature (value creation), some enhancements and optimisations (value protection), fix some defects or incidents or work on some risk and compliance concerns.
Extended lead time on those requests represents a source of dissatisfaction for customers. As with your UberEats, the value of the product being delivered can be diminished as the lead time increases.
What we see consistently in many organisations today is a delivery system that is performing at capacity yet with ever-increasing lead times, with the resulting degradation in customer satisfaction.
Problem: Low predictability
One of the biggest sources of frustration is the impact that is caused by unpredictable delivery. In many cases, customers care less about the lead time than they do about the predictability of delivery. This is often not very well appreciated by people who work in delivery ecosystems.
Modern organisations are complex and require a high level of coordination to produce new products and services to the end customer. Having low predictability within your delivery organisation has cascading impacts on dependent business activities that are planned around delivery. This makes planning almost impossible and increases the complexity and risk to the successful execution of your business strategy.
Predictability is a key selection criterion for customers and one of the main indicators of whether a service is fit for purpose. Unpredictable services are commonly considered unreliable by customers. Many delivery organisations today, unfortunately in our view, are perceived in this way.
Problem: Low Quality
Quality is one of those broad terms that is hard to define, especially within the digital and product development space.
There is the internal quality (codebase, infrastructure, etc.), external quality (the product as experienced by the user), functional quality (does it do what it was supposed to do?), and non-functional quality, which describes “how well” it performs.
Each different quality problem brings its own challenges:
Low functional quality - Your product is considered unreliable, as is the value stream producing it. Having low functional quality is below the acceptable threshold.
Low internal non-functional quality - The product is hard to build, maintain and scale. Satisfying customer needs start taking longer and longer, even for the most trivial tasks.
Low external non-functional quality - The product does what it promises, but the user experience isn’t great, compromising adoption and retention. That can manifest as low performance (takes too long to load), poor usability (too many clicks to complete an operation or not intuitive user interface) or even by not having great/professional aesthetics.
As expected, quality is another key selection criterion for customers and another key indicator of whether your service is fit for purpose. If alternative options are easily available to the customer and the switching cost is low, they will just walk away.
Problem: High rate of failure demand
Birds of a feather flock together. Low quality is very quickly followed by an avalanche of complaints, incidents and defects. This only amplifies the problem because capacity that should be going towards satisfying customer needs (value demand) is being utilised on work to rectify low quality (failure demand).
We often see this establishing a strong negative reinforcing feedback loop. So now you are not only compromising your customer experience because of the low quality, but now you're delivering less and taking longer, which further degrades your customer experience.
Diagnosing the source of the above problems is complex, and as every delivery system is unique and the cause can be difficult to diagnose. However, there are common patterns and key indicators to look for the key sources of the problem. In future articles we will explore these key indicators in detail.
This is the first of a series of articles on Diagnosing and Rectifying Delivery Under-performance. In future articles in this series we will explore:
- Lead Time Distribution, WIP Age and Inventory Age
- Volume of work in process (WIP) and completed (Throughput) and upcoming (inventory), including trend analysis]
- Predictability of time to market, productivity and quality
- Percentage of work discarded after the start
- Percentage of work stale
- Flow Debt
- Flow Efficiency
- Key sources of delay
- In/Outflow ratio
- Key bounce back steps
Insights & Causal Factors
- High WIP
- Frequent expedite work
- Undefined or weak pull-transaction policies
- Low liquidity with a high level of dependencies on individual contributors due to skillset and domain knowledge
- A culture of urgency frequently trading quality for speed, gated process with several queues throughout,
- An apparent mismatch between capacity and demand for selected teams, high bounce-back between dev and test.
- Reviewing WIP limits between commitment and departure matching in/outflow
- Defining classes of service with explicit policies on delivery ecosystem behaviour
- Defining clear pull-transaction policies
- Reviewing common critical sources of delay
- Reviewing common causes of high bounce-backs between dev and test stages
- Reviewing common reasons for key person bottlenecks