Is IT Killing your BPM Success?

Flournoy Henry
Next Post
Previous Post
I find it ironic that it’s often the IT department that pushes for and obtains a BPM solution. Again, it’s the IT department that spawns the first BPM evangelists in the enterprise and sets out to internalize and deploy BPM solutions; all with the hope that their business counterparts will “get it” and run with the benefits of process management and become true participants and later owners of the solutions. Yet, all too often, it’s the IT department that then slides into their familiar role as software developers and begins writing software instead of managing processes. They may deploy one or two quick process solutions and then comes the project or program that begins to derail the vision; the process centric vision that is. The project starts, you know, the one that’s larger than it should be, a seemingly invisible scope boundary, involves business units that don’t even know their included; yeah, that one. The group meetings start with good intentions, the process is kept in the middle for a while. But then, the conversations about how the interface looks, how fast will it run, what kind of system integrations are “we” going to pull off, begin. And suddenly, everyone loses focus of the business process. Suddenly, the “IT guys/gals” are writing software and the business analysts are trying to keep up with the requirements. The group meetings including the business sponsors give way to technical meetings with whiteboard discussions about how the BPM tool will be bent, prodded and tapped into to accomplish the “tricks” at hand. At the end of the day (month, year) you’re left with perhaps a slick solution; but where’s the process? Is there a useful process artifact for which the business sponsors can consume? Is the business unit ready to assume ownership and ongoing evaluation of the business process solution delivered? What about real process metrics, no, not the custom reports that were glued together on top of the custom database wired into the solution; but the real process metrics that could/should be gleaned from an adequate process model? These are the things that get lost when the process discipline and process centric visions are abandoned. What to do? If I had all the answers I suppose I’d write a book instead of this blog, but I do think we can start with the Project Manager role. This role is usually rooted in or reports to the IT department. As such, they’re often more focused on time lines, budget, and meeting requirements. Understandably so, but if this role were also responsible for an effective transition of ownership to the business sponsors/process owners, perhaps we could take some measures to keep the process centric view intact. From the start of the project, the business sponsors should be accountable for delivering a series of statements regarding the metrics they wish to obtain from the proposed solution. In addition, they should be required to agree upon the manner in which the solution will be deemed a success or failure; this often tied to the metrics acquired. The Project Manager should keep this “project contract” or “decree” if you will in focus at each meeting. When scope is concerned, if the item in question does not lend itself in support of the metrics and measurement for success, then it should not be considered (at least for the first release, table suggestions and “sugar coating” for subsequent releases) . After all, an important goal of BPM is to deliver timely solutions with an opportunity for rapid change; that too must not be lost in the vision. Many project teams are conducting routine “play backs” with their sponsors, but all too often these merely include screen shots or execution of interface screens and/or reports. Again, the process should run front and center. The process owners should know exactly what their process looks like before it’s delivered. They should be acutely aware of the swim lanes that exist, the roles associated with each, the activity steps defined. These are the things process owners manage, not an interface screen. Upon delivery, the Project Manager should conduct routine meetings with the process owners and hold them accountable for the metrics they stated were necessary. The same measurements for success should be evaluated again and again. The Project Manager must evaluate his/her own success against the process owner’s ability to own the process, to understand the process, to measure the process, and ultimately to be empowered to improve upon the process.

Related Posts

Budget First