For better BPM outcomes, consider a project management approach

Editor's Note: In this Q & A, ebizQ's Peter Schooff and business-process thought leader Paul Harmon discuss how project management can improve BPM implementations. Harmon is founder and executive editor of Business Process Trends, a BPM news and information organization. This interview, excerpted from a longer podcast, has been edited for length, clarity and editorial style.

Schooff: How do project management and business process management relate to each other?

We'll start with BPM. Lots of people use [the term] “BPM” in different ways. For example, software vendors often use “BPM” when they want to refer to software products that support business process development. That's not the way I use it.

[BPM suites] are valuable, but I use “BPM” to refer to a broad approach to managing processes within an organization. Lots of organizations have multiple process efforts underway. They have a Six Sigma group. They have a process group in IT. They may have a Lean group. They certainly have programs like the balanced scorecard [and other efforts] that affect the processes. I think the popularity of BPM at the moment is due in part to companies having decided they want some overarching way of thinking about all the processes, or at least coordinating them and prioritizing them.

So BPM has emerged as a sort of a broad collection of practices and techniques for integrating and prioritizing or coordinating various activities in an organization. [He refers to Figure 3, a visual depiction of methodology that stacks enterprise activities at the top, process activities in the middle, and implementation level activities at the bottom.]

At the top, you're concerned about things like strategy, developing a business architecture for the organization, figuring out how all the processes work together. At the process level, you're interested in improving existing processes or managing existing processes. And at the bottom level, you're interested in implementation resources to support process work, including everything from IT to HR, developing training for new employees, developing new software applications and so forth.

On the horizontal axis, what you see is that on the left side you've got projects and on the right side, you have day-to-day operations. So the right side is operational management and the left side is project management.

So right off, if you want to redesign a process, it's a project. It has a goal. It has a budget. It has a plan. You go through a whole series of steps. If you want to create a new business process architecture, it's a project. You start off with a goal; you have steps; you have a budget. It takes time, and the end result is an architecture that the company can use.

On the other hand, on the right side, you’ve got operational activities. Once you have an architecture, senior management uses it. There are techniques they can use to determine the priorities of different projects. There are things they do on a monthly basis to monitor which projects are doing best.

At the process level, you have activities that generate a new process. But on a day-to-day basis, you have to execute that process. The manager that runs the process has to give feedback to employees. They have to determine whether people need training. They have to get a budget approved every so often.

So BPM is broader than just projects. We certainly have projects. We have projects where we develop process improvement. We have projects where we improve processes. We have projects where we create new architectures. We have projects where we improve and generate new software to support processes.

At the same time, we have things like incremental improvement, which is not so much a project as an operational activity. We have things like monitoring processes on a day-by-day or monthly basis, which a BPM group might do; that's more operational management.

So there's a mix. You certainly use processes a lot when you do projects. You certainly use projects when you do process work. But there certainly are things within the broader BPM contexts, which are operational rather than project-oriented.

ebizQ: Now to drill down even further, how would you use project management to, for instance, do a BPM redesign project?

If you think about the process itself, you have something that you're doing and you're going to basically analyze it and then redesign it. There's a goal for that: You want to improve the process. It's a project. You end up bringing together a team, you end up assigning responsibility, you end up setting up a budget, you develop a plan and a schedule.

If you look at Figure 2, when we talk to people specifically about process redesign, we basically tell them the things that you're going to have to organize and coordinate if you're going to have a successful project: --Certainly, one of them is that you’ve got to know about how to do process modeling.

--You have to know how to do analysis and design. There’s a whole collection of skills and techniques that are involved in that.

--You have to know about doing research and interviewing. There’s a lot of information that the team is going to have to go get from other people in the organization.

--You need to do communication and change management. That's usually a higher level set of skills that involves keeping people abreast of what you're doing, trying to avoid surprises, trying to get employees to understand why you’re are doing what you're doing.

And on top of all of that, there's project management. In other words, somebody who’s involved in redesigning the process has to understand that it's a project and they have to be able to do the things that are required of somebody in a project.

ebizQ: Would you say project management should be used in all cases and stages of BPM?

Certainly in all the project portions of BPM. In other words, if I'm doing a redesign effort, it's a project. I need to use project management techniques. If I'm doing an architecture effort, at least initially developing the architecture is a project, and I need use all the techniques that are appropriate to make that happen. Same thing with developing software.

The team that’s going to put together a new software application to support or automate a process is going to go through a project [approach] and they need use project techniques. [He refers to Figure 1, adapted from the Project Management Institute (PMI)Project Management Body of Knowledge.]

What it basically shows is three different areas of concern with management. One of them is generally accepted project management knowledge and practice, which is documented in PMI's work. The second one is general management knowledge, the sort of thing you might find in a book by [the late management thought leader] Peter Drucker. The third area is specific applications of knowledge and practices.

So from our perspective, a process redesign project is a particular type of project that is focused on redesigning a process. It has its own specific knowledge and practices. For example, the kind of team that you assemble to do a process redesign is different than the kind of team you might assemble to, for instance, come up with a new logo or a new branding marketing plan.

ebizQ: What are some of the limitations or risks involved in this project management approach to BPM?

You can't do process redesign without having goals. You can't do process redesign without creating a team. You can't do process redesign without some sort of a budget.

All those things are basically the kinds of things that people know about if they know about project management. So it's not a matter of a risk if you use project management, it's almost the other way around: If you don't use project management, you're not likely to do a good process redesign.

When you do process redesign, you have to analyze the business process. It’s common, if you get the wrong sort of people on the team, that they get into “analysis paralysis,” which refers to the fact that they keep drawing models and getting more and more detailed ideas of how the process works, and they don't move on to the redesign phase.

There are people who try different kinds of redesign. Some people will look at a particular set of problems and decide it should be automated, when, in fact, it really isn't a good candidate for automation.

So the risks that we would certainly talk about would be the risks that are associated with working with changing process.

About the Author

Peter Schooff is a former contributing editor for ebizQ, where he also managed the ebizQ Forum for several years. Previously, Peter managed the database operations for a major cigar company, served as writer/editor of an early Internet entertainment site and developed a computer accounting system for several retail stores. Peter can be reached at

More by Peter Schooff

About ebizQ

ebizQ is the insider’s guide to next-generation business process management. We offer a growing collection of independent editorial articles on BPM trends, issues, challenges and solutions, all targeted to business and IT BPM professionals.

We cover BPM standards, governance, technology and continuous process improvement, as well as process discovery, modeling, simulation and optimization, among many other areas. We follow case management, decision management, business rules management, operational intelligence, complex event processing and other related topics. We closely track important trends such as the rise of social BPM, mobile BPM and BPM in the cloud. We also explore BPM’s use in functional areas, such as supply chain and customer management, and in key verticals, such as financial services, health care, insurance and government.

ebizQ's other BPM-oriented content includes podcasts, webcasts, webinars, white papers, a variety of expert blogs, a lively online forum and much more.