¿Cómo debe manejar un gerente de proyecto una solicitud de software contratado para producir el doble de informes que los especificados en los requisitos del proyecto?

Uno de los cuatro valores de Agile es "Colaboración del cliente sobre negociación de contratos".

Lo primero que hay que preguntarse es "¿qué es lo mejor para el cliente?". Una vez que haya hecho eso, entonces preguntará "¿está cubierto por el contrato?" y solo entonces ahondas en el "te pedimos más $".

Centrándome específicamente en su problema, la primera pregunta que haría es quién participó en la revisión y aprobación del BRD. A menudo me he dado cuenta de que el BRD solo tenía una persona del cliente y es posible que esa persona no haya sido realmente la persona adecuada.

Si el cliente es importante para su empresa, sugeriría seguir con el valor ágil y trabajar con ellos para hacerlos felices.

Luego, en cualquier proyecto futuro, asegúrese de obtener definiciones claras de los criterios de éxito y aceptación por adelantado. También asegúrese de que el SOW esté escrito de tal manera que los requisitos finales de referencia estén documentados en otro lugar.

Buena suerte

TL;DR

En esta etapa, el trabajo del director del proyecto es proporcionar un marco para que las empresas aborden el alcance y estimar el presupuesto y los recursos necesarios para entregar ese alcance. ¡Eso es! En situaciones como estas, las cuestiones de culpa (a menos, por supuesto, que sea suya) están realmente fuera del alcance de la responsabilidad de un gerente de proyecto.

En lugar de culpar o intentar trasladar la carga al cliente, debe:

1. Comuníquese de manera efectiva con su organización (y posiblemente con el cliente) sobre el problema.
2. Identificar una o más posibles soluciones al problema.
3. Recomiende una solución a su alta dirección, que luego puede resolverla con el cliente.

Cada uno de estos elementos de acción se analiza con más detalle a continuación.

Comunicarse de manera efectiva sobre los problemas

Los acrónimos pueden causar problemas de comunicación, pero rara vez los resuelven. La mayor parte de su publicación es una mezcla confusa de acrónimos y hace un mal trabajo al comunicar el problema real. Entonces, arreglemos eso primero. Sus hechos significativos son:

1. [L]a declaración de trabajo (SOW) simplemente dice que el software admitirá "informes".

2. [N]uestro documento de requisitos comerciales (BRD) describe tres informes que el software debe generar.

3. [E]l cliente nos pide que creemos seis informes adicionales y dice que está cubierto porque el SOW dice que el software se usará para producir informes.

En resumen, la declaración de trabajo que define el alcance es vaga, el documento de requisitos comerciales puede o no haber sido escrito en colaboración con el cliente, y el cliente solicita que el proyecto cubra seis informes en lugar de tres.

Analice el problema con precisión

Ahora que hemos identificado los problemas reales, veamos qué significa eso realmente para su alcance y su proceso.

1. Su empresa claramente tiene la culpa del vago alcance del SOW. Su proceso de contratación debe ser fijo, pero mientras tanto, elimina la responsabilidad de definir el alcance de la presentación de informes en el camino hacia algún otro documento o proceso dentro del proyecto. Este puede o no ser su documento de requisitos comerciales.
2. Cuando dice "nuestro" documento de requisitos comerciales, no está muy claro quién es realmente el propietario de BRD. ¿Fueron los requisitos escritos por el cliente, o solicitados por ellos, y luego incorporados al proyecto por el líder del proyecto? ¿O su equipo de proyecto creó este documento y tal vez hizo un trabajo incompleto al capturar el conjunto completo de requisitos? Esto importa mucho, porque en el primer caso el cliente definió un alcance que ahora está excediendo, mientras que en el segundo caso su organización usó un SOW vago seguido de un conjunto incompleto de requisitos para definir el alcance. Si su equipo de proyecto no pudo capturar los requisitos con precisión, nuevamente sería culpa de su empresa.
3. La misma existencia de la pregunta presupone que el producto de informes no es fácilmente extensible. Si lo fuera, sería un problema menor que no involucraría un presupuesto significativo ni causaría preocupación para dos equipos de administración separados. Entonces, hay una deuda técnica, una falta de una implementación sólida o hay complejidades sobre este requisito de informes que el proyecto no captó bien.
4. Esta es una cuestión tanto del alcance del proyecto (p. ej., ¿se incluyen los informes adicionales en el trabajo acordado?) como de la responsabilidad (p. ej., quién tiene la culpa de la falta de comunicación, el avance del alcance o los excesos presupuestarios). Esta es una pregunta que debe responder la alta gerencia (y posiblemente los abogados) de ambas partes, en lugar de una pregunta estrictamente de gestión de proyectos. En la medida en que el gerente del proyecto debería haber identificado el SOW vago como un riesgo, o haber trabajado para garantizar que el BRD fuera preciso y completo, ciertamente hay mucha culpa para repartir. Sin embargo, el problema real es quién paga los costos adicionales del proyecto.

