Posted: 23 Jun 2016 17:43 EDT 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?
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.
When I say Pega, it's not Pega as a company, it's development team building applications on Pega tool.
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
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.