A Big Bang? Going Live with Dynamics 365 or Power Platform with Andrew Bibby

Neil Benson: [00:00:00] I'm Neil Benson from Customery. This is Amazing Apps, where Microsoft business apps builders like you can find lessons and stories from the people building amazing Agile, Dynamics 365 and Power Platform apps. I've got two businesses. Customery, that produces this show, is my Agile training and coaching business.

And Superware is my business apps, ISV and systems integration business. As I'm recording this, my SuperWare team is just a few weeks away from another big go live event for one of our customers. All the features have been built and so we're in the final stages of preparing for the first major release into production.

It's fantastic timing then to have Andrew Bibby joining me on Amazing Apps. Andrew is one fourth of Proximo 3. They're like the fantastic four of the Microsoft Business Apps ecosystem. Andrew is the Customer Success Director at Proximo 3.

He's also a Microsoft MVP and MCT, and he's the chairperson of the Dynamics 365 and Power Platform UK user group. He's also a board member of the IAMCP. It sounds really busy, but he's always so laid back and relaxed. In this episode, he uses his 20 years of hard won experience to advise Microsoft customers on how to set themselves up for successful business applications initiatives.

Andrew is an expert on go lives. In this episode, we share our stories with each other about what's made our customers projects increasingly successful at the pointy end, the go live. We've witnessed the rise of the professional change manager being embraced by customer and partner teams, the payback from sustained investments in early testing and in end user training.

And we even debate the merits of going live on different days of the week. This is episode 150. You'll find a summary of our conversation with resources and a transcript [00:02:00] at amazingapps. show. Let's start with Andrew sharing his definition of a go live. And whether the Big Bang approach to going live is still as common as ever.

Here's Andrew Bibby from Proximo 3. Andrew Bibby from Proximo 3, welcome back to Amazing Apps. It's fantastic to have you back on the show. How have you been, my friend? I'm very good, 

Andrew Bibby: yeah. Thanks for having me back on. Yeah, it's always good to see you. 

Neil Benson: I would love to pick your brains about going live with Dynamics 365 or Power Platform applications, and it's a topic that you've got a lot of expertise and a lot of experience with, with major customers releasing their application into production.

Can we start with just defining what we mean by a go live event? How do you go live? Put your arms around it and define a goal life. 

Andrew Bibby: Yeah, I think this has probably changed a bit over the years. I've been doing Dynamics 365 for about 16 years now. And it used to be that projects were very much like, Big Bang kind of implementation, often literally Big Bang.

And then, you know, project kind of goes live. Everybody shuts down and then everyone goes away. But now and I, I much prefer to see this is that a go live can be very much like a phased affair can be going live with particular functionality and then it's basically planning for the next release and then there's another go live.

And if you take it to the. Extremes that maybe you guys do in your company, you can be going live every two weeks, and delivering functionality in that way. I most often see customers though, do this kind of mix of agile and waterfall where there is some kind of go live event, you know, that the users start using the new system rather than it being a very sort of small, gradual affair.

So yeah, a go live is. Normally an event where you're changing from an old system to a new system. There's maybe a data migration that needs to happen. And and then at some point everybody starts using the new system and stops using the old system.[00:04:00] And then hopefully you deliver more functionality after that.

So that's what I normally see. And they can be big and small. It could be for 20 users, it could be 200 users or a thousand users, you know. But fairly sort of similar approach. It's just a. Question of scale and preparation for those bigger go live events. 

Neil Benson: It mirrors my experience exactly.

So, although I love the idea of going into production really early with a small set of features, that's pretty hard to slice off a few features when you're replacing a legacy application. You've really got to wait until most of your features in that legacy application are available in the new application before you can cut over.

And so it's normally quite late. It is quite a big release, that initial release into production. And then, like you said, doing incremental releases in the weeks and months after that. I'd love to go into production much earlier. You know, the availability of the data, the functionality, just, that's not always practical.

So I'm probably in the same boat as you and some of your customers. Andrew, you mentioned that some of your customers had had a very successful go live events recently, and you were reflecting back on what you thought made those so successful. Can I just start with what is the definition of a successful?

Go live. What are you measuring to determine that? Yes, that was a great release. It went really well. What are you looking at in order to make that assessment? Yeah, 

Andrew Bibby: I think, you know, from the most sort of practical perspective is, is you go live and then you're kind of waiting by the phone almost, you know, you're waiting for people to get in touch with you and tell you what's wrong.

