BPM Proj MNG PDF

BPM Project Management
(Course code WB004/VB004/ZB004)
Student Notebook
ERC 2.0
IBM WebSphere Education

Trademarks
IBM® and the IBM logo are registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United States, or other countries, or
both:
Blueworks LiveTM WebSphere®
JavaScript, and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
April 2012 edition

The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis without any warranty
either express or implied. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on
the customer’s ability to evaluate and integrate them into the customer’s operational environment. While each item may have been reviewed by IBM
for accuracy in a specific situation, there is no guarantee that the same or similar results will result elsewhere. Customers attempting to adapt these
techniques to their own environments do so at their own risk.
© Copyright International Business Machines Corporation 2012.

This document may not be reproduced in whole or in part without the prior written permission of IBM.
Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions set forth in GSA
ADP Schedule Contract with IBM Corp.
Contents
Introduction 1
Course overview ��1
Unit 1: BPM project overview 5

Introduction ��5
Objectives ��5
Topics ��5
Introduction to business process management (BPM) projects 6
BPM solution life cycle ��21
How is the BPM solution life cycle different? ��22
BPM project roles ��24
BPM journey ��32
Unit 2: The discover and document phase 37

Objectives ��37
Topics ��37
Discover and document phase overview ��38
Requirements ��50
User stories ��52
Unit 3: The plan and implement phase, part I 63

Objectives ��63
Topics ��63
Plan and implement phase overview ��64
Playbacks and project management ��66
Quality assurance and testing ��80
Introduction to planning and estimation ��86
Unit 4: The plan and implement phase, part II 93

Objectives ��93
Topics ��93
Planning overview ��94
Rough order of magnitude (ROM) ��96
Budgetary estimate �� 100
Detailed estimate �� 114
BPM Project Management iii

Unit 5: The deploy phase and the manage phase 123
Introduction �� 123
Objectives �� 123
Topics �� 123
Deploy phase overview �� 124
Project retrospectives �� 133
Manage phase overview �� 138
Business activity monitoring (BAM) �� 139
Process improvement �� 144
Unit 6: Project to program 147

Introduction �� 147
Objectives �� 147
Topics �� 147
The BPM journey �� 148
Managing a BPM program �� 152
Appendix 157
Term Definitions �� 157
Capabilities �� 158
BPM solution life cycle history �� 160
References �� 161
iv Table of Contents
BPM Project Management v
IBM WEBSPHERE EDUCATION
Introduction Course overview

This BPM Project Management course covers the basics of managing a business
process management (BPM) project built with IBM Business Process Manager
and Blueworks Live or other modeling tool. BPM project management concepts
are presented in a systematic way, each concept building upon each other to
facilitate a thorough understanding of the subject matter.
This course covers the following:
• Business process management (BPM) - A review of BPM, focusing on BPM

benefits such as control and visibility.
• BPM solution life-cycle overview - A high-level discussion of the four phases

of project management, how this differs from other solution development ap-
proaches, and the identification of key project development roles.
• The four phases of the BPM solution life cycle - An in-depth look at each
BPM solution life-cycle phase, key components, outcomes and best practices
for each.
• Project to program - A high-level look at how to start moving from project to

program.
BPM Project Management 1

COURSE OBJECTIVES • Describe the process life-cycle project management phases

• Use user stories during project management
• Use tools to estimate project size, time, and budget
• Use the playback methodology to manage projects
• Deploy a process, and manage the process to complete the process life cycle
• Describe the BPM journey
COURSE MATERIALS The materials created for this course are supplements for training, including lecture, and
class activities:
• Course guide
• Spreadsheets for estimation
2 Introduction
RESOURCES IBM Blueworks Live

• Process Mapping 101 self-paced online course
• Performance support tutorials: IBM Blueworks Live help system
IBM WebSphere Lombardi Edition or IBM Business Process Manager

• IBM information center: http://www-01.ibm.com/software/integration/lombardi-edition/
library/documentation/ and http://www-01.ibm.com/software/integration/business-
process-manager/library/documentation/
Project management and general BPM

• Starting and Succeeding with BPM self-paced online course
• Scaling BPM Adoption from Project to Program with IBM Business Process Manager
redbook: http://www.redbooks.ibm.com/abstracts/sg247973.html
Other
• Technical questions can be directed to support by visiting http://www-947.ibm.com/
support/entry/portal/

Unit 1: BPM Introduction

project What is a business process management (BPM) project? It is important to know the
components and nuances of BPM to understand a BPM project as the two items are
overview closely tied together.
In this unit, we will look at the unique solution life cycle of a BPM project. We will review
a few different types of BPM projects, how a typical BPM project will be managed from
beginning to end, how managing a BPM project may be different from managing other
types of projects, and the roles and responsibilities in a project. We will conclude with an
overview of the BPM adoption journey.
Objectives
After completing this unit, you should be able to:
• List and describe BPM project features
• Describe the BPM solution life cycle
• List roles and their corresponding responsibilities in a BPM project
• Compare and contrast a BPM project with other types of projects
Topics
This unit is comprised of the following topics:
• Introduction to business process management (BPM) projects
• BPM solution life cycle
• How is the BPM solution life cycle different?
• BPM project roles
• BPM journey

Introduction to business process management (BPM) projects

BPM review
BPM is defined as an integrated approach to aligning the key activities of an organization
into processes you can consistently measure to optimize value to your organization and its
end customers.
For additional BPM related terminology, see Appendix A
6 Unit 1: BPM project overview

Why BPM?
Organizations implement BPM for a variety of purposes, including:
• Developing an application to connect complex processes that are involving both
humans and automated systems
• Orchestrating multiple departments and systems
• Managing real-time performance and visibility
• Keeping pace with changing business requirements
• Implementing a standards-based service-oriented architecture
• Fostering effective collaboration between business and information technology (IT)
• Making process excellence a source of competitive advantage
BPM systems incorporate various types of functionality, including:

• Workflow: adding control and automation to manual tasks
• Application development: building complete, mission critical applications for
orchestrating key processes
• Performance management: delivering end-to-end visibility and control of a process
that crosses application silos
• Exception management: complementing legacy applications by handling exceptions
efficiently
NOTES

Benefits
Control and visibility
Business process management provides a clearly defined process, managed execution
and measurable results of the process. BPM also adds a layer of control and visibility for
processes across an organization.
Strengths:
• Leverages existing investment
• Single process for participants across all systems
• Management visibility into transactional and process performance data
• Single system to make application changes and maintain business rules
• Single view of customer or account
Weaknesses:
• Integration must occur for each system
• Process normalization may be difficult
• One-time re-education of participants to new process
Establishes single, consistent process

layer across systems

IBM Business Process Manager project features

Process solutions developed with IBM Business Process Manager differ from other
projects by virtue of certain features of IBM Business Process Manager.
The Process Designer of Business Process Manager allows a data-driven shared model of
the process which is both the medium for modeling the process and the instructions for
execution of the process at run time.
This eliminates the need to translate a static model of the process developed in a pure
modeling tool into executable program code. Thus process development projects using
IBM Business Process Manager entail a somewhat different approach and set of tasks
than other software development efforts. Through many years of experience, an iterative
development approach based on agile principles has proven to be consistently successful.
This approach is focused on rapidly delivering working software of quantifiable business
value while leveraging the unique capabilities of IBM Business Process Manager.

The shared model facilitates an iterative development and project management approach
by enabling the project team to “play back” the current state of the process solution at
any point. They do not have to undertake a lengthy compile,build,deploy,configure effort.
Changes can be made directly to the process model and can be demonstrated to users
immediately in most cases. This allows the developers to obtain timely and valuable
feedback from the process owner, end users, and other subject matter experts (SMEs)
throughout development.

Code-driven vs. data-driven development

At the center of traditional application development is the conventional approach to
managing code instead of the process. This approach can cause problems when managing
BPM projects.

Code-driven
Code-driven development suffers from several disadvantages which limit how fast it can
change:
• Separate tools are used to create the pieces, user interface, connectors and
business rules
• These tools generate code and this code is passed from one group to another and
is bound up in order depending on the workflow
At this point, the process development is hard-coded. Then it has to be compiled,

tested,and transferred to an application server. The application server is stopped and re-
started, and the process is then run.
This same code-driven development cycle has to be repeated for even a small change to
the process.

Data-driven
Opposite to code driven application development is data-driven process development. This
has only two steps:
• Model: a single integrated graphical design environment is used to model the
process. The model is stored as data, not code.
• Run: at run time, the data is read and executed.

Why Iterative development?

Traditional development can be risky
Sailing a ship from origin to destination by simply setting the course at the outset and
never correcting along the way is ineffective for arriving at the intended destination. This is
because conditions, such as wind, tide, and currents, are constantly changing. The same is
true for development programs for business, except that in business programs, even the
destination may shift before you reach it. “Set it and forget it” approaches that attempt to
fix all requirements at the outset are doomed to arrive at a destination other than effective
solution of the business problem, even if they successfully meet all of the requirements
as stated at the outset.

Iteration reduces risk

An iterative approach to BPM development reduces the risk of missing the desired
targeted outcome. Since it is impossible to fully and accurately predict the target of a
development program of any significant duration, time and effort invested in producing
elaborate, complex, detailed specifications rarely if ever achieves its intended goal. An
iterative approach breaks up the overall scope of the solution into smaller increments or
releases, where the shorter term target can be better and more completely understood.
Less time and fewer resources are expended before feedback from the business users is
obtained and used to refine and correct the solution. Work on the subsequent iterations
begins from a known-good starting point that has been validated by the business and
proceeds toward a goal that can be seen more accurately than it could have been before
any development work was done.
In BPM development, we call these iterations “playbacks”, as at the end of each one, you
will “playback” the process with both business and IT stakeholders to validate and correct
the solution before proceeding with further development.

At each iteration, or playback, requirements definition leads to a playback design. This

design then is modeled, or developed, with specific goals in mind to test. Because the
developer is able to click the run icon in Process Designer as often as needed, testing can
happen early in the project development cycle.
Built into the playbacks is a final playback. This review allows for design validation. After
process development and testing is accomplished on this planned iteration work, the
process is played for all stakeholders in a final playback for that iteration. This provides the
visibility of the process functionality for stakeholders and process owners.
Planned work that could not be accomplished by iteration close becomes part of the
requirements for the next iteration. The planned work is prioritized to facilitate the level of
effort needed to continue towards project completion.

Playbacks in a basic project

Planned work for the playbacks can be scoped so that each review is on-target and
driving towards project completion. As each playback is complete, the next level of
complexity for the process development can be tackled.
In many situations, project completion can happen in a matter of weeks instead of
months with a fully deployed end-user process solution in place.

Types of BPM projects

In general, BPM projects can be categorized into three different types:
• Quick win
• Medium
• Long
The quick win project is sometimes referred to as a pilot project and is often the first
project a company undertakes. This type of project usually lasts 10-16 weeks and is very
focused on delivering value in a short amount of time.
A medium project is usually in the 4-8 month range and a long project is anything over 8
months.
Although the medium and long projects are longer than many of the diagrams you will
see when playbacks and cycles are described, it is important that these types of projects
are also developed iteratively. The overall scope of the project should be broken up into
smaller iterations, each self-contained and targeted to deliver business value.

What tools enable management of a project?

Within the actual project development cycle, the iterative approach helps drive the
refinement of the business and functional requirements of the process. As Business and
IT work towards project completion, IBM Business Process Manager and Blueworks Live,
undergird the effort to go from a level of uncertainty to a finite end target.
Both tools allow collaboration and access to one shared model. IBM Business Process
Manager is data-driven and process applications can be deployed easily and quickly.
Processes can easily be played back during modeling and implementation in Blueworks
Live and Business Process Manager.
Depending on your organization, other modeling tools may be used instead of Blueworks
Live.
In addition, an agile project management tool is also helpful after user stories are
completed. We will discuss this more in later units.

BPM development realities

Keep in mind some development realities as you work through the phases of the life cycle.
Change is inevitable:
• The process model will change as you iterate
• Requirements will change as you implement
• Priorities will shift
Collaboration is key:
• IT and Business MUST partner during the development
Incremental improvements are key:

• Incremental process improvement is far less risky than attempting a project that
attempts to develop all possible functionality as part of one extremely large release.
You may never have the opportunity to implement additional process improvements
based on data about actual process performance in a 1.1 release if you’re being
pushed for an “all-in” 1.0 release.
• Incremental releases are much higher value for customers and allow them to realize
the benefits of the improved process sooner.

BPM solution life cycle

Overview
A unique solution life cycle is required to manage a BPM project from beginning to end.
We have found success using four phases with every type of BPM project, from small
projects to larger ones.
The four phases of the BPM solutions life cycle
There are four distinct phases in the BPM solutions life cycle. At each phase there are key
activities, tools and outcomes that drive to a single BPM solution.
The four phases are:

• Discover and document
• Plan and implement
• Deploy
• Manage
We will talk more about each phase in later sections of this guide.

How is the BPM solution life cycle different?

