In addition to the staffing model and role resourcing responsibility, another prime area of responsibility for the delivery element of a BPM CoE is to actively monitor, manage, and drive delivery quality throughout the organization. This area means going beyond simply putting trained people on projects and relying on existing traditional IT methods for ensuring quality solutions. The BPM CoE must go further and establish its own BPM quality governance measures, which should be embodied in a tailored methodology that includes the concepts described in this section.

The BPM project lifecycle model should be an end-to-end view of implementing a typical BPM solution, from funding to discovery, and to deployment and then to support.

A methodology often sets the high-level milestones and vision for the lifecycle of a project. However, additional guidelines are often necessary to inform the daily work.

A best practice is a set of fit-for-purpose recommendations that can apply in a range of situations, without having a specific home in the methodology timeline. Examples are as follows:

• Have the business sponsor for the process lead each playback.
• Plan each release in 90-day increments.
• Use a “camel case” naming convention1 for variables inside the implementation tool.

It is often necessary to go beyond theoretical design patterns and actually build executable reusable assets that can be used for commonly occurring work across multiple processes. For instance, you might want to develop a Toolkit for Accounting System Integrations, or SAP integrations or Customer Lookup. Most toolkits tend to be thematically focused on various ways of talking to a single external system at a time, or encapsulating a commonly occurring design pattern or widget. Similar to design patterns, although some toolkits are specific to a domain and certainly an organization, several can be independent of those factors and used as utilities.

The BPM CoE responsibilities start with the curation and organization of all the assets described previously, but they should not end there. In fact, the entire purpose of having a methodology (with lifecycle, best practices, guidelines, and toolkits) is to proactively assert its appropriate usage within each individual project executed by the BPM CoE. This assertion should be done by applying regular and consistent project reviews, or health checks, which aim to measure the likelihood of success for each project at distinct stages in the lifecycle.

After the BPM CoE successfully executes and deploys a BPM Solution, it should also provide continued support that is specific for business process owners and participants. Although technical support and administration activities can be done by traditional IT groups and the shared infrastructure group, business functionality and solution support should be bolstered by a BPM-specific support team. This BPM solution support team should apply product expertise to support the solution at a Level 3 tier, such as in the following examples:

• How to interpret product specific behavior, read logs, use BPM specific tools to troubleshoot problems
• Be aware of the business purpose of various solutions, and so on

A beneficial approach is to rotate members of the project implementation team through 3 - 6 months of support engagement to help the team members develop well-rounded perspectives in implementing better solutions.

The success of the BPM solution support organization should be measured by percent of user adoption, amount of business rework as a result of errors, and interruptions of business continuity. Traditional measurements of support organizations, such as number of bugs resolved or time spent to close issues, does not measure business value in any meaningful way and can get lost in operational efficiency, divorced from true business value.