And then that doesn't happen. And then you're kind of, you know, I had this experience a couple of months ago, working with a customer. We did a lot of preparation in. To get ready for the go live. But it's always this bit of an unknown, particularly as when we're, we're working remotely, this was a customer in Canada, different time zones, you know, we're not actually on the ground and it just didn't happen.

And I got in touch with a customer to say, you know, is everything all right? And they were saying, yes, [00:06:00] it's absolutely fine. A couple of little teething things where maybe a user hasn't been set up properly, that sort of thing. And it really made me think actually. What, what did we do here that was different to previously?

I think there's a lot of different components go into that successful go live and we can talk about some of those, but ultimately it's about getting ready is making sure everybody's ready, you know, the, the solutions technically ready. People are ready to receive the new system. They know what they're doing.

There's good communication and then they're much more likely to have, you know, smoother go live and ultimately. It's what everybody wants, you know, as a Microsoft partner, you want a good go live because obviously that's a reflection on the work that you've done, where often, even if it's not your fault, in inverted commas, you know, that's where the reflection would be from the customer's perspective.

Poor go live, they're always going to look at the partner, it's like, what went wrong? So partner looks good, the customer looks good because they've got happy users, the product team look good on both sides, you know, so everybody's happy really. So the more effort you put into that successful go live event.

The happier everyone is and everybody wants a successful, you know, project, right? And that then leads on to happy customers and potentially more business in the future. So, why not put a lot of, a lot of effort if you can into that that transition from the old to the new I think it's very important.

So 

Neil Benson: tell us your, maybe, maybe you've got three key secrets that you've learned over the last couple of successful releases where. You find successful patterns perhaps that are repeatable that we can learn from. Is it, you know, does it all come down to change management? Does it come down to the way the user interface has been configured or the training material?

What have you found are the key kind of pillars of a successful release? 

Andrew Bibby: The technical problems you can have getting ready, you know, fixing issues, fixing bugs and things like that are largely understandable and you know that they're going to happen or, you know, they're not likely to just [00:08:00] immediately catch you out providing you've done.

Enough testing and things like that. But I would say that it's all about preparation. It's that old saying of fail to prepare, prepare to fail, particularly on bigger projects, and I worked on a multi year project. I think actually we talked about that on a previous podcast and they put a huge amount of effort into the go live planning.

There was a project manager dedicated to that, to go live. And it was his job to plan the go live and get all the resources aligned and also planned step by step. This is what's happening. Minute by minute, you know, of what's happening in which order, what happens if there's issues, you know, who to get in contact with, what's remediation or mitigation of those issues.

So it's the more planning you do, the more successful you're going to be. So have a go live plan, even if it's quite a small project, you want to go through that sort of step by step process, but also rehearse that. So, two reasons to rehearse as realistically as you possibly can. One is that you're going to find problems that you would experience, you know, during the real go live and that's generally things like security setup access to systems, things like that.

That's very common. But also you're going to get timings and that's very important as well on some projects. You know, you're going to understand how long it's going to take to do each of these steps, particularly when you've got things like a data migration to do. If you can rehearse a data migration as realistically as possible, you know what your go live window is, you know, so if you've got a go live window of let's say I don't know, a Sunday night or a weekend or an overnight, you've got eight hours to do the go live.

Should that migration takes 10 hours, then you're immediately, you know, you're on the back foot. But if you don't rehearse, you're never going to know that. Or at least you can only kind of guess how long something's going to take. But yeah, rehearsals. And timing, and also that mitigation of issues that may come up planning for that.

So you're not running around wondering what to do [00:10:00] next or trying to call people up at 11 o'clock on a Friday night, you know, to get them involved. It's all about preparation. The more preparation you do, the more rehearsal you do, the smoother things will be. And ultimately, nobody wants a stressful go live.

Nobody wants to be up all night, you know, trying to fix issues and I have been there. I've been awake, you know, on shifts an entire weekend with hotels booked nearby for the project team so that they can go get some rest in between. Nightmare go live, ultimately, what that does, it impacts confidence from everybody that's impacted, buy the new solution and if you impact the confidence in that solution, you're going to get poor user adoption, or you're very likely to. And it's a snowball effect of then people aren't using the new system. You're not going to get that return on investment. And then you're really on an uphill battle to try and get those people back on board.

So it's a nice, smooth go live. Everything else after that is also much easier. I'm just 

Neil Benson: reflecting on some of my recent big go live events. One where there was a massive data migration and we had set aside two or three days and done at least two rehearsals, I think a full data migration rehearsal, got the timings right.

