Etiquetas
Por Miguel Kelly | Julio 2013 
En esta octava y última entrega de la saga nos concentraremos en la entrega del proyecto a la operación. Corresponde a esa última parte del proyecto en la que el apuro por llegar al final hace que no seamos todo lo cuidadosos que deberíamos ser:
Fallas en la puesta en marcha y en la entrega del proyecto a la operación.
Se usa el término “Puesta en Marcha” por ser un término usual en los proyectos de inversión, aunque debe leerse como “Asegurarse que la operación, implementado el cambio, se comporte de acuerdo al objetivo del proyecto”.
Cuántas veces uno, en su apuro por llegar al final del proyecto, confunde que el objetivo no es entregar el proyecto a la operación sino asegurarse que la operación brinde los resultados previstos por el proyecto.
Esta causa puede desglosarse en una serie de causas de segundo orden, que listamos a continuación:
- Fallas en el Quality Assurance y las entregas parciales.
Usamos el término Quality Assurance (QA) por ser un término muy usado en los proyectos informáticos que, como su nombre lo indica, corresponde al aseguramiento que lo entregado se comporte de acuerdo a lo planeado.
En el mundo informático existen una serie de tests con marco predeterminado y, a partir de ese marco, se configura un protocolo que la entrega debe satisfacer. Algo similar ocurre con los proyectos de cambio, aunque en este caso el protocolo incluye el comportamiento de las personas involucradas, tanto en su función de operador como de manager y los resultados del test no corresponden a parámetros informáticos sino a parámetros del negocio.
El QA final asume que los QA correspondientes a las entregas parciales se llevaron a cabo a satisfacción. Si una entrega parcial incluía modificaciones que sólo podían ser identificadas cuando la totalidad del cambio hubiese sido implementado y no fue ensayado en su momento, al “saltar” en el QA final (si hubiese una falla) podría significar considerables retrabajos con el correspondiente retraso y la demanda de recursos adicionales.
También puede ser que el protocolo del QA final no testee aquellos aspectos que asume fueron testeados en los QA parciales. El error va a notarse en la operación.
Sin embargo, hay otros males que conspiran en esta entrega a Operación, como veremos enseguida.
- Apurar los tiempos y saltear etapas clave.
Esto ocurre cuando se enfrentan los requerimientos políticos y/o los requerimientos de mercado con los requerimientos del proyecto.
El proyecto puede haberse atrasado por infinitas causas, pero un gerente prometió a su director que el cambio estaría implementado para una cierta fecha y no lo alertó de los retrasos.
También puede haber ocurrido que el mercado adelantó los tiempos que habían sido previstos por el proyecto y se requiere que el cambio esté implementado en una fecha más cercana
Cualquiera de los dos escenarios significa acortar los tiempos restantes del proyecto, cuando no hay tiempo para replanificar.
Una forma típica es discutir: Qué no es esencial para la implementación? Identificarlo y posponerlo.
Ese posponer muchas veces se traduce en que lo que se pospuso nunca se implementa (cuando se llega a la fecha de entrega y esta se pasa con éxito, los ánimos se relajan y los compromisos de recursos se olvidan). Lo no implementado en algún momento, “salta”.
Hay más causas correspondientes a la entrega, como la siguiente.
- No capacitar adecuadamente y a tiempo a los futuros operadores y gerentes en el nuevo escenario.
Como se ha mencionado en episodios anteriores, la capacitación es una condición necesaria para el éxito del cambio.
Y se debe capacitar no solo en la nueva modalidad de operación sino también en la nueva modalidad de gestión (debemos recordar siempre que lo que se busca con el cambio es mejorar resultados). Los cursos deben ser necesariamente “hands on”, simulando el nuevo escenario y considerando no sólo la operación normal sino también los casos extremos que podrían darse.
De la misma manera, el “timing” de la capacitación es también importante. Esta no debe hacerse muy temprano ni muy sobre el momento de la implementación. Se debe dar un tiempo de maduración y de preguntas, por un lado y no sumarlo al momento de la transición donde la atención debe estar enfocada, justamente, en la transición.
Además, durante la capacitación es muy probable que surjan preguntas o situaciones que no necesariamente han sido consideradas en el diseño, pero que, de alguna manera, deben contemplarse.
Así pasamos a la última causa de segundo orden que vamos a tratar:
- Pasar apresuradamente el proyecto a la operación.
De la misma manera que aquellos afectados por el cambio pueden querer apresurar el mismo (como vimos más arriba), de la misma manera el líder de proyecto también puede verse tentado a la misma prisa.
Es como cuando uno sale a cabalgar y, de vuelta, el caballo apura el tranco por llegar a su corral. O cuando salimos de viaje y, cerca del destino, habiendo caído la noche, apuramos la velocidad cuando las más mínimas consideraciones de seguridad no diría que hay que disminuirla.
Las etapas tienen sus tiempos y hay que respetarlos. No se deben forzar los pasos.
Aquí finalizamos esta saga.
No significa que no haya más causas. Las debe haber, y muchas, pero por lo menos quisimos exponer algunas de ellas para colaborar a no caer en estos vicios y hacer fracasar los esfuerzos y las esperanzas contenidas en los proyectos de cambio.
miguel.kelly@managersgroup.com
Managers 