Uno de nuestros PM acaba de recibir un nuevo proyecto que estaba en la fase de ejecución con requisitos vagos. Debido a estos requisitos imprecisos, el Cliente ha solicitado muchos cambios y el equipo de desarrollo de productos también ha malinterpretado algunos de ellos.
Estos son algunos de los hechos:
¿Cuál es el enfoque estándar de la vida real para superar esta mala racha?
He estado en esta posición antes. Trabajamos con el cliente para elaborar un Documento de especificaciones, lo repasamos varias veces y, una vez que todos acordaron qué estaba dentro del alcance y qué estaba fuera del alcance, el cliente lo firmó.
La razón principal por la que guardo la documentación es porque sirve como un medio para resolver disputas y recordar a todas las partes interesadas cuáles son los requisitos del proyecto.
En mi situación, el cliente simplemente olvidó lo que pidió originalmente. Revisar los requisitos originales con él lo ayudó a darse cuenta de su error, y todos acordamos seguir con los requisitos originales.
Si hubiera insistido en cambiar los requisitos, habríamos cobrado una tarifa más alta por el mayor desarrollo y extendido la fecha de vencimiento original.
La línea de tiempo del proyecto y las características del proyecto son dos valores en una ecuación que se equilibran entre sí. Si se agregan más funciones, entonces se debe aumentar la línea de tiempo o se deben eliminar otras funciones.
Si bien podría hacer que las personas trabajen horas extra o cometer el error de agregar más recursos a un proyecto tarde , las posibilidades de éxito no son grandes.
El mejor enfoque de la vida real para superar esta mala racha es estar preparado documentando los requisitos con anticipación. Si es demasiado tarde para volver atrás y hacer esto, aún puede salvar el proyecto comunicándose con el cliente, explicando que los requisitos son vagos y convocando una reunión para obtener requisitos actualizados teniendo en cuenta el equilibrio entre la funcionalidad y el tiempo de comercialización.
La comunicación constante y ser realista sobre los plazos es su mejor activo en este momento.
Primero, entiende dónde estás. Haz tu tarea: comprueba qué tan importante es el proyecto y el cliente para la organización. Aprenda las restricciones clave: quién tiene que estar contento después de todo, cuánto les importa a los tomadores de decisiones, cuáles son las prioridades generales del proyecto dentro de la empresa, qué tan importante es hacer que la cosa sea rentable en el primer enfoque. Una vez que lo sepa, puede ajustar la estrategia a la situación.
Si el proyecto y/o el cliente son importantes, el enfoque debe centrarse en hacer que el cliente esté satisfecho con lo que obtiene, lo que probablemente signifique una gran flexibilidad para ajustar los planes al cliente en todos los sentidos, aportando un esfuerzo adicional del equipo del proyecto cuando sea necesario. cambiar y tratar de mantener todo en alta calidad (por difícil que parezca). Básicamente, haz que el equipo corra una milla extra. No debería ser difícil hacer que todos brillen si tienes éxito.
Con un proyecto de máxima prioridad, debería ser relativamente fácil obtener algún apoyo de los responsables de la toma de decisiones dentro de la organización. Alguna compensación por el esfuerzo adicional, tal vez una o dos personas adicionales para tareas que pueden subcontratarse fácilmente, etc.
Si el proyecto no es tan importante y la empresa tiene una buena relación con el cliente, a menudo es una buena estrategia hablar de esto. Describa la situación tal como es y trate de encontrar una solución razonable junto con el cliente. Qué características se pueden entregar más tarde, cómo se puede organizar mejor el proceso para que los cambios constantes no interrumpan tanto el proceso de desarrollo, cómo se pueden endurecer los requisitos críticos para que el producto final cumpla al menos con ellos.
Si ni el proyecto ni el cliente son importantes, puede aceptar que no sobresaldrá en este y simplemente hacer todo lo posible para organizar el proceso de una manera razonable, aunque no termine como un éxito rotundo. Tal vez eso sea cínico, pero no vale la pena morir por el proyecto que a nadie realmente le importa.
Si no te importa mucho el cliente o si el cliente es notoriamente molesto con el acuerdo formal, puedes jugar duro y usar el mismo enfoque. Si los requisitos se pueden interpretar, se pueden interpretar en ambos sentidos. Puede ser como perder-perder, pero bueno, a veces es mejor terminar una relación tóxica.
En cualquier caso, cualquier truco que organice mejor la carga de trabajo y reduzca la cantidad de cambios que afectan el trabajo diario de las personas sería excelente. No tiene que ser aislamiento, puede ajustar la forma en que trabaja el equipo de una manera que acepte los cambios para que nadie odie al cliente y al PM por lanzar otro cambio.
Bueno Geo,
No tengo experiencia en este negocio, ni siquiera soy PM (todavía, espero... estoy trabajando en eso), pero he visto una situación similar antes.
Sin embargo, diría que esta situación será y enumerar estos hechos arriba ayuda a comprender y manejar el problema (proyecto).
En una situación similar, tuvieron que volver a escribir la documentación y generar una corrección (pero esto fue en un negocio de software específico donde se pudo proporcionar una corrección rápida al cliente).
En primer lugar, el cliente debe ser consciente de que los cambios limitan el progreso.
Haga una lista de problemas críticos, ordenándolos de más urgentes a menos urgentes.
Haga una lista de las acciones críticas (o entregas) para el equipo de desarrollo (ordenadas como la lista anterior). Enfoca el trabajo en la acción más urgente y luego de completarlo, revisa las prioridades y comienza de nuevo.
Cada vez que se realiza una acción, compruebe si puede marcar un problema (de la lista de problemas críticos ) como resuelto. Las acciones eliminarán los problemas, así que enfócate en las acciones y los problemas desaparecerán naturalmente.
Habla con el equipo y explica la situación. Si es posible, ofrezca una bonificación por la finalización del trabajo.
¿Se generarán horas extras? Sí. Muy importante tener un equipo comprometido.
todas las grandes respuestas. Creo que también es importante recordar que al retroceder en el ciclo de vida del proyecto para asegurarse de que el alcance y los requisitos sean claros y luego la replanificación no significa un retraso de semanas. A menudo, esta actualización de la metodología se puede hacer en uno o dos días.
Me hice cargo de proyectos con estos problemas y realicé una revisión rápida del alcance, los requisitos y los informes de estado. Si las personas están trabajando en las tareas del proyecto y esas tareas tienen poca relación con el propósito original del proyecto, es hora de hablar con el patrocinador sobre lo que cambió.
SBWorks