And that really informed our go live. And it was kind of a one way, you know, we're leaving this legacy system behind. More recently, we're preparing to go live and our data migration strategy is quite different. We have migrated all the data quite early because there's still a synchronization going on with the legacy system.

So it's not a one time event and that's just made everything a lot more relaxed. We can get all the records migrated and then just let any changes in that legacy system over the next couple of weeks, you know, synchronize into our Dynamics 365 application and not have to worry about a massive data migration over the weekend.

Andrew Bibby: I think that's a really good point. I mean, I mean, just generally, the more you can do before you go live, before that date of go live, the easier everything is going to be, or even afterwards as well. So I've done migrations where, you know, [00:12:00] you may be migrating a huge amount of data, but a lot of that is historical.

And so you can migrate that beforehand, or you can even say, okay, but it's not important for the day to day running. Maybe we need it for analytics or something, something like that. We can even run that after the go live and just continue to run, run the migration afterwards. But yeah, not just migration, the more you can do to prepare and do those go live steps, really look through the go live plan and say, what can we do before we go live?

Like setting up users and making sure they've got the right security and things like that. It's always security that trips you up. You know, immediately somebody tries to log into the system and they can't access something that they need to. Probably because it's configured wrong. So I've definitely been through that as well.

Neil Benson: I've found that just for that security thing, it does quite often bite us on the backside. What I, a little trick I've found reasonably successful is we set up all the users with all the right security privileges. As we've been informed that they've got the right team memberships and right security rules, we've set them up like that in the training environment.

And then when we invite them in to come in and participate in training, that's when they go, Oh. Neil, I've got the wrong security role. I can't see this record I'm supposed to be loading. And that allows us, before we go live, that they've logged into a lifelike environment, a production like environment, and discovered that we've got the security setting not quite right.

Rather than, Monday morning, go live and get thousands of users screaming 

Andrew Bibby: at us. Yep. And the more users, right, the more impacted users, the bigger your problems will be. I've actually had years ago a project for a big insurance broker and there was, it wasn't a huge user, number of users, but there were very important users, about a hundred people.

And I had the CTO of that billion dollar insurance company tell me on the day of go live, because everybody was shouting at him to make everybody system administrator. And so that's what we did, not very you know, it's not something that you'd want to carry on doing, but yeah, it's always security that [00:14:00] trips you out.

I learned that early on in my career, and that was quite early on, but yeah, then you're really on an uphill battle to get everybody back on side. A couple of other 

Neil Benson: big pillars to a successful go live. I imagine you'll, you'll have seen this through your experience as well. One is. Your approach to testing and the second one is change management.

Can we, can we touch on testing? First of all, what kind of testing approaches or strategies have you seen work well and lead up to a great go live? For example, should we be doing user acceptance testing? Early and often during our build, or is it better to wait and concentrate all that user acceptance testing for a period just before we release into production?

Andrew Bibby: Yeah, I think that's, that's a good question. It's going to depend a lot on the customer and what sort of time and resources they have available. I think there is an overlap between testing and change management almost because what you're trying to do is show the system to users. Early and often, as you said, so there's an element of testing.

It can be almost like UAT, depending on the state of the system. But as soon as something is working enough, you know, and meets the requirements for you to be able to show it to users and say, you know, is this correct? Can you test it? Can you use it how you would normally use it in your day job? And you can do that early on, you know, that doesn't need to wait until this big block of testing, right.

Towards the end of the project that said, you know, on a lot of projects, you do need structured UAT. It needs to be you know, well documented the processes that people are going through to make sure that they're going through every single scenario that needs to be tested and you need to have those you know, the results from the testing, the quality metrics from that to identify issues and be able to prioritize issues in order to fix them or not fix them before go live.

But I'm a, I'm a big advocate of showing people. The right people, the solution as early as you possibly can, and throughout the project as well. Doesn't, you don't have to show everybody, but there's a real benefit to getting [00:16:00] people that are interested in the project on board early doors, and then they can help evangelize.

This change that's happening to the organization, to their peers, to their network to say, actually, this is a good thing that's happening because that's what you need to address for everybody. Nobody likes change. Everybody's resistant to change. Right now I'm using a windows laptop and I'm used to a Macbook and this is uncomfortable for me.

But I had to change laptops. So. You know, it makes everybody uncomfortable. And when you're in an organization, it's people's jobs. They can be worried about actually, is my job going to change? Are they going to still need me? This is really important stuff for people. So getting users on board early, as early as you possibly can, and it's just going to make everybody a bit more interested, a bit more excited for the change that you're bringing in.

