5 Reasons Your ERP Project Falls Apart Before Go-Live

Nirav Shah (00:00.014)
Season four, we get better at it.

Peter Nicholson (00:09.43)
Well, we're recording, not actually live. Not that good yet.

Nirav Shah (00:16.046)
We are live. Oh, we should have to set up a meeting later on this week when you guys get a chance to talk about that Ben appearance that we're having next week,

Peter Nicholson (00:30.262)
yeah.

Nirav Shah (00:32.43)
So, I talked to that. He filled out the questionnaire.

Peter Nicholson (00:44.8)
Ready?

Nirav Shah (00:53.806)
Cough

Peter Nicholson (00:58.098)
system now.

Nirav Shah (00:59.118)
Hahaha!

Peter Nicholson (01:03.228)
And welcome back to the ABCs of ERP and Beyond, the podcast that cuts through the noise and gives you the real story on ERP systems, particularly for manufacturing and distribution businesses. And today we are getting into something that I think is probably one area that can be overlooked when we're talking about ERP and the ERP space, and that is the project management side. So you might be thinking project management, really, but...

We've seen it time and time again. Companies can spend months and months selecting the right ERP, go through procurement, get the approval, sign the contract, get excited, and then the project starts to fall apart. Not because the software was wrong, not even because the consultants were bad, but because nobody had a proper grip on how the project was actually being run. today, Nirav and I are joined with Emily. Like we have...

really enjoyed the conversation we had last time. So the three of us are back on this and we are going to be discussing what good ERP project management actually looks like. Everything from structure and planning all the way through to keeping momentum and getting things finished. So stick around because this one could be a genuine episode that could help save your project. So without further ado, welcome, Nirav and Emily.

Emily Browning (02:26.814)
Hello.

Nirav Shah (02:27.214)
Happy to be back. Emily, nice to have you back again and share this. You're definitely the de facto expert on the project management side. You're running a number of different projects, excited to hear your thoughts on project management. We've done this on our side. We do this every day, but we do it from a partner perspective, right? And we do it where we try to provide, just to keep the project moving, try to provide best practices for the project.

but there's obviously a lot more in project management outside of just what we do. On the partner side, there's a whole customer aspect of it and how customers need to manage their own internal teams and how two teams come together properly to manage the overall success of the project. So super excited about this. There's so many different ways these projects take on their own life, hoping that today we could share best practices and at least a framework.

If you're embarking on this type of project right now, an ERP project, like where should you start? know, what type of teams you start developing? You know, what are the major phases? You don't go into this project blind at the end of the day and you're kind of well prepared to manage some different tasks to make it successful.

Emily Browning (03:45.323)
Well, thank you guys for having me again. I had a lot of fun last time and I would think project management is probably my favorite subject to discuss. I think it's relatively simple in a way. It's following a structure and this is really relevant to any project. It's not just ERP. I think probably what we're going to talk about will be applicable for anybody who has a project that they're leading and maybe thinking, well, where do I even start?

And frankly, it is pretty easy as long as you make a plan and stick to it. So that's, I think, what we will be getting into.

Peter Nicholson (04:23.606)
All right, let's kick off straight away. guess we'll start from the top. Making the plan, I guess. To me, it's almost like it's the same thing as you said with any project, whether it's even, you know, a home renovation project. So you're building extensions to the house. You wouldn't just get the builder and you selected the builder. You know what bricks you want. You wouldn't go, I'll start building walls then. You know, you'd actually need some kind of structure around it. So I guess let's start with the whole idea of how we start building out this kind of plan.

project plan in terms of the structure behind what we need to put in place.

Emily Browning (04:59.776)
Yeah, so putting a structure together is so, important. And I think to your analogy, there probably are some people who just go buy some bricks and start seeing what happens. So my recommendation would definitely be not to do that. And it can be exciting to want to get started. And if we go back to normal kind of projects, IT projects, business projects, whatever, you tend to...

pick them up with some kind of an idea of where you're going, goal-ish way you need to start, something you need to do, and you could just get started. You know, know you need to start gathering requirements so you can just start Googling, but the suggestion here, the recommendation here is that you stop, step back, and bring some structure to the project, plan out everything, essentially.

And I think there's two parts to it. One part is sort of the actual planning of the project itself. But what we're talking here is giving structure to sort of the background of the project. So what problem are we trying to solve? What is the goal? Who is involved? Who needs to be in those roles? What are the responsibilities of these roles? Who are my stakeholders? What is the project governance? What are the project phases? What are the risks?

Do all of that first so that you really understand what it is that you're doing, so that you don't get started, find yourself some way down the line and realise you've forgotten something important or you didn't involve somebody important.

Nirav Shah (06:37.922)
Yeah, I think that's super right on. Structure, going back to Peter, your analogy is the foundation. You got to lay down the cement or the concrete first to build a house on top of it. And this is all this stuff happens, I feel like even before you go out to look for an ERP system, you are putting this plan together and structure being the first thing is like you mentioned, Emily.

some really, some great points you hit the nail around the head is roles and responsibilities. We get this question all the time, believe it or not. That's even after they selected the software is, who should be part of our project team? Who do you think that we should have, you know, in our sales management meetings? I mean, who do think we should have in our purchase management meetings, right? Who do you think we should have in our planning or shipping? And I tell the customers like, yeah.

You should have your SMEs in there, obviously, but are they even the right people, right? Like you have subject matter experts, fine, they know your business now, but who is that visionary or who is that manager that will actually take the step or step into a role that is gonna help bring the business forward with this investment that you're making with an ERP system, right? Maybe it's not that person that's doing purchasing every single day.

that understands how to create purchase orders, how to go ahead and communicate with your vendors. Maybe you have that one person that is looking at this from a future state perspective, what improvements can be put into it, or what background do they come with technology that they should be the better party to be part of your steering committee at the end of day, right? That is going to be providing the vision of what they learn.

and the decisions you make in the ERP training that then comes down to the folks that are going to be doing the actual work, right? So we get this question all the time and from a partner perspective, sometimes a little difficult to answer that. Like, hey, you need to have this person, we don't know these people's background, right? Every single one and what they're exactly doing day to day. This is where customers need to take almost like, I feel like,

Nirav Shah (08:55.886)
six months prior to even going out to the market and looking for ERP software, like who's gonna be our dream team over here? That we're gonna assemble this team that's gonna keep the structure in place so when we get the software, we're gonna implement it correctly because let's face it, these implementations, these ERP projects, the project's, the system's installed, you're not changing again for 25, 30 years. So that person,

that's in that seat, that's in charge of that particular department, should have that same vision, that this is a 25-year vision that we're putting together for this project, not just for putting in orders at the end of the day.

Emily Browning (09:38.677)
Yeah, I think we can maybe talk a little bit more about maybe the different types of roles, because I think also a lot of people, especially if you're a smaller business, you might struggle to think, okay, well, you know, all of our teams are quite lean. So do we just bring in everyone? And then, you know, as one person, this role and this role and this role. And I'd recommend you try to have as much separation as you can. But maybe we can dig in a little bit to the specific roles that you would have in a project. So I think

Nirav Shah (09:43.203)
Yep.

