When most organizations start down the BPM road, it is often done with grand and lofty expectations. BPM projects, especially the initial endeavors, often are expected to be completed very quickly, with limited IT involvement, and deliver significant ROI in a short period of time. Vendors historically haven’t done themselves many favors and have fueled their customer’s perceptions that the LOBs can implement, change, and integrate their processes without having to significantly, if at all, involve IT resources.
Organizaitons often have the perception that by utilizing a BPMS solution, implementation will be quick and easy. While BPMS solutions can and do accelerate the delivery of process based projects, it often does not happen on the first, second, or even third project. Organizations often get lost in the lofty expectations of business tranformation and organizational agility to realize they do not have the skills, methodology, and infrastructure needed to implement as rapdily as desired.
Skills
There are a nubmer of skills required for BPMS based projects which are often constrained within an organization. On the business side, there are often only a few SMEs who truely understand the process well enough to document it enough to allow an implementation to begin. Because these users know the in’s and out’s of the process, they are often Super Users who are being pulled in a thousand different directions and fighting fires. On a positive note, that means the BPMS tool is being applied to a correct process! On the negative side, it often extends the amount of time needed to implement the process into a version that produces the expected results. Furthermore, the business case for starting down the BPM path often does not consider the training necessary to ramp up internal resources on the BPMS product. And as anyone who has been through training knows, understanding a product through training and being able to apply that knowledge to an actual project are two different animals. Unless organizations are planning to leverage a third party with specific skills in the BPMS tool, the initial time estimate often time is not going to be near long enough.
Methodology
Implementing a BPMS solution will require a tighter relationship between the business and IT sides of an organization. The historical waterfall delivery methodology simply does not work for BPMS implementations. Numerous articles, blog posts, and analyst sessions have outlined why iterative methodologies are better suited for BPMS projects so I won’t go into them here, but Agile, Scrum, and RUP skill sets are not are prevelant and encouraged within most organizations. In order to deliver BPMS project quickly, iterative methodologies are the only way to go. The time allocated to selecting a new methodology, how to implement the methodology, and the standard learning curve are often not considered in an initial BPM estimate.
Infrastructure
For and infrastructure view, it isn’t unusual to see a six to eight week lag time between identifying a need for a server and having the server installed and ready for the project team. Over the last ten years, I have been on more sales calls and in more meetings than I care to remember where the expectation was for an initial deployment to be six to eight weeks. It is hard to deliver something in six weeks when it takes eight weeks just to get a server available. Then there is the task of installing and configuring the BPMS product and then testing the various environments. Furthermore, the most significant value provided by BPMS projects is the ability to deliver the right data to the right people at the right time. In order to deliver the right data, there will need to be some manner of integration into the underlying systems. While initial projects should be scoped appropriate and not have a significant number of integration points, most often an itegration point or two is necessary in order to provide the value expected by the project sponsors.
Managing Expectations
So the logical question now is “how do I manage the expectations of the project sponsor?” While vendors are not going to make things easy since they often are pushing the BPM is easy mantra, as with most things in life, the key is communication. One of the most important items is to take an inventory of the skill sets needed for the initial BPM project and identify gaps which may need to be filled in the short term by third parties or resources from other areas of your organization. Another item is to establish a relationship between the BPM project team lead and their counterpart in IT. Having open lines of communication from the very beginning can make things happen much faster than when either group is caught by surprise.
Final Thoughts
When planning for an initial project, be certain to manage the expectations of how successful and how quickly the project will be implemented. The organizations I have worked with who are now the most mature organizationally around BPM all started with smallish projects, balanced expectations, and the support of senior management to make mistakes and learn. The early successes led to viral adoption of BPM within the organizations and most now have significant BPM Centers of Excellence and have begun to realize the significant benefits of being agile organizations.