What I would say though, and I see this on almost every project, I rail against it every time. When you get towards go live, what are the first two things that get cut? Training and testing, you know cause you always think, oh, we, we left loads of time for training, so we're just going to cut that in half, that'll be fine.

And likewise with testing, you know, that's where the pressure points, the pressure builds throughout the project. At the start, everybody's quite relaxed, you've got lots of time. Budget and all that kind of stuff. As you get towards the end of a project, it starts being, you know, why isn't this going live?

Why have we got so many problems? We, are we going to still hit this date? And then the testing starts to get cut. And what happens is they're the two most important things on a project. You want to make sure that your solution. Is going to work as expected and people know how to use it, you know, otherwise, first of all, if it's not working as expected and, and users see a lot of issues early on, again, they're not gonna want to use that system, and you're impacting the user adoption.

Likewise, if they don't know how to use it properly, they're not gonna want to use it either. It's not unreasonable. [00:18:00] To ensure that people are prepared to use this thing that you're delivering to them. You're not doing this thing to them. It's a partnership. you're trying to help them do their job better.

But what I do see is, yeah, is, is testing be cut. As like a, that's the first thing on the list that's going to go. When it's got a massive impact on user adoption and that return on investment that the organization is looking for. If people are not using the solution or not using it to the extent that they should, It's not going to pay for itself, you know, in which case you're going to have an unhappy customer at the end of the day.

That was a bit of a rant. Sorry about that. 

Neil Benson: I have this idealized view of the world perhaps that we should be doing continuous testing and having Users involved in sprints and testing the features before we declare them done so that we can avoid this late phase of user acceptance testing. And I think perhaps being a little bit naive and hoping that UAT will just go away as a block of activity at the end of a project, I think for all the reasons you mentioned, it's still necessary.

We still need to show and demonstrate the quality metrics are there. Thoroughly tested all the business scenarios, the integrations are working, that the data migration has been all mapped correctly. You can't do all of that at the start of the project, you're going to have to do some of it towards the end.

Yeah, I can't get away from it, but I can shrink the size of it and I can shrink the impact of it and give her, you know, uncovering the issues early gives us a chance to triage them in the middle of the project rather than at the end and decide whether or not to fix them. Get that feedback, make sure the applications are better fit.

Because we've had that feedback all along the way, so it's, it's a closer, you know, mesh towards what the users really wanted not just what we need, try and do it during the project training, I think it's probably still, most of that still happens towards the end of the project. We're still, we've got our testers and they're now super users and they're evangelizing your application, like you said, and they're often our change champions.

And they might be leading the training. I've seen that work really well. [00:20:00] I don't know. Do you have a point of view, just touching on training for a second, training the end users, who's best place to do it? Have you seen outside trainers come in, project team 

Andrew Bibby: members? Yeah, that's a really good one.

Yeah. I think that, it's probably something that not enough thought is put into, you know, I think there's, there's a certain way that the organizations are used to delivering IT projects, you know, like you're saying about UAT, they're used to having a block of UAT towards the end of a project, and then they can dedicate people to do that because you're taking time away from people's day jobs.

And it's more difficult for organizations sometimes to do that throughout the project. And so they kind of think, well, we're just going to do this two weeks or whatever. And it's sort of the same with training in that way. We've got this real, I'm going to say it's an immature view of, you know, you just train somebody for a couple of hours on how to use the system and then that's it.

It's like giving somebody one lesson on how to drive a car. It just doesn't work to train somebody. And it might be a month before you go live, you know, two weeks before you go live and then they don't touch it again. They forget half of what they've been told. And then you say, okay, well, we're going to give you this training manual and it's 50 pages or a hundred pages.

Nobody's reading that. Nobody's watching this back, this recorded training back, you know, for three hours or whatever. So this, this approach we've got of training just being this one off event before we go live, and then that's it. When actually. Really, what you need to do, you do need to get people ready and training is part of that.

But for there to be continual training after go live to help mop up those people, either that couldn't attend the training, or they didn't quite get it, or they didn't, you know, discover the, this feature that they now have to use. So it needs to be a continual training effort is one point, but I would say, you know, you touched on the, who's best to deliver that training.

It most often, in my experience, falls to the partner to deliver the training because they know the solution, which I think is a terrible idea because a lot of the time those [00:22:00] partners, they're not trainers for a start, they can probably write a training manual because they know the system, but it will be dry and, you know, nobody wants to read it and it will be out of date within a couple of months.