Emily Browning (10:07.648)
maybe first of all you need the right person to be a project manager. And sometimes I certainly see maybe the wrong person being suggested. You want somebody who knows how to manage a project for one, which is kind of what we're getting at here with this session. isn't rocket science. So someone who's interested and enthusiastic and wants to do a good job, well, you know, is probably good enough as long as they'll do...

as long as they'll do the research. yet you want somebody who's capable of kind of pulling everyone together. And there should be someone internal, I will add. You'll have a project manager from your vendor, most likely, but you can't rely on that as the only one. You need to take responsibility for it internally as well. And you should also consider what part of the business should they be from. And I don't think there's a hard rule there. It really depends.

but then I think you'd want them to know their limits, I suppose. you might think, well, you know what? Let's say we're doing an ERP migration, then maybe we want our finance manager or our controller to be the project manager because finance is the backbone of the ERP. So it makes sense that that person is managing our project, which is fine and totally valid. But then you would consider that if you have technical expertise,

maybe you want someone in IT to be your project manager, or maybe you at least want your finance manager to know their limitations and know that they don't know the technical, they don't know code or how that kind of thing works and therefore they're at least asking the right questions of the people when they don't know something. So that's not me attacking any particular role.

But that's what I mean. Consider who it is and what their skill set is and if there's something missing and there will be for most people who then should also be there supporting them. So you have your project manager and then you'll be trying to work out what Nirav was just talking about, which is, I have my key users. These are the people who

Emily Browning (12:19.454)
We'll be testing the software, giving feedback, being there as we do our discovery phase of the project, our requirements gathering. They're the people who can tell us this is what we need, this is how it works day to day. But you don't need everyone for that. So who are the right people and have you got people from the right departments? I think it can be common to miss out departments and I would say don't, don't do that. Bring them all in.

Not everybody from those departments, but make sure you have that representation. On top of key users, might have workstream owners, which is somebody who takes particular responsibility for an area of the implementation of the finished project. Nirav, you might have some insights here on different types of workstream owners, maybe. I'm thinking...

You could do it by department, could do it by flow, such as order to cash. What's your experience there?

Nirav Shah (13:21.324)
Yeah, we call them the work stream orders. We basically call them power users. And these are the folks that, whether it's departmentally led or it's organizationally led, the whole thing. And they are the gatekeepers of everything, end-to-end, order to cash, receivables and payable side of it. And they workflow it all out. They understand the whole system. And therein lies really the ROI of a project, from my perspective. It's because now you have that one person.

that understands everything and there's less dependence on the vendor. I think that's a separate conversation, but that workstream owner, I think, is the X factor. You put the right person in that seat, they could really supercharge that implementation and get things rolling. Whereas a partner can't. partner's not going to be there eight hours a day at the client site while we're working with the customer, but these workstream owners can. These power users can, because they're going to be digging in. They're going to be sitting in every single meeting.

you're gonna make sure that everyone could do their job correctly, right? They may push back, right? On either side, on the vendor side, on the partner side, or the customer side. So yeah, I think that's super important. I think that piece of it, doesn't get talked about enough. it should be a requirement, literally in my mind, that every ERP implementation has one or two power users.

I think nowadays, because everyone, everything's so fast-paced, nobody has time. Let's face it, nobody has time for these projects at all. But if you get somebody that's dedicated to this project and that's all they do, right, and become the power user, I think we'll see a lot higher success rates than what we're seeing right now in the ERP space. Like there was a Gartner study out there, probably, you know, this is a sidebar, like 75% of ERP projects are failing right now because

Because even though the organization needs ERP, they buy ERP, the end users don't have time to implement successfully.

Emily Browning (15:22.463)
It makes total sense. Go Pete.

Peter Nicholson (15:22.999)
I

I would also say with that when you're doing that is you should really make sure that you are communicating with these people and saying how much time they're expected to commit to the project in the first place. I think once you've defined a role and you say, right, you're this, it could be the greatest person and enthusiastic but if they don't know how much time that means in commitment of, how many hours per week, then it's not going to for them. It's not going to be seen as a role. It's just going to be seen as a liability to them. And how the hell am I going to fit?

Nirav Shah (15:54.178)
That's right.

Peter Nicholson (15:54.705)
this into my week. So I think it's works both ways. One, yes, identify that right person, but you setting up this team need to ensure that you communicate what's kind of expected to from them from a time commitment point of view.

Nirav Shah (16:08.162)
Yeah, yeah, absolutely. then, know, kind of just, you know, rounding out the structure phase of it, setting up cadences, I think is important on each side, making sure you do a project status call every week, if not maybe twice a week when you start the project, right? Those are super important. Those have to be taken seriously. Oftentimes, I get into these cadence calls and I'm sitting there like, they just want, the customer just wants to get off the call. Like, they don't even want to discuss any risks that are going on right now.

Until it gets too late and now you're closer to pilot test, you're closer to goal of like, okay guys, we've been talking about that. We don't have your chart of accounts finalized. How are we gonna go live? So it's really important to take that super seriously. Put that up in the structure. The governance of the project is super important. What is the guardrails here? How are we gonna make sure that something doesn't come out of left field and totally snowball this project in the wrong direction?

Let's hold off on the merger that we're planning to do until this ERP project's done. If you're planning to do a merger and you're doing the ERP project, well, hey, that may screw this up. That's gonna be a big risk. So have those safeguards in place. Think about all that type of stuff. you just focus. You have to have a singular focus on the.

Peter Nicholson (17:27.446)
All right, let's move on because we've got a ton of stuff to get through. Structure, we'll put a tick in against that and we'll probably come out with a full episode that starts to split out some of those. We can go a little bit more into detail. But for now, let's move on. Number two we've got down here is project planning. actually listing out the tasks, what we're going to have to do, when, what the phasing is of those. And another point that we've got right next to it is avoiding scope creep.

I want to call that out because that's just as important as setting the tasks right. What is a task and what definitely isn't the task and not to get sidetracked with. So who wants to kick off with project planning?

Emily Browning (18:08.01)
I'd love to kick off. Yeah, me, me, me.

Nirav Shah (18:08.794)
I go ahead. I'm gonna kick good kick it off. Yeah, I have I have I have this saying that I say all the time. I can't wait to say it when it comes to planning. So it's a sports reference. But Emily, please continue and then I'll put my unnecessary comment in right after that.

Peter Nicholson (18:10.039)
You both put your hand up.

Emily Browning (18:27.2)
Okay, so throughout my entire career and even when I was at university, the first thing I've ever done in any kind of group project, I think we all have that experience in university or college, we're in a group project and nobody knows what they're doing or you find you're the only person doing all the work or half the group are doing the work and the other half are down the pub at the bar, whatever, they're not engaged, they don't know what's going on and I found that same.

scenario sort of applies into our working lives as well. So stepping back and planning out the whole project as best you can is just so valuable for understanding how it's going to go, how long it's going to take, what do we need to consider. And I will say I get pushback on this a lot when we think about, especially a big project, if we're talking about an ERP.

