Did I ever tell you the definition of Go-Live?

  Have you ever wondered what exactly happens, and what flows should be followed once a customer project extension is requested? What if you’re supposed to be a part of this process? This article intends to answer the above-mentioned questions so that you’ll have a better view of the whole idea behind it.

  I remember myself feeling excited about the fact that I got involved at that time (a bit more than a year ago) in a customer project extension. Client, let’s call him XYZ (really fancy name), ordered for their warehouse a separate module that would simultaneously perform receiving and sorting of the stock. The whole idea behind this particular project sounded for me un-familiar due to the simple fact that I didn’t have any clue about XYZ itself at that time, nor how their warehouse looks like.

  What would normal people think of it, considering the mentioned above circumstances? Exactly, “Hell yeah, let’s do this!”, that’s what I thought at first glance. The good thing is that initially this project was thought to be done by a well-organized team that would consist of:

  • project manager, that would basically organize all the required meetings with the client and within the team, making sure that each member delivers constantly a valuable input;
  • 2 software engineers, whose mission is obviously writing the software part, asking questions about client expectations and handing over the requested solution;
  • 1 PLC engineer, responsible for building that bridge of communication between software and hardware part (conveyors);
  • 1 testing software engineer who, in my opinion, had one of the key-roles, proving that both the hardware and software solutions are working as expected. Jokes aside, that’s what he was hired for, using the system not just from developer’s perspective and trying to break it down as soon as possible (fortunately he didn’t manage to achieve this goal).

  Once we were assigned to perform this mission, several steps had to be done before the start:

  1. The team had to get to know about the specification document. What did the client request? What needs to be done exactly to implement this solution and how theoretically that would look like in the end?
  2. New Kanban board had to be created for this extension, dividing the entire Epic into multiple stories and their respective subtasks.
  3. A private branch was necessary for committing all Java code changes whenever they were ready to be tested/used.
  4. Separate configured VM where usually any new part of this functionality had to be deployed. Even though this particular point did not work as expected since each team member had to prepare locally the environment so that changes made by others would not interfere with their own.

  I don’t want to dig into too much detail, about how exactly this extension was developed, skipping technical aspects, about how many sub-tasks were implemented or how many bugs were discovered and solved during different project life cycles. I would like however to mention the organizational part, which in my opinion had a big impact on the final result and was the key to the successful delivery of the product.

Team componence formula

  Above-mentioned team structure was the perfect combination. Of course, this particular formation doesn’t play well under all circumstances and scenarios. Most probably for another project, either much bigger extension or some which doesn’t really require that much effort, this composition won’t do the trick.

  I think that the project manager should do in advance all required calculations for the planning and the needed effort so that the number of people engaged doesn’t change afterwards. I’m pretty sure you won’t agree with this point of view, telling me that during project calculation phase errors can be made. That’s true, but with experience, this risk should be reduced almost to zero probability. In our case either the project manager had 30 years old experience (even though he’s 35 years old), or maybe we just got lucky.

Well described requirements

  Team members have to know exactly what they are supposed to deliver. To accomplish successfully this part, functional documentation has to be clearly described with as many details as possible. In case of any ambiguities in specs, don’t ever hesitate to ask for clarification. That could happen because of many reasons, like a vague explanation in the initial document, the client doesn’t really know what he wants, or team members don’t have enough knowledge about the project itself.

Full commitment towards the final result

  Once the scope of the software extension is known for every participant, we can safely start the division of tasks between each member. Make sure everyone has a workable environment, where local tests can be performed. More than that, keep in mind that it’s always good to hold an initial backup, that might come in handy if you want to start again with your changes from the beginning.

  Meetings are supposed to be held frequently, either on a daily or weekly basis, so that the Kanban board can be updated accordingly. During these meetings, all team members should participate. Keep the focus on communication, which is necessary in those particular cases.

  Therefore, we finally got our project working only in In-house environment. We didn’t know how it will behave after the update on the production server. Of course, the best way to check this was performing UAT (User Acceptance Tests) on a Test environment. To succeed with this mission we were supposed to travel on-site and try it out. Based on our experience, several points have to be mentioned that need to be checked before UAT occurs:

  • User acceptance tests should follow a predefined test plan that should be created before going on-site. This suite of tests has to be discussed in advance with the project manager and client as well, to avoid any inconsistencies that could appear during normal test execution.
  • Make sure accommodations for your work are well prepared. There should be a ready working place (internet connection, tables, chairs, etc.) once you arrive there. Don’t forget that safety goes first (shoes, helmet if required) and it should be arranged before-hand.
  • All software/hardware changes are ready and updated on the test environment before you get to the customer. In my opinion, it’s better to have a ready to use project on your arrival.
  • Valid driving license driving experience. Though this particular point is optional, it’s good to have it if you don’t want to bother other colleagues to drive you to the warehouse (believe me, I felt guilty and uncomfortable at that time).

  I have to say that the final result of the UAT process was much better than we expected. We didn’t have to fix that many issues which appeared during these tests.


  However, I have to admit that some stressful situations did happen during my visit. Perhaps you want to look more professional in the client’s eyes, but you can’t, just because you’re too nervous in particular cases. In my opinion, I have learned some lessons that have helped me in further similar experiences:

Never tell the customer that you don’t know what’s the root cause for a certain problem

  Often there will be several supervisors/managers testing new functionality and I am pretty sure they will find ‘bugs’. If you’re not lucky enough, you’ll get attacked by a group of 4-5 people simultaneously, everyone telling you about some distinct incident they spotted. Don’t panic, keep calm and assure them that each problem will be handled and that for each problem there is currently someone working on it (that’s the advice that was given by one of the supervisors by the way).

Invest 30-45 minutes and visit the whole warehouse

  It’s better to know how everything is arranged in all subareas. At least you’ll have a better vision about where the extensions stand, compared to the whole system.

Be open-minded to communication

  This could sound a bit generic, but I think that customers will more likely greet a person who they can easily communicate with. Even though you need to prove a professional attitude, I think it’s important that your soft skills are at a high level too.

  In my opinion, not everything that has been described in this article is a perfect formula of a successful project. This list can be adjusted, but it’s up to you to mention what works perfectly and what should be avoided.

Share this article:

Dumitru D.
Java Developer