In some Business Central implementations there’s a lot of emotion attached to the Go-Live date. Clients pick a date for Go-Live and refuse to deviate. This locked target can be impractical, leaving no room for the unexpected.
At the other end of the spectrum, clients can be too movable with their date. Some delay Go-Live in pursuit of unrealistic system perfection, when really, they need to jump in and get it done.
Fenwick believe in a firm, not fixed Go-Live mentality. Every business is different and you need to find an approach that fits. This comes from planning and knowing your critical success factors.
Ultimately, Go-Live when it’s appropriate, and not because of a date you’ve had in your head since project inception.
Reasons for immovable Go-Live
There are many potential reasons clients insist upon a fixed Go-Live date.
Although these points must be considered, they shouldn’t be the deciding factors. User confidence and ability with the new system should dictate when you hit the big green button. Pushing for an unrealistic date could forsake quality and success.
Predetermined points on a calendar
Ending a financial year on your old system and starting the new year afresh is always appealing, which is why July 1 is a favourite predetermined date. Another favourite is the licence expiry for the legacy system. In order to avoid paying for renewal, clients will set a concrete Go-Live to avoid paying these costs.
Key resources going on leave
Clients think they must finish an implementation prior to a key resource going on leave, as they are fearful of that person not being there to assist with issues post Go-Live.
Operational change
Changes such as introducing a new line of products may require different processes and new levels of operations. Therefore, clients may want the Go-Live of the new system to align with their internal changes to achieve economy of scale. This can create unnecessary complexity in managing various dependencies.
Go-Live schedule checkpoints
During the Project Planning Workshop, the schedule and Go-Live date is set. In a perfect world, the schedule will cater for any issues that arise, but often this is not the case. Like a child who sees Christmas approaching, many businesses cannot bear the thought of waiting to unwrap their shiny new system and insist on an aggressive schedule.
Unknowns along the way can derail this optimism. The following checkpoints should flag if greater effort is required and if it’s enough to consider moving the Go-Live.
At all these points we can assess our Go-Live date. Perhaps users aren’t ready yet, or perhaps the project is becoming more involved than we all originally thought.
Post Analysis Workshops
During workshops, requirements are investigated in detail. Often the required solution can be more complex and require greater effort than originally thought. This may cause a rethink of the schedule.
Post Walkthroughs
In walk-throughs you start to see the system take shape. If the system works well post walkthroughs, the green light is given for end user training to commence. But, if additional requirements become apparent then unplanned development may be needed. With that, comes a rethink of the schedule.
During User Acceptance Testing (UAT)
It’s not uncommon for end-users to find missing functionality during UAT. If what’s missing is critical to the operation of your business, the extra effort to bring it in, may be enough to rethink the schedule.
Tracking Pace to Go-Live
Many of the above occurrences can easily derail a fixed target. Throughout an implementation, we must aim for a steady, linear pace towards a firm Go-Live target. We want to avoid a mad rush at the end to hit an unrealistic target.
Avoid a mad rush at the end to hit an unrealistic target
The Fenwick Project Status Report provides a calculation of the project pace, so we can gauge if a significant ramp up is needed. This allows for early identification of difficulties ahead.
We want to avoid any configuration, development or data conversion activities while end users complete UAT. User training should only start when there’s zero system development tasks remaining and all data is finalised. If we adhere to this rule, then it should be a calm and steady lead up to Go-Live. If adhering to this means the Go-Live date needs to move, then for the sake of quality, that’s what should happen.
Conversely, if you’re ahead of schedule and ready earlier than expected, then the Go-Live can always be brought forward.
The Go-Live choice is yours
Because every business situation is different, we encourage you to evaluate your critical success factors, to define how rigid or elastic they are.
We can provide our recommendations, but the choice is ultimately yours.
You may wish to cut costs in UAT and pay more in Go-Live Support as users are effectively learning and testing in the live system. This approach will add stress for your users, but it may be your best approach if users aren’t willing or able to dedicate the time needed for UAT.
Or, you might continue with UAT until you’re confident users are ready. This will lower your Go-Live Support costs but may increase costs through UAT. It’s horses for courses and only you can decide the best approach for your operation while considering cost, schedule and quality.
Go-Live honesty
As we get closer to Go-Live, concerns can arise from either Fenwick or the client. There’s a stigma that if we don’t meet the scheduled date, we have failed — this isn’t the case. With quality on the line, neither Fenwick nor the client should be scared to mention they aren’t ready.
Often there’s an expectation that throwing resources at a project will get it across the line when time is tight. From Fenwick’s side, we strongly believe that adding more resources isn’t the answer. We pride ourselves on our small dedicated team with a wealth of knowledge. More resources reduces the efficiency of our focused and personalised operation.
Pushing for an unrealistic date because “that’s the date” will burn out everyone involved. Open communication must be encouraged, to be honest with how we feel about Go-Live date.
Don’t expect to know everything at Go-Live
On the other hand, some clients continually put off Go-Live, when really, they need to jump in the deep end and get it done. Halting Go-Live can stem from a fear that users aren’t ready.
Like an L-plater graduating to their P’s, there is still plenty of learning to do after Go-Live, and that learning can only come through live use of the system.
We don’t want to give you a fish – we want to teach you how to fish.
Even if UAT drags out for years, you couldn’t expect to walk away at project completion with a new system operating to maximum efficiency. As users better familiarise themselves, they’ll start to see how the system can be tweaked to make their role more productive.
So, expect Operational Support costs to be greater in the first few months after project close — it will take time to get to a consistent level. What must be emphasised is the importance of having an internal triage process and testing it through UAT. If Fenwick are peppered with support request from end user’s through Go-Live and after project close, it’s going to cost you dearly.
Fenwick don’t want to give you a fish – we want to teach you how to fish.
Go-Live isn’t the death of us
It’s natural to be nervous when it comes to Go-Live time. However, it’s important we take the best route possible to get there. We need to work together with open communication in a steady climb to Go-Live.
