Delivery

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

Editorial by: Cover and Production by:

Lisa Pyle Alex Quigley

All trademarks are the property of their respective owners.

Apache™ and Apache log4j™ are trademarks of The Apache Software Foundation.
COBIT® is a Registered Trade Mark of ISACA and the IT Governance Institute.
ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark, of
the Office of Government Commerce (OGC) and is registered in the US Patent
and Trade Mark Office.
IBM®, Rational Unified Process®, and RUP® are trademarks of International
Business Machines Corporation, registered in many jurisdictions worldwide.
Microsoft® and Excel® are trademarks of the Microsoft group of companies.
Net Promoter®, Net Promoter Score®, and NPS® are trademarks of Satmetrix
Systems Inc., Bain & Company, and Fred Reichheld.
PMBOK® and PMI® are trademarks of the Product Management Institute.
Six Sigma® is a registered trademark and service mark of Motorola, Inc.
Scrum Alliance® and the corresponding logo are service marks of Scrum Alliance,
Inc. and are used with permission.

© May 2013 by Pegasystems Inc. Version 2.

Cover Art: Franz Marc, “Stallungen”, 1913.

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.

Prominent independent industry analysts such as Gartner and Forrester recognize

our unified software platform as leading across multiple categories including
Customer Relationship Management (CRM), Case Management, and Business
Process Management (BPM). However, it’s the execution and thought leadership
elements of our company and Strategic Alliance Partners that have driven our
continuous growth and contribute to the success of our clients who use our Build
for Change® technology.

Thought leadership is “the persuasive presentation of a well-informed opinion for

the purpose of positive change.”

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.

Quite frankly, executing crisply and providing thought leadership requires an

investment on your part. When done correctly, the outcomes are vastly
rewarding. Master how to deliver PRPC solutions the right way. You will be
equipped to help organizations adapt to change, continuously improve, and
transform the way they work as we collaborate with you on the journey.

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.

Pega Consulting is constantly refining our delivery model as we at Pegasystems

enhance our products, develop new tools, and learn from each successful
implementation. We value your input and welcome feedback from across our
entire ecosystem, including our Partners, Product Management, Engineering,
Support, Training, and our clients. We assess what is working and what is not,
and incorporate the views of our stakeholders.

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.

The fundamental purpose of our technology is to enable your business community

to revolutionize your organization in order to optimize your customers’ experience
and automate operations.

A Typical Pegasystems Implementation

To illustrate the advantage we offer, let’s examine how a typical Pegasystems
implementation proceeds. With our model, you establish a vision for business
change and then deliver the solution in a series of small iterative projects
(referred to as Sprints or slivers) that each build upon the previous ones.

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.

A Revolutionary Solution Delivery Model

Rather than being a separate step in a different tool or paradigm, automated
and simultaneous modeling of business rules and business processes is a key
differentiator of PRPC. At the start of the project, you capture business processes
directly into PRPC using its DCO features. The team then elaborates upon,
constructs, and ultimately releases the business process into production. Business
and technology professionals collaborate in the same environment that describes
the process and integrates the rules that drive and automate the process. PRPC
also easily connects to back office data stores and Web services and integrates
them into workflows, providing automation where possible and improving
business process efficiency.

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.

Directly Capture Objectives (DCO)

DCO covers all aspects of building a solution – business rules, business decisions,
information models, reports, user interface, integration, and so on. It enables
business and technical resources to collaborate on designing and modeling
processes and rules for an application. They both use DCO to write their
requirements directly into PRPC and model their needs in real time. The business
leads the definition of objectives, by describing each process, its requirements,
how it fits in the strategy, and the benefits to be achieved.

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”.

Changing Business Rules on Demand

As a business leader, you want to be able to adjust your business processes
without involving developers. After all, they are focused on delivering the
next Sprint or sliver to add incremental benefit. PRPC solutions give you the
flexibility to own and directly modify your business rules and decisions in
production – in real time – as needed.

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.

The Situational Layer Cake

Our Situational Layer Cake enables you to build solutions in the context of your
business. Development begins with the core PRPC platform and Pegasystems
industry-standard frameworks. You build specialized dimensions of your business
(perhaps layered by product, geography, and customer type) upon that
foundation. At runtime, PRPC applies the most appropriate asset based on
context (that is, situationally). Specifying only what is different for your business
accelerates time-to-market. Organizing dimensional logic in layers maximizes
reuse.

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.

Build for Change®

Ironically the true constant of business process is change, either to adapt or
improve. PRPC effectively manages the change process for both the iterative
development of the business process and for the promotion of rules into
production by your business community. This process is referred to as authoring.
It enables you to modify rules that are integrated into the application and
influence its behavior without involving developers. Rules to be modified are
typically related to business initiatives or regulation. For example:
• You have a threshold rule that sets a transaction value at $10,000 to
escalate processing to a supervisor. Based on daily throughput, your
business should be able to determine that the value may be better set
at $20,000 and make that change.
• You have decision rules that represent state variations in insurance
regulation. When regulations change, your business should be able to
directly change the rules that govern how claims are processed.
In PRPC, you place the rules that define the relevant business logic in a RuleSet
that contains rules approved for modification in production. You also designate
someone (typically a supervisor) who is allowed to modify them. Your business
can then monitor and maintain these rules as needed, without involving a
technical resource.

PRPC enables business and technology to collaborate successfully in a single

environment in order to deliver solutions and Build for Change®.

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.

PRPC inherently enables the delivery of smaller more manageable components

over time. These working increments of the application may be eligible to go into
production and do not necessarily have dependencies on other components or
capabilities slated to be released in future increments.

Agile methodologies facilitate the production readiness of these components

by enforcing best practices and standards, and ensuring that a high quality,
production-ready component is configured. Putting smaller functioning
increments of the application into production early allows for greater business
value to be realized sooner and made accessible for the business to leverage
and gain an industry competitive advantage.

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.

“Methodology is generally a guideline system for solving a problem, with specific

components such as phases, tasks, methods, techniques, and tools. It can be
defined also as follows:
1. the analysis of the principles of methods, rules, and postulates employed
by a discipline;
2. the systematic study of methods that are, can be, or have been applied
within a discipline;
3. the study or description of methods.
A methodology can be considered to include multiple methods, each as applied to
various facets of the whole scope of the methodology.” …Wikipedia.

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.

Supporting Factors for Success

The decision to use a particular methodology is not easy, as you have hundreds
from which to choose. Choosing one methodology over another does not
necessarily mean that the project risk goes up or down, or that the project is
doomed to fail or destined to succeed. Several additional factors contribute to
success apart from the methodology you select.

Factor Why It’s Important

Enabled A critical success factor. All team members should be trained on
Teams both the technology with which they will be implementing the
solution and the implementation methodology.
Enterprise Teams that simply take step-by-step direction tend to deliver
Support solutions that may appear to meet the requirements, but don’t
produce the intended results. In contrast, providing enterprise
support empowers your teams to deliver better results. It
encourages them to question the intent of requirements in
order to ensure their validity and implementation.
Collaborative Teams that work in an isolated manner miss the value of
Development interpretive discussions with and perspectives of others. “Just
send over your requirements and I will build it” mentalities have
shown the danger of this approach. Collaborative teams work
more cohesively towards common goals. The “he said, she
said …” excuse-driven process gives way to a “we have decided
as a team to …” collaborative approach.
Enterprise Consider the nature of your business processes when choosing
Factors a methodology. Some enterprises may require heavy processes
in order to ensure strict compliance levels. While seemingly
inefficient or burdensome, they may be necessary to ensure a
high quality product. For example, a lifesaving drug or device
requires a rigorous testing cycle with little tolerance for defects
or miscalculations.
Tolerance for Some methodologies and organizations are better suited to
Change adjust to real-time change. Change is inevitable; the
methodology and its guiding process dictate how you handle it.
Projects that account for change have a greater probability for
success than those that do not.

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.

