Building a Robust ERP Implementation Team

In a live stream discussion, Avero Advisors CEO Abhijit Verekar, Megan Seaton Business Development Manager,  and Director of Advisory Services Robert Kornovich discussed the importance of building a robust implementation team for ERP (Enterprise Resource Planning) projects. They emphasized the need for a project sponsor, a project champion, and a change management lead. They also highlighted the importance of defining roles and responsibilities early on, and ensuring that everyone is pulling in the same direction. They advised smaller organizations to spread responsibilities across different roles to avoid overburdening one person. They also stressed the importance of effective communication and collaboration within the team, and the need to address data-related challenges early in the process.

Stay up to date on industry trends!

Download our free eBook:
➡ https://bit.ly/2023techguide

Learn More About Avero:
➡ https://www.averoadvisors.com

Connect With Us:
LinkedIn: https://www.linkedin.com/company/averoadvisors
Facebook: https://www.facebook.com/averoadvisors
Instagram: https://www.instagram.com/averoadvisors
TikTok: https://www.tiktok.com/@averoadvisors

Connect With AV:
LinkedIn: https://www.linkedin.com/in/verekar

(865) 415-3848 | info@averoadvisors.com

Transcript

Megan (00:00):

Hello everyone. Good morning and Merry Christmas. Welcome to the Avero Advisors live stream. Today I am joined by Mr. Abhijit Verekar , who is our founder and CEO and Mr. Robert Kornovich , who is our director of advisory services. Hello guys and Merry Christmas AV (00:18):

Morning. Merry Christmas, I help you. Had a good break. Megan (00:21):

Yeah, I hope everyone had a great time with their families and enjoyed the time off. Today we are going to talk about building a robust implementation team. I think this is probably the most important part in my opinion when it comes to implementation, just so that the vision can be aligned with the whole organization and your team can help trickle that vision down right along with vendor accountability and keeping the project on track. So to open up this live topic today, I want to talk about what are some key aspects or key leadership skills needed in an implementation team. How do we choose those individuals who are going to be responsible for this ERP implementation? Robert (01:09):

Yeah. Advice I give to clients from the get-go is you really need to have a project sponsor, which is a named position that we always have on our projects and it's essentially our counterpart on the client side who's actually leading has tie in with executive with finance, just a number of things, not necessarily the project champion, which is the next role that comes to mind and change management's the other one as well. And those are so important because in some clients they all tie to the same person. It is one person who's doing your change management, who's doing your champion of the projects, and there's also your project sponsor larger projects that can be broken out and I think it's important for people to understand that they can be different people, that it's rare to find someone who can lead the change management, also be the champion of the project themselves. They're the ones who are the most excited. Usually those can be different functional roles spread across the organization, are assigned to key people and doesn't have to always be like the one person. In fact, AV would probably agree there's a danger if it's only one person who's your project champion, your project sponsor, and also your change management person. You're asking one person in the client side to get all of this done. And so the more you can spread it around, I think it works the best in the long run. AV (02:36):

And the PMI standard lays it out what should be the project roles, but in reality not all of them apply, but the ones that apply the most and the most important ones are the ones you've talked about. Robert Project sponsor, someone who is ultimately responsible not just for the success or failure of the project, but also owns the decision making. You can have competing priorities and competing interests in the project and they may not all align at all times. So the project sponsor's role is really to make decisions when it comes to those situations and the way we play with them is, like you said, Robert, it's a's a counterpart relationship. Yes, they're the sponsor, they're the main client from our perspective, but also we lean on each other a lot. Then the project champion can be one in the whole organization or one across each department. And then you have the different other roles we've talked about before like Project PMO, lead, program manager, business analyst, what have you, change management lead. There's a whole host of different project roles that have to be in place if your project is to be successful, especially a big project like a multi-year, multi-agency ERP implementation. Megan (03:57):

What about for the smaller organizations who may not have enough bodies to really fill these roles that you guys are talking about? Would their roles overlap at that point? What advice would you give to them? Robert (04:14):

