With our team’s years of experience with JD Edwards, we’ve seen it all: incredibly outdated systems that need to be brought up to date, unorganized data that needs to be sorted through and loaded into the ERP, and, perhaps the most shocking, failed JD Edwards implementations.
Recently, in two separate projects, our team has been recruited to get a failed JD Edwards implementation back on track. In the process, we’ve learned a thing or two about how to recover that project and what can be done to ensure it doesn’t happen in the first place.
When heading into a recovery project, our team starts by putting a structure around the project. That means establishing a project plan, milestones, and interim due dates. Our team does this by using the best from both the waterfall and agile project planning methodologies.
We start each JD Edwards implementation by setting up a traditional waterfall project plan. This plan establishes project milestones and due dates, giving the project team a strict timeframe to work in. Due dates are established by senior management to ensure they are realistic and then the project is planned backwards from the go-live date to the re-kickoff.
Backward planning, as it’s known, has been shown to result in better performance. Starting with the end result keeps that goal always in sight and makes it feel more attainable. It also provides a clearer vision of what steps are needed to meet that goal.
So, our team works with the client to determine the absolute deadline for go-live. From there, we move backwards developing phases, setting milestones, and determining deliverables. Business Process Owners are involved at every step of the way to ensure that their needs are met in each of those phases and that the timeline presented is realistic.
While the overall project plan establishes key phases and milestone dates, it doesn’t dictate what each of those phases looks like. Instead, we like to work in two-week sprints to evaluate what has been completed and what is coming next.
Weekly status meetings are used to plan and evaluate sprints. Depending on where the team is in a sprint, these meetings consist of documenting what is available for testing, reviewing that testing, or deciding what to schedule for the following sprint. This strategy allows our team to follow the appropriate steps and set key milestones, but still provides enough flexibility to account for project changes and delays.
For example, we had built in a full month of go-live prep for an implementation recovery project. However, as we started working through the first phase, we realized we needed more time before moving into the second phase. Instead of pushing the entire project back by a few weeks, we were able to more accurately predict the timelines for future phases. We found we could cut a few weeks from go-live prep and add them to the first phase. This adjustment allowed for flexibility as issues arose in the first phase without compromising the go-live date.
With a project plan in place, our team always kicks off an implementation recovery with reengagement. Often one of the main reasons a project gets derailed in the first place is because the team is no longer engaged. When starting the project over, team engagement is the element that can either make the project or break it.
The first step of the reengagement phase is to identify who is on the project team and who will be interacting with the new JD Edwards implementation. Those business process owners then need to identify which aspects of JD Edwards they interact with daily and are required to do their jobs. Typically, from there, we have the business process owners fill out a form stating what they require from JDE and then send it to their manager for sign off. This further establishes ownership over those business processes and loops in the whole team.
Another aspect of team identification is that business process owners need to identify who else they need to work with. While those people may not work on the implementation directly, their involvement is needed to make the business process owner’s job move more smoothly. Identifying these people from the start clears up any potential confusion.
With the project team members identified, the best way to keep people engaged is often the simplest: make attendance mandatory. We set up weekly status meetings with the business process owners and tracked attendance to ensure everyone was joining the meetings. We also published minutes and a formal status report after each meeting. These steps add some structure to those meetings and hold the team members accountable.
As the project develops, we also schedule assigned times for various members of the project team to meet in a room and actually work on JD Edwards. They navigate the system, process discreet transactions, and interact with the program.
Having this mandatory engagement throughout the project keeps team members involved and aware of the project’s progress.
So, how can you keep your project from going off the rails in the first place? Basically, by following our above steps from the get go. Accountability and structure are the two key things needed to get your JD Edwards implementation off the ground and keep it running smoothly.
When we talk about accountability, it’s not just identifying who is in charge of what. Accountability starts with management and then trickles down to individual team members. The management team needs to hold team members to task and put metrics and rewards in place to motivate the team. Of course, there still needs to be commitment from the business process owners and others involved with the project, but commitment needs to start with senior management.
One of the recovery projects we were involved in initially failed due to a lack of buy-in from the team. When we kicked off the recovery, our team provided structure, due dates, and experience, but none of that would have been effective had their senior leadership not driven accountability from the top down. For example, a few key senior managers would show up at weekly status meetings unannounced. They would drop in at random to keep track of milestones and make sure that everyone was keeping up with the pace of the project. This dedication to the schedule (plus the element of surprise) further encouraged team members to show up to status meetings.
Another way we like to keep accountability high and the team engaged is through weekly self-evaluation. At the end of each week, we have team members grade themselves on their work and understanding of the project. It may seem a little harsh, but we’ve found that it’s one of the best ways to motivate team members and promote self-awareness. Knowing that a self-evaluation is due at the end of the week tends to keep people on task and moving forward.
With the entire team engaged, the next most important way to prevent a failed JD Edwards implementation is to work within a project structure. That can be as simple as setting due dates and sticking to them, but that is often easier said than done.
At one of our recent recovery projects, our client was chipping away at the implementation but they didn’t have a go-live date. You read that right: they didn’t have a go-live date. This shocked our team and was the first thing we addressed. Setting a go-live date has the same importance of any success metric: you can’t be successful unless you’ve defined what success looks like. Whether the go-live date is six months in the future or six years, it needs to be established at the start of the project.
At another of our recovery projects, the client had set due dates for milestones, but they kept letting those dates slip. If something wasn’t done in time they pushed the date back further and further until the initial go-live date was in the rearview mirror. The issue here isn’t setting goals, but sticking to them. This client had a tendency to push their due dates so they could include additional features or developments, but they should instead have been prioritizing the go-live date. When we joined the project, we set a firm go-live date and any non-essential feature that threatened that date was eliminated from the scope of work.
Setting a go-live date and establishing a project structure at the beginning will keep your JD Edwards implementation on track. Setting a realistic date is the first step and actually sticking to it is the second. Don’t be afraid to cut from the scope of work in order to prioritize hitting go-live. Moving things to a “phase two” project is completely acceptable. If you do end up having to push your go-live date back, make sure it’s for a VERY good reason, and then push it even further than you think you need. If you anticipate needing an extra two weeks, push it two months instead to guarantee that this date sticks.
By following these tips, your JD Edwards implementation will be off to a great start. An even better way to ensure success is to work with an experienced partner. Whether you’re trying to get a project back on track or just want to discuss your JD Edwards options, our team is ready to help. Contact us to get your project started.
No Comments Yet
Let us know what you think