8.1 Proyectos que salieron bien | Cuatro mecanismos baratos

Capítulo 8 · 8.1 Volver al índice de la guía

8.1 Proyectos que salieron bien — cuatro mecanismos baratos, sostenidos veintiocho semanas

La frase que hay que decir primero, porque desmonta la expectativa con la que se abre una página como ésta: el proyecto A no hizo nada brillante. No tuvo un método, ni una herramienta nueva, ni un jefe de proyecto excepcional. Terminó dos semanas tarde sobre las veintiséis previstas, se recibió en la semana 28, y aun así se recuerda dentro de la empresa como un proyecto que salió bien. Lo que hizo fueron cuatro cosas baratas —ninguna pasa de media hora— y, esto es lo único difícil de las cuatro, no dejó de hacerlas cuando dejaron de doler. Ésa es toda la diferencia con el proyecto B de 8.0 Casos prácticos, que tropezó con los mismos tres problemas en las mismas semanas y se recibió once semanas después. Esta página recorre los cuatro mecanismos con su coste real al lado, dedica una sección entera a las tres cosas que A decidió no hacer —tres recomendaciones habituales que este proyecto descartó a conciencia— y termina con una pregunta que se puede contestar hoy: de los cuatro, ¿cuál puede empezar usted el jueves que viene sin pedirle nada a nadie?

El proyecto A no hizo nada brillante

Conviene quitarle el brillo antes de contarlo, porque si no la página se lee como el retrato de un equipo excepcional y no sirve para nada.

El jefe de proyecto de A llevaba otras dos cosas a la vez. El técnico de instalación se puso enfermo dos semanas en primavera. El cliente cambió de interlocutor a mitad de proyecto. La integración con el sistema de nómina se atascó por culpa de un tercero que no dependía de nadie del equipo. Nada de eso se resolvió con talento: se resolvió tarde, mal a ratos, y con dos semanas de retraso al final.

Tampoco hubo herramienta nueva, ni certificación, ni consultoría, ni un cambio de método a mitad de camino. La misma hoja de cálculo de siempre, el mismo correo, las mismas reuniones quincenales de seguimiento que ya existían antes.

Lo único que este proyecto tuvo y el otro no fueron cuatro sitios donde las cosas caían solas. Cuatro hábitos pequeños que funcionaban aunque nadie estuviera prestando atención ese martes concreto. Es una tesis poco vistosa, y es la única que sobrevive al contraste con la realidad de una pyme industrial: los mecanismos que dependen de que alguien esté lúcido fallan exactamente el día en que hacía falta que funcionaran.

Una precisión sobre qué está leyendo

Antes de entrar en el detalle: el proyecto A es una composición a partir de casos reales de implantación de control de presencia en industria, igual que el proyecto B. No es un proyecto único, no hay detrás un cliente al que se le pueda poner nombre, ciudad o sector, y las semanas y los recuentos son ilustrativos: están ahí para que el mecanismo se pueda ver, no para que se citen como dato.

Y lo que vale para el caso vale para el capítulo entero: no existe ninguna estadística española de tasas de éxito o fracaso de proyectos que resista un examen metodológico, de modo que en esta página no va a encontrar ninguna proporción de proyectos que salen bien, ninguna comparación entre países y ningún porcentaje de mejora atribuido a ninguno de los cuatro mecanismos. Lo que va a encontrar es el mecanismo, su coste y el fundamento legal donde lo hay.

Los cuatro mecanismos, con su coste al lado

Las cuatro tarjetas verdes del diagrama son los cuatro mecanismos, y cada una lleva debajo la línea que más importa: lo que costó. Conviene leerlas en ese orden —primero qué es, después qué costó—, porque el precio es la parte que decide si usted va a hacerlo.

Uno · el informe del jueves