migration or implementation or lots of other ERP type projects too. Maybe you're implementing a warehouse management system or you're bringing in an e-commerce site, whatever. Those are big projects. take months and months, sometimes more than a year, depending on what it is. And you could be sitting at the beginning of it before you've even done your requirements gathering, your discovery phase thinking, well, I don't know what's going to come.

So I can't do that. But I would argue, no, you can do that. You know that you have your discovery, your requirements gathering. You know that there's a period of time for that. can think about, well, you know, we need to, what do we need to identify? You've got your gap analysis. What departments do we have? What processes do we need to cover? Whatever. You know which things you need to tick off within that requirements gathering phase. After that, there's some kind of solution

design, what are we actually going to do? Maybe that's the point at which we're choosing the software. What do we need to do there? Do we need to start engaging vendors, get demos, that kind of thing? We know that takes time and then we know we need to make some kind of decision at the end of that. Maybe we also need financial approval and that can take weeks or months. It depends on the type of business that you're in.

Emily Browning (20:44.787)
Following that, you're going to have a kickoff and the development and testing phase, which is probably the longest. But again, you have a concept, know which modules, which areas need to be developed. You've already done your gap analysis, so you know a customization or a process needs to be developed for X, Y and Z. And you know those things need to be tested and you know they're not all going to be right.

So there's testing, there's redeveloping, there's testing again. You can assign time to all of that. And then when you're done in terms of that development and initial testing, then you've got things like...

Data migration, which you probably should have already been working on at that point, but then you've got maybe the real thing. You've got your user acceptance testing, which you know takes a bunch of time, and you can plan that out. Are you doing control room pilots? You can put all of that in this plan, and then you have your cut over, your go live plan, your go live weekend, go live week, hypercare period.

I'm talking about a mythical project here, but I can already say all of that. No, I don't know exactly how it will all go, but I can make some assumptions and it's really valuable to go through that.

Nirav Shah (22:03.584)
Yeah, I think all those are right on points. I think those all apply for regardless of the type of software technology that you're implementing, right? So if you're doing ERP right now, you're doing CRM right now, you're doing, you know, what have you, whatever systems you're implementing right now, think those are all valid points. My unnecessary comment that I was actually going to say is, Mike Tyson has a famous line. Everyone has a plan until they get punched in the face.

The idea behind that is how firm is your plan? How many different angles of different things that can make the plan go array have you thought about? In order for this plan to actually work at the night of the day, structure was probably one of the biggest elements of this, you need to have the right structure.

I think it'd be naive for anybody that's taking on a project to think that you're not going to build in different rework phases, different maybe revaluation areas, or multiple checkpoints. You can't go, you shouldn't go more than three weeks without actually seeing something in the system. So you need to have the plan has to be so solid that

It's taking account of anything that could come inside the plan and kind of like start diluting its effectiveness at the end of the day. So I feel like, you know, sometimes plans are created just for the fact that we're checking off a box. Now we have a plan instead of keeping the plan as like, we don't do a conversation unless it's actually a line item on the plan. Right now, maybe that's a little bit too much, but

Emily Browning (23:56.8)
Mm-hmm.

Nirav Shah (23:59.306)
If it's a major milestone decision, right? If it's something that we need to track, right? That should be on the plan at the end of the day. It has to be fully organized. I think everything, what you said, Emily, is super spot on. I've seen in our experience being a partner, but the part that I see where this fails is that the plan isn't taken seriously.

It's unfortunate a lot of times when that happens. So anyone out there that's listened to this episode that should be like You know, the only way you move forward is with the plan and every step of the way you go back to the plan

Emily Browning (24:42.164)
I think that's a really good point and probably something I would take for granted. But yes, absolutely. If I was doing any kind of project meeting that you're doing your weekly or bi-weekly project core team meeting, we're not just there having a chat. I'm not creating a new PowerPoint for that. I'm not coming with an agenda of bullet points. I'm opening up our project plan and we're talking through those points. that's the only way I would ever recommend.

anyone do it because then it keeps everything also in one place which is useful. But then it keeps it productive, it means you're focusing on exactly what you need to be focusing on. You know, don't need anyone raising their hand and saying but what about this thing because there it is, it's down there and it's not for four weeks time so we don't need to spend our time talking about that in this meeting. And I really think that kind of helps a little bit of the team morale as well because then the whole project doesn't feel like you know this mountain on your shoulders.

It's these five items that are live and maybe these three that are coming up in the next week before we meet again. I think it's really, really useful from that perspective.

Peter Nicholson (25:48.557)
I think also because you're going to have people in the room that aren't, this may well be their first ever project, this may well be the first time they've even been in the room with all of the people.

from the business as well. I think doing that and having that as the guiding light also gives them some consistency and familiarity. There might be people that are subject matter experts that have been nominated and pointed out as yes, you are a power user, but that doesn't necessarily mean that they are immediately comfortable being in a room with 10, 12 other people looking at this project charter and project plan up with all of these to-do lists. think if they know

over time as you go through it that they know the cadence of the meetings, they know what to expect. Of course you're never going to get that if you go in every single time and this week we've got a PowerPoint presentation to talk about this stuff. Next time we've got some kind of Excel file to look at. Next time we're pulling up emails of what's happened since the last time we met. I think if you have that consistency of let's just go by the project plan, here's the tasks, here's what's coming up, here's what's done, that starts to get

into the habit of, okay, I know what I need to bring to this meeting. I know what's coming up. I'm starting to feel more comfortable. I'm starting to feel like I am integral to the project and the team itself rather than I don't even know what to expect. I don't know before I walk into that room. I don't know what I'm going to see. All right, here's a debate.

Emily Browning (27:15.349)
Mm-hmm. Fight.

Nirav Shah (27:15.426)
Yeah.

Peter Nicholson (27:21.504)
Who wants to go first? I was going to give you a debate point.

Nirav Shah (27:23.566)
I was just going to say that I was just going to say if you do this well it doesn't matter what project you take on in the company. I think this just sets any business up for success to take on complicated projects.

Emily Browning (27:32.63)
Mm-hmm.

Peter Nicholson (27:39.288)
Alright, second half of this I want to say though. Go on. I'm gonna have fun editing all of this I tell you.

Emily Browning (27:44.033)
I just wanted to spotlight something that I have touched on, is the idea that the plan can change and things go wrong, because that's really important to keep in mind too. So you have your plan and it's fine if not everything goes exactly as you expected. That's sort of the idea of, you know, agile project planning.

Nirav Shah (27:47.138)
You

Emily Browning (28:10.624)
being available to change as and when things come up. I plan for that because it will happen. So I would always plan in some kind of buffer plan in the worst case scenario. For instance, if you were doing a customization and you're not really sure how it's going to go, know, worst case scenario, maybe it takes, you know, eight weeks to complete and it's a...

$15,000 customization, but best case scenario, you know, if we find out where, we're able to do it in this more simple way, could actually be done in two weeks and, you know, not really cost much at all. I'll just plan for the worst or put a buffer in for the worst so that I can also then convey that to the team or to any of the stakeholders, we're able to show, you know, here is our plan. This is the buffer for things going wrong.

We can eat into that, that's fine. Here's where we predict it may happen. And that's fine. That's what's going to happen. There's no way your project will follow exactly the plan you created in the very beginning. It's expected. So just plan for it.