What is a really good idea I think you mentioned there is actually having those change champions, those early adopters, the peers of the teams within your organization, to be delivering training as well. Now I'm not sure practically how often people would be up for doing that. But I think it's a really good idea from the perspective of you're hearing from somebody as a person being trained, you're hearing from somebody that's within your organization, that knows your business, that knows what you do, you're going to listen to them more.

So maybe it's a combination of partner and customer. 

Neil Benson: Andrew had a recent project where for a financial services firm, we had a couple of hundred users, made great support from change champions throughout the project, doing early UAT for us. They then worked really closely with the change management team, which is a couple of permanent consultants that worked for our customer.

And they collaborated together to produce the training plan, the training content, and it was the change champions who delivered it. As a Microsoft partner, we had almost nothing to do with the training that was delivered. And the feedback that I heard was it was awesome. It was delivered by peers who knew the system really well.

Who knew the business processes and the culture, who knew what stories to share. And that's, I think it's really vital, you know, examples of customer scenarios that they were able to solve or sales opportunities and how they would handle those in the new system or support cases or whatever your business process is.

And hearing that, how to do that from a team leader or a peer in your organization, I think is way more impactful than a professional trainer, an MCT or whatever they happen to have. It carries far more weight, comes from somebody inside your organization. 

Andrew Bibby: Completely agree. I think that's the dream scenario, really, where you've got people that are willing to deliver that training, and they've got some experience in how to do that because [00:24:00] ultimately a lot of the time Microsoft partners, the people that are expected to deliver.

to deliver training and not trainers either, you know, their functional consultants or their business analysts or whatever, because they happen to know the system. But absolutely, they don't know the business as well as people that are doing that that job day to day. 

Neil Benson: What change management then? That's another important pillar.

Is there more to change management than just communicating what's coming, putting up posters, Yammer posts, sending out emails to the users? What more is involved in a great change management strategy? 

Andrew Bibby: Yeah, I think you know, you mentioned there that project you worked on had change management. people dedicated to it.

That's, that's a unicorn. You know, in my experience is that a lot of organizations don't really take change management seriously. So I think change management is, is ultimately just getting people ready for the change that they're about to experience. So it's a kind of flowery title, but that's, that's the top and bottom of it.

It's making, it's the people side of change is what it's called. It's not about technology at all. But it is most often it's, it's comes down to training and it comes down to some communications, like you say, and that It's very often a few emails that get sent out in the weeks running up to go live, which, you know, predictably has poor results because people don't read emails.

They don't pay attention during training. I do the same thing just quietly. We're all likely to do this kind of thing. So you need to change management and actually getting people ready has to be a more fundamental part of a project. And where I see difficulties with that is with organizations that can't see the benefit of it.

But ultimately, and this is proved through a lot of change management methodologies, it is proven through research that if you do good change management, you're much, much more likely. To a have a successful go live, a successful project, much better return investment and good user adoption and good happy users.

You know, ultimately that's what [00:26:00] everybody wants. In particular, you want to see that money come back, right? So if you've invested a million dollars into a project, you expect to see more than that come back. Otherwise, what's the point? Literally, what's the point of spending a million dollars and not getting that back?

There's not many scenarios where you can justify that. And that's where it comes down to the argument of saying, well, why spend money getting people ready? Why spend money on change management? Cause it's adding to the budget of the project. It might be 10, 20 percent of the project, you know, quite a lot of money.

If you're adding that money and then you're seeing it back because you've got good user adoption, then it's paying for itself. It's a no brainer. And then you'll do it on the next project and the next project. So again, mini rant there, but yeah, in terms of what you can do to get. Get ready. It is that investment throughout the project.

It's involving people early, even before the project starts for the customer organization to start telling people that this is what we're planning to do. These are the benefits to you. And that's most often the question you need to answer is what's in it for me? You know, how's my life going to be better to each individual user?

What are the benefits to the organization when it's going to happen? And then it's keeping that communication going. It's regular updates throughout the project lifecycle to the impacted users, and that should be done in different ways, not just emails, not just posters, like you say, not just Yammer posts or internal sort of communication, because you're only going to catch a certain number of people with it with that.

Communication. So it should be done lots of different ways. Everybody should know what's happening. And a key point is that the communication should come from the right person or people that the person receiving that communication will actually listen to. So whether that's the CEO or the team leader or, you know, manager or whoever, it needs to come from a person that The people receiving that communication either have to listen to, or want to listen to, and then you're [00:28:00] going to get much more effective communication as you go through, but communication throughout the project, keeping everybody up to date on what's happening, when it's happening, how things are going. You can be open about issues that you've had and delays and things like that.