Go As Agile As You Can

We recommend that you deploy the most Agile methodology that your
implementation team can adopt without increasing risk to an intolerable level.
The combination of our Build for Change® technology with an Agile-friendly
methodology makes for a successful implementation and satisfied businesses.
Most of our clients use one of four methodologies – Scrum, Pega BPM, the IBM®
Rational Unified Process® (RUP®) framework, or Waterfall. A number of our
clients have built hybrid methodologies that use an industry-standard
methodology as a baseline, customized to fit their enterprise.

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.

Choosing the Right Methodology

Our approach to choosing the right methodology for a project is to treat the
methodology like a glove. It must fit your organization just right, neither too
tightly nor too loosely. It must allow your team to be flexible and agile without
introducing chaos. It must be sufficiently flexible to be used under different
conditions. Most importantly, it must be durable and capable of withstanding
the most challenging events.

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.

Remember, no single methodology is a perfect fit. The interaction between

the resources and the methodology generates successful implementations. A
methodology is only as good as the team that follows it. You may have a perfect
fit methodology, but resources that have not been trained to implement it
correctly can still cause the project to fail. No matter which methodology you
choose, your resources must be trained and have practical experience to make
it effective.

Focus on the User Experience (UX)

Delivering an outstanding user experience (UX) is central to our delivery model.
It recognizes the importance of quality user interface (UI) design and capturing
the true intent of your users. Incorporating UX into project delivery means
that you are designing a solution that not only meets the technical and business
requirements, but also considers the wants, needs, and goals of the users.

Develop a UX Strategy First

To achieve the goal of delivering a world class user experience, develop a UX
strategy as early as possible. Think of a UX strategy as a high-level design objective
for the project. Delivering a good UX is not only about pleasing your users or
the aesthetics of design. A good UX enhances productivity, improves task
performance, decreases user adoption issues, and delivers higher ROI, which
ultimately translates into reduced costs or higher income.

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.

Focus on UX and UI at Each Step

Every stage or aspect of the methodology you select should have UX-centered
activities. They must support the concepts of application definition, design,
prototyping, and testing, whether your chosen methodology is linear (Waterfall)
or more iterative (Scrum, Pega BPM). Typical UI activities include:
• Persona development • UI control configuration
• UI review • PRPC UI best development
• PRPC UI design practices

For information on UX and UI assistance available from our Strategic Alliance

Partners or Pega consulting, visit the PDN area on our web site at www.pega.com.

The Importance of Enablement

Your success with any methodology ultimately comes down to how enabled and
willing the team is to stick to its core principles and disciplines. If a team doesn’t
adhere to those standards, they risk corrupting the foundational components of
the methodology and not realizing its associated benefits.

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.

Enabled resources understand the core principles that make up whatever

methodology you select. They are also more likely to adhere to these principles
because they understand their benefits. Making sure your resources have the
proper training pays huge dividends. We firmly believe that a combination of
basic knowledge and hands-on experience is a better approach than relying solely
upon on-the-job training.

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.

As an Agile methodology framework, Scrum provides the foundation for

addressing these areas.

“Agile software development methodologies emphasize close collaboration

between the programmer team and business experts; face-to-face communication
(as more efficient than written documentation); frequent delivery of new
deployable business value; tight, self-organizing teams; and ways to craft the code
and the team such that the inevitable requirements churn is not a crisis.”
…Agile Alliance, www.agilealliance.org.

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.

The Scrum Team is therefore, by necessity, a cross-functional, multi-disciplined

group consisting of Analysts, Developers, and Testers. This team is supported by
two other individuals – the Scrum Master and the Product Owner. The Scrum
Master is considered to be a coach for the team and is a different role from the
typical Project Manager. The Scrum Master does not direct the team or allocate
work, but instead acts as the team’s escalation point for any issues preventing
progress. The Product Owner is the empowered representative for the business,
customers, and users, and provides guidance to the Scrum Team to ensure that
the correct solution is being built.

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.

Anatomy of a Scrum Team

Scrum is an extremely team-oriented methodology. It can work successfully
with geographically disparate staffing models, although day-to-day activities
can be harder to manage. The members of a Scrum Team cover many different
disciplines (Analysis, Development, Testing, Documentation, etc.). What is
important is that the constituent parts combine to produce the effective
activities necessary to provide what is called the Done for a User Story.

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.

The Scrum Team is self-organizing, self-managing, and is able to be completely

autonomous. The recommended team size is between 5 – 7 resources. Because
larger team sizes typically result in significantly lower productivity, split any team
over seven into multiple Scrum Teams.

Using Scrum with PRPC

Due to its flexible and inherent agility, the PRPC development platform has
historically aligned well with rapid development methodologies such as the RUP®
framework. Scrum therefore fits very well with PRPC, given the iterative nature
of both.

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.

Less Visibility Business Visibility High Visibility

Less Risk

-1
0 200 400 600
0 1 2
1 Debit Card Processing
1 2 Credit Card Processing
Complexity

2 3 4 3 Wireless Payments

3 5 4 Customer Dispute Processing

5 Mortgage Processing
4 6
6 Address Change
5 7
7 Call Center
6
More Risk

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 • Create the Application

Workshop (MAW)
• Methodology/tool
enablement for team
members
• Defining standards and best
practices
• Identify dependencies and
create the Dependency Log
• Perform Operational
Walkthroughs
Profile
• Identify and capture User
Stories/Epics
• Create the PRPC Project
Effort Sizing document
• Affinity Sizing Workshop
• Identify the Sprints
• Hold a Project Kickoff
Meeting

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.

Preparation for Backlog Grooming

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.

Completed Area Description

Priority The Priority of the User Story will be
determined and entered in PMF as the Rank in
the Product Backlog.

Recommended Areas for a Definition of Ready Document

 Priority  Draft Process Flow
 Description  Assumptions
 Technical Details  Design Decisions
 Acceptance Criteria  Exclusions
 Estimation  Issues
 SME Identified  Dependency
 Test Cases  Design Review
 UI Mock-up

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

When Backlog Grooming preparation is complete, the Product Owner, Scrum

Master, and Scrum Team convene in a Backlog Grooming Workshop. They
consider each User Story and the Scrum Team decides if the level of detail is
sufficient to be able to understand the complexity, estimate the effort required,
and start implementation. All pertinent details are stored in the User Story
description. During the workshop, they may break large User Stories into smaller
ones and group smaller ones into a single larger User Story.

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.

Completed Area Description

Tasks Completed All tasks have been tested. All tests have
been completed and are either successful, or
issues documented and accepted as
deferred. All test scripts are marked as
complete.

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

Sizing User Stories

After the Product Backlog contains a prioritized, groomed list of approximately
twice the number of User Stories required for a Sprint, you can begin sizing them.
Scrum utilizes an activity called Planning Poker for this purpose. You estimate size
based on Story Points (SP), which are a relative comparison of effort between
User Stories.

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.

