Gold Plating

3

El término gold-plating (traducido como “bañado en oro”) se utiliza comúnmente en gestión de proyectos como la práctica de añadir funcionalidades al producto entregado que no estaban incluidas inicialmente en el alcance del proyecto. En nuestro caso, proyectos de TI, y concretamente en el desarrollo de software es una práctica más común de lo deseable. Está claro que generalmente se desaconseja y estándares como Prince2 o PMBOK lo marcan como una mala práctica. Pero en mi carrera me he encontrado con defensores, a fin de mejorar la satisfacción del cliente y el éxito del proyecto (medido como el grado de satisfacción del cliente, valga la redundancia).

Personalmente creo que en el caso de servicios contratados, el concepto de gold-plating es de directa aplicación, por lo que todo lo que expongo en este artículo puede ser de utilidad para gestores de servicios.

Alcance del término Gold-plating

Creo que es importante diferenciar la distinta tipología de casos de ampliación de alcance para entender el término de Gold-Plating:

  • Ampliación de alcance sobre la que se ha medido el impacto y éste ha sido aprobado mediante el procedimiento de control de cambios.
  • Diferencia de opiniones entre cliente y proveedor acerca del alcance en la que el proveedor considera que el concepto no está incluido en el alcance inicial.
  • Solicitud de ampliación del alcance, sin asumir el impacto por parte del cliente y aceptada por el proveedor.
  • Ampliación del alcance desde el propio proyecto, de forma proactiva, con el ánimo de mejorar la satisfacción del cliente.

Como se puede ver no incluyo las ampliaciones de alcance por la materialización de riesgos. Es decir, la aparición de la necesidad de realizar determinadas tareas dentro del alcance del proyecto porque se ha materializado un determinado riesgo, sea este conocido o no. Esto es porque realmente no se trata de ampliar el alcance, sino de asumir el impacto de un riesgo materializado.

Por ejemplo el siguiente caso ilustra un alcance “escondido”:

En un proyecto se me solicitó la gestión de expedientes mediante un ciclo de vida que se determinaría en una fase intermedia del proyecto. Para limitar el alcance se determino que las reglas estarían basadas en el contenido de los expedientes, que incluirían un estado y que habría 5 roles diferentes que participarían en los expedientes.  Se dispondría de 5 tipos diferentes de expedientes. A la hora de planificarlos asumimos un sistema configurable de gestión del ciclo de vida de los expedientes basados en los roles. Pero a medida que se iban definiendo los procesos descubrimos que cada tipo de expediente era una entidad tan diferente, que en vez de hablar de un módulo de expedientes con un campo “tipo” con 5 valores diferentes, realmente eran 5 módulos multiplicando costes y plazos. Mala estimación = riesgo materializado.

De los cuatro conceptos que he presentado, los dos primeros no son gold-plating y los dos últimos sí lo son (por supuesto desde mi humilde punto de vista). Esto es porque el término gold-plating habla de aumentar funcionalidades sin modificar el resto de restricciones del proyecto (costes, alcance, riesgos, …) lo cual es imposible. Así que, por mucho que queramos ocultar la realidad, la estamos modificando. En los dos primeros, no se da esta condición.

Vamos a repasar un poco en detalle los cuatro supuestos

Ampliando alcance a través del control de cambios

Durante un proyecto podemos encontrarnos con que se descubre que una determinada funcionalidad o entregable sería de gran valor para negocio (o el cliente). Esta nueva necesidad estaría alineada con los objetivos estratégicos de la organización y tendría sentido incluirla dentro del proyecto en curso, y no como otro proyecto independiente, porque sustituye o modifica tareas planificadas, además de basarse en los mismos recursos.

En estos casos, el project manager debe informar al patrocinador de esta nueva funcionalidad y el impacto que tiene sobre el resto de restricciones del proyecto, y no me refiero sólo a coste y tiempo, sino a todas. Por lo que debemos también tener en cuenta la calidad, riesgos, satisfacción y recursos. Si con toda esta información el patrocinador, la PMO, o el comité de control de cambios están de acuerdo, estaríamos ante un cambio.

Este supuesto es una buena práctica, ya que conseguimos alinear aún más nuestro proyecto con los objetivos de negocio.

Desacuerdo de alcance

Este caso se da mucho en proyectos de desarrollo de software ya que entre la idea que tiene originalmente el cliente y lo que entiende el proveedor que tiene que hacer, puede haber mucha distancia. Además es relativamente fácil acordar un alcance en el que ambas partes crean que su expectativa está perfectamente plasmada. De esta manera en el momento en que el el producto que genera el proyecto desvela esa diferencia de expectativas se genera un conflicto difícil de resolver.

