¿Dónde termina la “Gestión del Cambio” y comienza el “Fracaso del Proyecto”?

Question

Me metí en un mini argumento con mi jefe recientemente con respecto al "fracaso del proyecto". Después de tres años, nuestro proyecto para migrar una base de código a una nueva plataforma (un proyecto en el que estuve durante 1,5 años, pero la ventaja de mi equipo estuvo solo durante unos meses) se puso en marcha.Él, junto con la alta dirección tanto de mi empresa como del cliente (soy uno de esos horribles consultores de los que tanto oyes hablar).Mi compromiso es un "Application Outsourcing") declaró que el proyecto fue un éxito.No estuve de acuerdo y afirmé que presentaciones antiguas que había encontrado mostraban que, en comparación con el cronograma original, el retraso en el despliegue se podía medir mejor en meses y potencialmente podría medirse en años.Le expliqué lo que sé sobre el fracaso de proyectos y los estudios y estadísticas detrás de las tasas de fracaso.Respondió que todo eso era académico y que ningún proyecto que dirigió había fracasado, gracias a las maravillas de la gestión del cambio/riesgo, lo que parece reducirse a explicar los retrasos y reevaluar el cronograma en función de nuevos datos.

Tal vez una consultoría como esta se diferencie de otros proyectos, pero parece que esto es solo un fracaso envuelto en un nombre más bonito para evitar el estigma de no haber podido entregar a tiempo, dentro del presupuesto o con la funcionalidad completa.El hecho de que me haya explicado que mi empresa regaló horas de trabajo para poder terminar el proyecto dentro del presupuesto máximo dice mucho.

Entonces te pregunto esto:

• ¿Qué es la gestión del cambio y cómo se aplica a un proyecto?
• ¿Dónde termina la "gestión del cambio" y comienza el "fracaso del proyecto"?

---

@shog9:
No estaba preguntando por un juego de culpas con los consultores, especialmente porque en este caso yo representar los consultores.Estaba buscando opiniones sobre cuándo un proyecto debería considerarse "fallido" independientemente de si tiene la funcionalidad necesaria. era finalmente implementado.
Estoy buscando la diferencia entre "esto es en realidad un poco más complejo de lo que pensábamos y va a durar otra semana", lo cual esperaría que fuera algo típico, y "fracaso del proyecto", como quiera que se defina el fracaso.¿Hay siquiera una diferencia?¿Este pequeño nivel de retraso en el cronograma constituye un "fracaso del proyecto" estadístico?

Answer 1

Creo que, la mayoría de las veces, los desarrolladores olvidamos que, después de todo, todo lo que hacemos tiene que ver con los negocios.

Desde ese punto de vista un proyecto no es un fracaso mientras el cliente esté dispuesto a pagar por él.Todo depende del cliente, algunos clientes tienen más paciencia y comprenden mejor los riesgos del desarrollo de software, otros simplemente no pagarán si hay un retraso sustancial.

De todos modos, sobre tu pregunta.Siempre que desarrollas un proyecto, existen riesgos involucrados, tal vez programes el final del proyecto en una fecha determinada, pero tomará como seis meses más de lo esperado.En ese caso, debe equilibrar lo que ya ha gastado y lo que puede ganar con los riesgos que está asumiendo.De hecho, existe toda una ciencia llamada "toma de decisiones" que lo estudia a nivel de software, por lo que tu jefe no se equivoca en absoluto.

Veamos algunas preguntas: ¿Está el cliente dispuesto a esperar el proyecto?¿Está dispuesto a asumir ciertos sobrecostes?Incluso si no lo hace, ¿merece la pena completar el proyecto asumiendo los costes extra en lugar de tirar todo el trabajo ya hecho?¿Puede la empresa asumir lo que ya está perdido?

La verdadera respuesta a su problema se encuentra detrás de esas preguntas.No se puede establecer un punto y decir aquí que si el proyecto no está terminado en este momento entonces es un fracaso.En cuanto a tu situación específica, ¿quién sabe?Probablemente tu jefe tenga más información que tú, así que tu trabajo es decirle cómo va el proyecto, cuánto costará y cuánto costará (en términos de horas/hombre si lo deseas).