Sizing Techniques for Success

 Use triangulation – a 2 SP story is half the size of a 4 SP story.
 Use ideal time – don’t consider any non-project activities or what-if scenarios.
 Estimate stories at any time outside of a Sprint backlog.
 Equate 1 SP to 1 person-day of effort to establish a basic foundation.
 Avoid estimating a User Story in isolation. Always compare it to the
benchmark.

We use a deck of Planning Poker cards with a series of relative indexes to

establish effort. While some teams use clothing sizes (xs,s,m,l,xl,xxl), we use
a numeric system called the Cohn Scale.

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.

Sprint Planning Meetings (Part 1 and 2)

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

Creating a Standard Activities Document

After selecting User Stories for the Sprint Backlog, define the tasks for each
activity associated with each User Story. Create a Standard Activities document
for each User Story with timings adjusted based on User Story content. Each task
should be between 1 and 16 hours in duration. Pegasystems uses the following
format; complete examples are available for use as a template.

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

Recommended Tasks for a Standard Activities Document

 DCO
 Documentation
 Interface Stub
 Development – Process
 Development – UI
 Unit Test
 Handovers & Reviews – Tester
 Handovers & Reviews – LSA
 Handovers & Reviews – PO
 Functional Test – Preparation
 Functional Test – Execution

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

During Sprint Execution, the Scrum Team is self-regulating. A Work Stream/

Technical Lead or Project Manager/Scrum Master cannot allocate any tasks. Each
Scrum Team member selects Tasks to work on each day and updates the Scrum
Team daily on progress and intent. We use Pegasystems Project Management
Framework (PMF) for communicating and driving these reports.

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.

Grooming the Product Backlog

The Product Owner continues to groom the Product Backlog during the Sprint,
adding details and acceptance criteria and moving User Stories towards the
Definition of Ready. Once an item is deemed ready for inclusion, the Product
Owner passes it to the Scrum Team for Story Point sizing. The Scrum Team also
meets with the Product Owner and Scrum Master to review the Product Backlog.
They may break down or combine User Stories, assign Story Points, or capture
additional detail.

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.

You can’t extend a Sprint to accommodate further completed User Stories.

However, the Product Owner can decide to shut down and end a Sprint early.

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.

Use a spreadsheet for organizing

and classifying the posted sticky
notes in a more manageable
format. We recommend using:
• C (Caused by Scrum)
• E (Exposed by Scrum)
• U (Unrelated to Scrum)

How to Account for External Dependencies

One question that always arises during Sprints on large projects is how to handle
external dependencies. This question is especially relevant when PRPC is a
component of a large solution and must interface with external systems through
Services and Connectors.
• Should you include a User Story in a Sprint if the dependency has not
yet been delivered?
• Or, should you wait to include the User Story in a later Sprint when the
dependency has been delivered, even if it means not starting the User
Story as early as you could?

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.

A common practice for mitigating risks is to agree upon the dependency

specification up front, enabling the construction of Stubs and Harnesses to
prevent delaying inclusion of the dependent User Story in a Sprint. You can
then develop and unit test the User Story in isolation from the dependent
system. Remember that you will still need to perform further testing for
end-to-end connectivity once the dependent system interface is provided.

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.

To create an implementable User Story, use PRPC Directly Capture Objectives

(DCO) features such as:
• Direct capture of information and storage
• PRPC flow and UI drafting
• Playback Sessions
• Rule-linking

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.

Pega BPM Differentiators

Several factors differentiate Pega BPM from other methodologies. In combination
with PRPC technology, they optimize the application development process by
adding efficiency throughout the project lifecycle.

Factor Pega BPM …

Faster Business Focuses on delivering business value quickly. You deliver
Value/Return small iterative project slivers that achieve a portion of the
business value sooner than a “big bang” approach. Then you
leverage the momentum to bring more business value in
subsequent slivers.
PRPC Technology Takes advantage of PRPC DCO features. They provide an
integrated solution for gathering, reconciling, and
constructing requirements by capturing work flows, use
cases, and business requirements directly in PRPC.
Quality Embeds QA best practices up front during the early phases of
the implementation. This approach ensures that defects are
discovered promptly and not allowed to snowball into bigger
issues that cost more to resolve.
Collaboration Involves your business users at every step of the project to
ensure that their requirements are well-understood and
accurately fulfilled. Business users interact with the
application much sooner than with other approaches,
ensuring that the features meet their needs.

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.

 Promote co-production, emphasis  Ensure success through proper

on enablement Governance
 Model flows and UI  Use the right methodology artifacts
 Directly Capture Objectives at every phase
 Phase and iterate around business  Staff for success
benefits  Build smart (follow the Ten
 Planned checkpoints and Guardrails)
mid-phase reviews  Complete interfaces early
 Plan for reuse  Thoroughly plan for production
 Test and confirm early and with well in advance
real data

Anatomy of a Pega BPM Team

The Pega BPM resource model is flexible and can accommodate any strategy that
comprises Partner or other third-party (on-shore and off-shore), Pegasystems,
and client resources. This staffing approach requires strict adherence to Project
Governance procedures and artifacts to ensure that the solution meets
expectations. Our Project Governance model minimizes change control that may
result from scope creep and delays that in turn may be caused by untimely
responses or communication gaps. Circumventing these situations is critical to
keeping plan, task, and schedule within control and under budget.

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.

Pega BPM is designed to be tailored, and is compatible with Functional

Decomposition, Data-Driven, Object-Oriented, and hybrid or proprietary
implementation methods. It was specifically designed to accelerate our
Partners’ and clients’ ability to become self-sufficient in the shortest possible
period of time.

We see client enablement and Co-Production as critical factors

for ensuring project success.

Before You Begin

Before explicitly beginning a Pega BPM project, you perform a set of activities
referred to as Project Initiation to evaluate its general intent and suitability.
They establish the foundation for an effective and efficient project:
• Operational Walkthrough • Enablement training
• Proof of Concept (POC) • Roadmap planning

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.

See Chapter 3 (Our Delivery Methodologies) for information about MAWs.

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.

Tools and Artifacts

Available Tools Artifacts Produced
 PRPC Project Effort Sizing Tool  Project Management Framework
 Methodology Alignment (PMF)
Workshop (MAW)  Application Profile (AP)
 Application Profile Review Process  Estimated Effort
 Specification and Requirement  Resource Rationale
Template  Project Plan
 Roles and Responsibilities Matrix

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.

In most methodologies, the Elaboration and Construction phase is usually

represented as two distinct phases. Pega BPM combines them into one hybrid
phase. The reason for this distinction is that many of the Elaboration tasks you
execute during this phase use PRPC ’s exclusive Directly Capture Objectives
(DCO) features, which jumpstarts the Construction effort.

DCO provides an integrated solution where Elaboration tasks produce draft

Construction artifacts without requiring additional effort. This capability reduces
the duration of the Elaboration and Construction phases.

The purpose of this phase is to organize specifications captured during the

Inception phase into logical work stream groupings called Specification Sets that
you incrementally elaborate upon and build out. They represent work stream
processes that travel together through the Elaboration/Construction phase.

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.

The Elaboration/Construction phase of Pega BPM is unique. While elaborating on

