7 factores para el fracaso garantizado

No aprecies a los empleados, subestimes la complejidad ni confíes en mitos. Si se tienen en cuenta estos y otros factores, su proyecto está garantizado para fracasar.

¿Lo sabes? Durante semanas y meses, el director del proyecto informa sobre su proyecto. Por supuesto, no deben faltar las clásicas lámparas de estado. Y esto está constantemente en el verde: todo bien. ¡Pero un día el semáforo cambia repentinamente a rojo! En consecuencia, se inicia un proceso de tramitación muy desagradable para los responsables. La mayoría de las veces la primera pregunta se aplica al culpable, la segunda a las causas, y luego una solo se dedica a las posibles soluciones.

A continuación se presentan 7 factores típicos que casi garantizan el fracaso.

Factor 1: ignorar el factor humano

En muchos años como desarrollador, gerente de proyectos, entrenador y gerente de crisis, descubrí que las tensiones interpersonales son el mayor obstáculo para implementar proyectos de TI. Por el contrario, la química entre los empleados es correcta y existe un clima abierto y tolerante a las fallas, se pueden encontrar soluciones para todas las dificultades, incluso en situaciones críticas.

Está en la naturaleza del hombre evitar los conflictos. Por lo tanto, es natural que las personas (p. ej., el director del proyecto) ignoren por completo o desvíen la mirada durante demasiado tiempo. Pero los conflictos por lo general no se disuelven por sí solos. Se requiere investigación, como moderación y al menos la perspectiva de cambio o solución.

A veces son las pequeñas cosas las que tienen un gran impacto, como un nuevo trabajo para un empleado. Sin embargo, a menudo son necesarios gastos mayores, como la reorganización de los equipos, para traer nuevamente la paz al proyecto. Sin embargo, la peor alternativa es prescindir del factor humano.

Factor 2: pensar demasiado en grande o hacer demasiado pequeño

Algunas empresas se hacen cargo de un proyecto. Subestiman la complejidad, los riesgos y el inmenso esfuerzo personal y material. Independientemente de los costos, ¿mi organización es capaz de gestionar un proyecto con 100 empleados? ¿Tenemos suficientes puestos de trabajo, salas de reuniones, capacidad de red, servidor de desarrollo, etc.?

¿Es capaz la empresa de cumplir con los requisitos de un gran equipo de desarrollo ágil en una pista de desarrollo y prueba que incluye integración/entrega continua? Predichas tales preguntas, el caso de negocios debería haber sido calculado de manera realista. He visto varias veces que poco antes del inicio de un proyecto gigantesco quedó claro que el sistema resultante no era realmente necesario porque no encajaba en el modelo de negocio de la empresa. Desafortunadamente, nadie lo había notado antes.

Otro patrón reconocible: un protagonista quiere absolutamente realizar un SW, por ejemplo, por razones de prestigio o para utilizar empleados, y calcula que los costos son insignificantes. Si el gerente del proyecto posterior no es lo suficientemente fuerte como para presentar la discrepancia en el contexto de los órganos de toma de decisiones, esto crea un alto potencial de crisis.

Factor 3: confía en las estimaciones y la planificación al 100%

Un mito muy extendido es la fiabilidad de las estimaciones y la planificación. El concepto del proyecto se define por su singularidad. Quizás ya había proyectos similares, pero en principio, una empresa está entrando en un nuevo territorio con cada proyecto. Esto significa que las estimaciones solo pueden ser tan buenas como las experiencias de los creadores y sus habilidades de adaptación con respecto al proyecto actual.

Sin embargo, los planes nunca pueden incluir eventos espontáneos, cambios en términos de requisitos, tecnologías o la entrada de riesgos no esperados. ¡En última instancia, las estimaciones y los planes basados ​​en ellas no son más que una apuesta sobre el futuro! Aceptar este hecho es un primer paso adelante. Disciplina, coraje y sistema ayudan a prevenir o aliviar posibles crisis.

Factor 4: El triángulo mágico de PM constantemente ignorado

Estudió informática, primer semestre, primera lección de gestión de proyectos: "El triángulo mágico de PM" . La persona interesada en las tareas de gestión conoce muy pronto las leyes de este triángulo. Estos dicen que el cambio en uno de los tres parámetros conduce inevitablemente a las consecuencias de al menos uno de los otros parámetros.

