By: Kris Collo, CEO, President and Founder, MicroPact
This is a story that many of us have heard before: An organization invests in some great new business process management (BPM) software in an effort to improve their systems and performance. They have a tiger team in place and get started down the implementation path. However, when they are well down that path they hit a roadblock – nobody wants to use the solution they have built – and ultimately the transformation they were looking for doesn’t materialize.
If you have seen this situation or found yourself in it, you’re not alone. Actually you’re in shockingly large company. According to Gartner analyst Janelle Hill, only 10 percent of the organizations that pursue BPM achieve enterprise success, due to the fact that many of the solutions that are developed haven’t benefited from the input of the people who will actually be using them.
The problem lies in the rigid nature of most traditional BPM solutions and the process oriented design constraints that often lead to these systems being built in a silo. Designing BPM solutions calls for a team of people who are experts in BPM. So even though a tiger team of experts may have architected a beautiful process solution, chances are they didn’t get as much input as they needed from the people on the front line — because it’s not easy for non-experts to give input into process-oriented system design. In the end, when the rigid process-based system is complete, having had little input from end-users, there is a high probability that it will fail to gain the needed levels of use and adoption.
Instead, the development of a successful BPM system should actually begin with the end-users in mind, should involve them in the process, and should be designed around how they operate. It seems obvious, but in the world of BPM it isn’t the norm. This concept of bringing users into the process upfront and designing the solution in a more iterative, agile fashion has been coined “design by doing” or “Social BPM.” In reality, this process is a little bit messy and can make traditional practitioners of BPM a little bit nervous.
I would encourage organizations to look at the entire life of the solution, not just the implementation phase when designing systems. Understandably the implementation team’s life may be easier and the design and implementation may go more quickly if outside parties aren’t involved. Indeed, if the implementation team isn’t tasked with looking at the entire lifecycle of the system they may well just build the system and say “our job is done” the day the system goes live. However, it is imperative that organizations make these teams responsible for the long-term effectiveness of the systems they are building. With this perspective they will feel more justified in slowing down an implementation to take into account the views, needs, and concerns of a wider user audience. Is this approach a little more work upfront? You bet. But if it leads to higher adoption rates and higher system utilization then it is completely worth it. It is this perspective that leads to “design by doing/Social BPM.”
Design by doing is difficult in that it does not follow a rigid requirements gathering and development path. Recently, one large federal agency embarked on just such a project. They used surveys, focus groups, user testing, and a host of other methods to gather input from their system’s managers and front-line users. Ultimately, after consolidating the feedback, they had a list of 4,000 line items that they wanted the new system to accommodate or address. The director then distributed that list back through the organization so that their teams could see in black and white that their input had been taken into account. Do you think these users are excited about the new system that is being built? You bet they are. Did this process take more time up front? Absolutely. And of course the implementation team has been going through the normal technical challenges of getting everything to work flawlessly but when it comes to system reviews and user testing, the excitement and anticipation from the user team representatives is almost palpable. They are able to see their vision come to life – the user vision – not the abstract vision of somebody that isn’t connected to the day-to-day system usage.
Of course not every system will involve the same amount of user input. At one end of the scale you have systems that are quite rigid in design, require little ad hoc decision making and follow a consistent predefined path – a vehicle registration system would be a good example. At the opposite end you have systems designed to support knowledge workers who have to weigh input from multiple sources and make a decision – such as a background investigation system. Knowledge based systems generally require more user input and frankly may be better candidates for a dynamic case management system rather than a more rigid BPM system. But in either case, if the system users don’t see the system as useful to themselves, adoption will be low.
All of this sort of begs the question: Do we still need personnel who are well versed in the philosophy and methodologies of BPM? I would say yes. But we need to push them beyond the flow charts and diagrams and expand their toolkit by teaching them how to elicit the needs and views of a wider audience, how to illustrate that those views have been heard, and how to build systems in a more iterative agile manner so that users can live it and feel the system as it comes to life.
___________________________________________________________________________________________________________________________
Kris Collo is the CEO, President and Founder of Herndon-Va., based MicroPact. MicroPact serves more than 200 federal agencies and organizations, as well as Fortune 500 companies, through the development of advanced Case Management and Business Process Management software.
Read Collo’s previous column The Path to Oz-Why You Should Follow the Data Instead of the Yellow Brick Road on WashingtonExec.
