Another approach is to reduce the scope of the BPM initiative. If a BPM project is limited to a simple software installation, the risk seems to be reduced for project planners. Unfortunately, limiting the project’s scope may be the surest way to drive a BPM initiative into the ground.

There is no silver bullet that guarantees success in BPM. But I recently had a conversation with Mike Davidson and Richard Holt, two directors at Alvarez & Marsal, in which they explained some not-so-silver bullets that frequently leave holes in performance management plans. Their firm has its roots in crisis management, and in their experience BPM failures tend to result from one (or more) of three types of problems.

The first of these problems will come as no surprise to anyone who reads BPM Magazine regularly: For a project to be successful, it needs a clear vision and strategy. The logic of this point is indisputable. A project that starts without direction could end up anywhere. But too many companies sidestep this crucial piece of the planning process, in the push to get resources for the project. An effective project begins with a clear vision, agreed upon by executives and project participants alike.

The second problem Alvarez & Marsal frequently encounters is inadequacy in project management or change management. Both are critically important. Quality project management involves stakeholders throughout the company in various stages of the project. Poor project management fails to involve all the right people at all the right times, and so is likely to result in the project coming in late or over budget, or to fail to deliver results that some stakeholders require. Change management is also critical, because the success of a performance management initiative depends on the buy-in of end users. Those who will be providing data for BPM processes, or those who will be using data from BPM systems to inform important decisions, must understand the purpose of the project and must be willing to change their behavior. Otherwise, the initiative is unlikely to produce desired results.

The third and final problem that Davidson and Holt have identified is pervasive misunderstandings about crucial details of the project. For example, expectations about the amount of time the project will consume often vary among participants. Data-quality problems are prevalent as well. And when businesspeople and the IT department disagree about the desired outcomes of the project, no one is happy with the results.

Obviously, these three types of problems are interrelated. A project that is well-managed will begin with the definition of its goals and will involve adequate communication to keep everyone on the same page. It’s interesting that so many projects continue to be poorly managed.

Building effective project and change management activities into initial projections of a project’s length and resource consumption may make the project less attractive to the executives who need to approve it, even sponsor it. But shortchanging these crucial elements in the beginning undercuts the project’s potential to be effective. In the experience of Davidson and Holt, at least, this is the surest way to lead a project to failure.