Nirav Shah (29:23.064)
Yeah.

Peter Nicholson (29:23.928)
Alright, I'm going to add on to that point.

Then on top of that is plan for it, but make sure that the time isn't used up because You know Tim isn't available for the workshop or this person didn't find time during the week to do it So it's fine. We've got some fat we can just use it for that I think there's some parts of the project that are simply non-negotiables that you just have to turn up you have to make time for it and That fat isn't there just because you didn't feel like doing whatever tasks you

had to do.

during the two meetings, because that time can easily be eaten up and that time when you actually need it and you stumble across something that's regulatory or something that's non-negotiable for your business, now you've got to find even more time to work on that customization and that's what you can't afford. Don't get comfy because you're built in the fat, it's there and it's serving a purpose, it's not there for, I just didn't feel

Nirav Shah (30:27.438)
Exactly.

Peter Nicholson (30:27.716)
like it. It's fine. got some extra time. Talking about that then a debate point for you though scope creep then if we were talking about that stuff where people do get excited and they're like great I love the task have we thought about this what about this can we add one more thing for you two, because ones on the partner side ones on the client side here debate point for you would be who is responsible for that.

Emily Browning (30:31.339)
this.

Peter Nicholson (30:55.678)
Is it the business and the client asking or is it really on the consultant to be pushing back who owns Scope creep or is it both?

Nirav Shah (31:07.118)
I've never heard of him exactly.

Peter Nicholson (31:14.624)
Never happens. Never happens in any project.

Nirav Shah (31:14.99)
Yeah, it never happens. No, good. Great point. These projects are living breathing entities at end of the day, right? Let's face it, customer or the client has been running their business for much longer than we've engaged with them as a partner, right? They know their business a lot better than we do at the end of the day. So we try to uncover everything as much as we can on the sales cycle.

for instance, and that's really a matter of how open the customer is, how much already homework they've done in terms of their business process flows, documenting, understanding their gaps, coming prepared to an ERP evaluation meeting. We rely on that heavily, right? I we could ask only so many questions as we're trying to understand their business, but we'll also kind of make some assumptions along the way. Like, okay, we know that

If you're looking at, if you're having some inventory control issues, that's most likely due to, maybe you're not vouchering your receipts potentially correctly. You're not doing a three way match or something along like that, right? Or landed costs is not a factor that maybe you need landed costs to get accurate inventory control or costing. So we could make some general assumptions at the end of the day, but things like that happen. And what I always refer back to when I tell our team is when scope creep happens.

Number one, you have to have a conversation. Don't ignore it, okay? Don't ignore it, because that's the worst thing you could do. Number two, is there a... So number two is how important is it? Is it a nice to have, or do we need it, right? At the end of the day, whatever the change is in functionality. And is there an out of the box functionality for it, or do we have to do a customization?

We have to gather all of this information first to really even realize is it a scope creep for phase one or is it something that we're gonna do in phase two? Sometimes to ring the alarm too early, right? People may feel deflated and say, my God, we didn't think about this or holy cow, we need to pause everything. Well, that's sometimes not the case. Let's go to our structure of the project. Let's go to the steering committee. Let's talk about this.

Nirav Shah (33:34.99)
from a common sense perspective and let's make the best decision for the outcome of the implementation, whether that's phase one or phase two. So you have to be careful who you mention that is this a scope creep or not, right? Because you actually need to have this decision with the actual steering committee on the impact of this scope creep before we call it a scope creep at end of the day, right? And then if it is something that we have to do phase one, let's plug it in there, let's all come into agreement exactly what we're doing here.

to keep the project moving forward, and something we're gonna talk about later on, so we don't stop the momentum. Because that could easily be momentum killers, and next thing you know, the project's on hold, everyone's discussing internally for things that maybe are five minute conversations, right? That's why it's important to go back to the structure, so you can make the decisions quickly and keep the project moving.

Emily Browning (34:26.005)
So this won't be much of a debate because I'm in complete agreement with everything Nirav just said. But I'll add a couple of comments from sort of the business side, the client side. Ultimately, I believe it's the business's responsibility to ensure Scope Creep doesn't happen, particularly me as a project manager or a program manager. It's my job to make sure we're on top of that. And I guess there's two ways to avoid it. One is by...

Nirav Shah (34:31.214)
Ha

Emily Browning (34:54.045)
involving all the right people at the beginning and making sure they understand what we're doing when we're doing our requirements gathering so that we don't realise something later that we forgot. And then also it's keeping on top of those, can we just have this? How about it does this? Can it do this? Can I just, you know, can I just press this big red button and all of the work is automated and it makes me a cup of coffee at the end because they'll ask for that. And so to Nirav's point about what he would do from the vendor side,

that's what I'm looking for in a vendor. want to get value or I see it as a very valuable trait in a vendor. If they can support me in that journey and kind of challenge back on my key users and my work stream owners as well when they're asking for that kind of thing, do we really need this? If so, okay, what is the right chain of command to go up to? also you could just have one key user say, yeah, I really want it to be able to do this.

and then your vendor goes away and does it and charges you for it. So you really want someone who's on top of that kind of thing. And then all of this, I would say, harks back to what we said at the beginning, which is putting all of that structure in place gives you this ability to say, okay, let's take that to the steering committee. Let's talk about that in the weekly project meeting. puts everybody on the same page with how to deal with that. And the only time I'd really accept scope creep

I guess is when we forgot something important, but you probably forgot something important because you didn't involve the right people in the right meeting or you scheduled that meeting at a time when they couldn't really engage properly, whatever. So I think you can definitely do work to avoid that kind of thing by making sure at the beginning you involve the right people, plan everything very well. And then it's asking that question of is this needed?

Nirav Shah (36:55.859)
Scope creep I've never heard of them. I'd love to meet them one day.

Peter Nicholson (37:00.717)
Love to be in your projects if you never have it. Great. I have less gray hairs. Point number three then.

Nirav Shah (37:05.742)
You

Emily Browning (37:06.954)
Thank

Peter Nicholson (37:09.421)
Visibility, so we're talking about project management. So it's easy to go, yeah, project management, it's all down to the project manager. But we know that if the project manager is the only person that really knows the status of the project, then you haven't got any visibility at all. You've probably got a single point of failure if it's just that person that actually knows the status of the project. So when we're talking about project management, let's break down what we mean by visibility, why it's important,

what increases visibility, what we need to do to increase visibility, and what we should avoid to keep our projects running and on track.

Emily Browning (37:51.565)
I can comment on it.

Peter Nicholson (37:52.077)
Good point number four.

Nirav Shah (37:54.014)
hahahahah

Emily Browning (37:58.85)
So visibility, think is, again, or I know is incredibly important. When I talk about visibility, what I would usually mean is making sure everybody in your project team knows what's supposed to happen, when it's supposed to happen and who's supposed to be doing it. If they can't see that plan, if they can't see their tasks.

they're not going to do them because they don't know about them. Maybe they have an email about it, but that's fallen under everything else that's going on in their day-to-day working life. So when I said that when I go through this project plan, sorry, my laptop's about to die. I need to plug it in. Where's the power cable?