The basic difference between the BPM solution life cycle and all others is the focus of
each.
BPM is process-focused, or better stated process-driven.
For instance, in a traditional system development life cycle (SDLC), the focus is building a
technology system. BPM requires the focus to be on the process. BPM thus provides an
approach and platform for improving the process throughout every stage of the life cycle.
Other solution approaches
• Most SDLCs emphasize optimization of functional silos and drive system-oriented,
rather than process-oriented, solutions. These approaches offer no features for
inherent control over task routing and execution or decision-making in the flow of the
process.
• Six Sigma is process focused, but its techniques are highly manual and lack
systematic implementation support and operational integration.
• Both SDLC and Six Sigma have no cost-effective support for measuring “process
performance”. SDLC is lacking in this area while Six Sigma is very manual in its
approach to measurement.

Conceptual approach to BPM projects

The diagram below outlines the high-level conceptual approach taken in BPM projects:
NOTES

BPM project roles

Overview
The primary project team for a BPM project development effort consist of the following
main and supporting roles:

BPM project roles: BPM project manager
Role Responsibilities Skills Required

BPM project • Is an expert in iterative delivery • Experience delivering
manager methodology iterative projects and
• Manages scope, budget, and managing program
resources roadmaps that are delivered
• Identifies and mitigates risks incrementally
• Acts as a conduit for escalations • Ability to facilitate business
and issue resolution and IT collaboration
• Provides internal and external • Ability to communicate
status and dashboards effectively to sponsor and
• Lets delivery team deliver executive levels of the
organization
Differentiators: The BPM project manager

The BPM project manager contrasted with IT project manager profiles:
Project manager/IT BPM project manager

• Project oversight • Expert in BPM project management
• Familiar with general project risk • Expert in iterative delivery methodology
management • Expert in BPM project sizing
• Familiar with the waterfall • Expert in BPM risk management
deployment method • Expert in staffing BPM experts across
• Provides staffing alignment and disciplines for optimized project execution
guidance in execution of the work • Expert in managing change control through an
plan agile development approach
• Manages change control and risk • Expert in management of BPM roadmap /
management requirements priorities
• Expert in identifying and delivering BPM
benefits to the organization
• Domain expertise in process improvement
and ability to identify projects that would be
good fits for BPM

BPM project roles: BPM analyst

BPM analyst • Leads process improvement • Experience with process
efforts design, requirements
• Is an expert in process gathering, facilitation
decomposition, scoping, and • Critical analysis and
optimization reporting skills
• Is a power user of IBM Blueworks • Lean Six Sigma training or
Live and Optimizer view of the certification
Process Designer
• Identifies the business case,
key opportunities, and return on
investment (ROI)
• Enforces delivery of key
performance indicators (KPIs),
service level agreements (SLAs),
and metrics

Differentiators: The BPM analyst

The BPM analyst contrasted with a business analyst and process analyst profile:
Business analyst Process analyst BPM analyst

• Identifies • Analyzes processes • Expert in process modeling and
business need • Data analysis as it decomposition
• Requirements relates to process • Six Sigma Green and Black Belts, with
development improvement extensive experience in process and data
• Use case • Documentation analysis
development of process and • Performs “big picture” process inventory
• Performs data methods & for purpose of roadmapping opportunities
analysis procedures and process improvement efforts
• Interpreter or • Deep dive root • Provides process guidance, expertise and
go-between cause analysis mentoring
customer • Internal consultants • Translates standard process documentation
and team – to business into BPM process documentation for
represents the • Assists business in successful development
business interpreting metrics • Optimizes and streamlines BPM processes
• Usually part of and improvement • Identifies KPIs and metrics critical to the
the business opportunities business, process and meeting needs for
and potentially a regulatory purposes
process SME • Business case development expertise
• Experienced change management
facilitator
• IBM Blueworks Live expert – modeling and
mapping of as-is and to-be documentation
in IBM Blueworks Live
• Develops documentation in Process
Designer as needed
• Quality Assurance of process standards,
identification of stakeholders, critical
metrics, overall business value
• Performs value add/business value add and
non-value add analysis

BPM project roles: BPM developer

BPM developer (includes • Models or imports the process • Experience with BPM
technical consultants using Process Designer process development and
and Integration Designer • Implements process flows, experience with software
developers) services, business logic, and user development leadership
interfaces • JavaScript, JSP, SQL, basic
• Develops KPIs, SLAs, and reports logic flows, user Interface
• Designs and implements development, HTML, .NET
integrations, custom data storage,
and complex data manipulations
(technical consultant)
• Guides infrastructure design
and implementation (technical
consultant)
• Develops integrations using
Integration Designer (Integration
Designer developer)

Differentiators: The BPM developer

The IBM Business Process Manager BPM developer contrasted with the developer/
industry profile:
Developer/industry BPM developer

• Use case feedback • Expert in distilling user requirements into a
• Writes code process model
• Writes design • Expert in developing process models using BPM
documents methodology
• Conducts testing • Expert in implementing the programmatic rules
• Writes test plans that drive the execution of the process model
• Uses frameworks • Expert in distilling user requirements into user
• No concept of BPM interfaces that are part of the process model
• Understands database • Expert in implementing Business Process
queries Manager user interfaces (coaches)
• Expert in defining the internal object/data model
that drives the process and the user interfaces
• Expert in using existing integrations to retrieve or
persist information from external systems
• Expert in defining KPIs and SLAs and tracking data
• Expert in defining and implementing trend-level
reports/screens to be used by non-participants in
the process
• Designs, extends, and develops reusable
frameworks and toolsets
• Expert in integrating Business Process Manager
with external systems (technical consultant)
• Applies best practices to deploy scalable systems
and identify and correct performance issues in
existing systems (technical consultant)
• Installs Business Process Manager in multiple
environments, platforms, and clusters (technical
consultant)
• System of record expert as it applies to BPM life
cycle (technical consultant)
• Expert in developing integrations in Integration
Designer (Integration Designer developer)

BPM project roles: BPM solution architect

BPM solution architect • Assists project manager with • Senior developer with five or
estimation more years experience with IBM
• Leads development teams Business Process Manager and
• Designs applications based on BPM project development
both business and technical input • Expert in all parts of BPM projects
• Performs both BPM analysis work including discovery, analysis,
and advanced development work planning, implementation,
as needed development, deployment and
continuous improvement
• Completed multiple BPM solution
implementations
BPM project roles: BPM solution administrator

The BPM solution administrator role may be filled by one or more individuals or
organizational roles, depending on the structure of the organization.

BPM solution • Is an expert in installation and • Experience with system
administrator configuration of application administration of multi-tier
servers, databases, and enterprise business applications.
operating systems • Experience in architecture
• Identifies appropriate environment planning, application services
architecture required to support • J2EE, SQL, SOAP, XML
development, testing and • Experience managing WebSphere
production migration requirements application servers
• Performs troubleshooting and • Experience managing applicable
root cause analysis of system and database platforms – DB2, MS
application issues SQL Server, Oracle DB
• Is proficient in monitoring and
tuning performance of a multi-
tier solution with service-based
integrations

BPM project roles: BPM process owner

BPM process owner • Has business accountability for the • Not applicable
process
• Functions as the leading subject
matter expert (SME) and main
collaboration contributor for
defining both the as-is and to-be
process
• Serves as the final decision-making
authority for defining the process
solution
BPM project roles: BPM process participant (SME)

BPM process participant • Provides practical and detailed • Experts on details and
(SME) information about the business extensive knowledge of the
process business process
• Collaborates with analysts and • Availability up to 80% of
developers during discovery, project time during early
planning, and implementation playbacks and 25-50%
phases of project time in later
playbacks

BPM journey
An organization’s experience with BPM can be thought of as a journey from project to

program to an organization-wide source of competitive advantage.
BPM is validated as a method through one or more initial projects, and then adopted
throughout a department or company. As it spreads, a BPM program is formed, and
eventually the company is transformed by BPM. The road to the transformation will involve
many projects of different sizes and scope.
As you can see the most risk is also undertaken at the point after the validation phase,
when a company starts undertaking new BPM projects on its own, relying on training
and mentoring they have received during the earlier projects, with less involvement from
experienced external resources. During this adoption phase, a company begins to become
self-enabled.
We will re-visit the BPM journey again at the end of the course. At this point, keep in
mind, that this course is only the start of a bigger BPM journey.
Validate Adopt Transform
Objective Prove Value and Suitability Embed in Core Operations Drive and Align Direction
Governance IT / Per Project Business + IT / Per Process Business + IT / Program
Result Proof Point Solutions Mission Critical Solutions Decision-enabling Solutions
RISK
Talent
Work With IBM Try it on your

and Partners own TALENT
GAP/RISK
PROFILE
Maturity

NOTES

Exercise 1.1: Unit review and discussion

In this exercise, you will discuss the following topics with your instructor
and classmates. Please be prepared to answer these questions using your
current organization and experience as your guide.
If you are taking a self-paced version of this course and do not have an
instructor, listen to the discussion provided and think about how these
questions apply to your organization.
• What type of development does your organization typically complete?

On a scale of 1 to 10, how iterative is this development? If you do not
currently develop iteratively, what challenges will you face if you do
develop your BPM projects with iterations?
• What is the main challenge you think you will encounter while managing
a BPM project?
• What type of BPM project will you be completing first or have you
completed recently? Quick win, medium, or long? How will you or did
you apply playbacks during the project? What were the benefits and
things to be aware of with your project?
• Where on the BPM journey do you think your organization is? Use the
graph on the previous pages to point out where you think you are and
have reasons to support your claim.

NOTES

Unit 2:The Introduction

The first stage of the BPM solution life cycle is the discover and document phase.
discover and In this stage, business and process implementation requirements are captured and
document communicated across the organization. We will discuss the methods used to capture
requirements to accomplish this stage in a comprehensive manner.
phase
Objectives
• Describe the parts of discover and document phase
• Manage project scope and requirements
• Define user stories for a BPM project
Topics
• The discover and document phase overview
• Requirements
• User stories

Discover and document phase
Overview
Key outcomes:
• Definition and modeling of as-is and to-be processes through collaboration across
functional boundaries to understand the complete value chain
• User stories (including acceptance criteria) captured and validated by business users
• Preliminary identification and estimation of development tasks related to user stories
by developers and project manager
• Prioritization of user stories/functionality by business users and process owners to
facilitate planning of development iterations
Tools:
• IBM Blueworks Live (other modeling tools can be used)
• IBM Business Process Manager, any edition
Primary activities:
• Identify and define business value of process activities
• Process decomposition and mapping (as-is and to-be)
• Process problem identification and prioritization
• KPI and SLA definitions
• Business case development
• Business change management
• User story definition
38 Unit 2: The discover and document phase

Where do things go wrong?

• Skipping process definition entirely, starting with system-centric functional
requirements instead of process-centric requirements (user stories)
• Absence of higher level strategic goals aligned to project, or misalignment of goals
• Inability to identify value propositions for the process
• Only involving the business at “arm’s length”
BPM succeeds most when:

• Business process management analysis is its own recognized discipline within the
organization
• Every project and every line item feature for that project is justified in the business
case
• There is a roadmap of opportunities that is identified as part of the initial process
analysis, as it is recognized that “not everything will go into version 1”
• Active ongoing business participation in the project

Discover and document stages

During the discover and document phase, the BPM project team endeavors to define and
capture the business requirements of the process. This is accomplished through a series
of discovery, analysis and assessment activities. These activities can be captured in IBM
Blueworks Live or another modeling tool collaboratively by the team with the Process
Owner. This phase normally takes 5-20 days.
There are four stages of the discover and document phase:
• Identify
• Assess
• Discover
• Analyze
Identify
An organization that intends to begin using BPM may begin their journey with a backlog of
process project candidates and a desire to identify the process or processes that can most
effectively and valuably be taken on first. In this situation, the “discover and document”
phase of the life cycle begins with creating a process inventory. It is important to develop
an inventory so you are working on the correct processes at the correct time. By choosing
the most appropriate process for an initial BPM project, you can build business value and
start getting people on board for change.
If the process that is the subject of an initial BPM project has already been selected, or
if the organization has decided to implement BPM specifically to address a particular
process or set of processes, this stage can be considered optional. BPM project
managers should be aware, however, of the basic activities and outcomes of this stage for
when usage of BPM expands beyond the initial project(s).
• Develop process inventory
• Conduct first interview
• Gather the following details about each process
• Process owner
• Short description
• Size and complexity
• Risk
• Pain
• Input process inventory into Blueworks Live or similar tool

Assess
In the assess stage, we determine if a process has enough business impact and return on
investment to pursue. This is also where the project charter is created. In some cases, this
phase might be shorter if a project has already been determined and defined by someone
else.
• Assessment of strategic alignment
• Develop the charter
• Create problem statement
• Determine goals and objectives
• Build initial business case
• Voice of the customer and business

• Identify and prioritize customers
• Translate customer needs to Critical to Quality (CTQ) attributes of the process
outputs
• Set process performance specifications for Critical to Quality (CTQ) attributes
• Develop and finalize prioritization matrix