Una página, todos los jueves, y la primera línea siempre con la decisión que hacía falta esa semana. No un resumen de lo hecho, no una lista de tareas cerradas, no un semáforo de colores: una línea que decía qué necesitaba el proyecto de alguien de fuera, y para cuándo.

Lo que costó: veinte minutos, veintiocho jueves seguidos.

Esa primera línea es el mecanismo entero. Un informe de estado que sólo cuenta lo hecho no pide nada, y lo que no pide nada no se lee: se archiva. En cambio un informe cuya primera línea dice «necesitamos que el proveedor de nómina se comprometa a una fecha; llevamos esperando desde el 14» obliga al que lo recibe a hacer algo, aunque sea contestar que no puede. Y esa respuesta, sea la que sea, saca el problema del equipo y lo pone donde puede resolverse.

Hay un efecto secundario que conviene nombrar porque es el que sostiene el hábito: el informe del jueves obligaba a alguien, una vez por semana, a preguntarse qué decisión hacía falta. Veinte minutos de esa pregunta valen más que cualquier reunión. La anatomía completa del informe, con la columna que dice por qué cada línea está ahí, está en 6.3 Informes de proyecto.

Dos · los días de espera

Cada punto que esperaba a alguien de fuera llevaba escrito desde qué día esperaba. No quién era el responsable —eso ya estaba—, no un estado de «bloqueado», sino una fecha concreta: el día en que el equipo se quedó parado esperando.

Lo que costó: una columna más en una hoja que ya existía.

Merece la pena detenerse en por qué esa columna cambia tanto por tan poco. Sin ella, la situación se cuenta con adjetivos: «vamos algo justos», «estamos pendientes de ellos», «se está complicando». Un adjetivo no se puede llevar a una reunión. Nadie puede decidir nada con «vamos algo justos», y quien lo escucha tampoco puede saber si eso significa tres días o dos meses, de modo que lo archiva junto con todos los demás adjetivos que ha oído esa semana.

Con la columna, la misma situación se cuenta así: «la especificación de la interfaz lleva parada desde el 14 de marzo; son veintidós días hábiles». Eso ya no es una impresión, es un número. Y un número tiene tres propiedades que un adjetivo no tiene: se puede comprobar, crece solo mientras nadie hace nada, y avergüenza discretamente a quien tiene la llave. Ninguna de las tres requiere que usted levante la voz.

Hay además una consecuencia contractual que casi nadie anticipa. Cuando al final del proyecto se discute un retraso, la conversación se juega sobre a quién es imputable. Si usted tiene escrito desde qué día estuvo esperando cada cosa, tiene una historia con fechas; si no lo tiene, tiene su palabra contra la del otro, y en esa discusión el que carece de registro pierde siempre. La forma de darle sitio visible a esa espera en el tablero está en 5.2 Tablero Kanban, y el seguimiento de lo que de verdad está aceptado, en 6.1 Seguimiento de entregables.

Tres · tres líneas antes

Ningún cambio se ejecutaba sin un correo previo con tres cosas: qué se añade, qué cuesta y quién firma. Tres líneas, enviadas la misma tarde en que se pedía el cambio, antes de tocar nada.

Lo que costó: una conversación incómoda en la semana 16.

La incomodidad fue real y conviene no minimizarla. El cliente había pedido dos turnos más de palabra, en una visita, delante de seis personas. Contestar a eso con un correo que dice «esto añade trabajo, cuesta esto, y necesito que lo autorice quien pueda hacerlo» tiene un coste social inmediato: suena a desconfianza, rompe el tono de la visita y obliga a alguien a asumir por escrito una decisión que había tomado de pasada. Ése es el precio del mecanismo, y es el único de los cuatro que duele.

Y aquí está el fundamento que convierte esa incomodidad en dinero. En una obra contratada a ajuste alzado, el artículo 1593 del Código Civil establece que el contratista no puede pedir aumento de precio aunque hayan subido los jornales o los materiales, pero sí puede pedirlo cuando se haya hecho algún cambio en el plano que produzca aumento de obra, siempre que el propietario hubiese dado su autorización. Léase entera la condición final, porque es todo el mecanismo: sin autorización del propietario, no hay aumento de precio.

