Dec. 3, 2024

Episode 350: In the Dynamics Corner Chair: The Three Pillars of Successful Implementations

👩‍💻We have Nelly Jebran back in the Dynamics Corner chair with us on this episode — this time in an enthusiastic discussion with Patrick Johnson on the importance of #ChangeManagement in successful implementations. 👨‍💼

⛵Join Kris and Brad along with our two guests as we navigate the waters of #BusinessCentral implementations from both the partner and end user perspectives.🚤

What you don't want to miss:

👥Why talking to representatives of each business function early in the implementation is critical in an integrated #ERP like Business Central.

🙋‍♀️Why user acceptance of the solution is just as important as user acceptance testing.

😱How the fear of change can stall go-live decisions and how psychology anchors implementation success.

👑The vital role of leadership in launching an implementation project and sustaining it throughout, and post go-live.

✳️The need for thorough requirements gathering in ensuring user satisfaction.

🧗‍♀️How a phased approach can help manage user expectations and keep your project within scope.

🗣🗨How two-way communication and ongoing dialogue between users and partners drives continuous improvement.

🌱"Don't let 'perfect' be the enemy of 'good enough'" and help your teams "grow" through implementations instead of just "going" through them.🌻

Join the conversation here and tell us what you think!

Send us a text

#MSDyn365BC #BusinessCentral #BC #DynamicsCorner

Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/

00:00 - Implementing Business Central

07:14 - Managing Implementation Scope and Changes

21:59 - Involving Various Functions in Implementation

25:26 - Aligning User Requirements With Business Goals

35:46 - Overcoming Fear of Change in Implementation

47:17 - Building Trust and Continuous Improvement

52:01 - Fostering Continuous Learning and Growth

01:06:24 - Effective Implementation Strategies and Pitfalls

WEBVTT

00:00:00.781 --> 00:00:04.772
Welcome everyone to another episode of Dynamics Corner.

00:00:04.772 --> 00:00:06.644
You know what I would want.

00:00:06.644 --> 00:00:12.910
I want my power back, and that's a change that I'm willing to bet on that I'm going to get my power back.

00:00:13.441 --> 00:00:15.381
I'm your co-host Chris, and this is Brad.

00:00:15.381 --> 00:00:19.432
This episode was recorded on November 21st 2024.

00:00:19.432 --> 00:00:23.653
Chris, chris, chris, sitting up there in the Pacific Northwest without power.

00:00:23.653 --> 00:00:24.015
That's a change.

00:00:24.015 --> 00:00:24.256
You have to.

00:00:24.256 --> 00:00:24.736
Northwest without power.

00:00:24.736 --> 00:00:25.339
That's a change.

00:00:25.339 --> 00:00:27.225
You have to manage that change.

00:00:27.225 --> 00:00:29.006
It's a change and adapt to that change.

00:00:29.006 --> 00:00:49.290
Speaking of change, today we had the opportunity to talk about implementations, changes within an implementation, how to implement Business Central with two podcast veterans, and I could talk with these two guests for hours about business central implementations and the human factor behind the implementations and some things to look out for implementations.

00:00:49.290 --> 00:00:52.301
Today, we have the opportunity to speak with Pat Johnson and Nellie Zmar.

00:00:52.301 --> 00:01:14.918
I hope so.

00:01:14.918 --> 00:01:18.099
If it doesn't, it's alright, alright, you ready.

00:01:18.099 --> 00:01:23.420
Actual recording quality is higher.

00:01:23.420 --> 00:01:25.948
What is my rates?

00:01:25.948 --> 00:01:32.268
Oh, dude, it's actually uploading slow for me too.

00:01:32.268 --> 00:01:34.831
I'm at 48.

00:01:34.831 --> 00:01:37.534
Am I going?

00:01:37.534 --> 00:01:38.016
Okay, though?

00:01:40.224 --> 00:01:41.585
yeah, yeah you're, it sounds.

00:01:41.585 --> 00:01:43.390
You're very clear, actually.

00:01:43.390 --> 00:01:53.771
Good morning, hello, hello, hi, hello from the Chris.

00:01:53.771 --> 00:01:56.043
You got power, the dark side.

00:01:56.043 --> 00:01:57.228
I have no power.

00:01:58.487 --> 00:01:59.120
The dark side.

00:01:59.200 --> 00:02:00.606
I am running off a generator.

00:02:01.819 --> 00:02:05.045
Yeah, the city just decided to clean our street.

00:02:05.447 --> 00:02:11.576
Of course, course, like right as I logged on yeah, that's, um, that's usually something that happens to me, so it works.

00:02:11.576 --> 00:02:22.887
Usually, every time I start a recording, uh, somebody will knock on the door or the the individuals that take care of the lawn will come and feel that they need to take care of the lawn.

00:02:22.887 --> 00:02:23.748
It's like clockwork.

00:02:23.748 --> 00:02:28.649
It doesn't matter, I could have a different, so it's good.

00:02:28.649 --> 00:02:31.383
Good morning, miss Nellie.

00:02:31.383 --> 00:02:31.905
How are you doing?

00:02:33.629 --> 00:02:37.768
Good morning, I'm okay, I'm alright, I'm good it's gloomy and rainy.

00:02:39.961 --> 00:02:40.462
It's rainy.

00:02:40.462 --> 00:02:42.031
I love gloomy and rainy.

00:02:42.031 --> 00:02:44.520
You live in Washington, that's just.

00:02:45.002 --> 00:02:47.566
You have rainy, you live in Washington, that's just you have to.

00:02:47.566 --> 00:02:49.590
You, just you, lie to yourself.

00:02:49.710 --> 00:02:54.385
It's normal, it's normal, I don't mind the rain, but as long as it's not gloomy.

00:02:54.385 --> 00:02:57.205
And I don't mind the rain as long as it's not cold.

00:02:57.205 --> 00:03:01.010
But, like a cold, raw rain is not nice Unless you have a fire.

00:03:01.010 --> 00:03:02.837
Yeah, rain is not nice Unless you have a fire.

00:03:03.680 --> 00:03:06.443
Yeah, unfortunately, that's what I have right now.

00:03:06.443 --> 00:03:11.671
It's like, first of all, we're recording this podcast with no power.

00:03:11.671 --> 00:03:21.945
I'm running off a generator and it's cold, rainy, gloomy and clearly it's dark.

00:03:21.945 --> 00:03:28.562
But, surprisingly though, with my kids kids with no electric electronics we had a great time, you know.

00:03:28.562 --> 00:03:30.126
I mean like we just sat in the table.

00:03:30.126 --> 00:03:35.905
We played this game called left right, I love that game uh, I don't know, it's amazing.

00:03:36.205 --> 00:03:42.802
It's amazing, so it's like it's like needed, I guess, in a, in a connected world.

