Contexto
El escenario es este: Eres el líder de un comité que tu empresa ha formado con la finalidad explícita de seleccionar al mejor proveedor de desarrollo de software para crear un producto nuevo que reemplazará el sistema de software central que hace posible operar el core business de tu compañía.
Selección del proveedor
La dirección ha dispuesto que el producto debe estar listo en 18 meses, dato que no revelas en tu Solicitud de Propuesta, porque esperas que cada proveedor estime su plazo, en base a los requerimientos de alto nivel que sí has consignado en dicha solicitud.
Para hacer la historia corta, supongamos que sólo tienes tres proveedores candidatos. El proveedor A (El rápido) te entrega, como parte de su propuesta un cronograma detallado por 15 meses, el Proveedor B (El cauteloso) también incluye un cronograma detallado por 25 meses y finalmente el Proveedor C (El incomprendido) quien te dice que no puede entregar un cronograma detallado porque no tiene toda la información para formularlo y no le parece correcto comprometerse con lo desconocido, te propone algo que llama desarrollo “iterativo e incremental”.
Para hacer la historia aún más corta, digamos que tu único criterio de selección es el plazo, porque todos tus proveedores candidatos han presentado un presupuesto económico similar. Así las cosas, descartas al proveedor B (El cauteloso) porque está fuera de plazo, también descartas al proveedor C (El incomprendido) porque no presentó cronograma detallado (Tu área de «Compras» no pudo compararlo con los otros proveedores) y además nadie entendió su propuesta.
Resultando que tu flamante nuevo proveedor es el Proveedor A (El rápido), quien desarrollará el proyecto en 15 meses, según el cronograma detallado que ha presentado. Todos en tu compañía están felices y emocionados porque es, además, un proveedor global con muchas certificaciones.
Inicio del proyecto y “Análisis de requerimientos”
Te nombraron gerente de proyecto, se firmó el contrato y el proyecto inició.
La felicidad duró poco, porque en la primera etapa del proyecto (que el proveedor llamó, bajo su enfoque en cascada, “Análisis de requerimientos”), los analistas asignados por el proveedor se reunieron con los usuarios responsables de definir los requerimientos en detalle y pronto se hizo evidente que las necesidades reales de éstos, excedían con creces, a lo que se había formulado en la Solicitud de Propuesta, que como todos sabemos, fue la base para formular el presupuesto económico que aceptaste y el cronograma ganador de 15 meses.
Fueron tantos los cambios planteados y tan duras las negociaciones que la relación con el proveedor se debilitó rápidamente, creándose una especie de dos bandos rivales (Tu organización y el proveedor) con un supuesto objetivo común: Desarrollar el sistema central para el core business de tu organización. Tremendo reto.
El proyecto ya estaba atrasado por más de tres meses por los cambios, más un mes adicional por lo que duró la negociación, por lo que el presupuesto económico también fue incrementado en consecuencia.
Como ya los usuarios asignados habían aprobado los requerimientos definidos, se tenía la sensación de que ya habían terminado el “Análisis de requerimientos” y había que hacer una presentación formal de éstos a la dirección, para lo cual se planearon y ejecutaron reuniones de presentación. Para sorpresa de todos, en las reuniones, los gerentes cuestionaron los requerimientos definidos y aprobados por los usuarios que ellos habían asignado. El resultado final fue que el 60% de los requerimientos tenían observaciones de todo calibre y se tuvo que entrar a unas nuevas ruedas de “Análisis” y de feroces “negociaciones”, que terminaron añadiendo 3 meses más al cronograma, el presupuesto económico también se incrementó en en consecuencia; pero, terminó la etapa de “Análisis de requerimientos” y finalmente se tenía un conjunto de requerimientos detallados y firmados por los usuarios. Había una sensación de avance, de logro.
En este momento el proyecto, había usado 4 meses de cronograma, pero esta primera fase estuvo planeada para 2 meses. Como resultados de los cambios, el cronograma tenía un incremento de 7 meses, por lo que el plazo total ahora era de 22 meses.
“Diseño y Construcción”
En la siguiente fase, “Diseño”, también se tuvo que enfrentar una serie de problemas por condiciones técnicas que no fueron explicadas en la Solicitud de Propuesta, pero que el proveedor trató como “supuestos” (que evidentemente no se cumplieron). Esto incremento el cronograma en 2 meses más de plazo y la parte económica en consecuencia.
Para la fase de “construcción” el proveedor se metió de lleno a desarrollar el producto, casi no se supo de él durante esta etapa. Solamente el Jefe de Proyecto asignado por el proveedor asistía a las sesiones de seguimiento, donde mostraba el “avance del cronograma”, todo parecía viento en popa, hasta que “terminaron de construir”.
Tus verdaderos problemas están por empezar: “Las pruebas”
(Como lo vemos, este es el riesgo mayor, al usar un enfoque en cascada.)
La verdadera tragedia de esta historia llegó en la siguiente fase llamada “pruebas”, porque los usuarios enfrentaron por primera vez el producto y pese a todas las definiciones de requerimientos iniciales pronto descubrieron que el producto se caía por todas partes y lo que funcionaba y se podía probar, no satisfacía sus necesidades como lo esperaban. A parte de que, como no se había planificado la prueba formalmente y tampoco había casos de prueba que guiaran la prueba, los usuarios hicieron una tarea hasta antojadiza, probando condiciones del sistema que nunca se habían tratado en los requerimientos, y por las que el proveedor nunca indagó ni preguntó.
El tiempo pasaba, pero el proyecto estaba atascado en enfrentamientos de toda índole entre los dos bandos participantes, el presupuesto económico casi consumido porque los pagos al proveedor no cesaron, a pesar de los problemas.
Por las fechas atrasadas, por la insatisfacción de los usuarios, por las constantes caídas del producto en prueba, la presión aumentaba cada día, las discusiones no dejaban de elevar su tono, se escalaban los problemas a instancias que tampoco lograban resolverlos.
Las reuniones estaban plagadas de frases como:
“No eres un tomador de pedidos, te presentaste como un proveedor global, para que sirven tus certificaciones.”
“Supuestamente tus analistas debían conocer esa parte del negocio, y si no ¡preguntar!, tu gente ni si quiera tiene ‘capacidad de asombro’”
“¿Cómo no van saber que las transacciones terminan con un asiento contable? ¡Tenemos que contarles hasta eso!”
“Los usuarios han dicho todo para alguien que conoce ese tema, solo has asignado principiantes, gente ‘junior’ con precio de gente experimentada.”
El proveedor tenía sus “defensas”:
“Pero nosotros te presentamos los requerimientos y ¡tú los firmaste!, eso es lo que hemos construido, ahora estás cambiando todo”
“Detallamos todos los requerimientos, los escribimos, dibujamos las pantallas. ¡Todo lo tenemos firmado!”
Tú, como gerente de proyecto, decides parar las pruebas para analizar los hallazgos descubiertos por los usuarios y re planificar la fase.
Mientras tanto el proveedor trata de corregir el producto como sea cada día, porque ahora es evidente que dijo que terminó, pero en realidad el producto no está terminado, porque hace agua por donde sea que se le toca.
La migración de datos, que le corresponde hacer a tu equipo, tampoco está terminada. No hay ni un plan para ello. Todo es un caos.
Producto del análisis que haces con tu equipo, compilas una gran lista de hallazgos que envías al proveedor y declaras la fase de construcción no terminada y la de pruebas como no iniciada, ni pagable el tiempo ya incurrido en ella.
El proveedor está viendo rojo, se toma varias semanas analizando la lista de hallazgos y para tu sorpresa empieza a desmantelar el equipo de desarrolladores asignado a tu proyecto, enviándolos a otros clientes, con los que, has escuchado, tiene problemas similares.
Tú estás en shock y ya estás evaluando alternativas, lo que no sabes es como recuperarás lo pagado, porque no pediste en la contratación una “Carta de garantía”.
Finalmente, el proveedor vuelve con la respuesta a tu lista de hallazgos. Ha analizado y calificado cada hallazgo que le enviaste y te presenta un resumen como este:
RESUMEN DE HALLAZGOS 1. Defectos de construcción: 7% 2. Nuevas funcionalidades: 70% 3. Errores por datos mal migrados: 10% 4. Errores de ambiente: 10% 5. No se pudo replicar: 3%
Problemas al límite
Las discusiones escalan tanto, que tu empresa pide que cambien al gerente de proyecto del proveedor, en su reemplazo asignan a su jefe, una gerente de mayor rango, que hace las negociaciones más tardadas y duras.
Son sesiones eternas para revisar uno por uno cada hallazgo y la respuesta que dio el proveedor. No hay acuerdos, es una situación sin solución ni fin.
El proveedor argumenta que el alcance de la funcionalidad del producto ha crecido 70%, con respecto a los requerimientos acordados al inicio y que se necesita un año más para desarrollar ese alcance nuevo y exige que se le pague lo que dice se le adeuda por la fase de pruebas más el análisis de los hallazgos y el sobreesfuerzo de su equipo.
No va más
Tu jefe y tú reciben autorización de tu compañía para llevar el proyecto a litigio, así que van a un arbitraje, como está previsto en el contrato.
Tu compañía pierde el arbitraje, porque los especialistas determinan que el proyecto fue solicitado con un alcance definido, que se afinó al inicio del proyecto y que eso fue lo que el proveedor entregó.
Los especialistas también determinaron que tu compañía, al solicitar un cronograma detallado al inicio de la contratación, estaba imponiendo el método definido en cascada, que usó el proveedor.
El laudo arbitral especificó que el proveedor debía corregir todos sus defectos (7% de la lista de hallazgos)
Que se le debía pagar la fase de pruebas y los sobre costos del análisis y sobre tiempo de su equipo.
Este es el final
El CEO de tu compañía está loco de rabia, decide cancelar el proyecto y pagar la suma acordada en el contrato por terminación anticipada, más lo adeudado según el laudo arbitral.
También, despide a tú jefe y te despide a ti.
Epílogo
Estás desempleado, tomando café a las 11 A.M. en un restaurante de negocios muy concurrido, reflexionas sobre estos dos últimos años de tu vida laboral, estás ensimismado recordando y pensando sobre las cosas que tal vez debiste hacer de manera diferente, cuando alguien te llama con una palmada en el hombro, es el vendedor del Proveedor C (El incomprendido), sí el que descartaste por el método raro de trabajo que te propuso.
No te lo dice, pero tú sabes que él conoce las noticias sobre cómo le fue a tu (ex) compañía con el proyecto que no le contrataron. Era noticia conocida en tu sector.
Lo saludas, hablan de nada y finalmente te animas, “Oye ¿me puedes contar más sobre ese método, ‘iterativo e incremental’ del que hace dos años me hablaste?”
EOF
0 comentarios