De ahí sale la formulación que conviene memorizar: las tres líneas antes valen dinero; las mismas tres líneas después, no. Escritas antes, son la autorización que el artículo exige. Escritas después, son una reclamación, y una reclamación se discute. Es exactamente la diferencia entre lo que hizo A y lo que hizo B en la misma semana 16, y explica por qué la factura de B acabó en discusión y la de A no.

Un apunte para no mezclar regímenes: si su cliente es una administración pública —y sólo en ese caso— el juego no es el del artículo 1593, sino el de la Ley de Contratos del Sector Público, con sus propios límites a la modificación del contrato. No traslade uno al otro. Cómo se separa una incidencia de un cambio, y qué se hace con cada uno, está en 6.2 Incidencias y cambios.

Cuatro · la recepción, pactada

En la semana 24 —cuatro antes de terminar— alguien preguntó qué documento acepta la instalación y quién lo firma, y lo escribió. No lo negoció como una cláusula: lo planteó como una pregunta práctica, se acordó en una conversación y se confirmó por correo.

Lo que costó: media hora, y llegar antes que el problema.

La segunda mitad de esa frase es la parte importante. La misma conversación, el día de la entrega, no cuesta media hora: cuesta semanas, porque para entonces las dos partes ya tienen una posición y cada una tiene razones para preferir una definición distinta de «aceptado». En la semana 24 nadie tiene todavía nada que defender, y por eso se pacta en media hora.

Lo que se pactó fue poco y bastó: qué documento acredita la recepción, quién lo firma por parte del cliente, qué se comprueba para poder firmarlo, y qué pasa con lo que quede pendiente —las reservas, concretas y con su plazo de subsanación—. En la semana 28 hubo un acta con dos reservas y una fecha; el proyecto B, sin ese acuerdo, terminó con una lista de sesenta puntos que no tenía criterio con el que cerrarse.

Y el motivo por el que esto hay que hacerlo en España y no se puede dar por supuesto: fuera del ámbito de la edificación no hay recepción por defecto. El Código Civil no impone al cliente recibir la obra, no fija plazo para recibirla y no contiene una regla general de recepción tácita: sólo dos supuestos estrechos, el de la obra pactada por piezas o por medida y el de la obra pactada «a satisfacción del propietario». Si su contrato no dice qué acto acepta la instalación, no lo dice nadie. Las cuatro frases que conviene que contenga están en 2.4 Fase de cierre, y la secuencia completa de la entrega, en 7.1 Entrega de entregables.

Las tres cosas que A no hizo

Esta sección existe porque la lista de arriba, leída sola, se parece demasiado a cualquier lista de buenas prácticas. Lo que distingue a este proyecto no es sólo lo que hizo: es que descartó a conciencia tres recomendaciones que se dan por defecto, y le fue bien.

No tuvo reunión diaria

El equipo estaba repartido entre turnos: parte de la gente entraba a las seis de la mañana en la planta del cliente y parte trabajaba en horario de oficina. Una reunión diaria de quince minutos con todo el mundo presente no existía como opción realista; la versión practicable habría costado una hora de equipo al día —sumando desplazamientos, esperas y el corte en el trabajo de los que estaban montando— para transmitir lo que cabía en un mensaje.

Lo que hicieron en su lugar fue escribir. Un mensaje al final del turno con lo que había quedado parado, y el informe del jueves para lo que necesitaba una decisión. No es una alternativa elegante y no aparece en ningún manual, pero respetaba una restricción real del proyecto en vez de pelearse con ella. Cuándo una reunión periódica compensa y cuándo no, en 4.3 Plan de comunicación.

No cambió de herramienta

