In my role as Transformation Director, I have seen many organizations working in silos. Unfortunately, in these cases, interactions between Pega teams are limited and potential re-use is identified too late in the delivery process. Sharing project experience, best practices, roadmaps and re-usable components can not only avoid potential problems and issues, but also significantly increase your organization’s success, application performance, and quality. But how should you set up your organization for success? In this blog you will learn about operating model essentials and additional options to get the highest possible value out of your investment.
Basic Operating model
I’m sure you have already heard about the concept of a Center of Excellence (COE) and maybe even about Communities of Practices, but what does this mean? Let’s first zoom in on what should be expected from your existing project teams and from a COE.
Project teams (also known as value teams, delivery teams, or just Scrum teams)
Most organizations are already familiar with some form of Agile methodology and have the recommended project team roles in place. If you are not familiar with these team roles, in Scrum all teams should have a dedicated Product Owner, a Scrum Master, test capacity, and resources from the Pega Business Architect and Solution Architect job families. Or maybe you have already explored how Citizen Development on Pega’s Low Code platform can significantly speed up your implementation and seriously shorten your application time to market. What all these teams have in common is that they deliver direct business value. The typical responsibilities of a project team are:
- Application design and configuration according to business needs.
- Making the application ready for release. It is highly recommended that you visit the Pega Express Go Live Checklist and make sure all topics are covered.
- Application deployment to production after platform owner approval.
- Application monitoring and bug fixing once an application is in production.
Center of Excellence (COE)
Pega defines a Center of Excellence as the governing body that works across business and IT to provide leadership, enablement, support, and governance for all initiatives built on Pega Platform™, concentrating on providing maximum business benefit and accelerating time to value with repeatable success.
A COE typically consists of a COE manager (preferably with delivery best practice knowledge and skills), a Lead System Architect (LSA), a Lead Business Architect (LBA), and a part-time User Experience (UX) expert. Over time, the COE can be (temporarily) extended with roles such as a Quality Assurance lead, Project Management Office, Release Management, Security Expert, additional development capacity, or whatever roles are required. Best practice is to start small and tailor the COE according to your needs. The work of the COE should be managed using an Agile approach (many COEs opt for a Kanban approach). For knowledge sharing with the other teams, a COE can organize lunch-and-learn sessions, share regular newsletters, document best practices in a wiki, have direct interaction with (new) teams to kickstart and support the teams, and work with Communities of Practices.
Typical responsibilities for a Center of Excellence are:
- Handling new project intakes
- Design authority role
- Providing guidelines and best practices and optimizing delivery models
- Coaching citizen development
- Driving innovation
- Stimulating re-use and knowledge sharing
- Designing and building reusable components
- Approving production deployments
- Owning all Pega environments, including platform sizing and performance
- Managing Pega software upgrades
Optional: Pega Platform teams
Variations on the theme are also possible. In some organizations, the COE can become a larger team and so some of the responsibilities are transferred to a dedicated Pega Platform team. This Pega Platform team could be made responsible for some of the original COE tasks. Typical Pega Platform team tasks include managing platform size and stability, managing software upgrades, building base layer common components (such as SSO, data integrations, and so on), and giving release approval. Like other teams, the Pega Platform team’s work should be managed using an Agile approach. Given the nature of the work, a Kanban approach can again be considered.
Remember that it is important to design and adapt the operating model and size according to your organization’s needs. You should make sure that the responsibilities between the various elements in the operating model are clear. This could, for example, be done by creating and publishing team charters.
An example of an organization with a COE and a Platform team
Extended operating model: Communities of Practice
On many assignments, I have seen that LSAs from the different project teams start to meet in a regular cadence. This is due to the dependencies and re-use options that they have, being in the same Pega Cloud™ instance, or simply for learning from each other’s work. These activities can already be considered a Community of Practice (COP). The same may go for other groups with similar expertise in an organization.
Nevertheless, it is worth considering formalizing these communities for various roles and making them an integral part of your operating model. LBAs, for example, can discuss effective Directly Capture Objectives (DCO) strategy, Definition of Ready, and story templates. Product Owners can discuss what has been built, what is on their roadmap, and about planning updates to new versions of Pega software. Citizen Developers can also support each other in their low code implementations.
My recommendation is to have a representative from each team in a COP. This team member can share with their peers in the team what has been discussed, or can bring the team’s questions to the COP. In general, this would be the most senior consultant from the team in that role. Work should not take more than only a few hours every week. Other recommendations for a Community of Practice include:
- Install a COP lead who plans the community sessions, aligns the agenda with the COP members and shares notes (tasks can be delegated). This lead can be someone from the COP or the COE.
- Agree with the COP how often the community will meet. For LSAs and UX communities this is typically on a weekly basis. For other communities this can be every 2-3 weeks.
- Take community work into account during sprint planning.
- Ensure that the Community has a task list to manage work. A Kanban board is perfectly suited to COP work.
- Document best practices and deliverables created by the COP. Here, a community can support a COE by taking ownership in a particular area of expertise.
- Tasks can be delegated from the COE to a COP, for example, creating reusable components.
A comment that I often hear made about COPs is that they take time away from project team members. While this is true, it is also important to remember that your organization and teams will benefit even more from sharing best practices, stimulating re-use, and increasing the overall level of knowledge within your organization. All of this can lead to shorter time to market, improved quality, and cost savings.
In short, to optimize your organization's success it is vital that your Pega teams start to interact and share best practices, knowledge, and their roadmaps, and re-use what is already available. A COE will provide leadership, enablement support, and governance for all your initiatives. Remember to start small and tailor the COE and other elements in your operating model over time, such as Communities of Practices, or by adding a Pega Platform team, according to your organization’s needs.
Interested in reading more about scaling your Pega enterprise or just how to start with your first Pega project steps? I highly recommend taking the time to read the Pega Transformation playbook
Recommended Links:
Don't Forget
- JOIN THE CONVERSATION on Support Center
- FOLLOW @PegaDeveloper on Twitter