AJC ERP Implementation: Gather the Team and Plan

Hi, I'm Andrea Jones and today we're going to talk about the implementation of your erp. First step, this is to gather the team and make a plan. And there's four components. There is gathering your team, there's the vendor team or any other integration, third party participants. There is creating the plan and aligning to that and there's the governance for all of the things that are going to happen for your team. Typically on a selection you've had pretty high up people that both understand your current and your future state. Often it might be a CFO driving this and that person is even participating fairly materially in the selection process. Now that you are moving into implementation, there are a lot more tasks that need to happen. There's data migration, there's cleanup, there's configuration, all these things. And the steering committee will be typically higher level people that were your selection team and the implementation or core team. Your team that's doing the day to day is maybe a mid management or a sort of senior individual contributor level representatives from each department that is going to be materially working in the new erp. So usually that is accounting pretty heavily, that is customer service, that is whatever your delivery of your product or service is. So if you're a manufacturer, it might be a top manufacturing person or planner there. Procurement, if you are in distribution, it's definitely procurement or warehousing. And sometimes you might have a quality representative as well. Especially if you're manufacturing something or if you have a high assembly component and there's some quality to be considered there. Sales, it depends. Sales and marketing. If you're implementing a CRM or you will have customer facing portals or anything in the first phase of your erp. Typically companies wait for second phase, phase two to do that. So yes, maybe there's a go to person in sales or marketing, but they don't always participate on the day to day during the implementation. All right. Of course you have your own project manager who's keeping your people aligned on track, making sure they know what they're doing and getting those things done and escalating any concerns to the steering committee. So you have your own project manager, that's your team, the vendor's team. So if you bought particular software, they will have their own project manager and that person is facing their team and interfaces with your team as well. But they're not going to be managing your people, they're managing their people. They usually have about 10 customers at a time. So if you think about a 40 hour workweek, which who knows if they're working that or less or more. But let's say that they're working 40 and they're splitting it evenly. The best you can expect is about four hours a week. At their time, it's not really enough. They will have a project manager. That's great. They will have an analyst team. That's usually the people that help your team understand the system better so that they can advise them on the configuration. There's an accounting or finance person and an operations person. Usually sometimes some subject matter expertise, especially if you're getting like the warehousing module or inventory or something like that. And if you have any customizations, they'll often be a developer or you know, maybe a senior developer or sort of a product owner that is liaising between your team and what your customization needs are and their team coding that. Okay. Often the vendor will have a trainer. Sometimes they ask you to go through training first and they put a certain person in there to guide your training. That's your navigation of the system. That sort of looks like, feels like getting your team comfortable. Trainer is usually not someone that sticks with the project throughout. They put that person on, you know, different projects and that's fine. All right, those are the team. So again, steering committee level is decision makers. Higher level people, often the ones that made that decision about who, which ERP to go with, they'll stay on steering committee. They can expect to have regular weekly updates, usually in writing and maybe monthly or bi monthly meetings like this face to face or in a virtual situation where they're getting verbal updates. And then they also need to be aware of an escalation path if there's anything that comes up critical path that's derailing you and the core team can't figure it out. Maybe it needs more budget, needs more time. Whatever it might be, they would be asked to participate then. So it's maybe zero to two hours a week at the most. I would say core team though they're expected to participate materially, I would say five to ten hours most weeks. When you get into heavy testing or heavy data migration time it might be more certainly. But before go live and especially when you're training everybody, they can expect to spend half if not three quarters of their time, so need to be prepared for that and it needs to be managed well so that it's not excessive. That's why the project manager is so critical in this area. You might even have a coordinator who is just literally scheduling meetings and following up on the multiple streams while the project manager is Keeping the higher level stuff on the rails, so there's some nuance there. Depending on how big and how complex your implementation is going to be. Okay, your team, the vendors team, we talked about that. And now I want to talk about the plan. I can't emphasize enough if you watched any of the previous videos, you know I'm very big on setting aligned expectations. Let's just get it out there up front. So we have a charter template that we use. You can find one anywhere, but if you want ours, please feel free to email me. And it has the high level goal, right? So we're trying to implement this ERP the rationale in order to be able to understand our finances. You know, our old system is no longer supported. Whatever the reasons are, you want to make sure people are clear. I wouldn't go into too much detail, just kind of high level three is enough. And then the roles, responsibilities of all those team members I just mentioned, so people are clear in writing. So. So people are able to look at it and understand what is expected of them and they can nod their heads and say, yes, I understand a high level milestone schedule. At this point there's no reason to detail everything out. You're only going to be changing dates and changing specifics later on. But a high level schedule is pretty important. That's kind of your big picture plan. And I would come up with your operating norms. How often are your teams going to meet? Are you going to have one core team meeting internally and then are you going to have discipline meetings weekly? Like maybe the ops team meets with the analysts on the vendor side and the finance team does the same, but they have separate meetings that come together once a week, stuff like that. How often is the steering committee meeting going to be? What are the times? I Recommend sticking to 30 minutes at least at first. Maybe it's every other week for the first month. While people are getting aligned, you back it off to monthly for the majority of the time and then you pick it up again closer to go live about two or three months prior, but put it on the calendar. These people are busy, you know, they need that time blocked early so they don't plan over the top of it and find out what's convenient for them. Is it virtual? You know, maybe it's a Friday instead of a Tuesday, for example. Those types of operating norms. Also, if you are writing down actions, which you obviously should be, what is the expectation on getting those things done? Do we expect people to get them done without someone poking and prodding at them? Of course that's always the norm. But if you don't say it out loud, people may or may not assume that and you really have no recourse in that case to go to them and be like, why didn't you get this done? You know, of course you probably will have to do that. And you know, that's just human nature. But that's again, what your project management, maybe your coordinator is for. So those are the plans, that's the norms, getting all that together in writing this whole process, because people will want to review, they're going to have questions. It can take up to a month. That doesn't mean that you can't get going with training or with data migration extraction and, you know, clean up into tables simultaneously. I'm not saying that. I do think though, spend the time to make sure everybody's super aligned. And then the fourth component in this first step of gathering the team and planning is setting up your project governance. So where are you going to keep your plan? All of the project documents, right? Is there a decision log so that if you talk about something in the meeting and you make a decision, you can write it down and say who was there and who approved this decision or you had to escalate it. Is there a specific template, for example, that your steering committee wants to have in order to see what decisions they have to make? We have an example of that. Like, here's the situation, the context, here is the specific decision we need. Here's the recommendation or options provided by the team. Give them something so that they aren't having to dive into the weeds and micromanage this. Give them something with some rationale and then take that to them in writing with, with, I would say the project manager, that person has a 15 minute conversation and if the steering committee can't, or the person that's a decision maker can't make a decision, perhaps there's additional follow up or back and forth, but still, you know, where is that all going to live? Is it going to be OneDrive? Is it going to be SharePoint? Is it going to be a Google Drive? Is it going to be a software system? Do you have Asana? Do you have Jira? Do you have, you know, Monday? Do you have something else like where is this stuff going to live? Make sure everybody has access to it, make sure that everybody is in there and can get to it and is getting to it and how often you're going to keep that updated. And if you're doing videos, which I highly recommend, especially when you meet with the vendor, you're recording things, where is that going to be saved? At some point you're going to have to archive this stuff and maybe put it into a folder for this is our phase one, if anybody ever needs to go back and look at what we did. Software projects are notorious for not really documenting well what decisions were made. And then you have the software and it works in a certain way and you're not quite sure why. A couple years down the road, remember you're not doing this again, hopefully for a really long time, 10 plus years. And you want to be able to see where the buff the bodies were buried. So that's the governance. So again, big first step. It can be done simultaneously with real work. But get your team together, make sure the vendors team, and I forgot to mention, but if they're integrated third parties, if they're not there at the beginning, you need to review the charter or the plan with them when they come on board. If not the very beginning. Also just getting that charter, those operating norms in writing and making sure everybody agrees to them. I used to go so far as to have people sign things that might be overkill, but it also might not be. It depends on your team. And then what's your governance structure? Where are you going to save everything? Making sure it's there, up to date, everyone has access, all that type of thing. Probably about a month's worth of time. You can do other things at the same time, but don't skimp on this. Make sure it happens so that everyone can stay as aligned as possible. Expectations are set up front and it sets you up for a great, positive working experience. Thanks for watching.