Siguió con la hoja de cálculo que todos abrían. Había una discusión abierta en la empresa sobre si convenía otra cosa —la hay siempre—, y esa discusión se aplazó al empezar el proyecto. Nunca hizo falta retomarla.

El coste de cambiar de herramienta a mitad de un proyecto rara vez se contabiliza entero: no es la licencia, es que durante unas semanas conviven dos sitios donde mirar, la gente deja de fiarse del dato y el jefe de proyecto pasa a dedicar una parte de su tiempo a explicar dónde está cada cosa. Una herramienta que todos abren y que refleja la verdad vale más que una mejor que sólo abre el que la eligió. Cuándo la hoja de cálculo se queda corta de verdad está en 5.5 Herramientas de gestión de tareas.

No escondió el retraso

Éste es el que más cuesta y el que más rinde. Las dos semanas de más se anunciaron en la semana 21, no en la 27. Es decir: se dijeron cuando aún eran una previsión y no un hecho consumado, con siete semanas por delante para que el cliente reorganizara lo que tuviera que reorganizar.

Anunciar un retraso pronto tiene un coste inmediato y evidente —la conversación mala se adelanta— y un beneficio que sólo se ve después: el cliente conserva margen de maniobra, y por eso no vive el retraso como un daño sino como una noticia. Anunciarlo en la semana 27 habría producido exactamente el mismo retraso con toda la mala fe encima, porque a esas alturas la única lectura posible es que se sabía antes y no se dijo.

Y de ahí sale la razón por la que este proyecto se recuerda como uno que salió bien pese a haber terminado tarde. Lo que la gente recuerda de un proyecto no es la desviación: es si tuvo que enterarse por sorpresa. Un retraso avisado a tiempo es una gestión; el mismo retraso descubierto al final es un incumplimiento, y da igual que la fecha sea la misma.

Por qué esto importa

Las tres son recomendaciones habituales: reunirse a diario, adoptar una herramienta como es debido, y —esto último de forma menos confesada pero igual de extendida— sostener el plazo mientras haya alguna posibilidad de recuperarlo. Un proyecto que salió bien descartó las tres a conciencia, no por descuido.

La conclusión práctica no es que esas tres cosas sean malas. Es que una práctica sólo vale lo que vale en su restricción concreta, y que copiar prácticas de contextos que no son el suyo consume el presupuesto de cambio que usted tiene —que es pequeño— en cosas que no le van a devolver nada. Antes de adoptar una, la pregunta útil es qué restricción de su proyecto resuelve. Si no resuelve ninguna, es un gasto.

Lo que de verdad distingue a los cuatro mecanismos

Mire la banda azul del diagrama, porque en ella está la propiedad común, y no es que sean buenas ideas.

Ninguno necesitaba permiso, presupuesto ni una herramienta nueva. Ninguno de los cuatro exigió convencer a un comité, esperar a enero, comprar nada ni cambiar el modo en que trabaja el resto de la empresa. Los cuatro se podían empezar un jueves por la tarde por decisión de una sola persona. Ésa es la razón por la que existieron: los mecanismos que requieren autorización se aplazan hasta el siguiente proyecto, y el siguiente proyecto empieza siempre con prisa.

Y los cuatro siguieron funcionando en las semanas tranquilas. Ésta es la parte difícil y la que separa de verdad. Un mecanismo no se abandona en la semana mala —en la semana mala todo el mundo escribe, informa y confirma por correo—. Se abandona en la semana tranquila, cuando no hay nada que contar y el informe del jueves parece una formalidad. Y se echa de menos exactamente en la siguiente semana mala, cuando ya no está en pie y volver a levantarlo cuesta el triple.

El proyecto B, sin ir más lejos, escribía informes en la semana 9. Lo que le pasó en la semana 18 fue que el informe seguía saliendo pero había dejado de pedir nada: tres actas seguidas con las mismas líneas palabra por palabra. Eso es un mecanismo abandonado sin que nadie tomara la decisión de abandonarlo. Está contado de cerca en 8.2 Lecciones de un proyecto fallido.