00:03:42.802 --> 00:03:51.787
But you know, you could only do that for like two days, right, and then you're like okay we need internet Dude how long have you been without power?

00:03:54.580 --> 00:03:55.364
So what's today?

00:03:55.364 --> 00:04:03.170
So Thursday, so that means we're having a power Tuesday, so we're not expected to have power back by Saturday.

00:04:03.170 --> 00:04:13.069
So it's pretty crazy that it's not typical.

00:04:13.069 --> 00:04:42.627
So we got hit with a what they call bomb cycle, a cyclone, bomb cyclone, and if you look at the images I saw yesterday and uh, it looks like a hurricane and you just get high winds we had like 65 mile per hour wind and so it was pretty, pretty scary, because I'm out in the woods with lots of trees and so a lot of neighbors had trees uh, fall on their property and then on, you know, on their house, unfortunately.

00:04:42.627 --> 00:04:50.127
So hopefully everyone comes out okay, whoever's dealing it, if you're out here in Washington State.

00:04:50.680 --> 00:04:52.387
Yeah, I talked to someone at Microsoft yesterday.

00:04:52.387 --> 00:04:58.307
Well, he was at the Microsoft office but had no power at home.

00:04:59.221 --> 00:05:01.045
Yeah, Redmond, which is where Microsoft is.

00:05:01.045 --> 00:05:05.048
Redmond, a ton of people that have no power.

00:05:05.048 --> 00:05:17.434
So there's about half a million, more than half a million people don't have power in one power provider, when you don't have power.

00:05:17.514 --> 00:05:22.711
It's a harsh realization sometimes of how dependent you are upon power for some of the smallest things.

00:05:22.711 --> 00:05:26.223
Even some stoves or other devices require power to start.

00:05:26.223 --> 00:05:28.569
So it it's, it's a catch.

00:05:28.569 --> 00:05:33.428
So you have to go back to make sure you have the traditional, you know, matches and and wood.

00:05:33.428 --> 00:05:35.596
But um yeah, which?

00:05:35.815 --> 00:05:43.182
which this whole conversation this whole conversation may be fitting for the individuals that we're speaking with, uh, but you know this whole.

00:05:43.182 --> 00:05:47.608
How do you deal with with change management or how do you deal with process?

00:05:47.608 --> 00:05:50.814
And thank you both for joining us again.

00:05:50.814 --> 00:06:00.932
You're both veterans now and we've had great conversations with you both and I'm happy to have both of you together because we have a lot of conversations about Business Central.

00:06:00.932 --> 00:06:09.553
As far as from the technical point of view and maybe from the application point of view of you know how to use the application, how to develop the application.

00:06:09.579 --> 00:06:16.788
I see a lot of information about that and what I'm happy to start seeing a lot of is how do you implement it right?

00:06:16.788 --> 00:06:19.259
It's not usually a lot of conversation about.

00:06:19.259 --> 00:06:30.526
These are the things that you need or should do as you undergo an implementation of Business Central or in anything I guess you could say, any ERP application.

00:06:30.526 --> 00:06:36.026
So it can kind of you know, cross many different applications that you have.

00:06:36.026 --> 00:06:45.048
But before we get into the conversation, if we could just tell everybody a little bit about yourselves and we'll go from right to left, left to right.

00:06:45.048 --> 00:06:46.005
However, I'm looking at this, patrick tell us a little bit about yourselves and we'll go from right to left, left to right.

00:06:46.005 --> 00:06:47.187
However, I'm looking at this.

00:06:47.187 --> 00:06:53.295
Uh, patrick, give us a little bit about yourself, please yeah, great having you guys.

00:06:53.516 --> 00:06:56.125
Uh, for another amazing conversation.

00:06:56.125 --> 00:07:00.322
Um, nelly, is the first one we get to do together, so great, great, getting to see you again.

00:07:00.322 --> 00:07:08.745
Um, my name is patrick johnson, so I am the business central practice manager at lbmc technologies, um, based in atlanta.

00:07:08.745 --> 00:07:09.767
I've got power.

00:07:09.767 --> 00:07:12.754
So sorry, chris, we got the mother-in-law suite.

00:07:12.754 --> 00:07:13.300
Come hang out.

00:07:13.300 --> 00:07:22.882
Um, you know we have been in this space for 21 years, coming up on 22, but what is it we talked about last time?

00:07:22.882 --> 00:07:26.511
We're going to start saying that, no, I've been doing it for more than two decades, over two decades.

00:07:26.552 --> 00:07:31.968
Yeah, Everything from general application implementation.

00:07:31.968 --> 00:07:49.266
I've been an end user, done support and development, a little IP, and then for the last five years I've been running a practice doing implementations, managing teams, doing cross implementations around platforms inside of the D365 suite, as well as a bunch of other tertiary products.

00:07:51.470 --> 00:07:52.473
Great, great Nellie.

00:07:52.473 --> 00:07:52.892
How about you?

00:07:55.302 --> 00:08:05.007
Well, thanks for having me on with Patrick, because I watched Patrick's episode and I loved your approach to implementations from a partner side, and something that I don't see often.

00:08:05.007 --> 00:08:07.925
So thanks just for that perspective.

00:08:07.925 --> 00:08:18.148
I'm excited to talk to you, but a little more, um, I'm back in the chair.

00:08:18.168 --> 00:08:20.632
We have the sign again we do.

00:08:20.632 --> 00:08:24.223
This is a permanent fixture in my household now um, so I have been in the bc space for half a decade.

00:08:24.223 --> 00:08:24.944
That doesn't sound as impressive.

00:08:24.964 --> 00:08:25.065
We do.

00:08:25.065 --> 00:08:26.168
This is a permanent fixture in my household now.

00:08:26.168 --> 00:08:27.913
So I have been in the BC space for half a decade.

00:08:27.913 --> 00:08:38.572
That doesn't sound as impressive For five years as a user and just due to the nature of the implementation.

00:08:38.572 --> 00:08:51.047
It was right in the beginning of COVID Our partner couldn't be on site and I had to kind of learn a lot that I may not have had to, which is, in hindsight, a really good thing.

00:08:51.047 --> 00:09:17.751
Um, and I think it's a great product, but we struggle to implement it because of the lack of change management, and so people don't think of it as much of a great product as it is because of that, and I try, you know, with our implementations and our other divisions, to keep that in mind, so that the benefits of the solution are evident to the users.

00:09:18.052 --> 00:09:23.490
And I think that has, you know, change management is critical to that, and so here, we are.

00:09:23.860 --> 00:09:25.206
No, it's great, Great Thank you.

00:09:25.206 --> 00:09:30.469
I look forward to the conversation with both of you and I get to see a lot of the information that you both share.

