Go live is the milestone your company has been waiting for. It marks the end of your initial project and is a time to celebrate the launch of your company’s new and improved technology. While go live can be a celebratory occasion, going live too soon can harm your company as an unreliable site can result in customer dissatisfaction and faulty business functions. There are a variety of reasons as to why companies go live too soon, and in a recent project our team had a firsthand look into these reasons and how they affected the company’s internal processes and website functionality after launch.
Our client is a global distributor of chemical specialty ingredients with branches, manufacturing plants, and warehouses all over the United States and Europe. Our client wanted all business units to run on the same version of JDE. In order to accomplish this our client needed to complete a global JDE E1 9.2 rollout that involved various process improvements based on the current JDE system one business unit was using. The Briteskies team was responsible for the United States and Canada rollouts.
A global rollout required a global template, meaning business processes were predefined and the ultimate goal was to put global processes in place that ensured all divisions were consistent. Our client set aggressive go-live dates for multiple divisions, so a pushback in one go-live date would result in the push back of other divisions’ go-live dates. This kept our client’s priority on maintaining their timeline as opposed to focusing on what the project needed in order to be completed correctly. The Briteskies team worked with the individual business units but since it was a company-wide initiative, the ultimate decision maker was corporate.
This project highlighted the importance of company culture and proper testing. Cutting corners or being misleading about a project’s process helps no one and can lead to damage down the road. Here’s what we learned during this JD Edwards project.
A supportive and understanding outlook from corporate and an honest project team are necessary when determining an appropriate go-live date. For example, during internal project meetings, members of the individual business unit teams had open and honest dialogue with the Briteskies team, where realistic go-live dates were set. However, during group phone calls it seemed as if the honesty dissipated as the internal project team members folded to corporate’s unrealistic go-live date expectations. The team failed to tell them ‘no’ or express concerns with such aggressive dates. This caused the go-live date to drive the go-live decision, instead of the site’s readiness.
It is important to encourage project teams to be transparent with corporate. As the team members on the ground floor of the project, you can’t just tell others what they want to hear; you must share what is actually happening. A lack of transparency can result in setting unrealistic expectations for your project. Giving honest appraisals of a project status is necessary for corporate to have a full understanding of why a go-live date was set or why it needs to be moved back.
Failing to tell corporate “we’re not ready” may cause tension but launching a site too early will cause complications. When explaining to corporate a push-back is needed, we recommend adding even more time than you think you will need. That way, if something else unexpected comes up you have time to deal with it, instead of having the push back conversation again.
Our client had three big installation projects going on at the same time: JD Edwards, Salesforce, and a product data management software (Product Hub), all with similar go-live dates. This caused even more pressure to keep the original go-live date and eventually, something had to get cut from the timeline. The client decided that they didn’t want to sacrifice time to testing. Not testing a new site is kind of like a blind date; you have an idea of what is going to happen, but you really have no idea how it is going to go. While it could be successful, it could also be a monumental disaster.
In our client’s case, hitting their go-live date became more important than complete comprehensive testing. Due to lack of unit testing there was significant differences in the pricing and cost data, as the data management system and JDE system didn’t correctly match up. There was interconnectivity between the other projects and JDE, and that wasn’t thoroughly tested either.
Our client ran into further testing issues when they started integrated testing too close to the go-live date, which didn't give them enough time to thoroughly test the projects. They also skipped some important features that needed to be tested to ensure that everything was functioning together properly.
Ideally, teams should complete all necessary unit testing before moving onto the next phase. Give your project team enough time to properly complete integrated testing, in some cases even doing a second pass to make sure all info coming in and going out is working as it should.
A true win isn’t about hitting your go-live date but creating a streamlined, smooth-running site. Sending your site live prematurely may give you the short term success of telling corporate “we met the deadline,” but what about long term success?
Without adequate testing, your site is at risk for future complications like not supporting traffic loads or being able to run the necessary applications. It can take double the time and money to fix problems after you’ve gone live, as opposed to just initially pushing the date back and fixing all issues beforehand.
While this client hit their goal go-live date, the site was having problems fulfilling orders and catching up on basic business functions almost as soon as it went live. By not allowing for an appropriate and realistic project timeline, the client now has additional issues that need to be fixed on their brand new site.
Pushing back your go-live date can seem like a catastrophe, but it’s not. Of course, the goal of any project is to hit or beat the deadline, but it’s normal to run into unforeseen problems that can cause delays. At the end of the day, it’s more important to have a completed site that accomplishes what you set out to achieve than a subpar implementation that met an arbitrary go-live date.
No Comments Yet
Let us know what you think