8.0 Casos prácticos | Dos proyectos, los mismos tres problemas

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

8.0 Casos prácticos — dos proyectos con el mismo encargo tropezaron con los mismos tres problemas, y terminaron con once semanas de diferencia

Conviene empezar por el hecho entero, sin suavizarlo: dos proyectos con el mismo encargo, la misma clase de presupuesto y gente igual de buena tropezaron con los mismos tres problemas, en las mismas semanas, y terminaron con once semanas de diferencia. El primero —lo llamaremos proyecto A— se recibió en la semana 28 con dos semanas de retraso sobre las veintiséis previstas. El segundo —el proyecto B— se recibió en la semana 39, y con una lista de sesenta puntos pendientes que nadie sabía cómo cerrar. Y el giro que sostiene este capítulo entero es que la diferencia no fue el talento ni la suerte: fueron los días de silencio. Los días que pasaron entre que cada problema existió y que alguien de fuera del equipo se enteró por escrito. Esta página recorre los tres problemas uno por uno, con lo que hizo cada proyecto en cada caso, y dedica después una sección entera —la más importante de la página— a explicar por qué lo que hizo B era razonable. Porque lo era: en los tres casos B tomó la decisión que toma la mayoría de la gente competente, y ninguna de las tres parecía importante el martes que ocurrió.

Dos proyectos con el mismo encargo

El encargo es de los que se hacen todos los años en cualquier pyme industrial: implantar un sistema de control de presencia en una planta con turnos, con lectores en dos accesos, integración con el sistema de nómina del cliente y formación a los mandos. Veintiséis semanas previstas en los dos casos. Presupuesto de la misma clase. Equipos parecidos: un jefe de proyecto que además lleva otras cosas, un técnico de instalación, alguien de sistemas a media dedicación y un comercial que aparece cuando hay que firmar algo.

El proyecto A se recibió en la semana 28. Dos semanas tarde. Se recuerda dentro de la empresa como un proyecto que salió bien, y esa memoria es correcta aunque haya terminado tarde, por razones que desarrolla 8.1 Proyectos que salieron bien.

El proyecto B se recibió en la semana 39. Trece semanas tarde, con una lista de sesenta puntos pendientes y una factura en discusión. Nadie lo llama fracaso —se entregó, se cobró y la instalación funciona— pero nadie lo repite con gusto. Los seis momentos concretos en que se decidió eso están en 8.2 Lecciones de un proyecto fallido.

Qué son exactamente el proyecto A y el proyecto B

Antes de seguir hay que decir con precisión qué está leyendo, porque el resto del capítulo depende de ello.

A y B son composiciones a partir de casos reales de implantación de control de presencia en industria. No son un proyecto único, no son un cliente identificable y no hay detrás ninguna empresa a la que se le puedan poner ciudad, sector o nombre. Los tres problemas son reales en el sentido de que aparecen una y otra vez en esta clase de trabajo; las semanas concretas y los recuentos son ilustrativos, y están ahí para que el mecanismo se pueda ver, no para que se citen como dato.

Y de ahí sale la frase que hay que dejar escrita antes que ninguna otra, porque es la que impide que este capítulo se lea como si fuera estadística: no existe ninguna estadística española de tasas de éxito o fracaso de proyectos que resista un examen metodológico.

Conviene ser explícito sobre lo que eso significa en la práctica, porque el hueco se llena solo. No hay una cifra fiable de qué proporción de proyectos españoles termina tarde. No hay una comparación de países que aguante. No hay un dato agregado de sobrecoste publicado por el Tribunal de Cuentas —fiscaliza contrato por contrato y publica informes individuales, de modo que o se cita un informe concreto con su número, o no se cita nada—. Y las cifras que circulan traducidas en artículos y presentaciones proceden en su inmensa mayoría de la misma fuente global, cuya metodología lleva veinte años cuestionada en la literatura académica.

Esto no es un tecnicismo. Es la razón por la que este capítulo está escrito con dos casos y no con una tabla de porcentajes: un mecanismo que usted puede reconocer en su propio proyecto vale más que una cifra que no puede comprobar. Si al terminar estas tres páginas usted piensa «esto me pasó en marzo», el capítulo ha funcionado. Si piensa «entonces la mayoría de los proyectos fracasa», el capítulo ha fallado, y además le ha dejado en la cabeza un número que nadie puede sostener.