Veamos un ejemplo:

En un proyecto se define dentro del alcance la creación de un blog basado en la identidad corporativa del cliente. El jefe de proyecto entrega un diseño para el blog, totalmente alineado con la identidad corporativa del cliente, pero el cliente al verlo dice que le faltan muchas cosas como una opción para compartir con twitter, un diseño responsive, un aviso legal de cookies. Todas estas funcionalidades no estaban consideradas por el proveedor cuando planificó el proyecto, pero el cliente considera que eran obvias, ya que cualquier blog que se genere en el mercado actualmente las tiene. El cliente le enseña al proveedor una conocida web de plantillas de wordpress y comprueban que las últimas 100 plantillas publicadas tienen todas esas funcionalidades.

Por un lado está el cliente que interpreta que es problema del proveedor por no haber tenido en cuenta algo obvio. Por otro lado está el proveedor que argumenta que al no estar declarado en el alcance no está obligado a cumplirlo.

Yo personalmente me he encontrado en estos casos en gran parte de los proyectos que he dirigido. En los que no me ha pasado eran aquellos casos en los que mi conocimiento sobre el negocio del cliente era tan grande que era capaz de alinearme al 100% con sus expectativas. Pero en el resto, en el que el conocimiento que tenía del cliente no era tan extenso, siempre me he encontrado con estos casos.

Es que es algo obvio. Si pides una silla, asumes que tendrá cuatro patas. Si me entregas una silla con tres patas, por mucho que no estuviese especificado que tenía que tener cuatro, no la aceptaré.

Un cliente en desacuerdo

En estos casos entramos en aguas pantanosas y no hay una estrategia clara. Entrarán en juego muchos factores a la hora de decidir si el cliente tiene razón. Yo por mi parte siempre he querido contar con apoyo a la hora de tomar la decisión. Por un lado apoyo de pares. Es decir, de otro project manager de dentro de mi organización, evitando consultar a gente de mi equipo, por estar sesgada su opinión. En muchos casos el project manager te mostrará un punto de vista externo y te ayudará a determinar si está fuera de alcance o no. Por otro lado el apoyo de mi propio negocio. Es decir, apoyo del gestor de la cuenta, de la PMO o de dirección de mi organización. Al final es tu organización la que debe asumir el cambio en las restricciones por culpa de la decisión, ya sean en insatisfacción del cliente o en aumento de costes.

Si tenemos claro que el cliente tiene razón, hablamos de un fallo en la toma de requisitos y en una materialización de un riesgo. Si creemos que el cliente no tiene razón, podemos tener dos visiones diferentes, y no me consigo decantar por ninguna:

  • Interpretarlo como un riesgo materializado.
  • Interpretarlo como gold-plating

Dado que en este caso hablamos muchas veces de riesgo materializado, es algo que me he acostumbrado a incluir en la gestión de riesgos. De hecho cuando elaboro el presupuesto de un nuevo proyecto, siempre intento estimar la probabilidad de que aparezcan estos champiñones por el camino, e incluirlos en la estimación de reservas de contingencias necesarias.

Solicitud de ampliación de alcance

Hay muchos términos para definir esta situación en el argot de los jefes de proyecto. Intentar meter un gol, regalo, poyaque o favorcillo son unos pocos. Hablamos de un aumento de alcance en el que el cliente asume que no estaba incluido pero que considera que tiene un escaso impacto sobre el resto de restricciones y que se podría asumir dentro del proyecto sin hablar de cambios.

En caso de aceptarse, hablamos de un claro caso de gold-plating. Estamos ante una ampliación de alcance sin haber medido el impacto del cambio. La primera vez que me enfrenté a este problema cometí el error del novato: acepté al momento. ¿Por qué? Pues porque realmente era poco comparado con el montante total del proyecto y creí que agradaría al cliente. Y todavía hoy cuando se me plantea esta situación tengo mis dudas, aún y cuando al pensarlo fríamente sé lo que debo hacer.

En cualquier caso estamos hablando de gold-plating.

Ampliación proactiva de alcance

Veamos el siguiente caso:

