What BPM Can Learn from the Lean Startup
- April 8, 2011
- 1 Comments
Since the beginning of the SXSW-interactive conference, I’ve posted a few times about the Lean Startup sessions and hinted that they might apply to BPM. Heading into the IBM Impact conference, this feels like the right time to talk about the Lean Startup as it relates to BPM – it provides a decent segue to the topic we will speak on at Impact – “Keeping the Business in BPM“.
Let’s Review What the Lean Startup is All About
It turns out, I’ve written about this before. But I think it is time to return to the subject with a little more perspective. The premise behind the lean startup is embodied really well by three charts . I’ve given each idea my own poor rendition here in the blog since I don’t see a good way to embed a single page from a SlideShare presentation.
First, Waterfall development techniques were designed around situations when we know the problem really well, and we also know the solution well, and simply have to make sure we deliver a quality result. It should be no surprise to anyone in the BPM space that this does not describe the typical BPM / Process Improvement project.
The second slide shows an innovation over the first: that when the problem is known, but solution unknown – a different technique is required to solve the problem: Agile development. There have been many proponents of an agile approach to software development, and it is arguably the most accepted methodology among software engineers. This does not mean, however, that it is always practiced, or practiced well, nor has it infiltrated all IT projects.
The third slide shows yet another innovation: when the problem is also unknown, the solution is unknown. At this point, we can’t rely on just documenting the requirements or interviewing the known user base. We have to apply what Steve Blank coined as “Customer Development” – getting out of the building and talking about our problem hypotheses with customers. When we get our hypothetical problems and hypothetical solutions in front of customers and discover we’ve “missed” the market, we “Pivot” – that is, take the lessons learned, and adapt what we’re doing to find an addressable market we can actually build a business around. Essentially, the lean startup keeps iterating and pivoting until it finds a business that it can scale (or until it runs out of money). Once it finds something to scale, the problem is no longer one of “searching” for a business model and solutions, but one of scaling an operation.
The coupling of the Customer Development process with the Agile Development process has been coined the “Lean Startup” by Eric Ries and others. Why do we call the problem “unknown”? Perhaps you think of course we know what problem we’re attacking – the startup company was formed to solve this particular problem. That sounds good – but actually startups only THINK they know what their business model will be. Google thought their model was search. But it was really targeted advertising delivery, based on Search and alongside search. Small startups pivot often, but we’ve also seen large companies pivot – as IBM did when it moved to really emphasize its services business.
How is BPM Like the Lean Startup? “Problem: Unknown”
Some readers should already be seeing a connection between the Lean Startup and BPM. But it helps to really spell it out. First, I propose that when you start a BPM project, you only have a hypothesis about your problem and solution. This is what we mean when we say the problem is “unknown” – that we have a hypothesis but it isn’t proven yet. How do we know that BPM suffers from this “unknown” Problem situation? Because the biggest risk to budget, or even success, of BPM projects, is getting the requirements wrong. As I often tell our team: “No, you’re not going to get good requirements up front for this project. And if you do, they’re probably wrong.” We have to approach projects with an open mind toward how requirements will evolve. Already, most BPM practitioners approach the solution as an “unknown” or “hypothesized” solution. This is why, for example, successful BPM projects typically have an Agile, or at the least iterative, approach to BPM development – it allows opportunities for course correction with the Business, getting closer to the “right” solution over the course of several iterations.
BPM Takeaways from the Lean Startup
But, the other side of the coin is that we BPM practitioners need to adopt some of the methods of the Lean Startup and Customer Development:
- We need to “get outside the building”. For the IT folks developing BPM solutions, this means going outside the IT labs and seeing how the “Business” really operates. Talk to them. Observe them. Read between the lines. Get their feedback on prototypes and early releases.
- We need to employ more A/B testing in our solutions. Don’t assume we’ve designed the right improvement to the process – prove it! A/B testing is de riguer in software circles, but not inside IT shops, and not in process improvement methodology. But it should be. I’ve only seen one BPM endeavor really embrace A/B testing – and it was a great success.
- The unit of progress is learning. This is a core principle of the Lean Startup. While we’re searching for the right problem to solve, and the right approach to address it, learning is what we want. An A/B test that shows we didn’t move the needle as we wanted to is a success if we have learned a better path forward or avoided a costly dead-end.
- Shift to Value-Based Delivery over Plan-Based.This means that we have to re-prioritize work throughout the project – to always keep the Delivery team focused on the highest value work. The plan is your hypothetical plan. Don’t stick to it when the facts dictate otherwise.
- Get the Business and the Technical Team working together. Seriously. Put them in the same space. Or the same room. Make them part of the same team. Make it the dream team. Because when you get the leadership and team right, everything else gets easier.
There is more to it than just this… But if we can just pick up these four things for our BPM projects, we’ll make dramatic progress on improving the process of BPM. It takes leadership to drive these behaviors – but I hope that leadership just needs a little bit of encouragement through education and familiarity with the concepts behind the Lean Startup. I’ll see many of you at Impact – in our session, I’ll touch on the whys and hows for a business-driven technical team. And if you read this blog, you’ll have some of the underpinnings behind my part of the talk. Of course, Lance and Reid have a few interesting points to make too! Wednesday, April 13, 3:15PM to 4:30PM, In the Venetian – Murano 3205 room: “Wells Fargo – Keeping the ‘Business’ in BPM”