• Prioritize requirements
• Pareto principle
• Finalize cost benefit analysis

• Forecasted NPV
• Cost avoided
• Revenue protected
• Final scope and value report

Discover
The discover stage is when process discovery begins and where the existing as-is process
is mapped and documented. These initial diagrams should reflect the current state of the
business process.
• Design primary process flows
• Executable BPD flow (Happy Path – with stubbed exception paths)
• Information elements of UIs (coaches) defined in model
• Data flow defined in model
• Integrations stubbed in model
• Preliminary user stories created for each primary business process diagram (BPD)
activity
• Details gathered for each activity using SIPOC method (suppliers, inputs, process,
outputs, customers)
• Non-functional requirements defined
• Identify KPIs and SLAs
• Record pain points and areas of risk at the end of the discovery phase, but do not
make this the focus of initial mapping

Analyze
Analysis of your as-is process leads to an improved to-be process. All of the information
recorded in the discover stage allows you to transform your process. Although it is
possible to begin automating activities at this point, it should not be the primary focus.
Providing additional business value or streamlining the process should be the overall focus
and analysis should be approached holistically.
• Re-engineer primary process flows
• Executable BPD flow (Happy Path – with stubbed exception paths)
• UIs defined in model
• Data flow defined in model
• Integrations stubbed in model
• Use KPI, SLA, pain point and risk information to drive change in the model
• Automate the process where value is added
TIPS Often the stages of this phase are not definite with end points, and oscillation between
the discover and analyze phases is common. For example, you might not have all the SI-
POC details completed for each activity before you analyze part of the process. Later you
will go back and finish those details and then analyze further. This type of oscillation aligns
with iterative development. The important goal is that these things are complete before
finishing the discover and document phase and moving onto development.

Discover and document deliverables

The initial discover and document stages align with the following deliverables:
Process inventory and triage (if multiple process projects are under consideration)
• Ranked process improvement opportunities
Goal mapping
• Strategy and goals mapped to processes
Project charter and business case/return
• High-level business case and return
As-is process models
• High-level process diagrams with major subprocesses indicated
KPI mapping
• Top project KPIs and SLAs
Process improvement plan
• Pain points, opportunities for improvement, and recommendations
To-be process models

Process inventory and triage

• Identify highest priority business goals and drivers
• Ranked list of processes based upon impact on those goals
Goal mapping
Identify project goals and business drivers
• Measurable objectives
• In scope / out of scope
• Key stakeholders and project team members

Project charter and business case/return

• Demonstrate end state benefits from the solution recommendation
• Quantifiable return numbers with a timeline for results
• Business benefits linked back to project goals
As-is process models

• Link process steps to project goals
• Identify roles, responsibilities, inputs/outputs and procedures
KPI mapping
• Discover and identify KPIs, SLAs, and metrics
• Associate those metrics with processes
• Plan to track and monitor performance with IBM Business Process
Manager

Process improvement plan
Problem and pain points

• Identify opportunities for improvement and pain points in the process
• Rank and identify the highest value problems to attack first
Opportunities for improvement

• Identify process hot spots
• Bottlenecks
• Rework
• Non-value added steps
Recommendations
• Identify and rank a set of recommendations for improving the biggest pain
points in the process
• Both short and long term
• Highlight operational impacts and cost of each

To-be process models

• High-level process diagrams with major
subprocesses indicated
• Address areas of inefficiency and pain identified
in the as-is process

Playback Zero
Traditionally, BPM development teams have used the term “playback” to describe an
interactive demonstration of the functionality developed within an iteration, involving
the developers, the process owner(s), business users, subject matter experts, and other
stakeholders. Playback 1 occurs at the end of the first iteration, playback 2 occurs after
the second iteration and so on. Playback zero, then, refers to the in-depth review of the
process information captured and documented during the discover and document phase.
During this playback, it’s often not yet possible to actually play back the process model;
the emphasis is on a detailed review of the process model, including the information on
process inputs/outputs, activities, areas of process pain and risk, etc.
At this point it is important to playback the process and not the technology. The focus
should be on high level business process understanding and building consensus.
The goals of playback zero are:

• Consensus building and discovery of business process amongst stakeholders
• Further understanding of implementation scope
• Alignment of bottom-line expectations, KPIs, and high-value metrics from executive
sponsors
• Transferring context and responsibility from the BPM analyst to the BPM developer
Logistics
• Have the process owner or another member of the business play back the process
• Secure participation from all stakeholders as this is a major milestone in the project

People, process, and technology assessment

Throughout this phase of project management, it is important to keep the following items
in mind and discuss these items with your team. Although the project management role
is not the same role as the process owner, it is important for the project manager to be
involved with minute details of a BPM project. Often, the process owner might not be
available or reachable due to other commitments. Many times, the project manager will
act as an agent for change and really be the glue that holds the project together. If it is not
your personal project management style to be involved with all details of a project, it is
important that you delegate this role to someone that is dedicated and readily available.
The following assessments will help you become familiar with project details:
• People
• Change readiness assessment
• Training and communication strategy People
• Rollout strategy (i.e., to pilot or not to pilot)
• Process
• Process prototype review and sign off
• BPM support strategy
• Process implementation estimates
• Technology
• IT readiness Technology Process
• Tools readiness
• Integration assessment

Requirements
How do you accomplish these four stages to complete the discover and document phase?
Let’s turn the focus on how this is actually accomplished, starting with requirements.
Requirements gathering is the most important portion of this phase. In fact, it is the most
important step in the overall project development. It can also be the most misunderstood
step.
A effective requirement for iterative development captures:

• Who is performing the action
• What is the action they are performing
• When is the action performed
What a requirement does not capture is how an action is performed. ”How” the
requirement is fulfilled is worked out collaboratively between the developers and process
participants or subject matter experts. The final important item of information to capture
for each requirement is its priority relative to the other requirements; ideally, this priority is
a function of the business value the requirement is expected to provide.
When are requirements gathered?
Gathering requirements starts early in the project, during the analysis activities. The to-
be process model and the process charter are the first places where requirements are
documented.
Gathering input
Input on requirements is gathered and validated via a variety of means, including:
• Process validation and refinement

• To-be process model walkthrough with the process owner and customer subject
matter experts
• Requirements interviews and facilitation sessions

• Document reviews
• Reviews of existing systems
• Playbacks

Where do things go wrong?

Requirements development can go astray when the following factors are present:
• Decision by committee (no clear decision maker or process owner)
• Goals / alignment are not clear (focused on the wrong things)
• Can’t tie individual requirements to business value, affecting ability to prioritize and
filter
• Technical requirements, capacity planning , and other non-functional requirements are
ignored or neglected
BPM succeeds most when . . .
In contrast, the most effective requirements gathering and validation happens when:
• There is a clearly defined process owner with a solid understanding of the process and
the authority to make timely, effective decisions about the process
• Analysts involved in requirements development are comfortable with an iterative

development approach and understand how to capture user stories that effectively
document requirements that can be developed and tested successfully
• An iterative development methodology is used. However, for some organizations this

is not possible, and it may be necessary for the project manager and process owner
or executive sponsor for the project to negotiate an appropriate hybrid approach.
Another option is to decide up front to revert to a waterfall methodology when agile is
absolutely impossible.

User stories
Overview
• What specifically is a user story?
• Why user stories for BPM?
• What is the difference between user stories and use cases?
It begins with a user story

• A user story is a software system requirement that is represented as one or two
sentences in the everyday language or business language of the user
• Each user story is limited, so it fits (or at least, could fit) on a small paper note card.
This ensures that the user story does not grow too large. Imagine a 3×5 inch note card
when creating stories.
• User stories are a quick way of tracking customer requirements without having to
create extensive formal requirement documents. The overwhelming administrative
tasks related to maintaining formalized requirement documents disappears.
Basic user story format:

“As a <user role> I want to <user action> so that <goal is achieved>”

Why user stories for BPM?

You have to know what you’re going to do. But defining everything up front in a formal
requirements document entails numerous assumptions that may or may not be valid,
and ignores the high likelihood of information that is incomplete or imperfect, or that is
right today but becomes wrong tomorrow. User stories provide a basis for planning and
estimating effort, timeline, etc., so that they’re not pure guesswork, but don’t pretend to
know more than they do.
User stories emphasize the specific goals that individual users must achieve in order for
the organization to meet its goals.
More information about the activity represented by the story becomes available as the
BPM team collaborates with the business. Using user stories allows the team to avoid
guessing at that detail in advance and to capture it when it’s actually needed to build the
functionality.
The need to collaborate between developers and users is actually a benefit of using
user stories. It is typically not possible for the development team to complete their
work effectively without that collaboration, and having collaboration greatly increases
the likelihood that the developed functionality not only meets some specification, but is
actually useful to and usable by the business in meeting its goals.
User stories have been described as “a promise to hold a conversation” between the
developers and the users to whom the story matters. It captures the need to implement
something while leaving the details of that to be worked out directly between the user
who will use the functionality and the developer who will build it.
What is the difference between user stories and use cases?

Use cases describe the interactions of actors with a system, mainly from the point of
view of the system. User stories describe an action that a user wants to perform, from
the perspective of the user. The user doesn’t necessarily care about the preconditions,
alternative paths, etc., that are part of a complete, formal use case.
However, there may be stakeholders involved who do care about these things, or who
need them to do their jobs (external QA resources, for example). Or, it may be the
case that the development team has insufficient domain knowledge to be able to work
effectively without the additional framework of use cases.

What makes a good user story?
Independent: Independent user stories are contained within boundaries so that no story
depends on another. Creating independent stories allows the ability to schedule and build
any story without considering order of the stories. Therefore, we can select stories with
the highest value without worrying about low value dependent stories.
Negotiable: User stories should be malleable and can be changed or rewritten if
necessary. In iterative development, the iteration or playback timeline is fixed and the
scope varies. Typically, higher value stories are developed first and lower value stories are
developed if time allows. In order to prioritize, it is important to be able to combine, split,
modify, and clarify stories as needed during the development cycle.
Valuable: The stories should bring business value to the users or stakeholders. It is
important that stories are written in a manner where the primary stakeholder understands
the value the story provides. Watch out for stories that become too technical. These might
be fun to code, but often do not bring much business value to the users.
Estimable: All stories should be estimable because if a story cannot be estimated, it will
not be planned or included in a playback and therefore, is not relevant to the project. Often
stories that cannot be estimated are missing a key component, missing supporting details,
or are too large. Estimates of user stories do not need to be exact, but we want to be able
to get a general estimation of the story.
Small: Stories that are negotiable and estimable are often small. Larger stories are harder
to negotiate and result in much more uncertainty during estimation. Break long user
stories, known as epic stories into smaller user stories. Small is a relative term, but after
working for a while, your team will naturally set a limit for the appropriately-sized story.
Testable: You want to be able to consider a user story complete and tested. If you cannot
test a user story, the story is often missing details or another key component. It should be
rewritten or left out of the project.


Best practices
• An “epic” is a user story, but one that covers a large set of requirements and can be
broken down into multiple user stories. When people describe the intended outcome
of the project as a whole, they’re probably talking in terms that would be considered
an “epic”
• Collectively, all of the user stories created for a project should cover all of the goals
that are defined for the project. Likewise, if a user story cannot be identified as
contributing to a specific goal, then it should be evaluated to determine if it should be
removed. If a story without a related goal is regarded as critical by the business, then
the goals for the project probably need to be re-evaluated.
• A “closed story” finishes with the achievement of a specified meaningful goal. It’s
straightforward to test whether the solution meets the need defined in the story by
determining if that goal is achieved.
• “Constraint stories” define conditions or technical considerations that apply to the
other stories. If the constraint applies only to a particular story (activity), include it as
part of that user story. If it applies universally or to a range of stories, use a separate
constraint story.
• Use cases may be required if a particular story is extremely complex, or if there
are numerous exception/alternative paths that must be specified, or if the context
and conditions under which the activity is performed are extreme, unusual, or
complicated.
• Interface: user stories should specify what needs to be accomplished, not how it
should be done. As such, interface considerations should rarely be included, and then
typically as a constraint story rather than as part of a functionality story.
• The business should own the content of the user story and the connection of the
story to goals. A great way to ensure this is to have the business owner or end-user
(participant) for a particular story write that story, in collaboration with the team.

Goals drive user stories

Ensure that the user stories collectively address all of the goals of the project. If each user
story fulfills the acceptance criteria defined for it, are all of the goals fully met? If not, there
are stories missing that must be accounted for before estimating and planning the project.

Gathering stories
Consider using IBM Blueworks Live to capture and document the user story as it applies
to activities. A good rule of thumb is that there should be, as a starting point, a user
story associated with each activity in a diagram. Note that there may not be a one-to-one
correspondence between user stores and activities in the resulting IBM Process Designer
business process definition (BPD). The BPD describes how the implementation of a
process works, while the Blueworks Live diagram describes the process from a business
point of view.
Other methods that can be used to gather user stories: workshops, interviews,
questionnaires and observation.
Who is responsible for capturing user stories?

The BPM project manager is responsible for the successful delivery of the project. The
PM will coordinate and lead other team members to meet this goal. This includes the
capture of user stories.
• The BPM analyst is responsible for capturing the as-is and to-be process and the initial
user stories
• The BPM developer is responsible for further decomposition of the user stories once
Playback 1 begins

Exercise 2.1: Process review and introduction

For the rest of this course, you will be using a scenario process to complete
exercises as we progress through the different phases of the course. The
process has already been through most of the discover and document phase
and is a to-be process model.
This process is smaller in scale than most real-world processes, but will
give you a good idea of the tasks that need to be completed as a project
manager. Some of the tasks we will do are to enforce concepts learned from
earlier in the unit. A different role might be doing some of the tasks when
you are actually managing a project.
Read the process requirements and examine the diagram to get familiar with
the process that will be used in other exercises.

NOTES
NOTES

Exercise 2.2: Writing user stories

To become even more familiar with the process and reinforce the user story
format, write three use stories based on the process and requirements.
Your instructor will act as the process owner for the process and you can ask
any questions you like to understand the process further.
If you are taking ZB004 version of this course, and do not have a live
instructor, listen to the recorded conversation and base your user stories on
the conversation and process requirements.
The user story format is:

As a <user role> I want to <user action> so that <goal is achieved>.
Remember these points when writing stories:

Good user stories are Independent, Negotiable, Valuable, Estimatable, Small
and Testable.

NOTES

Unit 3:The plan Introduction

The business requirements for a project are validated and implemented during the plan
and implement and implement phase of the BPM solution life cycle. The shared model architecture
phase, part I of IBM Business Process Manager allows for frequent “playbacks” of the developed
functionality for the business users. This ensures that feedback about the team’s success
in understanding and meeting the business needs is obtained early and often. The iterative
development approach allows for build and test schedules that stress the quality of the
solution throughout the development cycle.
Objectives
• Describe the plan and implement phase of the life cycle
• List and describe the playback phases in the implementation phase
• Describe the role of testing in the plan and implement phase
• List and describe the different types of estimation
Topics
This unit includes the following topics:
• Plan and implement phase overview
• Playbacks and project management
• Quality assurance and testing
• Introduction to planning and estimation

The plan and implement phase
Overview
Key outcomes:
• Allocation of user stories to iterations or playbacks
• Estimate of relative degree of effort required to implement each story
• Working software that meets the business needs identified by the user stories.
• Existing technology assets integrated into solution in a cost-effective manner
Tools:
• IBM Business Process Manager, spreadsheet program, Agile project management tool
Key activities:
• Estimation and planning
• Solution development
• Playbacks
• Quality assurance and testing
64 Unit 3: The plan and implement phase, part I

Estimation and planning

Planning and estimation takes place during process analysis at the end of the discover and
document phase and will often overlap with the playback zero of the process as defined in
the previous unit.
Three types of estimates are typically created for BPM projects at different points in the
solution life cycle:
• Rough order of magnitude
• Budgetary estimate
• Detailed estimate
Later in this unit, we will talk about how each type of estimate is used.
Before we move to estimation, it is important to first understand playbacks and their role
in a BPM project.

Playbacks and project management

Overview
In the BPM methodology, the term “playback” is used both for each time-boxed
development period (analogous to “iterations” or “sprints” in other iterative development
methodologies) and for the process of demonstrating developed functionality to
stakeholders and obtaining their feedback. Each playback period is concluded by a
scheduled, organized playback demo session that allows everyone involved to see and
experience how the user stories have been implemented. Within each playback iteration,
it is expected that the developers and stakeholders will be regularly “playing back” the
functionality under development as they collaborate on it. The final playback meeting at
the end of each iteration should be an end-to-end review and summary of functionality
developed during that playback period that the subject matter experts and process owners
have seen several times already during development.
Input
• Previously developed to-be process model
Activities
• Develop or import the to-be process model in IBM Business Process Manager
Process Designer
• Model and finalize the business process definition (BPD) with customer consensus
• Determine coach placeholders
• Identify coach variables and dependencies (include field validations)
• Identify and describe integrations
• Identify any other development items
• Load user stories into management software
• Create a development estimate (days/hours) and timeline. All features that need to
be developed = release backlog
• Create the release and iteration plan (including playbacks and build deployment)
• Execute iteration plan
Output
• Release and an iteration plan
• Build deployment and testing schedule
Tools
• IBM Business Process Manager, spreadsheet program, agile project management
software

Requirements, design, build, test

Each playback has stages of requirements gathering, designing, building, and testing.
Each of the stages is relatively short and the cycle will be repeated several times during a
playback phase resulting in a final playback. After a final playback in a phase, you can move
to the next playback phase of development.
For different projects, there are a variable number of playback phases, but generally, you
will have 4-5 numbered phases including playback zero. There is also variability in length
of playbacks. Keep this in mind as you cover the specifics of each playback. The most
important key is that you define goals and objectives for each of your project’s playbacks
and communicate these themes before the project is implemented.
The next pages give a high-level view with example themes for each playback. The course
guide continues with an example playback plan.

Theme: “Discover and analyze the process”

• Discover the process
• Author the as-is process
• Analyze and improve the process
• Author the to-be process
Roles
• BPM analyst (1)
• BPM developer (1, part-time)
• BPM project manager (1)
• BPM solution administrator (as needed)
• Process owner and process participants (SMEs) (as needed)

Theme: “Build the process”

• Author the business process definition
• Define the roles or participants
• Define the business objects and variables
• Configure the screens
• Model rules across the screens and model
Roles
• BPM analyst (1)
• BPM developer (3)

Theme: “Connect into the infrastructure”

• Configure data flow
• Connect to other systems of record
• SMTP
• Data warehouse
• Integrate LDAP or single-sign on (SSO)
• EAI
Roles

Theme: “Refine the delivery”

• Model corner cases
• Expand search capabilities
• Build metrics and performance reports (tuning and measurement)
• Other types of processing automation
• Feedback from playbacks
• Refine user interfaces (UI)
Roles

Playback plan
Before you start it is critical that you develop a playback plan. The plan below is an example
for a typical process.
Playback zero
Focus on high-level business process understanding and building consensus.
This playback is done at least once at the beginning of a project as part of the
process discovery phase.
The goals of playback zero are:
• Consensus building and discovery of business process amongst stakeholders

• Further understanding of implementation scope
• Alignment of bottom-line expectations, KPIs, and high-value metrics from executive
sponsors
• Transferring context and responsibility from the BPM Analyst to the BPM Developer
The deliverables of this playback include:
• An executable process definition (BPD)

• Modeled to the level of depth necessary to show each discrete end-user task
encountered in the process.
• Does not need to include the specific implementation of each activity. A place-
holder is sufficient.
• A participant and user group model
• As denoted by swim lanes in the BPD or as notes on the diagram when routing
rules are more sophisticated than a single participant group
• Notes on the diagram to denote end-user activities that will require information from
external systems (integrations)
• A basic data model using IBM Business Process Manager variable types
• Should cover all process data (as one sub-variable type) and as much business
data (as another sub-variable type) as reasonably as possible to discover in the
time frame
• Mocked-up reports that demonstrate a combination of the following BPM principles:
• Visibility
• Analysis
• Control
• A focused demonstration of the above deliverables, run within the default end-user
portal interface, implemented by the BPM analyst, and delivered by the process owner
with coaching from a BPM analyst
After conducting playback zero, the next step in subsequent playbacks is for the
BPM analyst to act as the executive-level voice of the customer, through
playback alignment with the executives.
Adapted from Scaling BPM Adoption from Project to Program with IBM Business Process Manager, IBM, Sep-
tember 2011.

Playback 1
Focus on user interface design and implementation.
This playback is typically done at least once, and in concept it can be done as
many times as is necessary to realize the theme of user interfaces.
The goals of playback 1 are:
• Consensus on and implementation of all necessary user interfaces

• Consensus on required data model to support user interfaces and business decisions
By working together with the BPM analyst, the BPM developer will define and
implement each human interface that the process requires. This should include
all human tasks in the process, any ad hoc interfaces that exist outside the
process, and any reports, dashboards, and scoreboards that are needed to
elevate visibility and control of the business process.
The deliverables of this playback include:
• Definition of the data model necessary for the business process

• Definition of what parts of the data model will be captured via human tasks or inter-
faces
• Definition of the business actions that need to be enabled in each interface
• Definition of all possible next steps for each action
• Definition of the required validation necessary to maintain data and decision integrity
• The general appearance of the process solution (styles, themes, headers, consistent
layout guidelines) - wireframes
• Implementation of all required user interfaces as informed by the above points
• It is assumed that this deliverable will not include the implemented integrations,
reference data (auto-population of choices), or system-of-record population that would
eventually be required for the full solution.
• A focused demonstration of the above deliverables, run from the default end-user por-
tal interface, implemented by the BPM developer, and delivered by the process owner
with coaching from the BPM analyst and BPM developer
The next steps after playback 1 leverage the understanding of the process from
Playback zero together with the data model and user interaction understanding from
playback 1 to focus on building the necessary integrations to support the
process, its decisions and human interactions.
tember 2011.

Playback 2
Focus on integrations.
many times as is necessary to realize the theme of integrations.
The goals of playback 2 include:
• Implementation and exception handling for all integrations that are needed to support
the business process
• Definition and acceptance of all service level agreements and setting expectations
with the owners of any external systems involved in the integrations
• The BPM developer and a specialized BPM developer, the technical consultant will
define and implement each integration necessary for the process. This should include
any external integrations and any System of Record (SOR) development necessary to
support the full process solution.
The deliverables of playback 2 include:
• Definition of the interfaces required for each integration point

• Definition of the data transformation required to send and receive information from
these external systems
• Definition of all the fault codes that could possibly be returned from the external sys-
tems in response to invoking an integration point
• Definition of the exception handling mechanism around handling any of the fault codes
• Definition of the required validation against these integration points necessary to main-
tain data and decision integrity
• Implementation of all required integrations as informed by the above points
• A playback 2 deliverable does not constitute a fully functional solution that is
ready for user acceptance testing. Additional elements that finalize the process
implementation from playback zero, the UI items from playback 1, and the inte-
gration items from playback 2 still remain to be implemented.
• A focused demonstration of the above deliverables, run from the Process Portal, imple-
mented by the BPM developers, and delivered by the process owner with coaching
from the BPM developer
The next steps after conducting playback 2 leverage the understanding of the
process from playback zero, the data model and user interaction understanding
from playback 1, and the finished integration points from playback 2, to focus on
consolidating all themes into an end-to-end solution that is ready for user
acceptance testing.
tember 2011.

Playback 3
Focus on consolidation of the previous themes and producing an end-to-end

solution.
many times as is necessary to accomplish the theme of the end-to-end solution.
The goals of playback 3 are:
• Completing all necessary implementation details to consolidate the process automa-

tion, user interfaces, and integrations necessary to deliver a full BPM solution
• Delivering a fully deployable and testable solution that is ready for user acceptance
testing
The BPM Developer will define and implement all remaining functionality points
necessary to complete the end-to-end process solution. This final playback
theme should not introduce any entirely new functionality to the solution. The
focus should be on completeness, refinement, and stability.
The deliverables of playback 3 include:
• An end-user testable solution, ready to be deployed to the user acceptance testing

environment
• Documentation (beyond what is already built into the solution) needed to enable end
users, administrators, and system-level developers
• A clear description of all functionality that has been deferred to the next revision of
this project (after the current iteration is deployed to production)
• Implementation of all required functionality necessary for an end-to-end solution
• A focused demonstration of the above deliverables, run from the end-user interface,
implemented by the BPM developer, and delivered by the process owner with coach-
ing from the BPM developer
The next step after conducting playback 3 is to submit the project to the user
acceptance testing phase, and prepare for a production deployment.
tember 2011.

Best practices for playbacks

The playback is one of the items that sets IBM apart from other solutions. The playback
meeting at the end of each playback period (iteration) should be focused. If you have a
large process that involves multiple teams, break out into multiple playbacks focusing on
one team at time to make the best use of everyone’s time.
• Define the purpose of the playback in advance
• Tell and show and tell
• Tell your audience what you plan on covering during the playback, show them the
functionality covered in the playback, and then tell them what you showed (recap
the playback)
• Have a defined “leader” of the playback, preferably the process owner
• Make sure that roles and responsibilities are clearly defined and the playback lead
knows his / her responsibilities
• Roles and handoffs should be clearly defined within the playback
• Who’s directing the playback? Who’s facilitating the discussion? Who is
responsible for coordinating questions from remote participants? Who’s capturing
feedback?
• Make sure there’s a plan and shared responsibility
• Set expectations for the playback ahead of time
• Treat your audience as “your customer” and make sure they know the parameters
of what they’ll see, and manage the scope
• Know your audience
• Make sure you know who’s attending and why.

• Categorize and prioritize the feedback

• Make sure everyone knows which “bucket” that the changes fall into (UI, flow,
integration / data, etc) and if there’s a set of priorities, be transparent about where
each suggestion falls
• Screenshots set the stage

• If you plan on going through numerous user interface items, it can be helpful to
pass out screen shots in advance so that everyone is clear on what’s being shown
in advance so that they can formulate feedback beforehand
• Plan the follow up

• Repeat their feedback, make sure that they know they’ve been heard, and set a
timeline for when they’ll see the changes you’ve recorded
• Multiple playbacks are okay

• If you’ve got an audience that covers a lot of ground (multiple business units, IT,
etc), then having multiple playbacks that are very targeted is okay
• Have a list of the open items
• Document these as soon as possible and share with the team along with the plans
for follow up

More tips for playbacks
Handoff
The process flow during planning and implementation requires oversight from the BPM
project manager so that each handoff, from BPM analyst to BPM developer and from
iteration to iteration, is properly documented and executed.
• BPM analyst develops process charter and IBM Blueworks Live or other modeling
diagram
• BPM analyst captures initial backlog and user stories
• BPM project manager reviews backlog and user stories with process owner
• Process owner should own the user stories, however, the project team will be
involved in documentation
• Process owner prioritizes the backlog

• Handoff to the BPM developer
• Each user story is further decomposed into coaches and services.
• Process owner updates/re-prioritizes backlog after each playback

• The PM may assist from an administrative perspective
• The user stories are used for customer acceptance at the end of the project
The backlog is a list of both user stories and other features, such as performance, that is
more technical in nature.

Daily stand-up meetings

An effective technique that will help mitigate communication gaps in the process
development is the daily stand-up meeting.
Parameters
• Daily
• 15 minutes
• Stand-up
• Not for problem solving
• Only team members with responsibility for specific deliverables should speak
• All project stakeholders are invited to listen
Three questions
• What did you do yesterday?
• What will you do today?
• What obstacles are in your way?

Quality assurance and testing
Overview
Quality assurance is, of course, more than just testing. It is proactive steps to build quality
into the solution. It starts at the beginning of the project. As such, quality assurance is a
combination of activities, such as testing, solution reviews and retrospectives.
Quality assurance should be planned to occur throughout the project. It should be included
at the end of the analysis, within each iteration, at the end of each iteration, and at project
completion.
Quality assurance key activities

• Program Reviews
• Peer Reviews
• Unit Testing
• System Testing
• Endurance / Peak Testing
• Testing Automation

Building quality into the project throughout development

Developers working disconnectedly from other developers (no peer reviews) or from the
stakeholders (no sanity check on output) are far more likely to produce solutions with
significant problems. Success of an iterative methodology depends on constant feedback.
You’re not coding to a cast-in-concrete requirements specification, and if the developed
solution doesn’t answer the business need, it’s defective, no matter how closely it
matches the documented requirements.
“Official” playbacks should be treated as releases, with the same sort of discipline around
defining a stable version, deploying to a known-good stable environment isolated from
other efforts, etc. It’s a lot more than just inviting the stakeholders into a room and taking
for a spin whatever version the developer happens to have on their laptop.
Often project teams include time for quality activities like unit and user testing, but not
necessarily for developing test services, preparing test environments, establishing data
sets for testing, etc. In particular, because BPM projects usually entail integration with
and orchestration of multiple external systems, the question of whether and how these
systems will be available in test environments is often crucial – and often overlooked.
Ongoing validation of solutions during development is critical to success in an iterative

methodology using “right-sized” requirements documentation.
Successful projects make all of these quality activities a clearly defined part of the project
methodology, ensuring they’re done in a deliberate, careful manner, not as an afterthought.

Testing
Overview
Testing should happen throughout development. Many iterative development proponents
argue that tests should be built before the code or components they relate to. There
may be reasons not to take this approach, but developers should consider providing
mechanisms for testing components (test services, test harnesses) to be part of the
deliverables for the development process.
• Iterative testing – not a “big bang” event, but ongoing throughout development
• Unit and functional testing for each iteration
• Build tests before/alongside functional components
• Write test cases based on user stories for acceptance testing
• Set up procedures for generating and resetting test data in each environment

Something may happen often, but has little or no impact on the intended goals for the
process, it’s probably not worth investing lots of time on tests to identify that defect.
Conversely, if something is extremely unlikely to occur, but has catastrophic impact if it
does, you must test for it.
• Scale the effort to the value of the process
• Push responsibility for testing the components down to the right level
• Focus on verifying the orchestration
• Focus on validating the highest risk items in your process
• For example: Highest volume services, Highest volume user-touch processes
• Focus on creating tests to verify defect fixes

Types of testing
For most BPM solutions, the testing effort needs to be organized slightly differently
than for pure-code development – you can focus more on testing the logic embodied
in the business process definition (BPD) than on the expression of that logic in code.
Manual testing
Testing by a formal QA group outside the project team may dictate production
of additional documentation beyond what is required to develop a BPM solution
effectively. Identify and negotiate organizational expectations early on in project
initiation.
For less complicated solutions, usually manual testing will suffice. The effort to
develop test services/harnesses is sometimes not justified based on the effort and
return.
Automated testing
Automated testing: Used for regression
• Unit (white box) – test inputs/outputs of a specific unit
• Works well with services
• Can be written as a service to call the service being tested
• Functional (black box) – test system

• Works well with coaches
• Can be implemented with 3rd party tools
• Performance Testing for high volume solutions

IBM Business Process Manager tools

Use the Process Designer to analyze, run, and track quality of the solution
• Simulate and analyze
• Use simulation to uncover resource shortages or bottlenecks before full
implementation is performed
• Identify and track issues
• Use IBM services to run each unit test, a suite of unit tests, or an entire regression
suite
• Generate load with scripted calls to a web service or event
• Measure and analyze
• Use Business Performance Warehouse to analyze the results of tests
• Use Business Performance Warehouse to report analyze find vs. fix rate
• Use Process Designer to measure performance of integrations using tracking
points
• Use Process Designer to measure performance of services using tracking points
Process Optimizer

Introduction to planning and estimation

Now that we have covered playbacks, we can talk more about planning and estimation
before playbacks begin. In the next unit, we will explore the tools used to complete an
estimation.
As mentioned before, there are three types of estimation:
• Budgetary
• Detailed
These three types go from least accurate to most accurate. Rough order of magnitude can
be completed early during discovery. A budgetary estimate is usually completed during
process discovery and analysis. Detailed estimates are started along with playback zero
using user stories and continue to playback 1, where the estimate becomes more detailed
and thus, more accurate.
Images from WebSphere Lombardi Edition BPM Project Estimation, IBM, 2011.

Rough order of magnitude

The rough order of magnitude estimation takes into account the complexity of the project.
Is the project of low, medium, or high implementation complexity?
Items to consider during this estimation include:
• # of business processes
• # of nested business processes
• # of screens or coaches and their complexity
• # of variables
• # of rules and their complexity
• # of basic reports and scoreboards
• # of integrations
Images from WebSphere Lombardi Edition BPM Project Estimation, IBM, 2011.

Budgetary estimation
A budgetary estimate:
• Has a higher level of confidence
• Based on process footprint and general established functionality
• Number of anticipated or known BPDs, coaches, services, integrations, and
reports
• Makes assumptions around complexity and scope
• Low, medium, and complex values
• Can be done using distilled requirements
• Blueworks Live models (or other preliminary to-be process models) and analysis
from discovery workshop
Adapted from WebSphere Lombardi Edition BPM Project Estimation, IBM, 2011.

Detailed estimation
A detailed estimate:
• Depends on having a level of detail that is only available after playback zero is complete
and considerable work has been done to define user stories.
• Is constructed based on sized/ prioritized user stories
• Uses story points
• Has project elements refined/ updated with prototyping
• Has a clearer scope and uncertainty is lessened
Adapted from WebSphere Lombardi Edition BPM Project Estimation, IBM, 2011.

Exercise 3.1: Unit review and discussion

In this exercise, you will discuss the following topics with your instructor
and classmates. Please be prepared to answer these questions using your
current organization and experience as your guide.
If you are taking a self-paced version of this course and do not have an
instructor, listen to the discussion provided and think about how these
questions apply to your organization.
• What are some of the success factors and some of the warning signs
things aren’t going well when you are completing playbacks?
• What are three best practices for playbacks?
• Consider testing incrementally and compare that to the testing your

company currently completes on applications.
• Name the three types of estimation. Have you done any estimation
similar to these? Which one?

NOTES

Unit 4:The plan and Introduction

Now that you have learned about playbacks, you are ready to estimate projects.
implement phase,
This section of our course focuses on planning, estimation, and the methods you
part II can use to estimate projects.
Objectives
• Use rough order of magnitude to estimate a project
• Use a budgetary estimation to estimate a project
• Use detailed estimation to estimate a project
Topics
• Planning overview
• Budgetary estimate
• Detailed estimate
BPM Program Management 93

Planning overview
As you can see from the image above, estimation happens at many different times during
a BPM project, and not just in the plan and implement phase.
One initial item that occurs during the identify part of the discover and document phase is
assessment of impact and effort of the projects. This includes a process inventory where
the business process is selected for implementation. A business analyst will usually
complete this work and the process will be selected before the project manager is on-site.
As discussed in the previous unit, the next three estimates in the image are the core
estimations and include:
• Budgetary
• Detailed
A revised estimate is also included in the image to remind you to revise your detailed
estimates as the project continues. The revision should be completed at least at the end
of every iteration. When you revisit these estimates and adjust during a project, they will
become more and more accurate for that project.
Adapted from Scaling BPM Adoption from Project to Program with IBM Business Process Manager, IBM, April
2012.
94 Unit 4: The plan and implement phase, part II

Cone of uncertainty
When estimating, it is important to note that you can only estimate to a certain precision
based on the amount of details that are available. For example, when a rough order of
magnitude is completed, the man-weeks can be estimated. As user stories are completed,
we have story points. Finally, several weeks into implementation, we can estimate man-
hours left for a project.
It is important that the decisions made during managing a BPM project reflect the amount
of uncertainty at that part of the project cycle. You would not want to assume a precise or
accurate finding if the underlying data does not support that finding.
The image below gives us an idea of the amount of certainty during a project. Based on
research, early estimates are usually up to 4x either way. This means the scope might
be up to 4x larger or .25x smaller than the original estimate. Depending on company
environment and culture, this value can even be much larger than 4x.
2012.

Rough order of magnitude (ROM)

A rough order of magnitude is the first formal estimate completed in a project. It will
usually be completed before or during playback zero and might be used to determine the
purchase order for the project. A lot of the time it is actually completed by a sales person
before the project manager is on site. It can be used to determine preliminary staffing of
developers and also gives an idea of the length of the project.
Typically, each project will be close to a category of low, medium or high implementation
complexity. The following chart has a list of the criteria for each type of project. These
categories and numbers have been derived from examining years of projects.
Your project might be right in between the categories. Let’s say that the project falls
within the medium section on all attributes except it has around 250 process variables and
4 integrations. This makes the project a bit more technical in nature than a medium project,
so plan for a low end high complexity project. This type of project might take 14 weeks
and need 4 developers. Remember, at this point, the accuracy of estimation is not very
high. A rough order of magnitude estimate is only about 40% accurate. After you continue
estimating, you can trim the project down or scale up as needed.
This information can be gathered by interviewing the business or by examining various
requirements documents.
The rough order of magnitude is often used to construct a business case and justify a
project charter.
2012.

A second consideration when deciding the rough order of magnitude is how the project is
staffed. If the project resources are very experienced with IBM Business Process Manager
and its implementation, the project length and number of developers will be matched as
indicated in the rough order of magnitude chart.
On the other hand, if developers and consultants used in the project are new to IBM
Business Process Manager and do not have as much experience as IBM consultants, the
project will take more time.
The bar above the rough order of magnitude chart shows this relationship and sort of
acts as a multiplier. As the yellow diamond moves to the left and uses more customer
resources and less IBM resources, the project length of construction will be longer.
2012.

Exercise 4.1: Estimate a project using rough order of

magnitude
Although the project manager role might not actually be completing the
rough order of magnitude, it is important to know exactly how it was
created. This exercise will take you through creating a rough order of
magnitude.
If you are taking the WB004 course, your instructor will act as the process
owner and you can ask as many questions as you like to determine what you
need for the rough order of magnitude.
If you are taking the ZB004 course and therefore do not have a live
instructor, listen to the recording of the process discussion and determine
the rough order of magnitude. After you are done, proceed to the next slide
to see a completed example.
The PDF titled Rough Order of Magnitude will provide you will a printable
chart to complete this exercise.

NOTES

Budgetary estimate
A budgetary estimate is completed during process discovery and analysis, the beginning of
the playback zero iteration. The budgetary estimate is slightly more confident than a rough
order of magnitude at a 55-65% level.
Sometimes a company will request a budgetary estimate earlier in the project because
a rough order of magnitude may not be enough for them to make procurement and
budgeting decisions.
This estimate is done using process diagrams from Blueworks Live or a similar process
diagramming tool. At this point, not all details of implementation are known, but the
diagram should be fairly complete with all placeholders noted for development. An
example of this type of diagram is a to-be process with the integration points noted where
applicable.
A project manager and solution architect or sometimes a business analyst are typically
involved in verifying and completing this estimation.
Assumptions
When completing the next estimates, assume the following points:
• The estimates should assume Business Process Manager developer technical

proficiency by an individual at the level of ‘1 year of Business Process Manager
development consulting experience’ or ‘at least 2 projects successfully executed’
• The term ‘development’ includes design, development, and unit testing for each
function identified in the estimate
• All estimates should assume that ‘out of the box’ product functionality will be
leveraged for all development, unless specific exceptions are called out and sized
individually
• The assignment of complexity as low, medium, and complex against any development
items is typically the level of granularity sufficient to estimate the item to a reasonable
level of accuracy
• Estimates assume that the business process diagrams are mostly complete and
placeholders have been established for the areas requiring development
• If certain functionality is not explicitly stated, it’s probably not taken into consideration
in the estimate
2012.

Misguiding with this estimate
If a company does request a budgetary estimate for more information earlier in a project,
make sure there is enough data to create the estimate with at least the amount of
accuracy indicated. For instance, you should not complete a budgetary estimate based on
an as-is process or with a process that does not have integrations noted. This type of early
estimation can cause more harm than good. Often the very high degree of uncertainty is
not communicated well enough to the business.
Where to start
The budgetary estimate starts as the rough order of magnitude estimate does, a similar
inventory of the solution elements:
• Business process definitions (BPDs)

• System and human activities (process steps)
• Coaches (screens)
• System integrations
• Key performance indicators (KPIs) and service level agreements (SLAs)
• Scoreboards and reports
With this estimate though, we will detail every single item and estimate its complexity
was low, medium, or high. For instance, if the process has an activity, Submit Form, this
activity will be marked as low, medium, or high.
Other time considerations

As you have been through this course, you might have realized that there are other time
considerations for a project besides development time. Participating in playbacks and other
tasks takes up project time. These sorts of tasks are also included in this estimate. Some
normal occurrences to allow for in a BPM project are:
• BPM analyst time for process analysis
• BPM solution administrator time for deployment planning and deployment
activities
• BPM solution administrator time for environment topology design and
installation of IBM Business Process Manager
• BPM project manager time for project management
• BPM developer time for troubleshooting and prototyping integration to new
systems
• Team time planning and delivering Playbacks
• SME time for iteration planning, commitment, and acceptance
• SME time for user acceptance testing
2012.

Pessimistic and optimistic multipliers
When we are creating a budgetary estimate to charter a new project and attain funding, it
is important to recognize the uncertainty in the estimate as previously discussed. We do
this using optimistic and pessimistic multipliers to give us a cost range in which the project
will most likely fall. These multipliers enable us to plan a project budget, schedule, and
staffing plan with contingency recommendations.
The technique we use can be traced back to Program Evaluation and Review Technique
(PERT) analysis and Critical Path Method (CPM). Historic data on estimating projects
suggests that we are more likely to under-estimate than we are to over-estimate. An
optimistic multiplier ranges between 0.5 and 0.75 whereas a pessimistic multiplier ranges
between 1.5 and 3.
Use multipliers that match your confidence in the amount of uncertainty. This means
that if our budgetary estimate is 1500 hours and we are confident in that we have a fair
understanding of the level complexity and uncertainty, we use an optimistic multiplier
of 0.75 and a pessimistic multiplier of 1.5. Our budgetary estimate gives us a 55-65%
confidence interval that implementation will fall between 1125 hours (0.75 x 1500) and
2250 hours (1.5 x 1500).
2012.

Calculating an estimate
With statistical analysis we can use the standard deviation of a PERT distribution to
calculate an estimate for planning purposes. The PERT distribution uses most likely,
optimistic, and pessimistic values. A PERT+n estimate for calculating length of effort is
calculated as follows:
PERT+n = average + n standard deviation

where:
average = ((4 most likely) + optimistic + pessimistic)/6
standard deviation = (pessimistic - optimistic)/6
Using an example project with rounded values from 1100 and 2300 hours of
implementation then:
average = ((4 x 1500) + 1100 + 2300)/6 = 1567

standard deviation = (2300 - 1100)/6 = 200
PERT+0 = 1567 + 0 x 200 = 1567
PERT+1 = 1567 + 1 x 200 = 1767
PERT+2 = 1567 + 2 x 200 = 1967
A PERT+0 estimate is very close to the most likely estimate and is appropriate for planning
a project without contingency (i.e. 50% probability based on normalized data). The PERT+1
value is used for planning out a project with contingency (i.e. 68% probability of falling
within one standard deviation). The PERT+2 value is used for budgetary procurement (i.e.
90% probability of falling within two standard deviations) and assumes change as part of
the effort.
NOTE This doesn’t mean you should propose funding and schedule around the pessimistic
implementation estimate (2300 hours in the previous example). You might seek budget for
a rounded PERT+2 value (like 2000 hours) and prepare to actively manage scope to keep
the project within schedule and cost constraints planned closer to 1800 hours, saving 200
hours for additional implementation cost and schedule contingency.
2012.

Logistics of a budgetary estimate
The budgetary estimate is in the form of a spreadsheet so you can use any spreadsheet
program to open the file and fill in the values. The spreadsheet contains several different
worksheets or tabs.
Each tab will be described on the next two pages.
BPM
This tab contains all of the artifact information and the estimates of high, medium, and
low. The following pages after this list will explain how to estimate if these items are high,
medium, or low. Sometimes a company might work on two processes in parallel. If this is
the case, you should have one tab BPM1 and another BPM2. In this course, we will just
use the BPM1 tab.
ADV
This tab contains the information for estimating using Business Process Manager
Advanced. This type of estimation using Advanced has not been done as many times as
the other types of estimations so this area is still improving.
PS
This tab is for shared work outside of development that is completed by the business
analyst, process developer, and technical consultant relating to playbacks and other items
such as the portal.
PD
This tab is for work completed by the business analyst, process developer, and technical
consultant, but is relating to deploying a process including setting up environments and
testing.
PM
This tab has hours for project management provided by the project manager, the process
developer, and the technical consultant.
PSUM
This adds all the hours from the previous 5 tabs and also shows days. It also calculates the
most likely, optimistic, pessimistic, standard deviations and average.

Timeline
This is where you fill in the resources for the most likely, optimistic, and pessimistic to
calculate the schedule.
Proposed
This tab is the final tab that you show and discuss with the business it has the final
statement of work suggestion as well as the budget suggestion, currently set at PERT +1.
Comments
This is used for comments, and one typical use is to use it to keep track of future iteration
work.
NOTE It is important to note that this spreadsheet is improved over time. Future iterations will
have rules and additional estimation tools for IBM Business Process Manager Advanced.

Low, medium, or high?

The following sections provide ranges for the level of effort required given characteristic
levels of complexity. When applying these ranges, use the higher end of the range when
dealing with high levels of uncertainty. This should be used for the 5 main tabs that total
together for the PSUM tab.
Business process definition (BPD)
The characteristics that affect the level of effort to construct a BPD are as follows:
• Number of activities (milestones, sub-processes, tasks)
• Number of decisions (splits, joins, gateways)
• Number of events (start/end, timer, message, exception)
• Number of participant groups (swim lanes)
• Number of user stories documented in the activities
BPD development work includes the creation of BPD artifacts in Process Designer and all
of the configuration of the swim lanes, milestones, events, and activities in each BPD. This
does not include the development work to implement the activities or events with human
services, decision services, or other service development in Process Designer. The range
in development effort (measured in man-days) required for BPDs of low, medium, and high
complexity.
When estimating the overall complexity of a Business Process Definition (BPD), you need
some level of detail as to the underlying complexity. The table illustrated here characterizes
BPD complexity as number of steps, decisions, events, and participant groups. The
number of steps includes process milestones, sub-processes, and tasks. Decisions and
events include any decision gateway or split on the process diagram. Events include start/
end events, message events, timer events, and exception events.
It helps to assess the relationship between events, gateways, and steps in the process
model to get an idea of the number of valid pathways through the process. Is there a clear
happy path and a small number of exception paths? Or are there several dozen paths and
loops in the process diagram? The latter case may have a high degree of uncertainty or a
lot or process complexity and should be reflected in your estimate.
Adapted from Project Estimation & Program Scoping: AIM BPM Planning, Guy Lipof, IBM, April 2011.

Coaches and services

Coaches are the user interface screens that allow a human user to participate in a process.
Coaches display process data (simple and complex variables) to users as well as accept
input from the user. Users can enter data fields into coaches or take action by clicking
buttons or other web form controls. There are a number of factors that influence the
complexity of a coach including the relative number of data elements and number of
actions a user can take on a given coach. Form field validation on the coach also influences
level of effort required to finish implementing a coach.
In the case of a non-coach service, there are a series of considerations.

Reports
In order to properly estimate the level of effort required for sizing a single scoreboard, a
series of information needs to be defined.
• Does a report require multiple sub queries to produce?
• With what frequency do reports need to be refreshed in the UI?
• Is there any need for static reports?
• Are there chart types or visualizations that we don’t know how to produce?
• Is the data being captured / readily available?
Collecting information from questions like the above will better help you break down the
complexity of reports.
The above does not include ancillary functionality like:

• Multiple reports per scoreboard
• Filtering and drill-downs
• Events/Alerts based upon scoreboard results

Data persistence and business data system of record (BSOR)

It often happens that data persistence and creation of a business data system of record
is overlooked during early project estimates. Whether or not a business data system of
record is needed may not surface until more details are known.
This is a good topic to ask during process discovery and should be accounted for in a
budgetary estimate. Here are some questions that can help during early phases of a
project.
• Is there an existing (legacy) business data system of record (BSOR)?
For many processes, there already is a system (or multiple systems) that are
the “source of truth” for business data. Examples of business data may include
customer records, invoices, purchase orders. In our sample scenario employee
records are maintained in an “HR Database” that serves as the BSOR. For
some processes, business data has no formal (or governed) system of record.
The business data may exist in email, excel files, or a shared drive. Asking a few
questions early can help expose what may be a significant impact to the budgetary
estimate.
• For each business entity identified in process discovery, where is that information
stored today?
• If there is a BSOR, do other systems integrate with the BSOR today? If yes, how?
• Has there been mention of needing a “custom database” for business data? If we
need to create a BSOR, do other systems need access to this data?

System integrations
Implementing a BPM solution will typically require integration with other systems within
the enterprise (including LDAP, ERP, or other operational data stores,...). BPM provides a
framework and tools that make these integrations as painless as possible. In general for
integrations we use the following to determine the amount of work.
• The number of systems to which to integrate
• The manner of the integration
• The number of integrations per system
In general we plan 1 day per integration point and an additional 5-15 days per system
(providing that direct access can be provided and no prerequisites need to be worked).
Factors that affect this type of effort include the following:
• The first integration to any given system can double the days to get done. We call
this the “Handshaking integration”
• Does the integration already exist in IBM Business Process Manager? (If yes,
lower the estimate)
• Does the integration already exist for another system? (If yes, lower the estimate)
• What is the number and complexity of the data elements? (The more elements
and complexity, the higher the estimate)
• Can we realize efficiency? (the 100th integration of the same type should take
significantly less time than the first)
• If the integration team is using IBM Business Process Manager to unit test their
integration time increases
• This time does not include the creation of the integration on the external system
• Java API integrations typically add 50% overhead, more for ones dealing with
binary data (document management for example)

Other considerations
Other elements that should be considered when sizing and scoping a project include the
following:
• Regulatory compliance
• BPM governance
• Policy regarding testing and change control
• Infrastructure considerations
• Customizations to the BPM platform to support the deployment
• Notifications / escalations
• Non-process deliverables - functionality not in the process tasks, like maintenance
screens, search capabilities

Exercise 4.2: Complete part of the budgetary estimate

Creating a budgetary estimate takes quite a bit of time, more than is
allowed for in this course, but we still want to have some experience
estimating different items.
For this exercise, you will use the spreadsheet file to complete a small part
of estimation on the BPD tab or worksheet.
The rest of the tabs are filled out with the information from this project
corresponding to the course’s process.
Look at the requirements and ask any questions you have of the instructor
if you are in WB004. If you are in ZB004, you will hear another recording
that will give you more clues on how to complete the budgetary estimate.

NOTES

Detailed estimate
A detailed estimate is created at the end of playback zero. At this time, the user stories
discussed in previous units should be completed and ready for this estimate. The detailed
estimate assigns story points to these user stories.
The detailed estimate should be revised at the end of every development iteration. As the
project progresses, and the cone of uncertainty narrows, we can apply a narrower ranges
of uncertainty. If we continue to use PERT, we might apply a PERT+1 or PERT+2 for earlier
iterations and move to PERT+0 in later iterations.
As we drill down in the granularity of what we are estimating, we have more detailed
knowledge of solution artifacts and scope. Our estimates improve in both accuracy and
precision. We use different measures at different levels of granularity.
The project manager completes the detailed estimate with point values estimated by a
developer. It is important to use more than one developer to do these point assignments
as a group of developers has varied experiences in implementation. Using a group of
developers, you can get a more accurate estimate of the story points.
2012.

Ways to assign points

As the development team reaches consensus on points they will think about the various
solution components the user story requires. Design considerations and questions should
be documented as notes or comments on the user story to provide justification for the
estimate and provide useful information to developers during implementation.
Teams use story points differently, but the two most popular ways to measure with story
points are either on a scale of 1 (low effort) to 10 (high effort) or a Fibonacci sequence
(0,1,2,3,5,8,13,21,34,55). The Fibonacci sequence is useful in that it reflects the manner in
which uncertainty (vagueness) plays a part as the story gets bigger and more complicated.
Both methods have pros and cons. It is important is that you chose a method that works
for you and your team knowing that you can modify later if it is not working.
When estimating story points, the team should take into consideration three concepts:
• Level of effort
• Level of complexity
• Level of uncertainty
Epic user stories, ones that are generally larger than 21 if using the Fibonacci method,
should be broken down into smaller stories. Large stories often contain too much
information to estimate accurately.
Measuring team velocity with user story points

User story points are relative in the sense that two user stories that have the same story
point value should be relatively the same size. This does not mean that two stories of
the same point value should consume exactly the same amount of development hours.
We can have two user stories of the same estimate but one could be very complicated
and low effort while the other could be very high effort but low complexity. The user
story points help us measure scope so that we can plan releases and iterations. After
completing several iterations with the same team, we will have a good measure of the
team’s velocity in story points. This measure is key to planning the scope achievable in
future iterations and releases.
Hours worked in a given day: Do not assume developers will complete 8 hours of
development tasks each day. These estimates are for actual development effort and do not
include time spent presenting mini-playbacks to process owners, collaborating with SMEs,
building prototypes, attending meetings, creating documentation, etc. Research suggests
that experienced developers maintain an average of 6.5 hours of development work
each day. Developers with less experience, user stories with more ambiguity, and tasks
involving high complexity will further reduce the hours of work completed in a day.
2012.

Prioritizing user stories

The process owner and process participants or subject matter experts are responsible for
prioritizing user stories. This priority helps the process owner work with BPM developers
during iteration planning to identify which stories to add to the iteration and work on first.
When getting started prioritizing the backlog, it helps to simplify the view and arrange
stories into three groups: high, medium, and low. Give each user story a priority indicating
the business value the user story represents in correlation with corporate and project
objectives.
The following are some additional considerations:

• If arranging into 3 groups, aim to distribute evenly: Top 3rd, Middle 3rd, Bottom 3rd. It
will not be helpful if more than 50% of all user stories are High priority.
• Prioritize user stories without regard to size. Try not to let the size of a story artificially
influence priority.
• For Epic stories that are medium or high priority, break them up into sub-stories and
prioritize each.
• If the user story does not have clear and transparent business value, or business
impact, ask the process owner and user story owner (SME) to finish writing the story
before setting priority.
2012.

Planning, committing, and accepting iterations with user story points

The process owner collaborates with the development team to plan iteration themes
and load iterations with user stories. We use story points to measure scope so that we
can schedule resources that align with the duration of the iteration. After loading an
iteration with user stories, BPM developers review the user stories and define work items
(development tasks) for each user story. This activity is collaborative as developers rely on
the user story owners to answer questions, provide examples, and elaborate on the details
needed to start implementation.
After all user stories have development tasks estimated in hours, the team collaborates
again to verify that the estimated hours fit in the scheduled duration of the iteration and
resource plan. If the iteration is overloaded, process owners remove user stories based
on priority until the iteration fits the resource schedule. At this time, the process owner
and development team commit iteration. Upon completion of all development tasks for a
user story anytime before the iteration end, the process owner accepts the user story as
completed. Once all user stories are accepted, the iteration is accepted.
Estimating development tasks with hours

The developers (and only developers) are responsible for estimating the hours needed to
complete each development task. A best practice recommendation is that no development
task should be more than 8 hours. Some teams prefer to use a Fibonacci sequence
(0,1,2,3,5,8) for tasks. Tasks larger than 8 hours should be further broken down into
multiple tasks, or sub-tasks. Tasks larger than 8 hours leave too much room for uncertainty
due to ambiguity or variability due to unplanned events or risks.
Another best practice recommendation is for developers to update the estimated hours
remaining on their tasks daily. If the work remaining increases due to new knowledge or
unforeseen events, the risk is immediately visible in the iteration burn-down chart and the
team can react accordingly.
NOTE It is very common for teams new to agile to try to correlate story points with hours. It will
be very tempting to do this. Please resist this temptation! Creating a correlation between
points and hours not only invalidates the benefits of planning in points, but it also assumes
that you have a development team with homogeneous experience and expertise. If you
have a Level 3 developer and a Level 1 developer on the same project, they will each a
different number of hours to complete development work for a 5 point user story.
Use team velocity instead. Team velocity is measured in story points accepted per
iteration and should be based on historic team performance to include the most recent
4-6 iterations (teams improve velocity over time). We can apply a range to our estimates to
include optimistic, most likely, and pessimistic values when planning releases or iterations.
2012.

Logistics of a detailed estimate

Similar to the budgetary estimate, the detailed estimate originally uses a spreadsheet to
come up with the values. The spreadsheet should then be imported into a Agile project
management tool for tracking. This allows you to keep track of user stories and commit
them each iteration.
A few of the worksheets or tabs are the same as the ones from the budgetary estimate.
Stories
This is where user stories are kept along with their priority, points, category, and details for
implementation.
PS
This tab is identical to the one in the budgetary estimate. This tab is for shared work
outside of development that is completed by the BPM analyst, BPM developer, and
technical consultant relating to playbacks and other items such as the portal.
PD
This tab is identical to the one in the budgetary estimate. This tab is for work completed
by the BPM analyst, BPM developer, and technical consultant, but is relating to deploying a
process including setting up environments and testing.
PM
This tab is identical to the one in the budgetary estimate. This tab has hours for project
management provided by the project manager, the BPM developer, and the technical
consultant.
PSUM
This tab is similar to the one used in the budgetary estimate, but uses the story tab for
more accurate numbers. This adds all the hours from the previous four tabs and also
shows days. It also calculates the most likely, optimistic, pessimistic, standard deviations
and average.

Timeline
This tab is similar to the one used in the budgetary estimate, but uses the story tab
for more accurate numbers. This is where you fill in the resources for the most likely,
optimistic, and pessimistic to calculate the schedule.
Proposed
This tab is similar to the one used in the budgetary estimate, but uses the story tab for
more accurate numbers. This tab is the final tab that you show and discuss with the
business it has the final statement of work suggestion as well as the budget suggestion,
currently set at PERT +1.
Comments
This is used for comments, and one typical use is to use it to keep track of future iteration
work.
JazzImport
This tab is specifically formatted for importing into the Agile tool, IBM Rational Team Con-
cert.
NOTE It is important to note that this spreadsheet is improved over time. Future iterations will
have rules and additional estimation tools for IBM Business Process Manager Advanced.
At this point, you can estimate items completed in Integration Designer with user stories.

Exercise 4.3: Complete part of a detailed estimate

Most of the detailed estimate has already been completed for you.
In this exercise, you will use the detailed estimate spreadsheet.
Listen to the following conversation between a group of developers
and complete two rows of the detailed estimate spreadsheet for the
corresponding user stories.

NOTES

Unit 5:The Introduction

The last two stages of the process life cycle are the deploy phase and the measure phase.
deploy phase It is important to understand how each layer within the deploy phase functions and the
and the responsible parties for execution within these layers.
In the same manner that process definition and implementation are key pieces of BPM,
manage phase it is also important to monitor and track business processes once deployed. This is
accomplished in the manage phase of the BPM solution life cycle. Over time, processes
should be measured for KPI and SLA compliance. The end result of the manage phase is
ongoing process improvement and optimization.
Objectives
• Describe the multiple layers that make up the deploy phase
• Conduct a project retrospective
• Describe the two main purposes of the manage phase
Topics
• Deploy phase overview
• Project retrospectives
• Manage phase overview
• Business activity monitoring (BAM)
• Process improvement

Deploy phase
Overview
Key Outcomes:
• Built-in visibility to current process status and resource utilization
• Standardization of work management practices within and across functional teams
• Standardization of control over your business operating model
Deployment
Input
• Defined solution from the implement phase
Activities
• Develop deployment rollout schedule
• Deploy final release into production
Output
• Final solution release
• Production rollout plan
Tools
• IBM Business Process Manager, spreadsheet program, Agile project tracking tool
124 Unit 5: The deploy phase and the manage phase

Deploy phase layers

The deployed process is made up of operational layers. They are as follows:

End-user environment
Description
Covers end-user computing environment, which could include
the Process Portal, Business Monitor, or a custom portal
Owners
Typically a mixture of project team and deployment-oriented
staff
Responsibilities
• End user support
• End user training
• Help desk – issue capture and diagnostics
Skill sets
• Process familiarity
• Environment expertise

Web server or load balancers
Description
Provides a layer of abstraction for end-users that allows better
systems management and availability or redundancy
Owners
Typically managed by infrastructure team
Responsibilities
• Configure and maintain proxying and load balancing
• Manage static assets
• Support hardware and OS
• Monitor server availability
Skill sets
• Web server or load balancer technology
• Architectural understanding

IBM Business Process Manager solutions
Description
Includes process solution(s) that are built using IBM Business
Process Manager
Owners
Typically BPM project team members
Responsibilities
• IBM Business Process Manager process development and
support
Skill sets
• IBM Business Process Manager process development
• IBM Business Process Manager end-user interaction
understanding

IBM Business Process Manager platform
Description
Includes the Process Center, Process Servers, and Business
Performance Data Warehouse servers of Business Process
Manager
Owners
Typically a combination of project team members and
infrastructure specialists
Responsibilities
• Business Process Manager configuration and tuning

• Monitoring system availability
Skill sets
• Business Process Manager administration and operation

Application server clustering
Description
Covers WebSphere Application Server, providing resources
such as connection pools and clustering
Owners
Typically the infrastructure team
Responsibilities
• Application server configuration and tuning
• Hardware and OS support
Skill sets
• Application server expertise

IBM Business Process Manager databases
Description
Covers databases used by Business Process Manager (Process
Server/Process Center DB and Business Performance Data
Warehouse DB)
Owners
Typically the infrastructure team
Responsibilities
• Database server configuration and maintenance
• Database instance configuration and maintenance
• Hardware and OS support
Skill sets
• Database platform expertise

Business systems of record (BSOR)
Description
Covers external databases used by the process solution and
the interfaces used by Business Process Manager
Owners
Typically the team that owns the systems of record
Responsibilities
• Management of the systems of record
• Monitoring of availability
Skill sets
• Systems familiarity

Project retrospectives
What is a project retrospective? It is a review of project development performance. The
focus is not on blame for problems, but on how to improve the process now and in the
future.
Throughout the project, the retrospective is used as a tool for process improvement and
quality assurance. Although retrospectives are conducted during a project at the end of
each playback, after deployment a more thorough session is conducted.
Continuous reflection and improvement are the keys to success in project execution,
especially with iterative projects like a BPM project.

The four questions

Regardless if it’s an end of project retrospective or one conducted at the end of a playback,
use the following four questions to drive the session:
1. What did we do well, that if we don’t discuss we might forget?
2. What did we learn?
3. What should we do differently next time?
4. What still puzzles us?
Retrospectives at playback
A quick retrospective (about 1 hour in length) should be conducted after each playback to
adjust course for the next iteration. Allow each team member to address what went well
and what needs improvement for the next iteration.
The retrospective doesn’t do any good unless you change behavior; assign team members
action items for implementing the ideas that come out of the retrospective. Add each of
the assignments to the backlog to track execution.

End of project retrospective

A more thorough retrospective is conducted at the end of the project. This takes more
advance planning. The retrospective may last from a few hours to half a day or more,
depending on how big the project was.
Have the team decide on the ground rules, things such as: don’t interrupt, turn off cell
phones, don’t text or e-mail during the discussion.
Start by having everyone discuss the timeline. One option is to use a long piece of craft
paper and draw the timeline, complete with milestones and memorable events. This
activity helps everyone recall the events of the project.
Next, post the 4 questions or project them on a screen. Pass out note cards and pens.
Have everyone start writing their responses on the cards and posting them to a wall. Then
have the team as a group organize the ideas around themes. When this is done, give each
theme a title. Have the team vote on the specific theme or themes they want to focus on.
Have in depth discussions on these selected themes including root causes, possible
solutions, select a solution and come up with concrete action items as follow up for after
the meeting. If this was done as multiple groups, have each group report back to the team
as whole. Capture action items and wrap up with a review of them. Follow up with e-mail
to distribute the information from the meeting.

Exercise 5.1: Project retrospective

