Go-Live Date / Data de Lan?amento

Go or No-Go

If there is an event which I think tense, it is the start-up of a new system, especially in large projects developed through the waterfall methodology. Yes, waterfall projects are still used, although the agile methodology has gained a lot of space in companies. Regardless of the most suitable methodology, the Go-Live is a magical moment which divides the past from the future.

The operational start-up of a new system is always a delicate moment. It usually comes with new processes, different responsibilities and more technology. We started by letting the family know that we won't be available for an uncertain period, and we got ready for a few rounds of pizza and lots of coffee. For more tests and trainings that are carried out, the production environment can hold unpleasant surprises, since the staging environment does not always faithfully reflect the production environment. Nothing is more frustrating than canceling a Go-Live on the eve or performing a Roll-Back – I have experienced both cases. I learned that the delay of a successful project ends up being forgotten in a short period of time, while come into operation with an immature or inconsistent project leaves almost eternal scars.

The checklist for starting a new system can be compared with the checklist procedures performed by the airplane pilot before the departure: a series of tests and validations also considering the external environment. However, we have an aggravating factor because each project is unique and has its own characteristics. Therefore, it is not an equally repetitive job.

Go-Live performed, at what time can we consider the project a success or a disaster? Well... this answer varies a lot according to the intensity and diversity of the operations carried out in the productive environment. There are projects that success or failure appears in the first few hours, others require up to a few months.

For us, technology practitioners, projects are part of our daily lives. In theory, we always looked for mitigants for the risks of departure, with alternative plans or reversals for the old environment which worked well or badly – everyone knew its strengths and weaknesses. But in some scenarios, this may not be feasible. Once, a group of directors asked me what Plan B was in case of a problem. I positioned myself, without hesitation, “Plan B is to make Plan A work”. It was a merger project which needed to be executed in a few weeks and there were no resources or time to come up with an alternative plan. In this specific situation, not committing 100% of the resources available in the master plan would be the biggest risk. Of course, technology and business were well known in this situation.

To wrap up... Why “Go or No-Go”? One of the project management rituals is the departure confirmation meeting. A moment to be true to yourself and the company, neither optimistic nor pessimistic. Trust must be well reasoned and risks calculated and shared.

Vai ou N?o Vai

Se tem um evento que julgo tenso, é a partida de um novo sistema, em especial em grandes projetos desenvolvidos por meio da metodologia cascata. Sim, projetos em cascata ainda s?o utilizados, apesar de a metodologia ágil ter conquistado grande espa?o nas empresas. Independentemente da metodologia mais adequada, o Go-Live é um momento mágico que divide o passado do futuro.

O início operativo de um novo sistema é sempre um momento delicado. Normalmente vem acompanhado de novos processos, diferentes responsabilidades e mais tecnologia. Iniciamos por avisar a família que n?o estaremos disponíveis por um período incerto, e nos preparamos para algumas rodadas de pizza e muito café. Por mais testes e treinamentos que s?o realizados, o ambiente produtivo pode guardar surpresas desagradáveis, já que o ambiente de homologa??o nem sempre reflete fielmente o ambiente de produ??o. Nada mais frustrante que cancelar um Go-Live na véspera ou executar um Roll-Back – já vivi ambos os casos. Aprendi que o atraso de um projeto de sucesso acaba sendo esquecido em um curto espa?o de tempo, enquanto entrar em opera??o com um projeto imaturo ou inconsistente deixa cicatrizes quase eternas.

A lista de verifica??o para partir com um novo sistema pode ser comparada com os procedimentos de averigua??o feitas pelo piloto do avi?o antes da partida: uma série de testes e valida??es considerando também o ambiente externo. Entretanto, temos um agravante pois cada projeto é único e tem suas próprias características. Portanto, n?o é um trabalho igualmente repetitivo.

Go-Live realizado, em qual momento podemos considerar o projeto um êxito ou um desastre? Bem... essa resposta varia muito conforme a intensidade e a diversidade das opera??es executadas no ambiente produtivo. Existem projetos que o sucesso ou o insucesso aparece logo nas primeiras horas, outros requerem até alguns meses.

Para nós, profissionais de tecnologia, projetos fazem parte do nosso cotidiano. Na teoria, sempre buscamos mitigadores para os riscos da partida, com planos alternativos ou de revers?o para o ambiente antigo que bem ou mal funcionava – todos conheciam suas qualidades e seus defeitos. Mas em alguns cenários isso pode ser inviável. Uma vez, um grupo de diretores me perguntou qual era o Plano B em caso de problema. Me posicionei, sem hesita??o, “O Plano B é fazer o Plano A funcionar”. Era um projeto de fus?o que precisava ser executado em poucas semanas e n?o havia recursos, nem tempo para viabilizar um plano alternativo. Nessa situa??o específica, n?o comprometer 100% dos recursos disponíveis no plano principal seria o maior risco. Claro, tecnologia e negócio eram bem conhecidos nessa situa??o.

Para terminar... Por que “Vai ou N?o Vai”? Um dos rituais da gest?o de projetos é a reuni?o de confirma??o da partida. Um momento para ser verdadeiro com você mesmo e com a empresa, nem otimista e nem pessimista. A confian?a deve estar bem fundamentada e os riscos calculados e compartilhados.