Course Summary

Pega APP Platform

Pega APP platform

Unified architecture
Each app built on Pega uses a common set of tools, vocabulary, model to communicate, validate and implement
reqs. CONSISTENT SET of TOOLs/ARTIFACTS saved in a single DB REPO. Saving DEV TIME

Model-based approach
It's an APP DEVELOPMENT APPROACH Using VISUAL FORM BASED DEFINITIONS of app component, closer to
BIZ SEMANTIC.
IMPROVE VISIBILITY of app architect so all the team members can see better the IMPACT OF REQS and
POTENTIAL GAPS

User roles
CASE PARTICIPANT, biz users of the app
WORKERS: create, view and work on their assignments
MANAGERS: create, view and work on their assignments and monitor other assignments, group status, goals and
deadline
CASE DESIGNER, building and delivering app
BA: work with participants to define BO and REQS, addressed to SPECs (they define how the app will work)
SA: provide tech skills, configure app on UI forms, automated decisions and correspondence, then review the
application with biz STKH for approval

User portals
RUNTIME PORTALS
CW PORTALS managed assigned cases
CM PORTALS managed assigned cases + view status of their direct report
DESIGN TIME PORTALS
PEGA EXP: accelerated environment, to create high level structure of cases and proccess step, create a RUNTIME
APP PROTOTYPE
DESIGNER ST: robust development environment to refine CLC design

Pega Express
- Create cases, phases, usr views, forms
- add/remove exysting users
- Define settings for theme, mobile
- SIMULATION MODE: BUILD DATA MODEL in the context of CLC, you can test your
design as a user would experience using the application.
- Ideal for initial G/E session in which biz and IT collaboratively define the primary
Designer Studio
Provide tools and info needed by dev team to build and extend app

Principles of APP development

DCO
Directly Capture Objectives, Practice of capturing business requirements directly into Pega, pros:
- COMMON UNDERSTANDING between biz and IT
- Doc and info are UP-TO-DATE and AVAILABLE
- COMMON VISUAL MODEL, every aspect of the app is captiured visually in a browser
based designer app
- No TRANSLATION ERROR
- Biz partner can see changes in the app in REAL-TIME

Mutli-dimensional APP architecture

SITUATIONAL LAYER CAKE is an architecture that allows you to create a taylored end-to-end experience to
customer without creating a copy of the app, but creating an app with the same dimension of your biz, pros:
- Re-use common policies, CONSISTENCY
- Allows different between layers (channel, product, regions ), AGILITY
- each layer is independently VERSIONED
- Let you ROLL BACK in a previous version of the app
- Simple and coherent CEx

Model-driven APP
Application design should match the way biz people naturally talk, Pega use a VISUAL REPRESENTATION of the
APP, rather than complex end-to-end diagrams, but with CLC:
CASE
- OUTCOME DRIVEN: represent a work to be done
- Defined by STAGE, as biz people talk
- Become a CANVAS, in which biz and it collaboratively work
- Automates SLA, escalations, prioritizations
- save audit and HISTORY

Best Practices
Well defined method which lead to a desired output

Establishing
They should be appropriate, fit, be cost-effective, necessary resources

Pega BP
- Leverage DCO: saves time and effort, no translation errors, direct engagement, enable participant to review
the work
- Use Pega capabilities: already tested, proven reliable
- Certified Team members
- Communicate Project progress at all level: daily standup meeting, biweekly project updates, monthly project
review
 - Iterate and test: test each new feature, demonstartion leads to FB, divide app in smaller components, testing
early
- Work with everyone involved in the project success: use their unique skills
- Follow Pega Guardrails, so app is easier to maintain and update

Consequences of not following BP

- Recreating existing features
- Increase time debugging a component not well designed
- Increase dev time
- Feature not working correctly
- Less maintainable