Specification Sets, the team uses PRPC DCO capabilities to capture and detail
draft artifacts such as process flows and user interface screens. Through further
iterations and DCO Elaboration sessions, these artifacts can be made production-
ready.

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.

During the Elaboration/Construction phase, you iterate on many Specification

Sets in parallel based on your resource model. As Specification Sets cycle through
the DCO process and migrate toward the Transition phase, you can assign team
resources to other work streams and maintain a constant flow of working
iterations.

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

• Environment setup • Define/prepare data

• Implement Governance migration strategy
model (if needed)
• Identify and outline change • Iterative production-
management process ready build-out for
Specification Set
• Identify and outline
configuration migration • Specification Set
procedures playback sessions
• Issue reporting and tracking • Application reporting
requirements
• Communicate and review
existing policies and • Deployment plan
standards • User training plan
• Run Application Accelerator • Quality checks using
• Directly Capture Objectives built-in PRPC
(DCO) session organizing and capabilities
planning • Phase readiness check
• DCO Elaboration sessions • Quality and usability
• Create test plan/strategy reviews
• Define/implement security
and access policies

PRPC tools and applications – such as Performance Analyzer (PAL), Pegasystems

Autonomic Event Services (AES), and PRPC Alert and Error Logs – help you identify
and correct configuration problems. Use them regularly and often during this phase
to ensure that you deliver a production-quality solution.

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
 PRPC Project Effort Sizing Tool
 Specification/Requirement
Template
 Specification/Requirement
Rule Traceability Matrices
 Project Management
Framework (PMF)
 PRPC Automated Unit Test
(AUT)
 Flow Drafting
 UI Drafting
 DCO Elaboration Sessions
 PRPC Performance Analyzer
(PAL)
 Pegasystems Autonomic Event
Services (AES)
 Reports Browser
 Property Trees
 Case Designer
 PRPC Alert and Error Logs
 Pegasystems Pre-Flight
 Automated Document
Generation
 Project Status Report
Template
64
Artifacts Produced
 Application Profile (AP)
 Fully qualified/detailed list of
Objectives captured inside PRPC
 Fully qualified/detailed list of
Requirements captured inside PRPC
 Fully qualified/detailed list of Atomic
Specifications captured inside PRPC
 Fully functional Application meeting all
the requirements of the Business
 Deployment Plan
 As-built documentation generated by
PRPC self-documenting feature
 Detailed Project Plan
 Detailed Testing Plan
 Test Scripts
 Detailed Production Run Book
 Updated PRPC Project Effort Sizing Tool
 Governance Deck
 Project Status Report (PSR)
 Traceability Reports
 Phase Readiness Assurance checklist
Phase 3: Transition
Ensure that the application that was built:
 Is of the highest quality standards.
 Performs to established expectations.
 Meets the business requirements.

The purpose of the Transition phase is to confirm that the application is

production-ready, maintainable by IT, and usable by the business community. It
ensures that the application is of high quality, functions as designed, and meets
all of the business requirements. Transition consists of two separate steps:
• Quality assurance (QA) testing
• User acceptance testing (UAT)

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.

Each QA cycle consists of a Smoke Test, integration testing, boundary/exception

testing, and system performance testing. During QA testing, the Smoke Test is
a quick check to assess readiness for more detailed testing. Be sure to track all
issues, assign them, resolve them, and then perform regression testing. If you
discover a high volume of issues, start a new cycle after releasing the application
from development to QA.

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

Transitioning the Team

The Transition phase begins with the full team from the Elaboration/Construction
phase so those most knowledgeable in the area can readily address any initial
transition issues. As implementation areas become stable, team members roll
off the project until only a core team (developers fixing defects and architecture
leadership) remains to bring the application to production.

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.

Be careful not to transition an application to the QA environment too soon.

This will typically result in a flurry of user-discovered defects, which reduces
confidence in the application. It also creates a disproportionate amount of
overhead dealing with the QA resolution process for defects that would
be better handled in Unit Testing.

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.

We recommend completing team training two to six weeks before the

implementation begins. Pegasystems offers a variety of training delivery options
to suit your needs and schedule.

Delivery Option Training

Self-study Online selection of our courses for students to take at their
own pace
Private onsite Pegasystems-certified instructors deliver training at your
facility
Public classes Pegasystems-certified instructors deliver training at our
global facilities
Virtual classes Pegasystems-certified instructors deliver training via the
(private or public) cloud

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.

How Directly Capture Objectives (DCO) Works with

Pega BPM
Pega BPM leverages PRPC DCO capabilities to make the implementation process
more efficient and improve application quality. DCO consist of tools, capabilities,
processes, and best practices that you use throughout the project lifecycle. Its
benefits include:
• Centralized data store that supports asset reuse.
• Expedited documentation of business requirements, their visualization,
and transformation into executable rules.
• Cross-department collaboration at the appropriate time and level.
• Linked application artifacts (objectives, requirements, specifications,
and business rules).
• Automated work products (document generation, effort estimation,
application acceleration).

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.

Our Strategic Alliance Partners have experienced certified resources available to

establish or augment your PRPC teams. For more information, visit the Partners
area on our web site at www.pega.com.

Roles and Responsibilities

When assembling your team, always look for certified resources with a deep
level of knowledge, experience, and leadership skills. Business and technology
are equally important. At a minimum, the business people should understand
the as-is process and existing related applications and work practices. More
importantly, the business people must have a vision of the future process, and
the leadership skills to transform and improve the business.

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.

Program and Project Management

Role Responsibilities
Project Manager (PM) Day-to-day responsibility for running the project. With
Business Sponsor, develops the project definition.
Ensures that the project is delivered on time, to budget,
and to the agreed quality standard. Ensures the project is
effectively resourced and manages relationships with a
wide range of groups (including all project contributors).
Manages consultants, allocating/utilizing resources in
an efficient manner and maintaining a co-operative,
motivated, and successful team.
Technical Engagement Works with the PM to manage the program, project, and
Lead (TEL) Sprints/slivers. Works with and manages the PRPC team
on a daily basis to ensure tasks are well-defined and
resources know which tasks are theirs. Manages the
Project Plan and Project Status Reports to ensure all
resources understand where the project is. Facilitation
resource for Project Governance. Manages schedules,
budgets, resources, timelines, and change controls.
Reports on all on a regular basis.
Project Sponsor (PS) Commissions others to deliver the solution and
champions its cause throughout the project lifecycle.
Normally a senior staff member with a relevant area of
responsibility that will be affected by the outcome.
Involved from the start, including defining the project in
conjunction with the PM. Ensures the project is actively
reviewed. Must be a diplomat.

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.

Technical and Business Architects

Role Responsibilities
Lead System Architect Ensures that the application quality and design are of
(LSA) the highest quality standards. Ensures that the
application meets current business needs, but also
supports future expansion for new features down the
road. Responsible for the Enterprise Class Structure
and the overall application design.
Lead Business Ensures that the business requirements, use cases, and
Architect (LBA) objectives are being addressed throughout the
implementation lifecycle. Interfaces regularly with the
business to capture the application objectives and
requirements. Facilitates and helps business resources
prepare for DCO sessions. Manages the tasks and
priorities of all Business Architects, and ensures artifact
quality.
Business Architect Ensures that the business requirements, use cases,
(BA) and objectives are addressed throughout the
implementation lifecycle. Interfaces regularly with the
business to capture the objectives and requirements
for the proposed application. Organizes and schedules
DCO sessions.
Senior System Responsible for the majority of the application
Architect (SSA) / configuration. Takes direction from the LSA for tasks,
System Architect (SA) priorities, design, and best practices.
User Experience (UX) Conceptualizes, designs, and communicates the UX
Architect components of the solution. Ensures that effective,
innovative, and usable solutions are created with user
and business needs in mind.

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.

