How This Program Manager Transformed Continuous Improvement Through Relentless Retrospectives

OK. Just to take down the question again in a minute. Continuous improvement. Yeah, uh, I will definitely still use this, uh, this current program I have led since the last 3 or 4 years because this, compared to my previous program, it was definitely at the, the next level of complexity. And because of the complexity, um, what I, the way I lead this program is that, um, we start early with the program with discovery phase where we understand the design of the solution and then we, we break down the work and then track the delivery. With the delivery coming, we test, we prepare the testing and the, and, and validate each phase, each part of that to make sure little by little, we group the whole pieces together, every piece together to make the solution complete and validated. All along this process, there are a lot of moments of retrospective and improvement that's We, uh, typically, um, uh, along these three years, I, if I just give a rough number, uh, for, for, for individual single, uh, we, I call that migration testing, we have at least 30+ of them. So, every time when uh dev team from both sides and even from partners, they deliver something, we group them logically together, conduct a validation, and then we continue. At least there are 30, 30, more than 30 of them. And each one of them will take, uh, generally from 1 to 34 weeks. And then we have 3 milestones which we call rehearsals. That's also a huge test in which we put, we take everything we have tested before, put together and simulate the production, uh, situation and do a, a production rollout. All these times, we have the building uh systematical uh retrospective. So every time there is a, there, after each validation, we retrospect and improve. And more than that, uh, uh, because if I look back, sometimes you, you can't just keep firefighting. For example, when I started this program, after the, the first big increment delivered by, by the dive team, I saw that at least I created the 4 risks because of somehow the, the tracking didn't work. That's where I say that, OK, let's stop there. I work, I work closely with the product engineering team to, OK, this process, we agreed together to track all these changes. There's something wrong. It's not dynamic enough, it's not good enough. We need to fundamentally change the way we collaborate and that's where we bring in a, a, a new process and, and improve the world. So I, I think all along the, the program. It's a lot of small improvement with the keeping in mind that this, this kind of big improvement is always needed when we see repetitive, uh, repetitive, uh, uh, uh, failures or miss. Typically, the, the, the, the way I lead the customer side, uh, program management is, is also another fundamental change, uh, at some, at some point of the program.

Um, OK, I see. I definitely, I didn't give you a clear answer. Uh, let me think how I can explain that.

Let me give you something. So, so this program I lead is, is a migration program for a huge hotel chain. So, uh, as a program migration, uh, uh, program manager for this program, I own two things. It's, first is to, first is the solution itself. I need to build a migration solution. It's, it's, at the end of the day, it's, uh, executable, uh, plan that, uh, have Maybe 200+ steps that we have each one who, uh, the owner knows, follow the steps, we know who is doing what at which moment in which order. So that's, that's the plan, final delivery. Another part I own is really the program itself. And along What we do, uh, along this program to, to achieve, so the goal is really to, um, uh, I, I should start with the goal, apologize for that. The, the goal of the program is really to deliver a complete solution. So this 200+ steps is a complete solution which, which nothing will be forget. The data system. Uh, whatever will be migrated, a complete solution and all these solutions must be fully validated. That, that's really the goal of the program. So, so that we can move this, uh, hotel chain from their current ecosystem to our system. That's, that's kind of onboarding or, or modernization program. So, um, that's, um, so, to achieve that goal, that's why the continuous improvement retro site is so important because, um, we do not have a, a solution ready in the beginning. Everything is built to customized. We have a huge development team, which is along the 34 years building features to this software delivered for the customer. And along with that, With all these deliveries, I build the, I, together with these teams, build the plan, the, the solution of migration, each step, we break down each step to say, OK, at some point when development team delivers something, I, we have something uh enabled and then we can test that part. So progressively, with the delivery from engineering team, we test the, the steps we agreed together and everything we test. We found something is missing, we enrich our solution. So, little by little, it make it, it more richer and, and, and, and, and uh more, uh, how to say that, more correct or accurate. That, that's why all along the program, it needs continuous improvement because we start from just a design and end with a very detailed executable solution to migrate the, to do the production migration. Is, is that um uh helps to It's not,

that's,

yeah, I know that is definitely something I should do better for the,