PegaWorld iNspire 2024: Turbocharging Delivery For Outcomes – Implementing 12 Pega Applications In A Year

My name is Rexy Joseph. I head the digital process automation practice within Cobridge Financial. So this is today. We are going to speak about turbocharging the delivery. So thank you very much for coming over. Uh, in this session, we are actually going to speak about how we went about delivering, uh, 12 applications. In fact, the initial list was around 22. And then we finally ended up, uh, you know, deciding around going with 12 applications that was brought down. So before we start, who is Cobridge Financial?

Most of us have not heard about Cobridge Financial because we are a fairly new company. Uh, we started our journey in 2000, 22nd September, when we were iPod. Most of us have known Corbridge. If you have not heard about the name, you might have heard definitely about our parent company, AIG. So we are the life and retirement division of AIG. In 2020 2nd September, we were ipo'd out as an independent company. And the latest news as of yesterday, AIG deconsolidated most of their, uh, you know, their shares from Corbridge as well. So we are now a wholly independent company as well. Uh, a brief about Corbridge.

We sell a lot of insurance products, especially around in our retirement and, you know, retirement and annuities as well as life policies. Uh, we have a proven track record of servicing our clients. And this has our journey has been beyond, you know, even AIG acquired us a long time ago as well. Uh, we have close to about $384 billion worth of assets under management, uh, close to about $40 billion worth of premiums and deposits. And we, you know, the moment of truth. Close to about $47 billion worth of claims that goes out. That number the last number is an important number because we actually have some of it going through an application that we built now that we have click baited you into coming into this session by saying 12 applications turbocharging, I promise you I'm not here to sell insurance policies, right. My goal is to definitely talk about what we did. But each and every story starts with a story, a back story of what we have done to get to this stage.

Our journey with Pega starts started about six years ago, right where we ended up building. We started off with one of the biggest and the most complex applications. We started off with that, right? We built an end to end live claims platform. The first. It includes the first notice of loss. We manage the claim handling. We manage the policy management, we do the management. We also built out a reusable component for requirements management.

So whenever a claim comes in, you want to decide how do you want to pay that off. So we automated all of that inside this Pega Platform. And we didn't just stop there. We went beyond that. We did the payment calculation, the interest calculation, the end to end disbursement. So in one platform we built all of this platform, all of these solutions and capabilities. And we did it as our foundation component. So when we went in with this platform, we decided and we knew that all of our admin systems has to be integrated with all of our core platforms, needs to be integrated with. So we spent close to about a year and a half as we built incrementally, we started thinking through how to make sure that each and every component we build is reusable.

That is now put into our foundational component. And I'll tell you the story about how this has helped, because this now helped us tackle one of the most complex business case or business processes within insurance companies. The entire claims handling process at the same time. Why we did also, another part of it is we built an actual workflow. As part of the model run process. We built a process, an end to end starting from conception to implementation was in 45 days. So we also proved the fact that not only can we handle complex processes, we can also handle the agility at which we can deliver it. So our trust and building it out in that foundation was built out. The next is now that we've built out this foundations, how do we consolidate.

Right. So we started then by consolidating all of our learnings, all of our abilities and capabilities, and started expanding across different spaces within Corbridge itself. At that time, we were still AIG. We were part of AIG. So we started building out components. That was the first time when AIG announced the potential that they're going to separate us out of their business. And at that time, we also had a platform called complaints for a Global Complaints. We actually used, uh, an AI system to build it out. So it was a it was a Pega based application that we, we in LNR was also referencing within AIG.

So as the separation came out, we needed a platform for ourselves. So we ended up building another Pega application. But this time it was with the difference. We didn't want what was with AIG. We wanted something that was more custom and processed for us. And we built out an end to end solution in under two months that was delivered from concept to delivery, and we delivered it at that point. Now, that also allowed us to create a lot more other foundational components, and we built it in such a way that our application now not just sits for one business unit. You started replicating for fraud, which is which is similar to anti-fraud management, which is similar to complaints from a processing perspective, we actually ask for escalation management, which is again a very lightweight version of a complaints, where complaints are big complaints, as we call it. But there's a small see complaints where our escalations which has which are numerous.

