No basta con entregar los proyectos a tiempo y dentro del presupuesto. Los líderes también deben asegurarse de cumplir con las métricas de usabilidad y adopción.
Los proyectos de tecnología de alto nivel suelen ser uno de los elementos más importantes de las responsabilidades de un líder tecnológico. Estos proyectos promueven la agenda estratégica más amplia de la organización, impulsan cambios, integran adquisiciones u otras tareas críticas. También suelen estar sujetos a un importante escrutinio organizacional. Los líderes y sus equipos están bajo presión constante para satisfacer la necesidad de entregar resultados a tiempo y dentro de las limitaciones presupuestarias y de alcance.
Históricamente, las filosofías de gestión de proyectos y programas se reducían a variaciones del modelo de “triple restricción”, en el que los líderes en última instancia gestionaban la interacción entre costo, cronograma y alcance del proyecto. Normalmente, los líderes podrían controlar uno o dos de estos factores. Por ejemplo, si se aumentara el alcance y se acortara el plazo, es probable que los costos aumentaran. Del mismo modo, si se dispusiera de un cronograma rápido y un presupuesto limitado, sería necesario controlar cuidadosamente el alcance para lograr este objetivo.
Esta línea de pensamiento funcionó bien para ejecutar proyectos que fueron éxitos técnicos y presupuestarios, donde el alcance planificado se entregó dentro de un cronograma y presupuesto aceptables. Sin embargo, el éxito técnico no siempre significa que un proyecto sea un verdadero activo para la organización. La mayoría de los líderes de TI han experimentado un "fracaso exitoso" en algún momento de sus carreras en el que "marcaron las casillas" del modelo de triple restricción pero entregaron algo que no cumplió con los objetivos estratégicos de la organización o no logró ser adoptado por el usuario final. .
Definición de fracaso exitoso
Al igual que construir una casa perfecta que los ocupantes odian por el diseño o la distribución de la habitación, los fracasos exitosos producen un resultado ejecutado correctamente que, en última instancia, no resuelve el problema correcto.
Esta avería suele producirse debido a alguna combinación de los siguientes factores:
- El problema empresarial estaba mal definido o definido incorrectamente, lo que provocó que el proyecto resolviera el problema equivocado.
- El entorno y el mercado cambiaron durante la implementación del proyecto, lo que provocó que el proyecto entregara una respuesta al problema comercial de ayer, pero no al problema comercial de hoy.
- No se consideraron adecuadamente las dificultades para adoptar los resultados del proyecto, generalmente debido a una capacitación deficiente o a una variedad de factores agrupados en el grupo de “gestión del cambio”.
- Se encontró o ya existía una alternativa atractiva al proyecto, lo que permitió al usuario final ignorar efectivamente los resultados del proyecto.
- El proyecto estaba demasiado centrado en una tecnología nueva o “cool” y no resolvió un problema empresarial útil.
- El proyecto altera o pone en peligro el sustento de alguien, por ejemplo, al eliminar una importante fuente de ingresos, creando una oposición activa.
Estos factores son complejos y matizados y requieren la mayor parte del enfoque y la diligencia de un líder. Asumir que nadie se opone activamente a una diapositiva del estatuto del proyecto elaborada por su analista junior no es lo mismo que examinar el problema empresarial que su proyecto está resolviendo y asegurarse de que está creando la solución adecuada para ese problema.
Evitar el atolladero de la gestión de proyectos
Podría decirse que gran parte de la atención en la gestión de proyectos se centra en sus aspectos técnicos, y las diversas certificaciones y organizaciones de gestión de proyectos que desarrollan diferentes metodologías se centran principalmente en estos detalles. Muchos líderes de TI se han destacado en la gestión de programas complejos y es fácil recurrir a preocupaciones sobre los elementos WBS, scrum masters y registros de problemas en lugar de abordar desafíos más difíciles relacionados con la comprensión de la verdadera naturaleza de un problema empresarial y la toma de decisiones difíciles si el El entorno cambia y hace que su programa, que de otro modo sería exitoso, sea discutible.
Los proyectos de TI tienen la complejidad adicional de tratar a menudo con tecnologías o proveedores nuevos o innovadores que presentan sus productos como una “solución” sin verificar minuciosamente si la implementación está dirigida al problema correcto.
Los modelos de desarrollo de software y gestión de proyectos se han convertido en gran medida en una "ciencia establecida" y es más fácil que nunca encontrar empleados, socios y proveedores que ejecuten proyectos de manera competente, rentable y puntual. Como líderes, debemos dedicar nuestro tiempo a investigar el “por qué” de cualquier proyecto que acordamos abordar, sin importar cuán interesante sea la tecnología o cuán ajustado sea el presupuesto.
Esta diligencia en la comprensión del problema a menudo se ignora, especialmente si la idea del proyecto fue válida en algún momento. Esto se vuelve aún más grave a medida que su organización pasa del debate sobre el problema a debates apasionantes y estimulantes sobre “cómo” y “cómo lo financiamos”. Aunque no se ha dicho, francamente es muy divertido estar involucrado en un esfuerzo complejo, con muchas personas contribuyendo con entusiasmo a las discusiones sobre cómo avanzar. Puede resultar difícil detener el impulso y examinar el terreno ya pisado. Sin embargo, es por eso que tenemos líderes.
Reemplazar la Carta con una declaración del problema y una revisión periódica
De hecho, una carta de proyecto eficaz puede ayudar a identificar cuándo un proyecto ya no cumple con sus objetivos. Sin embargo, a menudo son documentos vagamente redactados y diseñados para marcar una casilla en lugar de cumplir una función vital. En lugar de un estatuto, considere escribir una declaración del problema que articule claramente qué problema comercial pretende resolver el proyecto. Para que este proceso sea efectivo, se llevan a cabo revisiones periódicas mensuales, en las que las partes interesadas deben defender si el planteamiento del problema sigue siendo válido.
Para que este proceso sea aún más efectivo, considere articular posibles cambios ambientales o de mercado que invalidarían el planteamiento del problema cuando se cree el documento. Por ejemplo, un gran proyecto de consolidación de tecnología puede dejar de ser válido si se adquiere la empresa o si los servicios en la nube alcanzan un determinado precio.
La evaluación de su proyecto en relación con el planteamiento del problema y estos "modos de falla" identificará posibles "fallas exitosas" de manera temprana, mientras todavía hay tiempo para reorientar el proyecto o reasignar recursos a una prioridad más alta. Esto puede requerir mucha madurez por parte del líder, ya que efectivamente está cuestionando y potencialmente deteniendo un esfuerzo que parece cumplir con todos los criterios externos para el éxito. Sin embargo, si el planteamiento de su problema está bien elaborado y se comparte, puede servir como un “indicador de tiempo de espera” en lugar de requerirle que gaste capital de liderazgo para pausar y potencialmente terminar un proyecto.
Tener los procesos de gestión y el liderazgo necesarios para mitigar los “fracasos exitosos” puede parecer derrotista, pero tiene un doble propósito. No sólo evitará gastar dinero en un esfuerzo que, en última instancia, no tiene valor, sino que también aliviará a su organización de tener que soportar nuevos sistemas o procesos que no están generando el rendimiento esperado.
Nadie quiere presidir un fracaso, y mucho menos un proyecto ejecutado con éxito que termina fracasando en la lentitud organizacional posterior a su implementación. Sin embargo, si piensa con anticipación y define el planteamiento del problema que está tratando de resolver, puede evitar “fracasos exitosos” y dedicar su energía y recursos donde más se necesitan.