00:09:30.469 --> 00:09:41.229
But, as we talked about, I think separately and now I'm happy that we're all together but as, going through implementations, how do you?

00:09:41.229 --> 00:09:54.450
You know, one of the things that I see a lot of and work with a lot of on implementations is, you know, determining the scope of the project, right, how do we determine the scope of the project?

00:09:54.450 --> 00:10:11.291
And anytime you determine the scope of the project when you're going to do what we'll refer to as requirements gathering, as you go through the actual implementation, we have that wonderful thing called scope creep, right, and maybe does anybody know what scope creep is?

00:10:11.291 --> 00:10:12.785
Does anybody experience scope creep?

00:10:14.562 --> 00:10:15.206
All the time.

00:10:17.041 --> 00:10:18.488
We're the cause of that, the users.

00:10:18.990 --> 00:10:19.673
Yeah.

00:10:19.754 --> 00:10:33.753
Probably Well, and to be fair, sometimes it's the partner too, right, because if we're not asking the right questions at the right time, right, we might be missing something, because as users, you guys don't necessarily know what you don't know before you get into the situation.

00:10:33.753 --> 00:10:47.091
So you know, one of the things I like to say when I'm talking to clients, or even internally, is that this is the scope as we understand it today right, with an understanding that there's probably some need for agility later on.

00:10:47.091 --> 00:10:54.150
Otherwise, you know something that might take 6, 8, 12, 18 months.

00:10:54.150 --> 00:10:58.028
It used to say what the life cycle looks like.

00:10:58.028 --> 00:10:59.988
We're in a space that changes every six months.

00:10:59.988 --> 00:11:03.986
We get new features, hot fixes, there's new ISVs, right.

00:11:03.986 --> 00:11:10.610
So I always like to try to say scope as of today, right, with the expectation that there might be a change later on.

00:11:10.610 --> 00:11:17.089
Now, if we've got a one-week sprint and you change scope on Wednesday, right, there might be a little bit of a different conversation.

00:11:19.640 --> 00:11:24.652
Let me ask you guys a question from as implementers, typically from requirements gathering to go live.

00:11:24.652 --> 00:11:29.607
What's the typical timeline, or does it depend on, oh god, company size?

00:11:29.607 --> 00:11:33.942
Ours was two months and it was crazy.

00:11:34.022 --> 00:12:04.975
for my point of view it varies because it depends on what you're implementing and also, as you had mentioned in your comment, the size, because if you're implementing maybe the financials portion of it just general ledger accounts, receivable, accounts payable, just strictly invoicing, not really inventory management, that would be much faster than an implementation that involved distribution, manufacturing, multi, you know, transfers and such.

00:12:04.975 --> 00:12:14.094
So in my experience it varies and I don't think there's a cookie cutter approach to an implementation.

00:12:14.094 --> 00:12:20.048
I mean, I guess you could go through the process of determining what you need to implement, but I don't think that two implementations are the same.

00:12:20.048 --> 00:12:24.091
I mean you could even do two companies within the same company and the implementations could be different.

00:12:25.701 --> 00:12:36.048
Yeah, I mean, I've implemented two competitors right, so like two people to do the exact same thing in the exact same platform and generate the same product, and their two implementations were completely different.

00:12:36.048 --> 00:12:38.326
And it's something that I like to say.

00:12:38.326 --> 00:12:40.892
It's the people there and their processes, right.

00:12:40.892 --> 00:12:47.412
The platform could be identical, but those first two portions of it have a really big implication on the implementation.

00:12:47.412 --> 00:13:03.190
And then you know also the adherence to change management, right, because the people they're particularly leading the project and also the people involved in the implementation can really define how often they stray from what you kind of defined.

00:13:04.211 --> 00:13:12.751
And then also how fast it goes, right, it's the level of engagement, um, from the end user, because at the end of the day, like, how fast can you implement bc?

00:13:12.751 --> 00:13:15.807
I mean, the fastest one I've done was four weeks, right?

00:13:15.807 --> 00:13:17.894
Um, it don't.

00:13:17.894 --> 00:13:20.361
Yeah, that's a, that's a story for another day.

00:13:20.361 --> 00:13:35.496
But the, the uh, you know, the longest one I did was 36 months, and it was because we just constantly had this huge change curve you would see it every three or four months where, like, a new person would come into the project and have new requirements yeah, I think it.

00:13:35.758 --> 00:13:36.900
I think it varies so much.

00:13:36.900 --> 00:13:57.767
There's so many variables, like what patrick's, you know, mentioned, I've done, uh, my finance module only for a month and then, you know, and the other side of that, I've also worked with another end user that had his only finance module as well, but it took them three months and they were exactly the same.

00:13:57.767 --> 00:14:11.153
You know, again, there's so many variables because your involvement right, the end user's involvement can also hinder that because they're too busy, and vice versa as well.

00:14:11.153 --> 00:14:12.345
So, yeah, it really varies.

00:14:13.744 --> 00:14:14.567
Well, let's take that back.

00:14:14.567 --> 00:14:19.346
What I started talking about was scope creep, right, and I don't want to confuse.

00:14:19.346 --> 00:14:25.970
I mean, patrick, you started talking about maybe a change of scope because of the climate at a particular time.

00:14:25.970 --> 00:14:35.379
So, as you're going through implementation if it's spanning months or years, there may be a different requirement from the business point of view you had mentioned.

00:14:35.379 --> 00:14:39.822
Add a new person to the project and they change the requirement.

00:14:39.842 --> 00:15:00.092
So let's take it back to how can we minimize the scope creep, which, to me, scope creep means we've already gone through, or an organization has already gone through, a determination of what is needed and then, as they're going through the application, they say, oh, can we add this, oh, can we do this?

00:15:00.092 --> 00:15:06.495
Something that's separate from maybe a change in process, but it's now that I'm starting to use the application.

00:15:06.495 --> 00:15:07.797
I can see the stuff that we're doing.

00:15:07.797 --> 00:15:22.745
I'd like to have new things added From the user point of view and from the partner point of view, working together, which is why I'm excited to have both of you on, because we can have maybe two different perspectives or maybe two different thoughts on it from different angles.

00:15:23.460 --> 00:15:26.629
How can we minimize or how can someone minimize that?

00:15:26.629 --> 00:15:27.341
Because to me.

00:15:27.341 --> 00:15:44.671
I've seen that that's been costly, not only costly financially, because you often require additional time, and costly because of, again, time, it will maybe push the implementation off from your go-live date once you schedule one.

00:15:44.671 --> 00:15:56.110
And if you do have it scheduled, you're trying to squeeze some stuff and you may not get stuff thoroughly tested or thoroughly, you know, thoroughly, uh, trained, um, so how could you minimize that risk?