But we handle that. And that's the same foundation that we were able to replicate it across the other systems as well. What we also did within that particular part of the process is that we were able to standardize, how do I extract, extract data and documents from a source system and then move it into a target state and then provide a way for us in the new system to be able to reference it? Right? Remember, this is very important because when we talk about turbocharging our 12 application this comes into play. So we built that component out in such a way. We realized about three years ago that we will be getting into a lot of these situations where our source systems will be migrating to our target platform and data and documents that was in the source. Older platform needs to be moved over as well, so built a reusable component that actually allowed us to do it and that helped us accelerate a lot. So we'll talk about that more later.

Finally is our acceleration. We used all these learnings that we built out by the time we were done with the consolidation. One thing I missed to say was the claims platform that we built, that was built for the life side of the business. We took that entire platform and under two months we deployed it for the institutional market range as well. So that provides us with the ability that we can reuse our code, the code that we built for our claims. Our life side of the business was 90% reusable, as is, because the only change was the product and certain business rules that governs that product. Everything else, process wise, was standardized, and that gives us the confidence that we are ready to go. Now the key question comes we did all of this, but for what? The key part here is when we went for our IPO, we decided to build our own home right when we were talking about building a new home.

This is the other background story to what we did as part of this turbocharging. The key we have to understand is AIG. We were all hosted within an AIG domain. Think this through a network, an application that is built and stored that anytime you want to access that platform, you are saying AIG claims Pega.com. Now that entire system has to change to corporate financial. Com that's a rebranding work that we need to do. The entire brand has to change to this new platform. So we need to set up everything from ground up. Our entire network infrastructure has to be set up.

As we set up that infrastructure, we have to put together our security, our hosting, our IAM connections. Then we have to start deciding on what applications we want from AIG because we are effectively separating. There are certain applications that were mixed together that we wanted to separate it out, some of them that was wholly owned by Life and Retirements. We got it very easy. But the ones that are like our HR platforms, there are certain other systems that are actually very much, uh, mixed together. We want that also to be cloned over and brought it over at the same time. While this is happening, we have to migrate our users. We have to migrate our systems. Uh, and there was a time when half of the users migrated, half of the applications are migrated, but the same set of users that migrated to the new environment needs access back into the AI systems, because they are also working happening there as well.

This was the complexity of the environments that we were in in the middle of all of this, as we're building new house at any point in time, once you build a new house, there's this thought process do I carry my old stuff that is there in my attic and my garage, and do I move it to this new house? No, I don't want to do it right. So if I have an opportunity to reduce it, I will take that opportunity and reduce that. And that's what this session was about. That's what this initiative was all about. So we took some of those applications. We decided to rationalize it, and we then moved it over onto this new environment that we have. Okay. This is the context.

This is our you know, our foundations helped us to decide on this, and this is the context under which the team performed what we are about to discuss and listen to. So I would like to welcome Rahul. Rahul leads the Pega practice from for Coatbridge. So I will have him speak about how he and his team did this. Thanks for for setting that up so well. So. Hello everyone. Uh, thank you for being here. I understand it's the last session of the last day.

I'm glad you had some fuel left in the tank to be able to make it. Extremely excited about sharing the story. This is obviously was a very complex implementation, but also in a very unique set of constraints which you typically will not find on a normal Circumstances. So all those things coming together, we want to be able to speak to what exactly? How exactly do we do it? How we manage to do it. So you mentioned that, uh, you know. You know, I actually want to spend a little bit of time talking about the app rationalization program itself. So there was separation happening.

So what, since we're kind of fundamentally setting up a new organization, it kind of gave a very unique opportunity for us to look at the organization, see what our cost structure is, where do we want to go forward. Right. What is the target state, what business capabilities do we need and what is sustainable from a cost perspective and kind of managing this entire ecosystem? So we obviously were doing a bunch of things. We were setting up new infrastructure. We were migrating to the cloud. And we also looked at the application portfolio itself right now, specifically from a workflow and automation perspective. Um, there are a couple of, uh, you know, problems that we did see, right? One was we had a bunch of multiple workflow platforms in a typical organization.

