Jose María González López
Project manager y Fundador de Habilis Software http://www.habilissoftware.com/
Hundir un proyecto no es tarea sencilla. Hace falta ser un buen conocedor de todas las metodologías de gestión, de los métodos de control y medida, de las habilidades directivas y motivacionales, de los modelos, técnicas y herramientas de gestión de la información, de las estrategias de control de riesgos, del pensamiento divergente y de todos los consejos prácticos que existen para poder ignorarlos y conseguir que un proyecto se hunda, sin que se note, incluso desde su gestación.
Y digo "buen conocedor" porqueno vaya a ser que, por no conocer algo, se te olvide ignorarlo y entonces el proyecto llegue a buen puerto. Y digo "sin que se note" porque el truco está en que no se note. Ahí es donde se distingue el verdadero profesional del aficionado.
¿Por qué un decálogo para hundir proyectos? Pues muy simple: Psicología inversa.
Dado que estamos inundados de información y sabios consejos para conseguir finalizar proyectos con éxito y, aun así, sigue existiendo un altísimo índice de fracaso en los proyectos, he decidido hacer algo distinto al resto: recopilar todo lo que he podido constatar que sirve para hundir un proyecto y publicarlo... a ver si así dejamos de hacerlo...
Voy a plantear de inicio las suposiciones de que eres tú quien inicia el proyecto desde el principio y que posees la fortuna de tener capacidad de decisión (al menos, funcional) y de que el proyecto es de gran envergadura y en una empresa o para un cliente de importancia. También me gustaría centrar el decálogo en el entorno de las nuevas tecnologías (lo siento, es mi ámbito, pero os animo a que adaptéis el decálogo al vuestro).
Torpedo 1. SOW y requisitos principales
¿Tu proyecto tiene un SOW (Statment of work o enunciado del trabajo) que incluso ya indica unos requisitos de alto nivel?, ¿una RFP quizás? Comienza por ignorarlos, por lo menos en lo que a los requisitos se refiere. Ten en cuenta que es aquí donde vas a encontrar las directrices generales de trabajo y, posiblemente, requisitos ejecutivos por los que te acabarán preguntando y que pertenecen a las partes interesadas que más influencia tienen en el proyecto. Satisfacer estos requisitos no puede conducir más que al éxito. Tratemos en la medida de lo posible de no documentarlos debidamente y mucho menos en realizar una trazabilidad y un seguimiento... No, nada de eso. Por supuesto, trata de alejarte de herramientas CASE que te ayuden a organizar la información de los requisitos (como Enterprise Architect o PMP Mobile Suite RM para android).
¡Hey! ¿Qué es esto? ¡Sí parece un business case! Puedes mirarlo bien porque esos son los números que tienes que encargarte de romper. Por supuesto, no trates de buscar factores de riesgo en el cálculo del ROI o en los factores de cambio que hagan que el proyecto deje de ser viable en un futuro. No conviene tener en cuenta esas cosas... es hilar demasiado fino.
Torpedo 2. Identificación de las partes interesadas
Un punto a tratar de gestionar pobremente es la identificación de las partes interesadas. El ámbito de cada tipo de proyecto, tu experiencia en dicho ámbito y tu capacidad de pensamiento divergente te darán las claves para identificar adecuadamente a las partes interesadas. La norma a seguir es que cuanta más gente ignores, más rápido hundirás el proyecto. La excepción es que, dado que no tiene que notarse, es mejor tratar de no identificar a determinados interesados que harán que todo se dificulte.
Un buen comienzo para esto es no informarse bien acerca de dos cosas: La estructura de la organización y los activos de procesos de la organización. Así pasarás por alto temas como dependencias jerárquicas del personal, áreas que puedan verse involucradas en tu proyecto y sus responsabilidades, centros de coste a emplear para cada fase de tu proyecto, si ya hay procesos y procedimientos definidos para proyectos como el tuyo, protocolos de puesta en producción, protocolos de seguridad sobre datos, requisitos iniciales de calidad e incluso conocimiento práctico o material de proyectos anteriores...
Un consejo estupendo es no involucrar al director o responsable de sistemas de la empresa. Trata de evitarle. A lo mejor al principio él se interesa por ti porque ha oído de tu proyecto pero te dejará tranquilo después de una reunión o dos. Una buena parte de los problemas en las puestas en producción (cuando ya no hay tiempo de proyecto ni dinero para tenerlo) provienen de la no identificación de los responsables de éstas áreas, los cuales aportan sus requisitos, normativas, protocolos y posibles auditorías de código justo en el último momento.
Puedes incrementar el impacto, durante las dos primeras reuniones, tratando de ser ambiguo en la definición de la arquitectura de tu proyecto y de las necesidades que el área de sistemas tendrá que solventar. Nada de hablar de aprovisionamientos tempranos de hardware o de máquinas virtuales ni de compra de licencias de software y tampoco de protocolos de puesta en producción o de disponibilidad de usuarios de sistema. ¿Tu proyecto tiene salida a internet? Entonces no menciones socket seguros (https) ni sus costes asociados y tampoco los requisitos de seguridad que el área disponga y las posibles auditorias de código que exijan. Todas estas cosas convienen que surjan de repente... como si fueran imprevistos y no parte de tu orquestación maléfica.
Más partes interesadas importantes son aquellas relacionadas con la definición y validación, o aceptación, de los entregables que definas. Conviene realizar una identificación temprana de dichas partes interesadas para saber quién puede retrasar al máximo el inicio del desarrollo (por no estar de acuerdo en los contenidos funcionales, por ejemplo) y también, por supuesto, no informarse de cómo van a dar por válido tu trabajo ni de las métricas que van a emplear. ¿Tu proyecto necesita un diseño específico y adaptado a la marca de la empresa? Si es así, es mejor que ignores al departamento de marketing o de marca corporativa. Cuando vean lo que has hecho sin contar con ellos seguro que paran todo y te meten retrasos.
Como último consejo antes de finalizar la 1ª parte de éste decálogo, comentarte que, a medida que identifiques a las partes interesadas y procedas a pasar al siguiente punto en el trato con ellas (la captura de más requisitos y proceder a un análisis funcional de los mismos y del negocio) nunca menciones las necesidades en cuanto a la información que cada parte interesada tenga. Así obviarás información relativa a necesidades en niveles de detalle en las comunicaciones, periodicidad, canales adecuados de comunicación, formato de las mismas, etc... No hay nada como un poco de caos informativo cada lunes por la mañana, para aumentar tus posibilidades de hundir el proyecto.
Nota: El autor del presente artículo no se responsabiliza del mal uso de la información aquí recogida ni del hecho científico probado de que, en determinados cerebros, la psicología inversa no funciona...