Should we Incorporate “Process Debt” as a Concept in BPM?
Essentially, Technical Debt is the future cost you incur by taking short-cuts (knowingly or unknowingly) today. Of course, we explicitly choose sub-optimal solutions in the short term in order to have a shot at a better solution later (thus the axiom “Perfect is the Enemy of Good”). But we also incur technical debt when we inadvertently introduce defects or poor design decisions into production software.
In this post The Concept of Product Design Debt is introduced (to me) by Andrew Chen (@andrew_chen). Although the concepts of Technical Debt and Product Design Debt are not targeted explicitly at BPM projects, the concepts apply particularly well to iterative development projects, and to environments with a lot of change (in requirements and/or technical direction). As a result, it seems that they apply particularly well to BPM. Andrew walks through the example of Amazon’s website tabs that would grow seemingly without limit, before being refactored to something more manageable later (paying down the debt). If you’re truly running an iterative, agile BPM endeavor, the following passage may ring true for you:
The interesting part is when you get a couple months into your product cycle. You often end up with lots of half-done experiments lying around, an infrastructure that isn’t built to scale, and a mishmash of code that needs to be refactored. Most engineers know that in this kind of a case, the best practice is NOT to rewrite your code, but rather refactor it continually and take down the so-called “Technical debt” so that it’s always under control. However, there’s the other side of the coin, which is the product design. After you’ve added a ton of new features and stuck them all on the homepage, you create Product Design debt. The Amazon tabs at the top are a great example of this – you have a design philosophy built around tabs, you scale it as far as you can, and then you have to refactor your design.
He gives some great examples of how product design debt is introduced into production sites – but it isn’t hard to imagine in the world of process, where we’re often looking to alter our process designs to accommodate changing business requirements. The analogous question in BPM circles is whether the experiments and changes implemented in your process have created a process debt that needs to be paid down through refactoring.
In large part, I think you could describe the process investments of the last 20 years as having created great improvements in efficiencies, but they’ve also introduced process debt over time – processes have become more complicated than necessary, manual shortcuts have been introduced “temporarily” that became permanent, and IT systems were built to support re-engineering that couldn’t support ongoing change. In each of these cases, BPM can help surface this “process debt” and offer tools for carving it down to size.
The goal isn’t necessarily “zero debt” – but the goal is to keep it from getting out of hand. Even within BPM projects we can accrue process debt. This is independent of the technical debt we may have accrued that is purely technical – we’re not talking about running two queries where one would do – we’re talking about the process itself. Decisions about the process itself may be intentionally short of “right” in the short term, in order to get incremental improvement out the door. Or the design may have unintended consequences – creating a bottleneck where one wasn’t expected (squeezing the balloon, so to speak) – or fixing errors in one area and introducing errors in another.
There is yet another way we accrue process debt – and that is when our organizations fail to adapt to a changing business climate. If you rolled out a process two years ago and haven’t made any tweaks in the meantime, you have acquired process debt – a steady, growing gap between what your software and processes are designed to handle, and what the reality of current business conditions requires. After all, new products and services enter the market, new competitors enter, old competitors exit, and customer needs change over time. In a typical organization, the organization will wait until the process debt becomes quite large, and then address it with a big process improvement project, or a new software roll-out (new CRM system anyone?).
It isn’t that this decision to invest is wrong – in fact without a BPM Suite, this may be the most rational way to deal with process debt. But an organization focused on process needs to pay down this process debt along the way – and the best way to do it is with a robust BPMS and a team focused on BPM for the long haul, that can manage this process debt and keep it from getting out of reach. A BPM team that intends to really build capability in their organization for process improvement needs to account for the concept of process debt, and figure out how to manage it over time (and even pay it down from time to time).
Of course, some would probably argue that there’s no such thing as “debt” – that you are simply leaving yourself with additional work to do in a future iteration. But the argument for applying the concepts of technical debt, product design debt, and perhaps process debt – is that the “iteration” notion doesn’t properly help you capture the cost of decisions you are making now. We’re not talking about implementing 3/4 of something – we’re talking about implementing something that we know will cause a problem (as described above), and choosing to do it that way because we’ve measured that cost against other benefits which outweigh it. A classic example is when an integration isn’t available in time for go-live of a process – but we expect it to be in the future. In the short-term we can choose to take on that work with manual intervention (or a sub-optimal technical solution). But we’re incurring a future commitment to switch to that “correct” integration. It just makes sense to proactively manage these commitments as “debt” to be paid off.
So. I’ve made the argument in favor of including the Process Debt concept in long-running BPM operations. Are there good counter-arguments to be made? Are there problems with managing process debt the way we would manage technical debt?