Discussion
Bcbsnc
US
Last activity: 27 Jun 2016 22:26 EDT
What is the rule of thumb on dividing the work between LBA and LSA in DCO session?
the Application profile is very different in Pega 7.2 than in Pega 6. It used to be that LBA creates the process and requirements in Application profile. Now with Pega 7.2, looks like there is no Application profile as what was offered in 6. And all the things are broken to pieces. Now you have application overview which covers requirements, specifications and etc., and you have seperate places for case, process/flows, UI and etcs. Can anyone give some rule of thumb on who is responsible for what, I mean, in terms of LBA and LSA?
Telstra
AU
LSA doesn't actively participate as LBA does in DCO sessions. Most of the times, LSA just sits quiet and lets LBA drive the DCO session by jumping in when necessary. LBA is a liaison between Pega and Business/IT Team.
LBA
- Responsible for driving DCO sessions
- Reviews BRD and opens a dialogue
- Tells customer what can be/cannot be done in Pega
- Tells customer the complexity of the requirement being discussed
- Document the requirements and specifications
- Think from customer's perspective also to shape a solution which exceeds customer's expectations
- Should provide a clarity on how BRD is being converted to Pega Requirements and Specifications
- Not essentially LBA but Pega team BA is responsible for
- Testing the application from time to time
- Sending release notes
- Coordinating deployment schedules
- Educate business on how things work in Pega from time to time
LSA
LSA doesn't actively participate as LBA does in DCO sessions. Most of the times, LSA just sits quiet and lets LBA drive the DCO session by jumping in when necessary. LBA is a liaison between Pega and Business/IT Team.
LBA
- Responsible for driving DCO sessions
- Reviews BRD and opens a dialogue
- Tells customer what can be/cannot be done in Pega
- Tells customer the complexity of the requirement being discussed
- Document the requirements and specifications
- Think from customer's perspective also to shape a solution which exceeds customer's expectations
- Should provide a clarity on how BRD is being converted to Pega Requirements and Specifications
- Not essentially LBA but Pega team BA is responsible for
- Testing the application from time to time
- Sending release notes
- Coordinating deployment schedules
- Educate business on how things work in Pega from time to time
LSA
- Jumps in and advises if customer is trying to make things complex by suggesting complex solutions
- Advises the customer on Case Structure. This is important as this is foundation for any project
- Advise LBA on the timelines and complexities
- Analyze solution architecture provided by Solution Architecture team and provide inputs on how Pega will best fit into the big picture
- Provides estimates with no. of resources and timelines etc.
- Assists LBA if discussions get too technical like which integration should be used, SOAP or REST?
- Steers LBA into right direction if LBA is making decisions without proper LSA consultation
- Highlights re-usable components available
Few points to be highlight
- LBA shouldn't come to conclusions before getting LSA's nod
- LBA shouldn't contradict what LSA highlights in front of the client
- LBA shouldn't get involved in resourcing and timelines
- LBA shouldn't architect technical solution (LBA should architect business processes)
- LBA shouldn't create class structure/run app accelerator
- LSA shouldn't ignore LBA's opinions
- LSA shouldn't dominate LBA on optimizing business process (functionally) - BAs are more familiar with business processes than LSAs.
- Don't have more than 1 LBA and 1 LSA per project. Too many cooks spoil the kitchen.