I was recently inspired by tales of Spommer, a blogger detailing the trials and tribulations of a Scandinavian supermarket chain implementing a BPM program [“Are you on a path to process wilderness”], to consider what makes BPM projects fail. I wanted to take a moment to share my insights into why some BPM programs were always destined to fail, and what to do about it.
Failure Scenario #1: The BPM Supertanker
Often, what starts out as best intentions by IT to make the business more efficient grows into a Frankenstein monster; too big to succeed, or even so big that it has to fail! Scope quickly grows out of control, loads of decision makers become involved, each with conflicting priorities and requiring a global delivery team – none of which will help the program succeed. The resulting BPM ‘supertanker’ drains life from the business and becomes a sump for resources, capital and innovation. The initial business case was doomed from the outset.
Failure Scenario #2: Waterfall kills adoption
As detailed on Spommer’s article, we often see instances where large project teams are spending huge amounts of time detailing requirements with the business up-front before disappearing into their mysterious cave to start development. Months later the team resurfaces with the project now resembling something like Grendel the monster. Waterfall delivery for business-led projects rarely works; it is vital that the business and technology work together to deliver benefits.
Failure Scenario #3: The inevitable change dilemma
This topic comes up time and time again; at pretty much every meeting we attend and it is a question that has its roots in the underlying approach. How do you stop the business resisting change when implementing a BPM project? The answer is to understand WHY the solution will improve the day-to-day operations of those it affects – and then to communicate that clearly and at all levels. Failing to do so will lead to resentment, conflict and opposition for what you are trying to achieve. That’s why we believe BPM should be viewed as a change project, not an IT project. People and Processes are fundamental aspects of the new way of working – and technology should be viewed as the catalyst for success, not the cornerstone for implementing change for the sake of change.
I recommend small, agile projects that demonstrate value quickly. BPM doesn’t have to be a long erroneous and expensive journey; it should be short, sharp and focused on delivering business value. BPM projects can (and are) delivered in months for hundreds of thousands, not millions. Agile enables the project team to release something quickly, gain feedback and buy-in from the business, which can then be improved in the next iteration. T-Impact has delivered many BPM projects where our BPM implementation approach has provided a sound and robust agile methodology for surpassing expectations. It is built upon close and structured collaboration between line of business and technology, allowing confidence to be built in both camps. By delivering a small yet impactful project it is possible to deliver benefits quickly, with future iterations delivering more and more benefit as the project scales out.