Specialized Technical Resources

Role Responsibilities
System Administrator Manages and supports the IT system environments.
Testing Lead Creates the test plan and defines the test strategy and
scenarios. Each Scrum team needs one resource to
continuously test User Stories from creation until
development is complete. Pega BPM teams need one
or more resources for QA in the Transition phase.

To learn more about role-based learning paths, certifications, and areas of

specialization, visit the Pega Academy area on our web site at www.pega.com.

Scrum vs. Pega BPM Teams

The skillsets required to deliver a PRPC solution are the same regardless of the
methodology you select to guide the implementation lifecycle. However, your
staffing titles will be different depending on whether you are using Scrum or
Pega BPM. For example, with Scrum you could fill the Scrum Master role with
a Technical Engagement Lead (TEL) that has gone through Scrum training. The
Scrum Team will be a cross-functional team of resources that include an LSA, SA,
BA, testers, and other skilled resources. The difference is in the titles that fill the
roles and the type of methodology training required to ensure that the team
members understand the associated best practices.

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.

Group Key Functions

Program or Project • IT program/project governance
Management Office • Program tracking/reporting
(PMO) • Project financial tracking/reporting
Release Management • Manage solution releases into QA/Test and UAT
• Stage performance and production environments
• Manage build script and environment migration
processes for application configuration
Enterprise Support • Shared services (document management,
data services, etc.)
• Finance
• Risk management
• Information security
• Supply chain/vendor management
Infrastructure • Environment (HW/SW) provisioning
• Environment management (middleware, DBA)
• Capacity planning
• Data center management
Training • Ensuring user readiness
• Preparing training materials, job aids
Testing • Functional and automated testing for application
features
• Regression testing
• Test plan and script preparation/ownership
• Defect recording, tracking, reporting, and
production readiness assessment
Architecture • Develop technology and architecture migration
roadmaps
• Develop conceptual and logical architecture views
• Architecture governance and alternative
architecture assessment
• Partner with application development teams on
key technology initiatives
• Application/technology stack rationalization

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.

Client-Led, Partner- or Pegasystems-Facilitated Projects

As your organization gains experience and you have groomed in-house technical
leadership, you will begin to take the lead on PRPC projects. At this point, you
should have a solid cadre of PRPC System Architects who have taken the PRPC
technical training curriculum with some of them achieving CSA certification. Your
business analysts and project managers have attended PRPC Business Architect
Essentials training, experienced one or more project iterations, and can
confidently apply our Agile methodologies (Scrum or Pega BPM) and DCO tools.

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.

Client-Led, Partner- or Pegasystems-Supported Projects

Even after expanding your in-house PRPC technical leadership, you may find it
beneficial to bring in Partner or Pega Consulting resources to deliver specialized
advisory services such as Design Reviews, Usability Reviews, or Production
Performance Inspections.

For more information or to discuss your requirements, contact the Pegasystems

Professional Services Practice Leader for your engagement.

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.

Have Confidence in Competence

You are ultimately responsible for ensuring that the resources you engage to
implement Pegasystems technology are competent for your industry, in PRPC
implementation and best practices, and in the delivery methodology of your
choice. Look for specific skills and examine the resume of each person. We
recommend that you request each individual’s certification status. Finally,
remember to assess the individual’s PRPC experience with other clients.

You can also use the Certification Checker tool on the PDN to verify someone’s
certification status.

Outsourcing Projects to Offshore Partners

Outsourcing projects or parts of projects to offshore Partners can add significant
value. Offshore resources can lower costs and increase productivity through
distributed development across multiple teams. However, you must design the
environment to support offshore outsourcing from the beginning. Introducing
offshore resources as an afterthought or in an attempt to get a project back on
track can be risky.

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.

A follow-the-sun approach can lead to higher productivity of onshore and

offshore teams working hand-to-hand. At the same time, the geographic
and time zone separation of the business and requirements gathering from
development and testing may introduce new risks.

Advantages of incorporating offshore resources include:

• Better usage of the 24-hour clock. Tasks on the critical path can be
worked on by two shifts of consultants, depending on your location
and that of the offshore team. This practice can reduce or eliminate
tight deadlines.
• Budget savings. On average, offshore labor rates are significantly lower
than comparable rates onshore.

Disadvantages of using onshore/offshore teams include:

• More administrative complexity. Requirements and designs must be
concise so that they leave little or no room for misinterpretation. Daily
hand-off calls are often required at odd hours of the day and leave little
time to discuss all the details.
• Communication challenges. Offshore teams require solid documentation
and significantly increased communication. If the development team has
ad hoc questions or issues, the business may not be available at the time.

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.

Governance over Pegasystems programs and projects ensures conformance to

your policies, procedures, and processes to deliver Great Systems. We guide our
projects through a well-defined set of steps, according to an aligned methodology
and operating as part of a blended methodology, to implement business
initiatives. Governance is the key to delivering project excellence through best
practices that all projects should follow, including adherence to specific BPM
standards (whether business, architectural, or technical) and to the overall
business goals and objectives of the BPM initiative.

To ensure repeatable high-quality PRPC solution implementations, we also

establish governance to ensure rigorous Technical Oversight including steps such
as Process Quality and Assurance, Technical and Architecture Governance, Design,
and Deployment.

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.

Executive Governance focuses on the

activities of stakeholders to achieve
Executive
corporate goals. The intent of Executive
Program Governance is to provide a strong level of
Strategic
interaction and support between various
organizational divisions. It is typically
Program Tactical
established by executive management to
impact projects from the top down.
Project Level

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.

• Strategic Level Program Governance focuses on defining the roadmaps

and timelines, and providing the business segment or operating group
direction to implement transformational initiatives.
• Tactical Level Program Governance focuses on enabling delivery teams
and business sponsors to implement these initiatives through various
delivery groups and methods.

Project Governance defines the processes and methodology that need to be in

place for successful solution delivery. Project Governance is often considered a
subset of Program Governance and establishes the rules and regulations of
projects under the Program Governance umbrella. A well-defined Project
Governance program is absolutely essential to the success of a PRPC project.

These coordinated governance programs guide the successful delivery of multiple

projects. Typically a PRPC COE is responsible in part for establishing the structure
within an organization in order to establish a sound foundation for success. Full
governance may not happen overnight or to full maturity during the initial
projects. However, our blueprint establishes the critical delivery governance
(Quality, Technical, and Enterprise) for great results.

Governance Area Purpose

Process Quality and Establish reuse at the core, best practices for optimized
Assurance PRPC processes and benefits realization, and adherence
to DCO capabilities and benefits.
Technical Governance Establish Build for Change® through appropriate reuse
strategy, repeatable design patterns, and best practices
for delivery and deployment.
Enterprise Architecture Establish a landscape for delivering PRPC solutions
from a BPM Roadmap and Architecture Blueprint
(technology stack, SOA principles, etc.).

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.

Due to its relationship with Program Governance, Project Governance often