00:15:56.110 --> 00:16:02.990
And then I always have to go back to my famous question, which I'll ask afterwards here.

00:16:03.211 --> 00:16:09.726
Uh, maybe I'll start from the partner's side, because we're usually driving some of the conversation, at least in the first couple weeks.

00:16:09.726 --> 00:16:25.014
Um, you know, generally it's a shared project plan with the architecture understanding of hey, you know, you communicated x, y and z and we've recommended that you implement right and glap and ar.

00:16:25.014 --> 00:16:30.729
And then hey, but you also have this inventory component that might require this, this and this.

00:16:30.729 --> 00:16:33.000
This is how we're going to do it.

00:16:33.000 --> 00:16:35.225
We'll build out a project plan and we'll try to work towards that.

00:16:35.225 --> 00:17:06.133
You, as an end user, we try to share that project plan because it's very much you have to own a part of it, right, like, at the end of the day, we're really just helping you do the thing that we know how to do really well, but at the end of the day, like you have to own your system, like we can't be there to run your business, like there's other kind of consulting to do that, right, um, but for us it's a big thing about communication, transparency and then that shared progression, right, and we do it through, like project plans and weekly check-ins and things like that.

00:17:06.133 --> 00:17:16.991
But you know, I think it all boils down to communication and then level set expectations, right, like if you want to change something, this is how we change it procedurally, internally.

00:17:16.991 --> 00:17:19.726
And like there needs to be some level of agreement around.

00:17:19.726 --> 00:17:24.826
Yeah, if we're going to make a change to the scope of this implementation, we agree.

00:17:24.826 --> 00:17:34.028
You know, we'll go through this process with you and we've established that process based upon, you know, a lot of experience seeing it either done really well or, in some cases, really poorly.

00:17:34.028 --> 00:17:46.261
And it's that expectation and communication that I think really makes those successful, because change is going to happen at some point during the course of that implementation.

00:17:46.461 --> 00:17:59.163
Like it just is, um, and it's again because you don't know what you don't know, uh, but I think you've got to be really clear, transparent, honest, um, and that's bi-directional communication right.

00:17:59.163 --> 00:18:02.300
Like it can't just be the partner driving the whole process of the communication.

00:18:02.300 --> 00:18:05.008
Like the end users have got to communicate back to the partner driving the whole process of the communication.

00:18:05.008 --> 00:18:07.094
Like the end users have got to communicate back to the partner what their expectations are.

00:18:07.094 --> 00:18:11.086
Because it's not, you know, it's not all on the partner and it's not all on the end user.

00:18:11.086 --> 00:18:16.689
Like there's a reason they call us a partner and not an implementer, right, and it's because a partnership exists between the two groups.

00:18:16.689 --> 00:18:29.714
I mean, you really have to address it that way, rather than just treating it as a business transaction, like it really is a relationship style interaction, yeah, yeah, and I think from from a user perspective.

00:18:31.301 --> 00:18:32.183
So a couple of things.

00:18:32.183 --> 00:18:48.281
And I'll add one ownership on the client side is critical and has to be, again, like you said, it's your, your partner, but this is our system and it's going to be our system for how many years?

00:18:48.281 --> 00:18:50.046
So that part is critical.

00:18:50.046 --> 00:18:53.353
And then what you, you don't know, what you don't know.

00:18:54.000 --> 00:19:08.859
So from our experience, that was a huge element in scope creep, because we would get into certain functions and like, okay, we're doing this, okay, we're doing this, and then we're doing this.

00:19:08.859 --> 00:19:14.940
And then when we test it out, it's like, oh crap, no, we can't do this without this process.

00:19:14.940 --> 00:19:17.489
I'm thinking of when we were doing warehouse picks.

00:19:17.489 --> 00:19:32.973
We were testing warehouse picks and shipping, and so the standard warehouse pick in Business Central was missing a lot of information that we need, and so, okay, we had to rework that, create a custom warehouse pick.

00:19:32.973 --> 00:19:58.750
And so I think that discovery phase and, chris, I think, like you've talked about this a lot, a thorough, thorough discovery of what the client or the customer process is and like, like down to the nitty gritties so that you can incorporate that into the scope before actually doing it and then realizing, oh no, we need to do that.

00:19:58.750 --> 00:20:01.519
So, um, that's something that I would emphasize.

00:20:01.519 --> 00:20:11.752
Um, like, even the details that you don't think are going to matter, they do end up mattering when you're actually live or testing.

00:20:12.942 --> 00:20:20.111
And then I think another critical piece is like sponsorship, a sponsor on the client side who keeps things in check.

00:20:20.111 --> 00:20:22.326
If the sponsor knows this is what we want to implement.

00:20:22.326 --> 00:20:23.951
It might be a phased approach In phase one.

00:20:23.951 --> 00:20:25.115
This is what we want to implement.

00:20:25.115 --> 00:20:26.861
It might be a phased approach in phase one.

00:20:26.861 --> 00:20:31.731
This is all we need to do, and so anything else is going to be phase two.

00:20:31.731 --> 00:20:37.423
We're going to get by with whatever we're doing in phase one, but the sponsor on the client side has to enforce that.

00:20:37.423 --> 00:20:41.558
Um, with the understanding that the business will continue to function.

00:20:41.558 --> 00:20:50.115
We're going to support, we're going to do whatever we intend to do, and all these other things are just going to be add-ons and perks after the fact.

00:20:50.115 --> 00:21:00.933
So, yeah, sponsorship, ownership on the client side, and like thorough discovery, I think are three critical elements to mitigate scope creep.

00:21:02.063 --> 00:21:06.307
I do have a comment, nellie, you mentioned, mentioned about.

00:21:06.307 --> 00:21:08.241
We're talking about the requirements gathering.

00:21:08.241 --> 00:21:19.326
You can have the best requirements gathering, but if you don't have the, you don't have the right person yeah to be able to speak up.

00:21:19.326 --> 00:21:24.814
It's, it's, it's not, it'll be worthless.

00:21:24.814 --> 00:21:38.624
Because I've been in situations or I've been in implementations where everything was written, everything was well thought of and towards the very end someone comes up and say, actually, that's not what we do.

00:21:38.624 --> 00:21:42.431
I was like, where have you been, you know?

00:21:42.471 --> 00:21:43.512
that's change management.

00:21:43.512 --> 00:21:44.034
It's crazy.

00:21:45.076 --> 00:21:56.167
That is change management exactly yeah, because, uh, like you said, you can have somebody responsible for the project and the client and has no idea what's happening with each function.

00:21:57.009 --> 00:21:59.420
Um, they may think this is what we need to get going.

00:21:59.420 --> 00:22:02.162
Um, so again back to change management.

