A recent JD Edwards project we worked on had all of the classic indicators of a project that was not on the right track. While these red flags were immediately obvious to our team, the client wasn’t initially aware of how these issues would impact the project’s success. To help your team learn from these mistakes, take a look at the following ways you could be screwing up your JD Edwards project without even realizing it.
Unknown Business Processes
One issue that is sure to bring down the efficiency of your JDE project is when the business processes are not widely known. For this particular project, the IT staff knew more about the business than the business owners did, and those that did know some business processes only knew what affected them directly.
When there is no clear communication of business processes throughout the company, things get disorganized. People don’t know what happens when they hand a project off or how departments interact. With any ERP project, if the team can’t connect the dots, then you end up with a disjointed process flow. Even worse, people are more likely to make changes in one area of the business without understanding the ramifications elsewhere in the organization. This can lead the process to break down.
From a consulting standpoint, when the client team doesn’t know the business process, the consulting team has to go in and perform analysis, like a JD Edwards Business Process Review, on the organization in order to figure out the processes. All of that has to be solved before even starting the ERP project.
To avoid this, make sure everyone in the organization knows your company’s business processes. This means making sure they are documented, even if that document is high level. A business operates better and more efficiently when silos are broken down and people talk across departments, and informing them of the overall business process is the first step towards that goal.
Documentation plays a huge role in keeping your team informed. Documentation is part of standard business process, and your organization should have all processes documented, at least on a high level. Your organization will have turnover, so it’s important to get all pertinent information on paper, rather than just in the mind of someone on staff. This keeps everyone on the team informed, no matter how long they have been with the organization.
When it comes to consulting, documentation helps determine how an ERP project will progress. For a complete JDE implementation, documentation helps give an overview of how the company operates. For a BPR project, step-by-step documentation allows the consulting team to tweak those steps and get your organization closer to best practices.
Simply put, if there isn’t a set timeline, then there are no concrete milestones to work towards. If no one knows what needs to be done when, or there’s a lack of coordination to make sure that the disparate parts of a project come together at a certain time, then the project can easily drift. Day-to-day tasks can distract from the project, especially when you can always work on the project “tomorrow.” A lack of timeline was a big reason why this project got off track.
We recommend setting a timeline, no matter how broad. It’s important to have some set markers established so that the team has a general idea of what’s to come. As the project progresses, you can set more detailed deadlines. Think of it like driving across the country: you may know that you want to make it from coast to coast in a week, but you don’t have a set day to reach, say, Kansas. You’ll have a better idea of when you’ll get there as the trip progresses.
For this particular project, the client wanted to keep the project under wraps. It was on a need-to-know basis, and very few people needed to know. The challenge here was that when input was needed from an out-of-the-loop business process owner, our consulting team was not permitted to tell the business process owner why that information was needed. Therefore, it was much more difficult to get the applicable information.
Part of the reason they were hesitant to share information about the project was a concern of backlash from the team. Change can be scary, and the client was worried about how their team would react. However, if you’re concerned about your team’s reaction before a project has started, imagine how poorly it might be received after the change has already happened.
On any major project, communication is key. Everyone needs to know what they are working towards, or project momentum will stall. And, if the team’s reaction is cause for concern, perhaps the issue at hand is not the project, but the people. Any improvement to your organization should be met with enthusiasm, so if your team is not on board, they might be part of the problem.
One issue that we see time and again, and that was a problem during this project, was that the client did not have a project champion. Without someone to act as an internal sales person, the project didn’t receive the buy-in it needed.
If we’ve said it once, we’ve said it a thousand times: every project needs a champion. In order to be successful, your JDE project will need someone to lead the way. This person will pull the project through to completion and cut through disruptions to make sure the job gets done. Just like with timeline, day-to-day tasks will distract from the project at hand. But for the project champion, the project is their day-to-day task. They will keep it moving forward and manage the rest of the client team.
Only Outsourced or Part-Time Developers
Our client’s IT team was made up of subcontractors and, while they were skilled in the technology, they didn’t have the same loyalty to the company that they would have had if they were full-time employees. With a disjointed team like this, some people have more business process information than others, which makes progress tough. Additionally, one of their subcontractors took on another project full-time, so they were only available on nights and weekends. Without consistent access to that knowledge, the project slowed down.
Rather than outsourcing all IT resources, we recommend having a small staff of dedicated IT personnel to handle your core business. From there, you can outsource when needed while still having access to an internal team that is dedicated not only to the project, but the company as well. This, like many of the other tips above, keeps business knowledge accessible and will help the project move forward.
So, there you have it: a few ways to make sure that your JDE project gets off on the right foot. While none of these tips guarantee success, they will help you get out of your own way and start your project strong.
Do you have a JD Edwards project that could use some guidance? Contact our experienced team.