has IT Governance sponsorship. It adds a dimension of steering sponsorship with
executive representatives from both business and IT. They monitor progress and
provide guidance and support as needed.

We also recommend assigning a Project Sponsor to act as a project champion

and push initiatives through to success. Project Sponsors often participate as
part of a project board to monitor and control the outcome. The most successful
champions are those that have a particular interest in the project outcome. They
are sometimes appointed by executive team, but more often have a strong
relationship with the executive team and appoint themselves to sponsor a
project. Many Project Sponsors are senior members of the executive committee
and are the chair of the project board.

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.

You establish project governance during Vision Definition (Scrum) or Inception

(Pega BPM); it concludes only when the project is complete. It establishes a
foundation among team members focused on:
• Raising issues early.
• Resolving issues in a timely manner.
• Controlling scope via Change Control.
• Ensuring compliance with PRPC Guardrails.

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.

Project governance outlines the minimum standards by which all Pegasystems

projects are managed:
• Executive Project Steering Committee
• Project Status Reports (PSRs)
• Project Meetings
• Issue Resolution
• Change Control

Pegasystems has standard templates for key governance documents such as

Project Status Reports.

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.

Effective communications and active governance are critical components of

successful delivery. Governance meetings are important for keeping a continual
flow of information between project leadership, business sponsors, and executive
leadership.

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.

Project Kickoff Meeting Agenda

 Team introductions
 Discuss ROI (both project
importance and expected)
 Review the use cases, interfaces,
and reports
 Review project plan, and roles and
responsibilities
 Agree on team norms
 Set up routine governance

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

Stakeholder Governance is a key Critical Success Metric and is not optional.

Conduct meetings at least once every two weeks for most engagements. Even
a thirty-minute meeting every two weeks can provide huge dividends.

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

Technical Oversight. It covers the people, Enterprise Reuse

processes, and tools that each project Standard and Best

Practices

employs to guarantee solution quality in Technical Oversight

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.

Conduct Configuration Reviews at a frequency that is appropriate for the project’s

release cycle and configuration volatility. When developer activity is high, you
may need to conduct reviews on a weekly basis. The capacity and availability
of technical resources capable of performing the reviews may constrain their
frequency. For example, on large projects with multiple work streams, the
LSA may choose to delegate Configuration Reviews to the work stream leads.
Performing peer reviews with LSA supervision avoids the LSA becoming a
bottleneck and imposes a higher degree of responsibility for configuration
quality on the work stream leads.

A common mechanism for communicating configuration anomalies to the team is

to create a Findings & Recommendations document. Attach this document to the
project in PMF as a formal deliverable to ensure that all issues are resolved.

Phase Readiness Assurance Checklist

The Phase Readiness Assurance Checklist is actually a set of checklists, one for
each phase of a PRPC project. They ensure that the project moves seamlessly
through its phases. The Project Manager is responsible for making sure that the
Phase Readiness Assurance Checklist is used, kept up to date with the current
project status, and includes relevant actions for any incomplete items.

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.

On your initial projects, either a Strategic Alliance Partner or Pegasystems

typically provides these services with the goal of transferring ownership and
delivery to your Center of Excellence (COE). Once you have an operational
COE, its experts are typically responsible for providing these services.

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.

Pegasystems provides a set of tools that support project development, a

framework that supports the tools, and two methodologies (Scrum and Pega
BPM) that can easily blend with your methodology. PRPC Directly Capture
Objectives (DCO) features provide the foundation for this approach. DCO
enables you to capture business objectives, project goals, requirements, and
use cases, and tie them directly to the implementation.

Defining Project Scope

You begin every PRPC project by using a DCO tool called the Application Profiler.
It is a flexible and comprehensive requirements gathering tool that you use to
define and communicate project objectives. You use it to define a series of
applications to be built (Sprints/slivers) as part of an overall project or program,
and then use it again to define the individual Sprints/slivers.

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 Application Profile answers the question "What will we build?".

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.

On average, it takes a few days of dedicated effort to build an Application Profile.

You use the information in the Application Profile to size and document the
project, and then prime the generation of the application — thus providing the
project with the most relevant information from the start.

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.

Pega BPM Sizing Summary

The Pega BPM Summary Worksheet focuses on hours, duration, and schedule.

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.

Capturing this information is usually a collaborative effort between the Technical

Engagement Lead, Lead Business Analyst, and Lead System Architect. These steps
are often iterative and you may need to conduct some what-if analysis to identify
the optimal mix of resources, schedule, and scope.

After you enter the additional data, the spreadsheet updates its calculations to
provide a staffing model, total hours, and schedule.

Managing Project Scope

Managing project scope is all about the requirements. They must be clear,
concise, specific, and relevant – but most of all, they must be communicated. If
the team does not know the requirements, there is no possible way to manage
them and the scope they define. So, you initially define the overall requirements
(or Objectives) of the application using the Application Profiler tool, communicate
them via the Application Profile document, and then migrate them to a PRPC
application using the Application Accelerator.

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.

Methodology Managing Scope Creep

Scrum Define the project scope within a Sprint and then time-box the
Sprint, which puts pressure on the team to both understand and
not exceed the scope.
Pega BPM Define project iterations and increments (slivers) where the
scope is defined in small chunks, which is easier to manage.
Waterfall Because project requirements and scope are defined so early, it
is difficult to accurately define – and then even more difficult to
stay within – a scope that might not truly define what’s needed.

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.

The Agile Precept The Potential Pitfall

Ease of Because making changes in PRPC is so easy, you often want
Development to make them in real-time. While individual changes may
seem minor, they can add up to a lot of additional work.
Collaborative The close connection between business and IT can also
Teams make it seem too easy to make changes on the fly. Monitor
changes closely to make sure they are within the original
scope and make trade-offs as necessary.
High-Level Initial Defining initial objectives in too much detail in an Agile
Objectives project can cause over-analysis too early. But this same high
level can also lead to ambiguity later.
Frequent Testing Although frequent testing significantly reduces the risk of
project failure, the associated resource load is often
underestimated in project scoping.

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.

Evaluating, Sizing, and Shaping PRPC Solutions

The pendulum in the BPM industry is clearly swinging in a new direction – shifting
the focus away from IT and technology delivery, and towards business-driven
solution delivery. As a business leader, you seek technology solutions that can be
implemented much faster, are of higher quality, and allow you to control and
effect change more directly. These factors offer the competitive advantage for
your enterprise to compete at the highest level.

PRPC embraces this paradigm by giving the business a meaningful role in

delivering technology solutions. Success in this environment means that you
no longer simply compile a list of requirements and hand them over to IT to
implement. Instead, you are engaged throughout the implementation lifecycle
to model and modify your requirements directly in PRPC (using DCO). You have
the visibility to ensure that your requirements are being met – not from a
technology perspective, but from a “This is how we are doing business going
forward” vision.

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.

A BPM or PRPC Center of Excellence (COE) is a useful resource for providing

assistance with adopting PRPC and this paradigm, as well as for establishing a
solution roadmap. See Chapter 12 (Maximizing Your PRPC Return on Investment)
for more information.

Establishing a Solution Roadmap

Let’s examine how this collaborative model works. First you establish the vision
(or roadmap) for business change. You start by collecting your set of high-level
Business Objectives. For example, you may need to create new customer-facing
initiatives in order to win against your competitors, or replace an older solution
that cannot support the current state of your business.
These objectives are typically driven by one or more events such as:
• Competitive gaps • Technical debt
• Application sunsets • New technology channels
• New capabilities

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.

