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…

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…

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.

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.

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.

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.

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!

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!