Architecture & Process: Doug Reynolds

Doug Reynolds of AgilityPlus Solutions presented on critical success factors in a BPM implementation. I’ve known Doug a long time — back in 2000 when he was at Meta Software and I was at FileNet — and have had a lot of discussions with him over the years about the BPM implementations that we’ve seen, both the successes and the failures.

He talked about how BPM is similar to other performance improvement initiatives, but that there’s some key differences, too. Any successful BPM project has several facets: solution, project management and change management. Breaking the solution component down further, it includes people, process and technology. He feels that process is the place to start with any solution, since people and technology will need to meet the needs of the process.

In order to talk about success factors, it’s important to look at why projects fail. With IT projects, we have a lot of failures to choose from for examination, since various analyst sources report failure levels of up to 70% in IT projects. In many cases, projects fail because of poor requirements or ill-defined scope; in BPM projects, the business process analysis drives the requirements, which in turn drive the solution, highlighting the critical nature of business process analysis.

He highlighted eight signs of a healthy BPM implementation, using the word semiotic as a mnemonic:

• Stability. The system must be stable so that the business is able to rely on its availability.
• Exploitation. You need to exploit the technology — put it to work and continually improve your usage of it — in order to get the benefit. Buying a system that was very successful for someone else doesn’t automatically confer their level of success onto you.
• Management and leadership. You need executive sponsorship with vision and direction, but also have to consider the impact on middle management, who are heavily affected by changing processes in terms of how they manage their workforce.
• Inertia. You need to actively change the way people work, or they’ll keep doing things the old way with the new system.
• Ownership. Ownership of the solution needs to stay with the business, not transfer to IT, in order to have the focus stay on benefit rather than capability.
• Transparency. Some aspects of work may appear to be less transparent — e.g., you can’t tell how much work there is to do by walking around and looking at the piles of paper — but the metrics gathered by a BPMS actually provide much more information than manual methods. This “Big Brother” view of individual performance can be threatening to some people, and their perceptions may need to be managed.
• Integration. Integration with other systems can be a huge contributor to the benefits by facilitating automation and decoupling process from data and functional services. However, this can be too complex and cause project delays if too much integration is attempted at once. I completely agree with this, and usually advocate getting something simpler in production sooner, then adding in the integration bits as you go along.
• Change management. Change management is key to bringing people, process and technology together successfully, and needs to be active throughout a project, not as a last-minute task just before deployment.

Doug encouraged interaction throughout the presentation by asking us to identify which two of these eight are the most foundational, and eventually identified his two foundational picks as exploitation and inertia: using the system the best way possible, and ensuring that change happens, are two things that he often sees missing in less-than-successful implementations, and are required before the rest of the things can occur.