Yeah, it's going to depend upon, again, we're using the consultant answer, it depends. The key thing when we talk to clients is showing them that a lot of this might look overwhelming on a piece of paper, but it's all manageable. It just needs to be apportioned correctly. And sometimes the project champion is in procurement. It's a procurement officer who's really excited about this ERP because procurement's able to see all departments. It's like it, they interact with all departments on a regular basis so they can see a lot of the pain and frustration the existing system is providing, whereas the finance director is not going to see that the police department or HR is necessarily struggling on a day-to-day basis with their ERP system. So it's going to depend upon who that project champion is, who's really the agent for change. It's preferable that it be at the executive level.
(05:11)
Sometimes though we have projects where the executives aren't really excited about an ERB, they see it as just another big project that they're taking on. And so the enthusiasm has to come from someone else in the organization, so it doesn't have to be full-time roles and it doesn't even have to be anything that's another duty on top of your existing job as a member of that organization. It's just the communication I think is what sets the standard and that's what we're very good at. We're going to tell you how this is going to be possible. Yes, you're our agent for change when it comes to change management, but I'm not going to meet with you for five hours a week just to talk about change management. This is just going to be a very quick weekly check-in to get your temperatures to what's going on in the organization. So all manageable just by getting the lay of the land and working with the client to get it tuned just right, so it's not yet another responsibility on top of what they're already doing. AV (06:07):

Yeah, and good question, Megan. In smaller organizations, if the organization's small, the project isn't that larger risky, right? We're talking about the six to 10,000 employee organization, lots at stake, lots of moving parts. You need to have these defined roles in place. In smaller places you may get away with just having a PMO lead and a project sponsor and you can call department heads, project champions. You still need to do the work in terms of pushing the project through and communicating and making sure people are on the same page. But the extent or the expanse of that, the roles may be a little smaller. Megan (06:54):

What are some of the responsibilities that these lead roles will take on during an ERP implementation? AV (07:04):

Well, I think primarily it's the leadership, right? There's the work layer and then there's leadership layer. By the work layer, I mean people that will actually be contributing to making decisions on how the system should be configured, what kind of buttons they want to see, what the workflow should be. You don't necessarily expect the CFO or the city manager to be that person that's looking at every piece of detail. So there's that layer and then you have the leadership decision-making layer where one, you're making sure that everybody's pulling in the same direction, right? We've seen situations where city manager or mayor lets the IT department lead it or one of the functional areas drive it, and then it becomes a very one-sided affair where other people may lose interest, other departments may lose interest because finance is making decisions that only benefit them or it is doing things that are too technical for us. So the sponsor role is critical in breaking those deadlocks to make sure that everyone's as excited as they were on kickoff day and keeping that momentum going. So it's really important to have that role in place, big or small of an agency. Megan (08:23):

Perfect. rk, do you have any comments on that question? Robert (08:26):

Well, I was just thinking sometimes we get executives who do want to do that sort of detail. They do want to be shown this is exactly how this screen's going to look and be configured, and that's okay. What they wind up realizing though, especially if they're a big advocate for technology change and they've done this before in a prior organization, they really want to be part of this project, but they do reach a point where suddenly it's, I got 25 things on my plate, I'm managing enterprise risk on a daily basis. At some point, their interest in their ability to be that detail involved with ERP wanes. And so that's why it's still important at the very beginning to define these roles and figuring out how this is going to work out because you don't want to suddenly have to pivot to someone else and then drag them through halfway down the road to implementation or testing, establish it at the very get go. Even if someone goes, I don't know how I'm going to do this project. I don't have the time, I'm not the expert on this, we are able to go in there very quickly at the very beginning and go, this is who you're going to need. Let's start those relationships now and you might not need them for a couple of months, but let's establish this now. And it goes a lot smoother. AV (09:40):

Well, and clients also, especially the ones that haven't been through this before, they have different words for the same things. We might say project sponsor, but they've been to some training that someone else held and they called it something else. So you have to be cognizant of that fact and make sure that terminologies match things like what is a project sponsor versus what is a project manager versus what is a program manager? And you have to define these things before you name them so that the client and you are all on the same page on what that role entails. We've been in situations where we kicked off a project and the project sponsor is asking for, well, where's the project team? Where's the project team? And we're saying, this is your project team. And the sponsor asked us for weeks, Robert. It was like, well, when are we going to set up the project team? So then we came down to tell us what you mean about a project team and to that client, it meant a team that would be on their side working dedicatedly on this project to the end and beyond. And to us it was like, well, this is your consulting project team and as we go along, we will pick people that we need for subject matter expertise or workflow design and things like that. So really critical to make sure you have a good definition of what you're talking about when it comes to roles Robert (11:05):

