For many people, the hardest part of the transition is letting go of old habits and redefining the way we measure individual contribution and success. For each role, the transition requires a new perspective on business value. Each of us should clearly understand our individual, and collective, contribution toward achieving business value. When the outcome of our collective effort results in a process application that delivers measurable business value, we achieve success. Until then, the number of user stories written, or number of pages of documentation signed off, or test cases run, or defects found (and fixed), do not matter.

Project and Program Management is a broad field. There are multiple organizations and certifications along with methodologies that each company tweaks or implements differently. Although some core tenets are commonly shared, the execution, inputs, tools, techniques, outputs, and gates vary. When adopting BPM, we find some techniques and methods that work better than others.

A leading practice for BPM is co-locating the team throughout the duration of a project. Being co-located makes it easy for the project to adjust based on meaningful feedback and changing priorities while also engaging in conversation to ensure what is being developed meets the goals. This one activity of increased collaboration is radically different from how most projects are run today. Although having a shared space or other method of keeping the team together is key, it is also important to ensure that the shared space does not become a meeting room. The development team needs a place where they can concentrate to create the designed functionality.

The promise of BPM is business agility. Scaling BPM adoption means extending the capability to process owners to make regular and decisive changes, thus adapting your business to BPM with the support of objective measurements and current performance data. In order for our agile business to respond to change decisively and timely, we must be capable of rapidly measuring, deciding, and changing the processes that support our business. It is therefore necessary to adopt an agile software development and delivery methodology that can govern regular and frequent changes to our process solutions.

Most software engineers, project managers, and development leads have been exposed to agile methodologies. Many of these people have some experience in a company that is beginning to adopt or has adopted agile techniques. Having skills in agile approaches, like SCRUM, XP, and OpenUP, is helpful when moving to manage BPM projects.

Beyond looking at phases, dates, scope, assignments, risks, and such elements, managing BPM projects is about having a constant focus on business value. The most successful BPM project/program managers have the capability, experience, and comfort to work in a BPM analyst capacity. These BPM project/program managers do not replace BPM analysts, but complement the analyst role and bring forward-thinking when assembling work into themes that can be evaluated and compared when creating a process roadmap or a process inventory. These elements are assembled and maintained by the BPM project/program manager with input (as part of governance) from stakeholders, process owners, and others for establishing a backlog that can be executed based on company strategy or tactical market decisions. As you can imagine, critical thinking with a focus on business value is key when guiding governance decisions.

To guide governance decisions and help with project planning and tracking, BPM project/program managers must have knowledge about how processes are architected. They do not need to be expert BPM developers, but should be familiar enough with BPM to review and play back the process independently. This familiarity helps project/program managers answer questions associated with effort remaining and solution completeness. This familiarity is especially important when estimating project elements or sizing for a program. Being familiar with relative sizing estimation, like story points, is a key technique that helps project/program managers easily mature project schedules from estimations to predictive tools. When delivering multiple projects, skills in forecasting and relative sizing of projects to each other becomes more important. A project/program manager's hands-on approach improves accuracy and confidence in planning, achieving business value, and determining the priority needed for BPM governance.

A single project/program manager can typically manage two small to medium sized projects effectively. As the complexity and size of the team increases, a manager at 50% time is not enough. A first-time project in BPM, even a small one, should also have a dedicated project/program manager at 100%. It is important when beginning the BPM journey that the BPM project/program manager role is not regarded a Project Administrator that can span many projects. If the manager is staffed in such a fashion, then it is unlikely the manager is able to garner enough details to effectively manage the project, understand the value being delivered, or guide the necessary decisions to facilitate change.

Many organizations have a small army of business analysts, and most have at least a few individuals who carry this title. Business analysts are familiar with the business and know how to identify business needs and translate those needs into objective and specific requirement specifications. For some business analysts, their ultimate achievement is a thorough and detailed analysis resulting in an extensive software requirement specification (SRS) document.

Sometimes the business analyst is a go-between or interpreter that bridges the IT/Business divide. In these environments, the business often does not collaborate directly with engineers and developers. Some business analysts emerge from a SME background with experience in the operational business. Others are systems analysts that emerge from an IT background. Some business analysts achieve Six Sigma Black Belt Certification and are familiar with multiple techniques to analyze processes, document methods and procedures, and dive into root cause analysis. If your organization develops or maintains systems, you have analysts congregating in conference rooms or working at their desks generating volumes of documentation that people try to review and sign off.

BPM analysts are experts at creating a collaborative environment where process owners and SMEs discover, document, and analyze their business processes. A BPM analyst focuses more on facilitating and less on documentation. The BPM analyst facilitates these sessions with the process owner, SMEs, and key process participants. Continued learning in process modeling and process discovery comes with experience and mentoring. A BPM analyst learns best practices, such as how to document process elements, create self-contained and reusable subprocesses, streamline common processes, reduce exception paths, optimize processes, write user stories, and perform supplier, inputs, problems, outputs, and customer (SIPOC) analysis.

BPM analysts often have a background in Six Sigma and use their process and data analysis experience to identify process problems before moving into future state design innovation. They know how to prioritize and associate improvement opportunities and help guide the team in determining the future state of the process. Learning to do this type of activity dovetails with clearly defining the success criteria for a business process implementation. Learning to do such work, possibly by taking Six Sigma courses, is critical to detecting inefficiencies and improving process quality.