Sin embargo, estas leyes son felices de ignorar en la práctica. Como ya se mencionó en el contexto de la estimación y la planificación, un proyecto es algo único y la probabilidad de influencias no planificadas es excepcionalmente alta. Es por eso que tarde o temprano es necesario para casi todos los proyectos que los responsables reaccionen a estas influencias. Sin embargo, si todos los parámetros son fijos, es decir, el cliente sigue exigiendo el cumplimiento de tiempo, presupuesto y contenido, el fracaso es sólo cuestión de tiempo.

Factor 5: Documentación de todo

Gratis después de Franz Beckenbauer: "¡Lo llamamos un clásico!" Aunque cada vez son más las empresas que apuestan por procedimientos ágiles (principalmente scrum), se siguen encontrando organizaciones y proyectos que dan más importancia a la extensa documentación que al software a crear. Este es un alto riesgo, especialmente en proyectos grandes. A menudo, una búsqueda de consultores y expertos del departamento en miles de páginas ha funcionado durante meses o incluso años, que luego será traducida por otro equipo en SW.

Cuanto más extensa sea la documentación, mayor será el tiempo de realización y menos probable es que el SW se corresponda con los requisitos reales de los usuarios. Las reacciones a los cambios en el mercado no son posibles o solo son posibles con un gran esfuerzo y concesiones temporales. Un documento ofrece una base contra la cual se puede retirar el producto. Desafortunadamente, lo que está escrito no es necesariamente claro y el resultado es diferente al pensado originalmente. Cuántas veces escuché la frase del personal del departamento y los usuarios finales: "¡Oh, me lo imaginaba muy diferente!" .

Factor 6: Simplemente no hay una organización equilibrada del proyecto

¿Un equipo de 20 desarrolladores y 1 contacto técnico? No hay necesidad de un conocimiento experto para reconocer que esta construcción fallará tarde o temprano. Al comienzo de un proyecto, ya sea en cascada o ágil, aún puede funcionar porque los desarrolladores están ocupados con los marcos o configurando los entornos. Pero muy pronto los empleados harán preguntas: necesitarán apoyo profesional intensivo.

Un solo experto en la materia nunca puede soportar esta presión temporal y emocional y requiere apoyo, tanto en términos de personal como durante el proceso de implementación. Sin embargo, es una muy mala idea contrarrestar el cuello de botella de personal con la restricción de la comunicación.

También una idea popular y muy frontal en la escala de los típicos errores de gestión: un empleado recoge las preguntas de los desarrolladores, las discute con el contacto técnico y devuelve las respuestas. De esta manera, creas un cuello de botella por excelencia, desencadenas una tasa de error extremadamente alta y retrasas significativamente el desarrollo.

Factor 7: Calentar la rana lentamente

¿Conoces esta historia? Si pones una rana en una cacerola con agua y la calientas continuamente hasta que se cocina, la rana no intenta escapar. Si lo arrojas directamente al agua caliente, salta inmediatamente.

Uno de mis conocimientos más importantes sobre mí en los últimos años es que los empleados de proyectos de TI expiran con una duración cada vez mayor de una ceguera cada vez mayor. Una vez establecidos, los procesos quizás sean cuestionados en retrospectivas, pero rara vez son realmente drásticos. La capacidad de reacción de las personas ante los cambios desaparece de forma proporcional a la duración de un proyecto.

Por lo tanto, la iluminación esporádica (comprobaciones de estado) es recomendada por proyectos (enormes) por un consultor externo, que no participó anteriormente, para descubrir las fugas, las rutas potencialmente no deseadas. A más tardar después de reconocer una crisis en toda regla, es casi imposible crear el cambio de rumbo solo con el personal existente.

Entonces puede ser posible

Los errores de gestión típicos descritos son solo una pequeña selección de mi lista personal de patrones de comportamiento que impiden o incluso impiden la finalización exitosa de los proyectos de desarrollo de SW. Desde la distancia, podría surgir la impresión de que es fácil reconocer los problemas y corregirlos en las primeras etapas de los proyectos. Pero las condiciones marco supuestamente inamovibles y la ceguera mencionada dificultan muchas veces la toma de decisiones acertadas. Las estadísticas del Standish Group decían al principio que así lo demuestran año tras año.

Si un proyecto está en problemas, se recomienda enfáticamente que un administrador de crisis externo pueda analizar y actuar de manera objetiva, libre de sensibilidades y sin el lastre del historial del proyecto. La sola participación de un experto que escucha a las personas en el proyecto ya puede causar efectos positivos. La selección de las medidas adecuadas también tiene éxito en la transformación y finalmente en el giro.