Guardrails
Message advising the user that app does not conform to pega BP
Prototype APP using Pega Exp
Designing CLC
- CLC design: MODELLING TECHNIQUE to describe how the app should work
- Case: WORK that deliver an outcome, deliverable meaningful to client, internal stkh or partner
- 1o2w
- Names relevant and meaningful to the biz
- SINGULAR CONTEXT
- Case type: type of artifact in pega used to define TASKS and DECISIONS to solve a case
- Stages: high level MILESTONES in which a case is organized, they contains process and workflows, they
can represent change in authority or status
- NOUN or NOUN PHRASE
- Max 7+/-2, If you find yourself needing more than 10 or so stages, consider combining one or more
stages, or using a separate case type
- PRIMARY STAGES lead to EXPECTED OUTCOME (HAPPY PATH)
- Processes: one or more PATHS the case must follow, contains STEPS, actions that must be completed to
solve a case
- VERB+NOUN
- Every pprocess should have a goal that can be expressed on a SINGULAR OUTCOME
- Process steps: action that a user perform, automatic action performed by the system or other processes
that contain a separate set of actions
- VERB+NOUN
- Max 5+/-2, If more than seven obvious steps are needed, consider breaking down some steps into
other processes

Assigning Work
- Current user: the task is assigned to the user that has performed the previous task
- Specific user: the task is assigned to a SPECIFIC USERNAME
- Work queue: the task is assigned to the ANY USER that belongs to a QUEUE

SLA
Expectation of desired outcome within an EXPECTED TIME, defined by 3 milestone:
- Goal: the duration the task MAY have, calculated from assignment start
- Deadline: the duration the task SHOULD HAVE, calculated from assignment start
- Passed Deadline: when is TOO FAR PASSED from the deadline, calculated from deadline end (this is not
configurable by a BA, only by a SA), it can be repeatedly
Each milestone can have two attributes:
- Urgency: value between 10 and 100, default is 10, higher value higher urgency
- Escalation Actions: actions to be taken if the milestone has been passed
Add to a case: case type -> life cycle -> settings -> goal and deadline:
- This case: the calculation starts when an instance of the current case is created
- Parent case: the calculation starts when an instance of the parent case is created
- Top level case: the calculation starts when an instance of a top level case is created
Add to a stg: case type -> life cycle -> select stg -> goal and deadline:

User Views
User performs task by entering info in a form, each form is designed for one task, they are defined by:
 - Data element: what info should the user see?
- Format: how the user should enter the info?
- Required: the user see it in read only mode or it is editable?
When a form is complete a NEW DATA ELEMENT is saved in the app and can be re-used
Types:
- Custom form: case life cycle -> step -> configure view
- Std form: case life cycle -> views tab
The form should be:
- Model driven: contextually sensitive to biz env, faster dev and faster changes
- Intent driven: easy to understand what to do
- Simple and obvious: minimize elements, avoid unnecessary, meaningful description
- Common Ui elements: create a pattern
Case design using Designer Studio
Requirement Mgmt
Process of collecting and reviewing PDT REQs
- BO: statements describing the BIZ VALUE the application MUST provide, they define the SCOPE, BA
creates BO to fix inefficiencies
- APP REQS: an AGREEMENT between IT and BIZ, describe WHAT the app should do, they can be:
- ABSTRACT, eg "view order history"
- DETAILED, eg "Modified data in a DB should be updated for all users accessing within 2 secs"
- They have to be a BENCHMARK to test your app against
- They are categorized in 5 types:
- Biz rule: describe the business logic in a step
- Change ctrl: change in the app
- Enterprise std: rules applying to all enterprise or industry
- Functional: function used in the app, data manipulation or calculation
- Non-functional: performance metrics, screen to screen interaction times
- They should be:
- BU Business Term
- CI Clear and Concise
- VI Verifiable
- C Consistent
- APP SPECs: describe HOW the app will work,it is important to define WHO-HOW-WHAT, they should be
- BU Business terms
- CO Complet
- N No change in ownership
- C can be tested and developed
- TRACEABILITY: link SPECS to BO and REQs, specs are the central of traceability in pega, SA link them to
implementation element, and BA link them to BO and REQS: COMPLETE PICTURE of what BIZ WANTS
and IT IMPLEMENTS

CLC Exception
Work to complete that is not part of the primary path
- Alternate stages: exception from the primary path
- NOUN PHRASE
- Max 3+/-2
- Do not have ORDER, managed with transition
- Stg Transition: action in a step or step in a process that allows a CONTROLLED TRANSITION, often with
yes/no decision, for primary stg by default there is transition to the next stg
- Change stage: step in a process that allows an AUTOMATED TRANSITION