Large organization by default over a period of time, there's a lot of proliferation, which happens built for very specific purpose and over time not really invested in its, you know, supporting a particular function. But at the end of the day, it's not really meeting the business satisfaction. Right? So it is kind of trudging along but not really doing the job that by default also results in a higher technology cost. Right? There is cost in terms of maintaining licenses. Again, we were kind of stuck with certain kind of arrangements, which was not conducive from a cost structure perspective. So we wanted to use the opportunity to also kind of reduce that. And at the end of the day, it was also not positioned for growth.

We wanted we knew that as an organization, there's going to be a substantial amount of automation and workflow that we will invest in. But at the end of the day, we want to be able to rationalize it. There should be a consistent strategy from an architecture perspective that meets the business needs. Now, what is the fundamental solution? And it was fairly obvious based on, you know, the nature of the problem statement itself. One is we want to be able to kind of rationalize the app portfolio. Uh, you know, identify what the target state workflow platforms will be. And anything that did not make sense from a long term perspective, we wanted to be able to kind of, uh, you know, rationalize that and kind of remove that, which automatically impacts, uh, the it opex that we had. Uh, we wanted to kind of reduce that so we can kind of translate that and move that for growth.

Right. We want to be able to not kind of just run the, uh, you know, keep the lights on, but also kind of make sure it's efficiently done so that we can, you know, invest the balance of the money in growth and eventually positioned for a target state. We want to be Cloud first, we want to make sure that the business has the capabilities that they need. Right. As soon as possible. So the conclusion that we kind of came to is, uh, we wanted to remove, uh, one of the workflow platforms that we had and moved to the target state, which from our perspective is Pega. So I've spoken to the why of why we needed to do this, right. So the question is how did we execute on it? Um, there were basically broadly done in two parts.

The first thing that we did started off was a discovery phase. And this was extremely important, I believe, because the amount of time that we invested in this about like a month and a half odd, was extremely important in terms of the success that we derived later. And I'm going to speak to some length on this specifically, but broadly, there were three aspects of it. Uh, one was the business case. A large part of the entire exercise is driven by the fact that we want to rationalize the cost structure from our perspective, but is there even a business case around it? Right. So we looked at, uh, what is the current licensing and maintenance costs that we have for these platforms? Uh, what will be the cost to achieve? What will be the time period that we'll get a return on.

It became pretty obvious to us pretty early on that there's a good business case to be had here. The second part of it is the roadmap, right? Like how do we fundamentally execute this. So we looked at the scope actually mentioned that we're speaking of 12. But we actually did start with 22. We saw that actually there were 17 which were relevant from a corporate perspective. And we started during this recovery period having discussions with sure you had these. You have a particular use case, right. And you you obviously need the same capabilities in the future, but is there a better, efficient way of doing it right?

So we actually found a good replacement or a good solve because there were other initiatives that are happening from an organization perspective where these use cases could be met for. Right. So by default we automatically reduce that by another five applications. And that's how we arrived at the the 12 applications. We looked at all the stakeholders because we were impacting multiple user groups across treasury capital markets, investments, ISO. So we made sure that we kind of reached out to all those people. Everyone's aligned to that. Identify all the risks and all the moving parts that were a lot of them. I'm going to spend some time talking about that and then, uh, change management.

Right. So work through all these aspects, then looked at the delivery approach. How do we structure the team? What are the resources and skills required. And and how do we set it up from a plot perspective. So then once we essentially got the go ahead from leadership that yes, let's go ahead and do it. We got to the implementation phase. So again so many applications. We created multiple pods at this point in time, each one fundamentally kind of working in a factory model.