00:22:02.162 --> 00:22:47.009
This is why, before you're even talking to a partner about an implementation internally, you need to talk to everybody that you possibly can in each function in that conversation, and then one person is like the documenter of all of that and the communicator, but everybody has to be involved in that internal discovery first, and then you communicate that to your partner and have people from multiple functions in those meetings with your partner, because I'm not going to know what a finance function requirement is, I just don't.

00:22:47.009 --> 00:22:58.162
And so somebody from finance and accounting needs to be on those calls, someone from warehouse needs to be on those calls, and in our case, it was just me trying to represent everybody.

00:22:58.162 --> 00:23:00.125
I did an okay job, but I wish I could have brought in other people.

00:23:00.125 --> 00:23:06.515
I did an okay job, but I wish I could have brought in other people, and I would do that in the future.

00:23:09.048 --> 00:23:09.451
Absolutely.

00:23:09.451 --> 00:23:15.920
Yeah, that's.

00:23:15.920 --> 00:23:17.563
I think that's very, very important to bring in others perspective.

00:23:17.563 --> 00:23:40.007
Because I mean, Patrick, I don't know if you've got come across this and I think this came across one time in in my experience where gather requirements, we provided the estimate, everything looks good, and you go through the implementation at the very end or not very end, but closer to the to the end, as you're going through the uat, you know they all agreed to maybe use out of the box functionality because it met the requirements, right, all that stuff, uh, towards uat.

00:23:40.007 --> 00:23:47.101
They come up to you and say this is not what we had expected yeah, yeah, you wanted to look like this.

00:23:47.121 --> 00:23:50.990
I was like wait, you were okay with the out of the box in the zero hour.

00:23:51.029 --> 00:23:51.811
Why the change?

00:23:52.092 --> 00:23:54.964
yes, yes, um, how do you handle that?

00:23:55.726 --> 00:24:00.034
you know, I think I mean I think everybody is, I don't, you know.

00:24:00.034 --> 00:24:07.913
I think if you've been in the space and done more than a couple implementations, you've probably run into it because unfortunately it's common.

00:24:07.913 --> 00:24:23.808
You know, like I'd like to say that it happened one or two times in the last year, but you know it's a pretty common thing and a lot of it has to do with some of the scale of your organization can be a big impact on that.

00:24:23.808 --> 00:24:49.359
Because you know, to be transparent, not everybody can be part of the implementation, right, and you know, back in the day when I was doing a lot of implementations, my thing was warehousing and manufacturing and unfortunately those guys are usually underrepresented in the implementation groups and unfortunately those guys are usually underrepresented in the implementation groups.

00:24:50.079 --> 00:24:54.665
And then you know you'll get out there and you're training users on handhelds and they're like, yeah, the manager thinks that that's how I do my job, but let me tell you how I actually do it.

00:24:54.665 --> 00:25:26.246
It was like, guys, we've been implementing for like four months and I'm just now hearing this while we're doing user acceptance testing, and I got to be honest, like I've got to go back to the product sponsor inside of the implementation team and be like, hey, you need to figure out what is a business need, what is a business requirement and what is our path forward, and then I'll help you figure out what that is, but I can't be the one making the decision as to what's best for your business moving forward, and there there's a.

00:25:26.246 --> 00:25:42.564
There's a second portion of this which I think is part of OCM, which is user acceptance and utilization after you've been live, and if those people that are out there doing the job all day long don't like the system because they don't feel represented in it, they're never going to adopt it.

00:25:42.564 --> 00:25:46.451
They're going to revert back to like bad practices or the way I've always done it.

00:25:46.451 --> 00:25:55.410
God, I hate that, but like the way I've always done it because I know it works right, even though that may not be the way that we need to do this.

00:25:55.450 --> 00:26:14.452
Going forward for the best path for the business, right, or maybe like there's an effort that they don't have visibility of, but if they don't feel represented in their voice as far as like this is how I do my job isn't represented within the implementation, you'll struggle and you'll end up with OCM.

00:26:14.452 --> 00:26:16.315
You'll end up with scope creep.

00:26:16.315 --> 00:26:18.676
You'll end up with changes in the zero hour.

00:26:19.978 --> 00:26:23.883
And those can be costly financially as well as the implementation.

00:26:23.883 --> 00:26:32.211
Because I've seen changes come in and I still struggle with when do you introduce changes and how do you determine the changes?

00:26:32.211 --> 00:26:35.817
Because you mentioned, patrick, what is the business requirement?

00:26:35.817 --> 00:26:47.107
And then also what is the requirement within the application, because you know a change or a scope creep or a change in scope.

00:26:47.107 --> 00:27:01.890
I've seen someone want to say something just because they became more comfortable with the application or going through the process, or a requirement came up and a modification was made, or somebody started a process and they said, oh, I found this button, this can do this.

00:27:01.890 --> 00:27:08.828
Oh, that would be so great if we could do this, which could throw off the entire process that you put together and and sent it back.

00:27:08.828 --> 00:27:21.359
So how can someone determine the difference between a business requirement and a business requirement within the application?

00:27:25.528 --> 00:27:29.434
you know from from my perspective as a partner, but I've also been an end user, right like I've the application.

00:27:29.434 --> 00:27:34.430
You know from my perspective as a partner, but I've also been an end user, right Like I've been a warehouse user, been running around a forklift in a giant warehouse.

00:27:34.651 --> 00:27:38.363
That must have been awesome, yeah you.

00:27:39.965 --> 00:27:53.502
You say that it's fun until you're like 100 degrees and in the south you know 100 humidity and yeah so it's fun for an afternoon or a couple hours then maybe yeah, it's fun for the discovery now that I sit in air conditioning all day.

00:27:53.883 --> 00:28:10.352
Um, the um, the the big part of that is really determining what's mission critical for the business, right, and sometimes, unfortunately, that can't be what's mission critical for the individual.

00:28:10.352 --> 00:28:34.478
You've got to have as a partner and as an end user and probably more so important as an end user have a clear vision of what do I want to do and this is like such a horrible cliche, but it's true Like what do I want to do in the next five years, right, and then help help your partner understand those goals and why you're making some of those decisions.

00:28:34.478 --> 00:28:40.762
Obviously, you can't tell them everything, but at least give them some indication so that we can help you through that process.

00:28:40.762 --> 00:28:52.112
Because, much like you were kind of describing Brad, where you might have a user say oh, I didn't know I could use that button, we may not have known to recommend it because we didn't know that that was a requirement right.

00:28:52.339 --> 00:29:03.722
Like there's like a really unique, judicious way to say well, if you had told me in the first place, right, but you obviously can't say it that way.

00:29:03.722 --> 00:29:04.444
But it's the.

00:29:04.444 --> 00:29:09.502
You know, if we understood these requirements at day one, we might have recommended a different path.