Peter Nicholson (38:43.469)
We can cut out. Yeah, we can cut out.

Nirav Shah (38:43.498)
Yeah,

Emily Browning (38:51.587)
Bye.

Peter Nicholson (38:53.554)
I can finish off my Guinness now.

Nirav Shah (38:56.846)
Jealous. Would it look bad if I drank a beer at 11.30 in the morning here? You're right, Peter. Let me go get one.

Peter Nicholson (39:01.963)
No, it's fine.

Emily Browning (39:02.805)
It's 4.30 here.

Peter Nicholson (39:06.233)
You've had enough of the hard liquor, you need to get back to something.

Nirav Shah (39:09.538)
Yeah

Emily Browning (39:12.193)
I also think my headphones are the wrong way round.

Nirav Shah (39:17.308)
no.

Emily Browning (39:19.123)
Ugh. Everything's changed. Hold on.

Nirav Shah (39:22.284)
Hahaha

Emily Browning (39:32.161)
Right. Do I sound the same?

Peter Nicholson (39:35.384)
Yeah.

Emily Browning (39:37.739)
Good. Then we're fine.

Nirav Shah (39:43.918)
All right. Cool. We're talking about India cricket right now. They're in the finals. I think they might be winning.

Emily Browning (39:43.967)
Well, well.

Peter Nicholson (39:46.937)
You can just start from the top.

Emily Browning (39:52.734)
Okay, congrats!

Nirav Shah (39:57.112)
We're talking about visibility right here. And Emily, you're on a roll. You're on a roll there. You have some good stuff that you're saying.

Emily Browning (39:59.137)
Visibility.

Yeah, I forget it now. I will have to repeat it, so let me think for a second. Yeah, let's do it.

Peter Nicholson (40:05.721)
You're gonna have to repeat that.

Nirav Shah (40:08.942)
You have minutes. Yeah, all right. You want me to Okay, let me do it. All right, Peter. Let's camera action. Let me know

Peter Nicholson (40:17.197)
Yeah, go for it.

Nirav Shah (40:19.074)
Okay, so visibility, it's from a project perspective, there's a couple things here. One is I always feel anything visual is so much better for people. And here I'm talking about tactically what they see day to day. What are my green tasks versus what are yellow, what are red? I love the stop light approach at the other day. If there's anything, whether from a project plan perspective or

and open issues list, right? Where are we overall in the project with the stoplight approach and then assigning people? Super important. Now there's a lot of really intuitive project management tools out there and I think this gets underutilized. Us internally, for example, for our projects we use Smartsheet that has like conditional formatting where you could put, you know, green rows versus yellow rows versus red.

yellow red rose and that type of stuff and it automatically has you assign people to tasks, it shoots them an email, right? Shoots them a notification, which is huge. I think if you're not using that for this type of project, you should. That's gonna eliminate a lot of confusion, because these project management or collaboration tools are super robust. You could attach documents on there, all these different type of files. You could have like a running chain or thread of comments on single threads, which keep, you know, the

everybody aware of what's happening obviously. So I think that in itself is important from a visibility standpoint. And I think just looking at visibility from maybe a little bit more of the abstract sense is are you talking to the right people for your project? Are the end users talking to the key users? Are the key users talking to the steering committee?

you know, the power users or the power users talking to the steering committee. Oftentimes within that chain, there's breakdowns. So what the steering committee thinks is I have full visibility of what's happening on project, but hey, I'm sorry, you know, the key users haven't updated the project plan or they haven't updated where they are in their tasks. So really how accurate is that visibility at the end of the day? There has to be a full cadence on when people are actually updating the proper project documents to create that visibility and have that.

Nirav Shah (42:46.85)
that perfect 50,000 foot view of the project versus the 10 foot view of the project so you understand everything in between.

Emily Browning (42:58.283)
Totally agree. And on the business side of things, if I'm managing a project, I need to make that project plan visible. I need all of those tasks to be visible to my whole team, because how are they going to know what to do and when to do it if they can't see it? And I think as a project manager, that turns your role into more, you know, delegating out tasks, telling people what they need to do, chasing them by email, walking up to their desk, whatever.

And then that's not really the role you want as a project manager. It's certainly not how I like to do things. If you have your project plan visible and totally agree things like Smartsheet, monday.com, Trello, Jira, whatever, I think those tools are really, really good. It's a great way to contain everything. I don't particularly recommend using Excel and email in this day and age because it's great to have these kind of fully self-contained

project areas, but if you make that plan visible and it's what you use for all of your meetings, everybody knows what they're supposed to be doing. Everybody knows what each other is supposed to be doing. And that eliminates a lot of what you would otherwise be doing as a project manager, which is chasing people, telling them what they need to be doing, reminding them of deadlines. If you put that board up with their name assigned to it with the due date of yesterday, you know, in your

Peter Nicholson (43:57.572)
Mm-hmm.

Emily Browning (44:24.094)
project core team weekly meeting, you don't need to say anything because they have to sit there in front of everyone and explain why they've not done it. You don't need to say it. It's on the board. It's visible. And that's really, really valuable, depending on how you like to be a project manager. But I like to see myself as a facilitator of the team, making it possible for them to do this project really well, making it possible for them to collaborate.

I think is a great aspect of the visibility as well. If you can all see it, all see the plan, you will know exactly what's coming. And if we've forgotten something, you know, it's not on the board. you can, you know, that's the point at which you need to mention it. So visibility, ultimately on the business side.

tells everybody what they need to be doing when, and it holds them accountable without you as a project manager really needing to do anything other than bring them all into the meeting and share that project plan on screen. They'll talk about it. You might take us down the list and say, okay, we're talking about this. Now this one, how's this going? What's going on with this one? I can see it was due yesterday. What's happened? Is there anything we can help with? But ultimately it stops you from

chasing and kind of being the, you know, the big negative presence for everyone, you know, probably avoiding you in the corridors because you're going to come and chase them. It eliminates all of that and kind of puts it on the entire project team together.

Peter Nicholson (45:54.447)
Yeah, it's so funny because listening to you to talk about the both of you about the different tools there. It's just shows how powerful having a single shared source of truth is. And I think it's almost like you could say it's good practice if you are going on to your first ERP. Once you start to see the benefit of the team coming together, we're all looking at the same sheet, we're all working towards the same tasks and the same end goal. It's exactly the same.

an ERP is powerful because it is that single source of truth. Everyone's working from the same foundations, using the same tools, seeing the same information, and hopefully pulling in the same direction. I think it's almost, you could say that this is good practice for those end users once they actually get into the ERP and they're all using the same single system just like they did during the project. Point number four, because we're rapidly running out of time.

and we need to keep the momentum going. So point number four here, keeping momentum and finishing the project. I would say this, well, all five points we've got are critical.

But I would say this one is definitely critical and would seriously harm how successful Go Live is. Because I don't think an ERP project really fails at Go Live. It probably fails months before, but you just didn't notice, or you didn't want to accept it when that kind of mid-project slump comes. People are suffering decision fatigue. People are panicking. People are dragging their heels. Things aren't being