Mientras acababa mis estudios en la Universidad, hacía de desarrollador freelance para sacarme cuatro duros. En esa tarea era Juan Palomo, yo hacía de comercial, de project manager, de desarrollador, … vamos que yo me lo guisaba todo. Así que tenía que hacer estimaciones. Tenía diseñado un sistema parametrizado para medir la complejidad de una aplicación basado en la cantidad de formularios, tablas e informes, que me daba una estimación de las horas que me llevaría desarrollarlo. La verdad es que no lo hacía por haberlo estudiado, sino porque era lo que el sentido común me dictaba, después de haberme pegado un par de tortazos. En esa etapa temprana de mi carrera, me salió un cliente que me pidió un sistema de gestión para una federación deportiva. Uno de los puntos fue el registro de socios. Yo interpreté que necesitaba una tabla para los socios, ya que de las conversaciones con el usuario clave se dedujo que se necesitaba un número de licencia deportiva en vigor, un teléfono de contacto, un nivel (número) del deportista, etc. Cerré presupuesto y me puse a desarrollarlo. Durante el desarrollo, llegué a la conclusión de que al cliente realmente le gustaría tener un listado de teléfonos de contacto (+1 tabla, +1 formulario), y sustituí el campo teléfono por una tabla de teléfonos. Lo mismo con el nivel, pensé que era mejor llevar una trazabilidad de en que fecha consiguió el deportista ese nivel (+1 tabla, +1 formulario). Después pensé en que cada año había que renovar la tarjeta deportiva… así que añadí un listado de licencias por año (+1 tabla, +1 formulario). Y así con otras cosas que no se me habían pedido: detección de DNI incorrecto, detección de Cuenta Bancaria Incorrecta, cargar un listado de códigos de banco y que el formulario te diga de qué banco es la cuenta, añadí el campo de email y lo integré con outlook para enviar mails (que en aquel momento tenía su historia), y un largo etcétera de funcionalidades que no se me había pedido. Bañé el formulario de gestión de socios en oro. Claro, el tiempo que tardé en desarrollarlo fue el triple de lo estimado. Pero lo peor ya no fue eso. La primera decepción fue ver que al cliente le gustó, pero tampoco como para tirar cohetes. La segunda y peor fue cuando me llamó enfadado porque no había puesto un informe con un listado del histórico de niveles del socio y que ahora no podía imprimirlo. Es decir, no sólo no aumentó la satisfacción del cliente en lo esperado, sino que además aumentó sus quejas. Me tocó hacer ese informe.

Seguro que todos los que me leáis en algún momento os habéis encontrado en una situación similar. O vosotros como project manager o un miembro de vuestro equipo habéis regalado de forma proactiva algo que no se había pedido. Es otro caso de gold-plating. Pero a diferencia de lo anterior, no es ya sólo un caso de gold-plating “forzado” sino que lo habéis generado vosotros mismos.

EDITO: Tal y como señala Joan Barceló en un comentario, esta ampliación proactiva puede venir de la dirección del proyecto o de forma oculta al project manager cuando un miembro del equipo desarrolla esta mejora por su cuenta. Este segundo origen puede tener muchas causas, desde ganas de retos técnicos por parte del miembro del equipo a una mala comunicación de los requisitos.

¿Es bueno el gold-plating?

Lo dicen las guías de buenas prácticas, te lo dicen los gurús, te lo dice tu propia experiencia y aún así, seguimos practicando el gold-plating. Mi experiencia me dice un mensaje bien claro, el gold-plating no se te agradece, empeora la rentabilidad de tu proyecto y aumenta los riesgos.

¿Alguna vez te han aumentado el presupuesto un poquito porque te iría bien? Total, por 2.000 € más en un proyecto de 100.000 €, ¿qué más le da al cliente? Verdad que eso a nadie le entra en la cabeza. Pues ¿Por qué narices al revés no se asume lo mismo? No es recíproco, por lo tanto es algo a evitar.

Además el cliente se aferrará al alcance como si la vida le fuese en ello cuando incumplas alguno de los entregables, sin importar lo que le hayas “regalado”. Sobretodo si el cliente es una administración pública. He llegado a ver a un compañero darse de cabezazos (en sentido figurado) por intentar eliminar del alcance un punto que se había convertido en problemático. Para convencer al cliente le hizo varios “regalitos”. Al final se comió los “regalitos” y el alcance que quería eliminar. La frase del cliente era clara: “Ese regalo no te lo he pedido, lo otro sí.” ¡Y es que tenía razón!.

Los regalos proactivos al mínimo. Si se observa una mejora sustancial, primero se habla con el cliente que lo valore. Y entonces tratarlo como un cambio con todas sus consecuencias. Pero hay que intentar evitarlos.

Mantener la satisfacción del cliente