00:29:09.502 --> 00:29:21.690
And in some cases it's like a blip right, like it's a day of work to change it, and in other times it restructures a lot of the organizational change as well as the system.

00:29:22.711 --> 00:29:26.576
So, but to take that back, I know, nellie, you probably have a lot to add.

00:29:26.576 --> 00:29:28.538
I'll pause for a moment, but I get excited about the topic.

00:29:28.558 --> 00:29:29.319
I do, I'm trying to jot them down.

00:29:29.319 --> 00:29:31.079
No, no, no, I will pause in a moment.

00:29:31.240 --> 00:29:37.027
But what you're talking about is similar to my question is there's the business requirement.

00:29:37.027 --> 00:29:50.326
I may be a business manager, business owner or someone who's driving the future of the business, and then you also have the individuals that are performing the actions daily, that will have requirements based on what they know.

00:29:50.326 --> 00:29:54.606
So now, how do you in essence then filter?

00:29:54.606 --> 00:29:57.534
Okay, here is the requirement from the user.

00:29:57.534 --> 00:30:00.779
How does it align, maybe, with the direction of the business?

00:30:00.779 --> 00:30:06.492
Because, to me, if you're going to switch to a new ERP system such as Business Central, there's a reason for it.

00:30:06.492 --> 00:30:10.851
The reason may be you want to get efficiencies, you want operational gains.

00:30:10.851 --> 00:30:12.743
There's some sort of reason.

00:30:12.743 --> 00:30:21.325
So, the requirements that a user has, how do they align with the direction of the business and how do you make sure that that comes together?

00:30:21.325 --> 00:30:30.807
So then, also, when you're going through the implementation, it's not somebody saying, oh, I found this button, it would make my life so much easier and, like you said, it could shift you in a different direction.

00:30:30.807 --> 00:30:33.073
It's tough.

00:30:33.480 --> 00:30:35.045
See, this whole implementation thing is tough.

00:30:35.385 --> 00:30:36.067
Yeah, I'm jumping in.

00:30:36.067 --> 00:30:38.031
I'm being quiet, I'll mute myself.

00:30:44.300 --> 00:30:44.761
No, it's fine.

00:30:44.761 --> 00:30:52.263
I think this is where a phased approach is is important because you can have, okay, this is our ultimate, perfect, ideal vision of the system, incorporating what the users need and everything.

00:30:52.263 --> 00:30:59.769
And, like you said, pat, like as the customer or the sponsor, you communicate those things to your partner what are all the requirements?

00:30:59.769 --> 00:31:05.920
But at the same time, you've got to be communicating what we're going to accomplish in a phased approach to your people.

00:31:05.920 --> 00:31:17.222
So, okay, you're not going to have this functionality for a little while, but we're going to get by with this because we need to keep the business operating, we need to keep shipping orders, whatever it is that we want to do.

00:31:17.222 --> 00:31:21.131
But this is in the next phase and we're going to do this.

00:31:21.131 --> 00:31:25.287
And then in the next phase, we're going to add this there has to be like a minimum.

00:31:25.346 --> 00:31:39.982
I guess a minimum viable product, if you're kind of talking agile like this is going to keep us going and your, your people, need to know that like this isn't the end of it, but we have to do something and then we can talk about something else in phase two.

00:31:39.982 --> 00:31:40.865
That's frustrating.

00:31:40.865 --> 00:31:55.468
Frustrating too, because, as a user, there have been things that I've been told are going to be in phase two and I'm like, but no, like we want that now, we need that now, and it's gonna suck, but it's a give and take.

00:31:55.468 --> 00:32:01.548
But I think communication and conversation with your people from the beginning about what we're gonna do helps that.

00:32:01.548 --> 00:32:09.531
Just let them know, like, like, this is the plan, this is what we're going to try to do, this is what we want to accomplish, and it's not going to be all done overnight.

00:32:09.531 --> 00:32:17.288
Um, and I don't typically are doing phased implementations, or is it like start and then we're done?

00:32:19.073 --> 00:32:25.222
that that depends for yeah you know that really depends because you know a partner would do their.

00:32:25.222 --> 00:32:36.751
I consider your partner as the, the organization that will, or your partner would be responsible for executing your vision right, because they know the system.

00:32:36.751 --> 00:32:41.503
But, um, it's really up to you if you want to do phases.

00:32:41.503 --> 00:32:44.711
I've've been in implementation where I don't want phases.

00:32:44.711 --> 00:32:53.246
I want everything I need to do to get my business running, so even things that they wanted to add.

00:32:53.246 --> 00:32:58.115
They don't have now, but they want to add because Business Central has that capability.

00:32:58.115 --> 00:32:59.325
They want that now.

00:32:59.819 --> 00:33:05.113
They don't want to have to wait, you know, three months after go live to execute that.

00:33:05.113 --> 00:33:07.047
They would say, why can't we do that now?

00:33:07.047 --> 00:33:08.945
It's really a balance.

00:33:08.945 --> 00:33:12.109
It's never a question of like, why can't a partner do that?

00:33:12.109 --> 00:33:21.590
It's usually it's like do you have the capacity, you as an end user that's going to live in this application that's going to backbone of your, of your organization?

00:33:21.590 --> 00:33:29.135
Can you know, um, do you have the capacity to do that and try to change that or bring in a new process?

00:33:29.917 --> 00:33:40.390
yeah, and another piece too is like the microsoft updates like that come all the time that we tend to like those might solve a problem that we have now that we don't know it's going to be solved.

00:33:40.390 --> 00:33:48.828
Like, if you kind of wait it out I we've seen that happen like things that we wanted that would have now that we don't know is going to be solved If you kind of wait it out we've seen that happen Things that we wanted that would have been customizations just end up being part of the system.

00:33:48.828 --> 00:34:01.028
So understanding that the system is continuously evolving and changing helps us as users to know okay, well, this is not necessarily permanent and we might have a solution coming up soon.

00:34:01.028 --> 00:34:06.170
Let's just kind of wait it out and see what's coming and if that works, then we're good, Then we don't need to customize.

00:34:06.780 --> 00:34:14.826
To that point, Nellie, I'm going to do a shameless plug akams forward, slash BC ideas If you are not putting your stuff in there.

00:34:15.527 --> 00:34:20.048
Microsoft is not going to hear about the thing that you want unless your partner is putting it out there for you.

00:34:20.048 --> 00:34:26.793
And they hear about the thing that you want unless your partner's putting it out there for you and they do look at it and they upvote and they talk about the development plans for it and they'll throw it on the roadmap.

00:34:26.793 --> 00:34:34.447
Um, but, kind of going back to, I think, your original question, brad, you know the how do you determine, like, how do you address that change?

00:34:34.447 --> 00:34:41.811
The big thing that I ask my people is like how is this going to impact your ability to either provide goods and services and generate revenue?