And let us leverage our experience. Because I'm thinking of a client recently who the day of the kickoff wanted to know when do I start doing my staff logs? When do I start pulling people from various departments to be the SMEs for this particular project? And it took a lot of discussion to show them you can do that if you need to, if there's an internal pressure for you to build that team. But there is nothing right now for them to do specifically. I really don't want to put people in a room and sit them down and go, okay, this is the project that's coming, but by the way, there's nothing for you to do two and a half months. So let us leverage our experience in showing you how to do that. And we understand government procurement, we understand that you can't just turn around tomorrow and grab someone and bring them in as a staff.
(11:54)
There's a lot of process that has to be done in local government. We will give you advanced notice to give you plenty of time to do that. So just allow us to leverage our expertise to help guide you so that you're not in a situation where you've got seven people who are now sitting in a room because they were re-designated for an ERP project, but they don't have anything to do yet. I think that's a more uncomfortable position for the client, whereas let us show you how this plays out, how this time's out, and give you the lead time to do what you need to do. AV (12:26):

Well, and it goes back to defining not just defining things upfront but also the executive alignment piece we talk about and do for our clients. Let's get all of the players in the room at the very top with this main sponsor and define what this is going to look like, what the risks are, where the flash points might be, what happens if you do get into a fight. Rules of engagement need to be laid out way before the kickoff happens. So that phase before you start phase one is critical where you're just talking to the executive team, making sure everybody's aligned behind what the outcome of this project should be and what the rules of engagement are. Megan (13:06):

Yes. And in your all's opinion, we talk about bridging this gap between the IT department and then governmental operations, right? So in your all's opinion, do you think that you should have a role of a liaison between the two or should you lean on a consultant like a Vero to help bridge that gap between technical knowledge, sorry, and government operations? Robert (13:34):

I would lean on us, but that's because we have the depth and the background in not only the technical world but also in the actual hands-on practical functional parts of implementing these projects. So it's easier for me to, the discussion I usually have with the key people in the organization, the chief financial officer, the IT director, and the HR is let's both set up an understanding where I can leverage my experience and my understanding as to what not only does your organization want, but also what the software vendor's going to be looking for and what they would like to do and let us each commit to using our perspectives in the organization to give feedback to each other. So as a Vero, I don't want to step in and say I'm the absolute expert at everything. I mean we could be if we needed to because done this enough times, but there's that balance between the engagement, the communication at the same time letting the client tell us, I'm really having a lot of difficulty working with it on this, bring that to our attention and let us try some things to help mitigate that and help control that.
(14:53)
And the same thing as well, I need to be able to go to the CFO and go, it is really getting a lot of pushback from your department on this training. We have a problem here. I think we need to figure out, by the way, this is usually how this will play out. Now this can work well. So again, I'll go back to communication, setting that expectation from the get go with all the stakeholders that there will be constant communication to the point that if you have a concern or something doesn't look right, you should be able to pick up the phone and call me immediately and say, I'm encountering this problem, or it looks like change management stalling in this particular thing and then let us work as partners to resolve that. But it's much more preferable if we are involved in that from the very beginning rather than waiting for a conflict with HR and CFO to start boiling over into our meetings and then we become aware of it. So we try and establish that expectation and that level of communication from the get go that allows that to happen. AV (15:55):

And we've, I'm going to pull up our QR code that has links to all of our content around this. We have a cool quick start guide on our website that would be very useful as you start this process, especially if you're about to start thinking about an ERP implementation or selection in the next year. Take a look at these guides and checklists and they'll be really, really important along the way. Sorry Megan, I had to Megan (16:22):

No, you're fine. I think that's great. I love that checklist. I'm very proud of that. I think it is interesting. So when we talk about executive alignment and visioning on the front end, is that when one would, number one, build their implementation team out and define the roles and expectations of each, and then would you include an IT director in that executive alignment sort of meeting visioning strategy? AV (16:50):

Well, question two, absolutely. Absolutely. One of the biggest cogs in the wheel will be the IT department, IT director, CIO, whatever you call 'em, and think about where things stand when you're looking for an ERP system. Usually it's the user group that has been for years saying, our system doesn't work, can you help us find something else? They've tried tweaking things eventually leads up, if it's an ERP that's financial, it's typically the finance CFO's decision. So they along with the CIO, maybe HR form, like the core team that makes this decision to go out to RFP or start looking at products. So that's your core team. So pre kickoff executive alignment at the very least needs to be limited to those three roles. Now in larger organizations that are full service cities, you might have the chief of police, you might have utilities director, you might have the K through 12 representation.
(18:00)
So it depends on how you look at ERP because all of these or most of these will be included in a new system. So you need to bring these people to the table to start talking about what this looks like. And that's where a consultant or a CIO plays a crucial role, right? Because they understand the ins and outs and purchasing too. You understand how each department works when the last time we did something for them and how this all comes together for the organization as a whole. So that happens prior to alignment and then when the project kicks off, it's important to go to define the things we talked about earlier and keep alignment in place. Megan (18:42):

