The Pilot Is Just the Beginning, Part 1

While a complete enterprise BPM roll-out is a multi-year effort, this two-part series focuses on the Pilot as the crucial first step in an enterprise initiative designed to spread throughout the organization.

On first toeing the BPM waters, there is what we call the “Startup” phase. The goal for this phase is to demonstrate that your organization can adopt and benefit from BPM on a broad scale. Your Pilot project, hopefully, is a great success – and frankly, it usually is. Why? Because you have spent months laying the groundwork, aligning the team, building the business case and acquiring the technology. Your company – at least the part working on the Pilot — is aligned, dedicated, and singularly focused on a shared and common goal.

But now, with a single successful process under your belt – what comes next?

This is where the challenges begin from an overall enterprise perspective. Word of the Pilot spreads. And unless there is a clear plan for scaling to this new demand (and there usually isn’t), this is where it becomes difficult to replicate your initial successes. And as a result, the overall enterprise BPM initiative can stall before it gets off the ground.

To avoid this scenario, the Pilot program itself needs to be designed such that your initial success can be studied, perfected and replicated. The objective is to validate that the organization has the true capability to deploy BPM projects in the first place. Think of this as “proof” that the organization can succeed with BPM.

In order for that proof to be compelling, the Pilot should follow several key guidelines:

• We, in fact, recommend that you have two separate Pilots. This is the best way to demonstrate repeatability and maximize learning.

• Each Pilot needs to go from creation to deployment to end users of version 1.0 of their process. Typically, this will take 10-12 weeks.

• An iterative approach should be used for developing processes. This means full process “playbacks” or reviews every two weeks by process owners and team members.

• Each Pilot team should also deliver a version 1.1 of their process to production. This provides proof and learning to both the deployment teams and, just as important, to the business users using the process application. This gives the organization experience with the challenges of on-going process improvement – like responding to change requests and migrating in-flight processes to the newest version of the process. Typically, this will take five to six weeks. This also provides a key proof-point to the business: that process changes can be implemented quickly.

• Each team should include at least three full-time people from both the business and technical parts of your organization (see below).

• Enterprise architecture and/or Service Oriented Architecture (SOA) teams should be involved in the Pilots. Furthermore, the part of the organization that is responsible for application and/or infrastructure operations should be involved from the beginning, and called in on an as-needed basis. This will help them understand how BPM technology fits in their architecture.

Ed.: In Part Two of this post, we talk about picking processes for the Pilot, staffing up, and executing in a way that will ensure success beyond this initial phase.

Additional resources:

How to justify your BPM project

Getting started with BPM