Los tres problemas, uno por uno

Las tres filas de la tabla del diagrama son los tres problemas. El enunciado es idéntico en los dos proyectos —esa es la gracia del ejercicio—; lo que cambia es la columna del medio y la de la derecha.

Semana 9 · el tercero no contesta

El proveedor del sistema de nómina del cliente tiene que entregar la especificación de la interfaz: qué campos salen, en qué formato y con qué periodicidad. Sin eso no se puede programar la integración. Es un tercero clásico: no es su proveedor, no le paga usted, no depende de usted, y sin embargo su proyecto se para si no contesta. Ésta es exactamente la dependencia que ningún cronograma refleja bien, porque en el diagrama de barras aparece como una tarea de tres días y en la realidad es una espera de duración desconocida.

Qué hizo A. Lo puso en el informe del jueves con los días acumulados de espera, y pidió al cliente que le pusiera fecha. No escaló, no se quejó, no amenazó con nada: escribió una línea que decía desde qué día se estaba esperando y qué decisión hacía falta. El destinatario de esa línea no era el proveedor —al proveedor ya se le había escrito— sino el cliente, que es el único que tiene relación contractual con él.

Qué hizo B. Siguió insistiendo por su cuenta. Correo el lunes, llamada el jueves, otro correo la semana siguiente. Todo perfectamente profesional, todo por escrito, y nada de ello llegó nunca al informe. Cuando el asunto por fin se puso encima de la mesa, la pregunta del cliente fue la peor posible: «¿y esto desde cuándo?». Nadie tenía la respuesta, porque nadie había escrito nunca desde qué día se estaba esperando.

La diferencia entre los dos no está en el esfuerzo. B trabajó más en este punto que A. Está en quién sabía que existía el problema, y en qué formato lo sabía. La mecánica de convertir una espera en un número que alguien puede llevar a una reunión está en 6.3 Informes de proyecto, y la forma de reflejarla en el tablero, en 5.2 Tablero Kanban.

Semana 16 · piden un cambio de plano

En una visita a la planta, el responsable de recursos humanos del cliente comenta que además de los dos turnos previstos hay que contemplar otros dos, porque en la nave de expedición se trabaja de otra manera. Lo dice de palabra, delante de seis personas, con normalidad y sin ninguna intención de forzar nada. Nadie en la sala percibe que acaba de pedirse un cambio.

Qué hizo A. Escribió tres líneas por correo esa misma tarde: qué se añade, qué cuesta y quién lo autoriza. Y esperó la respuesta antes de ejecutarlo. Tardó unos días en llegar la confirmación, y en esos días el equipo siguió con otra cosa.

Qué hizo B. Lo ejecutó y lo facturó después. El cliente había dicho que sí delante de todos; pedir una confirmación por correo habría sonado a desconfianza, y además el trabajo era pequeño. La factura, meses más tarde, acabó en discusión.

Aquí hay un fundamento legal que conviene tener presente desde antes de que ocurra, y que 8.1 Proyectos que salieron bien desarrolla: en una obra contratada a ajuste alzado, el artículo 1593 del Código Civil no concede aumento de precio por un cambio en el plano que produzca aumento de obra si el propietario no lo autorizó. Las tres líneas de A no eran una formalidad: eran la autorización. Las mismas tres líneas escritas después de ejecutar el trabajo no valen lo mismo. Cómo se separa una incidencia de un cambio, y qué se hace con cada uno, está en 6.2 Incidencias y cambios.

Semana 24 · nadie definió la recepción

El contrato no dice qué acto acepta la instalación ni quién lo firma. Dice que el último hito se cobra «a la entrega», y ahí se queda. No es un contrato mal hecho: es un contrato normal, redactado por gente que pensaba en el precio y en el plazo, que son las dos cosas que se discuten al firmar.

Qué hizo A. Lo detectó en la semana 24 —cuatro semanas antes de terminar— y acordó por escrito el acta y el criterio antes de que llegara el final. Media hora de conversación y un correo de confirmación. En la semana 28 hubo un documento que alguien firmó, con dos reservas concretas y su plazo para resolverlas.