I think we need to create some marketing around specific roles for implementation team. I think that would be very neat. So we have a question in the comments. How important is industry specific knowledge in the team and how do you assess or build this expertise? It's a good question. Robert (19:03):

Yeah, this question can have a couple of different interpretations. Industry knowledge sometimes could be just like subject matter expertise on the software itself, and in that particular case, we can find if there's something that does need a specific subject matter expert on, we can find that person and bring them into the team. The industry specific knowledge usually is this other definition I'm thinking of, which is how is this done? And a's exactly right, most of our clients have either never done any RP implementation, they haven't done one in 15 years, or the one they did five years ago is failing and that's the reason why they're out looking for a consultant to help 'em through this. For that one, considering the number of projects that we've done and a lot of our employees have done over their lifespan as project managers and industry professionals, there is a lot of inherent expertise that not only makes your project successful, the successful project, that's not the scary aspect.
(20:09)
The scary aspect that clients have is what happens when this happens. In other words, following the happy path as we like to call it, gets you to project success. But what happens when your executive director leaves in the middle of the project and a new one comes in? Very tricky situation. We know how to handle that and not allow that to derail the project. Your CIO could leave in the middle of the project, so key stakeholders leaving and then sometimes it's just unforeseen events. We had a small client we were working with that had to have a major outlay of capital to mitigate a serious community situation that temporarily derailed that ERP project and there's a way for being able to handle that to being able to either pause the project or redirect the project to be able to deal with this other risk that's occurring in the organization and still allow you to get to a successful timeline because the option of just, well, we're halfway through and I need to take my money and go do something else, so let's just kill the entire project is not, first of all, it doesn't make sense going back to your elected board.
(21:18)
They're very upset that you just wasted a lot of money to do a halfway implementation. So a lot of times they turn to us and go, okay, tell me how this works. How am I able to park this project for a month or two and then resume it? Are there things we can be doing in the meantime? So when we talk about industry specific expertise, in my mind that's what clients are really looking for. How does this functionally play out? How does this work and where's the leadership going to be from you guys when a project variable pops up? AV (21:50):

And it's not just industry expertise, right? It's subject matter expertise. Yeah. They're also looking for people with accounting expertise. They want your support on setting up the chart of accounts or if it's a transit agency, they need somebody with transit experience or having done work with transit agencies. So it's functional and industry specific and you don't always need it. That's the key point here. You'll need SME subject matter experts for specific pieces of the project or to answer specific questions, but you don't need that kind of resource throughout the project because it's a combination of your own staff, your IT department, maybe your outsourced outside consultant, and then you lean on them to bring in the expertise as needed for very specific pinpointed things. Robert (22:44):

In fact, the most important subject matter experts on a project are almost always on the client side. I need to know how this process actually works and how you want this to be in your new ERP system. That's the critical piece that the software vendor's not going to bother to try and figure out, which is key to what we do, which is, yeah, I can shoehorn you into a product, but if it doesn't respect the processes and the way you have to do things or the reason why you have to do things, you guys are just going to find a workaround to go back to the way it was before and you're going to be unsatisfied with the system. So I definitely need as much expertise as to the day-to-day and the process and the outcome on the client side much more than I ever need someone who is a specific expert on this particular work order screen on this particular product. I can get that, but the gap usually is in figuring out what the client needs so I can get them the right system. Megan (23:43):

We have another question. Megan (23:44):

I was going to try to bring it up. It's a two part question. So from Klay, thank you for joining. Clay, do you have any tips for an organization that is looking to hire someone new to work with the consultant project team to handle the day-to-day of the project, and then what does that job description look like and what skills and experience should they look for in a candidate? Robert (24:08):

