After these areas are specifically identified and given concrete articulation, it becomes important to give shape to the actual organization that will advance the areas of responsibility. This organization can be envisioned in the following typical areas:

• Roles
• Skills
• Organizational Structure

One of the primary areas of responsibility for the delivery element of a BPM CoE is to provide the staffing, expertise, and experience required to execute on the pipeline of projects built by the strategy element of the BPM CoE. This area requires a staffing model and a resource pool, aligned with roles in the BPM methodology.

The staffing model is the engagement mechanism by which individual projects can make requests for resources to implement their process. The purpose of the staffing model should go beyond simply supplying tactical skills needed to add discrete functionality to individual solutions, to assuming responsibility for the overall success of the BPM solution.

Any staffing model for BPM projects should take into account a need for scalability to keep pace with BPM adoption across the enterprise. This scalability can be enabled by understanding the specialization of various roles involved in successfully implementing a BPM project, and the recommended level of involvement by these roles in each project.

These resources are likely to start being used for multiple projects as resource demands grow for the BPM CoE. A high degree of usability across projects is the primary value of a centralized BPM delivery organization.

A methodology coach who provides oversight in the area of driving iterations, playbacks, estimation, planning engagement methodology, and agile development in general. Initially, this role can also provide traditional Project Management skills (such as contract management, time tracking, expenses, and other administrative tasks). However, the real value of this role is in driving and owning the methodology and lifecycle of each project.

Longer term, each organization has to make a decision about whether to combine the administrative and methodology responsibility in one role or to separate them out. From a methodology coach perspective, this role is recommended at a minimum of 50% involvement for each individual BPM project.

A BPM Analyst focuses on discovering and modeling value-driven process requirements within the context of an individual project and with the intent of collaborating with the solution implementation team. This role is heavily involved in initial process definition and leading process owners and subject matter experts (SMEs) to consensus. The BPM Analyst coaches the business participants to deliver Playback Zero and looks for ways to accelerate business value through process optimization.

A BPM implementation expert who is trained and experienced in using the BPM platform to develop solutions. The key value of this role is to drive toward a release by using the BPM methodology and focus on ready-to-use product rather than custom development done outside the tool (or unsupported development done inside the tool). This role inherits the requirements for the solution from the BPM Analyst at the end of Playback Zero, and is then responsible for shepherding the team through the remainder of the playbacks.

A senior member of this role is typically in a team lead or solution architect role for one or more projects, and a junior or mid-level member typically acts in a capacity of individual contributor on single projects.

The BPM Developer role should have a 100% involvement for each individual BPM project, although multiple people will likely be in this role for each project.

The BPM Integration Developer is a more technically focused version of the BPM Developer role. The BPM Developer focuses on ready usage; the Integration Developer focuses on building additional functionality outside the core product that is needed to complete the end-to-end solution. In some cases, this focus might mean developing a custom integration connector that is not supplied as ready-for-use, troubleshooting any issues with using ready for use connectors, developing custom interfaces (beyond the ready-for-use business user interfaces in IBM BPM) when there is a valid business, and so forth. The key value of this role is handling the IT-driven technical requirements for the project, allowing the BPM Developer to focus on addressing the business scenario with ready-for-use functionality.

The involvement of this role is highly dependent on the amount of custom development required for a project. For a project with no customizations or no new external integrations, the involvement can be as low as 30% (to ensure correct usage of existing integrations). On the other hand, for a project with custom user interfaces and new integrations to a number of external systems, it can be as high as 100% with multiple Integration Developers. As an aside, the latter projects are to be strongly scrutinized as appropriate fits for BPM.

These roles can exist across a spectrum of experience, expertise, and involvement, implying varying levels of ownership and responsibility on the project. This information is called out specifically to reduce unnecessary middle-management in projects, thus a Team Lead, Solution Architect, or Lead Analyst must still align with and perform (with some portion of their time) one of the roles described previously.

Other roles that are resourced from outside the BPM CoE delivery capability  As a matter of pragmatism, a successful BPM project needs more roles than the roles described previously. However, these roles do not need to be resourced by the delivery capability of BPM CoE and may be provided by other traditional parts of your IT organization