Lean Startups and BPM
Just saw this blog post from Clay Richardson of Forrester, titled “Think Like A Lean Startup for BPM Success”:
The next day when I reflected on the conversation, I had a moment of satori. I could see that startups share the same risk/reward profile as business process management initiatives. Just like startups, BPM initiatives promise huge returns to investors and stakeholders. Additionally, just like startups, BPM initiatives are fraught with risks such as inadequate funding, low adoption, and difficulty attracting skilled resources.
My conversation with the student about the importance of business planning seemed to parallel conversations I often have with enterprise architects and business architects launching or retooling their BPM initiatives. Most tend to overestimate the BPM’s potential rewards and downplay — or do not fully understand — the risks involved with launching a BPM initiative. However, for the most successful BPM initiatives, I have found that their leaders tend to have a “lean startup” mentality.
Clay is largely on target in these two paragraphs (risk/reward are probably not quite the same in the BPM projects – at least for the individual people involved). But the most important similarity between BPM and Lean Startups is the fact that we don’t know the answers up front. We have hypotheses – estimated problems and estimated solutions. The goal of a lean startup (or a BPM initiative) is to iterate until the problem is known, and the solution is known. Some of the traditional approaches just don’t work because the problem isn’t fully known – which is why we always say that incorrect requirements are the biggest risk to your BPM initiative.
If you follow our blog, you know I’ve been writing about the parallels of Lean Startup and BPM for almost three years now. You can see the posts under the “lean-startup” tag. And of course you can find many lean startup points discussed in our other posts on startups as well.
One of the first posts I wrote on the subject references a presentation Eric Ries made back in April 2009:
In slide 22, we see the introduction of the Customer Development Process to the mix, and the situation is one where the problem is not known, and the solution is also unknown. So part of the journey is to discover the right problem to solve, as well as the solution that solves it.
I think a lot of BPM projects would do well to adopt this third method (or an adaptation of it) as well. At a high level we may know that there is a problem (opportunity), but we may not understand what that problem is at a detailed level that would allow us to design a good solution. So we have to do some level of customer development (in our case these may be users) to understand the problem adequately, and then use an iterative approach to get the proposed solutions improved and adapted as quickly as possible.