These things happen on every project. So why not tell people about them? But that's a key pillar of change management, or one of them anyway, is that communication and having a communication plan. It's very often left to somebody as a bit of a side job to actually communicate what's happening.

Like you said there on your project, you need dedicated resource. And actually, if you have dedicated resource, things go much better because people have got time to do a good job on that communication and, you know, training and whatever else needs to happen. 

Neil Benson: So 10 years ago, I don't think there was any change management in most of my projects, it's becoming much more common and that's a great thing.

I think it's a reason why my more recent projects have been more successful because we've had better change management and with our financial services firm, we had a change manager as part of it. Our scrum team. So in scrum we have developers who are building the product and it's normally analysts and makers and architects and developers.

And this time we had a change manager and the change manager had product backlog items to build just like we did. And they were the communication plan and the executive briefing pack and, you know, the training needs analysis study and all these artifacts that were not technical, they're not power platform components, but they were.

Contributing towards the success or deployment of our application. And I remember a couple of the executive briefings we were doing where he's showing the communications plan, but like you said, the communication wasn't always just coming from him. He was feeding his executives with things that they could say in their town hall, their next monthly update to their team members so that the communication was coming from all corners of the organization from top to bottom.

And through our change champions, it's coming from the [00:30:00] bottom back upwards again. And it was a pleasure to behold. It's definitely a key learning that I'll take away to future projects that do it like that. 

Andrew Bibby: Honestly, that's fantastic. And I have never worked on a project that has taken it that far, but I think that's exactly the sort of approach that needs to happen because change comes from the top in the, you know, Managers and team leaders are going to listen to their superiors and you know, all the way up to the executive.

So if the messaging is coming down from the top, that's the most effective way of getting messaging across, but also from the bottom as well, from the troops on the ground, you know, if you've got some of them on board, you're in a much better position, but it requires resource. It requires budget fundamentally, but I think, you know, ultimately you're going to have a much more successful project and it's actually proven by research.

If you do excellent change management on a project. You're six times more likely to have a successful project. You're five times more likely to be on time and deliver it on time. And you're twice as likely to not exceed the budget you've got, or even be under budget. I can't remember the last time I worked on a project that was under budget, but yeah, change management, whilst it's a bit of a buzzword, it's really, really effective way of having more successful project and ultimately who doesn't want a successful project, everybody.

So 

Neil Benson: I'm, I'm seven weeks out with my next customer. They're going live on Monday, 9th of October. Hopefully this episode gets published before then. And we are successful in October. You talked earlier about choosing the right day. It's Monday. We'll talk about the other things that we can do to be successful in this go live, but is Monday a good day or why would you not choose a 

Andrew Bibby: Monday, Andrew?

Yeah, I think I go back and forth on this and I think, and I was going to ask you the same question because you've got lots of experience in this. My experience is that, that it depends on the organization and depends on the team. My, my reluctance to go live on a Monday is all about. You're, you basically, you're expecting people to work on a weekend.

You can get, you can do as [00:32:00] much preparation as you want the weeks before that. And you can be, you can say, on Friday, okay, we're ready to go, but if something goes wrong, you need to have people ready over the weekend. And like it or not, some people are not willing to do that, or don't want to do that, or you might have to pay them some more money.

And it also adds more pressure as well. If everybody is logging in 9am on Monday morning and using the new system, things have to be working. If they're not working, then, you know, it's a lot, it's a lot to manage. And that's not to say choosing a different day of the week, so I would prefer to go live on a Wednesday.

And you've got, you know, hopefully a fairly calm lead up to that Wednesday. You've got some time with people actually in the office to be able to test things and do more rehearsal. You're not expecting people to work on the weekend, even though they might end up doing that, but it's less likely.

It's all about sort of lowering the pressure of a go live, all of that preparation and practice. If you've got a successful go live, then everything goes nice and smoothly and you've got a happy everybody. And I find that if you're going live on a On a Wednesday, that's, that suits me in a lot more scenarios, but it just depends on the organization.

Sometimes you can't do that. And if you've got hundreds and hundreds of users, you need to have a particular day and then that's it. But yeah, I'd be interested to, to understand why you chose the Monday or why the organization chose Monday. Oh, 

Neil Benson: it wasn't my, it wasn't my choice. And I think it's maybe, it's maybe, it's maybe a habit.

Because data migration events quite often are the long pole in the tent. You know, if you think about the activity that takes the longest, it's hard to compress it's data migration. Sometimes they just takes 36 hours to migrate all the data from a legacy system. Over into, into Dataverse and unless you've figured out a strategy for pre migrating the data, that can quite often be a, you know, last minute, go live activity.