En los casos de proyectos contratados por otra organización, mantener la satisfacción del cliente está alineado con los objetivos de tu propia organización, ya que futuros proyectos pueden estar en ello. Así que nos veremos obligados a claudicar en algunas ocasiones. Esto tiene que estar alineado con nuestra propia estrategia comercial y no estar a criterio del project manager. Es decir, asumo que habrá en la empresa un responsable de la cuenta de ese cliente, o alguien que esté asumiendo esas funciones. Esa persona estará al cargo, a nivel comercial, de todos los proyectos que se hacen, han hecho y se harán con el cliente. Así que la decisión de claudicar debe ser de esa persona. Pero no libremente, esa persona tiene que conocer el impacto que tendrá su decisión, por lo que hablamos de un proceso de gestión de cambios interno. Como tal seguiremos los pasos habituales:

  • El cliente pide un cambio.
  • El PM estima el impacto en todas las restricciones del proyecto.
  • El gestor de la cuenta (actuando como patrocinador interno del proyecto) estima si debe aplicarse y dotará de recursos al proyecto.
  • El PM realiza el cambio con más presupuesto.

¿Pero, más presupuesto? Si, más presupuesto. El cliente no paga más, pero tu organización sí. Lo debe sacar de las reservas de gestión. Así el gestor de la cuenta debe justificar su decisión ante la dirección para solicitar esa reserva, si es que no la gestiona el mismo. Al final la decisión afectará a la cuenta de resultados de ese gestor de cuentas, pero no del project manager. ¿Qué culpa tiene el project manager de que el gestor de la cuenta se dedique a regalar cosas?

Otro caso es el que el gestor de cuentas o el project manager vean que se trata de una mala definición de alcance, ahí el project manager deberá apechugar con el problema y tirar de sus reservas de contingencias, si es que ha previsto que eso le podía pasar.

Inflar presupuestos

Una práctica común es asumir que te va a pasar e inflar el presupuesto. Primero, inflar el presupuesto es mala práctica. Si lo haces, hazlo bien y claro: define el riesgo y crea la reserva adecuada. Pero no infles estimaciones. Pero mucho ojo con esto, porque es la solución fácil al problema. Si ves que va a haber un problema con el alcance, intenta atacar a la raíz del problema: invierte más en definir ese alcance y limita ese riesgo. Porque si se trabaja con presupuestos hinchados, corremos el riesgo de que no nos contraten. Yo he hecho eso en el pasado en un concurso público y lo he perdido. Cuando al cliente un año más tarde le dije que yo pensaba haber hecho más que lo que había hecho el ganador, me respondió: “¿Lo pedía el pliego?” Y quedo claro el error que había cometido.

Otras veces la estrategia comercial te dice algo como “Infla un poco el presupuesto porque este proyecto es estratégico y hay que quedar muy bien.” Mi opinión es que como project managers debemos entregar un presupuesto realista así que ese inflado debe venir de funcionalidades concretas que te diga el comercial que incluyas (no te dirá ninguna), o si no que lo infle luego el mismo. No es plantear al gestor de la cuenta como el enemigo, pero al cesar lo que es del cesar. Yo planifico y pongo coste: el beneficio comercial o los regalitos que se esperan dar los debe poner el gestor de la cuenta. Es lo mejor, porque así el decidirá en qué grado quiere regalar cosas. Nuestra estimación de recursos del proyecto debe estar bien hecha.

Conclusión

Repite conmigo: “Minimizaré el gold-plating” Y si se hace, siempre debe ser una decisión informada por parte del patrocinador, o del gestor de la cuenta si es un proyecto contratado.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

3 comments

  1. Joan Barceló 22 Diciembre, 2014 at 16:19 Responder

    Hola Jose!

    enhorabuena por el artículo, creo que aportas información muy completa sobre un tema bastante delicado. La línea que separa la gestión de expectativas del Gold Plating es muy delgada 😉

    En mi opinión, hay también otros aspectos que normalmente no se tienen en cuenta al tratar de evitar el Gold Plating: la falta de información del equipo de trabajo sobre las tareas que debe realizar y, algo bastante frecuente en el sector IT, la falta de motivación de personas que se sienten capacitadas para realizar tareas más complejas de las que tienen asignadas.

    Te dejo el enlace a un artículo que publiqué hace ya dos años relacionando este concepto:

    http://hands-on-pm.blogspot.com.es/2011/10/gold-plating-los-entregables-chapados.html

    Un cordial saludo!

Post a new comment

Te puede interesar...

Yo soy mejor que tú

Existe una tendencia natural a considerarnos mejores que los demás, aunque no lo seamos. ¿Qué lecciones podemos aprender de esto?