Have you been in a situation where you are trying to implement a new technology and had to roll back two times? What did you do? keep pushing or look for another solution?
Sort by:
A roll-back should be really analyzed to understand the reason that it was required. If it is because the solution is not working or other steps were not done correctly. Depending on this you should evaluate if you are forcing a technology solution that does not cover the needs or you need to work on some missing steps or just in the adoption to the users.
If you faced this, and "apparently" solved all the steps and when trying to launch the second time you have to roll back again, it is clear that there are more things than the ones being evaluated.
I would perform a full RCA to identify why it happened twice, and if the solution is really valuable to the business. Only if you can resolve all the underlying issues and the business is pressuring you to continue then plan for a new release. But, it seems that solution may not be the right one. Involve the partner (or the company/team that develops/support the product or solution) to get their input on how to make this successful.
Was the rollout planned but did the plan miss any items from the scope of investigation and sandbox testing to prove that the prod deploy will not have the hiccups?
If the technology is critical for business enablement and second hiccup itself is progress the first, then as Ben said, it is worth taking it forward.
Technology and tool implementers may not have envisioned all real life scenarios and tested so extensively and it is not even possible to unearth all combinations in lab setups and tests. So, if the tool vendor is genuinely working and collaborating without stonewalling, it is also a chance to give it a chance to continue.
More fundamentally, how well is your team owning and stepping up to drive this?
As you said it is new technology, we can guess you don't have a solution currently, the current one has been business hindrance, costly or never fully worked. And if the new tech is a great (and maybe probably an empty) promise made and bought into, then assess how many more potential gaps would be encountered and how much of your team time will be eaten into if you decide to take it further along. Is this a team dedicated and not affecting other critical functions in the org? If so, then it is a luxury to have such a team and your company may have a lot to throw at.
About looking for another solution, during evaluation of the new tech, were there alternatives identified? What is the guarantee another one won't give similar troubles? Have they been vetted and has some inhouse knowledge about the alternatives too?
That depends. If the rollback reason was the same both times, and we did not have a clearly defined avenue of inquiry to expect a different result on any further attempts, then it would be time to cut losses and move on. However, if the rollback was necessary for different/multiple reasons, then that might be a different story. If there were progress and a second, different roadblock occurred, that likely warrants a reason to continue trying to take the original objective.
I echo the sentiment that some of the others have expressed here. The term "roll back" implies something went wrong with the deployment of a project or solution to production.
For example, if this project leveraged a waterfall project methodology, perhaps the project successfully traversed the requirements, design, build, and test phases, however something went wrong in the way it was technically deployed. In that case, this would likely be caused by a procedural oversight, change management deficiency, poor test planning, or insufficient cutover plan. If so, it would be unfortunate to write-off the investment made in the other phases due to an operational flaw like this. With this scenario, it would be advisable to really dig into what went wrong, learn the lessons, and implement some safeguards to ensure you don't experience this again with your next attempt. Also, seeking out a different solution will not necessarily eliminate the possibility of experiencing this again, if the cause was related to project type mechanics.
On the other hand, if the "rollback" was more related to a missing or immature capability, feature, or functionality, then perhaps this scenario would benefit from a fresh market scan, to see if there is a solution out there that better meets the business requirements. In this scenario, it's really important to start with a strong foundation of requirements. Then, the stakeholders can score the ability of each solution's potential to meet those requirements, so that the selection process is very transparent, objective, and informed. Then, when the testing phase rolls around, it's important to have test scripts that trace back to all those functional requirements. So, if a solution is immature, then this would be uncovered in the testing phase well before a deployment is even considered. Also, for complex solutions, it would not be uncommon to seek out a demo, trial, or proof-of-concept, to further validate assumptions on product selection well before significant time and effort is invested into a larger scale build, testing, and deployment. Hope this helps!