We recommend Scrum or Pega BPM if you are seeking an Agile implementation

approach. See Chapter 4 (When/How To Use Scrum) and Chapter 5 (When/How to
Use Pega BPM) for more information.

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.

Project Management Framework (PMF)

PMF enables development teams to manage their projects efficiently, while
giving stakeholders visibility into project status. Team members can update their
work status directly from the PRPC Developer Studio, which improves developer
productivity. Since PMF implements best practices for managing and tracking
projects across multiple development and QA environments, it also promotes
consistent project management across PRPC teams.

You can run PMF as-is out of the box, or extend it to include new capabilities or
interfaces with other systems.

Key PMF Features

• Self-documentation and interactive capabilities for recording
status or issues
• Convenient reports and dashboard to monitor defects, product
readiness, performance, and milestones
• Real-time view of project status with complete audit track
• Interfaces to PRPC tools/applications such as Designer Studio,
Application Profiler, and Direct Feedback
• Supports third-party tools, such as Microsoft® Project software
and artifact repositories

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.

Don’t Forget the Final Step

As a final step in the program and project management process, you must always
remember to measure success in terms of the business value realized. You may
not always be able to measure that value day-one after going live. However, as
part of organizing your solution delivery, make sure that you completely identify
and clearly articulate how you will measure its success. Also be sure to establish
a plan to measure the delivered value of the solution over the appropriate
timetable.

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.

Build Great Systems

We define delivery success by whether the team was able to build a Great
System. Great systems provide benefits to the business owners that align with
and extend the agreed-upon success criteria in the following ways.
• Business Value. The system tangibly improves the business by promoting
straight-through processing and reducing manual work steps or total
work time. It increases revenues by fostering customer retention and
automatically suggesting cross-sell opportunities, and lowers cost by
reducing human resources required.
• User Experience. The system provides an attractive, intuitive, highly
usable, and intent-led UI that improves user adoption and satisfaction.
Users “just get it” with limited training.
• Technical Architecture. The system is implemented to meet best
practices and the performance requirements of the business. It responds
crisply and reliably.
• Built for Change. The business users understand what they can change
in the system and are able to implement changes in days or weeks.
Business functions were designed and packaged for reuse in other
implementations.

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).

Manage and Evaluate Your Metrics

You track and monitor technology
solution delivery along three basic
dimensions: time, cost, and scope. Many
project managers refer to these as the Time Cost
triple constraint, Project Management
Triangle, or three legs of the project Quality
management stool (as per PMBOK®).
Each side or leg represents a constraint
that cannot be changed without affecting Scope
the others.
Some project management organizations such as the Project Management
Institute (PMI®) include quality as an additional element.

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.

Project managers review these metrics daily against a baseline in order to

understand progress and mitigate risks. It is not surprising that this approach
has become the standard method to define and measure 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.

Some organizations utilize a project management technique called Earned Value

Management (EVM) that utilizes the same dimensions of time, cost, and scope.
However, EVM also objectively evaluates cost and schedule efficiency and helps
identify potential issues. Earned value analysis is a point-in-time evaluation based
on three metrics:
• Planned Value: How much work did you plan to complete?
• Earned Value: How much work did you actually complete?
• Actual Cost: How much did it cost to complete the work?

The Earned Value Management System (EVMS) started on Department of Defense

projects in the 1960s. Other government agencies and organizations in the private
sector have since adopted it.

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.

The industry-leading Net Promoter® methodology was developed by Satmetrix

Systems Inc. with Bain & Company and loyalty expert Fred Reichheld. For more
information, go to www.satmetrix.com.

Obviously measuring success might take an extended period of time after

the go-live. Nevertheless, realizing business benefits is an important success
criterion. Take steps early to ensure that the results of implementing the solution
will be tracked and measured. Business benefits must align with the project
objectives, in turn supporting the corporate strategies and goals. If the project
is the first Sprint/sliver in a solution or the first solution in a strategic enterprise
program, the total benefits may not be realized until the completion of the
program – which could take three to five years.

“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.

Meeting Business Case Objectives

Meeting the business case objectives is directly related to benefits realization.
Most, if not all, solution implementations are approved based on a business case
which is the justification for the resource and investment. It also serves as a
consistent message to all stakeholders. The business case defines the:
• Reason for the solution: the problem(s) being solved and the
opportunities.
• Recommended solution: how the problem(s) will be addressed
and opportunities met, and alternatives.
• Benefits: the expected outcomes and financial justification.
• Plan: project scope, expected resource requirements, and timeline.
• Risks: any risks associated with implementing the solution.
• Gap analysis: any risks associated with not implementing the solution.

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?

We recommend conducting retrospectives or lessons learned sessions after the

completion of each project to determine areas of improvement. Your Program
Management Office (PMO), Center of Excellence (COE), or IT portfolio governance
group should conduct these meetings and analyze the results across multiple
projects. This effort can uncover additional training needs or incentive
adjustments.

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.

Meeting Governance Criteria

Most organizations have a process in place for IT project governance. These
requirements take the form of formal entry and exit criteria along with required
approvals, a change management process, issue management and resolution,
adherence to company and industry standards (COBIT®, ITIL®, BSC, and Six
2
Sigma®) and policies, and so on.

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.

Plan for Continued Success

After all of the celebrations are over and congratulations have been handed
out when a project is declared a success, it’s just as important that your
organization is prepared for success. What this means is that you have planned
for how your organization will operate post-success from the people, process,
and IT perspectives. The new application must be sustainable going forward
and you need to have the proper support mechanisms in place to ensure that
the success continues.

We cannot stress enough the importance of methodology and technology

enablement for both the project team and the support team that takes over after
go-live.

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.

By building on the successes of past projects, your organization will be

well-positioned for the next successful endeavor.

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.

In addition to the typical interactive development environment (IDE) tools,

Designer Studio provides a range of productivity tools that address the unique
developer needs of the Model-Driven Architecture (MDA) of the PRPC platform.
These fit-for-purpose tools are designed to increase developer productivity and
improve the quality and performance of the resulting configuration.

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.

 Rule Management  Quality and Testing

 Release Management  Application Performance

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.

Rule and Application Versioning

RuleSet versioning, and by extension application versioning, are powerful
mechanisms that you can use to give different groups of users access to different
versions of the same application. Let’s assume that MortgageApp 01.04 contains
the current production version of an application. You can grant access to a group
of pilot users to MortgageApp 01.05 (which is the evolving next version of the
application) in the same production environment.

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.

 Lock & Roll

 Release Planning and Management
 Parallel Development

Lock & Roll

At the end of a development cycle (such as a Sprint/Sliver), you lock the
current version of the RuleSets and create a new version to use for continued
development. We refer to this step as Lock & Roll.

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.

Release Planning and Management

Armed with RuleSet and application versioning to support ongoing development,
the release planning process includes the following activities:

• Identify the RuleSet, application, and product versions to use.

• Ensure your versioning model supports the current release and
any concurrent production releases.
• Allow room in your versioning model for application iterations
(Sprints/slivers).

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.

 Unit Testing (Run Rule)

 Built-In Quality of Deliverables (Guardrails)
 Automated Unit Testing (AUT)
 Executing Test Scenarios

Unit Testing (Run Rule)