Qué hizo B. Lo descubrió el día de la entrega. Y a partir de ahí, cada visita a la planta añadía puntos a una lista que no tenía criterio con el que cerrarse: como nadie había pactado qué significa «aceptado», cualquier observación era igual de válida que cualquier otra, y la lista sólo podía crecer. Llegó a sesenta puntos.

Ésta es la fila que más incomoda, porque en ella B no hizo nada mal: heredó un contrato que no contestaba a la pregunta. Lo que hizo A tampoco fue brillante; fue anticiparse cuatro semanas. La diferencia entre las dos cosas cabe en un correo.

Por qué lo que hizo B era razonable

Ésta es la sección que decide si esta página vale algo, y por eso conviene decirlo del modo más incómodo posible: en los tres casos, B tomó la decisión que toma la mayoría de la gente competente. No fue descuido, no fue pereza y no fue falta de oficio. Fue criterio profesional aplicado con normalidad.

En la semana 9, no dar la lata era lo correcto. El proveedor de nómina era el de siempre, con una relación de años y una persona conocida al otro lado. Aún quedaban muchas semanas de plazo. Escalar al cliente por un retraso de dos semanas en una especificación, cuando existe margen y la relación es buena, es exactamente la clase de gesto que le convierte a usted en el proveedor quejica, ése al que hay que gestionar. Cualquiera que haya trabajado con terceros sabe que ese capital se gasta una vez.

En la semana 16, pedir un correo de confirmación habría sonado a desconfianza. El cliente acababa de decir que sí delante de seis personas, en su propia planta, sin ninguna ambigüedad. Responder a eso con «¿me lo confirma por escrito?» es, en el registro habitual de una visita de obra, una forma educada de decir «no me fío de usted». Y encima el trabajo era pequeño. Nadie se juega una relación de meses por dos turnos más.

Y en la semana 24, sacar el problema de la recepción parecía adelantar un problema que quizá no llegara. El contrato no lo exigía. El cliente no lo estaba reclamando. Quedaban dos meses de trabajo por delante y una lista de cosas urgentes de verdad. Plantear en ese momento una cuestión contractual que nadie ha puesto sobre la mesa tiene un coste inmediato y seguro —la conversación incómoda— frente a un beneficio remoto e incierto. La aritmética emocional de esa decisión favorece siempre callarse.

De ahí sale la única conclusión que esta página quiere que usted se lleve, y es deliberadamente poco heroica: ninguna de las tres parecía importante el martes que ocurrió. Las tres eran decisiones pequeñas, defendibles, tomadas en veinte segundos entre dos cosas más urgentes. Ninguna de las tres se discutió en ninguna reunión. Y las tres sólo se pudieron discutir cuando ya habían pasado.

Por eso este capítulo no propone en ningún momento trabajar más ni tener más cuidado. Si el problema fuese descuido, la solución sería atención, y la atención se agota. Lo que separó a A de B fue que A tenía cuatro mecanismos que funcionaban aunque nadie estuviera prestando atención: cuatro sitios donde estas cosas caían solas, sin que hiciera falta que alguien tuviera la lucidez de percibir, ese martes concreto, que aquello iba a costar once semanas.

Las dos páginas que siguen

El capítulo se reparte en dos miradas, y conviene saber para qué sirve cada una antes de entrar.

8.1 Proyectos que salieron bien mira qué hizo A y cuánto costó. Cuatro mecanismos, con su precio real al lado: veinte minutos a la semana, una columna más en una hoja que ya existía, un correo de tres líneas antes de ejecutar nada, y media hora de conversación en la semana 24. Ninguno pasa de media hora. Y —esto es lo único difícil— A no dejó de hacerlos cuando dejaron de doler. Esa página incluye además las tres cosas que A decidió no hacer, que son tres recomendaciones habituales que este proyecto descartó a conciencia.