BPM analysts are advocates for agile methodology. Those analysts with a solid track record defining business processes for agile delivery are the most successful. They understand how to define the future state process at various levels, knowing where to deep dive in analysis and share the vision of phased releases based on business priorities and critical success metrics. The skill and experience to identify business value and deliver that value in a series of short iterative releases helps establish a process roadmap and build an inventory of business processes.

The BPM analyst translates business needs and requests into process documentation that provides key performance indicators (KPIs), service level agreements (SLAs), and the resultant metrics. The BPM analyst ensures that the appropriate metrics are included in each release and that the business process is meeting business needs, like regulatory or improvement goals. Defining key process metrics and their associated reporting goals is essential in the business justification for continued process implementation projects. Building a return on investment (ROI) case is an important skill necessary when presenting a proof of concept and business case to stakeholders for future projects. Creating credible process optimization scenarios with both historic data and simulated data means that BPM analysts must learn how to use the Process Designer authoring environment and the Process Optimizer tools.

For the traditional business analysts, their work typically finishes when implementation begins. For the BPM analyst, there is no transition of requirements or specifications to the developer. The BPM analyst is needed for the duration of the implementation of a business process. For most small to medium-sized processes, a BPM analyst is most often used to start the project with process discovery sessions and lead the team through the first two iterations of implementation (Playback 0 and Playback 1). If the Process Owner or SMEs are able to dedicate enough time to manage and elaborate on changes to the process, then the BPM analyst might become involved part-time. For medium to large-sized processes, a BPM analyst is needed throughout the project to prioritize user stories, continue analyzing process details, help the team collaborate on user story details, and participate in planning, committing, and accepting development iterations. As your organization matures to a BPM program conducting several large projects concurrently, you have multiple BPM analysts distributing their time across several projects at various stages in the project lifecycle.

If your organization is like most, you already have many individuals with architect in their job title: software architect, enterprise architect, database architect, solution architect, and so on. A BPM solution architect might move from one of these other roles. It is important, however, to recognize that a BPM solution architect is not just another senior architect or a senior Java, .NET, or other application developer.

Like other BPM-specific roles, the BPM solution architect also maintains a particular allegiance to business value. Although familiar with technical subjects, from SQL to Ajax, from SOA to JMS, and from design patterns to agile methodology, the BPM solution architect is more often found collaborating with the process owner and SMEs. He collaborates with these people to better understand the business process, its key performance indicators (KPIs), its service level agreements (SLAs), and how that process might be best implemented.

The BPM solution architect typically moves from a senior role in engineering or development with five or more years of experience in programming and application design. Some BPM solution architects move from a business analyst role with deep technical experience. The BPM solution architect might have a background in any number of programming languages, including Java, .NET, C++, PERL, COBOL, or mainframe computing. These individuals might spend two to five years in the role of BPM developer or BPM analyst as they mature in achieving certification levels 1, 2, and then level 3.

A level 3 BPM developer or analyst can fill the role of BPM solution architect. The keys to a successful transition to the role of BPM solution architect include the following items:

1. Learn to assess, prioritize, and measure business value in all aspects of solution delivery
2. Become both practitioner and evangelist for agile methodology
3. Establish trust among business stakeholders, process owners, and process participants while maintaining influence within IT
4. Achieve both breadth and depth in knowledge of every component and the many capabilities of the BPMS (IBM Business Process Manager)
5. Practice and teach BPM best practices, common solution design patterns, and business process modeling guidelines

The BPM solution architects emerge from your project/program over time. Even those architects with five or more years of experience in software programming or architecture spend another five years in BPM before achieving a level of success and experience to take on the responsibilities of a BPM solution architect. For many, the most exciting part about becoming a BPM solution architect occurs when the team achieves significant business value through short iterative delivery cycles. These achievements are recognized by business stakeholders and celebrated among members of the IT team. The savvy BPM solution architects are the ones who quickly align themselves with business stakeholders to better understand business value and corporate objectives. They use their experience in IT to better serve the business.

Of all the roles named in a BPM project, the role of BPM solution administrator is most like a traditional IT systems administrator. Nonetheless, the BPM solution administrator, like the other roles, shares a healthy disregard for technology when it comes to being committed to achieving business value in short iterative delivery cycles. The BPM solution administrator accepts the responsibility of frequent deployments of new versions of process applications, monitors the web of dependencies among toolkits and process applications, manages the risk associated with regular and frequent deployments, and provides both transparency and governance. The administrator does these tasks so that process owners and stakeholders can collaborate in managing that risk.

The BPM solution administrator has deep knowledge of the Process Center and runtime environments. The administrator knows how each environment is configured, installed, deployed, secured, supported, backed up, and recovered. A senior (Level 3) BPM solution administrator might lead a team of systems experts to design and install IBM Business Process Manager and all of its components in your organization's IT environments.

A good BPM solution administrator is also familiar with the Process Designer and the same tools used by the BPM developer. The BPM solution administrator often takes on development tasks to build the more technically challenging integration components for connecting the BPM process to the many different systems in your IT environment. BPM solution administrators often have years of prior experience in Java or .NET development and are familiar with SOA and related integration technologies, including web services, Java messaging, and database connectivity.

Succeeding in the transition to a BPM solution administrator is no small undertaking. This task is not something that can be achieved after taking five days of training on the software. The responsibilities of this role almost exclusively attract individuals from other system administrative roles in IT. This role is not for an administrator who prefers the command prompt over a graphical user interface. This role is also not for a Linux administrator who prefers racks of servers over a boardroom of process participants drawing on the whiteboard and sequencing activities in Blueworks Live. The BPM solution administrator is as much a team player in the delivery team as the BPM analyst and BPM solution architect.