It's almost like one in the next. You know, as soon as they're done with, they get to the next level and they move on from there. I actually want to spend a little bit of time talking about these chevrons that you're seeing, right? Like for all practical purposes, there are three pods and 12 applications. We didn't just like play bingo to decide like which application goes where, right? I mean, we spent some time thinking about it, right. And it was extremely crucial from our perspective, from our success perspective, to make sure that we get this right. So what were the things that we kind of, uh, used as determination factors, right? One was, uh, we wanted to get some early success for something where you're building so many applications.

Right. You do want some early success. So we picked up at least two applications, which we knew had high relative, you know, potential success and made sure that we get that initial momentum. But we also don't want to leave all the hard stuff for later because we were time boxed, right. There was only so much we had to finish at the end of one year, right? So we want to make sure that we at least kick off one very hard application. Right. And uh, and a get that out of the way. But also make sure if there's any kind of potential risk, etc., we are able to consume it later versus leaving all of that for the end.

The second thing is we looked at, uh, the team, right. Uh, and we did a mapping of which application best fits into which team. Right. So just want to make sure there's a high probability of success for the implementation itself. The another thing we looked at was we wanted to make sure that there was no too difficult applications back to back. Right. So at the end of the day, you know, this is a Sprint but being done over a year. So you want some dry gunpowder at the end of it. You also don't want to kind of amplify the risk if you're running behind any of them.

So you want to make sure there is that kind of cadence built in. Uh, there was a lot of ambiguity around the scope itself. Right. So I mentioned that we're doing this, we're doing physical separation. But there was also a Treasury transformation happening. There was also an investment transformation happening. Right. All of which impacted as to whether we actually need to build this or if we need to build this, how do we build it? Right.

So those are decisions that were not made when we started off. So we want to make sure from a timing perspective we place them accordingly in a way where those decisions would have been made. And then the last factor, which is the probably the most critical factor is the physical separation, right? I mean, in all of this, we had to make sure that we build this, but we, you know, physically separate the Pega infrastructure, but we also make sure that all the infrastructure that is being moved around, right, which we are impacted by, those are not impacted because at the end of the day, that's the bigger priority. So that's again, like some of the discovery that I spoke about kind of played into how all of the sequencing happened purely from an approach perspective in the implementation. I mean, each port, as I said, was kind of running on a factory mode. The general approach at a very high level was we were building it. We were deploying it for the business, at which point in time we were migrating all the data, all the documents over, and we made sure it was available to the business in this new application, because these applications have, uh, lots of historical data that's required. So they should be able to access it in an easy way.

So we made sure that's there. And we allowed the business just to kind of reduce the pain from a transition perspective to complete what they were doing. So if they were in the middle of a process in the earlier application, let them finish in that application itself. We would do the delta migration and move on. Right? So that purely from a change management perspective, it reduced the pain for the business itself. So they were fine. We had to make sure that depending on what kind of application we're talking about, because certain had long tails, certain had did not. We had to kind of sequence it, plan for it, but for practical purposes, that kind of baked out.

And at the end of it, the most important point is we had to decommission it. So we just kind of the entire infrastructure removal, the data removal, everything had to be done. And that's pretty much like rinse and repeat and repeat kind of kind of continue with that entire process. All right. So moving on to, you know, the you spoke about like what we did. Right. Now this of course, you know, I've probably touched upon a few of these talking points. I won't spend too much time this, you know, uh, you know, we were doing all of this, but also it was a fairly challenging, complex environment that we were kind of navigating. Uh, one was the scope lockdown.

I spoke about the fact that you start an engagement like this, but you don't even know which applications you're building or how you're building. And that was problematic. Right. And, uh, you know, it's, uh. And it was not that. We just didn't know that it was it separation happening. But there was also business separation happening at some level because the organizations were separating, certain business units were moving. So ownership of applications, ownership of business processes, those things were not kind of well defined also. So that made it extremely difficult.