Optional Biz pcss

User actions: allows user to do work out of the primary path, but it the user doing the DETERMINATION of
EXECUTION the task, they are:
- Available for a case: when the case is open
- Available for a stg: when the action is defined in the stg
Two types;
- Local action: single screen to update info, the user returns to the primary path
- Optional pcss: multiple screen to update info, the user may not return to the primary path
Sending Correspondence
Pros:
- Timely communication to establish a SHARED UNDERSTANDING
- Keep case workers UP-TO-DATE
- Communicate with someone INDIRECTLY INVOLVED
WHO (roles):
- Owner: who has created the case
- Customer: whom the case is transacted for
- Interested: who monitor the task/work
- Parties: one or more of the previous roles
HOW, shared template, via fax, mail, text message
WHEN define a step in the cases

Guiding through biz pcss

Case status: default new, progress indicator, set at the beginning of a pcss or a stg
Instructions: identify to end user what should be accomplished, architect can set for each step, user sees in worklist

Complex pcss flow

Flow rules: visual method for modelling process flow
Flow shapes: task accomplished as apart of the pcss flow, they can be user action, automated action, automated
decision, they can be
- STD:
- Start, one for each flow
- Assignments, user task
- Utilities, automated system action
- Sub-process, reference to another flow rule
- Decision, automated task defining which path to take
- Connector, define a sequence of shape
- End, one or more for each flow
- SMART: change stg, send email, attach content, create pdf, post to pulse, persist case, create case,
duplicate search, update cases, approval 9route to one or more reviewers based on authority matrix or
username)
Draft mode:
- When you create a new flow rule Pega automatically turn draft mode on
- You can not run in draft mode on production
- It enables you creating flow shapes and connectors referring to flow rules that do not exist yet

Report Planning and Design

A way to understand how BIZ PROCESSES are functioning , where the BOTTLENECKS are and if there are
opportunities to improve

Biz Reports
Biz reports:
- Measure what the organization's work is
- Data used are collected from outside the app and stored in a DB
- Use business metrics: the data you define for an app, ex: number of orders cancelled
Process Reports:
- Track statistics on how work is performed in Pega
- Data defined and generated within the app
- Use process metrics, how long it takes to complete an assignment, how often a SLA is violated

Report Browser
Used for run, organize and schedule reports
Organized in:
- Public category: standard pcss report provided by pega, available to all manager in the app
- Private category: created and saved for individual work manager, they can share it putting in a public
category
Viewable in a summary layout, or list or chart.
You can
- Run report
- Schedule report in the case manager portal
- Create and delete reports
Application Analysis
Analyse business needs and capture them in a form of BO and REQs

Business Analysis
Benefit: Define SOLUTIONS that add VALUES to the BIZ, the value can be measurable (returns) or intangible
(customer goodwill)
BA roles:
- ADVOCATE FOR A CHANGE, help client run the business more efficient
- ELICIT input from different stkh to create an HOLISTIC view of solution
- Propose solutions
- Clarify what the customer MUST have
Key Activities:
- Identify BIZ NEEDS, talk with different stkh, each one has his unique perspective based on job experience
and role
- BIZ USERS, define ROLES/RESPONSIBILITIES
- BIZ PROBLEMS
- What ADD VALUE to the business
Key Questions:
- Why need it?
- Who will use it?
- Who will be impacted?
- How current system work?
- What future system will do?

