In nearly every digital transformation I have experienced in my career, there has been a crucial decision to make: should we postpone the go-live date or should we continue as planned and implement on time?
In every digital transformation project we undertake, there is always a question regarding whether or not we should proceed with the go-live phase. Typically, towards the end of a project, there is a milestone called the "Go/No-Go decision." This serves as the final checkpoint to ensure that everything is ready, or at the very least, that we are comfortable with the risk involved in going live. However, there are instances even earlier in a project where it becomes evident that something is amiss, and we are off track. In such cases, the predetermined go-live milestone in our plan may pose too much risk.
Organizations often grapple with the dilemma of whether to delay the go-live or proceed as planned and go live on time. Making this decision can be challenging, and organizations often lack clear guidance, relying on guesswork to find the right answer. Today, I would like to discuss some of the considerations you should take into account when determining whether or not to delay the go-live phase.
Before delving into the reasons for considering a delay in the go-live phase, it is important to take a step back and understand that the go-live milestone is just one part of the transformation process. While undoubtedly a critical step, it is not the endpoint where everything will be perfect. In fact, it is quite common to continue optimizing and stabilizing after the go-live phase, aiming to maximize the value derived from the overall transformation investment. Things may not be exactly where you want them to be at the time of go-live, but the key is to recognize what is "good enough." The goal is to ensure that go-live is not only a smooth event that doesn't disrupt the business, but also sets the stage for future success and improved business optimization.
Therefore, it is crucial to understand that go-live is just one step in a process, albeit a significant milestone that should be treated seriously. It is not the final step in the process; there are further opportunities to optimize and ensure the stability of the implementation that has just been carried out.
One of the most important considerations you should make and questions you need to ask yourself is the cost of delaying the go-live and how it compares to the cost of not delaying it. This aspect is often overlooked by many organizations. During a transformation or implementation process, there is often a strong desire to reach the go-live stage. Teams are exhausted, stressed, and chaos may be prevalent. After months or even years of work, the anticipation to witness the live results within the organization grows. Additionally, senior executives, board members, and higher-ups may become impatient. They are tired of the expenses and distractions associated with the project and want to see the go-live happen promptly. Consequently, there is immense pressure to meet the go-live target and avoid project delays that can lead to increased costs.
However, what is frequently neglected is the potential outcome if we do not delay the go-live. While it may appear that we save money in the short term by adhering to the predefined timeline and containing costs, it is essential to consider the long-term consequences. What does the go-live look like in such circumstances? What damage could it cause to our business? There have been instances where clients focused solely on achieving the go-live date, only to encounter significant problems afterward. The effort and expenses required to clean up the mess exceeded what they would have spent if they had invested a little more time and effort to ensure a proper implementation and go-live.
It is crucial to approach this decision not just from the perspective of the project itself, but also considering its impact on business operations. While hitting the go-live date prematurely may save some money initially, it introduces additional risks to the organization. This, in turn, can lead to lost revenue, decreased profits, dissatisfied customers, diminished shareholder value, and substantial financial implications. It becomes a trade-off—a blend of art and science—where you must carefully weigh the potential downsides of not delaying the go-live against the added time and resources required to ensure a successful implementation.
When making the decision of whether to delay the go-live or not, it is inevitable to encounter a diverse range of opinions. This is entirely normal and expected within any organization. Internally, some individuals will advocate for staying the course and not delaying the go-live, while others may argue in favor of a delay. Additionally, external voices, such as third-party vendors, will also provide their input. It is crucial to recognize the motivations behind these perspectives and recommendations.
For instance, if your team's structure includes a go-live bonus, it is highly likely that they will exert significant effort to meet the go-live date, as their bonus is tied to it. Similarly, if you have a fixed-bid contract with a software vendor, they will prioritize hitting the go-live date to avoid exceeding the agreed-upon time and budget, which affects their profit margin. Understanding the economic incentives and self-interests involved is important, as they can influence decisions that may or may not align with the best interests of the organization. By recognizing these biases, it becomes possible to objectively evaluate and determine the right course of action for your organization.
One option and strategy that is often overlooked in the binary decision of whether to delay the go-live or not is considering what actions can be taken during the delay. If you choose to delay the go-live, it is commonly assumed that you will continue running at the same monthly cost rate for the extended period. However, if you catch this early enough and make the decision to delay the go-live early in the process, you have the opportunity to reevaluate and adjust the entire project plan and staffing approach, thereby reducing the time and money spent.
For instance, let's assume that you are currently spending $200,000 per month on the project. Each month that passes, this amount is allocated to consultants, technical implementers, and project support. If the projected duration is another six months, but you decide to push the go-live date to nine months from now, instead of spending $200,000 per month for nine months, you can throttle back the spending to, let's say, $150,000 or $160,000 per month. By slowing down the spending rate, you stretch out the expenses. This is an option that many organizations fail to consider, partly because they do not view it as a viable solution, and also because system integrators and technical implementers may push back against it, as it defers their revenue. However, it is essential to look beyond individual economic incentives and prioritize what is best for the business.
If the right answer for the business is to push out the go-live date, one way to minimize the negative impact of the delay is to adjust and right-size the spending rate. We should spend only what is necessary. However, organizations often face challenges when the initial proposal from the software vendor assumes a 12-month implementation duration, even if the realistic timeline was always 18 or 24 months. In such cases, the software vendor may not automatically adjust their staffing to accommodate the longer timeline. It becomes the responsibility of the implementing organization to push back and ask critical questions, such as whether the current spending rate is necessary and if it can be reduced to align with the extended implementation period, if a delayed go-live is deemed most appropriate for the organization.
Another option, if you find it unfeasible for your organization to delay the go-live date, is to reduce the scope of the project. Instead of attempting to accomplish everything initially planned by the original go-live date, you can scale back the scope. However, I recommend focusing on cutting technical scope if you decide to reduce scope. By doing so, you will decrease technical complexity and allocate more time and resources to ensure the success of the people and operational aspects of your transformation. If you prioritize these two components, even if you don't achieve as much technological progress as initially envisioned, you are more likely to have a successful transformation.
I aim to provide you with recommendations that offer alternative perspectives and approaches, rather than limiting you to binary choices. These suggestions can help you navigate the complexities and politics involved in making these decisions and allow you to explore different scenarios.
When faced with the decision of whether or not to delay the go-live, there are a few common mistakes that I encourage you to avoid. These mistakes are often made by organizations during this decision-making process.
One of the initial mistakes organizations often make in a project is attempting to expedite the implementation process and achieve a quick go-live by neglecting implementation readiness and overall project planning. They believe that by bypassing this initial two or three-month period, they can save time. However, the reality is that although it may seem like a short-term acceleration, I can assure you with almost complete certainty that you will end up spending much more on the implementation itself compared to the time saved by skipping implementation planning and readiness. Therefore, it is crucial not to skip implementation readiness and planning.
Another shortcut that organizations often consider to expedite their go-live is to bypass or skip the definition of future state business processes. They believe that by deploying new technology, the technology itself will provide the answers on how their business will operate going forward. However, this is a significant mistake. While it may accelerate things in the short term, it creates confusion and uncertainty later in the project, resulting in a lack of direction. Consequently, you will end up spending considerably more time trying to determine your desired outcomes while the project is already underway. If you had taken the time upfront to define your future state before delving too deeply into the technology implementation, you could have avoided such issues.
Skipping or accelerating the user acceptance testing process is another common and risky proposition. Organizations often consider reducing the number of testing cycles from three or four to just one or two, believing that it will save time and increase the likelihood of meeting the go-live deadline. However, this decision carries significant risks. It escalates the project's overall risk profile and greatly increases the potential for resistance to change. By bypassing thorough user acceptance testing, individuals may not fully comprehend or become comfortable with the future state of the system. There are numerous reasons why this approach should be avoided. It is crucial not to overlook or rush through user acceptance testing as a means to achieve the go-live milestone.
Another common mistake organizations make in their attempt to meet the go-live milestone is to underestimate or overlook change management and training activities. They might think that a few weeks of training before go-live is sufficient, considering it as their change management strategy. However, this approach is a recipe for disaster. While it may expedite the project timeline, it significantly increases the likelihood of a chaotic and problematic go-live, particularly in terms of operations and organizational aspects. Skipping or glossing over change management and training is a risky strategy that should be avoided at all costs in order to achieve a successful go-live milestone.
One final recommendation is to not ignore the risks associated with your transformation. As you approach the go-live milestone, it's natural to seek good news and focus on positive outcomes after enduring chaos, stress, and concerns about meeting the go-live date. However, this mindset can lead to biases and create an echo chamber where only favorable information is acknowledged. While it's possible that everything will go smoothly, going live itself is inherently risky, and it's crucial not to escalate that risk by disregarding potential risks.
To mitigate these risks, it's important to have a comprehensive understanding of them and develop strategies for their mitigation. Simply ignoring or failing to identify risks doesn't make them disappear. Recognizing and acknowledging the risks is key. If you don't already have a robust list of identified risks, it's likely that they exist but haven't been identified yet. Therefore, it's essential not to ignore risks and seek objective assistance in identifying and addressing them. The goal is not to be excessively negative or create unnecessary concerns but to confront the risks head-on and increase the likelihood of a successful go-live within the designated timeframe and budget.
I hope this guidance helps you navigate the challenging decision of whether to stick to the original go-live date or delay it. It's never an easy answer, considering the political and organizational dynamics that come into play. While I haven't delved into those specific challenges here, I wanted to provide objective reasoning and logic to aid your decision-making process in an unbiased and objective manner.
I would enjoy brainstorming ideas with you if you are looking to strategize an upcoming transformation or are looking at selecting an ERP system, so please feel free to contact me at firstname.lastname@example.org. I am happy to be a sounding board as you continue your digital transformation journey.
Be sure to download the newly released 2023 Digital Transformation Report to garner additional industry insight and project best practices.