So we had to kind of figure out what is the point in time that we have to take a call and kind of move ahead. Uh, understanding of legacy apps. I'm sure, uh, most folks here appreciate the problem statement with something like this. You know, things were built a long time back. The teams have transitioned off. The documentation may not be, you know, it's not very good. So you're almost relying on test cases, etc., which is not really doing the job. So it almost came to a point that the team was basically kind of digging into the code to understand what's exactly happening, right? So it kind of adds more complexity to this entire piece.

Uh, it separation. Uh, you know, I've spoken about it at length, but for all practical purposes, you know, in any other year, ah, you know, this project would have been extremely high priority and it was right. But for all practical purposes, separation was the biggest priority that had to get done. So we had to make sure that whatever we did like, we have to thread that needle in a way that we don't impact, you know, the larger physical separation itself, right. And system dependencies. Right. So you're talking about kind of getting rid of like the workflow Platform. But that's not the only thing. There's an entire ecosystem of technology underlying it, all of which was also on the way out for practical purposes.

But from a timing perspective, unfortunately, we had to build on top of it. The challenge became that we're building stuff, it's creaking and some of that performance essentially is impacting us. So that was impacting how we change over and kind of deploy it, right. So there was a substantial amount of pain which came in for particular applications in terms of being able to manage that. Right. So this was like again, some some you know, some of these challenges would be true for any application that you face. Some of it is very specific to the context of the year we were in. Now, obviously, after the very dramatic problem statement and how the environment was challenging, we obviously have come out on the other side pretty well. The reason we are standing here in the first place.

So what are we fundamentally achieve? Uh, so we achieved the fundamental decommission of the legacy, uh, platform itself, which was the primary objective. We did that, uh, we decommissioned it, migrated all the data. It was a painless and seamless. We kind of achieved that for all practical purposes. Uh, transitioned over 500 users. Right? So, uh, you know, this was an IT driven initiative at the end of the day, but the impact was on the business, right? And a lot of these applications are used for fairly complex regular financial transactions.

Money goes out at the end of the day, right. Which means that, you know, there could be no disruption to business. And also a bunch of these applications with Sox applications. Right? So we had to make sure, given the industry that we are in, that we make sure for financial controls, IT controls, work with legal risk, manage the entire transition. So it is like making sure that purely from a business perspective, the transition happens. And it's a substantial number of users. As you can see it managed for the physical separation. Again do no harm, achieve objectives.

We managed to separate the Pega infrastructure itself. And then of course everything else that was around it. You know, we made sure that we weren't impacted or at least we kind of worked around all of that, um, delivered on time and below cost. Right? So this as I said, this entire engagement was timeboxed, right? We had to get it done by a certain time because there was, uh, an end period. Right? We had to get it done by because, you know, there was a licensing renewal cycle. We wanted to kind of get it done.

Otherwise the business case gets diluted. So there was no option but to get it done within the year. There's no liberty of saying, oh, we are running behind. Let's prioritize this for later. It had to be done. And it was done on time, right? Which was pretty amazing. And we achieved this 13% below cost, right? And part of the reason is I was talking about the 17 applications to 12 applications.

We saw that, you know, we don't have to kind of do the cost to achieve for some of these things. So, you know, much cheaper than what we anticipated in the first place. The finance team was extremely thankful. They sent us wine and chocolates, which never happened. But I'm just joking. But but yeah, I mean it was a great achievement at the end of the day. Right? To that extent in terms of like purely from a time and cost perspective. And the biggest thing reduce it cost, right.

I mean, we are I can't quote numbers here, but fundamentally substantially less money that we're now putting it back into the business to put it somewhere else from a growth perspective. Um, so how do we, you know, achieve this? Um, sorry, actually, jump the gun here. So a couple of things. I mean, if you really think about it in, in hindsight, none of it was rocket science, right? I think there are three fundamental aspects of it. I think there's a need for a strong foundation. There's need for design discipline, and there's a need to shift left. From an implementation perspective, all things which seem pretty obvious, but we have to make sure that we wake up every day and do it right.

