Who needs to drive improvement projects to make them successful?

Going beyond involvement to gain commitment

• IT application capabilities
• collaborative partner needs
• the BPMS vendor’s idea of how the BPMS should be used
• some consultant’s opinion
• the business manager’s needs
• BPM CoE standards
• finance and cost reduction

All are valid perspectives, but who should be the most critical driver of a solution that really delivers benefit?

Ridiculous question? I originally thought so, but I have recently had to not only answer this question but to debate the answer.

So who do you think needs to drive any improvement? Think about it. Every participant has a different view and all are valid. Company politics and other factors also enter into the answer.

The fact is that senior managers or sponsors need to fund it and at the end of the day they must be happy with the outcome. But they won’t be directly involved. IT will need to build, buy, or make changes to applications but they don’t have the background to really understand the ebb and flow of the business and implications of actions. So, neither senior managers, sponsors, nor IT should lead business process improvement. So, who should?

My answer is the business managers who will be affected should drive the solution. Everyone else will participate, but in the end, if the people who need to use the solution declare it a failure, it will be a failure. Period. End of story. For years I have felt that this was a "cut and dried", obvious answer.

The interesting fact is that I have started to get serious pushback from business managers who claim they don’t have time to engage and support transformation or even improvement projects. This shift may be isolated, but I have seen it in several companies recently. I have also seen a growing trend in IT to become the driving force within the company for business modelling and change.

Unfortunately, this seems to be driving a perception by many that BPM is becoming an IT function. This may be a result of the fact that improvement or transformation always has an application component and even if applications are generated by a Business Process Management Suite (BPMS), most solutions include interfacing to legacy data or applications.

In addition, many IT departments are trying to fit this new technology into their current approaches and are reaching out to their business leaders to offer BPM support. This is great but it seems to be having a negative impact on at least some business managers in that it is pushing them back to old habits and relationships with IT that have never worked well.

The habit that seems to be re-emerging is that many business managers are starting to think that giving IT some requirements is all they need to do! A couple of requirements workshops, a quick review, and then their part is finished. Business as usual! Change as usual! Results as usual!!!!

The question that comes to mind is "how has that worked out for you in the past?" If the answer is great, leave it alone and continue as is. But, I seldom talk to people who think their business operation is optimal or that their IT support is as good as they need it to be. So why would you now think the same old approach will give new results? Something needs to be fixed! And at least a big part of the answer is driving the change from a new business operating design – not simply from a set of business requirements that IT will translate into technical requirements for some change in support.

As a BPM evangelist, I believe that BPM and BPMS together provide the foundation that is needed to change the way the business is operated. However, BPM and BPMS require collaboration. They also require a business perspective to be successful. It is part of the BPM framework and the need to collaborate is embedded in most of the BPM concepts and techniques. BPM, accordingly, requires business operation involvement and a commitment from business management if it is to deliver its potential.

The fact is that only the business managers can determine the real impact of any difference in the way work is performed and the benefit of the change. No one else can make this determination. To make certain any approach or solution is sound, business managers and staff must be involved throughout the effort – they cannot participate in a "requirements definition" and then back away to see what IT builds.

In addition, acceptance of the solution by the business managers and staff is critical. Regardless of any other aspect of the process improvement, the solution must be accepted. This is the reason for the old saying that a project can be a "technical success and a business failure".

The business managers must accept the responsibility for making certain the solution gives them an optimal outcome. When they are not committed to the project, the outcome is dependent upon other people’s thoughts on how the business should work.

In reality, there are only two ways to deal with change. You can either do it "to someone" or "with someone". There is no third option. The choice of these approaches is directly related to business manager involvement and the commitment of business resources to the project.

Are you doing change to or with them?

Business activities constantly evolve. We all deal with that every day. In doing so, creative business managers find ways to get the job done. Underlying this change is an active, constant involvement by business managers and staff in all parts of the change. Where these changes can be delivered through manual work around activity, no one outside the group even knows anything changed. Things just keep working. But, everyone in the business unit suffers extra work, extra stress, and a failure of management to understand why it takes so much work to do "simple things". However, if an application system needs to change, the business managers must go outside their unit.

