How to Pick That First BPM Project

Ann All

Many organizations have so many business processes that are ripe for improvement, it may be tough to select the first one for a business process management (BPM) project.


I've written about this several times, sharing BPM implementation tips from Gartner, and from other experts, including Nathaniel Palmer, principal and chief BPM strategist at SRA International, editor-in-chief at and executive director at the Workflow Management Coalition. Palmer was working for advisory company Transformation+Innovation when I interviewed him back in 2007 and he told me organizations should select a small, yet highly visible project for their entry into BPM.


He suggested the new hire process, noting that it lends itself well to BPM because:

  • It affects the entire business
  • It's a well understood, yet not rigidly defined, process
  • It's fairly straightforward
  • An ROI can be developed for it rather easily


And finally, he told me, it will get senior management's attention. He said:

It's generally one where you could go to the CEO and say, 'We want to make this experience better, cheaper and faster. It's going to be key to our success as an organization. We also want to use it as a proof point for how we are going to transform the organization by taking a more process-oriented approach. Can we get your support in doing this?' It becomes an enterprise-wide initiative without trying to boil the ocean all at once.

Much of this good advice is reiterated in a post by Sandy Kemsley, an independent analyst and systems architect specializing in BPM, Enterprise 2.0, enterprise architecture and business intelligence, and Steve Russell, SVP of Research and Development and CTO for BPM software provider Global 360. Even more so than Gartner or Palmer, these two experts focus on getting buy-in from business users for BPM, an aspect that is too often neglected in technology implementations.


The key theme of their post is selecting a core process that is highly relevant to the business. They write:

Unless your only goal for BPM implementation within your company is for non-line-of-business administrative processes, don't pick one of those as your first process. It's not that these processes can't be improved-they probably can-but you can't expect everyone in the company to become excited about the potential of BPM by showing them how you can make their expense reports process better. Selecting a low-value process as your initial process for implementation means that few people will care if you are successful: Although the implementation is low risk, you've put your entire future BPM program at risk because you haven't used the first project as an opportunity to prove potential value. Furthermore, if you do get the go-ahead for that second project, you might find that there's not a lot of reusability of either methods or processes as you move from an administrative process to a line-of-business process.

This differs a bit from Palmer's suggestion of using the new hire process as an initial BPM project. But human resources does touch everyone in an organization. And as Palmer pointed out in our interview, "All sorts of studies show that the experiences individuals have within the first one to two weeks of coming on board with a company will affect their long term attitude toward the organization and their overall outlook for success."


More tips from Kemsley and Russell:

  • Keep it simple, with minimum functionality and as little customization as possible. If you are replacing a manual process, any amount of improved user experience and automation can show benefit. Keeping it simple allows you to move a process into production in a short timeframe, a piece of advice offered by both Gartner and Palmer. It should also cut down on complicated integration work.
  • Provide maximum flexibility to users in how they execute their work. If software includes ad hoc/dynamic process management functionality, make it available to users so they can capture emergent processes or identify areas that may not be well suited to structured processes.
  • Begin with a core group of users, possibly in a single department, then expand outward in order to reduce handoffs between the BPM system and manual processes. Your ultimate goal should be managing the end-to-end process. Aim for breadth (more of the process) before depth (more functionality at any given step) as functionality will likely shift as the process broadens.
  • Realize that initial requirements will probably need to be modified. Gather user feedback after they've had a chance to use the BPM system in their daily work and employ their suggestions to determine which functions should be included in later iterations.
  • As users get up to speed and reach an acceptable level of productivity, begin to implement the more technical integration functionality. Be sure to consider reusability of these functions with other processes in the future.


Kemsley and Russell promise to offer advice in a future post on how to capitalize on initial project success and expand a BPM initiative throughout the enterprise.

Add Comment      Leave a comment on this blog post

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.