And therefore you want to give yourself a weekend when there's not as much usage of the system or [00:34:00] no usage of the system to go live on a Monday. I don't think that's necessary in this example. I think we could have picked any day of the week. And I remember a policy more or less at Henderson Global Investors in London many, many years ago when I worked there their preferred go live was a Friday morning because Friday, traditionally in the finance sector in London is reasonably quiet day in terms of trading and investments and customer service and everything.

It was much quieter than most of the other days of the week. Monday morning was pretty busy, actually. Lots of activity kicking off at the start of the week. Friday allowed them to make a decision, you know, go live. What's a successful. If not, we're going to revert back to the old system on Monday morning, but we've got all weekend to fix it if there was an emergency and it came up, but Friday was pretty low pressure, low key way to ease the users into the new system.

And then the database administrators typically would knock off at one o'clock on Friday and you'd find them in a pub if you had to call them back in. So yeah, Fridays seem to work well in the city of London. I don't know if the culture has changed, but I don't think Monday morning's the best time to go live in a new system, it's too much.

Too much pressure. 

Andrew Bibby: Yeah, I think there's some good reasons you mentioned there, particularly around data migration, but if you can migrate data before or after to try and minimize that window, I think that's you know, a good approach, but yeah, it's going to come down to the organization, particularly the internal IT resources I find and when they're available and when they're willing to work because you're going, it's going to be a Friday I can see some of the benefits there, but I guess I'd be worried that actually.

When people start using the system, they start on Friday, and then they go away for the weekend. Maybe only do an hour on Friday morning, and then on Monday, they're like, oh, well, how do we do this again? And so maybe there's a bit more, sort of, mopping up of training and things like that, but probably quite minimal.

Lots of things we talk about there are really people impacts that you need to consider, not technical things, but other than the data migration, so many [00:36:00] people factors to our projects rather than technical things anymore. 

Neil Benson: Yeah, it could be where are the people located?

Is that a global deployment? You know, do we have time zones and languages to think about as well? Lots of factors that come into it and it's very organization dependent. 

Have you seen customers with great measurements for measuring the success or the impact of the application? You know, we talk about user adoption, but are they measuring case resolution times?

If in the old system and measuring those in the new system over the course of the first few weeks and months, and to be honest, I've never seen a customer with that much rigor or other KPIs that is measuring the outcomes of the new application. Have you had any success stories with customers measuring those kind of impacts?

Andrew Bibby: Yeah, again, this is a good question. And, and I've had similar experience in that people the project team is so focused on delivering the project from both sides, partner side and customer side, not really so concerned about what happens after go live, but ultimately, somebody went to the board, let's say, and said we need a million dollars to, to replace this system.

And the board said, okay. Great, when can we expect to see that money back in, in efficiencies in fewer support calls in quicker processes, better customer experience, ultimately. And then it's easy to come up with a load of reasons to say, okay, this process used to take four hours. It's now going to take two hours because we've put some automation.

So you can easily build out the benefits early on and justify that investment. But then. Ultimately, once you go live, you have to be able to prove that those things that you said are reality, or at least if they're not what benefits are there? And it might be that you've shortened that process to three hours rather than four hours, but there's still benefit there.

But if you don't have those metrics built into the system, there's no way to measure that other than some kind of time and motion study, which are painful for everybody. So [00:38:00] building in metrics and. Is how you, you can justify the original investment and that's going to help you justify the following investment because we're not in a world where it's a one off deployment anymore.

You need to continually invest in your systems. So this is something I can, I have to, sounds patronizing, but educate customers that we need to build this stuff in. And if it's gonna be built in, they need to be in the backlog. Those things need to be built. They need to be tested. You need to do reporting and maybe have some analytics out the back.

It all has to be built and that's, that's gonna cost some money and take some time and resource. But if you don't do that, you have very little way of being able to prove whether your system. Is a success or not, whether it's going to benefit the organization or not in the way that you expect. So, but I'm exactly in the same boat is most customers don't do that.

And what I often find actually is that the people that approved that budget in the first place. They're not all that interested either. They've spent the money, they're on to the next thing, or they've left. And that's very often the case on bigger projects. You know, the people that were involved originally have moved on.

And so there isn't the pressure to, to prove that actually this is a success, but. If you're not doing that, you don't know if you're delivering the benefit and the value to the organization. And so you can't continue to do that. It's much harder to justify continuing that investment. So yeah, absolutely.