Answer 2

A menos que los objetivos se indiquen claramente al comienzo del proyecto, no hay líneas claras entre el "éxito" y el "fracaso". A menudo, un proyecto tendría un grado variable de éxito/fracaso.

Para algunos, simplemente poner algunos conceptos en código sería un éxito, mientras que otros pueden medir el éxito como recuperar todas las inversiones y obtener ganancias.Dos modos de fallas bien conocidos son los retrasos en el cronograma y el deterioro de la calidad, pero en el mundo real, a la gente no parece importarle mucho.

Las formas simples de retrasar el cronograma son dejar que los gerentes hagan solicitudes cuando lo deseen (funciones progresivas) y dejar que los programadores codifiquen lo que consideren correcto (codificación vaquera).Proceso de gestión de cambios como planificación de sprint de melé y juego de planificación de XP son algunos de los ejemplos.Estos son algunos de los intentos de la gerencia y los desarrolladores de enviar productos confiables a tiempo.Si alguna de las partes no está interesada en que el proceso sea confiable o puntual, entonces la gestión del cambio no sería útil.

Answer 3

Supongo que el éxito del proyecto depende de quién sea el cliente.Si el cliente fueran los directores de la empresa y estuvieran contentos, entonces el proyecto fue un éxito independientemente de los fracasos que haya en el camino.

Answer 4

Andy Rutledge ha escrito un artículo bastante interesante sobre el éxito.Aunque el título es Discusiones previas a la oferta, el artículo define tener un proyecto exitoso, que para Andy implica:

1. ¿Se me permitirá a mí o a mi equipo aportar nuestro mejor trabajo al resultado final?
2. ¿Está el cliente preparado para participar adecuadamente en el proyecto?
3. ¿Está el cliente preparado para comenzar este proyecto?
4. ¿Está el cliente preparado para confiar en mis ideas o las de mi equipo?
5. ¿Estoy yo o mi equipo preparado para cumplir o superar los requisitos del proyecto?

Este artículo fue señalado por Obie Fernández, un exitoso consultor, en su Haz el ajetreo conferencia sobre consultoría.

Answer 5

¿Qué es la gestión del cambio y cómo se aplica a un proyecto?

La gestión de cambios consiste en aprobar y comunicar cambios en un proyecto antes de que sucedan.Si alguien en su proyecto (usuario, patrocinador, miembro del equipo...quien quiera agregar una característica, el cambio debe documentarse y analizarse para determinar el efecto.Cualquier cambio resultante en el alcance, el presupuesto y el cronograma debe aprobarse antes de que se lleve a cabo el cambio.Estos cambios suelen ser aprobados por su patrocinador, su comité directivo o su cliente.

Una vez que los cambios hayan sido aprobados y aceptados, ese será su nuevo plan.No importa cuál era el presupuesto o el cronograma original.

La gestión del cambio en proyectos tiene que ver con el principio de "Sin sorpresas".Las personas adecuadas (su Junta de Control de Cambios) deben aprobar cualquier cambio en el alcance, el cronograma y el presupuesto antes de que se apliquen.

Una cosa que hay que recordar es que puede haber ciertas limitaciones y tolerancias explícitas o implícitas para el cambio.Es posible que deba entregar su proyecto en una fecha determinada para cumplir con los requisitos reglamentarios gubernamentales.O su organización puede tener un umbral según el cual una vez que el presupuesto de un proyecto supera en un 30% el presupuesto original, debe pasar a un nivel "C" o el proyecto se cancela.Investigar y establecer explícitamente estos umbrales y tolerancias por adelantado es una buena manera de tener proyectos más exitosos.

¿Dónde termina la "gestión del cambio" y comienza el "fracaso del proyecto"?

Si un proyecto cumple con el alcance, el cronograma y el presupuesto aprobados, entonces es un éxito.

Sin embargo, todavía puede considerarse un fracaso.Las revisiones posteriores a la implementación son una buena herramienta para calificar esto con las partes interesadas (no solo con su jefe).También valdría la pena analizar la realización de beneficios para ver más allá de la caja negra del proyecto y el impacto en el negocio en su conjunto.