Getting the foundations right for a BPM CoE means thinking about the business (Part 2)

But, before we go further, I’d like to refer all my readers to a new book that I co-authored – the ABPMP Common Body of Knowledge (Version 3). The CBOK is about process and how to deal with different levels of change – from transformation to optimization to improvement. And, yes, we do talk about CoEs along with almost everything else that is part of BPM.

Laying the right foundations

Before the CoE can be launched, it is important that the right foundation be put in place. This column is focused on the soft side (business operating) of this foundation – the side that is usually neglected ( to the regret of the CoE’s management).

This is not to be interpreted as meaning that the more traditional technical side is not equally important. It is simply that I have seen too great an emphasis on the BPMS or data side – to the virtual exclusion of establishing the business side foundation.

Do No Harm

Success is in the eye of the beholder. Even with requirements and test sign offs, when a change is implemented many projects are declared a failure by the "buyer" – the business. Removing this fact is a key foundation concern of the BPM CoE. Without it, no one will be eager to work with the new BPM CoE. Why should they bother?

The simple fact is that any change should result in improvement. But as we all know many fail in this regard – they do not result in improvement. Well, at least in some people’s opinions. We still have the traditional IT / business divide. And, we often have problems with business being fully engaged in the projects.

However you look at it, success clearly means different things to different groups. This includes the business manager, the worker, IT, and the customer. If any one of these groups loses in a change, the change will be a failure for them. And the argument begins.

A recent example of this was a meeting I attended about three months ago. The IT people in the meeting were proud of the new BPMS system they had just deployed and were telling everyone what a success it was. The VP of the business area listened for a few minutes and then calmly said that he had no idea what the IT people were talking about. From a business standpoint the project had been a failure and resulted in more work, not less. The IT people were stunned.

Unfortunately this is fairly common. IT delivers based on technical requirements that really don’t define how the business should work or the benefits the business is looking for. But each requirement gets checked off and even agreed to by the users. The problem happens when the individual requirement solutions are put together – the parts are OK, but the whole is a problem. The new business operation is not improved.

This is not simply a requirements definition problem. It is not a communication problem. Although both can play a part, the main issue is that no one is controlling the involvement of all the players or looking holistically at the way the business operation will change.

This issue is, "How many projects consider success from the perspectives of all who will be affected?" In most companies, the answer is none. One reason is that few projects consider impact or benefit beyond the requirements of the direct requestor. This has set the stage for the infamous project ripple.

This divide is an area of opportunity for the BPM CoE. It should stand between the two perspectives (traditional requirements and holistic business) and bridge the business / IT gap. That alone would be of great value. Because the CoE is BPM focused, it should be business focused and it should insure that both business operating and technical requirements are defined, aligned and holistic. It should also guide the project to make certain that the business will judge the project as a success – improves the operation and solves one or more problems.

Setting this expectation is a fundamental requirement for defining the value of the BPM CoE and obtaining business and IT management buy-in.

Pulling all parties together

I like to think that all involved or affected will look at a change as an improvement and that they will be willing to work together to make the project succeed. Good concept but difficult because of conflicting needs, priorities, approaches and more.

But it is possible to achieve is win/win situation if the company has a group (such as a BPM CoE) with the ability to consider improvement from different perspectives and coordinate activity. This presumes an ability to predict who will be affected by a change and what the impact will be. It also presumes that this group will have the ability to escalate issues. Once the scope and players are defined, the CoE can create a project guidance group of all those who will be affected. When done at the project definition stage, this allows a more accurate view of "success". It also allows a holistic approach to any solution with a broader benefit and buy-in.

This ability to identify cross functional and cross organizational players is often a weakness in companies today. But it is a must in the hyper collaborative operating environment of BPM. This is why a BPM CoE must be designed to consider any change from multiple perspectives and why the ability to collaborate with a wide range of managers in different business areas is important.

The objective is to build a consensus on goals and outcomes and then work backwards in the design to find ways to improve that are acceptable to most.

Building the long term perspectives needed to deliver this cooperative collaboration is one of the primary missed opportunities in many BPM CoEs. In starting your BPM CoE special attention must be given to building the necessary relationships with both IT and each manager in the business areas the CoE will serve.

This is the start of the constant job of selling the CoE and BPM in the company, which will be explored in the next column in this series.

[inlinead]

Read the full series: