Академический Документы
Профессиональный Документы
Культура Документы
I
ntr
oduc
tionandText
by
Dougl
asKr
a,Seni
orVi
cePr
esi
dentPegaConsul
ti
ng
wi
thaFor
ewor
dbyAl
anTr
efl
er,Founder
,Chai
rman,andCEO
DELIVERY@PEGA
Contributions from: Invaluable Support from:
Benoit Dubouloz Idrees Ali
Richard Fay Rahul Ashok
Mark Guthrie Tim Beachus
Scott Haggerty Adrian Bignall
Konrad Jelen Andy Elliott
Thomas Kaufmann Rob Guy
James Maciolek Kedar Jog
Paul Roeck Ian Johnston
Baruch Sachs Setrag Khoshafian
Iain Tollemache Michael Ray
Ken Yu Michael Smith
Kimberly Thurow
SK Tirumala
2
Contents
Foreword by Alan Trefler ..................................................................................... 5
A Word from Douglas Kra .................................................................................... 7
1. Why Delivery@Pega .................................................................................. 10
2. How We’re Better – the Pegasystems Business Advantage ...................... 14
3. Our Delivery Methodologies ..................................................................... 24
4. When/How to Use Scrum .......................................................................... 32
5. When/How to Use Pega BPM.................................................................... 54
6. Successfully Staffing Your Projects ............................................................ 74
7. Governance and Technical Oversight ........................................................ 86
8. Defining and Managing Size/Scope in an Agile World .............................. 98
9. Program and Project Management ......................................................... 104
10. How to Measure Success......................................................................... 112
11. Build Management, Quality, and Performance ...................................... 122
12. Maximizing Your PRPC Return on Investment ........................................ 136
3
4
Foreword by Alan Trefler
Our technology – Pegasystems PegaRULES Process Commander® (PRPC) –
fundamentally transforms the way in which organizations around the world
conduct their businesses. It revolutionizes how they optimize the customer
experience and how they automate their operations.
The best way to deliver PRPC solutions is to use one of our recommended Agile
methodologies – Scrum or Pega BPM. They include best practices, standardized
processes, tools, and Guardrails that have been refined through the experience
of many projects and the collective knowledge of our Pega Consulting workforce.
By employing our full lifecycle approach, you can build more sustainable, scalable,
and successful PRPC solutions faster, easier, and for a lower cost. This approach
leads to realizing business benefits sooner, higher quality solutions, and ultimately
client success.
5
6
A Word from Douglas Kra
Pega Consulting’s mission is all about making our clients successful with
Pegasystems’ revolutionary technology, whether it’s:
• Helping the world’s busiest international airport ensure that flights
leave on time.
• Guiding caregivers in helping millions of people lead healthy lives.
• Managing insurance claims that help families and businesses rebuild.
• Connecting stranded drivers with the assistance they need.
• Turning complex business rules and regulations into real solutions
for real people.
We are committed to helping our clients meet their strategic goals and objectives.
Our consulting services resources are some of the best in the world as they bring
thought leadership, experience, and domain expertise to each project. We also
partner with the world’s largest consulting organizations, system integrators, and
regional Strategic Alliance Partners to deliver high quality PRPC solutions. Enabling
our Strategic Alliance Partners on Pegasystems’ delivery best practices, methods,
and technology ensures more predictable outcomes, better quality, and shorter
delivery lifecycles.
To realize maximum benefit, our Strategic Alliance Partner and Pega Consulting
resources are enabled with the proper training and proven methodologies for
designing, deploying, and maintaining PRPC solutions. Our Agile delivery
approaches, proven over time and on many delivery engagements, are the
fundamental building blocks for implementing a single PRPC solution or an
enterprise change management program. They are comprehensive and include
everything you need for success.
This book describes how Pegasystems delivers PRPC solutions and how to be
successful following our approach. Master these concepts so you can deliver
PRPC solutions in the most efficient and effective way – leading to successful
implementations, Great Systems, and delighted businesses.
7
8
1
WHY DELIVERY@PEGA
9
1. Why Delivery@Pega
Pegasystems’ Build for Change® technology is transformational and a game
changer. To help you achieve great results with our technology, we have
developed a methodology to make the journey easier. To quote Douglas Kra,
“the mission of Pega Consulting is to ensure that our clients are successful.” If
all of us – our Strategic Alliance Partners, Pegasystems, and our clients – fulfill
this promise with every solution delivery, we will attract the best and brightest
resources, and provide an environment that fosters thought leadership and
breakthrough technology.
This book describes how to deliver a successful Pegasystems project using our
proven approach – in other words, how to deliver PRPC solutions the right way.
Our delivery approach is not complicated. However, you must have diligence and
discipline to execute correctly, including:
• Utilizing Scrum/Agile or our Pega BPM methodology.
• Engaging the business.
• Managing programs/projects, including resourcing, governance,
estimating, quality, and performance.
• Measuring success and benefit realization.
• Incorporating a BPM or PRPC Center of Excellence (COE).
• Leveraging reusable assets.
By following these principles and using the recommended tools and processes,
you can successfully deliver a fully functional PRPC application within 90 days.
Implementing a sustainable and scalable application in a shorter time as part of
a larger solution maximizes benefit realization while minimizing risks and issues.
10
For First-Time PRPC Projects
For organizations embarking on their first PRPC solution, it is critical to staff key
roles with certified resources available from our Strategic Alliance Partners or
Pega Consulting. We recommend utilizing these experienced resources in key
project roles to provide oversight and guidance, thought leadership, mentoring
and coaching, and domain expertise. We have found that this approach sets a
foundation for success from the start.
Once fully enabled, you will be able to effectively maintain and develop new PRPC
solutions on your own. This objective is one of the reasons why we have a robust,
flexible, and standardized methodology. Anyone should be able to use it and
achieve the same results.
If you need assistance at any time, Pega Consulting offers a range of services
including project staffing, design reviews, performance assessment, user interface
(UI) recommendations, establishing a BPM or PRPC Center of Excellence (COE),
and more.
The Chinese Taoist philosopher, Lao Tzu, once said, “Give a man a fish and you
feed him for a day. Teach him how to fish and you feed him for a lifetime.”
Studying and practicing the concepts in this book will empower you to assist some
of the world’s most dynamic organizations become more “built for change”.
11
Additional Resources
Resource What It Provides
Pega Developer Network (PDN)
www.pega.com/community/groups/pega-developer-network-pdn
A private member community to help you maximize the
value of your investment in PRPC, with services such as:
• Knowledgebase with answers to hundreds of
common product questions
• Product documentation including release notes,
installation guides, and upgrade guides
• Community forums
• Live and archived developer Webinars
Pega Academy
www.pega.com/services/university-of-pega
Where to go for Pegasystems training (both self-study
modules and formal instructor-led courses) and
information about our certifications
Pega Mesh
www.pega.com/community/groups/pega-mesh
A continuous conversation among our Partners,
employees, and clients. The Mesh is an online channel
where participants collaborate in an open and
transparent environment. Citizens in this community
can:
• Influence product development
• Download source code
• Access product feature planning and issue tracking
12
2
HOW WE’RE BETTER -
THE PEGASYSTEMS
BUSINESS ADVANTAGE
13
2. How We’re Better – the Pegasystems Business
Advantage
The typical audience for a Pegasystems solution is a business leader focused on
revenue growth, client satisfaction and retention, or operational efficiency. You
need to be able to respond quickly to a changing business environment and
competitive pressures. Pegasystems empowers you to achieve this through faster
time to market and with the flexibility to adapt a solution while in production to
changing market conditions.
As a business leader, you work closely with your project delivery lead to decide
where and how to enable change in your business. We offer a number of
accelerators to help you, such as industry-specific and business vertical
built-for-purpose frameworks, an integrated business model-driven approach
to better business outcomes, built-in case management, and business process
management (BPM) to focus on work automation.
You start by deciding on the high-level scope of your solution to build the capacity
for change and leverage multiple customer channels.
14
Next you empower your business community to decide specifically where to begin
within that scope, comfortable with the knowledge that PRPC enables you to
deliver incremental functionality as the business changes. Typically you also
reach out to experts in your BPM or PRPC Center of Excellence (COE). This team
provides services that act as a catalyst for BPM adoption and architecting for
reuse. They provide valuable advice in defining your BPM roadmap and the initial
business case.
Together with your project delivery lead and COE, you initiate your first project.
Now your business community drives the detailed definition of the project scope.
The first step is to capture and refine the objectives for the business process
directly in PRPC via its unique Directly Capture Objectives (DCO) features,
which also measure the associated return on investment (the “R”). By leveraging
DCO from the start, you can enhance the workflow iteratively and consider
re-engineering rather than simply replicating the as-is process.
15
Your next decision is whether releasing Sprints or slivers iteratively would
enable you to realize benefits immediately. You must have a clear vision of the
operational nature of the business and what you are trying to achieve with the
project. (Is it case management, work automation? What are the key objectives?)
The combination of a clear vision and the ability to bring your business along with
you will foster efficiency in subsequent phases. Your COE and delivery lead help
you refine the project vision by conducting Operational Walkthroughs to solidify
the desired solution.
As the project continues, PRPC enables you to quickly capture and easily refine
your business goals as models that can be instantly turned into intelligent,
automated processes. There are no long development intervals. Delivery
resources focus on configuration, design patterns, and reuse to expedite solution
delivery and the “R”. PRPC generates most of the code needed to deliver fully
functional processes and applications. As your business community becomes
more enabled, they can assume responsibility for more aspects of the delivery
which allows for greater speed and increased quality.
With Pegasystems, gone are the days when the business must rely on IT to
interpret their needs, wait for upwards of 18 months for delivery, and then wait
months more to adjust and tune the solution.
16
With Agile delivery methodologies and various accelerators, Pegasystems
empowers your business to:
• Drive business change through active sponsorship and decision making.
• Determine the level of functionality and benefits to implement based
on an overall BPM roadmap.
• Engage with delivery leads to make the level of business change
needed as and when required, knowing that they can continue to
Build for Change®.
• Work in a collaborative business and delivery-driven team to
achieve the desired outcomes.
• Determine the optimum path for incremental functionality to be
delivered and benefits gained.
Identifying the “R” is a key element in the process to ensure that resources are
spent wisely and benefits are achieved quickly.
After requirements are gathered, PRPC automates the code generation. There is
no need for months of traditional programming, which vastly improves the speed
of building and changing an application. In essence, DCO eliminates the need for
translating written requirements documents into code.
17
As you refine requirements, the documentation and the solution remain aligned.
Business documentation is generated from the same tool (PRPC) that describes
the application, keeping the capture of the business process, the implementation,
and the documentation synchronized. The project delivery lead supplements the
automated documentation by adding more specific design patterns in PRPC – in
other words, reuse structures that enable the delivery team to build the more
technical aspects.
Through DCO, PRPC provides a single repository for business and technology to
deliver collaboratively. Business requirements are translated directly into the
solution, and the technical interpretation is described and modified alongside what
the business specified.
ROI-Driven Approach
An essential part of capturing the business process is identifying its benefit and
determining its “R”. This focus on value ensures that funding to solve problems
and enhance process is well-spent. Leveraging Pegasystems frameworks can also
add significant value and shorten project delivery.
When you couple PRPC with an Agile methodology such as Scrum or Pega BPM,
you deliver value to the business incrementally and quickly. Historically, systems
were delivered in their entirety and could take 18 months or more. In contrast,
PRPC solutions begin to deliver value in 90 days or less and deliver increasingly
more value as the months pass. Further, when an 18-month cycle is required to
deliver an application, requirements often change just before it is delivered.
With PRPC and Agile processes, you can iteratively change requirements in a
series of successive project Sprints (Scrum) or slivers (Pega BPM) to deliver a
fit-for-purpose solution in a timely manner.
PRPC supports Service Oriented Architecture (SOA) principles, which fosters reuse,
reduces development effort, and increases ROI. PRPC solutions can consume Web
services that are interfaces to existing legacy or enterprise resource planning (ERP)
systems, or be exposed as Web services themselves.
18
Iterative Implementation
After identifying and scoping the proposed solution, your delivery team moves
onto implementation. Although emphasis shifts to the technology team’s efforts,
the business community remains intensely involved.
When using Agile methodologies such as Scrum or Pega BPM, your business
community is embedded in the team and has direct input into the form and flow
of the application as it is being developed. They have the opportunity to provide
ongoing feedback during frequent “show and tells”. Business and technology
collaborate in self-organizing teams. They execute short iterated cycles that
produce measurable results and release candidates that are tested together for
possible release into production.
Your business decides when to release each Sprint or sliver in order to provide
immediate and incremental benefit to their user community. They have the final
say over acceptance. The best way of gaining feedback on a release is assessing
the value that comes from production usage.
Incorporate the business feedback into decisions going forward as the solution
moves to meet the next incremental functionality, which of course you select based
on the “R”.
As you capture your requirements in PRPC, you identify those business needs
that must be able to change dynamically and under which controls or business
authority. You also identify the need for a “Sandbox” environment in which you
can model changes before moving them into production so you can evaluate
their impact on your business.
19
With PRPC, you define specialized processes to suit your changing business needs
dynamically and in real time. PRPC selects the right rule at the right time, which is
referred to as Rule Resolution and is very powerful when you understand and
plan for it. However, you must carefully choose and manage the rules that your
business community is empowered to change on demand and thus adjust how the
business process works.
The “managed carefully” aspect means that you should also control the update
process (preferably via a PRPC approval workflow) to ensure that the changes have
the desired effect.
The 6Rs
PRPC enables you to streamline and automate a business process from how
the work is Received, where it is Routed, how it is Reported, Researched, and
Responded, and lastly how it can be Resolved. We refer to this foundation as the
6Rs of case automation. Work resolution is automated wherever possible, or
assigned to a resource for resolution on an exception basis when the work cannot
be resolved with the application of rules. Business resources are freed up from
the more tedious, repetitive work, allowing them to focus on higher value efforts.
We believe that the seventh “R” – Return – is the most important of all. By
delivering iterative project Sprints or slivers, you also deliver incremental, faster,
and cumulatively higher return on investment.
20
You use the 6Rs together with what we call an Operational Walkthrough early in
the project to identify and quantify current execution gaps. You then map them to
PRPC functionality to deliver these benefits and close the gaps. This approach
enables you to assess the solution benefits.
This approach is possible because of the nature of PRPC, which provides both
a Business Rules Engine (BRE) and a Business Process Management (BPM) model
that seamlessly unifies business rules with the workflow engine. It also depicts
business process flows in a manner that is both friendly to the business
community and represents the actual implementation. Business and technology
share a single solution.
21
PRPC creates the process to perfectly map to the needs of your customers,
specialized by channel, with complete coherence to what is specified from DCO
to the Situational Layer Cake to production. What your business manages in the
Situational Layer Cake is exactly what runs in PRPC. There are no gaps to
introduce errors.
22
3
OUR DELIVERY
METHODOLOGIES
23
3. Our Delivery Methodologies
Selecting the right methodology for delivering your PRPC solutions is one of
the first critical decisions that you make with regard to project success. The
methodology must fit the application, the team, and the enterprise. This means
that some projects are best suited to one methodology, while other projects are
a better fit with another. For example:
• A solution that is not well-defined upfront and has many changing
requirements may be better suited for a Scrum/Agile methodology. This
type of methodology aligns well with this type of project because it is
designed to handle and adapt to change easily.
• Waterfall methodologies can handle change, but they are not as agile or
receptive to it. The requirements tend to be locked down upfront and
change is handled through a more rigorous change management process.
Enterprises or solutions that require more detail up front and a fully
qualified roadmap of how to deliver the specifications over the lifecycle
of the project – or through multiple projects – tend to follow more of a
Waterfall approach.
The Potential Business Value (PBV) is the value of the business case on which you
justify a project. The Realized Business Value (RBV) is the business value that you
achieve after delivery. By reducing PBV (what you expect to achieve) and increasing
RBV (what you actually achieve), PRPC and our Agile methodologies significantly
increase the real return on investment.
24
What is A Methodology?
The terms “guideline”, “solving a problem”, and “discipline” sum up what a
methodology requires with the most elegant and simplistic perspective.
Guideline
A methodology is supposed to guide you through the process without providing a
step-by-step prescriptive process. Using this technique requires team members to
continue to think and react to situations that arise during the implementation.
When more prescriptive methodologies are used, team members tend to look to
the methodology to solve challenges for them instead of using the methodology
as a tool to assist with the removing the impediment. The team should always be
in control of the methodology and not the reverse.
Solving a Problem
A methodology should always have the ultimate goal of solving a problem. You
can define a problem in many ways. It could be a business need, a technical
challenge or deficiency, or a process improvement. Some methodologies lose
focus on the ultimate goal and tend to spend too much time documenting for the
sake of documenting. Of course, some level of documentation is necessary. But
exceeding an appropriate amount is wasteful and distracts the team from its
ultimate goals.
Discipline
A methodology should not be so prescriptive that it removes the human factor
from the equation and reduces the methodology’s ability to be Agile. However,
you do need to instill discipline to the basic principles of the methodology. When
diluted, these basic principles can cause the methodology to be inefficient and
problematic, and ultimately cause a project to be unsuccessful.
25
A methodology can also morph into something totally different when
undisciplined. In this case, you will lose many of benefits of the methodology.
For example, it is very easy to change a Scrum methodology into a Waterfall
methodology simply by not strictly adhering to the basic disciplines of Scrum.
26
Remember that selecting the correct methodology is not a science. You could
develop a solution under the same enterprise circumstances using two different
teams of resources and methodologies, and both could be classified as successful.
This book focuses on the most frequently used methodologies for PRPC projects –
Scrum and Pega BPM.
We recommend that you use either Scrum or Pega BPM because they work
seamlessly with PRPC DCO capabilities. This combination makes your teams more
efficient and effective at building and delivering high quality solutions on time and
on budget. DCO capabilities allow you to focus on core capabilities by automating
many manual tasks such as the documentation process. DCO also reduces the
amount of time you spend looking through vast sets of documents in search of
specific requirements or specifications by linking assets directly in PRPC, creating
a 360-degree view of the implementation assets.
Other systems allow you to manage assets by linking them together, but PRPC
and DCO take this capability further. You can link Specifications directly to the
Configuration rules that form the application. Developers can access these
assets in the development environment with a single mouse click, making the
development process far more efficient.
27
So, how do you make an informed choice for your organization?
• Scrum. If your team and organization are open to new experiences and
fully understand the disciplines associated with Scrum, moving directly
to Scrum can be a positive and rewarding experience.
• Pega BPM. If you are coming from a Waterfall implementation
environment, are unsure how much risk Scrum will introduce, or your
teams are not yet prepared to adopt all of its associated disciplines,
Pega BPM may be a good interim step. Pega BPM introduces your team
to many of the Agile concepts associated with Scrum, while tolerating
some of the overhead associated with non-Scrum implementations.
Industries are now changing so rapidly that it is hard for large projects to keep up.
An 18-month project may deliver 100% of the functionality required or requested
by the business. However, only a small portion of it will ever be used. The
business no longer needs the rest of it because the industry changed during the
implementation lifecycle. Consider the Standish Group study that examined how
often features developed in a system are used – the results are not pretty.
28
To determine your “best-fit” methodology, we use what we call a Methodology
Alignment Workshop (MAW). We look at your environment and how you
currently conduct projects. We look to see what is working well and what could
be improved. We look to see to what degree agility is emphasized and to what
degree the methodology is open to change. During the MAW, we work with your
teams to:
• Evaluate which practices work best and which cause inefficiencies.
• Assess the possibility of moving towards a more Agile and iterative
model such as Scrum or Pega BPM.
• If you are receptive, determine exactly how open you are to a more Agile
approach.
• Assess whether you could move to a Scrum model now or Pega BPM
might be a good step towards the next Agile maturity level.
29
Address developing a UX strategy up front during the DCO sessions. Since you can
capture Use Cases and draft User Interface Wireframes, you can capture the UX
strategy into your project and incorporate feedback in an iterative fashion upfront
to establish a good UI baseline.
A team can also corrupt a healthy process by doing things it perceives as correct,
but inadvertently making the process inefficient. For example, teams using Scrum
achieve a state of high productivity only by religiously following its disciplines.
Putting in more hours than planned can actually corrupt the process and
negatively affect the team’s velocity. Agile methodologies deliver good results
because of highly motivated resources. Overworked resources tend to be
unmotivated, introducing poor configuration practices that result in bad design
and defects.
30
4
WHEN/HOW TO USE
SCRUM
31
4. When/How to Use Scrum
Many studies (such as the Standish Group one mentioned earlier) demonstrate
that business uptake of system features is typically low. The metrics show that
only 20% of developed features are often or always used, and 64% of features are
rarely or never used. To counter this, a new solution must identify key business
value correctly, implement it as rapidly as possible, and engage the business
throughout the process to promote shared ownership.
Agile tools address the rapid development aspect, but you also need a
methodology to identify business value and retain business involvement
throughout. It is not sufficient to just rapidly release a solution. You must assess
it against business value, and track it to ensure it remains valid and owned by
the business areas.
High-Level View
Scrum is not a prescriptive, detailed list of directed step-by-step processes,
milestones, and deliverables. Instead, it provides guidance to the development
team who are best placed to determine how to produce the solution. In this way,
Scrum enables empowered self-organization among its project teams.
32
A Scrum Project operates as follows:
• A Scrum project consists of a number of time-boxed iterative periods
called Sprints, which are usually 2 – 4 weeks long.
• The Sprint consists of a number of components (called User Stories)
that are selected from a repository of requirements (called a Product
Backlog) as being defined enough for completion in the Sprint, and
have been moved by the Scrum Team into a Sprint Backlog.
• The team delivers a production-quality configuration at the end of
each Sprint.
• At the end of each Sprint, the team demonstrates the result to the
Product Owner (plus other interested Stakeholders) in a session called
a Sprint Review.
If you are new to Agile and Scrum, “Scrum and XP from the Trenches (Enterprise
Software Development)” by Henrik Kniberg is a useful resource for understanding
how other organizations have implemented them.
33
Role Description
Scrum Team Resources assigned to the project to facilitate delivering the
defined functionality.
Scrum Master Not a resource manager or a Project Manager, but rather a
team coach and mentor. Primary function is to help the team
be successful. Protects the Scrum Team from outside
interference, while guiding Sprint resources. Monitors Sprint
reports to ensure the team remains on target for delivery.
Product Owner Responsible for and manages the Product Backlog by
determining its contents and prioritization. Also responsible
for what is delivered by the project, ensuring its validity to
deliver the “R” to the business.
Stakeholder Any person who has a direct or indirect interest in the work
of the team, but does not participate as a team member.
34
PRPC embraces the industry-standard Scrum Framework as advocated by the
Scrum Alliance® (www.scrumalliance.org). It provides a range of tools and best
practices that enhance development:
• Directly Capture Objectives (DCO) features make teams more efficient.
• Work Automation further improves the development process.
• Project Management Framework (PMF) supports project management,
tracking, allocating, and planning.
Velocity (or rate of throughput) is how much work the team believes they can
complete during the next Sprint. Maximize the use of these tools on your projects
to achieve the highest velocity.
In our experience, the primary focus of Scrum is on the iterative cycles of refining
requirements and delivering functionality. We have found that the initial Vision
stage often fades into the background, obscuring the long-range vision and
strategic goals. To address this, we split the initial Vision stage into three
components that each concentrate on a particular element, with two additional
stages to cover the iterative definition, build, test, and rollout processes. You
revisit the vision and goals at the beginning of each Sprint to retain strategic
focus.
If you are considering Scrum, we strongly advocate following this approach with
five main phases.
35
Stage 1: Vision Definition
This stage focuses on developing both long-term and short-term strategies for
releasing significant Business Value in short incremental bursts of delivery. It is
successful when you have a clear and concise understanding of what Business
Value will be delivered by what Functionality, and when.
To define your long-term strategies, you first identify the key Goals with the
business. Then you evaluate each Goal to compare predicted costs, anticipated
benefits, and risk. The intersection of project complexity and business visibility
influences your project selection.
-1
0 200 400 600
0 1 2
1 Debit Card Processing
1 2 Credit Card Processing
Complexity
2 3 4 3 Wireless Payments
If validated, you next identify Releases against each Goal (or set of Goals) with
defined and measurable Business Benefits associated. We have consistently found
that realizing Business Benefits is critical to project success. Once you have
identified and agreed on these Benefits, you should carefully track them
throughout the project.
You further break down Releases into Projects, and create and store Epics in
associated Product Backlogs. Finally, you apply these Releases and Projects to an
estimated delivery timeline, resulting in a roadmap.
36
In this way, the Vision Definition stage:
• Ensures all strategic Initiatives demonstrate clearly articulated
Business Value.
• Breaks down and organizes Initiatives into Releases.
• Provides a prioritization based on Value, Risk, and Return for
each Release.
• Breaks down and organizes Releases into Projects.
• Creates Product Backlogs containing Epics, and associates them
with Projects (and therefore Benefits).
• Creates an estimated delivery timeline/roadmap.
Epics are large User Stories that are typically too big and high level to implement in
a single iteration. You decompose an Epic into a set of smaller, well-defined
implementable User Stories during Backlog Grooming activities.
37
Stage 2: Project Initiation and Preparation
This stage focuses on setting expectations with the project team and project
stakeholders, defining the first project, and creating/enhancing the Product
Backlog. Typical activities include:
Methodology Alignment
Pegasystems provides both methodology and technology to support the Scrum
framework. However, we realize that you may need to integrate this structure
into your own methodology. We conduct a Methodology Alignment Workshop
(MAW) at this stage to evaluate the best methodology for you and your project.
Similar on-going activities are likely as you amend the blended methodology to
reflect your daily practices and processes.
See Chapter 3 (Our Delivery Methodologies) for more information about MAWs.
Realize that you must adhere to the fundamental elements and practices of
Scrum. We have seen many instances of Scrum being aligned to other
methodologies and being described as “Scrum-but” or “Scrum-with”. These
methodologies may be completely valid in their approach and ideal for the
circumstances, but they are not Scrum. You will only realize the full benefits
of Scrum by rigorously applying the Scrum framework.
Operational Walkthroughs
In addition to aligning the methodology, you capture high-level User Stories
(Epics) during Operational Walkthroughs and other meetings with the business.
While usually not defined to the level of an implementable User Story, Epics
contain sufficient detail and identified benefit to be prioritized and sized in
38
the Product Backlog. You use these Epics to create a release schedule with a
number of planned Sprints. We require Operational Walkthroughs during the
initial stages of a project. They are a proven way to understand the existing
system and challenges.
Affinity Sizing
You must have an early indication of project size in order to produce a plan
that delivers incremental Sprints to the business. Reviewing every User Story
in a Product Backlog and producing a level of detail (and acceptance criteria)
required for sizing would be a lengthy and wasteful exercise. Only groom User
Stories as they move up a prioritized Product Backlog. Otherwise, you would
be investing valuable time on something that may never be implemented. To
produce an initial estimate of size and a plan, Pegasystems uses a proven process
known as Affinity Sizing (also known as Affinity Estimating).
For an Affinity Sizing Workshop, Scrum Team members rank a subset of the
Product Backlog relative to each other considering the effort involved, from
smaller to larger. Items stacked vertically on the table are about the same relative
size in effort. After sizing an initial subset, each Scrum Team member sizes the
remaining User Stories in comparison with the initial subset. This is not estimating
complexity, but rather estimating effort. The Product Owner and any additional
stakeholders/supporters provide clarity where needed.
Place any questionable Product Backlog items (such as items which are too
ambiguous to size at this point) in a holding area.
39
Next the Scrum Team reviews all User Stories in their groupings to agree relative
sizings. We recommend using Fibonacci numbers for this purpose, which is a
defined sequence of integers (1,2,3,5,8,13) commonly used in mathematics and
computer algorithms. The team assigns a number to each item to create arbitrary
initial boundaries and, respecting the physical scale, groups the items. The space
between the groups should reflect the effort difference and the Fibonacci scale.
After the Product Owner has reviewed and discussed any contentious items
with the team, they register relative Story Points against each User Story. Once
a User Story is groomed and suitably detailed, the team creates a more accurate
estimate of effort in Stage 4 (Scrum Implementation).
40
Stage 3: Enterprise Planning
This stage focuses not only on the current architecture, but also what will be
needed to support future applications. During this stage, you design the
Enterprise Class Structure (ECS) that maximizes reuse capacity across Sprints,
projects, and applications, and an infrastructure to support current and future
needs. You continue to groom the Product Backlog and add details to each User
Story. You may also run the Application Accelerator (described later) in order to
preview the application structure.
The ECS is the hierarchy that defines application classes across your enterprise. See
Chapter 12 (Maximizing Your PRPC Investment) for more information.
Foundation
During this stage, you set up the hardware environments and define a strategy
that covers promotion of the application into each environment (Development,
Test, QA, and so on).
Reusability
Identifying and reusing components contributes significantly to cost reduction in
both development and maintenance. During this stage, you begin to identify
reusable assets and create a reuse library. Performing this activity at this point
ensures that you adopt a build for reuse strategy, which reduces the rework
necessary to refactor a core component for reuse later in the project.
Testing
Be sure to draft and amend test strategies to cover the Scrum development
phases, the rollout plan, and the PRPC capabilities. A key differentiator of Scrum
is the integration of iterative build and test cycles within a Sprint. PRPC is flexible
enough to support parallel development and test cycles, multiple releases, and
multiple versioning. It also includes tools such as PAL (Performance Analyzer)
that assist in identifying performance issues early, thereby reducing their
resolution costs.
41
Stage 4: Scrum Implementation
In this stage, the team follows a prescribed series of steps to define, plan, and
execute the Sprint.
When you have completed the activities to establish a sound project foundation,
you can begin the Sprint activities. Initially the Product Owner reviews and
updates the Product Backlog to ensure that:
• Prioritization is correct.
• Business value for each Epic/User Story is still valid.
• Dependencies are mitigated.
• Level of detail for User Stories is correct.
The Product Owner and Scrum Team must absolutely agree on the level of detail
required for a User Story. We recommend using a Definition of Ready document
for this purpose. It lists the criteria by which a User Story can be considered ready
for inclusion in a Sprint Backlog. Pegasystems uses the following format; complete
examples are available for use as a template.
42
Throughout this stage, the Product Owner continues preparing the Product
Backlog for the Backlog Grooming workshops. Note that you don’t need to
prepare all User Stories in the Product Backlog. Indeed, to do so would be wasted
effort as User Stories may change, be re-prioritized, or even be rejected during
the project. As a guideline, the Product Owner should prepare twice the number
of User Stories required for a Sprint, for each Sprint Team.
Backlog Grooming
The workshop participants also agree upon a clear and concise Definition of Done
(DoD), for which there can be a number of definitions for each User Story, Sprint,
and Release. This document forms an agreement between all parties on the end
stage for activities. When the Backlog Grooming Workshop convenes for the first
time, the team either creates a new DoD document or amends one from a
previous Sprint. Teams typically use a standard Definition of Done document.
Pegasystems uses the following format; this excerpt is for a User Story. Complete
examples are available for use as a template.
43
Recommended Areas for a Definition of Done Document
Tasks Completed Product Owner Acceptance
Performance Unit Testing
DDL Show & Tell
Configuration Checked In Warnings
Documenting Rules LSA Acceptance
Bug Fixing Data Instances
Story Linking Integration Testing
Screens Localized Regression Testing
Peer Review
Scrum uses a relative scale because asking Scrum Team members to estimate
implementation effort in days results in large variances, depending on developer
experience and confidence. Instead, you create a reference point to a relative
scale. When performing Planning Poker for the first time, choose a User Story that
is neither too complex nor too easy and give it a rating of 8 Story Points. Use this
reference point as a benchmark for estimating all other Story Points.
44
It consists of a series of cards with 13 numbers (1/2,1,2,3,5,8,13,20,40,100) that
represent relative effort in points, plus three specialty cards (0,?,C):
• 0 = No effort required; this functionality already exists.
• ? = I cannot answer now; I do not understand what is being asked for.
• C = I need a break.
Planning Poker is essentially a secret ballot process. After discussing each User
Story, all team members select the card that most closely represents their view
of the relative size of the work to be done and place it face down in front of them.
Everyone turns their cards face up at the same time and discusses the various
estimates. They repeat the process until they reach consensus and then assign
Story Points to the User Story.
Aim for User Stories that are estimated in the range of 2 – 8 Story Points. If you
can’t reach consensus after three iterations, discard the User Story as it doesn’t
have sufficient detail to be understood.
With a groomed and sized backlog prepared, you are now ready to plan the
Sprint. For reasons of time and efficiency, we recommend splitting the Sprint
Planning Meeting into two parts.
Purpose Attendees
Part 1 Final Product Backlog Preparation: the Product Product Owner, Scrum
Owner explains the goal, vision, business Master, and Scrum
benefits, and backlog items so the team has a Team
clear understanding of the business need
Part 2 Sprint Backlog Creation: the Scrum Team Scrum Master and
designs, plans, and commits to work Scrum Team
Product Owner
(optional)
45
Part 1 Objectives
• Review the Definition of Done to ensure full agreement.
• Discuss any dependencies to ensure schedule coordination.
• Review the Product Backlog to ensure priorities/details reflect
business, technical, and dependency issues.
• Determine the Sprint Duration.
A typical Sprint Duration is two, three, or four weeks. Initially use three or four
weeks in order to understand and align to the Scrum method. After two or three
Sprints, reduce the duration to two or three weeks.
Part 2 Objectives
• Determine how many User Story Points to include in a single Sprint
based on team resources and velocity.
• Select User Stories from the Product Backlog to include in the Sprint
Backlog, with total Story Points equal to or greater than the team
velocity.
Allocate 6 – 7 hours of an 8-hour day to the Sprint for Scrum Team members.
The additional 1 – 2 hours are for activities outside the Sprint. For initial Sprints,
assume one User Story Point per day’s effort for one resource to calculate Team
Velocity.
Consider the velocity for a three-week Sprint with a Scrum Team of four resources:
(15 days x 6 hours) / 8-hour workday = 11.25 days x 4 resources = 45 days =
45 Story Points = Team Velocity
46
Hours
Task
Task Name Task Description Duration
ID
(Planned)
1 Directly Capture Planned number of hours for 3
Objectives (DCO) Scrum Team members to prep for
and attend a DCO session
By creating and committing to a Sprint Backlog, the Scrum Team and Product
Owner have agreed regarding what, how, and when the work will be completed,
and what constitutes Done. It’s time to start the Sprint.
Sprint Execution
The PMF Scrum Board provides a useful pictorial representation of Scrum Team
progress. See Chapter 9 (Program and Project Management) for more information.
47
Daily Standup
During the Daily Standup, each Scrum Team member relates what they have
worked on since the last Standup, what they will work on until the next Standup,
and any progress blockers or help required. Each member should take only two
to three minutes to provide this summary update. Conduct any detailed questions
or reviews outside of the meeting.
Task Updates
At the end of each day, Scrum Team members update their tasks with the hours
remaining to complete and hours worked that day. The Scrum Master reports
progress towards Sprint completion based on these two numbers, plus the target
hours stated when the task was created. Everyone must diligently follow this
process to avoid skewed metrics.
Sprint Review
At the end of the allocated time, the Scrum Team presents all User Stories that
are considered complete (according to the Definition of Done) to the Product
Owner at a Sprint Review. The Product Owner considers whether each User
Story is complete and accepted. Accepted User Stories go into the next release
component. Rejected User Stories return to the Product Backlog, where the
Product Owner prioritizes them for resizing.
48
Stage 5: Scrum Retrospective
The purpose of the Scrum Retrospective meeting
is to look back on the Sprint and review what
improvements could be made. Its focus is on
continuous improvement and the “access, learn,
adjust, improve” cycle in which issues are raised,
reviewed, and actions to mitigate/resolve are
agreed, thereby improving the process.
The Scrum Master and Scrum Team attend the Scrum Retrospective meeting.
The Product Owner is invited, but not required to attend.
To support the Scrum Retrospective, we use a large wall-mounted grid with four
sections. During the meeting, team members write their observations on sticky
notes and post them in the applicable section. The group reviews and classifies
the underlying cause of each issue. The team then discusses underlying causes
and decides upon resolution and/or mitigation.
49
We recommend that you record all dependencies against User Stories. Complete
this effort as early as possible in the project. Identify links to and from Scrum
deliverables and register them in a Dependency Log. This practice ensures that
risks are identified and mitigation agreed upon for each dependency.
With large programs, business units will develop solutions to meet the overall
vision at different rates – for example, applications, platform, and core
infrastructure. While each unit may have different approaches, they are all likely
to have dependencies and you will need to manage them.
Team Enablement
Enablement is the key to effectively using Scrum on a PRPC project. It consists
of two elements – formal training and further mentoring to improve the
implementation of the methodology. The recommended Scrum and PRPC
technical training is based on the Scrum team role. All team members should
attend PMF training, which explains how to use PMF to track, manage, and
report on Scrum project progress.
Role Training
Scrum • Scrum Master course leading to Certified Scrum Master
Master accreditation
• Project Management Framework (PMF) training
Product • Appropriate level of PRPC technical training
Owner • Project Management Framework (PMF) training
Scrum Team • Appropriate level of PRPC technical training
• Project Management Framework (PMF) training
See Chapter 6 (Successfully Staffing Your Projects) for recommended PRPC team
expertise.
50
How Directly Capture Objectives (DCO) Works with
Scrum
You use PRPC DCO to both define and implement a User Story. You need a certain
level of detail in order to size and include User Stories in a Sprint. The level varies
according to the Scrum Team and approach. For example, PRPC projects often
use a series of parallel Sprints. You might use one Sprint to elaborate the User
Story in a Business Sprint, which in turn feeds implementable User Stories into a
Development Sprint.
DCO streamlines the process of creating User Stories, which form the backbone of
Scrum.
51
52
5
WHEN/HOW TO USE
PEGA BPM
53
5. When/How to Use Pega BPM
The Pegasystems BPM-Enabled Methodology (or simply Pega BPM) is an
Agile/iterative approach to delivering PRPC solutions. While structured similarly
to the RUP® framework, it differs in that it is closely aligned with PRPC and its
capabilities.
Pega BPM helps you identify the steps that define how your application will
perform the 6Rs of case automation (Receive, Route, Report, Research, Respond,
and Resolve). It takes advantage of PRPC features such as work automation,
Directly Capture Objectives (DCO), flow modeling, and rapid UI development to
shorten your project timeline. It leverages these capabilities while providing the
flexibility to meet the requirements of your Project Management Office (PMO). It
also ensures that you build a high quality solution that easily allows for future
expansion. Pega BPM is flexible and can be right-sized to fit the needs of your
project and organization.
Pega BPM breaks the solution down into smaller iterative chunks of work called
slivers. Pega BPM is not considered to be as Agile or iterative as Scrum. However,
it leverages many of the disciplines required to be Agile without assuming the full
aggressive nature of Scrum. Therefore, Pega BPM can be an excellent alternative
for teams that currently follow a Waterfall methodology and want to reap the
benefits of an Agile methodology but don’t feel ready to progress directly to a
Scrum-based methodology.
Project Candidates
Pega BPM is an excellent choice for projects:
• Where your team is currently using a traditional Waterfall model and
wants to start to implementing projects with a more Agile discipline.
• That require a methodology that can be right-sized easily.
• That will be using PRPC to deliver some or all of the project
requirements.
• That have the ability to be broken down into slivers that can be released
into production as it makes business sense to do so.
• That want to take advantage of PRPC DCO features.
54
• That want or need more learning opportunities for continuous process
improvement.
• Where the business and all interested parties want to play an active role,
collaborating effectively throughout the implementation lifecycle.
55
Implementing for Success
Pega BPM incorporates core guidelines that help you meet the business
requirements and ensure that the solution delivered meets high quality
standards.
PRPC projects that use Pega BPM consist of a cross-functional team with a set of
well-defined roles and responsibilities:
• Program and project • Specialized business experts
management • Specialized technical experts
• Technical and business • Client IT resources
architects
You can fill these roles with many different types of resources. The key to success
is that each person filling a role must have the right skillset and training to be
effective in that position.
See Chapter 6 (Successfully Staffing Your Projects) for recommended roles and
responsibilities.
56
High-Level View
Pega BPM consists of four main phases that provide the baseline methodology for
successful PRPC projects – whether first-time sliver implementations, framework
implementations, or subsequent solution releases.
57
Phase 1: Inception
Provide high-level application description leading to a budget estimate of
project scope, effort, and cost.
Establish a thorough understanding of the scope of what is to be delivered.
Get consensus on the scope of the first sliver and approval to move forward.
This phase is the scoping phase based on what you discovered during Project
Initiation. Its purpose is to clearly define the main objectives, requirements, and
high-level specifications of the proposed solution, and budgetary estimate. At the
end of the Inception phase, you should have a good high-level business view of
what you want to accomplish with the project. You have identified the key areas
of process improvement and re-engineering to achieve a bigger “R”. You have
used the PRPC DCO features (specifically the Application Profile, enhanced via
additional Operational Walkthroughs) to collect the high-level assets that frame
the project.
If you are using PRPC for the first time, we recommend that you engage with
certified experienced professionals from our Strategic Alliance Partners or Pega
Consulting during the Inception phase or earlier to assist with the Methodology
Alignment Workshop (MAW). This workshop is beneficial if you want to embrace
the Build for Change® aspects of PRPC technology, but may not fully understand
how to implement them successfully.
58
You probably have an established methodology for developing and/or
implementing systems throughout your organization, but may not have worked
with PRPC DCO capabilities yet. The MAW bridges the gap and helps determine
the best methodology fit for you and the proposed implementation. The MAW
aims to blend your current Project Management Office (PMO) requirements and
Pega BPM to establish an efficient and effective methodology. Jointly we close
the gaps and eliminate any overlap. The result is reflected in a tailored version of
Pega BPM that is tuned to your needs and implementation team.
Key Activities
• Process improvement/ • Perform Methodology
process re-engineering Alignment Workshop
• Sliver/iteration confirmed (MAW)
• Create Application Profile • Application Profile
• Draft High-Level Project Plan review and approval
• Provide effort/cost estimates
Time Required
Since this phase consists of high-level scoping, most Inception phases span two
to three weeks of effort. If you need a more accurate estimate (such as for a fixed
effort estimate), take more time to ensure that the information captured in the
Application Profile includes the level of detail required to produce a substantiated
estimate.
59
Phase 2: Elaboration/Construction
Establish the application foundation and refine the technical architecture.
Incrementally elaborate on and build out the application.
Conduct on-going system performance, quality, and user experience
evaluations.
Ensure Guardrail compliance.
60
You assign small cross-functional teams (or pods) to these Specification Sets.
These teams include key business process resources (Business Architects),
technical resources (System Architects), and business subject matter experts
(Business Analysts). These pods work together to ensure that the Specification
Sets are elaborated on at the right level at the right time.
As the team elaborates on the work stream, they focus on all disciplines
associated with high-quality application development. As the work stream
evolves through the Elaboration iterations, the business resources periodically
review the build progression during what we call Playback Sessions. They provide
the Business Line with a preview of the work stream process before it is fully
developed as a production-ready application. In essence, the Business Line has
an opportunity to react much sooner in the process and provide critical
constructive feedback while there is still ample opportunity for course correction
without undue risk.
61
Repeat the DCO Elaboration sessions until the business feels comfortable that
the application is progressing in the correct direction. Once completed, these
increments of working application move into the next phase (Transition) where
they will be tested and, if it makes business sense, moved into production.
We recommend that you spend no more than two to three DCO Elaboration
Sessions on any Specification Set.
The result of this phase is a functioning application that meets the business
requirements. It is essential that your business lead has seen the application several
times and accepted that it fulfills the requirements.
62
Key Activities
Time Required
The Elaboration/Construction phase is an iterative design and development effort.
Its duration is based on the scope, complexity, and resource model of the
application being developed. Use our PRPC Project Effort Sizing Tool to estimate
the number of hours required to deliver an application based on the specifications
that are in scope. We have calibrated this spreadsheet based on many PRPC
projects and solutions. However, you can fine-tune it to accommodate your own
contingencies.
63
Tools and Artifacts
Available Tools Artifacts Produced
PRPC Project Effort Sizing Tool Application Profile (AP)
Specification/Requirement Fully qualified/detailed list of
Template Objectives captured inside PRPC
Specification/Requirement Fully qualified/detailed list of
Rule Traceability Matrices Requirements captured inside PRPC
Project Management Fully qualified/detailed list of Atomic
Framework (PMF) Specifications captured inside PRPC
PRPC Automated Unit Test Fully functional Application meeting all
(AUT) the requirements of the Business
Flow Drafting Deployment Plan
UI Drafting As-built documentation generated by
DCO Elaboration Sessions PRPC self-documenting feature
PRPC Performance Analyzer Detailed Project Plan
(PAL) Detailed Testing Plan
Pegasystems Autonomic Event Test Scripts
Services (AES) Detailed Production Run Book
Reports Browser Updated PRPC Project Effort Sizing Tool
Property Trees Governance Deck
Case Designer Project Status Report (PSR)
PRPC Alert and Error Logs Traceability Reports
Pegasystems Pre-Flight Phase Readiness Assurance checklist
Automated Document
Generation
Project Status Report
Template
64
Phase 3: Transition
Ensure that the application that was built:
Is of the highest quality standards.
Performs to established expectations.
Meets the business requirements.
During this phase, you migrate the application from the development
environment to the QA environment. Do not view this migration as a one-time
exercise. Practice the migration several times before required in the schedule to
test that the process works smoothly. The client QA organization is usually
responsible for this process, with support from our Partners or Pegasystems.
65
Quality Assurance Testing (QA)
The QA team begins the Transition phase with QA testing and reports defects to
the development team for correction. They move the modified components back
to the QA environment for retest. We recommend a three-cycle approach to QA
testing before releasing an application for User Acceptance Test (UAT). Each QA
cycle brings the application closer to successfully passing the UAT. If you find few
things to fix, less than three cycles may be acceptable.
At the end of each cycle, hold a team meeting to review the outstanding issues.
Prioritize the issues and decide whether another cycle is required before handoff
to UAT. While a UAT candidate does not have to be 100% error-free, it should
contain no show-stoppers.
66
User Acceptance Testing (UAT)
Upon completion of QA testing, you should have a high degree of confidence that
the application is of high quality and most defects/issues have been found and
repaired. The goal is to ensure that the application is fully functioning when the
business begins UAT and runs its own test scripts. Most test scripts should pass
without issues.
During UAT, the Smoke Test is a quick run-through of enough elements to verify
that the application basically works. In a typical BPM implementation, this test
includes real-life examples such as:
• Adding a work object using data from a remote source.
• Picking an item off the work list, resolving it, and generating
correspondence.
• Checking the audit trail and an attachment.
• Reviewing a report.
• Updating a business rule.
• Running a Performance Analyzer (PAL) sample.
The Smoke Test is useful for extra validation when changes are made (such
as after a new component is checked into the environment) to ensure that
nothing obvious breaks as a result. (It is also valuable during Construction
iterations.) Routinely execute the Smoke Test to evaluate how development
is going.
67
At the conclusion of the test, take a Performance Analyzer (PAL) reading so
you can compare performance readings to typical expectations and review
them against readings from other points in development to see if degradation
has occurred.
Key Activities
Conduct these activities according to standard organizational operating
procedures.
• Environment migration • Load/performance testing
• Production readiness • System integration testing
• Alert evaluation • User Acceptance Testing
• Pre-flight evaluation (UAT)
• Quality Assurance testing • User rollout and support
Time Required
In the Transition phase, you complete the majority of application testing and
validation. Its duration is based on the scope, complexity, and resource model of
the application being developed. Use our PRPC Project Effort Sizing Tool to
estimate the number of hours required to deliver an application based on the
specifications that are in scope. We have calibrated this spreadsheet based on
many PRPC projects and applications. However, you can fine-tune it to
accommodate your own contingencies.
Always make sure that Unit and Integration tests are robust and thoroughly
completed before moving an application into the QA environment.
68
Tools and Artifacts
Available Tools Artifacts Produced
PRPC Performance Analyzer (PAL) Bugs and Issues
Pegasystems Autonomic Event Services Project Status Report (PSR)
(AES) Test Cycle Bug Report
PRPC Alert Logs Training Materials
Pegasystems Pre-Flight
Project Status Report (PSR) Template
Project Management Framework (PMF)
PRPC Automated Unit Test (AUT)
Team Enablement
Investing in quality training for your team delivers significant business benefits
through increased self-sufficiency and productivity. Pega Academy provides you
with the knowledge required to master Pegasystems software. The benefits of a
well-trained team include:
• Reduced cost: utilizing in-house skilled resources dramatically lowers
the cost of ownership.
• Faster deployment/minimized risk: well-trained teams understand
how to design and build solutions rapidly, minimizing exposure to
implementation risks.
• Build for Change®: well-trained teams respond quickly to change and
evolving requirements.
• Career development: acquiring new business process management skills
represents development opportunities for business and IT staff.
69
We can create a customized training plan for your team using any of our delivery
options. At a minimum, we recommend that all team members take our
foundation course (PRPC: Fast Track) to learn the essentials of how to build
solutions that enable users to manage complex business processes.
To review our offerings in detail, visit the Pega Academy area on our web site at
www.pega.com.
70
DCO enables you to produce documents in moments versus the traditional
approach of manually creating documents, which can take many person
weeks/months of effort. Its auto-document generation feature also ensures that
your documents are always up-to-date (as-built). Using the template-based merge
capabilities, you can customize the document form and layout to meet the needs
of your Project Management Office (PMO) or Center of Excellence (COE).
71
72
6
SUCCESSFULLY STAFFING
YOUR PROJECTS
73
6. Successfully Staffing Your Projects
Effectively using the PRPC platform requires a fresh look at both human resources
and methodology. When you staff a PRPC solution delivery team, you have
already agreed on an Agile development methodology such as Scrum or Pega
BPM. Using an iterative approach, you break down programs into projects and
releases, organizing them on a program roadmap. Each project implements a
series of Use Cases delivered in a number of Sprints (Scrum) or slivers (Pega BPM),
each building on the previous ones.
The result: you can deliver real business value in a short time, typically within a
three-month period. However, you must align team resources to a phased
approach that enables this type of delivery model.
Fully staff your teams with people that have the adequate depth and breadth of
skills and knowledge. Team members should be enabled in both PRPC technology
and your methodology of choice. All required roles must be filled, from talented
System and Business Architects to Subject Matter Experts. Leaving skills gaps or
critical roles unstaffed will significantly and negatively impact your success.
The Lead Business Architect is often your linchpin of solution delivery success.
A good candidate must be business savvy, as well as fluent in the chosen
methodology and PRPC platform capabilities. Business Architects need a deep
appreciation of the power of process and an intimate understanding of how
change occurs inside an organization.
74
Individuals fulfilling the lead role typically have completed several successful
PRPC projects. They must be well-versed in Business Process Reengineering (BPR)
principles and practices, and continuous improvement methodologies such as
Lean or Six Sigma®. Look for accomplished and diplomatic individuals who are
capable of building an effective bridge between the business and IT.
We also recommend that you include a User Experience (UX) Architect on your
team as early as possible, ideally as part of the DCO sessions. Depending upon
the complexity of the UI requirements, a UX Architect can be involved for just a
few weeks or participate as a full-time team member. While UX activities can be
incorporated in many different ways, we recommend that you focus on it early
enough to realize a positive impact. Waiting too long to consider UI or its impact
on user adoption will significantly impair the ability for UX to influence design.
75
Role Responsibilities
Steering Normally comprised of management-grade personnel.
Group/Board/ Oversees project progress and reacts to any strategic
Committee problems. Optional if the Sponsor-Manager relationship
is seen as the best means of control. Usually required for
large projects that cross functional boundaries.
Pegasystems Practice Leaders (PLs) are accountable for the successful business
development, solution delivery, and client realization of benefits across their
assigned portfolio of accounts. They work closely with the Program and Project
Management team members to ensure proper governance, issue escalation as
needed, and overall delivery team success.
76
Specialized Business Resources
Role Responsibilities
Process Owner Senior user from the business area who makes all key
business process decisions. Acts as the primary resource
to handle political issues and maintain focus on the
business objectives of the solution.
Subject Matter Individuals with a consummate knowledge of the
Experts (SMEs) operational mechanics of the as-is process and an
appreciation for transforming process in order to
leverage PRPC capabilities. SMEs also need a deep
appreciation of the macro-level business objectives.
One SME per each major impacted business area.
Regardless of the chosen methodology, keep the development team size small and
nimble. The ideal size of a Scrum or Pega BPM team is 5-7 members (excluding
business resources such as Process Owner and SMEs). Larger teams can easily
become bogged down by communication issues or lack of clarity.
77
Client IT Roles and Responsibilities
In addition to the core members, PRPC teams require the support of several
groups from the client IT organization.
78
Group Key Functions
Change Management • Own process changes, impact assessment, process
design, and implementation
• Steer projects through Enterprise Change
Management approval toll gates
• Overall status reporting, risk
mitigation/communication
• Define, track, and report on project controls and
metrics
• Manage user acceptance testing
Production • Level 1, 2, and 3 support for applications in
Support/Administration production
• Resolve user questions, troubleshoot problems,
triage and gather issue data
• Communicate/escalate production outages,
critical issues impacting users
• Hand-off to development support teams on issues
encountered in production
• Coordinate resolution efforts for critical
production issues
• Manage disaster recovery efforts and system
recovery after failures
Engagement Models
In the early stages of BPM adoption, you may not have all of the necessary skills
in-house to fill the required team roles. We recommend that you engage with
one of our Strategic Alliance Partners or Pega Consulting to ensure that the
new paradigm takes proper root. As your organization’s level of BPM maturity
advances, the appropriate resource mix will change accordingly.
79
Partner-Led or Pegasystems-Led Projects
We recommend that you entrust project leadership to one of our Strategic
Alliance Partners or Pegasystems during the early phases of BPM and PRPC
technology adoption, until you have achieved implementation maturity and
self-sufficiency.
At this point, your continued success depends on your in-house team taking
advantage of advances in Pegasystems methodology, tools, and product/
framework features. You typically bring in a small number of leaders from one
of our Strategic Alliance Partners or Pegasystems for this purpose.
80
Working with Our Partners
Pegasystems is committed to delivering joint solutions resulting in positive
outcomes – regardless of who leads or participates on the team. We see working
with our Strategic Alliance Partners as a triple win for the Partner, Pegasystems,
and the client. We have strong long-term relationships with our Partners built
on mutual trust and business integrity.
As members of the Strategic Alliance Program, our Partners commit to the same
level of expertise and certification that you receive from Pega Consulting. Our
enablement and certification programs provide our Partners with the latest
Pegasystems methodology tools, product enhancements, and platform features.
Their teams also have access to the Pegasystems Proposal Clinic, which validates
proposed solutions for business and technical fit.
For more information about the Pegasystems Partner community and the Strategic
Alliance Program, visit the Partners area on our web site at www.pega.com.
You can also use the Certification Checker tool on the PDN to verify someone’s
certification status.
81
Resource cost comparisons always impact the choice of the staffing model.
However, they should not be the sole decision criteria for offshoring. Hourly rates
for offshore resources are often considerably lower than those for comparable
onshore resources. However, realize that each offshore project manager,
technical lead, and business lead requires an onsite counterpart, which could
impact administrative and project management costs.
Successful projects that rely on significant offshore resources plan for excellent
communication and collaboration – social networking and other collaboration
tools, easy access to good audio visual facilities, and a schedule that ensures
opportunities for team member overlay. Pegasystems would be happy to share
its own experience internally with Scrum and this model.
82
Identifying the Right Project
Carefully select PRPC projects (or portions of projects) that are appropriate
for including offshore resources. Generally speaking, the best candidates are
those that are well-specified and self-contained. Clear specifications and loose
coupling reduce the risk of misinterpretation. Be sure that business objectives,
use cases, and process flows have been captured and are non-ambiguous, and
the application is not heavily dependent on other enterprise systems and data
sources.
Many of our clients use offshore resources to handle tasks such as QA, defect
fixing, enhancement requests, and upgrades. You may also choose to use them
effectively to develop interfaces to other systems, particularly when the solutions
use standard messaging formats or protocols.
Pegasystems has an Offshoring Score Card tool to help you assess fit for offshore
outsourcing. It incorporates criteria such as methodology, team size, flexibility of
timeline, and budget to objectively analyze suitability.
Resource Models
Some of our clients use a traditional resource model that includes an onsite
outsourced resource working with a team of 5-8 offshore developers. The
offshore team typically includes an offshore lead developer responsible for
overseeing the day-to-day deliverables. This individual is also the central
point of communication with the onsite technical team.
Other clients use a “pod” model in which they assign a team lead from their
internal staff to manage a small team of offshore developers. In this model, the
offshore team also includes a senior technical team lead. However, the model is
less hierarchical and places strong emphasis on regular communication with the
entire team. Because of geographical time differences, most clients that use this
model establish one or two daily check-in calls with their offshore team members
and a weekly project plan review. In the daily call (early morning if onshore is in a
US time zone), the team reviews assignments and deliverables from the previous
day and establishes new assignments.
As with all outsourced projects, effective governance and communication with the
offshore team is critical to success.
83
84
7
GOVERNANCE AND
TECHNICAL OVERSIGHT
85
7. Governance and Technical Oversight
Governance deals with the policies, procedures, and processes that allow
consistent control and verification so your organization can function to its fullest
potential. A properly functioning governance program ensures that the activities
under its control are ethical, the processes are effective and repeatable, and that
those performing those activities are accountable for their actions.
Types of Governance
When delivering the initial project, the team focuses on establishing the typical
governance that envelops all projects. Several types of governance affect the
success of Pegasystems projects.
86
Program Governance focuses on the relationship between business and IT. It has
a profound influence on the way solutions are implemented and their ultimate
success. A well-defined Program Governance program paves the way for
successful projects. A poorly-designed or non-existent Program Governance
program often leads to barriers or silos between business and IT, and a high
failure rate.
87
Governance Sponsorship
Successful governance requires proper sponsorship. Executive Governance
sponsorship establishes and funds the initiatives needed to implement corporate
governance. Program Governance sponsorship is typically business and IT
executive management. Sponsors ensure that there is a driving need for
governance activities. Because sponsors influence and remove roadblocks, they
must remain connected with an open flow of communication.
Project Governance
Project governance focuses on establishing solid lines of communication to ensure
that the business benefit is delivered and project scope, time, and budget are
controlled. Project governance is essential to the proper functioning of a PRPC
team. A solid governance model ensures that issues are resolved in a timely
manner consistent with the fast-paced, iterative nature of the methodology.
88
By raising issues early and resolving them in a timely manner, project governance
prevents issues from escalating into risks that might impact the project.
Controlling scope keeps the project in check and enhances likelihood of it coming
in on time and in budget. Ensuring compliance with the Guardrails prevents
unnecessary development and ensures that development progresses according
to best practices.
Roles Required
Members of the project governance team include:
• Project sponsors and executives
• Team leaders (TEL, PM, LSA)
• Invited stakeholders
Governance Meetings
The key activity in Governance involves conducting effective regular governance
meetings. Research shows that the success of governance is directly proportional
to the level of senior management commitment. Governance meetings that “get
things done” are a primary predictor of ultimate success.
89
Typical governance meetings should last an hour when held every two
weeks – less time if weekly and more time as critical milestones approach.
Meeting and
Frequency and Format Participants
Owner
Project Kickoff Roundtable and conference call to All project team
(PM & TEL) ensure all pre-project items are members
complete and review project plan
Regular Pulse (PM) Daily meeting PM, LSA, TEL
Status Update (PM) Weekly conference call to review VP IT, PM, LSA
status and issues, and keep the
project on track
Stakeholder Bi-weekly, additional by exception Business Sponsor,
Governance VP IT, PM, LSA
(Business Sponsor)
Project Kickoff
The Proposal provides the majority of input for the Project Kickoff Meeting.
Regular Pulse
Regular pulse meetings are essential to healthy team dynamics and
communication. These meetings, which are usually informal sub-team
get-togethers, provide the data input for Status Update meetings.
Status Update
Each sub-team prepares a brief status slide and identifies any challenges that
could impact delivery. Be sure to address any dependencies between sub-teams.
Unresolved items from this meeting usually become issues and Status Updates
are inputs to the weekly Status Report.
90
Stakeholder Governance
Stakeholder Governance meetings are critical to success. More than just status
meetings, the attendees are responsible for removing roadblock issues that
impede progress. These meetings provide bi-directional escalation paths and
force all parties to be in sync. A Governance Deck guides this meeting.
Governance Deck
Project Goals Detailed Phase Status
Project Team and Overview Issues
Key Performance Indicators Risks
Schedule Important Upcoming Events
Architecture Governance
Architecture governance is the process by which we manage the strategic
business and technical architecture. It defines and governs the overall Enterprise
Class Structure (ECS), reference library, reusable assets and strategy, blueprints,
standards, and best practices. The Architecture Governance team is typically a
virtual body that is led by the Center of Excellence (COE) and includes Enterprise
Architects, Business Architects, and the individual project LSAs. It meets at regular
intervals to review and discuss these elements.
91
Project LSA attendance at these meetings ensures a bi-directional communication
channel. It guarantees that all projects understand and adopt the enterprise
architecture decisions and standards, and ensures that individual project
challenges are raised early enough to be properly addressed.
Technical Oversight
Architecture governance is complemented
Reference
by project-level governance in the form of Architecture
terms of:
• Maintainability and extensibility
• Performance
• Defect density and quality of configuration
• Production readiness
The Lead System Architect (LSA) defines and oversees how the team addresses
Technical Oversight throughout the delivery lifecycle. The Project Manager
ensures that time for oversight activities is accounted for in the project plan and
communicated to the team.
Depending on the team size and dynamics as well as the project type and
methodology, the LSA may delegate some Technical Oversight responsibilities to
work stream leads. For example, consider a Scrum project with two different
Scrum teams executing Sprints in parallel. The LSA might delegate the
Configuration Review (an advisory service that is part of Technical Oversight)
to a technical lead on each team and review outstanding issues as needed. But
the LSA is ultimately accountable for the outcome.
Technical Oversight consists of eight areas. Successful projects define and embed
controls and quality criteria for each area in their day-to-day work practices. For
example, Scrum projects might include checks against each area mentioned in
their Definition of Done (DoD) for User Stories. Pega BPM projects might use a
document named Quality Assurance that summarizes the status of each area at
the Level 1 Use Case level.
92
Independent of your choice of methodology, we recommend that you implement
Technical Oversight of all eight areas for the daily work of your team. Set clear
objectives in each area and hold team members accountable for those targets.
This structure effectively achieves the objectives of Technical Oversight, and
establishes a homogeneous and repeatable configuration practice.
This chapter focuses on the project governance aspects of Technical Oversight. See
Chapter 11 (Build Management, Quality, and Performance) for information about
the PRPC tools and practices that support the other aspects – Unit Testing,
Guardrails, Performance Analyzer (PAL), and Error/Alert logs.
Support Requests
Pegasystems prides itself on developing a partnership with our clients, rather
than the traditional vendor/client relationship. Our Global Customer Support
(GCS) organization is an important part of this partnership that supports sound
Technical Oversight. Whether you’re implementing a single application or
engaged in an enterprise deployment, our GCS experts will provide you with
dependable best-in-class support. We are committed to getting the right people
involved to resolve issues as quickly as possible using our personalized approach
and issue escalation procedures.
93
The quickest way of engaging with GCS is to register a support request (SR) via the
online Pega Support Resource Center. It provides a single stop for submitting and
reviewing the status of your SRs. Follow these best practices to prepare your SR
for the quickest resolution:
• Login to the Pega Support Resource Center before you find any issues
to understand how to register an SR.
• Know the PRPC version, any Solution Frameworks and versions, and
any Service Packs that are installed on your system.
• Document the steps to reproduce the issue.
• Take supporting screenshots.
• Verify the scope of the issue by having others try to reproduce it using
their user accounts.
• If possible, ask your IT department to provide the log files and error logs
for the time period when the issue occurred.
• Verify with your IT department whether any scheduled events (such as
planned downtime) may be causing the issue.
The GCS Application where you enter online SRs offers a Subscriptions feature that
enables you to receive automatic notifications when a case is updated and regular
account summaries.
GCS involvement will not end until the issue is resolved to your satisfaction.
With more complex or integrated applications, distinguishing which system or
technology is the root cause of a support request can be complicated. GCS may
need to work with other vendors’ support organizations in order to resolve the
issue. They can facilitate this collaboration between vendors and participate in
team calls as needed.
The Pega Support Resource Center also provides access to a wide range of
product and technical information, discussion forums, Webinars, and more.
Visiting this site on a regular basis and using its resources will improve the
design of your solutions, ensuring better Technical Oversight and avoiding
potential pitfalls.
To access the Pega Support Resource Center, visit the Services area on our website
at www.pega.com and click on Support.
94
Configuration Review
A Configuration Review is a systematic examination of a PRPC application by a
peer or your Center of Excellence. Its purpose is to find and address mistakes
overlooked in the initial development phase in order to improve the overall
quality of the application and developer skills. You conduct Configuration Reviews
as a combination of informal walkthroughs, formal configuration inspections, and
reviews of PRPC-generated logs and reports.
Depending on the team skills and setup, type of solution, and project phase, you
review some or all of the rules created or modified since the last Configuration
Review.
Consider making a Configuration Review one of the criteria for the Definition of
Done for a User Story.
95
Governance through Advisory Services
Advisory services are “spot checks” performed on PRPC project teams throughout
the course of a project. Their purpose is to validate that the team is following best
practices, Guardrails, standards, and so on. Think of the collective rule book of
best practices, Guardrails, and standards as the legislative branch, and Advisory
Services as the executive branch, of technical and methodology governance.
The goal is to help your delivery teams build applications better, faster, and
cheaper by using the technology and tools in the best possible way. The results
are reduced project risk through a repeatable process, higher quality of work
product through following best practices, and faster delivery times through
leveraging reusable assets.
96
8
DEFINING AND MANAGING
SIZE/SCOPE IN AN
AGILE WORLD
97
8. Defining and Managing Size/Scope in an Agile
World
Most projects fail not because of a poor project development lifecycle, but
because of a poorly-executed project development lifecycle. Pegasystems makes
the project development lifecycle and its supporting tools intuitive, integrated
with PRPC, and easy to use.
We want project teams to focus on the project and not on the intricacies of the
project development lifecycle.
Successfully managing the size and scope of any project consists of defining the
scope correctly at the start and then staying consistent in that definition. Easier
said than done – especially on Agile projects. A good project development
lifecycle emphasizes the initial definition of scope or boundaries of the project,
typically in the form of business-dictated requirements. The team must then
design, implement, test, and deliver those requirements to the business.
No matter what the tool or project, there is usually a sequence of events that
defines how the project will operate, beginning with project initiation and ending
with project delivery. This sequence can be very conventional (Waterfall) or
very iterative (Agile). However, it always includes the basic elements of project
identification (scoping), project definition (design), project execution
(construction), project verification (testing), and delivery.
98
To capture the details, you use the Application Profiler (the tool) to create an
Application Profile (the definition) for the application. The Application Profile is
a collection of information that specifies the business processes, case types, use
cases, requirements, and other processing elements associated with
implementing the application.
The goal of creating the Application Profile is to focus team discussions and get
the project started in the right direction. Business analysts, lead architects, and
other team members work together to iteratively create the Application Profile.
This collaborative effort increases the likelihood of a successful delivery because
core business questions are asked and discussed, and the answers are captured in
one place – the Application Profile.
Project Sizing
Sizing a PRPC project requires the well-defined project scope that you obtain by
completing the Application Profile. Armed with this information, use our PRPC
Project Effort Sizing Tool to estimate the scope of the project in terms of hours,
resources, and schedule. While simple to use, this tool collects and processes
extensive data to provide detailed information about the project size.
The PRPC Project Effort Sizing Tool is a Microsoft® Excel® spreadsheet with several
interactive worksheets. It comes in two types (Scrum and Pega BPM) with similar
capabilities. We have evolved this tool over many years to incorporate heuristic
project information and requested capabilities.
The summary views provide an overall snapshot of the project and the most
relevant information for project planning. Teams often use them to create reports
for managers and project approvers.
99
Scrum Sizing Summary
The Scrum Summary Worksheet focuses on the number and duration of Sprints,
and total hours.
100
Using the PRPC Project Effort Sizing Tool
Most of the data entry required to use the PRPC Project Effort Sizing Tool is
automated. Information from the Application Profile is directly transferred into
the tool and calculations are automatically applied to establish an initial baseline.
However, you must manually enter some additional information (start date,
resources, staffing model, etc.) that is not stored in the Application Profile in
order to determine the total work effort and schedule.
After you enter the additional data, the spreadsheet updates its calculations to
provide a staffing model, total hours, and schedule.
Once defined, the Objectives provide the development boundaries (the scope) to
which the team must adhere. There are many opportunities for communicating
the scope throughout the project lifecycle and thus many opportunities to exceed
it (often called scope creep).
101
In theory, the closer your project is to a Waterfall model, the more likely it is to
experience scope creep.
Our Agile project methodologies and the supporting PRPC tools provide some
pitfalls that can inadvertently make it harder to manage scope. Interestingly,
some of the positive precepts of Agile are also pitfalls of scope creep. Vigilance
and careful monitoring are the secret to successfully avoiding it.
PRPC projects are easier to define, size, and manage because the platform, its
built-in tools, and our methodology frameworks were purposely designed to
support managing objectives. The key to success is the team’s ability to execute
projects efficiently and consistently, which depends upon all members being
enabled in PRPC, its tools, and the selected methodology.
102
9
PROGRAM AND
PROJECT MANAGEMENT
103
9. Program and Project Management
Managing a successful PRPC solution delivery consists of coordinating two
different (but related) initiatives.
• Program Management. As part of evaluating the target business need
and vision for change, you identify the high-level objectives for the PRPC
solution and the expected benefits. Program management consists of
laying the foundation for, coordinating, and governing the successful
build-out of the overall solution.
• Project Management. Based on the PRPC solution objectives, you size,
shape, and organize the solution delivery into an iterative series of
projects (Sprints/slivers). Project management consists of managing
and delivering the initial and subsequent Sprints/slivers.
PRPC provides purpose-built tools to support both perspectives. However, the key
to success is how you approach the process of establishing the overall business
vision and defining the iterative steps by which you will achieve it.
104
Close collaboration between business and IT means that you are the client and IT
functions as an extension of your business team. By establishing this joint venture,
the business and IT organizations build an environment for collective success.
This approach does not necessarily mean that IT reports directly to the business.
However, it illustrates the close ties between business and IT that are required
for a truly collaborative environment.
Next you identify a Business Value Indicator for each objective in order to
quantify the return that it will bring to your enterprise – for example, cost
savings, additional revenue, or some other measurable value. This value helps
you determine the relative priority of the requirements to be addressed and
in which order to achieve them.
105
Based on these metrics, you organize your objectives into a series of Strategic
Initiatives focused on five categories of business improvement.
Category Description
Process Improvement Remove manual process steps.
Process Consolidation Consolidate like processes into one common process.
Enterprise Vision Establish a vision of the future enterprise regarding
market competitiveness.
Process Reuse Create core capabilities that can be shared across the
enterprise.
Process Modernization/ Create straight-through processing.
Automation
Now you align your initiatives with a high-level timeline to establish a Solution
Roadmap for future development.
Finally, you break down your strategic initiatives into an iterative series of smaller
projects (Sprints/slivers) that deliver value in incremental 60-90 day bursts. By
decomposing the initiatives into business-focused projects, you manage individual
project scope. This approach reduces the outdated requirements and unused
features risks associated with “Big Bang” rollouts.
The longer the project development lifecycle, the greater the risk of implementing
stale requirements.
106
Our Methodologies and Tools
Sound program and project management consists of using PRPC technology and
your selected methodology to successfully deliver a comprehensive solution. They
cover the implementation of your strategic vision and its iterative projects, and
coordinate the day-to-day project events that will transform your business
requirements into a fully functional, high-quality solution. Therefore, selecting
and applying a methodology that fits your resources and is well-supported by the
enterprise is one of the most important criteria for a successful delivery.
The concept of an Agile solution delivery means many things to many people. For
Pegasystems, Agile is an embedded process in a methodology that can adapt to
and handle real-time business change. For projects where change is an inevitable
part of what is expected, a methodology that supports change at its core is the
optimal solution.
PRPC is seldom the only effort within a corporate program or initiative. Therefore,
you must coordinate PRPC solution delivery in an environment where different
methodologies and technologies are used, often across departments and
divisions.
Be sure that your project plans support both the PRPC development efforts and
the timing/scheduling associated with initiatives such as external interfaces,
corporate testing requirements, and program production schedules.
107
Pegasystems provides the following tools to facilitate sound project management.
While specifically designed to make PRPC projects efficient, they also work well
with non-PRPC projects or projects with both PRPC and non-PRPC components.
• The PRPC Project Effort Sizing Tool is a resource for scoping and sizing
projects. It determines PRPC project effort in hours and relates the effort
to a particular phase or Sprint. Using the hours, resources, and schedule
from this tool, you can produce a close approximation of the schedule
and resources for effort estimates.
• The Project Management Framework (PMF) is a flexible application for
planning and controlling PRPC projects. PMF is especially well-suited for
PRPC projects that use Scrum or Pega BPM, although it works with any
methodology.
You can run PMF as-is out of the box, or extend it to include new capabilities or
interfaces with other systems.
108
Tracking Projects in PMF
For Scrum projects, the Scrum Board in PMF is the most useful feature for viewing
team progress. It displays the content of the Sprint in an easy-to-use grid format
so you can view, discuss, and interactively update the status of User Stories,
Tasks, Bugs, and Issues. The Scrum Board has many automated features. It also
helps geographically distributed teams stay on the same page and have
informative Daily Standups and Sprint Reviews.
For non-Scrum and Pega BPM projects, PMF provides a tree-like project view that
shows a more traditional work breakdown structure. It provides a summary view
of the work that needs to be done.
109
Using Direct Feedback Capabilities
Our unique Direct Feedback feature enables you to capture issues directly in
PRPC applications. To enable this feature, you make a simple configuration
change in each environment (Development, QA, Production, etc.) where you
want to use it. Users can then access Direct Feedback with a single click directly
from the application portal. You simply drag and drop its pushpin icon to any
PRPC application, enter a description of the problem or issue, and/or capture a
screenshot. You send that information as a message to PMF, which uses it to
create a work object that can be triaged for resolution or rejection and closure.
You can also create Direct Feedback items directly in PMF. This option is useful if
your development system is not connected to PMF or you do not have access to
the development system.
110
10
HOW TO MEASURE
SUCCESS
111
10. How to Measure Success
In order to measure program or project success, you must first define what you
are aiming for and then assess whether you achieved it. Success criteria are
accompanied by Key Performance Indicators (KPIs) that quantify achievement
of the business objectives. In addition, other less quantifiable elements are often
vital for a successful project. Such Critical Success Factors (CSFs) can make or
break the success of the solution. For example:
• KPIs
- Reduce call handling time by 20% within 3 months.
- Increase average product per customer by 15% by end of year.
• CSFs
- Projects will follow the selected methodology.
- Project resources have been enabled on the PRPC technology.
“If you don’t know where you’re going, you’ll end up someplace else.” …Yogi Berra,
former New York Yankees baseball player.
112
• Thought Leadership. The team followed the selected implementation
methodology and provided thought leadership to all participating
resources.
• User Satisfaction. The system is perceived to realize the anticipated
business benefits and met the defined success criteria (KPIs, CSFs).
Dimension Affect
Time Activities can take more or less time to complete depending on
factors such as the number of people assigned, experience, skills,
and so on. Failure to meet deadlines can create adverse effects.
Most often, the main reason for failure is lack of resources.
Cost Budgets ensure that solutions are delivered at or below a certain
cost. Project managers may need to allocate more resources in order
to meet a deadline with a penalty of higher project costs.
Scope Scope refers to the implementation outcome, consisting of a list of
deliverables that need to be addressed by the team. A successful
project manager knows how to manage both the scope and any
change in scope that impacts time and cost.
Quality While not part of the triangle, quality is the ultimate objective of
every solution delivery. High quality often comes with a high cost.
Conversely, using low quality resources to meet deadlines may
jeopardize overall project success.
113
For more information about the Product Management Book of Knowledge
(PMBOK®) and its associated disciplines, go to the Project Management Institute
(PMI®) web site at www.pmi.org.
While the triple constraint (time, cost, scope) is necessary, it is not enough.
1
The following factors also contribute to success :
• Benefits realization • Client/user adoption
• Stakeholder and client • Quality of delivery
satisfaction • Meeting governance criteria
• Meeting business case
objectives
Benefits Realization
With increased emphasis today on the expected business results and outcome,
perhaps the most important success factor is the return that you expect to realize
after implementing a new application or technology. We call this the “R” or
return. Is the “R” compelling enough to go forward with this solution, or does
another opportunity offer a better return on the investment? Although a solution
might have been implemented on time and under budget, and met all the
requirements, it cannot be considered successful if the intended benefits
specified in the business case were not realized. This is the paramount criterion
in measuring success.
1
Responses of stakeholders based on a survey conducted by the Projectize Group LLC in 2008/2009.
114
Be as specific as you can when defining your KPIs. For example:
• Improve the account opening process by 50% within 1 month.
• Increase retention of our premium customers by 30% over the
next year.
• Raise the Net Promoter Score® (NPS®) by 5 points by next quarter.
• Raise employee satisfaction by 10% at the next employee survey.
The Net Promoter Score® (NPS®) is an industry standard that many leading
companies use to measure and improve customer loyalty. This metric can help
you drive improvements to support profitable growth and benefit realization.
NPS® is based on asking the simple question of “How likely is that you would
recommend [your company] to a friend or colleague?”. If you are using NPS®
as a corporate or employee satisfaction metric, having KPIs associated with
improving NPS® is crucial.
“Great results! Thank you all for the hard work and great team effort. Now let’s go
make some money!” …Executive business sponsor, Vodafone Group.
115
Stakeholder and Client Satisfaction
You must also consider stakeholder and sponsor satisfaction as a success factor.
Although the implementation may have delivered on all stated requirements,
how satisfied was the business with the final solution? Take care to manage
stakeholder expectations throughout the implementation lifecycle. This process
starts at the beginning with capturing requirements accurately and continues to
the end when the expected benefits are realized. The team should strive to meet
or exceed these expectations.
The sponsor’s perception of the result is crucial since by definition they have the
biggest stake in the success of the solution. Sponsors are also footing the bill and
being held accountable for the outcome. Having regular checkpoints and keeping
stakeholders informed on a regular basis ensures that expectations are set
properly and there are no surprises at the end.
A business case analysis that includes the expected “R” helps decision makers
prioritize efforts. Measuring quantifiable objectives such as ROI, NPV (net present
value), and IRR (internal rate of return) is straightforward. Measuring qualitative
metrics such as improved user satisfaction and ease of doing business can be
more difficult.
Pegasystems uses the 6Rs of case automation that drive work to done as a primary
objective for all PRPC solutions.
116
Client/User Adoption
Usability and user adoption of the solution have a direct impact on satisfaction.
Quite simply, the business people who use the solution will determine its success.
If they are not happy with how the application looks and feels, or find it more
cumbersome than what they currently have, they will not use it. Teams must have
sufficient input and feedback from your business to realize any benefits. Getting
these key stakeholders involved from the start conveys a sense of ownership,
resulting in a more targeted and complete solution.
The quality of your UI significantly impacts the user experience and therefore
solution success. Be sure to involve UI experts on your team as early and often as
possible. See Chapter 6 (Successfully Staffing Your Projects) for more information.
Remember that putting usability first and including user interface adoption as
part of the measurement criteria are critical to a successful PRPC implementation.
Be sure to incorporate usability reviews and user experience best practices
workshops to ensure user satisfaction and adoption.
Quality of Delivery
When evaluating project success, remember to consider how well the project was
managed and implemented. Project metrics do not always tell the whole story.
Was the project manager effective in leading the team? Did the team provide
thought leadership throughout the implementation cycle? How were the quality
and completeness of the project documents and deliverables? How good was the
communication?
These groups should also provide artifacts that projects can leverage to follow
PRPC best practices and Guardrails and to adhere to the Scrum or Pega BPM
methodology. Be sure to inform the team at the beginning that you will conduct
a retrospective at the end of the project and what topics will be covered. Team
members can then self-assess and improve upon them throughout the project.
117
Pegasystems Strategic Alliance Partners and Pega Consulting resources can provide
assistance based on their experience with and access to Pegasystems templates
and reference materials.
Depending on which methodology you use, the requirements will differ from
company to company, and in some cases from project to project. Projects that
use Scrum or Pega BPM can leverage features built into PRPC that promote
compliance with governance criteria.
Partner or client methodology constraints may prevent some PRPC projects from
employing DCO. However, those that do ensure project success by saving time,
effort, and money, while maintaining quality.
2
COBIT®: Control Objectives for Information and Related Technology framework, created by ISACA.
ITIL®: Information Technology Infrastructure Library is a set of practices for IT service management.
BSC: Balanced Scorecard is a strategic performance management tool. Six Sigma®: developed by
Motorola to improve process quality output by removing defect causes and minimizing variability.
118
Remember, the success of a project is typically just one step in the strategic
direction of your organization. A single project (Sprint/sliver) is usually part of
a larger, transformational business initiative. Sprints/slivers can be organized
by a particular business process, organization, or geography. Subsequent
Sprints/slivers leverage previous ones.
119
120
11
BUILD MANAGEMENT,
QUALITY, AND
PERFORMANCE
121
11. Build Management, Quality, and Performance
PRPC provides an innovative, high-productivity portal for developers called the
Designer Studio that gives you easy access to dozens of tools and wizards. It
groups developer gadgets into landing pages that simplify navigation and
management at the application level.
MDA refers to the PRPC architecture in which a single model drives both
design-time changes and runtime behavior. A rule configuration change has an
immediate impact on the runtime result. You don’t need to migrate rule changes
between “business modeller” and “process manager” environments.
A comprehensive set of PRPC features and Designer Studio tools promote sound
build management, quality, and performance practices. They directly support our
project governance guidelines for Technical Oversight.
122
Rule Management Features
PRPC integrates configuration management into the development environment
through a variety of rule management features.
Rule Checkout
Rule History
Rule and Application Versioning
Rule Checkout
The Rule Checkout facility allows a development team to evolve an application in
a coordinated way. Once you check out a rule into your personal RuleSet, that
rule is locked and can no longer be inadvertently modified by another team
member until you check it back in. You can test new or changed functionality in
the checked-out rule while everyone else uses the prior, checked-in version.
For greater control over the development process, you can also execute an
approval work flow upon rule check-in. You can use this feature to ensure that
changes to multiple related rules are checked in together, or to support a second
level of unit test in a safeguarded development environment.
Rule History
The Rule History feature automatically keeps a copy of each rule as it is checked
in. It enables you to undo a recent rule change by restoring an earlier state of the
rule. Note that rule history is kept only within the RuleSet version. It is reset when
you save a copy of the rule in a new RuleSet version.
You can also associate RuleSet versions with an effective start date. You can use
this date to establish a cutoff date for RuleSets, allowing for historical processing.
For example, setting the RuleSet effective date to October 1, 2012 would execute
only those rules that were effective at that date. (This effort is also known as
“as-was” processing.)
123
Release Management Features
PRPC simplifies application version control with a variety of release management
features.
For Scrum projects, QA resources are part of the Scrum team. Development and
QA happen throughout the Sprint, and you lock the RuleSets at the end of the
Sprint. For Pega BPM projects, a dedicated team performs QA. You schedule QA
releases (locking the RuleSets each time) on a regular basis based on the time
allocated for each QA testing cycle.
We recommend time-boxing iterations for both Scrum and Pega BPM projects.
A fixed release schedule will not be affected by the missing scope of any User
Stories that don’t make it into the release.
If you deem the reduced scope not release-worthy, skip the release and wait for the
next “release train” to put your configuration into production.
124
Production support releases begin once the application is stable (or “steady
state”). They should not happen more than once every other week. Immediately
after an application release, the frequency of production support releases may be
higher. At this point, always leave room in your versioning model to allow for one
or two emergency releases per week. In steady state, allow for one emergency
release a week.
Parallel Development
Phased application development leads to staggered overlapping streams of
Sprint/sliver development and testing. Once you complete development for
Sprint/sliver n and release the configuration to QA, most of the development
team moves on to Sprint/sliver n+1. Only a small number of developers remain to
fix Sprint/sliver n defects. When a defect is found and addressed, you propagate
the fix to later Sprints/slivers to ensure that new versions of “unfixed” rules don’t
hide and override the defect fixes in earlier ones.
Multiple applications that are developed at the same time often share common
components and frameworks. You must correctly sequence the implementation
of common Use Cases to avoid delays. Make sure that common Use Cases are
implemented before you implement application-specific Use Cases that depend
upon them.
Application versions also enable you to add branches and create branch RuleSets
to support parallel development. A branch is an isolated area in which teams can
do development without impacting others. Once branch development is complete
and unit tested, you merge the branch back into the trunk (or main) RuleSets.
You can achieve very efficient parallel development of three, four, or even more
applications as long as you leverage the PRPC branch and merge capabilities.
125
Quality and Testing Features
Designer Studio provides a range of powerful tools that improve configuration
quality and testing.
Depending on your methodology and project type, you can use various methods
to define and execute unit tests. In its simplest form, a unit test consists of the
definition of actions, their associated input, and expected results. Capture the
outcome of the unit test execution along with the test definition, and include
the date and name of the tester.
Experienced teams working with an Agile approach might include the test
definition and outcome as part of their Definition of Done. As a best practice,
group unit test definition around deliverables. For example, associate a unit test
with a User Story when using Scrum or with a Use Case when using Pega BPM.
Storing test cases with each unit provides living documentation of the application.
126
As in any development environment, the number of defects in a QA release will
go down if you properly unit test. Unit testing gives you confidence that individual
units of configuration are fit for use. A unit is the smallest testable part of an
application. In PRPC, the unit is one rule – a decision table, a decision tree, an
activity, a flow, and so on.
PRPC provides a Run Rule feature for unit testing every executable rule type. It is
toolbar-accessible from an open rule. Provide test data, run the rule, review the
results interactively and, if necessary, re-test.
Your goal for the project is to have no unjustified warnings. The LSA defines the
approach and policy for addressing Guardrail warnings. One method is to include
their resolution in the Definition of Done.
127
Automated Unit Testing (AUT)
PRPC provides built-in support for automated unit and regression testing of
applications. The Automated Unit Testing (AUT) feature saves time, simplifies
testing, and helps to ensure that changes do not introduce unexpected and
undesired results. As a result, you can be more agile about determining when
corrective action is necessary within your development process.
You access AUT directly from a rule form. It enables you to:
• Capture and store test data with the units (i.e., rules) being tested.
• Store the test results as a baseline.
• Compare test re-run results (such as after a rule change) to the
baseline and review any differences.
Some rule types (such as decision tables) enable you to auto-generate all possible
test cases for the rule, increasing the speed of testing and ensuring that you don’t
overlook any test cases.
By allowing you to combine multiple tests into test suites, AUT enables you to turn
unit testing into more comprehensive regression testing.
128
Application Performance Tools
Even the best-looking car would not be fun if it did not drive fast. The same is
true for systems. Even with the most user friendly and ergonomic design, if
the performance is poor it’s unlikely that the user experience will be great. For
systems with large straight-through processing volumes, poor performance can
become a major obstacle if transactions can’t be processed in the allotted time.
PRPC provides several tools to help you uncover, detect, and resolve performance
issues in your application. You access these debugging and profiling tools in the
Designer Studio.
129
A typical PAL report provides a vast array of statistics to help you identify and
diagnose performance problems.
Excessive reads of the storage stream (known as the BLOB), excessive CPU time, or
excessive number of interactions between browser and server may all indicate
configuration problems.
PAL reports also establish a baseline for the current configuration. As the
configuration is changed, you can compare previous and current reports to
quickly assess performance impact.
PAL readings are not intended to provide definitive answers about performance
problems. Instead, they highlight processes that fall outside of the norm and
therefore warrant closer inspection. We have guidelines that you can use as a
baseline. In the context of each project, the LSA reviews and defines finer
thresholds as needed.
130
Database Tracer
PRPC database performance is a significant factor in overall performance. It
affects response time for interactive browser-based users, the turnaround time
for services, and system throughput. Database Tracer enables you to debug, trace,
and analyze requests from the server to the PRPC database. You can configure it
to compile a trace of all database requests from your session or to generate a
system-wide trace of all database requests.
To interpret the large amount of Database Tracer output, use Microsoft® Excel®
software with Pegasystems macros that load, analyze, and organize the data to
simplify analysis.
Performance Profiler
Performance Profiler determines the amount of time being spent in each
activity. This tool provides more comprehensive performance data than either
Performance Analyzer or Database Tracer. You can trace every execution of
activities, when conditions, and data transforms in all RuleSets in all threads
of your requestor. You can also use it to profile another requestor or to profile
all processing on all nodes.
Performance Profiler produces a comma-separated value (CSV) file that you can
open in Microsoft® Excel® software.
131
Monitor your log files closely in all system environments (development, QA, etc.).
Many errors and exceptions may not noticeably impact the user experience – at
least, it may seem so during unit testing. However, a failed call to a connector, a
missing or inconsistent rule, or a null pointer exception can significantly impact
application quality.
In addition, keep your log files clean by analyzing and addressing the issues raised.
The presence of many errors has a tendency to destabilize or slow down the
system. In addition, logging errors and stack traces are resource intensive. A log
file flooded with error messages and exceptions may make it difficult to hone in
on the real issues.
The presence of many issues in the logs on a development system may be due to
the nature of development activities. However, the logs in higher environments
should contain no errors, exceptions, or alerts. Record, analyze, and fix any issues
uncovered during QA, UA, or load testing.
Recommended
Tool Purpose
Frequency
Run Rule button Unit testing of individual rules Before every rule
check-in
My Alerts gadget View alerts generated by the As needed, when a
current application pop-up message
indicates an alert
was triggered
Guardrails tool Assess compliance with best Once a week
practice guidelines including
optimal reuse, maintainability, and
system performance
Database Tracer Debugging As needed
132
Recommended
Tool Purpose
Frequency
Performance Identify performance bottlenecks Once a week
Analyzer (PAL),
Database Tracer,
Performance Profiler
PegaRULES Log Analyze error/exception and alert Once a week
Analyzer logs
Rule Security Identify security vulnerabilities to At least once before
Analyzer malicious attacks beginning testing
133
134
12
MAXIMIZING YOUR PRPC
RETURN ON INVESTMENT
135
12. Maximizing Your PRPC Return on Investment
Your individual PRPC solutions have a significant impact on the targeted lines
of business. However, establishing an enterprise strategy to support your BPM
and PRPC efforts enables you to realize maximum return on your investment.
A cross-solution, cross-organization architecture provides an optimal environment
for efficient solution delivery and quick response to business change. In our
experience, the following initiatives are key success factors:
• Establishing a Center of Excellence (COE) to provide a coordinated
BPM/PRPC strategy and architecture.
• Implementing an Enterprise Reuse Strategy to foster reusing,
instead of rebuilding, common assets.
These efforts typically ramp up as your BPM and PRPC environment matures.
Every organization’s journey along these initiatives will be unique, but share a
common foundation.
“Almost half (49%) of enterprises that reported clear and measurable benefits from
their BPM efforts had a BPM COE in place. Project performance related to
enterprise goals also appears to be directly linked to having a BPM COE.
Specifically, 67% of enterprises that reported their BPM efforts significantly
exceeded their goals had a BPM COE.” …BPM Has Become Mainstream by Ken
Vollmer. Forrester Research, 2008.
136
COE Team and Charter
The enterprise COE charter comprises the services, functions, tools, and
metrics that its team members use to select, prioritize, manage, govern,
communicate, and execute PRPC projects. For best results, establish your COE
as a cross-functional team that supports all lines of business in planning and
implementing PRPC initiatives. A COE typically consists of three main parts,
each with a distinct focus, that collectively support one or more project teams.
All COE team members do not necessarily need to be full-time roles. The scope and
number of your inflight projects will influence your COE staffing levels.
A COE is not a “one size fits all” model. You need to create a structure that will
work for you. In some cases, a single COE may be able to meet the needs of the
entire organization. However, where you have very distinct needs that vary by line
of business or geography, we have found that establishing a federated model with
a central COE that supports several individual COEs works well. Lines of business
or geography that drive very different PRPC implementations would have their
own COEs. A corporate COE would serve as an umbrella organization across the
COEs and maintain corporate best practices, artifacts, reusable components,
and so on.
137
COEs deliver three main types of services: People, Process, and Technology. We
believe that the COE should avoid putting its own resources on the critical path of
business initiatives or get directly involved in project scoping, requirements
definition, or development. Instead, its role is to provide thought leadership for
and govern business and IT initiatives to ensure that your organization’s standards
and best practices are maintained and followed.
For more information on or assistance with establishing a COE, visit the PDN area
on our web site at www.pega.com.
138
Implementing an Enterprise Reuse Strategy
As you grow an inventory of PRPC business and technical processes, your
organization should move towards an approach of enterprise asset reuse – that is,
aggregation and integration to deliver new solutions – rather than building every
application from scratch. Well-formed PRPC solutions are part of this reuse
strategy in that they are able to both contribute to and draw from an asset
repository. This inventory of reusable assets becomes the engine that moves your
business and ties it together in a consistent, reliable, and transformative way.
The degree to which you realize these benefits is an indication of the maturity of
your enterprise architecture. It reflects how you are able to improve productivity,
respond to change, and manage risk.
139
As your BPM strategy matures, you must move away from ad hoc (and largely
individual) reuse initiatives in order to achieve the maximum return on your
PRPC investment.
Strategy
Driven
Change strategic and operational
Domain structure of organization.
Future markets and products
Reuse Oriented served with malleable assets.
Value Emphasis on domain to
identify and design business
Systematic assets for reuse.
Assets become coherent.
Planned, orderly process.
Ad Hoc Reuse of assets other than code.
Infrastructure to support reuse.
For PRPC to be a transformational technology with broad impact, you must mature
along this dimension in both business and technical expertise.
140
Benefit How
Reduced Time to Reusing assets greatly reduces the associated time to
Market develop and test, delivering solutions to users sooner.
Reduced Defect Reused assets have already been developed, tested, and
Density are in production, passing on those benefits to the new
application.
• PRPC Enterprise Class Structure (ECS): Provides the foundation for asset
reuse by establishing the class pattern that all PRPC applications will use.
It reflects your current organization structure while considering future
growth, and allows applications to behave appropriately according to
their placement in the organization.
Building for reuse may seem to require more time upfront. However, it saves time
and cost later because you don’t need to build similar components multiple times.
141
142