8.2 Lecciones de un proyecto fallido mira los seis momentos de B de cerca. Los tres de esta página y otros tres que aparecen después: el informe que dejó de pedir nada en la semana 18, los criterios de uso del sistema elaborados sin los representantes de los trabajadores en la semana 26, y los noventa días de plazo de pago aceptados en la semana 30. Cada uno con las tres columnas completas: el momento, por qué callarse era razonable ese día, y lo que costó al final.

La advertencia española que atraviesa las tres filas

Queda un punto que hay que dejar claro antes de cerrar, porque cambia la lectura del tercer problema y porque se ignora sistemáticamente: fuera del ámbito de la edificación no hay recepción por defecto.

El Código Civil no contiene un deber general de recibir la obra. No hay en él un plazo para recibir, ni una exigencia de acta, ni una regla de recepción tácita aplicable a cualquier contrato de obra. Sólo hay dos supuestos estrechos: el de la obra pactada por piezas o por medida, donde el contratista puede exigir del dueño que la reciba por partes y que la pague en proporción, y donde se presume aprobada y recibida la parte satisfecha; y el de la obra pactada «a satisfacción del propietario», donde la aprobación, a falta de acuerdo, se defiere a juicio pericial.

Dentro del ámbito de la Ley de Ordenación de la Edificación el panorama es el contrario: la recepción está regulada como acto, el acta tiene contenido mínimo tasado, y existe una regla de silencio —salvo pacto expreso en contrario, la recepción se entiende tácitamente producida si pasan treinta días desde la notificación escrita de terminación sin reservas ni rechazo motivado por escrito—. Una implantación de control de presencia en una planta no está ahí: es instalación y sistemas, no edificación.

Y ésa es la razón por la que el tercer problema no es un descuido de B. Es el estado normal de un contrato español de instalación que nadie redactó pensando en esto. Si su contrato no dice qué acto acepta la instalación y quién lo firma, la respuesta por defecto no es «lo dice la ley»: es que no hay respuesta, y la discusión se resuelve por relación comercial en vez de por derecho, lo que en la práctica significa que se resuelve pagando. Las cuatro frases que conviene que su contrato contenga están en 2.4 Fase de cierre, y la secuencia completa de la entrega en los dos mundos, en 7.1 Entrega de entregables.

Un apunte de delimitación, para no mezclar regímenes: si su cliente es una administración pública —y sólo en ese caso— nada de lo anterior gobierna, sino la Ley de Contratos del Sector Público, con su acto formal de recepción y sus propios plazos. Esas reglas no se trasladan a un contrato privado.

Cómo se ve esto en AB

Tres cosas concretas, y las tres se hacen en una tarde sobre proyectos que ya existen.

Lo primero: ponga una fecha de inicio de espera a cada punto que dependa de alguien de fuera. No un responsable, no un estado: una fecha, la del día en que usted se quedó esperando. Es un campo. Con él, la pregunta «¿y esto desde cuándo?» tiene siempre respuesta, y esa respuesta es un número, no una impresión. Es literalmente el único mecanismo que separó a A de B en la semana 9.

Lo segundo: separe las incidencias de los cambios desde el primer día del proyecto, con dos tipos distintos y no con una etiqueta dentro de la misma lista. Una incidencia se resuelve; un cambio se autoriza, y quien lo autoriza tiene nombre. Si los dos viven en la misma lista, el cambio se ejecuta como si fuera una incidencia, que es exactamente lo que pasó en la semana 16.

Y lo tercero: cree el hito de recepción al crear el proyecto, no al terminarlo, con un campo que diga qué documento lo acredita y quién lo firma. Si al abrir el proyecto ese campo está vacío, usted acaba de descubrir el problema de la semana 24 en la semana 1, que es cuando cuesta media hora.

Términos de esta página

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

Recepción tácita

En edificación, treinta días desde la notificación escrita, y salvo pacto expreso en contrario. 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, no se resuelve — y no es lo mismo que una incidencia. 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 de un tercero es la que ningún cronograma refleja bien. Ampliar

Reservas

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

Contrato de obra

Se debe un resultado. La fuente de casi todas las reglas de este capítulo cuando la ley calla. Ampliar

LOE

La Ley 38/1999. Antes de discutir la recepción, decida si su obra está dentro o fuera de ella. Ampliar

LCSP

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

Informe de estado

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

Seguir leyendo