They're building these metrics. The other thing is to is to build in monitoring of your solution as well, so that you're getting ahead of any issues that occur. So monitoring integrations, monitoring that user experience, so that you can try and fix these things before they become bigger problems, which is going to impact your user adoption, because people don't like using a system that's really slow or, you know, has.

Error messages popping up left and right. So if you're, if you're monitoring performance and error messages and things like that and getting ahead of those, again, you're going to have a better user [00:40:00] experience, better return on investment. So, and that's also something I don't see done very often, probably a bit more often than monitoring kind of business benefit.

But yeah, that's another important aspect. 

Neil Benson: Yeah, a couple of critical ones there, Andrew. So thanks for the nudge and the reminder. A couple of things I had to take back to our product owner next week and make sure she's considered those in a backlog. So we've, we've covered approaches to go live, you know, what does it go live?

Should we stagger it? Should we have a big bargain release? Should we try and do phase releases? We've talked about the importance of user training, testing early, change management, getting our communications and the change champions going. Talk about monitoring and business case benefits realization.

So it's so much grind we've covered. Is there anything else that you want to add in for the audience before we let you go? No, 

Andrew Bibby: I would say that everything that you mentioned there, there's a lot of effort, right? I think that ultimately, if this was easy, everybody would do it. You know, everyone would have successful projects and successful go lives and everybody would have an easier life but all each of those things also takes investment and that we need to get across this message of being able to justify the investment in these almost non functional areas.

So they're not satisfying business requirements often, but they are contributing to this successful project. Ultimately you can build a system that meets every single business requirement. You've done a great job as a partner. Delivered everything that you said you would, you're on time, on budget, but if people aren't using the solution, nobody wins. Customer doesn't win, partner doesn't win because you're not going to get called back to do that next phase.

I think it's all about this getting across the message that there is more to projects than technical delivery. And as you said, there is more appreciation than there used to be of that, but just getting the project across the line, that's just the first step ultimately in incorporating change management.

You're much more likely to be successful. So 

Neil Benson: Andrew, I believe customers, particularly in the UK can always tap into Proximo 3, you've got a [00:42:00] crack team of very experienced business applications consultants. If somebody is looking for expert assistance, maybe doing some, some go live planning how can people get hold of you if they want to get in touch?

Yeah, 

Andrew Bibby: absolutely. Well, visit our website, Proxmo3. com. We're on all of the socials, but also, yeah, contact me on LinkedIn. I'm fairly easy to find. And yeah, get in touch. Always happy to help. Even if it's just a conversation and you're looking for some advice or you'd like a bit more sort of structured approach where we can come in and Bring our 40 odd years of experience on business applications, projects to your project and, and help you avoid some of those pitfalls.

So yes, please do reach out. And have 

Neil Benson: you got any conference presentations or sessions planned where people can, can tap into some of your experience sitting in the front row? 

Andrew Bibby: Yeah, yes, great, great point. Yeah, I have there's a conference in Copenhagen coming up next month called Nordic Summit.

Nordicsummit. info. I'm doing a session now. It's actually on co pilot and using all the co pilot tools within Power Platform. So that should be fun. And also I'm, I'm hoping to be speaking at South Coast Summit, which is in the UK as well, and I'm actually one of the sessions I've submitted for that is around go live planning.

It's a free event and look for that SouthCoastSummit. com and yeah, come along and happy to talk over any of these aspects. 

Neil Benson: Andrew, thanks so much for joining me. I wish you well at the Nordic Summit and hopefully your sessions get picked up at South Coast Summit as well. I wish I could be there, but thanks so much for joining me on Amazing Apps today.

Andrew Bibby: No problem at all. Thanks for having me. Always good to talk. Thanks, 

Neil Benson: Andrew, for joining me on Amazing Apps. It was great to catch up with you. Pass on my regards to the rest of the awesome foursome at Proximo 3. I hope you enjoyed that episode with Andrew as well. If you did, there are two things you can do right now just before we close out episode 150.

If you've got a story to share about going live with Dynamics 365 or Power Platform, [00:44:00] come and share it on the show. Send me a message on LinkedIn or drop me an email, neil at customery. com. I'd love to feature a greater diversity of voices and stories on amazing apps. Not just from Microsoft MVPs, it could be you.

If you're not quite ready to join me on the show, the next best thing you can do is to ensure that other people is to leave me a rating or review on Apple Podcasts or on Spotify or on the show's website at amazingapps. show slash reviews. It helps prospective guests know that there's someone listening and enjoying the content I'm trying to create for you.

That's it for now. Until next time, keep experimenting.