Based on what you have learned so far, use the methods and questions of
the project retrospective to turn a critical eye on this course. Make a plan
with action items of what you will do with what you’ve learned so far.

Retrospective activities
• Set the ground rules
• Review project timeline and major milestones
• Brainstorm/affinity diagramming on four questions
• Use note cards
• Post ideas on board
• Group similar ideas
• Decide on one or more themes to focus on
• Conduct in-depth discussions

• Go into detailed root-cause analysis
• Have assigned follow-up after the meeting to improve process area
• Document the results and distribute
• Follow up on action items

Manage phase
Overview
Key outcomes:
• Real-time measurement of service level and business productivity goal attainment
• Built-in analysis of historical process trends and simulated impacts of proposed
changes
• Align improvements around quantifiable impact business process performance
Two main purposes:

• Identify and proactively intervene in current problems or potential problems in
processes (Business activity monitoring or “BAM”)
• Collect and analyze historical process performance data for use in identifying and
simulating potential process improvements
Tools:
• IBM Business Process Manager Optimizer, reports

Business activity monitoring (BAM)

• Real-time business intelligence
• Process Events
• Correlation
• Escalations
• Goal of zero information latency
• Used to drive continuous process improvement

Visibility
An important thing we do for our organization is provide a way to get a complete and
real-time view to how the business is performing. When we say visibility, we mean much
more than delivering “reports”:
• Ability to combine data you might have today with process data that you can’t get
today (example: projected vs. forecasted)
• Ability to act on this data by delivering proactive alerts, notifications when problems
arise or thresholds are exceeded
• Ability to not only be shown where the bottlenecks are today but also have a way to fix
them: by changing business parameters, or by knowing what to ask for from IT & how
to prioritize those requests
In fact, rather than beginning by automating parts of the process, some of our
organizations decide to start by implementing scoreboards that give them the visibility
they need to determine where the biggest gaps are and which changes will have the
biggest positive impact on their business.
Example: Improving cycle times with workload balancing
One way to improve operational effectiveness is by improving cycle time through dynamic
workload balancing. This capability lets operations managers make sure workload
bottlenecks are addressed as soon as they arise.

In our example, an operations manager would monitor a scoreboard that tracks workload,
and periodically drill down to look for bottlenecks.
In the drill down example provided, the post close stage of the process is well over is
threshold of 20 days.
Because of this visibility, the operations manager now not only knows where the problem
lies, but has a way to do something about the problem.

Real-time reports: Task monitoring

Real-time reports available are centered on task monitoring. Task monitoring is
accomplished by the using the define task report templates:
• Search tasks by user/role, type, priority, category
• Reprioritize, re-categorize, reassign
This monitoring allows you to understand individual performance plus process
performance and be able to act.

Real-time reports: Process performance

Once you define the tasks you want to monitor, by drilling down on each data point, you
can access the process performance data through the standard task report templates.
• How many instances of each task? Drill down to individual instances
• How long are task durations (automatically calculated)?
Drill down and compare to simulation data, last weeks data, last months, or last years
data.

Process improvement
You might have noticed that at the same time the manage stage is happening, the
optimize phase begins and feedback from optimization and the project retrospective is fed
back into the next planning for the following release of the process application.
Overview
Historical process performance data is collected and can be used to identify trends,
bottlenecks and problem areas.
Executive sponsors and process owners need to understand the need to plan for and
execute on the ongoing governance and program-related activities of the measure
stage. Processes can be designed to monitor themselves, but only people who have the
responsibility to do so can decide what use to make of that information.
BPM projects may end when everything is deployed and the retrospective is done, but to
deliver value the program must be designed to live on and take responsibility for ongoing
improvement. Much of the value in a BPM effort is wrapped up in this area.

Although the manage phase is at the end of the solution life cycle, this does not mean
you should wait to discuss reports and optimization at the end of a project. Have these
discussions early and often during development.
For example, if a certain business data is needed and the future of the project involves
using the Optimizer of Business Process Manager, the data needs to be tracked early and
set up correctly on the production server to display in this tool.

Unit 6: Project to Introduction

program A “program” is defined as a durable initiative intended to produce a valuable business
outcome consistently by coordinating the governance, infrastructure, resources, and
strategic alignment of multiple processes and projects. BPM program management
governs multiple projects concurrently or in a planned prioritized manner.
Objectives
• Identify the program management relationship
• Describe the key activities in program management
Topics
• The BPM journey
• Managing a BPM program

The BPM journey

Often the goal of an organization is to move past validation of BPM and the first BPM
project to acceptance of BPM as a strategic tool, and ultimately, business transformation.
At some point, the focus will be on enabling your organization to complete BPM projects
on their own without as much outside assistance. This transformation carries risk and
many people believe that this curve is shaped a bit differently, but it is important to notice
that risk is still inherent in the transform stage. You can mitigate this risk slightly with
resources and training, but ultimately there will still be a slight talent gap.
In this journey, is where moving from a single BPM project to a BPM program begins.
148 Unit 6: Project to program

Resources
In order to successfully deploy a BPM program, the right resources must be available and
trained. When selecting projects for execution, verify that resources are available to work
the projects. Are there enough technical resources to support all the projects going on?
Don’t forget about hardware/software. When a new process is deployed, will it impact
performance?
Communication
Communication is critical so that the correct decisions can be made. Program level
reports should be compiled from data for each project. Risks should be identified and
communicated across the program.
Training
Prepare
• Build awareness
• Identify skill gaps
• Assess readiness
• Understand perceptions of impact
Develop training plan

Choosing processes
To initialize your program, it takes that first project. Not all processes make good
candidates for business process management. A good program management approach
will screen out those processes that aren’t good candidates. Building a process inventory
and selecting the right projects is one key for success.
What makes a good BPM project?
• Significant human to human and human to system interactions
• Processes with long timelines from start to finish
• Paper based processes: Fax, spreadsheet, e-mail
• Need for performance data
• High reliance on subject matter experts
• Manual work-arounds
• Long training/ramp-up required
• Business process needs change faster than IT processes can keep up with

Project prioritization
An organization must determine what criteria are important to it when evaluating
processes. Using these criteria, the organization prioritizes the projects that are
identified in order to determine which one to work on first. Make sure to align criteria
with strategic objectives and goals.
Example criteria
• Process errors causing revenue loss
• Inefficiency is causing additional cost or headcount
• Rework required
• Unsure of steps for process improvement
• Low customer or employee satisfaction
• Losing opportunities to more responsive competitor
• No audit trail
• IT not responsive to business needs

Managing a BPM program

How do you turn your project into a successful program?
One key is to balance solutions with achievable scope.
The following is an example of how more than one project is implemented at a time, along
with a suggested training plan.
Here is where we are after our first project:

At the end of the first project, during the test cycle, the program is starting to be defined.
An improvement of the first project is started and implementation mentoring is used to
enable the organization.
A process inventory and selection is completed with analysis mentoring. A program

mentor is also included in this stage. After selection, a second project, Process B is started
concurrently with the second release of process A.

BPM awareness and managing change is a large part of a program to progress toward
transformation. Process A will continue to go through improvement cycles as Process B
finishes and also goes into an improvement cycle. Performance benchmarks, tuning and
capacity planning are also very important in a program and should not be overlooked.

It is important to note that your program can be started at either place indicated in the
diagram. Some organizations start with a process inventory of all processes and then
continue down the path, while others prefer to complete a first project and then complete
the process inventory and selection.
NOTE For more information on the project to program transformation, read the redbook, Scaling
BPM Adoption from Project to Program with IBM Business Process Manager, referenced
in the introduction of this course guide.
Also, watch for the next WebSphere Education course in this series, BPM Program
Management, which will be developed in the future.

Appendix Term Definitions

Process
A set of activities that takes specific inputs and converts them into specific outputs in a
defined, predictable fashion.
Project
A unique effort to produce a specific set of deliverables within a defined timeframe and
budget.
Program
A durable initiative intended to produce a valuable business outcome consistently by
coordinating the governance, infrastructure, resources, and strategic alignment of multiple
processes and/or projects.
Business process
A process that occurs within a business enterprise to produce outputs that contribute to
business value.
Business process management system (BPMS)

A technology platform for performing BPM in an automated, interactive manner.
BPM program
A program that uses BPM tools and techniques to deliver continuous process
improvement.
IBM Business Process Manager

A Business Process Management System (BPMS) from IBM.
IBM Blueworks Live

A web-based, hosted process discovery tool from IBM that integrates with IBM Business
Process Manager.

ESSENTIAL BPM Capabilities

What are considered the essential BPM capabilities?
Modeling
Simulation &
Optimization
Workflow
Business
Rules
Business Data
Management
158 Appendix
ESSENTIAL BPM
Human Interfaces
Event Monitoring
System Integration
Metrics
Analytics

BPM SOLUTION LIFE BPM ssolution life cycle history

CYCLE
• Iterative Waterfall, “The Playback Method” (2001-2004)
• Iterative development
• Agility through playbacks, mid-development changes
• Introduce the business to the IT process
• Lombardi Implementation Framework (2004-2007)

• True iterative development
• Alignment of Lean Sigma process disciplines
• Leverage modeling and measurement capabilities
• The Delivery Methodology (2007- )

• Process definition emphasis for best results
• Persistence in having the conversation for ‘optimum value’
• More verification and validation throughout
160 Appendix
References
Reference material that explore topics discussed in this course are listed below.
If any difficulties are experienced locating the articles, please contact WebSphere
Education.
• Scaling BPM Adoption. From Project to Program with. IBM Business

Process Manager, Lisa Dyer, Flournoy Henry, Ines Lehmann, Guy Lipof,
Fahad Osmani, Dennis Parrott, Wim Peeters, Jonas Zahn, March 2012.
http://www.redbooks.ibm.com/redbooks/pdfs/sg247973.pdf
• Project Estimation & Program Scoping: AIM BPM Planning (white paper),
Guy Lipof, February 2011.
https://w3-connections.ibm.com/wikis/form/api/library/b2baa896-
5fc4-4244-a82e-926c5c930659/document/99c5f50b-6bbb-4c8b-be09-
f266c2381056/attachment/d3720f50-58c0-42cb-a89c-93d686a8e87c/
media/AIM%20BPM%20Estimation%20and%20Scoping.docx
• WebSphere Lombardi Edition BPM Project Estimation slide show, IBM.
• Authoring Processes with IBM Business Process Manager
http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r5m1/index.
jsp?topic=%2Fcom.ibm.wbpm.main.doc%2Fic-homepage-bpm.html
• “Maximizing the Payback of Playbacks”, Sean Pizel, Sr. BPM consultant
(PDF)
http://wiki.lombardi.com/download/attachments/15958169/BPM-Playback-
WP.pdf?version=1

BPM Proj MNG PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

BPM Proj MNG PDF

Загружено:

Авторское право:

Доступные форматы

BPM Project Management

(Course code WB004/VB004/ZB004)

IBM WebSphere Education

April 2012 edition

© Copyright International Business Machines Corporation 2012.

Unit 1: BPM project overview 5

Unit 2: The discover and document phase 37

Unit 3: The plan and implement phase, part I 63

Unit 4: The plan and implement phase, part II 93

BPM Project Management iii

Unit 6: Project to program 147

Introduction Course overview

• Business process management (BPM) - A review of BPM, focusing on BPM

• BPM solution life-cycle overview - A high-level discussion of the four phases

• Project to program - A high-level look at how to start moving from project to

BPM Project Management 1

COURSE OBJECTIVES • Describe the process life-cycle project management phases

RESOURCES IBM Blueworks Live

IBM WebSphere Lombardi Edition or IBM Business Process Manager

Project management and general BPM

BPM Project Management 3

Unit 1: BPM Introduction

• Compare and contrast a BPM project with other types of projects

BPM Project Management 5

Introduction to business process management (BPM) projects

For additional BPM related terminology, see Appendix A

6 Unit 1: BPM project overview

BPM systems incorporate various types of functionality, including:

BPM Project Management 7

Establishes single, consistent process

8 Unit 1: BPM project overview

IBM Business Process Manager project features

BPM Project Management 9

10 Unit 1: BPM project overview

Code-driven vs. data-driven development

BPM Project Management 11

At this point, the process development is hard-coded. Then it has to be compiled,

12 Unit 1: BPM project overview

BPM Project Management 13

Why Iterative development?

14 Unit 1: BPM project overview

Iteration reduces risk

BPM Project Management 15

At each iteration, or playback, requirements definition leads to a playback design. This

16 Unit 1: BPM project overview

Playbacks in a basic project

BPM Project Management 17

Types of BPM projects

18 Unit 1: BPM project overview

What tools enable management of a project?

BPM Project Management 19

BPM development realities

Incremental improvements are key:

20 Unit 1: BPM project overview

BPM solution life cycle

The four phases are:

BPM Project Management 21

How is the BPM solution life cycle different?

22 Unit 1: BPM project overview

Conceptual approach to BPM projects

BPM Project Management 23

BPM project roles

24 Unit 1: BPM project overview