And that's when it kind of comes together. So we'll just touch upon a few of the things here. So one was setting up the foundation itself. Right. I think, uh, Rex's spoken about that to an extent. Uh, focus on planning. Right. Again, I've kind of harped on that a bit. Uh, but it was extremely important that we, you know, when you're doing an implementation where, you know, you have to achieve a lot and you know, and build a lot in a particular time, there really is no breathing space.

There really is no, uh, you know, you can only make so many mistakes for practical purposes, right? So you have to focus on planning and get that right. Right. So and that pays dividends later. And I think the time that we invested upfront really kind of paid dividends to that extent. Establish delivery guidelines and principles. So I think, you know what, as an organization, what we have done right. I think we have relatively but in terms of Pega, it's a six year journey. One can argue it's still relatively young, but I think what the what the team and the center of excellence within the organization has done is define some very clear standards on coding, right, or database naming or UX standards, things that we kind of define very early on.

And we've codified that into implementations at large. Right. So it doesn't matter whether we are doing this program or whatever we're doing right now or the next year, we fundamentally have kind of institutionalized this. And and then you basically know what you're going to go and kind of implement on that specifically. Uh, we are extremely big on reusability or actually use the example of the institutional market claims, where I think that's the best example of how you can, you know, a standalone for would have been a huge project, but the fact that a couple of people did that over a few months, reusing the entire workflow, changing the admin system, changing the data model somewhat, but, you know, getting it through, the reason we've achieved that is because there are components built at, uh, you know, purely at the organizational level, like just to take an example, like an address validation, right? We're going to do address validation in every application. We're not going to rebuild it every time. Right. So it's built that by default.

We don't even think about it now. It's just scaled up. Right. There are things that are built at the division level. Right. So like institutional markets or life or the, you know, the entities business or retirement services, we don't repeat that because some, some things are fundamentally built and we can just scale it up very quickly. So it's important to kind of think of reusability like that. Um solution design and skills. Right.

So from an application perspective you have design but at a high level architecture perspective. Right. The pattern etc. that is something which A is well defined. Right. So you know, and that's entirely aligned with our larger enterprise architecture team. There are patterns that we don't have to kind of go back and discuss every time we are building something as part of this implementation. There are certain things that the earlier workflow Platform was doing with security was not okay with. So we had to define new patterns for it.

But now that we've defined the pattern, we're actually now piggybacking this year on some of that stuff. And we're kind of going back to the drawing board talking about it. And if you have to talk about a new pattern, a new mechanism which helps us for future builds, we'll go that codify it, institutionalization and kind of go from there. So the high level architecture, you know, irrespective of what application you're building, you've kind of put that in and skills, right. It's extremely important. You know, at the end of the day, Pega is a great technology, right. But it's very important that we have the right people to do it. Right. So there are some very good people who are veterans in Pega implementations who, you know, can see not just Pega per se, but think of the entire ecosystem in which Pega has to co-exist.

So you have to be very conversant in understanding data integrations, architecture at large. So I think it's something which has been honed over time. And at the end of the day, a huge part of the reason that, you know, we have is some of the core, you know, strengths of the team itself. We work with extremely strong vendor partners who help us in implementing that. And as a combination of both things, fundamentally, the people the people have to be right, and the technology is one part of it. But unless you get that part of it right, it doesn't really work out. Yeah. So the foundational aspect of it, the next part is creating the structure. So on that, you know, how do we what is the structure that we want to create for for an execution to happen.

Right. Standardization. Right. I've spoken about like we have strong coding standards, etc. but even if you kind of take it down to an implementation level, like I think we've we've basically beat functional or technical, right? Be it a beta design document. Write. I think the, you know, we've kind of kind of standardized the template to the extent like this. All these have to be coming, right?

I mean, we don't get into implementation unless all these things, this checklist of items are coming kind of come in being defined with a particular naming convention naming structure. Our backlog structure is fairly defined too. Like if you go into any workflow application, we even the start of this program, we kind of defined what needs to come into the backlog. What change probably is the specific workflow aspect of it, but we want to make sure that we don't miss the core fundamentals of setting up the users, the reporting, the nonfunctional, uh, you know, exception management. Right. Those things are across the board, have to be codified into the implementation. Again, you kind of keep on repeating that process. Um, communication of goals, right. Uh, in this case, you know, we, you know, uh, very early on, we communicate goals to what we kind of both from a business perspective, but from an IT perspective, that's extremely important.