00:34:41.811 --> 00:35:02.681
And if you can still do those core things, let's address refinement at a later date, right, and you know, as long as we can still operate in the premise of can I generate revenue, can I run my business, are my people are going to be OK at the end of every day, and can we refine that at a future date?

00:35:02.702 --> 00:35:07.893
And then you know not to jump into the phased approach again, but can I potentially push that change into a future phase?

00:35:07.893 --> 00:35:11.409
But can I get live and be able to run my business day one?

00:35:11.409 --> 00:35:14.204
And you know we're not trying to quote unquote.

00:35:14.204 --> 00:35:17.932
Like not every implementation's goal is quote unquote to just get it live as fast as you can.

00:35:17.932 --> 00:35:33.106
But if you're going to jump into an effort like implementing Business Central or any platform, the goal has got to be continue business operations as quickly as possible, because the implementation is a big interrupt.

00:35:33.106 --> 00:35:45.726
It's pulling people away from their day-to-day jobs and then get them back to being able to run the business and generating revenue and then worry about refining and making that a little better or easier.

00:35:45.726 --> 00:35:53.548
Um, assuming that you've introduced this new scope, creep right yeah, the go live.

00:35:54.692 --> 00:35:56.375
see this, this, the go live.

00:35:56.375 --> 00:35:56.735
Right.

00:35:56.735 --> 00:35:58.559
So you go through a project, you plan.

00:35:58.559 --> 00:36:00.784
I do want to go back to the requirements.

00:36:00.784 --> 00:36:06.393
I still have this thing hung up in my brain that I can't shake.

00:36:06.393 --> 00:36:29.610
But to go back to the go live, as you're talking about, with the go live date and preparation for go live and making sure that the business can operate, you know, typically some will say if we can ship products and, you know, apply cash, you know if we can ship product, ship invoices and receive cash, you know we're OK to start and then we can, and you know, bring in some of the other changes and efficiencies.

00:36:29.610 --> 00:36:33.367
But you have an implementation, you have a go live date planned.

00:36:34.320 --> 00:36:46.003
Now I've seen some hesitation at times of when do you go live Right, some hesitation at times of when do you go live right Is is what.

00:36:46.003 --> 00:36:53.543
How do you determine that you're ready to go live and how can you, you know, ensure that the go live is going to be proper?

00:36:53.543 --> 00:37:00.606
I mean, I'm sure any new change, any new process there's always, you know, change brings up some challenges and I'm not saying that it doesn't work properly.

00:37:00.606 --> 00:37:03.974
Some people will forget, possibly, how to do a process.

00:37:03.974 --> 00:37:06.500
But how can you push into that go-live?

00:37:06.500 --> 00:37:15.530
Because I've seen go-lives stall because someone will say we're not ready, but we're not ready because of something new.

00:37:15.530 --> 00:37:25.061
It's a matter of, okay, I'm not comfortable and ready to go live because I'm afraid versus it's not ready.

00:37:25.061 --> 00:37:33.536
It's one of those things that I see often and it's like well, we have to delay it for a week, we have to delay it for a month and I have some questions.

00:37:33.536 --> 00:37:35.902
I ask for that, but I wanted to hear everybody's thoughts on that.

00:37:37.063 --> 00:37:52.849
I love what you're saying there, brad, because being afraid and not ready are two different things in my opinion, because you can be ready and you have everything you need to have a successful go-live, but for some reason, they just have this fear of change.

00:37:52.849 --> 00:37:54.766
Now this change is going to happen.

00:37:54.766 --> 00:38:07.047
I'm really scared, like, for example, I mean Brad you hike and Nelly you're out in the woods just like me, and Patrick you're in Atlanta.

00:38:07.047 --> 00:38:08.585
It's a jungle out there.

00:38:08.585 --> 00:38:21.693
You know, you're prepared, you have all your stuff ready to go, and then, right when you're about to leave, you still have that nervousness, feeling of like I'm not sure if I want to hike this thing.

00:38:22.679 --> 00:38:23.221
And bear is going to get me.

00:38:23.240 --> 00:38:26.809
That's what I think Exactly, still have that nervousness, feeling of like I'm I I'm not sure if I want to hike this thing and exactly you can be prepared.

00:38:26.809 --> 00:38:30.362
You know you can have a bear, mace and stuff like that, but you still have that fear.

00:38:30.362 --> 00:38:42.233
Um, but preparedness and fear is I like that's two different things and I see that all the time, um in implementations yeah, definitely from a user perspective.

00:38:42.360 --> 00:39:06.929
Like it's like you're coming up with excuses not to go live because you just like, oh no, no, this has to be done first and it's that's such a critical distinction and if you think, like personally, in personal lives and personal changes, you know this is what you have to do, but you try to come up with reasons not to, because it's a change and it's scary, um, and that just translates directly into workplace changes too.

00:39:06.929 --> 00:39:12.650
We, or you'll find like people will come up with things at the last minute just because it's so close.

00:39:12.670 --> 00:39:24.990
We're that close, yeah yeah, it could just be one person that's making that decision too, and then they may be afraid to make the decision for everybody you know, especially if you're the decision maker of go live or no.

00:39:24.990 --> 00:39:28.385
Go live, oh, I gotta decide this for all the departments.

00:39:28.385 --> 00:39:29.568
That's a scary feeling.

00:39:29.608 --> 00:39:40.025
That's, that's fear, yeah you have to find a happy balance between sorry I don't go ahead, go ahead no, just the balance between making a decision and also considering everyone's perspectives.

00:39:40.025 --> 00:39:40.505
At some point.

00:39:40.505 --> 00:39:46.780
Someone has to make a decision, you know, otherwise we're stuck in eternal limbo and analysis, paralysis, whatever.

00:39:47.101 --> 00:39:58.083
So somebody has to make a decision in light of everything at some point well, and to go back to something you said earlier, nelly, this is what we would classify as that organizational, like that sponsor, right?

00:39:58.083 --> 00:40:01.028
Um, somebody has got to make the decision.

00:40:01.028 --> 00:40:08.315
I hope he doesn't watch this episode, cause he's going to know who I'm talking about.

00:40:08.315 --> 00:40:08.739
But I worked with a.

00:40:08.739 --> 00:40:21.710
I worked with a COO who knew nothing about technology kind of didn't understand all of the nitty gritty of operations, but knew how to drive business initiatives forward.

00:40:21.710 --> 00:40:27.512
And I remember this is actually right in the middle of lockdown, like we were in the middle of implementation.

00:40:27.512 --> 00:40:41.934
We were two weeks from go live and then all of a sudden, the country shut down, um, and he rallied the troops, quote unquote, and said it doesn't matter, you know, hell or high water, we're going live.