Yeah, it's going to vary a lot from client to client. Larger clients, you can probably be more specific targeting something where you need a staff fog, but usually on the smaller clients, I need another body. I need someone else in here who can handle, even if it's just scheduling folks. So I'll give a number of examples. The person who actually does a lot of work on the backend to get all these people scheduled to be into this particular project meeting who makes sure that there's enough advanced notice to the legislature before you bring something to them, and sometimes even the executive assistant to the county or city manager is one of the most important people you're going to have on the project because they're going to be able to tell you, yeah, you're not going to be able to get that on that agenda, so tell me what date you're trying to target to get everyone in the same room or be able to brief the council.
(25:07)
They're going to know just as much as the city manager or the county manager on things like that. So they can be particularly key, particularly key. There's also some other things, which is someone to help you run. Help desk is another example because once you go live with your ERP project, you're going to have to figure out how you're going to solve that long-term issue of, okay, what do I do that now that I'm live on the system and I'm starting to get support tickets in, who's going to manage that for me? You can either hire someone to do that, you can certainly use that. We've talked about managed ERP, so it's going to vary dependent upon what the client needs really. There's a number of examples that I could give, but like I said, the larger the organization is, the more specific that ask tens, that S tends to be AV (25:57):

Well, and most of our clients have a project manager on their end, especially the larger ones. You have us leading the charge on the overall implementation and sometimes they'll have in a larger project, they'll have a project manager on their side either reporting into finance or, and their job is to help us herd their cats. If they weren't in that spot, we would have someone in that spot because it's a crucial position in a large organization. There's always so many moving parts. They all have day jobs that it's helpful to have an internal project manager, but the roles and responsibilities in the job description is really what it looks like for us, like for RPMs, someone that has some experience dealing with work plans and schedules and people and timelines and vendors. But also what's beneficial when you have someone like us involved is that we have a deadline and a budget. Our job is to get it done and get out there. So it's pros and cons. If a client is looking to hire somebody to be the PM on their end, that doesn't preclude us from being the pm. It's a distinct different role, but they both support each other. Robert (27:18):

Yeah and I think there's going to be with some clients creating that new position, you're going to be better served by backfilling with someone else in the organization that wants to move into that position temporarily or permanently, rather than going out and just finding someone out in the market who meets a specific set of requirements, probably going to be better to allow that person to move to this new position and then backfill on your end for that position. That person vacated. And there's another layer on top of this, which makes it really interesting, which is unions, which can make things very complicated in terms of putting together specific job requirements. It gets very, very tricky at that point because the minute you start specifically defining a skill or a job requirement and you have unions involved, they are really, really going to look at exactly how you worded that and say, you can't do that.
(28:13)
Skill resides in this other position, so you can't have overlap. Or they're going to put you in a box that says, sure, you can hire this person, but they can only do this. So now you have someone who could not be brought into another part of the project if the project needs to concentrate more on this rather than what that specific assignment is. So it's a very, very tricky situation. There's ways of doing this, and generally it's not to be too specific on what you're asking for because that puts you in a box and then makes it very difficult to use that person as a resource in other areas of the project. Megan (28:50):

I want to talk about effective communication and collaboration strategies within the implementation team. You have all these different ideas and wants and needs and you bring 'em all together and we've tried to create a vision that aligns with everyone's thoughts and wants and ideas. So how can we help foster effective communication and collaboration throughout the ERP implementation team? Robert (29:21):

Yeah, I'm very big on breaking down and eliminating assumptions. We tell our clients this a lot, which is I'm not going to allow the software vendor to operate on assumptions and we don't operate on assumptions and I'm not going to force you as the client to have to operate on assumptions. Things will be specifically spoken about and communicated. That'll be the level of expectation. So again, like I said, if someone has a concern, they come out of an internal meeting that we weren't involved in and they're sensing we've got a little bit of a change management issue related to this ERP project, I want them to pick up the phone and call me immediately and say, I think we have a problem here. Let's see if we can figure out a way to navigate that. So I always look at it from that perspective, breaking down and eliminating assumptions, and that's a challenge for us as well. We have to make sure that we don't assume the client understands that we're talking about. We are going to stop and make sure that it's crystal clear that everyone in the room understands what we're talking about, what the outcomes are, and not just try and steamroll over people with a bunch of jargon. That's my approach to communication and what we like to have our projects team do throughout the entire project, no matter who they're talking to. AV (30:37):

Well, and slowing things down, things down is also critical. Depending on when you bring us in or any consultant, if you're a good consultant, you'll tell the client not to go by the vendor's timelines. Vendors are going to say, we can get this done in six months and you're going to be left holding the bag. We've talked about the definition of go live and what done means. So it's important to define that. So timelines and go live and what data you want to transfer really should be defined by you, the client, and not anyone else. Megan (31:21):

