Failure is the Only Option
I can outright tell you that your BPM implementation is going to fail, and I will be right 9 out of 10 times. Is this scary?
Research has shown that even amongst IT projects only 20% of them finish on time. On BPM projects, the failure rate is even higher due to the immaturity of the technology and scope of the implementation. If you are implementing a BPM project with the current tools and using the current standards that are still in flux, you are on the bleeding edge of technology. So your failure rate is even higher.
In this article, we will discuss some of the major causes of failures. Once you understand a cause, the fix for it is straightforward to determine. However, implementing the fix is the greatest problem. For example, one major cause of failure is lack of communication. The solution is easy – need to foster more communication. However, implementing ‘better communication’ is easier said than done.
A Leap of Faith
Other than the fact BPM implementation is cutting edge, it has another facet that makes it different from a ‘normal’ IT project. It spans across multiple siloed department. By virtue of being a business process, we know that it has to span across the organization. The weakest part of a process is at the interface between departments, when the handoff does not work well.
In the past, each department went out and purchased the ‘best-of-breed’ application for it’s particular needs. However, not much consideration was given to the needs of the overall business process. Part of the reason for that was the lack of a ‘process steward’ who would have identified optimization parameters across the process.
What Fails?
Communication – We touched upon the fact that communication or the lack thereof can cause the project to fail. Communication now, has to be facilitated not only within the department but also across departmental boundaries. Whether you like it or not, the larger the organization, the greater the chances for politics and fiefdoms. Coming to agreement on simple things can take up vast amounts of time.
Success in this area has to be facilitated by a project manager working in collaboration with the process steward. The walls of fiefdoms have to be broken down – and this can only be achieved with executive support. At some point, if a consensus-based approach does not work, a dictatorial approach may be the only options. The sponsoring executive may have to issue a deadline “Reach a conclusion in X days, or you will have to live with the one I propose.”
Architecture – In many of the BPM projects I have seen fail, the architecture was weak. This was either because the teams would not be able to come to a consensus or because there was no single architect who owned the responsibility for the business process. Even with a Service Oriented Architecture (SOA) approach, it is not enough for the different applications to publish their interfaces and expect the consumer to adapt to that interface. Often times one architect who understands one business domain is moved into the position of higher responsibility. He or she then may have a skewed view of the solutions.
The solution would be to nominate a strong architect who understands the overall business problem and process to oversee all the interface definitions across departments. If such domain knowledge is not available with a single architect, an architectural team is a good compromise. The other option would be for executive support for a single architect who can work across departmental boundaries without being bullied.
Executive support – As you notice, the executive support is a recurring theme as being critical for the success of the BPM implementation because of the very nature of the project is that it spans across departmental boundaries. The business justification for the BPM implementation has to come from the top, with its full support all the way to deployment. Senior management has to be especially active in quashing politics and fiefdoms while maintaining a healthy environment. This could be very difficult to do.
One approach would be to force the department heads to meet more often in a non-threatening atmosphere to help build trust and to explain how the implementation will benefit all those involved. Each department should have to be given specific upsides, or else the implementation will fail.
Business IT misalignment – If the BPM project is kicked off with much fanfare but then later ‘thrown over the wall’ for IT to implement, IT will most likely get caught up in the allure of using the latest technology rather than addressing the business problem at hand, as it’s first priority. This is simply the nature of the technical people. What drives them is the technology and sometimes that can overpower the business need, if that is not monitored properly.
The solution for this would be for management to continuously monitor the progress through multiple modes. For instance, management should insist on regular meetings and updates, and perhaps even a way to ‘look into’ the implementation in real time – perhaps by looking at reports on the bugs or insist on a system to be available continuously to showcase the features that have been implemented so far.
Integration – It is a well-known fact that integration is amongst the most difficult part of an IT implementation, yet it is not given the attention it deserves up front. If two groups are building a bridge from either side, we better be 100% sure that they are going to meet in the middle.
One of the responsibilities of the BPM architect is to ensure clean and consistent interfaces. Any changes to such interfaces should be reviewed and approved minimally by the affected parties, but most preferably by all the architects involves to ensure that it does not cause any ripple effects elsewhere.
Testing – Many companies play lip service to testing. The reality is that business believes that they have allocated enough time for testing, but the implementation team decides to push out testing till the end. When the end nears and functionality is not yet completed, and yet the deadline remains the same, testing is compromised. In some extreme cases, the implementation team just ‘hopes’ that the system will work as planned. Inevitable it does not.
To mitigate this risk, management needs to insist on testing cycles start from the earlier phases of the project. Also, they need to get visibility into the testing process and plans to ensure that testing is proceeding as scheduled and is not compromised for other features. Management should also enforce a mindset that ‘testing is as critical as implementation’ and should rather push out the delivery date rather than release partly a partly tested system.
In Conclusion
In this article we covered some of the major causes of BPM implementation failures. The key to avoid these expensive errors is to constantly monitor and correct for it – much of which requires common sense management techniques. Execution is the key.
