Si un proyecto tiene problemas, ¿cuál es la mejor salida?

Interpreto que esta pregunta trata sobre cómo guardar un proyecto fallido y lo que podemos hacer para evitar proyectos de TI fallidos.

A lo largo de mi carrera, mi punto de vista es que los proyectos de TI exitosos son el resultado de:

  • Planificación consistente pero no grandes planes . “Los planes no son nada, la planificación lo es todo”, como dice el refrán. Los proyectos de TI están llenos de incertidumbre. No puede predecirlo, por eso recomiendo de todo corazón las prácticas ágiles sobre las prescriptivas y las predictoras. Sé humilde y sé consciente de lo que sabes y de lo que no puedes saber. Planificar en consecuencia.
  • Una comprensión compartida de los objetivos comerciales del proyecto , los usuarios finales y la priorización que resulta de él. Muchos proyectos sufren el juego del susurro, en el que los miembros del equipo no entienden por qué algo necesita ser construido o diseñado de cierta manera. Ningún gerente de proyecto como intermediario y más transparencia ayuda. Idealmente, el té debe saber por qué se llevan a cabo los proyectos y por qué cada parte es importante. “Intención del comandante” es otra palabra para esto.
  • Expectativas realistas que se basan en los resultados y el retorno de la inversión . Construimos cosas para lograr algo. Los proyectos de TI son inversiones para hacer, ahorrar o proteger dinero. Todos los esfuerzos que hacemos se realizan para lograr los objetivos. Usted compra un taladro para colocar estanterías (para usar una metáfora bien conocida). No quieres un ejercicio, quieres un buen lugar visible para colocar tus libros, para impresionar a ese lindo autor con el que estás saliendo. Los proyectos de TI a menudo usan especificaciones para determinar el progreso, a pesar de que no tienen nada que ver con el resultado o impacto previsto. Hay mejores formas Al entregar cosas que funcionan de manera consistente y temprana, puede obtener comentarios directos antes. Eso te dirá si estás construyendo lo correcto. El efecto importa, no la eficiencia. Correr súper rápido es irrelevante si corres en la dirección incorrecta.

He hablado de esto en varias conferencias. Aquí hay una de mis presentaciones donde menciono algunos de estos principios, en el contexto del desarrollo web:
http://www.slideshare.net/jakobp…

Una de mis herramientas favoritas para crear la hoja de ruta del proyecto que le permite hacer lo anterior es el mapeo de impacto. Estoy escribiendo una tesis sobre este método y entrevisté a varios gerentes de proyectos y productos y ha sido sorprendente escuchar cómo ha transformado su forma de trabajar:
http://impactmapping.org/

     

Advertising Here

Pregunta original

Si un proyecto tiene problemas, ¿cuál es la mejor salida?

Eso depende de si usted es el empleador o el consultor. Si usted es el empleador, culpe al consultor. Todos te creerán. Si usted es el consultor, culpe al empleador; tus amigos te creerán, pero no esperes que te paguen. Hablo por experiencia como ex consultor informático senior en compañías Fortune 50.

Editar después de agregar detalles:
Tiene toda la razón, pero entienda que las compañías no contratan consultores para agitar una varita mágica, son contratados para implementar las ideas que los empleados ya tienen, pero que están estancadas porque nadie puede correr el riesgo de seguir adelante. El consultor es un agente de cambio que brinda cobertura para el éxito o el fracaso. Raramente se me ocurrió una idea en la definición de mi proyecto que no fue sugerida o conocida por el personal de TI.

La mayoría de las fallas de TI que he visto son causadas por el arrastre de características, el cambio de estándares, el pellizco de centavo, la dependencia de un software innovador no probado que tiene características que deberían funcionar, pero no lo hacen, y las compañías que intentan hacer que un producto de software haga algo que no está diseñado hacer agregando demasiada personalización interna. Además, los proyectos que están diseñados internamente desde cero cuando un producto comercial hubiera sido más fácil de implementar y usar.

Salí de TI porque decidí que la presión sobre mí para entregar cuando no podía depender del software o la implementación adecuada del software me estaba enfermando. No podría pagarme lo suficiente como para asumir la responsabilidad de la seguridad o la posible falla catastrófica de un proyecto de TI. Buena suerte. Espero que encuentres una respuesta antes de enfermarte y enfermarte tanto como yo.