Yes, and at the beginning, right? Absolutely. Before you do any of this, are there any tools or practices you all would recommend for effective communication amongst the team? AV (31:36):

Oh, often in upfront, good, bad or ugly, it needs to be on the table. It needs to be in the risk register. It needs to be talked about because there is no bigger risk than bad communication, and you have to, again, going back to slow it down, be comprehensive and do it right, because this is once in a, it should be once a career if you do it. So the tools are varied, depends on who the people are, how they communicate, what they react to. It's our job as project managers change management practitioners to create that kind of cadence and format that the organization is receptive to. Megan (32:18):

Right? Robert (32:19):

Yeah, questions. Just leaving room for the client to ask questions. Even just simple things as in a 30 minute meeting, make sure you leave plenty of time for people in the room to ask questions and show that we respect that and encourage that from the very beginning. And we're not going to shortcut something because all I want to do is get in the meeting, tell the client what they need to know and then get out of the meeting. No, that's not effective communication. That's not a relationship. Just like Avi said, just having the cadence and the professionalism to allow all people, no matter who they are, speak up and talk about a concern of theirs, whether it's a specific technical thing or it's just, I got this problem, I don't know if it's going to affect the project or not, but tell you, lemme what it is or lemme tell you my observation on what I'm seeing. Megan (33:16):

One of the things that Katie and I talked about a few weeks ago is being curious and I think being curious is part of communication. Why is this thing the way it is? Or why do we do this thing this way? So coming to the table and being curious I think is a big piece of this as well. How do we handle conflict or misalignment within the team, especially if it involves public sector stakeholders. AV (33:50):

I think communication, I mean really going back to no surprises. One of the things we say to our clients is we don't surprise you. We don't like to be surprised. We won't surprise you. So if you follow that, then you're not going to have conflict. And if you do have conflict, then you go back to your conflict resolution plan. If it's a large enough project, it's actually a documented plan. How are you going to define this? Who gets to make decisions and how do you resolve the conflict? So variety of different ways, but I think it all goes back to having defined what this should look like when it's done and if everyone is pulling in that same direction, if you're communicated too about timelines, key milestones, what's needed from you and it's documented well, it shouldn't be a surprise, so therefore should not be a conflict and there are opportunities for people to say no to something or change something throughout the process. We provide various opportunities for feedback on a project or a work plan, and if you haven't said something during that feedback window, then I'm sorry it's too late, but it's not always very rigid. You can always make changes as long as it's driving in the right direction. Robert (35:12):

Yeah, I agree with that. If we're doing our job correctly and we're managing communication correctly, we're going to know something's coming before it actually reached the point of conflict. We're going to know that there's already a disagreement going on between these two particular people just like we promised the client. The minute we know that there's going to be a problem with the timeline because the software vendor suddenly to switch out people, the minute we know there's a risk to that timeline, you are going to know as well, we're not going to sit on that news for days or weeks and then try and figure something out and come to you. When risks and variables pop up, the client's going to know those as well and it's going to be the same way for us. We're going to know something's coming, we're going to sense that this is going to be a problem so we can step in and mitigate it before it becomes a true conflict between two people or a group of people. It's going to be controlled and mitigated before it even gets to that point so that there is no escalation of tempers or all those other things that when we say conflict, that's what people think of. We resolve a lot of that in the background, so it never has to get to that point. Megan (36:22):

Could you all share some examples of where collaboration and communication worked well in an ERP implementation or maybe one that didn't work well and how we maybe came in and saved the day or what we did to get the project back on track? Robert (36:40):

The ones that come to mind for me that worked well is at the very beginning we wind up having a meeting with the key stakeholder and they tell us, I'm scared to death about this project. They start revealing things that they're not telling other people in the organization, which is great because I can mitigate that relief. I can show you that there is a way to do this, there's a way to manage that, and there's a way to address your concerns rather until waiting three months in the process and I'm sensing that you're really upset about something or you're really concerned about something. So the great communication ones are an immediate rapport with the project sponsor, with the key stakeholders so that they can meet with us and go, this is really my concern, or you need to watch out for this, or there's an undercurrent that's going on in the city council that you need to know about.
(37:31)
Having that initial communication and establishing that relationship of being able to talk about things like that always leads to project success and successful communication because again, I now know that I can call that person and give them bad news on something that the software vendor just threw at us and not have to go, okay, how am I going to frame this so that I don't get this person upset and do I need to figure out a way to solve it before I bring the problem to them? That's the key. And the ones for me that are problems with communication are almost always clients that just didn't want to communicate either because they don't care about the project they were just told they need to do it. It's not their style to be communicative like that. When the client doesn't want to communicate or stay involved or hold interest, those are when the problems can really start to develop. That's really rare, but it does happen every so often, especially if your project sponsor is someone who doesn't like ERP doesn't care about it, but they got their name picked to run this project and it takes a lot of work to show them, let us guide you on this and make this successful for you. So sometimes there's an initial communication issue in those areas that guess be overcome. Megan (38:49):