De modo que la prueba de si un mecanismo está vivo no es si existe el documento. Es si el documento de la semana tranquila pide algo distinto del de la semana anterior. Si tres informes seguidos son intercambiables, el mecanismo ya se cayó y nadie lo ha notado.

Y la pregunta con la que se cierra la página

De los cuatro mecanismos, ¿cuál puede empezar usted el jueves que viene sin pedirle nada a nadie?

La pregunta está formulada así a propósito. No es cuál es el mejor, ni cuál tiene más sentido en su empresa, ni cuál recomendaría un manual. Es cuál puede empezar usted, esta semana, sin una reunión previa, sin convencer a nadie y sin esperar a que termine lo que está en marcha. Porque los cuatro cumplen esa condición, y porque un mecanismo que necesita una conversación previa para arrancar tiene muchas probabilidades de no arrancar nunca.

Si sirve de orientación: el más barato de los cuatro es el segundo. Añadir una columna con la fecha desde la que se espera cada cosa no cambia el modo de trabajar de nadie más que usted, no obliga a ninguna conversación incómoda y produce un número desde el primer día. Es también el único de los cuatro que no necesita que nadie colabore.

Cómo se ve esto en AB

Cuatro cosas concretas, una por mecanismo, y ninguna lleva más de una tarde.

Lo primero: convierta la primera línea del informe en un campo del proyecto, no en un párrafo dentro de un documento. Un campo llamado «decisión que hace falta esta semana», visible en la vista de proyectos, hace dos cosas que un documento no hace: se puede dejar vacío —y verse que está vacío—, y se puede repasar en veinte segundos para todos los proyectos a la vez.

Lo segundo: añada a las tareas un campo de fecha «esperando desde», y ordene por él. No hace falta nada más: la lista ordenada por esa fecha es, literalmente, el orden en que hay que reclamar. Y el punto más antiguo de la lista es siempre el que más conviene sacar del equipo esta semana.

Lo tercero: haga que los cambios sean un tipo distinto de las incidencias, con un campo obligatorio de quién autoriza. Si el campo está vacío, el cambio no se ejecuta. Esa obligatoriedad es la versión automática de las tres líneas antes, y no depende de que alguien se acuerde.

Y lo cuarto: cree el hito de recepción al crear el proyecto, con dos campos: qué documento lo acredita y quién lo firma. Si al abrir el proyecto están vacíos, usted ha descubierto en la semana 1 el problema que a B le apareció el día de la entrega.

Términos de esta página

Informe de estado

Una página cuya primera línea dice qué decisión hace falta esta semana. Ampliar

Ajuste alzado

Precio cerrado por la obra completa. El régimen del art. 1593 del Código Civil vive aquí. Ampliar

Cambio

Una modificación de lo pactado. Se autoriza antes, o se discute después. Ampliar

Incidencia

Algo que ya ha ocurrido y hay que resolver dentro de lo pactado. Ampliar

Dependencia

Lo que su trabajo necesita de otro. La columna «esperando desde» existe por esto. Ampliar

Recepción

Entregar y aceptar. En edificación la regula la ley; fuera de ella, sólo su contrato. Ampliar

Acta de recepción

El documento que fija el día cero, con las reservas concretas y su plazo. Ampliar

Reservas

Lo pendiente que no impide aceptar. Concretas y con plazo, o no cierran nada. Ampliar

Recepción tácita

En edificación, treinta días desde la notificación escrita, y salvo pacto expreso en contrario. Ampliar

Hito

Un punto del calendario que se acredita con algo, no una fecha decorativa. Ampliar

LCSP

El régimen del sector público, y sólo de él. No se traslada a un contrato privado. Ampliar

Lecciones aprendidas

Sólo son lecciones si cambian algo comprobable: una plantilla, un precio, una cláusula. Ampliar

Seguir leyendo