called out and dealt with. So when we talk about keeping project momentum, one, what do we mean? Two, what things should we look out for? And three, how do we deal with them?

Nirav Shah (47:52.108)
Emily?

Emily Browning (47:53.375)
Yeah, I think there's two parts to it. One of the first part is around the flow of the project. And I think, to be honest, we've touched on a lot of it with that visibility piece. And the cadence from the structure. If you're having the meetings, you're making the plan visible. It's probably going to flow quite well. But I think Nirav had some good points on that. And then the second part of it for me would be around

the definition of what the end of the project is and you know what is phase one and what is phase two and how are we kind of creating governance and a plan around all of that but before talking about the end of the project I guess maybe if we have a few more points on flow would be useful.

Nirav Shah (48:44.236)
Yeah, I look at it this way. I look at project momentum as, let's say, any sporting event. Let's take a basketball game, for example. They give you six timeouts. You have three per half at the end of the day. Some are full timeouts, 30 seconds, and then some are 20 second timeouts. I look at that also like ERP project and a project plan. You're going to have to take these timeouts.

throughout the project, it's just gonna end up happening. But they need to be controlled, right? Imagine a basketball game where someone was allowed to take unlimited timeouts, or how long a timeout was gonna be, that game would never end, right? There's a reason why you can only take a 20 second timeout or a 30 second timeout, because you gotta make your decisions, you gotta make your adjustments, you gotta get back in the game, and you gotta get going, right? You have a finish line that you have to get to at the end of the day. And I think oftentimes, people think these projects are

They should be open-ended like we need to be a hundred percent perfect right before we go live or we need this to happen But I think you know these projects evolve so much software evolves your business evolves, right? So you can I take that same analogy and tell customers like hey, we're gonna have these situations where We're gonna run into a speed bump, but let's take out you know three days Let's talk about it. Let's figure out a plan

Let's solve it, let's move on. Let's try to hit our Go Live date, guys. Because very easy, could just stop, one person, let's say purchasing has the loudest voice in the whole project. All of a sudden, they don't see that the ERP system doesn't automatically update the expected receipt date from a vendor acknowledgement, for example, and they're all up in airs about it. They make a fuss about it and say, we're not moving forward with the project until we get this fixed and resolved.

The partner's trying to give best practices, saying, guys, you could do this. Maybe here's an import scenario. an Acumatica, for example. To take an import scenario, pop them into Excel spreadsheet. Go ahead and update your expected receipt dates inside Acumatica. That's like a phase one. Phase two, we can look at automating it. No, no, no, we can't do that. We can't do that. But now guess what happens? That project's going to stall. There's going to be lot of back and forth. Maybe that enhancement's going to be like 80 hours to do from an API perspective.

Nirav Shah (51:12.526)
The business doesn't want to pay 80 hours. We know that that's not a big enough issue right now that we could go live without it. And now you're looking at an extended like six months potentially, five months, right? Or you lose all momentum. So I am a very firm believer that have timeouts in a project, but have them controlled and move forward. You gotta get back in the game and you gotta keep playing and you have to go live.

Peter Nicholson (51:37.723)
Yeah.

Nirav Shah (51:41.89)
That's just the end result at the end of the day. It's not gonna be perfect. But we're gonna get there. We're eventually gonna get there because you have software that's gonna really supercharge your business, right? But you're gonna solve maybe five out of 15 things for phase one, and then you're gonna start solving the other things later on.

Peter Nicholson (51:46.032)
Yeah.

Peter Nicholson (52:00.09)
Yeah, I think what I'm hearing you say is really the successful at least the companies that finish ERP projects on time. They kind of have one thing in common, right? And it's just make decisions, make the decisions and move on. And not necessarily perfect decisions. not gonna be, all of the traffic lights aren't gonna be green. They're not gonna make every single decision exactly what you need. There are gonna be issues, but.

Nirav Shah (52:12.291)
Yeah.

Nirav Shah (52:23.331)
Yeah.

Peter Nicholson (52:24.719)
Don't, well, I hate to say it, but don't let perfect get in the way of good. Yeah, just make those decisions and move on and keep that momentum going. Just make timely decisions, right?

Nirav Shah (52:28.972)
Yeah. Yeah.

Nirav Shah (52:36.686)
It goes back to structure, it goes back to project planning, put these timeouts in places, right, that we're gonna have to take them because things are gonna come up, right? Have the right visibility so the right people understand where we're taking this time out, make the decision and keep the moving. You saw how I connected all that by the way? That was actually pretty nice.

Peter Nicholson (52:50.106)
Yeah.

Emily Browning (52:55.806)
expert.

Peter Nicholson (52:55.951)
We're going through all of the different sports. At boxing and basketball, what else can we have? We should have golf stances in your background. We've not had a golf one yet.

Nirav Shah (53:01.602)
We did, yeah. We should have golf, yeah, we should have golf. Although golf could become like a two day event if it rains, or like there's hail and you have to stop playing because of natural factors.

Peter Nicholson (53:16.091)
What was I going to say? Oh, the other thing is also like those timeouts use them. You're right. You've only got three per half, right? There's a set number. It doesn't mean you need to have take time out every single time. So I think it's important to identify what is just like normal project turbulence because people are going to be busy and you can't be super rigid.

Nirav Shah (53:23.788)
Yeah.

Yeah.

Peter Nicholson (53:35.653)
But the same time, it's like when to call a time. When is it worthy of calling a timeout versus, guys, is it just a normal kind of project hiccup, just keep moving, kind of. You need to be able to make a judgment call on those.

Emily Browning (53:50.751)
I totally agree and it keeps the team morale high if you keep moving forwards as well. Yeah, so what else do we mean when we talk about keeping our project momentum? And that's why I'd really like to talk about the end of the project because I think two things can happen. One of them can be that the project sort of never ends and we keep adding and adding and adding.

Or we keep saying things will be in phase two or maybe we bring them out of phase two and into phase one. You really need to be clear on what your goal is at the beginning, like going back to the structure. And I think if we talk about, I'm kind of talking about a lot of my references here are thinking about with a big ERP, with like a big go live, which gives you quite a clear finish line, but that's not the case with all projects.

especially depending on what they are. some of them, you're implementing something technical, if you're implementing something in the ERP, but then maybe something sort of gets handed off to some of the departments, maybe they need to do some work on their processes or, know, everything's live, but we haven't written up the SOPs yet, the standard operating procedures. So we're going to leave that with them. If you don't keep leading the project,

having the project plan, giving the visibility, giving the updates to your stakeholders, those things aren't going to happen. It's just going to fizzle out. And I would say the majority of projects that I see just fizzle out because, and I think it can come down to the confidence of the project manager. If you've implemented your system, your upgrade, your new functionality, whatever.

great, you've done your job, the bit that you're an expert in, and now this team, you this department that you don't really know so much about, now they need to do, you know, this little bit just to finalise it and you think, well, you know, that's, that department head is, you know, they rank above me, they know what they're doing, they don't need me to tell them what to do, but they do, because it's still, it's still part of the project. And