Yeah. Do you have any stores you'd like to tell? AV (38:53):

No, I think the stories are pretty common. There's the symptoms of certain issues and they're pretty visible at the outset of the project. So again, going back to effective risk management and identifying who your stakeholders are and how they operate and what takes them off is very critical. So this is why we excel at this or other good consulting companies because they go beyond the technical because again, it's a fallacy to think that these are technical projects. They are. IT projects, you're buying a service and you need to set it up just right, so your operations benefit from it. There's very little technical stuff involved anymore as long as you're implementing a vanilla software as a service hosted environment. Then it comes down to infrastructure and how you're connected. So it's a fallacy again, to think of this as a technical project or an IT project. Again, going back to my, I think I say this every week, think of this as a school building or a police station. This is all of the problems you're going to face with that project will be in this project and more. Robert (40:15):

Yeah, really the way I've always looked at it is your consultant, your advisors on this project should be instilling a sense of excitement in you and tying this to how this is going to make your organization better. Because I tell people all the time, the mechanics of what we do as project managers are great, but they're not exciting. No one goes home and tells the family, Hey, I learned how to build a risk register today from this consultant or requirements traceability matrix. These things are important functions and they're important for the project, but you still have to build that excitement in that the cavalry is coming. We are going to get you out of this functional workaround bad process situation that you're in with this current system that's broken. Let's not forget that the outcome here is to have better service delivery, to have more transparency, to have higher accountability, to be able to share data easily, to be able to allow people to go into a portal to look at the data on their own for your organization, a whole variety of things, and let their housing clients, the ability to house people quicker, get them processed.
(41:24)
There are some key things that tie into this project that are exciting and tie into high level vision, but also the practical thing of the housing specialist that just wants to be able to house this person quicker. That's the stuff to get excited about. That's the stuff to focus on and get people really engaged on because the technical aspects are great. The project management mechanics are great, but at the end of the day, that's what people are going to take away as to why the project was successful. My community's now excited to be able to engage with us as a city now, providing them a lot of tools to be able to do that. That's what people remember and that's what leaves them with that good feeling at the end of the project. Megan (42:02):

Yes, and that's the most exciting part for me in the work that we do, is how we're changing the lives of so many people all at once, right? To see the changes occurring at that level is truly beneficial and it's my why. So I love that. I do want to dive into a little bit, we've talked about this the last few weeks, but the data, learning where your data is and how you're going to convert it and how much you're going to move to the new system. Mackensie asked a question in the chat and I think it's just a good topic to dive into, but what are the most common data related challenges in ERP implementation and how can they be addressed? And I'm going to add to that question. We're talking about team roles, right? Implementation team roles. Whose responsibility is it for the data? AV (42:53):

So it's two sets of responsibilities. I think One is the CFOs and the HRO because they own the data and the biggest decision is how much data do you want to take forward into the new system and without worrying about where it sits or what format it's in and is it compatible, how much work? Most people will say, well, we want everything from the beginning of time, but these are large or small government organizations that have been around for a long time. So they probably have had four different systems. And the last one probably was in a S 400 green screen that was home-baked, and it's not always easy to transfer data. So a lot of the work and money will be spent on data transfers and data cleanup if you're not careful. So that's the decision. Number one is how much data do you carry forward?
(43:51)
And then the second sort of area of responsibility is its, and the vendors, right? If the CFO says, okay, we agree to take four years worth of data to the new system, IT tell me or vendor, tell me how I can archive the remaining 35, 40 years of data and how I can access it when I need to. Because you never know, right? You get a FOIA request or something happens, you have to go back to 1975 to look at a certain po. What are you going to do? So it needs to be archived. We can't just get rid of it. So transferring only three years of data doesn't mean that you get rid of the rest of it. You need to have an archival solution. That's where your IT and vendors, technical folks come into the picture and give you options on how you want to archive data and access it. I think that's the most critical thing in data related decisions. Robert (44:47):