Al final del día, las primeras tres preguntas son sobre la asignación de culpas y realmente no ayudan fuera de la sala del tribunal si su disputa contractual llega tan lejos. Lo que realmente importa es cómo salvar el proyecto, la relación con el cliente y evitar grandes sobrecostos.

El conjunto de posibles soluciones

En primer lugar, olvida cómo llegaste a donde estás. Arregla eso en otro momento. Concéntrese en cambio en cómo colaborar con el cliente para encontrar una solución satisfactoria que satisfaga:

1. las expectativas del cliente para un producto de trabajo, y
2. la necesidad de su empresa de financiar cualquier trabajo adicional.

Sin ningún orden en particular, su proyecto eventualmente hará uno o más de los siguientes:

• Grite "mea culpa" y haga el trabajo restante sin cargo adicional.
• Utilice la experiencia para mejorar los procesos de contratación, presupuestación, estimación y recopilación de requisitos en el futuro.
• Recopile nuevos requisitos de informes y agréguelos al proyecto con miras a minimizar cualquier costo adicional y al mismo tiempo brindar el valor esperado para el cliente.
• Colaborar con el cliente para encontrar una solución equitativa.
  • Colaborar con el cliente para redefinir el alcance.
  • Colaborar con el cliente para renegociar el presupuesto.
• Sic los principales contratantes entre sí para llegar a una solución mutuamente (in)satisfactoria.
• Abogado, e ir a la corte para ver quién tenía razón.

Puede haber algunas variaciones sobre un tema que no he cubierto, pero en general esas son su grupo de opciones. Algunas son definitivamente más apetecibles que otras, pero realmente depende de la alta gerencia elegir el conjunto de opciones, no del gerente del proyecto.

Recomendaciones

Personalmente, recomendaría el enfoque colaborativo siempre que sea posible. Su objetivo debe ser ofrecer tanto valor como sea posible sin consumir costos excesivos, mientras que el objetivo del cliente debe ser obtener un software que funcione y que satisfaga sus necesidades sin esperar trabajo gratis o agriar una relación con la que puede estar contando para el soporte a largo plazo de la empresa. software que le están pagando a su compañía para escribir.

En un mundo perfecto, este problema nunca hubiera surgido. Ya que lo ha hecho, desea explorar el arte del compromiso para que ambas partes puedan irse contentas, si no felices.

En un taller ágil, simplemente lo trataría como una extensión iterativa del trabajo ya realizado. En una tienda de cascadas, yo:

1. Reúne los requisitos.
2. Obtenga la aprobación del cliente y su equipo de desarrollo en el nuevo alcance para asegurarse de que todos estén en la misma página.
3. Estime el esfuerzo y el costo asociados con el nuevo alcance.
4. Deje que los ejecutivos de ambas compañías ganen su pago de 400:1 determinando quién pagará por el alcance adicional.

En esta etapa, el trabajo del director del proyecto es proporcionar un marco para que las empresas aborden el alcance y estimar el presupuesto y los recursos necesarios para entregar ese alcance. ¡Eso es! En situaciones como estas, las cuestiones de culpa (a menos, por supuesto, que sea suya) están realmente fuera del alcance de la responsabilidad de un gerente de proyecto.

El SOW es contractual. El BRD es un producto de trabajo. La SOW probablemente prevalecerá si esto alguna vez termina en disputa. Dicho esto, el BRD no está exento de peso. Si los informes adicionales son difíciles de crear y lo afectarán desde una perspectiva de costos, entonces lleve al cliente a la mesa y discuta más dinero. Un cliente razonable negociará. Un cliente irrazonable no lo hará. Pero luego aprendió la lección para su próximo concierto para generar más contingencia para cosas como esta, en su precio.

Según mi experiencia, el documento que prevalecerá será el firmado por ambas partes .

• Si el BRD fue muy claro acerca de 3 informes pero el cliente no estaba al tanto , depende del proyecto absorber este error y revisar lo antes posible el BRD en busca de más lagunas.
• Si el cliente conocía el BRD y lo firmó , es cuestión de replanificar
• Si no hay un documento formal firmado , entonces se trata de llegar a un acuerdo sobre cómo abordarlo (muchas alternativas mencionadas ampliamente por CodeGnome): firmar un documento, ya que parece que la colaboración (como la que esperamos en Agile entornos) no es fuerte en este entorno.