Emily Browning (56:05.128)
and you want it to finish, you want to be able to report out at the end, this is how it went, yes, we've done everything, and end it, because then you also get to kind of celebrate the end of it as well, and really close off your phase one rather than have it just...

fizzle or drag out and then maybe eventually you start some of your phase two things or maybe more often than not you don't. But so ultimately my recommendation here is really define what the end point of the project is and even though the noise or the excitement you know all of the main stuff is done just keep going keep doing that project until everything is finished.

Peter Nicholson (56:47.515)
I wouldn't.

expand on that because we may have people listening that don't understand when we're saying phase one and phase two. So what is the what is the endpoint? What is the finish line? Because we've got down about keeping project management, keeping project momentum and finishing the projects. But I would say that if we're saying well, you know, phase one and then phase two, one, what is phase two? And two, is the go live day actually

the end of the project or are there things that you should continue to do afterwards and then you can say right this was a successful project because I'd imagine if if it's go live day and it's like bye done I think a project can still fail so where is the end what is the finish line if if it's not actually the go live day is there anything that we can do to keep momentum going after that period

Emily Browning (57:47.037)
I think it comes back to structure at the beginning and how you defined your projects, an important part of structure, which I don't think we really talked about.

maybe we can another time, defining your goal, defining the problems that you're trying to solve so that you're all very clear at the beginning, what are we actually trying to achieve? Because there's lots more you could do and people would like for it to do. And that's sort of where the concept of phase two comes in. I think it's usually, when we mention phase two, it's normally a way to say, yeah, that is a good idea, but it's just not something we're going to be able to get into this part

the project before we go live, maybe because it will take too long or it will be too expensive, you it takes us over budget of this project right now, or there are probably other reasons you do it, but it tends to be something people say to be like, yes, it would be great, it would be nice to have this, or it could be important to have this even, but can we live without it? Yes, let's call it phase two. And when we say phase two, we mean, okay, we go live, we get used to it.

and then we're going to start some more projects and this may be one of them. So that's what I would mean by that. And then the concept of stopping, you know, do we stop on Go Live Day or even, you know, at the end of Go Live Week? Probably no. Maybe it depends a little bit on the project itself. But I would always plan in, in my initial structure, in my initial project plan, what do I think?

That go live week, go live month, hypercare period, what does that look like? How long do I expect our vendor to still be engaged and really giving us that sort of very active support? Where might things still be going wrong? How are we going to handle the adoption of this project? That's what we mean by that. And to define it, I'd be defining it right at the very beginning before I even started. What is the end of this project? And it's going to vary depending on what the project is.

Peter Nicholson (59:53.51)
Nirav?

Nirav Shah (59:54.574)
Yeah, so the way we kind of try to draw a line in the sand, saying, hey, did we get to this point? Was it successful? 90 % of the time, I'm not going to say 100, but 90 % time, is we're able to do it the first one, then close. So we say you get the 30 days of support after you go live, and we're going to make sure you reconcile your books.

and give you your own month end procedures and what they look like. And month two, we generally feel that the customer should be self-sufficient and start running on their own, right? With just, you know, more or less a part-time support basis at that point. But month ends, you the first month end close is usually our kind of, hey, we'll get to this point and that's gonna be the end of phase one. Because we'll have delivered everything that you need to do to run your business by that standpoint and then.

We recommend you take two or three months to keep running the system before we kind of initiate and go down to phase two.

Peter Nicholson (01:00:59.516)
Alright, let's squeeze in. Well, I hate to say that squeeze in point five, knowing what point five is. I think we're all in agreement that we should definitely do a full episode on this one. But let's squeeze it in nonetheless. Change management. And we've already identified that there's two halves to this is the technical side, system configuration, data integrations, other platform integrations, and then the social side, people, behavior, the culture of the business. I think most

Well, it's easy for me to say from being a technical guy, but I think most of my project focus is definitely on the first. And sometimes it's easy to just hope that the second kind of takes care of itself. You know, you've got a brand new system, everyone's going to love it, surely. That'll be fine. So let's break this down and understand in terms of project management, how we can handle change management. And I really want to focus.

maybe focus a little bit more on that social side, on the people side first. So how do we best handle our people during such a huge kind of heart transplant of our business from a technical side?

Emily Browning (01:02:15.932)
I think it's a really difficult part of the project, probably quite underrated and maybe one of the biggest problems that you have with these projects. You'd like to think everybody likes their new system, it's better than the old one, especially when the old system is, you know, 25 years old. And on one hand, you think, OK, the old system is gone.

So they have to adopt the new system, but then you go live and you find out, they were actually doing most of the business in all of these Excel sheets and they still have those. So that maybe they're still doing them. it really is make or break, to be honest. And I have seen ERP migrations kind of go live and then die because they're just carried on using Excel like they were used to.

So it's a really challenging one and it's something you have to plan for. And certainly not something I'm perfect at yet by any means. But one of the key ways I think to challenge it is or to take on that challenge is with your that project organization, your roles and responsibilities, your key users and your work stream owners, your power users and the visibility aspect. You're giving the people in the business

ownership and responsibility over the success of this for their department or a particular process, whatever. You can adopt things such as train the trainer, which is where

instead of the project team or the vendor or the IT team training all of your users, you're taking the power user or someone relevant within a department and saying, we're going to train you and then you're going to go and train everyone else. And then that makes it more

Emily Browning (01:04:04.55)
I don't know, more applicable to the day to day, less like, you know, the IT team or the business or people from some other country, you know, leadership who are based in the US, but we're based in Spain. You know, they're telling us what to do. You're kind of eliminating that when you start to move the training over to the people that they work with and giving them that ownership. So that's that is a way to do it. It's not perfect, but.

it helps and I think we could delve in more and more but I think as a key big number one make sure there are people in the business who have ownership over parts of the project.

Peter Nicholson (01:04:43.984)
Yeah, I think that's critical because it's so easy to not see that, especially if you're not one of those end users doing day to day transactions, but you're the project manager that you need to see whether I guess people are just, you know,

They're in this, you think they're in the system and the system go live and the business just quietly works around it with those Excel files and you're none the wiser. And I think it's so critical because it's that kind of stuff that really starts to determine whether the whole project was worth the money. If it falls flat because of organ rejection, right? If we hark back to one of our earlier episodes, the business just rejects it, then.

you know, from a cultural point, from a human point.

from the technical point, that's the thing that really governs whether it's actually worth the money. And I think when you're looking at that kind of from the people side, there's going to be issues. People are going to resist it. And it's not because of laziness because we know that, you know, a modern ERP system will give them time back, you can better focus them on more value add stuff and grow the business. We know that. So it's not laziness. It's the kind of loss of control is that it's the people behind that.

the fear of exposure. Now you've taken away their Excel spreadsheets and their old system. What if the new system starts to show that they've been doing their job wrong? And I think that genuine disruption to the people is the thing that can really make or break the project because you might have the best technical implementation ever, but if people just don't like it and are...

Peter Nicholson (01:06:28.963)
actively looking for workarounds or scrabbling away trying to get back to the way they used to operate. the executive stakeholders walk in and see that and people are still busy doing all of this extra non-value-add stuff. Wasn't a success, right? People can make or break this project.

