Should we Incorporate “Process Debt” as a Concept in BPM?

Scott Francis
Next Post
Previous Post

I’ve been reconnecting with some concepts from the startup world, such as “technical debt” – well-defined in Wikipedia, but also better covered by this article, among others.

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?

  • Lance

    And this is the whole root of the concept of “Process Shift” where literally the process shifts in performance for a variety of reason and variation continues to build until you have a legacy process which is incapable of delivering as it must. And as they say, “Shift Happens”. Its not a question of IF but only WHEN.
    Good read Scott

  • Lance

    And this is the whole root of the concept of “Process Shift” where literally the process shifts in performance for a variety of reason and variation continues to build until you have a legacy process which is incapable of delivering as it must. And as they say, “Shift Happens”. Its not a question of IF but only WHEN.
    Good read Scott

  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Should we Incorporate “Process Debt” as a Concept in BPM? -- Topsy.com()

  • Lance, good point – although I think process debt introduces a new element to the process shift notion. If you take my meaning – process shift will happen even if EVERYTHING else around you is static – normal tendency toward entropy in a sense ;) Whereas process debt I think captures the idea that over time your actual notion of “good process” changes to reflect new market realities and business realities – and if you aren’t investing in your process, you’re actually incurring future cost (debt) of implementation to catch up. Process shift would be one kind of debt, I would argue, while “changing requirements” are another kind of process debt…

    Sounds like I need to write a followup and try to characterize process debt types more succinctly, as some of the types of debt clearly reduce to concepts like “technical debt” or “process shift” while some perhaps do not.

    I’m interested in more feedback out there – no login required, let’s hear it!

  • Lance, good point – although I think process debt introduces a new element to the process shift notion. If you take my meaning – process shift will happen even if EVERYTHING else around you is static – normal tendency toward entropy in a sense ;) Whereas process debt I think captures the idea that over time your actual notion of “good process” changes to reflect new market realities and business realities – and if you aren’t investing in your process, you’re actually incurring future cost (debt) of implementation to catch up. Process shift would be one kind of debt, I would argue, while “changing requirements” are another kind of process debt…

    Sounds like I need to write a followup and try to characterize process debt types more succinctly, as some of the types of debt clearly reduce to concepts like “technical debt” or “process shift” while some perhaps do not.

    I’m interested in more feedback out there – no login required, let’s hear it!

  • This is a great topic because it seems most of our focus in discussions around value of BPM tend to centre around the value it can help unlock in ‘the first run’ if you will, whereas the stage for more significant benefits are only just being set in the first run.

    A process that is experiencing BPMization, if you will, for the first time will see benefits of one kind, but then, approached the right way, it really would also introduce a paradigm shift in the way ‘process management’ itself has been traditionally viewed and conducted in an organization. And that brings in several lateral possibilities for improvement in the subsequent runs. It may even be unrelated to some of those factors that influenced the first run.

    From what I understand about Process Debt, first off, it does not have to be a bad thing – Scott, correct me if I am wrong here when I say that. But what is important may be to acknowledge it might/will exist and have a plan around addressing it.

    I think two important factors can help in addressing it – a carefully handpicked team of BPCC and a roadmap for each process that comes under the purview of a BPM initiative. The road map will be about business drivers, expected market drivers and related changes, not necessarily centered around the BPM inititiative itself.

    Periodic assessments of BAM data and related metrics in the context of the roadmap will be crucial to ensure continuous improvement and continuously ‘settling’ the process debt. THAT plan is what, in my opinion, will help exploiting money spent on BPM projects.

  • This is a great topic because it seems most of our focus in discussions around value of BPM tend to centre around the value it can help unlock in ‘the first run’ if you will, whereas the stage for more significant benefits are only just being set in the first run.

    A process that is experiencing BPMization, if you will, for the first time will see benefits of one kind, but then, approached the right way, it really would also introduce a paradigm shift in the way ‘process management’ itself has been traditionally viewed and conducted in an organization. And that brings in several lateral possibilities for improvement in the subsequent runs. It may even be unrelated to some of those factors that influenced the first run.

    From what I understand about Process Debt, first off, it does not have to be a bad thing – Scott, correct me if I am wrong here when I say that. But what is important may be to acknowledge it might/will exist and have a plan around addressing it.

    I think two important factors can help in addressing it – a carefully handpicked team of BPCC and a roadmap for each process that comes under the purview of a BPM initiative. The road map will be about business drivers, expected market drivers and related changes, not necessarily centered around the BPM inititiative itself.

    Periodic assessments of BAM data and related metrics in the context of the roadmap will be crucial to ensure continuous improvement and continuously ‘settling’ the process debt. THAT plan is what, in my opinion, will help exploiting money spent on BPM projects.

  • Steve

    I like the idea of process debt to describe some of the hidden cost of the decisions we make as we proceed with a BPM implementation or initiative. I think it can also be a mechanism for explaining how to use the debt effectively and to remember that it has to be paid back.

    In business we often borrow money to get a product to market faster. The speed buys us market share and an understanding of the market, from which we iterate our design and revisit our strategy. So the debt is worth it and we have to have some faith that the product will make enough money to pay back the debt.

    For many companies, BPM is a new thing, so they don’t fully understand how to use it, and they will only get this understanding when they “get it to market”. So, for example, a simple UI that isn’t as productive to use as the “perfect UI” is a good debt. It allows us to get our BPM initiative “to market” faster and start understanding it and adjusting our strategy. We just have to realize that like all debt, we need to pay it off at some point and improve the UI.

  • Steve

    I like the idea of process debt to describe some of the hidden cost of the decisions we make as we proceed with a BPM implementation or initiative. I think it can also be a mechanism for explaining how to use the debt effectively and to remember that it has to be paid back.

    In business we often borrow money to get a product to market faster. The speed buys us market share and an understanding of the market, from which we iterate our design and revisit our strategy. So the debt is worth it and we have to have some faith that the product will make enough money to pay back the debt.

    For many companies, BPM is a new thing, so they don’t fully understand how to use it, and they will only get this understanding when they “get it to market”. So, for example, a simple UI that isn’t as productive to use as the “perfect UI” is a good debt. It allows us to get our BPM initiative “to market” faster and start understanding it and adjusting our strategy. We just have to realize that like all debt, we need to pay it off at some point and improve the UI.

  • @Jaisundar – in my view, you’re correct – debt isn’t inherently bad – just like debt to buy a house or expand a business isn’t inherently bad. But it is still something we have to address in the future, and ideally we don’t want to build up so much debt that our “cashflow” can’t maintain the interest payments! (maintenance efforts and process improvement efforts).

    I think @Steve hits the nail on the head – we take on debt to get process out the door faster, learn from it, and proceed from there. I think process debt, as a concept, helps explain why it is so helpful to budget for more than one release from the get-go. Because you’ll want a .1, .2, .3 release to address process debt intentionally incurred during the initial roll-out…

  • @Jaisundar – in my view, you’re correct – debt isn’t inherently bad – just like debt to buy a house or expand a business isn’t inherently bad. But it is still something we have to address in the future, and ideally we don’t want to build up so much debt that our “cashflow” can’t maintain the interest payments! (maintenance efforts and process improvement efforts).

    I think @Steve hits the nail on the head – we take on debt to get process out the door faster, learn from it, and proceed from there. I think process debt, as a concept, helps explain why it is so helpful to budget for more than one release from the get-go. Because you’ll want a .1, .2, .3 release to address process debt intentionally incurred during the initial roll-out…

  • Pingback: Process for the Enterprise » Blog Archive » Creating and Retiring Process Debt at #bpmCamp 2010 @ Stanford()