But, you know, you know, especially for an engagement like this, you have to, you know, if you're not extremely high priority, you have to continue to make sure that you're communicating those ideas and everyone understands what's being done, where they need to come in, how they need to help establish governance. Right. So that kind of governance, we want to make sure that from a reporting perspective, you know, kind of rolling up to leadership, etc., all those things are set up again, agnostic of which application you're building, which program you're doing. Those things are standardized rigor and execution. So this goes to the shift left mentality in implementation itself. Right. You know, very clear understanding of ownership. Right. Like everyone needs to understand that they are they own not just activities.

They need to understand their own outcomes. Right. So for all practical purposes, very clear on who owns what, exactly what they need to kind of deliver on. And there should be no ambiguity whatsoever. And then kind of track to that stringent gatekeeping. The idea is to catch things early. We can't let things slip, especially again, this is a good case of if you let things slip into the latter part of your implementation, it automatically means that you're now playing catch up, right? So automatically the next application is getting hit, right? So catch them early, right?

This is gatekeeping from a functional perspective. From a technical perspective, every piece of that code that is going in, you know, spend the time to catch it in Sprint, you know, and make sure that only, you know, the the branch gets merged once that review is fundamentally happened. Um, and elevate risk and track. Right. Uh, again so much happening. Uh, you need to have a year on the ground, be very close to what's happening, because sometimes your project reporting won't even reflect the fact that there's a problem, right? But, you know, I think there are multiple instances where we could see that the wind is blowing probably in the wrong direction. Get ahead of it and and solve it right there itself. If it ever came to a point that we had to elevate that to leadership to be solved because we couldn't do it.

There are a couple of occasions that we've had to do that, and they were extremely helpful. but but stay close to the we had to because otherwise it becomes too late to react. You don't have the opportunity because the next application gets impacted. And the final thing is, you know, focus on transition. Lots of times from a technology perspective, we get so focused on just the building part of it, getting it right, everything else right. But the you know, at the end of the day, you know, business has to consume it. Right? And they have to as I said, there are 500 plus users. Right.

So, you know, for practical purposes, we have to make sure that they are comfortable with what's coming in, keep them close to what you're delivering and, uh, you know, and make sure that, you know, enough time is spent. Uh, from a unit perspective, training perspective, we went the extra mile because resources were scarce on the business side. Also to make sure that we created how to videos, documentation, etc., just so that once it really came to it, they didn't feel the pain of having the transition, because that kind of negative noise also kind of impacts, you know your work, you know the feedback you're getting, you know, no matter how much what kind of good work you've done, it kind of becomes a bit of a drag, right? So just always keep an eye on it. What we typically do is whenever you're starting an engagement, we we we typically start a change management track. So we start reporting on change management also like what are we doing. What are timelines. What needs to be done. Who's engaged, who's on point.

Right. If it's something which you do early in the game, sometimes there's just no time for it. So broadly, again, as I said, uh, potentially not rocket science, but it's important to get the small things right. And I think, you know, this probably kind of spoke to the fact that, you know, hyper engaged, you know, making sure that we're very close to what's happening, doing the things early on, you know, solving for problems early on and just kind of running with it. Um, I think what's, what's what's what's given us at the end of this, this engagement essentially is a lot of confidence that we can kind of really take things at scale. Right. The team is now running, uh, you know, at a certain momentum, which is pretty amazing. Like we're doing a lot of work this year, and I think that becomes the foundation for us to kind of as a practice, just to keep on growing and building. I think it's a great story, right.