This topic is what by far and large is the biggest threat to timeline and budget because when you start trying to bring 10 years of transactional data over the price tag, the software vendor's going to give you is impressive. It's going to be multiples of what the value of the original contract is. So they're always going to tell you, given enough time and given enough money, sure, we can migrate all your data. It's going to be a question of what's going to be practical and what's actually going to make sense for you. Most organizations only need a handful of years brought over, especially for accounting and especially for transactional data that can be even less. So it's unique for every client, but the cost of trying to bring over everything is very commonly, substantially larger than what the initial investment of the software is. So it's a very critical balance to avoid not putting you on a road where your project cost is now five times what it was, and it's now going to take three and a half years to convert that data. Megan (45:51):

What about data security? When you're talking about implementation, whose responsibility is to mitigate that? Whose is it? Robert (46:01):

Yeah. From our perspective, this is a discussion that needs to start at the very beginning and even to the point of your requirements traceability matrix and matrices, your RFP document that actually goes out for when you're soliciting, define all this early and often so that you ask the vendors the tough questions and more importantly, they'll demonstrate this to you during the vendor demo. If they're selected, show us how this works. Show us how this is actually secured. Send us the documentation on this. Tell us what your backup processes are, what your disaster recovery processes are, because if you wait until after you sign the contract, you will never get that software vendor to become compliant with something that a standard you're being held to like your housing authority or later on you decide, I really need to, as part of my getting cybersecurity insurance, I have to have this type of documentation in place, and therefore my software as a service vendors also need to provide me documentation. You try and ask for that after a contract signing, they're not going to produce it and they're going to continue to kick the can down the road on that particular question. Make it the key focus of your cybersecurity in the procurement process from the very beginning of this process, and we ensure that that is done. It's one of the first questions we ask get brought into a client. Megan (47:24):

Well, I'm going to wrap us up today unless you guys have more thoughts. I do have one last question that I like to ask at the very end about key takeaways. What are the top two or three things that you want our listeners to take away from this live session today? AV (47:43):

One, go look at a very detailed video we have on our channel on project roles and responsibilities. We've talked about this a lot. I think building a robust ERP implementation team is not something you do at the very last minute. If you are a organizational leader thinking about replacing your system or getting one that is more modern, when you make that decision, you have to think about who, if you are leading it, who's going to be your team at the very top. That's number one. Build that executive team because everything is going to flow from that point downwards because if you don't have executive alignment, if you're not pulling in the same direction as far as what the outcomes need to be, you are setting off on the wrong path. So first thing to do is that, so that's my number one takeaway because this is pretty high level. We've talked at length about each role on the project and what work it does, but at the highest level, executive team management is critical. Robert (48:52):

Yeah. I'm going to say what I always say, which is I love giving out free advice, and there's a lot that we talked about in here that has to be specific to your organization, and I want to hear from you on that. Even if, let's say you're an executive director or you're the finance officer and you're watching this and you're like, I don't even have ERP in the budget anytime soon, but some of this is resonating with me, please reach out and talk to us. We would love to talk to you about that and give you some clarifying answers on things that we couldn't always talk specifically about in here because it varies from organization to organization. But I love those conversations and I will give you all the time and attention that you want to try and figure this out. Even if ERP is nowhere near on your horizon yet, just reach out to us. Love to have that conversation. Megan (49:44):

Yeah, and I think for me, I mean, I know we were talking about team roles and responsibilities, but the key to all of this is before you even get to implementation, which you two have already said, this, is to almost lay out an ERP plan. Like, Hey, we're thinking about purchasing a new ERP system. Here are five things I need to do before I even start looking at ERP systems. And that may be something that we talk about in the near future, but it's like laying out the roadmap. Here's our ERP roadmap and here's what each department is responsible for, and here is the team lead for each of those departments or whatever that may look like. I think we always go back to, let's plan for this. Let's not just do it. Let's lay out a strategy and a plan and let's stick to that plan. So thank you guys for joining me today right after the Christmas holiday. I really appreciate it. I think this has been a great chat, and for our viewers, we are on every social media platform, so if you have questions or you have topics or you just want to get to know AVEO advisors, please reach out. We're very active on social media. We have our podcast as well as our newsletter, so be sure to sign up for that. Those are really fun. But thank you guys for your time today. I appreciate it.