00:40:41.934 --> 00:40:59.985
He was actually one of our biggest detractors at the initiation of the project and then, as he got into it and recognized the value add to the business, you know, he said, regardless of what's happening within the world, regardless of what's happened during the course of the implementation, we are going live on this date.

00:40:59.985 --> 00:41:19.659
And he championed that across the board with his users, to the extent of literally like sitting down individually with everybody when they voiced an opposition to the go live and then championed the process and just the fact that you've got to do it right.

00:41:19.920 --> 00:41:24.552
Because, you know, we talked a little bit about the fear of, of kind of transitioning Right.

00:41:24.552 --> 00:41:36.771
I think the best kind of implementation that that fear is transitioned to like the, the heightened anticipation of like doing it right Everybody's a little excited to take that jump, even though they know it's scary, right.

00:41:36.771 --> 00:41:46.047
The best kind of implementation is when, as a partner, the best kind of implementation is when, as a partner, the best kind of implementation is when your end user is like can we go live on this date, like we're ready?

00:41:46.047 --> 00:42:02.972
Um, and I, you know, I think, hopefully, chris, you've had at least a couple of those, because those are really gratifying as a partner, where you're like I've done a good job, like I've been a very great champion for the, the system, and my customer feels ready, like because cause it's, it's like having a kid right, going out in the world.

00:42:02.972 --> 00:42:06.125
You're like okay, you're ready, yeah.

00:42:07.067 --> 00:42:09.492
Yeah, absolutely, it was very similar.

00:42:09.492 --> 00:42:11.505
Yeah, it's, it's.

00:42:11.505 --> 00:42:31.423
It's one of those things where I had a similar situation as from a partner's perspective, we went, you know, a client wanted to go live they're manufacturing, you know, manufacturing, you know, and and it was during covid, so it was very difficult to fly anywhere and be on site went live all remote, not stepping foot, and I was scared.

00:42:31.423 --> 00:42:34.509
It's like I'm not there to like hold our hands.

00:42:34.509 --> 00:42:47.300
But we did all virtual and and you know I I worked with somebody on the other end that we were both ready and our mind, our time, it's going to be dedicated to this and it went smooth.

00:42:47.300 --> 00:43:07.130
And then, like you said, you know, it's like it's an amazing feeling to see them flourish and be able to just run the system and not be, you know, not have to wait because COVID was happening and they weren't sure if they can run this application.

00:43:07.130 --> 00:43:08.505
No, they're just like let's do it.

00:43:08.505 --> 00:43:15.748
Chris got our back, we could do this, and then it was amazing and those kind of implementations are fun.

00:43:16.123 --> 00:43:21.931
It is important to put as part of the implementation, with the fear of it, as you're all talking about.

00:43:21.931 --> 00:43:30.070
Sometimes the fear is they're just afraid of the new system and I've even come across where requirements that surface.

00:43:30.070 --> 00:43:38.873
After they start using it and they become comfortable with it because it is new, they realize that they don't need that change any longer.

00:43:38.873 --> 00:43:44.918
Because I remember working with a, an organization.

00:43:44.918 --> 00:43:52.161
They're going through implementation, someone's going through, and they said they always would say, well, in the old system we would do this, well, in the old system we would do that, in the old system we would do this.

00:43:52.903 --> 00:43:59.844
And I I heard that proverbial like five years later you know it's, they're still talking about it and it's just like, well, whatever.

00:43:59.844 --> 00:44:09.373
But after they started going through the process this was an organization, they went through an acquisition and they had to look at the system that the company that they were acquiring was using.

00:44:09.373 --> 00:44:15.960
And then I heard that same individual say, well, they have to do it this way, we get to do it this way.

00:44:15.960 --> 00:44:32.697
You know, it's like the mindset shifted because it all comes back to that fear of change, the fear of doing something new, and then realizing, well, it wasn't so bad looking back at it.

00:44:34.561 --> 00:44:39.552
But how do you embrace that fear to push someone over the edge?

00:44:39.552 --> 00:44:42.909
I mean, I've asked the question sometimes where someone said, well, we need to delay a week.

00:44:42.909 --> 00:44:51.507
And I would ask okay, if we delay a week, what will change from Sunday, the day that you wanted to go live, to the next Sunday?

00:44:51.507 --> 00:45:03.903
If you're going to have some in-depth training or testing or somebody's going to do everything, then delaying a week may be advantageous because you're going to do something and have some productive results.

00:45:03.903 --> 00:45:11.148
But if you're just delaying it a week and everyone's going to do their same duty and you can pick the time frame, what do?

00:45:11.148 --> 00:45:11.911
What's the?

00:45:11.911 --> 00:45:21.710
You know what's the the rationale for going uh later, other than fear yeah and I wonder too.

00:45:21.731 --> 00:45:24.655
How much sorry, pat, go ahead oh I was gonna say.

00:45:25.315 --> 00:45:31.771
I don't know what your guys experience has been, but this is um, this has been my experience previously.

00:45:31.771 --> 00:45:40.599
Um, if you are willing to delay a go live one time, it is more likely to happen again and again and again.

00:45:40.599 --> 00:45:48.579
There will always be this continual understanding of oh well, we can just keep delaying, rather than creating some immediacy of no, you need to get live.

00:45:48.579 --> 00:45:57.126
Like, there needs to be a definition of done right, minimum usable product, go right.

00:45:57.126 --> 00:46:08.525
But I have seen end users and I've been guilty of it as an end user right, it's the don't let perfect be the enemy of good enough.

00:46:08.865 --> 00:46:26.449
Right like, um, if you're going to keep delaying and yeah, if you're going to keep delaying, you you will get into the habit of understanding like oh well, I can just introduce new scope creep and as a partner, you know we're here to literally help you through the process.

00:46:26.449 --> 00:46:27.358
So we're going to say yes to a lot of things.

00:46:27.358 --> 00:46:28.525
Right, yeah, we'll help you do that.

00:46:28.525 --> 00:46:37.626
But we've got to also say yeah, but is that in the best interest of the implementation and your team and your budget and your timeline and your sanity right?

00:46:37.626 --> 00:46:46.148
Like, at some point we have to get that minimum viable product and go live and say do it, and then we'll refine later.

00:46:48.032 --> 00:46:52.402

Nelly Jebran

Senior Global IT Project Manager, Protective Industries Inc.

Nelly Jebran is a Change Management and Project Management professional from Toronto. She has successfully facilitated numerous initiatives, and has a special fondness for Business Central implementations. She is Prosci and Lean Change certified, has a Master of Arts in Political Science, and has led global sales and customer service teams. Nelly is passionate about working with people to bring about meaningful change. She has developed a unique approach to change management that aligns technical solutions with business requirements while foundationally supported by people engagement.