Define BO
Definition:
- Statements that define BIZ VALUE/RESULTS,
- they define HOW THE APPLICATION DELIVERS VALUE TO THE BUSINESS,
- use action verbs as limit, reduce, increase and update,
- some of them SERVE as MILESTONE to show stkh the MEASURABLE DELIVERED VALUE, they describe
short-term, medium-term and long-term outcome
- they should be:
- S Specific -> Use clear language to describe what must be delivered,
- M Measurable -> include metrics/KPI that measure success/failure (eg. customer satisfaction rate,
customer retention rate, customer engagement, return on investment, conversion rate )
- A Achievable -> Realistic according to biz and that can be reported on TO SHOW PROGRESS
- R Relevant -> to the biz users and it, relevant to pega solution eg. impact core biz revenue or
functions delivered with pega app
- T Time-bound -> with specific end point, completion date, or checkpoints
Template: What/Who - From [baseline] by [rate] - When
Example
Reduce customer support calls for cancelled rental car reservations by 30 percent by the end of the 4th
quarter.
No, the objective is not measurable because there is no baseline rate for support calls 30 percent
compared to what? In addition, the target date does not include a specific year.
Example
BO: Reduce customer response time from 24 to 12 by 3Q18
BASELINE
DESIRED OUTPUT
 REQ: Each customer will receive an email no later than 12 hours after the timestamp for their initial phone
call. The email should includes name, address, phone
WHAT, customer response time is defined, SLA
SPEC: As a customer service representative I want to respond to customer inquiries within 12 hours, so I
can WHO, customer service representative,
TASK, respond to customer inquiries within 12 hours,
OUTCOME, resolve the customer issue

Analyzing REQs
REQ
- WHAT an application must do to meet the biz needs
- is an EVENT/CONDITION/FUNCTION that MUST BE SATISFIED or tracked to satisfy business objectives,
- They define the criteria of successful implementation of the specification
- they can be
- FUNCTIONAL: describe smthg the system SHOULD DO, eg. User should be able to select a
location to rent a car
- NON FUNCTIONAL: describe a criteria that judge the operation of the system, eg DB updates
should be available to all users within 2 secs
Key Activities:
- Identify STKH,
- someone who has interest in or influence over or impact on the proposed solution,
- include sponsor and pega app champions
- They determine functionalities and evaluate solutions.
- THROUGH THE PROJECT continue UPDATE STKH,
- their input have influence over the success of the pjt
- Elicit REQS
- Analyze REQs, review each req to make sure it describes a behavior essential to the operation of the
application
- Capture REQS
Purpose:
- determine EXACTLY WHAT is NEEDED to solve a biz problem and resolve AMBIGUITY
- Define APPLICATION CAPABILITIES
- Ask question (CONVERSATIONAL) or to tell a story, to clarify input and find IMPLIED REQs
- Focus on WHAT to build and WHO will be using:
- What does the new application need to do?
- What is the end result?
- What are the key capabilities you hope to have?
- Which capabilities are the most important for you?
- What information needs to be reported on?

Writing REQs
REQ:
I they are poorly defined, the likelihood of delivering a solution satisfying business objectives is reduced
They can be ABSTRACT or DETAILED
They describe a DESIRED BEHAVIOR and they have to be:
- Ve Verifiable, testable condition
- CC Clear and Concise, use max 30-50 words, no definitions, positive language, unambiguous
- Com Complete, all info, usable as a benchmark
- Con Consistent, no conflicts with other reqs, use the same terminology in order to avoid misunderstanding
- Tra Traceable, link to specs in order to verify a req is well implemented in the app
- Ne Necessary, to the scope of the app
 - SF Solution-free, no approach or solution defined
- U Understandable, by biz and it
- Vi Viable, it team should implement within schedule and budget, within the scope
- G Granularity, individually testable, you can think to a small number of tests
- S Singular, no redundant
They are categorized in 5 types:
- Biz rule: describe the business logic in a step, RULE (smth that defines, constraints, enables) for
ORGANIZATIONAL OPERATIONS. Business derives conclusion from a condition, often associate to a step
in the process, manual or automated, to identify desired system behavior, often in a form "when/if - then":
eg. Request over 5000 require CFO approval
Rule Example

Promotion If it is December, then the December to Remember campaign is active.

Regulatory If the employee is terminated, then the employee cannot log in to the system.

Security If the user is authorized, then the user may approve the expense reimbursement.

Credit score If the person has a credit score below 650, then the person cannot be auto-approved for a loan.

- Change ctrl: change in the app before or after release, eg. Reduce goal approval time to one day
Change control Example

Automate printing Replace existing manual system to print distribution paperwork with automated solution.

Credit check Change credit score verification functionality to new credit score web service.