Unit testing is a method by which you test individual units of configuration to
ensure they are fit for use. As a development best practice, unit testing is the
first – and arguably the most impactful – building block in the application testing
chain. Testing and stabilizing the parts of an application before testing the sum of
its parts reduces the number of integration test cycles.

Unit testing is a cornerstone of Agile development practices and should be an

integral part of your overall test strategy. It represents your team’s signoff on
your deliverables.

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.

Built-In Quality of Deliverables (Guardrails)

Pegasystems has established a set
of best practices for designing and PRPC 10 Guardrails
1) Adopt an Iterative Approach
implementing PRPC applications 2) Establish a Robust Foundation
which we call the Guardrails. These 3) Do Nothing That is Hard

guidelines promote optimal reuse, 4) Limit Custom Java

5) Build for Change®
maintainability, and system 6) Design Intent-driven Processes
performance. They are built directly 7) Create Easy-to-Read Flows
into the PRPC development tools to 8) Monitor Performance Regularly
9) Calculate and Edit Declaratively,
guide you towards building a solid Not Procedurally
and technically sound application. 10) Keep Security Object-Oriented, Too

PRPC provides interactive warnings when you save a rule to indicate

non-compliance and a potential problem.
• Standard Rule Warnings. PRPC rule forms display warning messages
if you save a rule that violates any of the Guardrails. Message types
include performance, security, data integrity, and best practices.
• Custom Rule Warnings. You can add your own warnings to PRPC
rule forms to warn if a rule violates any of your organization’s
development standards. For example, Pegasystems provides a Best
Practices QA RuleSet with custom warnings for undocumented rules.

The Developer Studio also includes a Guardrails tool that provides a

comprehensive compliance report for all rules in an application.

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.

Executing Test Scenarios

You can run test cases individually, one-by-one. You can also use AUT to create a
test suite with all available test cases for a given rule and simply choose which
tests to run. You can schedule recurring test suite execution at various periodic
frequencies. AUT displays the results as a pie chart in which you can drill down to
view the details for any test case not yielding the expected result.

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.

 Performance Analyzer (PAL)

 Database Tracer
 Performance Profiler

Performance Analyzer (PAL)

Performance Analyzer (commonly referred to as PAL) is an interactive tool for
determining where your system is spending resources. Run PAL frequently and
continually monitor performance as you are building the application. Monitoring
allows you to detect issues early before they require a significant amount of effort
to analyze, handle, and correct. Effective performance monitoring also drives
down defects and considerably reduces project risk.

PAL allows you to create and compare snapshots of performance-related data

during a requester session. This data includes over 100 statistics, including
counters and timers for:
• Rules assembled, compiled, and executed.
• Bytes read from and written to the database.
• Bytes exchanged between browser and server.
• Bytes sent to and received from external systems.

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.

Need A New Set of PAL

Type of Change
Readings?
 Integrating a new interface in a flow  Yes
 Adding a new embedded List View to a screen  Yes
 Adding a dynamic select to a screen  Probably Yes
 Adding a single property reference to a screen  Probably No
 If the value is calculated through a complex  Perhaps Yes
declarative network

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.

Error and Alert Logs

PRPC uses several methods to inform you about system errors and alerts.

Log Contents To Review

PRPC Log Industry-standard Java log file For one Java node:
(Apache log4j™, Apache Software PegaRULES Log Analyzer
Foundation) that records errors, (PLA) tool to view or export
exceptions, and informational to a spreadsheet
messages
PRPC PRPC-generated autonomous Across multiple Java nodes
in a cluster:
Alert Log alerts of issues and errors related
Autonomic Event Services
to performance and security
(AES) product
Current Alerts generated by the current Designer Studio
Alerts application, primarily designed for (My Alerts gadget)
individual developers

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.

Before you promote an application to the next-level environment (UAT, Pre-

Production, Production), the log and alert files must not contain any serious issues.

Tools Best Practices

Designer Studio provides powerful tools to help you build in and improve
application quality and performance. Be sure to use them early, frequently,
and regularly for best results.

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.

Establishing a Center of Excellence (COE)

The purpose of a COE is to influence your organization to embrace the cultural
change required to adopt process management strategies and deliver Build for
Change®. A COE is a self-organizing highly motivated team that provides the
thought leadership to drive business transformation with PRPC:
• Actively nurture BPM/PRPC initiatives.
• Establish an overall PRPC roadmap and architecture blueprint.
• Work with executive, senior business, and technology leaders to
select the “right projects”.
• Define and foster the sharing of best practices, standards, and
knowledge.
• Provide project governance and guidance.
• Help realize the return on investment while lowering the risk profile.
We have found that organizations that have been successful in their adoption and
ongoing operations of BPM/PRPC almost always have a COE.

“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.

Starting Your PRPC COE

Many organizations ask, “When should we establish our PRPC COE?”. We typically
see two starting points:
• Organizations that are new to Pegasystems and want to ensure from
the beginning that they are implementing PRPC correctly from a solid
foundation.
• Organizations that have three to five projects complete/underway,
see opportunities for improvement, and understand that having a COE
is an effective way to address these areas.

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.

Evolution of a Reuse Strategy

Building reusable assets typically starts organically in an ad hoc fashion. For
example, a project team needs a single sign-on capability that it understands
another group has already implemented. They set up a meeting between the two
groups, copy the knowledge and RuleSets, add the assets to the new application,
and then modify them to fit. The reuse might also be more formalized, with
someone modifying the asset to address the needs of both applications,
documenting it, and adding it to an asset library.

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.

Primarily directed at code

leverage or reuse.
Short-term time horizon.
Individual, non-coordinated efforts.

Time and Effort

For PRPC to be a transformational technology with broad impact, you must mature
along this dimension in both business and technical expertise.

Become organized to a basic level of reuse with documentation and to a

domain-oriented level of reuse that enables different groups in the organization
to interact effectively. Achieving a strategy-driven level of reuse means that
your organization has business process assets that are flexible and able to be
enhanced or modified to quickly respond to market need.

Benefits of Asset Reuse

Benefit How
Increased Leveraging existing, stable assets accelerates development
Productivity and enables you to deploy applications sooner with
reduced cost.
Improved Agility You can combine and assemble applications more quickly in
response to business community needs.
Enhanced Enterprise assets must pass a higher bar, have narrower
Application Stability well-travelled code paths, and are less prone to failure.
Including (rather than building) assets leverages “tried-and-
true” rules that are already proven in production.
Better Managed More consistent implementations reliably and consistently
Risk interact with external systems. Having business processes
in multiple places may introduce risk due to variations in
implementation.

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.

Creating a Foundation for Asset Reuse

The core of defining an enterprise reuse strategy and architecture is asset
definition. How do you package and manage assets to be easily consumed by
others? A barrier to reuse is often the complexity of integrating the needed
functionality into a new application. If the effort of “getting it to work” is too
high, the associated costs and risks will hamper your ability to bring its assets
to bear. Several elements foster and support this initiative.

• 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.

• Enterprise Asset Repository: Serves as a central storage location,

typically governed by the PRPC COE, for reusable assets of all types.
These assets are typically “at rest” and cannot be directly built on.

• PRPC Center of Excellence (COE): Defines your enterprise reuse strategy,

specifies repeatable processes and best practices, and identifies the
form/structure of reusable assets. The COE may also contribute assets of
a utility nature such as a single sign-on capability or data model.

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