Inspired by the tales of Søren Pommer, co-founder of Social BPM provider Gluu, I wanted to take a moment to share my insights into why some BPM programmes are always destined to fail, and what to do about it. In one of his latest posts, Søren details the trials and tribulations of an imaginary Scandinavian supermarket chain implementing a BPM programme [“Are you on a path to process wilderness”]. It’s a great article and worth a read, but I felt that Søren could have gone a step further to underline the top three key reasons for why Nordic Market took the wrong approach to BPM. Have a read and let me know if you agree:
1. The BPM Supertanker:
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 programme 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.
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.
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.
The Solution:
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.
Follow