The leadership appreciates it. The reason they are focusing more and more Pega is for the fact, for all the success stories that we've had at this point in time, they believe that we can get it done right. And from our perspective, we gain the confidence that we can get it done right. We're getting the kind of support and everything else. So hopefully, you know, we're hopefully able to kind of give you a bit of a background as to how this was done, you know, happy to take any questions, uh, you know, that you might have at this point in time. Yeah. I think good. So we did, uh, you know, summarize the entire year's worth of work in 30 minutes, 35 minutes here. There's a lot of things that has happened that, you know, it's, uh, that we could not put into a slide or we could not speak in this 30s 30 minutes that we were allotted.

Um, this why? We were proud about a lot of what. What have we have done is, um, this was done while the, you know, in quite, quite, uh, figurative sense, the ground was shifting underneath us. Um, our entire technology assets in a data center was moving to the clouds. That's the infrastructure that is getting done. So we moved our entire infrastructure over onto the clouds. Uh Pega. We have a solution on, uh, cloud itself. So it's an a Pega Cloud.

So as they were migrating, we had to figure out which application is where. Where is it residing right now? Is it on the colo instance or is it on the cloud instance? What do I have to take into account to make sure that the connectivity is all set? And when that gets migrated, my connectivity has to be reset again, this is all happening while we're developing as well. And each of these applications are equally pretty significant from a financial perspective, from a Sox perspective, from a business impact perspective as well, mostly in finance, Treasury and our ISO or our information Security organization. These are the workflows that are being used by them to track a lot of these events. And it's pretty important that while you're doing this separation, this needs to be working as usual as well. So it was not just migrating an existing application over to the other side.

There's a lot more about migrating and enhancing those capabilities. So we actually delivered a solution that was not what was earlier one legacy solution. No, it was a more modern application which actually reduced a lot of their operational, uh, that improved their a lot of their operational needs, added a lot of features that they did not had in the previous instances. And we built this from ground up in one cycle, after another, after another. And I can promise you, all of us took vacations. I think there was there we had a good time. It was a nice, nice, nice delivery that we ended up with. So we are open for any questions if you have. Sure.

Yeah, please. How you talked about those pods. How big were the pods? Like, just just trying to get a sense of team size. We're obviously trying to implement Pega. So just trying to figure out, like what that looked like, right? Sure. That's you? So, uh, typical pod would, you know, had about.

So there were two parts of it, right? There was the core pod, which was doing the Pega development work itself, uh, that had about seven, eight members. There was a supporting team. Right. So which was looking at specifically all the APIs, the data migration. Right, which was kind of supporting as and when the build was happening. They were plugging into each of the respective pods, right. The API build or, you know, when they were getting to, let's say, a Sprint to making sure that the entire data migration mechanism is built so that they can extract all of that. So primary Pega work, let's say about seven, eight and then of course the supporting team of API.

And so I think at a certain point in time, we didn't have a size more than 40 people. The project, I think across the three pods and the supporting team, the delivery team including testing UAT users and all, it was 40. The reason why the 40 number is interesting is you would expect a program of this size to have a large 200 member team. You don't need that kind of size if you if you've done the homework right. Foundations if you've set up the foundations upfront. We spent five years doing that. That five years of foundation helped us not to have a large team to deliver things. We don't need that larger team for a product like Pega. So I mean, again, spoken about reusability, right?

I mean, out of the 12 applications, uh, a whole bunch of them were investment operations, right? So fundamentally, in terms of like what we are setting up for them, etc., a lot of them were, you know, once we built the initial set, right, it became just easier to kind of build other ones because you kind of create the format layer. Maybe you even have the process kind of define at this point in time, kind of build on that. Any questions? Any feedback and suggestions? Absolutely. We will do that again. Thanks a lot for coming on. As I said, this is obviously the last session of the last day, right.

So everyone's kind of winding down. This is winding down. So thank you very much for your for you being all here. We really appreciate your presence. And I think this was a story I hope it actually enthused you. Um, you can hit me. Hit us up on LinkedIn. We are available. We can always have a conversation at any point in time.

This is a story that we would like the community to understand, that there is a lot that you can do if you plan it properly. So thank you very much. Thank you very much.