from a partner side, then is there anything that you could help post to go live to get that business going? I know you obviously you said, in our point before around finishing the project, let's get you to month end. is this stuff that you're doing then during those first few weeks after go live that helps people in the business from a, from this kind of cultural change management point of view, or is that purely on the, on the business? Maybe, maybe you've got some tips anyway on here.

Nirav Shah (01:07:19.724)
Yeah, I think all good stuff right there, all valid and viable. We always, every partner is different. And I can tell you what our culture is and our philosophy is that, you know, we don't implement the, the, the what we try to implement the why. And what I mean by that is, you know, yeah, you know, we'll implement Acumatica or implement, you know, business central, but end users really at the end of the day, don't care about that. They want to know.

how is the system gonna help them do their job, right? So what we try to tell them is, you know, business objective wise, we try to pull you out of spreadsheets. We try to pull you out of different things that you're doing inside of those, and that is change management. But we try to do it in a way that has less friction involved in that conversion process. And there's gaps and things like that that we need to kind of identify. But, you know, the more I think we're able to give

positive reinforcement that this change, difficulty of the change is maybe just temporary, long term, it works out and everyone's on a single system and actually helps build your job. And a piece that we didn't even talk about today is how AI is helping in this project management for ERP projects, right? And when you look at it and say, well, there's AI out there, what's happening with the data, you're creating clean data.

And that data then is helping you by way of agents or by way of other kind of, know, however you instituted, you know, AI for your ERP project, that it's just not you doing the same steps. You're doing those steps a lot more efficiently than right now. So now you're more on the business making better decisions than, you know, spending half your day doing data entry, right? That you were doing before chasing down four or five people to get to the information you're looking for. So.

You know, we really focus on that. It's always human nature is inevitable for people when you go live to say, hey, let me go grab my spreadsheet again because I'm just too scared of where we are with things. And we say, hey, hold on, hold on. Before you go to there, let's validate this data. OK, it could be wrong. Sure, absolutely. But let's now try to work together. Let's fix it. So next time you have the same enquiry, you're going to have good data at the end of the day. So you kind of have to start that right away as soon as you go live to gain that trust and that confidence with the users.

Peter Nicholson (01:09:43.174)
Is there anything on the technical side then in change management and other things that we should be looking at in terms of keeping our eye on maybe any integrations with other systems that we need to be talking to throughout ERP? What would you do for change management from a technical perspective? What are you looking for?

Nirav Shah (01:10:01.558)
Yeah, I think if we're talking about integrations after Go Live, we've done a, I don't think we've done the best job of planning for the integration prior, right? I think in my perspective, anytime there's integrations involved, that has to be scoped early on and developed, tested, piloted before we go live. And if there's integration after that, we try to minimize, like I said, dilute the success of the project, right?

People, somebody may think that it's super important that we need this integration now, but that was never discussed. The steering committee didn't think it was necessary, right? So we have to make those, have those hard conversations and say, hey, yeah, there's this integration. It's just going to be pushed off a little bit. You're going to continue doing what you're doing at the end of the day. So, you know, those are, those are sometimes hard conversations or those are easy conversations, right? It all depends on how we set the plan up. What's the structure around this, right? We try not to cry wolf.

unless we absolutely need to when it comes to change management.

Peter Nicholson (01:11:05.967)
Emily, any closing thoughts?

Emily Browning (01:11:08.256)
with change or the technical side of change management. I would think it's very relevant post go live because pre go live it is all being logged. was all in your project plan. It's all sort there as a task somewhere. Then you go live and we realize, what about, what about this? How am I going to do this now?

we can't do this anymore. How does this thing work? I can't print this thing anymore. What happened? And you end up adding a bunch of stuff in that you had to add in. It could be pretty minor things, but that list of changes can get out of control quite fast. And little changes can go in that maybe other people from the team don't know about now because the person, the department who spotted it, they went straight to the vendor.

You're not meeting up with your project team anymore, so it's not getting publicized like it used to be. So what I think is important post-Go Live with your change management, change control, is making sure you have some kind of system in place for logging and approving those changes to the system. And you need that.

going forwards anyway when you're managing any kind of software. But I think the particular danger zone for that is right after Go Live, when you change a bunch of little things and now suddenly, you know, your screenshots and your SOPs and things are not quite correct and it all makes it a bit harder to follow as your users are trying to get used to a new system.

Peter Nicholson (01:12:35.762)
Yep, wise words. And I think that is a wrap for today's episode. A huge thank you to you, Emily, for joining us on this one. I think your perspective on the real world side of this, what it actually looks like from the... yeah, we might have you back on. We might have you back on. It's good to...

Emily Browning (01:12:51.572)
You're welcome.

Nirav Shah (01:12:53.454)
Yeah, yeah, yeah, yeah.

Peter Nicholson (01:12:57.446)
to see it from the business side of actually going through this. So I'm sure our listeners would have gained a lot from having you here. So maybe you can come back.

Emily Browning (01:13:07.932)
for having me again, perhaps.

Nirav Shah (01:13:09.742)
I say she comes back, I think I think

Emily Browning (01:13:15.728)
Okay, you've twisted my arm.

Peter Nicholson (01:13:18.812)
I feel like Rex from Toy Story. What? We're being replaced? He really flips out. I to drop that into the edit.

Nirav Shah (01:13:29.976)
Great analogy though, I like that analogy.

Emily Browning (01:13:30.334)
Mm-hmm.

Peter Nicholson (01:13:33.982)
So yes, and thank you to everyone listening. So whether you are on YouTube or Spotify, Apple podcasts, or wherever you get your podcasts, we hit all of the platforms. And if today's episode resonated with you, please do give us a like, give us a review, share it with a colleague who might be going through an ERP project or got one on the horizon, and definitely subscribe so you don't miss what's coming next.

As ever we are the ABCs of ERP and beyond we come out with a new podcast every two weeks On all major platforms as I said, so make sure you find us. We also like to spam it on LinkedIn So reach out to us Nirav Shah, Peter Nicholson and Emily who's replacing both of us by the sounds of it. You can find us on LinkedIn

Emily Browning (01:14:23.744)
Mm-hmm.

Nirav Shah (01:14:24.066)
Hahaha

Peter Nicholson (01:14:25.982)
And I should say we also find us on TikTok as well. We haven't done a TikTok dance or anything yet. We'll have to work on something maybe.

Nirav Shah (01:14:29.966)
Yes. No. Yeah. Yeah. I know. Yeah. Yeah. Yeah. I don't know. Hey, Peter, get on those AI images quick because I don't know if you could do the real one. So.

Emily Browning (01:14:33.504)
Ugh. I look forward to it.

Peter Nicholson (01:14:39.102)
she says with gritted teeth.

Emily Browning (01:14:41.044)
Well, I don't have to do it, right? It's you two. So I look forward to seeing it.

Peter Nicholson (01:14:47.102)
You

Peter Nicholson (01:14:50.864)
Yeah, that's it. Yeah, all right, I'll work on something. Very good. Thank you both, and I'll see you on the next episode.

Nirav Shah (01:15:00.686)
Absolutely, thank you.

Emily Browning (01:15:01.226)
Thank you.