- Enterprise std: rules applying to all enterprise or industry, eg. validate format of email address when
entered
Requirement Business need

Customer statements are generated in SAP format. Specific format for statements

Website home page for each rental car location includes company logo. Corporate branding guideline

- Functional: function used in the app, data manipulation or calculation, what SFTW SYSTEM SHOULD DO,
similar to biz rule, but ti[ically describe an automated system function, eg convert telephone num format to
xxx-xxx-xxx
Requirement Release
User filters new cars by make Release 1.0

User filters used cars by make Release 1.0

User selects new car Release 1.0

System sends email when user requests a quote. Release 1.0

User filters used trucks by make Release 2.0

User filters Certified Pre-Owned trucks by make Release 2.0

- Non-functional: performance metrics, screen to screen interaction times, CONSTRAINTS/PERFORMACE

on HOW the SYSTEM SHOULD OPERATE, eg. Return order query results within 40 secs

Non-functional Example

Usability Alarms can be set to display on the user interface and play as audio files.

Performance User receives email no more than 12 hours after requesting a quote.

Availability System must be available 99.9 percent.

Reliability Redundant system with real time failover.

Scalability System is able to accommodate 5 million users (baseline 2 million).

Data Migration Historical data is uploaded in bulk one time.

Certification Solution must comply with NERC CIP version 5 regulations.

Security Payment transactions are submitted securely.

Permissions Users have read, write, and/or delete access, depending on role.
Operational During outages, calls are routed to the backup call center.

System The system is available 24/7.

Compliance Customer transaction data is archived for seven years.

Delivery The website will be rolled out in stages. The first release will be for MA, NH, ME, VT, NH, and CT.

Licensing There are no licensing requirements for release 1.0.

Application Profile
Document that describes WHAT APP WILL DO,
it is a BUSINESS ARTIFACT that contains the BUSINESS RELATED INFO associated with the implementation of a
pjt,
It supports DCO, Business analysts, system architects, and other project members collaboratively and iteratively
create the content in the application profile. This collaborative effort increases the likelihood of a successful
implementation, because core business questions are asked and discussed, with the answers documented in the
application profile.
it is divided in:
- Executive Summary:
- App Overview/Description: briefly description of what is VALUABLE to the CLIENT, example
- An expense report application will eliminate the need for employees to create their expense reports
using multiple spreadsheets.
- BO: biz OUTCOME and GOALS, ex:
- Reduce the rate of customers calling the customer service team by 500 per month by June, 2018.
- REQs: BEHAVIOR of the APP, ex:
- The manager is able to review expenses online.

Quiz
New BA on a pjt: prepare for the first meeting with sponsor?
Review existing reqs
Talk to pega members who are familiar with the customer, to help understand the customer needs.
New BA on a pjt. Pjt sponsor on one hour meeting to introduce team, attendees include pjt sponsor and biz
stkh, your goals?
Listen for pjt sponsor to describe things they want the pega app do
Identify biz experts who can summarize and clarify what you heard during the meeting.
Application Design
Step in which you ensure the PLANNED biz APP satisfies the BIZ NEEDS, collected in BO and REQS

Application Design
Establish a BLUEPRINT of the app, defining what is REQUIRED and what is EXPECTED
BA roles:
- Help stkh define HOW APP will WORK
- Communication bridge input between biz stkh and it, to ensure everyone shares a common understanding of
REQS and proposed solution design
- Interpret biz needs;
- Translator
- Resolve conflicts
- Define app and effort needed with specs
Key Activities:
- Review BO and REQS, manage change on reqs from biz and dev
- Identify solutions that meets biz needs, in order to bring the most value and the design meets all the reqs
- Establish reqs traceability to ensure the solution conforms the reqs
- Identify opportunities for improvement in the operation of the system, eg. automating business policies or re-
using pcss
- Record SPECS in pega, synthesize stkh input to create high level specs, write specs from the perspective of
a single user

Writing SPECs
Key Activities:
- Describe specs (name, short name, description), ex:
- Name: Collect Personal Information
- Short description: Collect personal information for an employee
- Description: Collect the following information: first name (required text field), Last Name (required
text field)
- Define details (case type, specification type, LOE), ex:
- Case type: Onboarding
- Specific type: UI
- Complexity: Low
- Define traceability (link to Bo and REQS, biz impact)
- BO: Eliminate errors in personal information
- Impact: Medium
- Requirement: Enroll in Benefits Online
Ex;
Name; Enter Expense Details
Short description: Enter itemized list of expense details
Description: Employee enters itemized list of expenses: Expense item (text, required), Expense Amount
(currency, required), Date of Purchase (date, required)
Case type: Expense voucher
Spec type: human based type
Complexity: medium
Business Impact: High
BO: Eliminate out-of-compliance expense reimbursement requests

Purpose:
 - Agreement with the customer
- Point of synchronization
- Instructions to the architect
- Baseline for master plan and schedule
Type:
- Business use case: multiple user, entire process or set of steps, describe a step in the process, change in
authority
- Atomic use case: single user, single step, no change in authority, describe the behavior of a single step

Delegating Biz rules

Purpose:
- Shared responsibilities
- Decrease the workload of an architect
- Provide a level of empowerment to the biz user
- Increase the ability of the app to change
- Let agile response to the ever changing biz env
- Key activities for a BUILD FOR CHANGE STRATEGY
Biz rules to delegate:
- SLA,time allocated to complete assignments can change based on the seasonal adjustment or financial
constraints
- Flows,
- constraints, might need regular updating, ex: interest on loan
- mkt conditions, regulation,
- decision tree
- Decision rules, such as "when" rules and "decision tabels"
- Map value
Document delegated rules:
- During design time
- Create appropriate and complete documentation
- Short and meaningful description in the biz context
- Try to create a sentence with biz rule name + type + biz logic, to check if the rule is in a biz context
- It is useful to define a small set of volatile rules to manage in production
- Once created in the dev environment and moved to prod, rules can be managed in AUTHORING
ENVIRONMENT (biz user can tested without impact on production, once tested the migration wizard can be
used to promote rules into production on a separate cycle form dev)
Application Elaboration
Application Elaboration
It is an ITERATIVE and COLLABORATIVE ELABORATION that clear the reqs
Ba role:
- Ensure pjt team has ALL INFO to build the app
- Ensure the DESIGN DECISIONS have incorporated the knowledge and the reqs of stkh
Activities:
- Conduct G/E to achieve AGREEMENT between all parties
- Define APP BEHAVIOR
- Define biz and automate CHANGES
- Deine BIZ NEEDS and their RELATIVE BENEFITS
Purpose:
- APP FEASIBILITY
- TESTING before CONSTRUCTION begins reduce risks
- BASELINE ARCHITECTURE
- EVOLUTIONARY PROTOTYPE, including production quality elements and re-using existing
component/subprocess to mitigate specific risks
- Ensure baseline architecture support reqs, within COST and TIME
- Giving a SUPPORTING ENVIRONMENT
- Ensure reqs, plans and arch are STABLES
Duration: simple <= 2we, complex >= 1month

G/E session
Provide STRUCTURE and FORUM for gathering info on FIXED SETS of SPECs
Purpose: gain CONSENSUS and APPROVED PROTOTYPE, approved set of app specs and gain consensus
among all biz parties
Styles:

Prep and review Realtime whiteboard Realtime capture

SME availability Part time Full time Full time

logistic Geo dispersed On site On site

agile waterfall scrum scrum

Decision making Multiple decision maker, 1 or 2 decision maker, fast 1 or 2 decision maker, fast
slow

G/E skills good expert expert

scope Data-heavy, integration, Generic user views reqs, Process-heavy, screen,

more complex process, less complex less complex

Time schedule More flexible limited No timeline flexibility

Output: Validate REQS, approved SPECs, CLC refined, UV draft

Roles/Responsibilities
 Prep stg Session stg Post stg PB stg

MOD Drive toward scope Closing PLI Drive toward scope

Drive best practices Drive best practices
Lead session Lead session
Arbiter Close PLI
identify/assign PLI

SME Review SPECS SPECS: Follow up on PLI Validate:

Develop OQ Concerns Decides what is next CLC
Gain consensus on Confidence score UV
TOBE PCSS Sticky to scope SPECs
Fully engage
Decisive FB

SA Uses SPECS to Ensure documented Follow up on PLI Decisive FB

create DRAFT CLC SPECs are Create CLC and UV Update CLC and UV
and UV implementable MOCKUP
Understand SPECs

BA Review SPECS Drive best practices Follow up on PLI Manage FB

Develop OQ Seek clarification on Plan PB Ensure biz have a
Gain consensus on REQs Refine SPECs VISUAL of SPECs
TOBE PCSS Decisive FB
Act as a liason
Plan sess stg

QA Draft Test plan Update test plan Update test plan

IT Ensure how new Answer to pjt team Ensure how new

impact existing it questions on CLC impact existing it
infrastructure and and UV MOCKUP infrastructure and
evaluate if there are evaluate if there are
adverse effects adverse effects

Prep stg
Roles: BA, SA, SME
Activities in kickoff after session style defined:
- TASK assignments
- Set EXPECTATIONS
- EDUCATING team members
- Plan SESSION SCHEDULE
- Send INVITATION
- Identify PROCESS OWNER
- Prepare ARTIFACTs and CLC drafts
Purpose: ACCURATE ARTIFACT CREATION, gets reqs and specs clearer giving a speedier approval
Resources: high-level specs, business process diagrams, reqs
Output:
- C Confirm SME has the CONSENSUS of all biz parties
- C Ask SME to identify and track CLARIFICATIONS, SUBTRACTIONS
- C Have SME COMMITMENT to review ARTIFACTS before the session
BA and SA organize SPECS in SETS and tie the sets to BO and REQS
G/E Session
Roles: BA, SA, SME, QA, IT, MOD (can be substituted by a BA)
Activities:
- Mod: sets GOALS and EXPECTATIONS, brief overview of the PLI (Parking Lot Items)
- BA and SA: validate/adjust CLC, review step-by-step the UV
- All: review CLC and draft, find dependencies, which require elaboration too
Purpose:
- Find SPECS and DEPENDENCIES
- Review CLC and UV without spending too much time on PLI
Best Practices:
- SIMPLE PRESENTATION of the pjt at the beginning of the meeting
- General OVERVIEW of the CLC, so the participant are focused on the goal
- Update ARTIFACTS asap, less inaccuracy later
- Ensure SME is the DECISION MAKER
- PLI <= 10
- Max DURATION 4 hrs
- Limit to NECESSARY RESOURCES
- Sticky to AGENDA ITEMS

Closing G/E
Output:
- CLC and UV refined with FB incorporated
- PLI with follow up plan
- PB scheduled
- Team CONSENSUS on the project artifacts

Post stg
Activities:
- SME, BA and SA Follow up on assigned PLI
- Assure the ACTION ITEM RESOLUTION within expected time
- TEAM discuss on the session outcome
- IT answers to the team questions on the mockups
- SA prepare MOCKUPS of CLC and UV and should build a RELEVANT PORTION of the app
- BA plan and schedule PB and REFINE SPECs

PB stg
Activities:
- Review mockups
- Gather more FB
Purpose:
- Provide instant FB
- Giving a FORUM for biz with QA and IT
- Encourage communication between biz and it
- Clarify reqs
- Draft artifacts let SME and PO VISUALIZE the PROCESS
Output: REFINED CLC and UV with no more FB to be addressed, VERBALLY APPROVED
Approval stg
Purpose: receive written approval, after SA will start build the app and the team will move forward

Common Challenges
Limit number: G/E session to 5 SME (at least 2 topic experts), PB session to 6-10 (2 topic experts)
Sme schedule change: plan another session
Sme substitute: defer to the designated sme
Non standard pcss: ask to follow up after the session and clarify
Out of scope specs: details them and then go back to the agenda items
Uninformed sme: help him recognize people who have knowledge, to involve, or help him to find the necessary info

Document the app

Purpose:
- All info in one point
- Wizard that produce doc from any/different source
- Doc produced iteratively
- As the app progress the doc is more detailed

Quiz
If PLI>=12, you are the MOD:
- Request another SME
- Review PLI after the agenda topic