[00:00:01] Speaker A: David Kaiser, thanks for being here.
[00:00:02] Speaker B: Yeah, thank you for having me. I always enjoy our conversations.
[00:00:06] Speaker A: We're going to explore systems rollouts today.
I was hoping for the general audience we could try to just explore, well, what are we talking about with the systems rollout? I'll name drop a little bit. People have heard of Oracle or Salesforce or Sage, but when you talk about a system rollout, what are we, what are we talking about within a company?
[00:00:30] Speaker B: Well, it's essentially when a particular company is either consolidating various parts of their business onto one single system.
It's essentially when they're upgrading into a new system.
A lot of companies that we've seen over the years, you know, they'll, they'll grow through acquisition and when those acquired pieces come into play, they're coming in with different systems and different processes. And so they'll take a moment, a big moment to actually get everybody on the same system and then therefore the same process. And that helps downstream with high level reporting. If they have any system wide changes they want to push down, they can do that across the company because everyone's on the same platform using the same process.
[00:01:11] Speaker A: Right. So we talk in business about people and processes and sounds like this, there's a technology piece of this which is the foundation. But what we're going to be talking about today is really the people and the processes around that help us understand why those pieces are critical to success of the technology launch.
[00:01:34] Speaker B: So everyone's really familiar with project management. We use it just putting together a grocery list and feeding your family throughout the whole week. You know, we've all been pulled into projects on other duties as assigned throughout our, our roles. And so there's a lot of clarity in that. And, and that is essentially the what and the how. So what are we going to be doing? How are we going to get, get it done?
That bit that's more than the technical piece that makes projects really successful is the change management side of things. And that really just if you boil that down in the most simplest terms, that is the who and the why. So who will be doing the work, who will be transitioning that work and why do they actually care about doing that? Why is this important to the company as a whole?
[00:02:19] Speaker A: So let's dig into this using the example. You've worked on multiple projects like this, but you just finished recently a large Fortune 500 healthcare industry company going through a large platform migration.
Tell us about that rollout. And so what was it? And what were the challenges?
[00:02:41] Speaker B: Yes, so this was actually My so I've been working on system implementations all the way back to 2008 and then with Axiom, this was actually my third system implementation project. And just prior to this was on a very similar company in size and industry.
And so we've had a few, we've had a really good run over the last couple of years with some really, really robust projects working on some major system implementations. On this particular client that we just wrapped up a couple months ago, this was that example of where you had a company that grown through acquisition. And so they had different large pieces of the company on different systems and therefore different processes. And so it gets really hard to report across. It gets really hard to make big system wide changes. And so they were standardizing all of their core processes onto a standard suite of several different systems.
[00:03:35] Speaker A: So in that hypothetical, the company has identified the need for a change. They've already started down the path of identifying their solution. So at what point did you enter into the project and how did you approach onboarding yourself and developing a scope of work?
[00:03:53] Speaker B: Yeah, so with these larger companies, these projects, they take multiple years. So where we came into this was actually just before the rollout of the systems themselves. So they had been in preparation, they had been working with subject matter experts and the teams in operations to actually get the alignment build out the systems. Some systems were completely new, some parts of the business were standardizing to an existing system. And so there had been several years of work already in play for that. And where we came in as learning consultants was in the rollout of that system system.
So we came in several months prior. We had to learn the systems, kind of understand, you know, what was, what was going into them. We had to get ready to actually be able to train them. And, and then with large companies like this, they'll do this in a phased rollout where they'll take one piece of the business at a time and roll out those systems. So you'll still have one foot in the old ways and one foot in the new ways. And then methodically we're working across all parts of the business to get everybody onto the same system setup.
[00:05:01] Speaker A: Right. So what did that look like? If you give me an example maybe of one of the.
Was it tailored by function or group or an example of how you approached supporting a learner or user population there.
[00:05:18] Speaker B: Well, so it's normally by a function because the systems themselves handle particular function. So you'll have a billing system, you'll have an accounting system, you'll. This particular client was in healthcare and so you'll have all the healthcare records on a particular system. And so depending on which end user is using it, you'll have, I guess, a different profile. So someone working in the call center will need access to a certain set of systems so that they can answer those phone calls. Someone working in billing is probably going to need to have deeper access into the accounting systems. And also, let's say the, the claim system so that they can understand and troubleshoot issues that they deal with their day to day.
So there's essentially a matrix that's put together based on the different roles and what they need, what information they need to know so that they understand what access they need to which systems.
Let me say that the other way around, they'll need to know which systems they need access and what level of access they need in their security profile. So there's a whole matrix that's put together and that then drives the training plan for them.
[00:06:31] Speaker A: Right. That would also drive the measure of success too, because you're identifying, okay, well, what do they need to be able to do? How do they have the understanding to be able to do what they need to do? But also measuring, okay, after they've gotten hands on for a bit, are they actually able to do it? Is it. So how do you establish objectives for, for the behaviors that you want to see?
[00:06:58] Speaker B: Well, this particular client, they're very good.
They're very good on a lot of different levels on this. For this particular question, after every single training program, they would assess that and then they would actually go back later on and assess them again.
There also had a really robust change program so that if we encountered anything during the training and the rollout, we would get that feedback. And especially as trainers, we're the ones speaking to everybody, all the way down to the end user. And so we would get that feedback often and we could feed that into a change document and so that we could see the change. If the change needed to happen at the system level, it would get communicated there if the change needed to happen.
And what we were teaching, it could happen quickly. And so they were very quick to respond and they had really good processes in place to do so.
[00:07:47] Speaker A: Yeah. So that rapid response and that agility, we talk about that as being a benefit to projects overall. But in a complex one, where you need to correct before a wrong direction gets cast in stone, that's particularly important.
What other learnings would you share? From this example, this particular launch, what did they do? Well, that you could take or others can take and apply to Their own projects.
[00:08:16] Speaker B: I think the agility piece that you mentioned, this showed up in several different places I mentioned earlier about the system changes.
They took the opportunity to centralize all of their documentation and to a central receptacle. So instead of having it in file cabinets and shared folders and developed by the teams themselves, they had a central team that would develop, develop all of your QRGs and your walkthroughs.
And so if something, if something changed in the system, that team was actually engaged as part of the project plan for that change. And so what you had was a standard receptacle for all these materials and real time updates?
Well, I wouldn't say real time because you know these things, these, there is an approval process, but they're very quick.
[00:09:07] Speaker A: They kind of a rapid response then if not real time.
[00:09:10] Speaker B: Yes, they are. I mean they were much faster than anything I've seen. And then, you know, when you go to that standard receptacle, you know that you're always pulling the most recent version of that document, which is version control is one of the biggest pitfalls that you run into with any kind of documentation.
[00:09:29] Speaker A: So thinking about, again, this is a large systems implementation. These tend to be owned by people in it, people in operations. HR tends not to own these.
But what we're talking about here is the importance of getting alignment then between the people side of the business and the ops technical side of the business.
So if you're listening to this and if you're in the seat as the skills person, the human skills person, what could someone in that role do to make sure that they're part of the process and helping to support the successful launch?
[00:10:11] Speaker B: So this is, so now we're now getting into the change piece, the who and the why. And the first place you would start with this is aligning business objectives.
You could go all the way back to just the mission and the vision of the company and then work from there.
For something like an insurance company, you know, they're very focused on what their client, what their experience is, do they feel like they're being served? It's very passionate business.
And so by implementing new systems, you get better information, better, better engagements with that client. And so, so people feel better about working that. And so that industry already attracts people that really care and, and, and it helps them serve that. So if you connect this whole rollout to the why, like why we want to serve our clients better and we really, truly care about that, what that does is it gives people license to add more value, add more ideas.
It Makes them more resilient to change. A lot of times when you're coming in with the system implementation, somebody may have been working in the system for years and they're a subject matter expert in that system. And so it can be disempowering sometimes to have to learn a new system because kind of resets the playing field. And so that change can be hard. And so by aligning it to something bigger than ourselves, but something that we all value within that company, people can really step up and they're motivated by something bigger than themselves.
[00:11:45] Speaker A: Right. And that's a very different way to approach change management approach, sort of understanding folks motivation than, you know, I mean, the default, and I'll be a little crass here, the default is to say, okay, it's a new system, you get on or get out.
Which I would be lying if I said that doesn't happen sometimes. You know what? But that's relying on a whole different type of. And I'll put motivation in air quotes, but it's a different way to try to leverage behavior. What you're talking about is much more.
It's an intrinsic motivation. Right?
[00:12:20] Speaker B: That's right, yeah. Yeah, that's the exact term I always use, extrinsic motivation.
Things that get people through the door. It's what you pay them. It's the benefits that come along.
Intrinsic motivation is obviously prestige is a really big intrinsic motivator, you know, and what am I. Is what I'm doing important?
You know, I mentioned earlier, we have. You have a really passionate workforce that works in insurance. And so helping others is an intrinsic motivator, but also creativity and then opportunity, autonomy, all these things where you can actually do some meaningful work is really, really fantastic way to motivate. And so if you have somebody that is looking for more opportunity that, that wants to try something new, they come up with a lot of good ideas. They're really great people to add to projects like this. Because at any, at some given time, you will have something go wrong with the project. And these are the type of people that don't get flustered by that. They step up and say, okay, how are we going to fix this?
[00:13:20] Speaker A: Right. And that's. That's when we were talking in prep for this podcast, we were talking, we talked a little, you know, sort of enablement versus versus pushing. Right. And that's kind of where we are here. But so talk me through the difference it can make when you have people who are sort of aligned with the mission, working within the project to help push it forward.
What does that look like in practice and how does that change the result and the outcome?
[00:13:55] Speaker B: Well, when thinking from it, from a leadership perspective, one thing that happens with every single client that I've had my experience with is at some point you have so much on the line, both personally and professionally, but also for the company, for the client. When you're doing this transition, it's a very risky prospect to do this.
And so at some point, your motivation can switch to fear.
Fear of failure, fear of, you know, personal level, you know, feel fear of being the one that messed it up and then potentially losing your employment. It could be fear of, you know, the client, you know, changing to another company because they're, they're so unhappy with, you know, with their service that's being provided.
And so with fear comes a heavier sense of control. You want to start controlling every point of that and that breaks down that autonomy, that creativity.
And so I guess from a leadership perspective, being cognizant of what's actually driving you, do you have the courage to actually push something through and take a little bit of risk, or are you being driven by fear?
If you remove that fear element out of it, then that opens up your people to actually create solutions to try and pilot different ideas.
And it creates a psychologically safe environment for everyone to kind of work together and find a solution in the most efficient manner.
[00:15:22] Speaker A: So let's take the conversation back a little bit in terms of, again, using this project as a case example. We've talked about understanding how we motivate folks to carry forward, but I wanted to take a step back and look at sort of the structure of the project. As you mentioned, you brought in, the project's already underway.
You have multiple phases of work you're looking at. How did you structure the human factors work, the change management, the learning around what was it? Solution, engineering, training, facilitation, go live. There's different needs around each of those buckets.
How do you approach and move forward in each of those areas?
[00:16:08] Speaker B: I think the biggest piece of this for us in this instance was, I guess because we were working at the front line, we were helping with adoption. And so you're getting that frontline resistance to a system. And so it's really important for us to understand what was happening prior so that we could show the value in the new system that was coming online.
We had to, to break it down and really understand where were the benefits so that when you're going through this, you could give the context of the past to then, you know, Paint how, how, how this was actually helping them reduce time or be more efficient or answer questions better when they're going through things, then in live training, you have to understand the system and the process enough so that when people do bring up ideas and come back, you can either find a solution for them in the moment. We could park that and find a solution utilizing the SMEs that were assigned to that particular process, which this company was really good about, having embedded SMEs and all the different functional teams that we were able to reach out to and discuss with them. You know, okay, how can we, how can we answer this particular question?
And then if it took a system change, if there was something that they just could not do, then there was an escalation structure in place for, for that as well that could either go to change the materials or to go change the actual system process itself.
[00:17:38] Speaker A: Right.
[00:17:38] Speaker B: So we had different levels of issues that would, that would come about, and a lot of times they would come through us because we were right there. We were teaching the end user. So a lot of the solutions, design and engineering had been done already for the first pass had been completed and they had built it out. But there are always things that get missed once you start going live and you turn the system on and you realize, oh, we need to do this a little bit different. We had very clear processes on how to get those resolved as quickly as possible.
[00:18:10] Speaker A: Yeah. And there's almost a way to look at it to say. You mentioned training frontline staff and anyone's worked, having worked on frontline staff in my earlier career and worked with, since, it is sometimes a little bit of a thankless job.
But also there's sort of an old truism that if you want to know what's really going on, you know, talk to the folks on the front line because they know where the brand is, where the point where the disconnects are.
They see it and they live it. So when we're talking about training that frontline team on a new system, you know, a, it's natural that the training, the person doing training delivery is going to be their first point of contact, because you're right there, you're with them.
But also you have to build, I would say this is my word, credibility with those, with, with those folks, because if they raise an issue, whether the training materials are off, whether the system implementation, there's a dialog box or something else that needs to be fixed, you know, it needs to be addressed normally, I would assume pretty quickly, because otherwise they're going to be looking at you going, well, we told you about that last month. What's going on?
[00:19:19] Speaker B: That's a really good point. And it even goes deeper than that because that's just honoring their feedback and giving it weight. And you have a duty to actually give that feedback to make their job as streamlined as possible.
But also in these trainings, we stress the importance of what their job is. Every single job in the entire company is part of a larger machine. But it's all absolutely essential. So it's an opportunity to honor what they do and kind of celebrate what they know and the contribution that they're giving.
This is a skill. This goes all the way back to the first implementation I ever worked on. It was for a cash accounting team and people would come in, they would do bank account uploads and it was a very mundane job. But we really stressed the importance of that job because by doing that on time, cash sweeps went in, money moved around and then we were able to, you know, I guess, you know, it was for a mining company, so we were able to buy a new tractor over at this mine site. And so what they did seemed mundane, but we really stressed the importance of that. And that goes across any role and any, any company. So it's important to stress the value that they're adding so that they know that they're doing something important. And then the second piece is the system piece where making sure that they understand the value that that system is bringing to them. And then if there's something that they can improve through their ideas, honoring that by making sure that it gets escalated properly.
[00:21:00] Speaker A: In our conversation the other day we started chatting about night. I know. I wanted to ask you to take us through sort of the roadmap or best practices that can support user adoption. So there's a, you know, these each I think require a little bit of explanation so we understand what this looks like. But can you take us through kind of in your experience what the, you know, if there's a checklist for best practices, what needs to happen to set yourself up to be successful?
[00:21:33] Speaker B: Successful, yes.
So in, in change management, the two models I worked with the most are Cotter's 8 step model and the McKinsey 7 7s model. I like Cotter's 8 step model because it explains a lot of the theory of why we do, like why these is important. Like we, we talk vision and mission ad nauseam in so many different circles. They really, truly, truly are important.
And so Kotters does a really good job of explaining that the McKinsey 7S model, if you're building out a plan, that's a really great place to start. If you're looking into this, because that is for me very obvious kind of step by step process to work through this.
I guess this response that I put together is an amalgamation of those two.
It's the highlights and then my own personal experience in that. But if you're looking for best practices is to. From a change management perspective, I always say it always starts from the top. So you need to have the sponsorship of the leadership and, and the governance in place. So are there steering committees that are, you know, that you can escalate things to. Are the escalation paths really clear? And this last case we had very, very clear governance on escalation which essentially it removed barriers to get things done because we, we had a really clear understanding of who we needed to talk to, to help us out. So, so that sponsorship and governance, it's really key. That's the very first thing you would set up from there the vision and strategy. So what are we actually trying to do? How is this impacting our clients? How is this impacting the end users? Why is this adding value? Why is this important?
And being really clear from that, this creates a common identity for everybody that's involved and the project and in the company because we're all working towards the same thing and we all value the same thing from there, you know, mapping out the stakeholders, the impacts. This is in that solutions design. So you know, as we change things, as we move people over who's being impacted so that you can get ahead of the communications, so that they know, you know, you know, on these larger ones they know years ahead that something's coming. And a lot of times people know nine months ahead of time that they're cutover date is going to be September 4th. And, and they can either dread that date or be excited about that date. But what they can really do is they can prepare both mentally and with their skills to be ready for that date.
Standing up a champions network. I've heard them called ambassador networks.
Really common term is SMEs but essentially having not only people who are best in the process, but they're influencers, they care, they're really passionate about helping people. These are the people that will go over and above because they truly care. And I ran into some world class champions at this last contract and people I admire so much now that if I ever go back to that city I would call them up and ask them out to Dinner because met some really, really, really wonderful people that were in these positions. But they are the, they're the people that will be, you know, down on the front lines after the training team's gone, after, you know, the stabilization for the project is gone. They're the ones that are going to pick up, you know, that, pick up that process and those changes and the system feedback and they're going to be the ones running with it. And they're also going to help out immensely with training.
[00:25:06] Speaker A: And so linking this also by the way into, into HR and people management is, can be an important sort of cross pollination because the same people who might be the champion in the project might also be someone that could be looked at or should be looked at perhaps as a, you know, potential, high potential program participant or someone who's, you know, this is a stretch assignment.
[00:25:30] Speaker B: Yes, yes. Because often they're still doing their normal day to day and this and they do it because they really care. This actually goes back to our comments about intrinsic and extrinsic motivation. These people are highly motivated by intrinsic motivation, by the prestige, by the creativity, by the autonomy.
They want to make a difference and they love what they do.
[00:25:53] Speaker A: Yeah. And by giving them an opportunity, really recognizing their passion and their skill, you can set up their, it helps their personal growth, helps their professional growth. But also it would seem like an outcome of this that's maybe not within the written scope of the project is we're supporting the growth of people and their skills which makes for a healthier, stronger organization.
[00:26:21] Speaker B: It's an important benefit because also as those people rise, they create a vacuum to pull up others behind them. And so you end up getting this excellent talent pipeline by giving these opportunities and to make a difference.
[00:26:35] Speaker A: Right. So I'll stop my aside here, but you're taking us through best practices, so yeah, we have the champions. What's next?
[00:26:44] Speaker B: All right, what's next? So this is kind of more on the project management side of things, but setting up objectives and KPIs, this is really important. And I've worked across multiple industries, at mine sites, measuring hours on machinery, hospitals measure everything you could possibly imagine.
But setting up KPIs and metrics are really important because you have to give milestones. People measure time in their head and they measure their progress through these KPIs. So it's important from a leadership perspective to understand project success, but it's also very important at all levels essentially to understand the value that they're adding. If you have really strong KPIs that are linked to really valuable, you know, like really true value adding tasks. And you can see that there's improvement there.
People see that the sacrifice they've made to do this implementation was worth it.
From again, from a project perspective these are just a few but they could they kind of cross over between but designing role based training.
So this, on this last project, this was really well done. Just having a really solid matrix to, to understand which systems are needed and then most importantly which access is needed. Access can be one of the hardest things to do. It seems very simple, but it could be that you know, you get somebody, you know, you get somebody into the accounting system but they don't have the visibility to see what they need to see. That could take weeks to get sorted and it creates a lot of unnecessary frustrations. And so understanding what those roles are, making sure the access is set and then giving them targeted training, it goes a long way and it doesn't create unnecessary like having issues in those areas is just completely unnecessary noise. And when it's, it's already a noisy time. So, so it's very important to put the pre planning in place.
[00:28:48] Speaker A: So, and you mentioned, you know, we're setting, we're setting objectives and KPIs. Obviously you sort of alluded to the one objective that I think most people would point to first is okay, I know what my cutover date is. I know, I know when the deadline is, is.
But you know, there's, there's a, there's a lot. So much of the work comes post cutover. Right. Support, reinforcement, sustainment, all of that.
[00:29:11] Speaker B: Right. And when I was saying KPIs I was thinking operational KPIs. Like there's definitely project milestones so you can see the project moving along.
Those are so high level and they're so critical they rarely get missed. And if they do, it's very, very big deal.
These KPIs like let's say rework or error management. If you could see, you can see very clearly what was being measured before. And if you see that error rate go down, it just proves out the value of the system and the value of the effort put in to learn that system and improve the process as a whole.
[00:29:46] Speaker A: So you mentioned earlier that it's pretty common that a platform project gets underway and then sort of learning comes in somewhat later.
And I wanted to get your thoughts both and this is kind of a two pronged question because on one hand I love to get your thoughts on when should the human factor side change management learning come in to a project is there too early. So when should learning come in? But also what advice do you have to someone who's already somewhat down the road and has not really started thinking about the people and the change and.
[00:30:24] Speaker B: The training, the human element that you just mentioned that comes before the project even kicks off, it just manifests differently. And so in those initial phases you've got, they set the strategy, they create the structure, what needs to be changed, what is it going to look like after. And then they start working on the systems and the processes that support those systems.
But during that time the people, the communication piece, that strategy has already come into play to I guess lead. So there's no surprises. So people know that this change is coming.
But where Axiom jumped in as learning consultants to help, you know, make the, I guess the knowledge transfer transfer effective it really you have to wait until the solutions design is done. The systems are created because there's so much change that happens all the way up. Even to cut over that you end up, if you start too early, you end up with materials that are out of date and no longer useful.
And even when you get to like let's say you made the materials the day before cutover, there's always learnings after cutover where the system still changes. And so there's always another cycle of training materials that are tweaked a month or two or three after the cutover.
So to your question, where when is the right time to come in?
From a learning and development perspective, it's after that. Strategy, structure and systems, they've all been put in place, the solution is designed and the if they're creating a new software, that software is ready to be tested. It's when you get into the UAT testing, that's when you can start understanding the processes are stable enough to where you can actually start developing training materials.
But from a change perspective, as soon as that project is kicking off, there should be communications about what it is garning excitement, saying hey, we're, we're taking this company, got all these old systems, we are moving into the future because, because we're aggressive, we care and, and we want to be the best and, and building that excitement so that by the time those individual messages come saying hey, your cutover is in September, people already know what it is, they're not afraid of it and they have the resources in place to actually start learning about it and preparing for it.
[00:32:40] Speaker A: So what can happen if one of the pieces we were just talking about is missing or it isn't handled properly, what can happen in the real world?
[00:32:51] Speaker B: Well, I opened up with values and having just common strategy that gives a common identity. So we're all working for one thing. And so if you don't have a clear picture of what that value is, you know, if that shared identity isn't strong, then adoption can feel forced. And so people feel pressured into taking on something. And so. And you get resistance that just naturally occurs there. And that can be very, very difficult because it just adds human inefficiency into a project that we've spent so much time and, and money on making successful. And so it's really important to reinforce that vision, the mission and those values so that people approach this as of them being part of something big and being excited about it. So adoption is not forced. Adoption is willingly accepted and then creatively dealt with when issues do come up. So that's a really, really important point.
Making sure that everybody's ready is also, it's kind of a no brainer, but just having really, really good processes to understand where the skill gaps are, making sure that the. We talked a little bit about system access, access to the correct systems and then the correct security profiles within those systems. It has to be, it's essential that employees can execute once that cutover happens. And it creates a monumental amount of frustration if they can't. Once the cutover does happen, a lot of long hours, a lot of overtime and a lot of frustration that's unnecessary with the right amount of pre work.
[00:34:28] Speaker A: Right. And there has to be a value then too about just bringing in someone. I'll let you pat your own back here a little bit, but bring in someone who's been down the path before because you know, you can advise what the, you know, what the company might not see coming. You can, you can help them circumvent the obstacles rather than having to encounter each one.
[00:34:50] Speaker B: Right. And escalate with the right amount of urgency just to understand, kind of paint a clear picture of how important it is. So because any given point, anybody in this project, everyone feels that their issue is urgent.
And so it's sometimes tough to be heard among the noise. It's.
[00:35:11] Speaker A: So if you're talking to the CIO or the chro who's looking down the future at a major implementation, is there just a sort of final piece of advice you would give?
[00:35:25] Speaker B: Yeah, I mean, we've spent the majority talking about change management or the who and the why. Not so much the what and the how.
And I think just this is commonly overlooked.
Like I mentioned Everybody has a really firm understanding of what project management is, especially at the leadership level, because they've worked on really great projects to get them there.
But I think awareness is the first step that these models are out there. The two that I mentioned here was the McKinsey 7S model and the Cotter 8 step model. I really enjoy those. And you can do that just with a simple Google search. Just kind of understand them, kind of see and understand the concepts.
When you apply those concepts to, to your experiences, as you think back, it becomes real obvious to kind of see where you could interject these ideas, and it makes a big difference. So these system implementations are always going to be stressful, but when you shift that lens and you use these models to go from controlling outcomes to empowering people, you're going to deliver on the project.
But there's also all these lasting benefits that happen downstream where you're really unlocking the full potential of your workforce.
[00:36:35] Speaker A: Great. And I'll put links to examples of those models on the episode page for this
[email protected] podcast. But David Kaiser, I appreciate your perspective and your expertise, and thanks for being here.
[00:36:50] Speaker B: Thank you so much. I enjoyed it.
