Having learned about the four key roles in BPM, you might already have identified candidates in your organization to transition to these roles. Next, let us illustrate how these roles come together to create a cross-functional, self-directed, and high-performing team to deliver a business process. Let us also show you how the team makeup might change based on the size and complexity of your process projects. As we illustrate these team compositions for different process projects, keep in mind that your teams are composed of individuals with different levels and types of experience.

As you form your teams, try matching junior and senior people to create a rich learning environment. Consider matching different levels of experience across functions. For example, a Level 3 BPM program manager can mentor Level 1 BPM developers on one project, while a Level 3 BPM solution architect can mentor a Level 1 BPM program manager on a different project. The key is keeping a focus on continuous learning as you compose your teams; each individual project is an investment in your overall BPM program. Although assigning senior level individuals to a single high-priority project might seem a good idea, this action could be a detriment to the overall BPM program and ultimately have a negative impact on BPM adoption.

As with growing new skills of any type, mentors are important. A team of brand new talents without a mentor not only takes longer to learn and longer to deliver results, but these individuals certainly suffer after developing bad habits. Pairing new team members with experienced contributors is important. In making these pairings across your BPM program, you need a way to measure experience and individual success from achievements.

There is a tendency in many organizations to charter, plan, and manage larger projects. Keep in mind these words: think big, start small, scale fast. There is significant research supporting agile methods that keep project teams small (three to six individual contributors paired with stakeholders, a process owner, and SMEs as needed). Teams larger than six individuals should be broken into smaller project teams, or tracks, each concentrating on a part of the solution that can be logically separated from the other. There are dependencies, and a BPM project/program manager and BPM solution architect help to manage dependencies on a larger and more complex project with multiple tracks. They key is to remember that smaller teams with six or fewer individual contributors outperform larger teams.

The same thinking that applies to small cross-functional teams also applies to scoping process projects. Keeping the scope small enough for 90 - 120 day release cycles for a single team of five individual contributors yields more business value than a single team of ten or more individual contributors working on a multimonth (or multiyear) release cycle. Break up larger projects into smaller, iterative projects. Remember, think big, start small, scale fast.

In general, a low complexity process team includes one of each role and is purely focused on delivering a process project in less than three months. A single Level 2 BPM developer can lead and mentor a small team with a total of five individual contributors. The nature of the project might involve few, if any, system integrations, low complexity in scope with a single business process definition, and no subprocesses with 15 or fewer process steps. The user interface requirements might be low in complexity, leaving much of the implementation details as fairly straight forward. A low complexity project such as this one is an excellent candidate for a single leader/mentor and a small team of Level 1 or recently trained individuals.

For a low complexity process project, the BPM analyst might be engaged full-time during the Discovery phase for 2 - 4 weeks leading up to Playback 0 or Playback 1, and then part-time on a limited as-needed basis for further analysis. The same is true for the BPM solution administrator. The administrator might need to be involved only on a part-time basis for 2 - 3 weeks during the latter half of the project to assist with one or two system integrations and the deployment planning for the process application. The BPM project/program manager and BPM developers should be full-time. For a low complexity project, a senior BPM project/program manager and BPM solution architect could also participate in a limited part-time capacity to mentor the team.

Again, the aim is to organize a team that can deliver the necessary scope in 90 -120 day release cycles. There might be two or more 90-day release cycles for this project before a real production go-live event, but we can manage scope in incremental releases with this small and high-performing team. This example adds only one headcount to the number of individual contributors on the team, and increases the team capability by scaling up the experience of most roles to Level 2. We want to keep the team small and cross-functional to maintain high-performing and self-directed team structures. In this medium complexity process project, we might be dealing with a single top-level business process and 2 - 3 subprocesses for a total of 15 - 30 individual process steps. The user interface requirements might include several medium and high complexity user interfaces (Coaches) for several of the steps.

In this example, we added another Level 1 BPM developer to work under the leadership of a Level 2 developer. For a process that has more scope in system integrations than in user interfaces and process complexity, we could add a BPM solution administrator instead. Nonetheless, aim to keep the team no bigger than six individual contributors.

In this medium complexity process project, we can expect the BPM analyst to spend 4 - 6 weeks on a full-time basis leading up to Playback 1. If broken into two or more 90-day release cycles, the BPM analyst might re-engage for the first Playback cycle of each new release and participate part-time as needed thereafter. Here too, the BPM solution administrator might participate less than full-time to assist with complex integrations and deployment at the appropriate stages of each release cycle. The BPM developers and BPM project/program manager are assumed full-time throughout. Similar to low complexity projects, a Level 3 BPM solution architect, BPM analyst, or BPM project/program manager might participate on a limited part-time basis to provide guidance and mentoring throughout the project's release cycles.

Some processes just cannot be broken into multiple projects. They might contain many steps (60 or more) arranged in more than one top-level business process and 10 or more subprocesses. There might be large number of different user interfaces required or several high complexity user interfaces as a minimum requirement for Release 1. Some processes involve many system integrations that are required for Release One. Some processes involve many different participant groups (10 or more) requiring discovery workshops with several different groups of subject matter experts. For these types of high complexity projects, we again scale up the output of the team by adding more experienced Level 2 and Level 3 resources.

We might also need to scale up the total headcount beyond the recommended team size of six individual contributors. The team illustrated in Figure 2.2.4/3 has 11 individual contributors. With two BPM project/program managers, split this larger team into two tracks to maintain two small teams of five or six individuals. Distribute the senior team members equally among the junior members to maximize mentoring and learning. Our experience shows that two smaller teams far outperforms a single larger team with the same number of individual contributors. The BPM project/program manager must coordinate dependencies between the tracks, but multiple smaller teams (tracks) work faster and spend less time in meetings than single larger teams.

The journey to BPM transformation within your enterprise begins with skills development. Skills development leads to BPM adoption. BPM adoption leads to stakeholder acceptance, a new collaborative relationship between the operational business and the technology team, and additional funding for the BPM project/program and more BPM projects. Our experience is that organizations that are most successful in achieving BPM adoption make a conscious investment early and often in skills development activities, including training and continuous education, and formal and informal mentoring that accompany project-based experience.