This is also where improvement really becomes a project that requires different skills and collaboration. However, the fact is that many companies have cut staff to the point where they barely can keep up with the daily work. For these business managers, taking staff and dedicating them to anything is an issue. This is where the redesign often becomes the responsibility of people external to the business unit.

The result is that the old approaches of relying on requirements instead of collaboration and improvement based on formal business redesign, once again kick in. Worst of all, without addressing the redesign of the work holistically, the business managers often create more manual work around the solution to "get by".

When this separation takes place, the project team will have only minimal input from the business operation. This in turn forces the team to work in a guessing mode – they are forced to do what they think will be a good way to improve the operation. This "outside in" solution building is "doing it to the business". But, it is also the only option when the business managers are not committed and not willing to invest the time and knowledge needed to deliver a solution they believe is optimal.

Make sure you're "doing it" with them

As you have probably guessed, "doing it with them" is just that – integrating business area managers and staff on an ongoing basis into the project team. I have found that doing anything with the people who will be affected is much more prone to success than doing things "to them". In fact, the more time they can spend on the project, the better.

The reasons include:

• Those who will be affected by a change should be committed to it – the need to have "skin in the game" – they need to want it to work
• Those who will need to perform the activities and use the applications that will be changed are the best people to ask how something will affect them – people want their opinions to be heard
• It is always better to work with people and negotiate a solution than it is to impose something on them – history has proven that when a solution is imposed, people will reject it
• Because most business operations are poorly documented, the only people who will know how things really work are the people who perform the work – so talking to a broad group of managers and workers gives a much better understanding of the real business operation
• No activity is conducted in a vacuum – everything is part of something else and interacts with other people, processes, applications, production operations, and support services – these interactions need to be clearly understood
• All change ripples through an organization – predicting the ripple is dependent on the knowledge of the people on the floor – the "doers"

While all of these points are true, the problem of business engagement in BPM projects remains. The issue is how to get someone who is not interested in committing the time needed to help themselves, to engage. The problem is really just that simple. However, the answer is clearly not simple. If it was, it would have been resolved 30 years ago.

When I was young and naðve I believed that you could count on a person to do what is in their best interest. I felt the same would be true for managers and companies. I learned that I was wrong.

The issue is perception. What I or anyone outside a group thinks is in their best interest can be very different than what they think is in their best interest.

This is why so many "outside in" approached projects fail. Avoiding this is where collaboration comes in. In BPM it is important to understand everyone’s perception of benefit and how it can be achieved.

Eliminating this danger requires communication and a melding of ideas and goals. It also means that no one has the right answer for someone else. So the solution must evolve as people work together and share background and ideas. This is why commitment from all involved to the project and solution is critical to reducing the risk of "a technical success and a business failure."

Managing Risk

Although I personally believe that any project that does not have the right engagement and commitment from all the participants should be cancelled – even if it has already started, I understand that this dramatic position is not acceptable in many companies. So what do you do?

The fact is that each company culture is different. The approach to a solution will accordingly be unique to each company. However, the need for business area commitment is common to all BPM projects and any lack of commitment increases risk. This should be explained as part of expectation management. The business solution must drive the application needs, production capabilities, social media use and more. As many BPM managers have found out, this issue is a failure level concern.

To help manage this issue you may need to consider breaking the improvement into components and then addressing each separately but within a larger framework of the entire solution. This can allow business managers to reduce their commitment and to change out who will be involved in each part of the solution.

This division of the project is often referred to as "agile BPM". However, this approach will take on a variety of "flavors" depending on the way IT approaches agile development and how they interpret "agile BPM". This will be a topic of a future column, but today I suggest that as any BPM project starts, the project team seriously looks at what this approach can mean to them and how it can help to engage business managers and obtain a commitment from ALL participants.

As always, I welcome comments and would like to hear from you. What's happening in your company? Have you seen the same trend in terms of user willingness to be involved in BPM projects?