AJC ERP Implementation Escalation to the Steering Committee

Andrea Jones explains when the ERP core team should escalate problems to the steering committee. When a readiness assessment two months before Go-Live showed low user scores, the committee delayed launch by one month and funded extra training to reach the target of 4 on a 1-5 scale.
Chapters
Hi, I'm Andrea Jones and we are continuing our ERP implementation series with my favorite topic which is escalation of issues or problems the core team cannot resolve to the steering committee. Escalation to the steering committee. So we said before during selection, usually it's fairly high level people making the decision on what ERP system you're going to buy. They will participate in the demos, they are thinking about the future state requirements, they are evaluating and adjudicating things. There might be some deep dive demos that subject matter experts in accounting or customer service or operations will do. But you know, ultimately it's the CEO, the cfo, the coo, the leadership team who is making the decision on what system to buy. They do not participate on the day to day activities for the implementation. That would be not the highest and best use of their time. Most likely, especially if you're a business of any couple million dollar, 10 to 20 or more million dollar size, it's not the best use of their time. So when the implementation is happening, we have a steering committee that is comprised of those people and they meet at least monthly throughout the course of the implementation, maybe a bit more toward the end. And they help understand, you know, what the status is, make any big picture decisions on budget or understanding of timeline, whether they want to resource differently, things like that. However, there sometimes are things that happen in between those meetings that do need to be escalated because the core team is not able to resolve it on their own. So for example, I was on the steering committee of an implementation where we had placed a project manager. And so I was participating on the steering committee level once a month, but they called a special meeting because it was two months before GO Live. And we had also helped them coach them in change management for this particular implementation. So they had done a readiness assessment two months before GO Live. They had issued their first round of user training and people were in the sandbox and working on things. And the readiness assessment came back lower scores than they hoped, meaning people did not feel like they were really understanding how to navigate in the system. They didn't feel like they could operate. They felt they needed more training effectively. And so the team needed to spend an extra month doing that. But they did not feel like they could make that decision. Can we postpone the GO Live for another month? So it's instead of two months out, now we're three months out. The project itself was ready to go. Everything technically was pretty much ready to go. They were working on the cutover plan, the last bits of data migration plan and all that. However, the decision to the steering committee had to happen. And so they pulled it in before, you know, they waited too much longer to make that decision. And the steering committee agreed that it would be fine to wait one more month so that the team would be more ready. They did two more readiness assessments, if I recall. So they waited one more month and did more of a deep dive into the training with the team. You know, the ultimate end users did assessments. The score went up a little bit, but not still not perfectly where they want it to be. So our assessments on a one to five scale and before go live, you should be at a four. So they were, you know, before they were at a two, then they were at three. One more month of additional training, especially for the gap areas. Right. Some people were high and some are still lower to get them to that closer to a 4 average before they went live. That's an example of an escalation that sometimes doesn't happen. If it doesn't happen, it's kind of like when your kid tells you the night before school and a big project is due that they're like, oh, I forgot, I need a big poster board and I need to print out a bunch of things in color so I can turn in this gigantic project I've known about for three weeks. And you're like, dude, could you, could you not have told me about that a long time ago? Great. There's nobody there to escalate that decision and that need earlier than sometimes it slides till it's urgent. You do not want that in your ERP implementation. Project managers and change managers too, will help keep the pulse on the organization and escalate anything that the core team can't determine or figure out on their own to the steering committee in a timely fashion so that you're not stuck at Hobby Lobby the night before your big project is due. Right. To follow my analogy, you can tell this has happened to us before. Anyway, I hope that is helpful and gives you a good understanding of why we want a project manager to escalate decisions to a steering committee in a timely fashion in a major project like an ERP implementation. Thanks for watching.










