Documentar las decisiones de hacer o comprar es una de esas tareas que muchos directores de proyecto subestiman porque suena demasiado simple. Una lista con un par de justificaciones no parece un artefacto que vaya a definir el rumbo de una adquisición compleja. Sin embargo, esa simplicidad es justamente lo que la hace tan potente cuando se utiliza bien. El documento de decisiones de hacer o comprar recoge las conclusiones a las que llega el equipo sobre qué productos, servicios o resultados del proyecto se van a adquirir fuera de la organización y cuáles se van a desarrollar internamente. También puede incluir la decisión de contratar pólizas de seguros o fianzas de cumplimiento para cubrir riesgos específicos. Lo fundamental es que no se trata de un análisis detallado ni de un estudio de viabilidad, sino de un registro de lo que se ha decidido y por qué, en un formato que permita a cualquiera entender de un vistazo la lógica de abastecimiento del proyecto.
Tabla resumen: documentar decisiones de hacer o comprar
| Concepto | Descripción |
|---|---|
| Documento formal | Captura la decisión estratégica de adquirir externamente o desarrollar de manera interna, alineando capacidades y objetivos del proyecto. |
| Propósito | Ofrece una visión inmediata de los criterios de aprovisionamiento, diferenciándose de un estudio de viabilidad por su enfoque en la decisión final. |
| Criterios de decisión | La capacidad interna real, la urgencia de entrega, la ventaja competitiva y la confidencialidad determinan si es preferible construir o adquirir. |
| Marco PMBOK | El análisis formal se integra en los procesos de planificación de la gestión de adquisiciones (PMBOK 6, 12.1), aunque el artefacto resultante no es obligatorio. |
| Actualización iterativa | Revisarlo en cada ciclo de planificación refleja la madurez del equipo y evita la dependencia de comunicaciones informales o actas desactualizadas. |
| Aplicación en Scrum | El Product Owner evalúa si integrar un componente externo, como una API de pago, aporta más valor que desarrollar una historia de usuario, considerando el coste de oportunidad. |
| Estructura del documento | Incluye campos esenciales: elemento a evaluar, categoría, decisión adoptada, razonamiento clave, supuestos críticos, fecha de vigencia y responsable de la ejecución. |
| Beneficio principal | Permite al área de compras alinearse rápidamente con la estrategia del proyecto, reduciendo la fricción y acelerando las contrataciones sin interpretar documentos extensos. |
¿Qué contiene exactamente este documento?
El contenido puede ser tan escueto como una tabla con tres columnas: el elemento que se necesita, la decisión tomada (hacer o comprar) y una breve justificación. Por ejemplo, si un proyecto de desarrollo de software necesita un módulo de autenticación, la decisión podría ser "comprar" un servicio en la nube con la justificación "reduce el tiempo de desarrollo en tres meses y evita la contratación de especialistas en seguridad". No hay un formato estándar obligatorio; cada organización define el suyo según sus prácticas internas de gestión de proyectos. Lo que sí debe quedar claro es el razonamiento que respalda cada elección, porque más adelante, cuando las condiciones cambien, ese razonamiento será la base para reevaluar la decisión sin empezar de cero. El valor del documento radica en esa trazabilidad de las razones, no en la sofisticación del formato.
Una práctica habitual es incluir también los supuestos clave que se tuvieron en cuenta. Si se decide hacer internamente una pieza de infraestructura, el documento podría anotar que se asume la disponibilidad del equipo de operaciones durante los próximos seis meses. Estos supuestos son frágiles por naturaleza, y cuando uno de ellos se rompe, el director del proyecto necesita saber que esa decisión de hacer o comprar está en riesgo. El documento, entonces, funciona como un ancla que conecta las decisiones de adquisición con las condiciones operativas del proyecto. Sin ese registro, los supuestos se olvidan y la decisión original se vuelve inamovible por inercia.
Conviene no confundir este documento con el plan de gestión de las adquisiciones. El plan de adquisiciones describe cómo se van a gestionar los procesos de compra, los tipos de contrato, los criterios de selección de proveedores y los procedimientos de cierre. El documento de decisiones de hacer o comprar es un insumo para ese plan, una especie de hoja de ruta previa que delimita qué se va a comprar y qué no. En proyectos grandes, donde las adquisiciones son numerosas y variadas, tener este documento separado permite que el equipo de compras entienda rápidamente la estrategia de abastecimiento sin tener que descifrar todo el plan de gestión.
Justificaciones que van más allá del costo
Muchas veces se piensa que la justificación se reduce a un simple análisis de costos: si hacerlo sale más barato que comprarlo, se hace. La realidad es que las razones suelen ser más matizadas. La disponibilidad de capacidades internas, la urgencia del plazo, la criticidad del componente para la ventaja competitiva o incluso la confidencialidad de la información pueden inclinar la balanza hacia un lado u otro. Una decisión de comprar puede justificarse por la necesidad de transferir un riesgo técnico al proveedor, aunque el costo sea mayor. El documento debe capturar esos matices, porque cuando el proyecto avance y alguien cuestione por qué se externalizó algo que parecía sencillo, la respuesta tiene que estar escrita sin ambigüedades.
El análisis de hacer o comprar, como proceso formal, pertenece al grupo de procesos de planificación y al área de conocimiento de la gestión de las adquisiciones en el marco del PMBOK. Sin embargo, la documentación de las decisiones resultantes es un artefacto opcional que muchas organizaciones pasan por alto porque confían en que las actas de reunión o los correos electrónicos bastan. Ese es un error clásico: la memoria del proyecto es frágil y los correos se pierden. Tener un único lugar donde todas las decisiones de abastecimiento están consolidadas ahorra discusiones interminables en las fases posteriores.
Claves sobre el contenido del documento
- Formato libre y adaptable
- Cada organización define el formato según sus propias prácticas de gestión de proyectos, lo que permite ajustarlo a la complejidad y el contexto de cada caso.
- Razonamiento como núcleo
- El análisis que justifica cada decisión de hacer o comprar debe quedar explícito, de forma que pueda reevaluarse con agilidad si cambian las condiciones, sin necesidad de repetir todo el estudio.
- Supuestos frágiles documentados
- Las decisiones se apoyan en supuestos críticos, como la disponibilidad del equipo. Si uno de ellos se invalida, el director del proyecto debe identificar de inmediato el riesgo que corre la decisión asociada.
- Plan de adquisiciones complementario
- Este plan detalla los procesos de compra, los tipos de contrato aplicables, los criterios de selección de proveedores y los procedimientos de cierre, y resulta especialmente valioso cuando el proyecto alcanza una escala significativa.
La flexibilidad como principio rector
Las decisiones de hacer o comprar no están grabadas en piedra. Las notas originales lo dejan claro: estas decisiones pueden alterarse a medida que las actividades de adquisición posteriores muestren la necesidad de un enfoque diferente. Por ejemplo, un equipo puede decidir comprar un componente estándar, pero durante la búsqueda de proveedores descubre que ninguno cumple con los requisitos técnicos en el plazo necesario. En ese punto, la decisión inicial de comprar se vuelve insostenible y el proyecto debe virar hacia el desarrollo interno. Si el documento original está bien fundamentado, el equipo puede comparar la situación actual con los supuestos originales y tomar una decisión informada de cambio.
Esta capacidad de adaptación es más importante de lo que parece. Los proyectos rara vez transcurren según lo planeado, y el mercado de proveedores puede cambiar de un trimestre al siguiente. Una empresa que ofrece un servicio especializado puede dejar de operar, o puede surgir una nueva tecnología que haga innecesario el desarrollo interno. Mantener el documento como un artefacto vivo, que se revisa en cada gran iteración de la planificación, es una práctica que distingue a los equipos de proyecto maduros de los que simplemente siguen una receta administrativa.
En entornos ágiles, la noción de un documento formal de decisiones de hacer o comprar puede parecer contradictoria con la filosofía de simplicidad y documentación mínima. Sin embargo, la necesidad de decidir qué se construye y qué se adquiere no desaparece; simplemente se integra en las conversaciones de refinamiento del backlog y en la planificación de la iteración. En Scrum, por ejemplo, el Product Owner puede decidir que una historia de usuario se satisfaga mediante la integración de un API externa en lugar de desarrollarla desde cero. Esa decisión se documenta en la historia misma o en los criterios de aceptación. La práctica es menos formal que en un proyecto predictivo, pero no por ello menos rigurosa: el razonamiento sigue siendo explícito y trazable.
Cuándo incluir pólizas de seguro o fianzas
El documento puede extenderse para cubrir decisiones que no son estrictamente de hacer o comprar un producto, sino de adquirir protección financiera. Contratar una póliza de seguro para cubrir la pérdida de equipos críticos o exigir una fianza de cumplimiento a un proveedor clave son decisiones que mitigan riesgos identificados en el proyecto. Estas determinaciones encajan naturalmente en el mismo artefacto porque comparten la lógica de evaluar si la organización asume el riesgo internamente o lo transfiere a un tercero mediante un contrato. Cuando un proyecto decide exigir una fianza, está diciendo, en esencia, que prefiere comprar la seguridad de que el proveedor cumplirá, en lugar de absorber el impacto de un incumplimiento.
La inclusión de estos elementos en el mismo documento ayuda a consolidar la visión de abastecimiento del proyecto. No es raro que los seguros y las fianzas se gestionen en compartimentos separados, a veces por el equipo legal o por finanzas, y el director de proyecto pierda la trazabilidad de esas decisiones. Centralizarlas en un solo lugar, aunque sea con referencias a los contratos específicos, ofrece una imagen completa de la exposición al riesgo que el proyecto ha decidido transferir. Esta práctica es particularmente valiosa en proyectos de construcción o infraestructura, donde las fianzas de cumplimiento son casi una constante y su omisión en la documentación de adquisiciones puede generar confusiones sobre las responsabilidades contractuales.
Cómo estructurar el documento en la práctica
No existe una plantilla universal, pero la experiencia muestra que un formato tabular simple suele ser el más efectivo. Las columnas típicas incluyen: descripción del elemento, clasificación (producto, servicio, resultado, seguro o fianza), decisión (hacer, comprar o transferir), justificación breve, supuestos clave, fecha de la decisión y responsable. La columna de justificación no debería exceder las tres o cuatro líneas; si se necesita más espacio, es señal de que el análisis de base no se ha documentado adecuadamente en otro lugar. El documento es un resumen ejecutivo de las decisiones, no el análisis en sí mismo.
Algunas organizaciones añaden una columna de estado, que permite marcar si la decisión está vigente, en revisión o ha sido reemplazada. Esto facilita la lectura rápida durante las reuniones de seguimiento. Otra práctica útil es asociar cada decisión con el riesgo o la oportunidad que la originó, utilizando el registro de riesgos del proyecto como referencia cruzada. De este modo, si un riesgo se materializa o se mitiga, el equipo puede reevaluar inmediatamente todas las decisiones de hacer o comprar vinculadas a ese riesgo sin tener que escarbar en la memoria del proyecto.
Cuando el proyecto es pequeño, el documento puede ser una simple sección dentro del plan de gestión del proyecto, sin necesidad de un archivo independiente. La clave es que esté escrito, que sea accesible para todas las partes interesadas relevantes y que se actualice cuando las condiciones cambien. Un error común es crear un documento exhaustivo al inicio del proyecto y luego abandonarlo. Las decisiones de hacer o comprar no son un hito que se cumple y se olvida; son directrices vivas que necesitan ser revisitadas cada vez que se revisa la planificación del proyecto.
Errores frecuentes al documentar estas decisiones
Uno de los tropiezos más habituales es confundir la decisión con el deseo. Un patrocinador puede decir "esto lo compramos" sin que exista un análisis real de viabilidad. El documento debe reflejar decisiones tomadas tras un proceso de evaluación, no preferencias personales. Si el director del proyecto plasma esa instrucción sin más, está trasladando un riesgo de sesgo cognitivo a todo el proceso de adquisiciones. La justificación, por breve que sea, debe evidenciar que se consideraron alternativas y que la decisión se basa en criterios de negocio, no en corazonadas.
Otro error es dejar la justificación demasiado vaga. Frases como "es más eficiente" o "porque siempre lo hemos hecho así" no aportan nada cuando, meses después, hay que defender la decisión ante un auditor o un nuevo interesado. La justificación debe ser específica: mencionar plazos, costos estimados, capacidades internas disponibles o ausentes, riesgos concretos que se transfieren. Cuanto más concreta sea la redacción, más útil será el documento como herramienta de gobierno y menos como un trámite burocrático.
La falta de alineación con el plan de gestión de los riesgos es otro fallo que se repite. Una decisión de comprar un componente crítico puede ser en realidad una respuesta a un riesgo técnico identificado; si ese riesgo cambia de probabilidad o impacto, la decisión de comprar debería reevaluarse automáticamente. Sin embargo, si el documento de decisiones de hacer o comprar no está vinculado al registro de riesgos, esa conexión se pierde y el proyecto sigue ejecutando una estrategia de adquisición desfasada. Integrar ambos artefactos es una práctica de gestión de proyectos madura que evita que las decisiones queden flotando sin contexto.
Resumen esencial sobre estructuración
- Formato tabular simple
- El empleo de un formato tabular sencillo, con columnas dedicadas a la descripción del elemento, clasificación, decisión, justificación, supuestos, fecha y responsable, constituye la opción más efectiva en la práctica.
- Justificación limitada a tres o cuatro líneas
- La justificación debe limitarse a tres o cuatro líneas; si ocupa más espacio, esto sugiere que el análisis fundamental no ha sido debidamente documentado en otra sección.
- Estado y vínculo con riesgos
- Incorporar una columna de estado y enlazar cada decisión al registro de riesgos facilita la identificación inmediata de las decisiones vigentes y su reevaluación ante la materialización o mitigación de un riesgo.
- Documento vivo y proporcional
- En proyectos pequeños es suficiente con integrar la tabla en el plan de gestión; sin embargo, debe mantenerse por escrito, ser accesible y actualizarse periódicamente, ya que las decisiones de hacer o comprar constituyen directrices dinámicas que se revisan en cada ciclo de planificación.
Conexión con los procesos de la dirección de proyectos
En el marco del PMBOK, este documento se genera como salida del proceso "Planificar la Gestión de las Adquisiciones". Su creación es posterior al análisis de hacer o comprar y alimenta directamente la definición de la estrategia de adquisiciones y los enunciados del trabajo de las adquisiciones. En PRINCE2, la lógica es similar: las decisiones de hacer o comprar forman parte del enfoque de adquisiciones dentro del plan del proyecto, y se documentan en el registro de lecciones o en el plan mismo, dependiendo de la escala del proyecto. En ambos casos, la trazabilidad es el denominador común; se espera que cualquier interesado pueda entender por qué se tomó una decisión y bajo qué supuestos.
Esta trazabilidad se vuelve crítica durante las auditorías de proyecto o las revisiones de fase. Un auditor no solo verificará que los contratos se hayan firmado correctamente; también querrá entender por qué se decidió contratar externamente y no desarrollar internamente. Si el proyecto no puede mostrar un documento que recoja esa decisión y su justificación, la auditoría encontrará una debilidad de control interno, incluso si la decisión en sí fue acertada. Documentar no es solo una buena práctica, es una protección frente al escrutinio.
Desde la perspectiva de la gestión del valor del negocio, una decisión de hacer o comprar mal documentada puede erosionar los beneficios esperados del proyecto. Supongamos que un proyecto decide comprar una plataforma de atención al cliente en lugar de desarrollarla, con la justificación de acelerar el lanzamiento. Si esa decisión no está registrada, cuando el proyecto entre en operación y la plataforma comprada resulte insuficiente, será difícil reconstruir el razonamiento original y aprender de la experiencia. El documento actúa como un espejo retrospectivo que permite a la organización mejorar su criterio en futuros proyectos.
El papel del director de proyecto en la documentación
El director de proyecto no tiene por qué ser el autor material de cada línea del documento, pero sí es el custodio de su integridad. Su responsabilidad es asegurarse de que todas las decisiones de hacer o comprar que afectan al alcance, al cronograma o al presupuesto estén registradas y que las justificaciones sean defendibles. En equipos grandes, puede delegar la redacción en un especialista en adquisiciones o en un analista de negocio, pero la revisión final le corresponde a él, porque estas decisiones impactan directamente en la capacidad del proyecto para cumplir sus objetivos.
Una técnica que funciona bien es revisar el documento en cada reunión de control de cambios. Cuando se evalúa una solicitud de cambio que modifica el alcance, inevitablemente surgen nuevas necesidades de productos o servicios. El director de proyecto puede preguntar explícitamente: ¿esto lo hacemos o lo compramos? Y acto seguido, documentar la respuesta. Así, el documento crece de manera orgánica a lo largo del ciclo de vida, en lugar de ser un ejercicio puntual al inicio. Esta práctica también refuerza la disciplina de no dar por sentado que todo se hará internamente por defecto.
En proyectos donde se aplican métodos híbridos, el director de proyecto tiene que encontrar el equilibrio entre la documentación ligera que promueven los marcos ágiles y la necesidad de trazabilidad de los entornos predictivos. Una solución práctica es mantener un registro simple, quizás en una wiki o en una herramienta colaborativa, donde cada decisión de hacer o comprar se documenta en el momento en que se discute, con un formato de pocas líneas. No se necesita un documento formal con control de versiones estricto, pero sí un lugar común donde todas las partes puedan consultar el estado actual de las decisiones de abastecimiento.
La actualización como hábito, no como tarea
Convertir la actualización del documento en un hábito incrustado en la rutina del proyecto es más efectivo que programar revisiones trimestrales que a menudo se posponen. Cada vez que se cierra una ronda de negociaciones con un proveedor, cada vez que se recibe un prototipo interno que cambia la percepción de la capacidad del equipo, cada vez que un riesgo se materializa: esos son los momentos naturales para revisar si la decisión original de hacer o comprar sigue siendo válida. El documento no debería requerir un esfuerzo de mantenimiento desproporcionado; si se integra en el flujo de trabajo, se actualiza casi solo.
Algunas organizaciones vinculan el documento de decisiones de hacer o comprar con los hitos de aprobación del proyecto. Antes de pasar de una fase a la siguiente, se revisa el documento y se confirma que todas las decisiones siguen siendo coherentes con la realidad del proyecto. Esta verificación periódica forzada por el ciclo de vida ayuda a que el equipo no pierda de vista las decisiones que se tomaron al principio y que podrían haberse vuelto obsoletas. Un proyecto de dos años que nunca revisó sus decisiones iniciales de hacer o comprar está casi condenado a encontrarse con sorpresas desagradables en la recta final.
El valor de la brevedad
Hay una tentación comprensible de convertir este documento en un análisis exhaustivo que justifique cada decisión con gráficos de costo-beneficio y matrices de riesgo. Resístala. El documento gana efectividad cuando es breve. Su función no es contener el análisis, sino apuntar a él si alguien necesita profundizar. Una buena práctica es incluir referencias a los estudios de viabilidad, las cotizaciones de proveedores o las actas de las reuniones donde se discutió cada decisión. De esta manera, el documento se mantiene ligero pero conectado con la evidencia de respaldo.
La brevedad también facilita la comunicación con los interesados de alto nivel, que rara vez tienen tiempo de leer documentos extensos. Un patrocinador que necesita entender la estrategia de abastecimiento del proyecto en diez minutos agradecerá una tabla de una página que resuma las decisiones clave. Si necesita más detalle, sabe a qué documentos acudir. Esta separación entre el resumen ejecutivo y los análisis detallados es una práctica de comunicación efectiva que el director de proyecto puede adoptar sin añadir carga administrativa significativa.
Resumen: actualización como hábito
- Actualización integrada al flujo
- Cada cierre de negociación, cada prototipo recibido o cada riesgo materializado activa automáticamente la revisión de la decisión original de hacer o comprar.
- Revisión ligada a hitos
- Vincular el documento a los hitos de aprobación del proyecto obliga a confirmar la vigencia de las decisiones de hacer o comprar antes de pasar a la siguiente fase.
- Consecuencias de la falta de revisión
- Un proyecto de dos años que omite la revisión periódica de sus decisiones iniciales de hacer o comprar acumula riesgos ocultos que suelen manifestarse de forma disruptiva en la fase final.
- Brevedad con referencias externas
- Conviene mantener un resumen ejecutivo conciso y derivar los análisis detallados, como cotizaciones y estudios de viabilidad, a referencias o anexos, sin añadir carga administrativa al proceso de revisión.
Lecciones desde la gestión de valor del negocio
La metodología de gestión de proyectos orientada al valor del negocio, BVOPM, enfatiza la eliminación del desperdicio y la entrega de valor tangible, principios que encajan bien con la práctica de documentar decisiones de hacer o comprar de forma ágil. Desde esa óptica, documentar de manera excesiva una decisión de compra menor es un desperdicio en sí mismo; documentar de menos una decisión de subcontratación crítica es un riesgo evitable. El equilibrio se alcanza cuando el nivel de detalle de la documentación es proporcional al impacto de la decisión en los objetivos del proyecto. No todas las decisiones merecen el mismo espacio en el documento; algunas pueden resolverse con una línea, otras pueden requerir un párrafo más extenso.
En BVOPM, la noción de que las decisiones de hacer o comprar pueden cambiar sin que ello se interprete como un fallo del proyecto resulta particularmente relevante. Se asume que el aprendizaje durante la ejecución modificará las decisiones iniciales, y eso no es un síntoma de mala planificación, sino de adaptación inteligente. El documento, entonces, se convierte en un registro de esa evolución, lo que permite a los equipos futuros entender no solo qué se decidió, sino cómo y por qué se cambió de rumbo. Esta transparencia es oro puro para la mejora continua de los procesos organizacionales.
Impacto en la gestión de los interesados
Mantener un documento de decisiones de hacer o comprar actualizado y accesible reduce la ansiedad de ciertos interesados. El director financiero quiere saber qué gastos externos están comprometidos y por qué; el director técnico quiere entender qué capacidades se están desarrollando internamente. Si ambos pueden consultar un mismo documento y encontrar respuestas coherentes, se evitan incontables reuniones de alineación. La transparencia que genera este artefacto es un lubricante para las relaciones con los interesados, especialmente en entornos políticos donde las decisiones de subcontratación pueden ser sensibles.
Por otro lado, la falta de documentación puede erosionar la confianza. Si un interesado descubre que se tomó una decisión de comprar sin que exista un registro de la justificación, es probable que asuma que la decisión fue arbitraria o que se ocultó información. La documentación no solo sirve para la trazabilidad técnica; también es un mecanismo de rendición de cuentas que protege al equipo de proyecto de acusaciones de mala gestión.
Adaptación a diferentes tipos de proyectos
La forma de documentar variará sensiblemente según la naturaleza del proyecto. En un proyecto de construcción, las decisiones de hacer o comprar suelen estar muy definidas desde el inicio y es raro que cambien radicalmente, porque los contratos de obra son difíciles de renegociar. En ese contexto, el documento puede ser casi estático, pero debe incluir con precisión las partidas que se subcontratan y las que se ejecutan con medios propios. En un proyecto de desarrollo de software, en cambio, las decisiones pueden cambiar con cada iteración, y el documento tiene que ser lo bastante flexible para absorber esos vaivenes sin convertirse en un cuello de botella administrativo.
Los proyectos de investigación y desarrollo presentan un desafío particular. A menudo, la viabilidad técnica de hacer algo internamente no se conoce hasta que se ha avanzado bastante en la investigación, por lo que la decisión de hacer o comprar no puede tomarse con certeza al inicio. En estos casos, el documento puede reflejar decisiones condicionales: "Si el prototipo interno alcanza el nivel de madurez X en la fecha Y, se hará internamente; en caso contrario, se comprará". Estas bifurcaciones documentadas permiten al equipo de proyecto gestionar la incertidumbre sin paralizar las adquisiciones.
La clave está en reconocer que el documento es una herramienta de comunicación y control, no un fin en sí mismo. Si su formato o su contenido no se adaptan al ritmo del proyecto, se convertirá en un estorbo que nadie mantiene. La flexibilidad en la forma de documentar es tan importante como la flexibilidad en las propias decisiones de hacer o comprar.
La conexión con la gestión de la configuración
Aunque a primera vista no lo parezca, el documento de decisiones de hacer o comprar tiene un parentesco cercano con la gestión de la configuración. Cada decisión define, en cierto modo, la procedencia de un componente del producto final: si viene de fuera o de dentro. Cuando ese componente necesita un cambio, saber su origen es esencial para entender el proceso de control de cambios aplicable. Un componente comprado externamente puede requerir una negociación contractual para modificarse; uno desarrollado internamente puede ajustarse con una orden de trabajo. El documento de decisiones de hacer o comprar proporciona ese contexto de origen que la gestión de la configuración necesita para ser efectiva.
Por eso, en proyectos de alta complejidad técnica, donde la configuración del producto es crítica, el documento de hacer o comprar se integra con el plan de gestión de la configuración. No es raro que los elementos de configuración se etiqueten con su origen, y esa etiqueta se deriva directamente de este documento. Así se cierra un círculo de trazabilidad que va desde la decisión estratégica de abastecimiento hasta el control diario de cambios en el producto.
Claves para adaptar la documentación
- Documentación según proyecto
- Documentar las decisiones de hacer o comprar exige un enfoque adaptado, ya que los factores críticos como el plazo de entrega, la madurez técnica y el presupuesto pesan de manera distinta en cada contexto.
- Construcción: decisiones estáticas
- En construcción, las decisiones suelen cerrarse en la fase de planificación, por lo que el documento es casi estático: enumera las partidas que se subcontratan y aquellas que se ejecutan con recursos internos.
- Software: flexibilidad iterativa
- En desarrollo de software, las decisiones de hacer o comprar fluctúan entre iteraciones; el documento debe adaptarse ágilmente, absorbiendo cambios sin generar retrasos administrativos.
- Decisiones condicionales ante incertidumbre
- Cuando la viabilidad técnica es incierta al inicio, conviene documentar bifurcaciones claras: si el prototipo alcanza la madurez X para la fecha Y, se desarrolla internamente; de lo contrario, se compra.
- Conexión con configuración
- El documento se conecta con la gestión de la configuración, pues modificar un componente adquirido obliga a revisar el contrato, mientras que ajustar uno desarrollado internamente solo requiere una orden de trabajo.
La perspectiva del análisis de riesgos
Las decisiones de hacer o comprar son, en esencia, respuestas a riesgos. Cuando un proyecto decide hacer internamente, está aceptando riesgos técnicos y de recursos, pero retiene el control. Cuando decide comprar, transfiere parte del riesgo al proveedor, pero introduce riesgos de dependencia y de calidad. El documento de decisiones de hacer o comprar debería reflejar esta dualidad. Una buena práctica es incluir, aunque sea de manera sucinta, el riesgo principal que se está gestionando con cada decisión. Esto permite que, durante las revisiones periódicas de riesgos, el equipo evalúe si la decisión de transferir un riesgo mediante la compra sigue siendo efectiva o si ese riesgo se ha transformado en algo distinto.
Imaginemos un proyecto que decide comprar un servicio de alojamiento en la nube para transferir el riesgo de caídas del sistema. El documento registraría esa decisión con su justificación de transferencia de riesgo. Meses después, el proveedor sufre una brecha de seguridad y el riesgo de caída se transforma en un riesgo de exposición de datos. La decisión inicial de comprar quizás ya no es suficiente para mitigar el nuevo perfil de riesgo. Si el documento está vinculado al registro de riesgos, el equipo identificará este desacoplamiento y podrá actuar, por ejemplo, contratando un seguro adicional o migrando a otro proveedor.
Errores de sobre-documentación
Tan perjudicial como documentar de menos es documentar de más. Algunos equipos, movidos por un celo excesivo, redactan justificaciones tan extensas que nadie las lee. El resultado es un documento que intimida y que rara vez se actualiza porque hacerlo es una tarea titánica. La sobre-documentación mata la utilidad práctica del artefacto. Si una decisión de comprar un lote de tornillos para un prototipo requiere tres párrafos de justificación, el documento ha perdido el norte. La habilidad del director de proyecto está en calibrar cuánta justificación es suficiente para cada decisión, reservando la profundidad para aquellas que realmente impactan en los objetivos críticos del proyecto.
Una regla práctica que circula entre profesionales es la de "la prueba del pasillo": si le explicas la decisión a un colega en el tiempo que se tarda en recorrer un pasillo y esa explicación basta para que entienda la lógica, entonces la justificación documentada no debería ser mucho más larga que esa conversación. Si la decisión requiere una reunión de una hora para ser comprendida, probablemente merezca una justificación más extensa y referencias a los análisis que la sustentan. Esta regla no es un estándar, pero ayuda a poner en perspectiva el volumen de documentación realmente necesario.
El futuro de este artefacto en entornos digitales
Con la creciente adopción de herramientas de gestión de proyectos basadas en inteligencia artificial, es posible que en pocos años la documentación de las decisiones de hacer o comprar se automatice parcialmente. Las herramientas ya pueden analizar las actas de reuniones, los correos electrónicos y los historiales de chat para extraer decisiones y justificaciones. Sin embargo, la validación humana seguirá siendo imprescindible. Una máquina puede sugerir que se tomó una decisión, pero solo el director de proyecto puede confirmar que esa decisión refleja la intención real del equipo y que los supuestos registrados son correctos. El documento del futuro será, probablemente, un panel en tiempo real que se actualiza con cada interacción relevante, pero la responsabilidad de su exactitud seguirá estando en las personas.
Mientras ese futuro llega, la práctica sólida de mantener un documento simple, vivo y conectado con los demás procesos del proyecto es una inversión de bajo costo que paga dividendos en claridad, trazabilidad y capacidad de adaptación. Los equipos que lo integran en su día a día rara vez vuelven a la práctica de gestionar las adquisiciones a ciegas, porque descubren que saber exactamente por qué se decidió comprar o hacer es, en sí mismo, una ventaja competitiva en la ejecución de proyectos.
Resumen: futuro digital y validación humana
- Automatización parcial de decisiones
- Las herramientas de IA podrán analizar actas, correos electrónicos y conversaciones de chat para extraer decisiones de hacer o comprar, automatizando parte de la documentación en pocos años.
- Validación humana imprescindible
- Solo el director del proyecto puede confirmar que la decisión registrada refleja la intención real del equipo y que los supuestos documentados son correctos.
- Panel en tiempo real y práctica sólida
- El documento futuro será un panel que se actualiza con cada interacción relevante; no obstante, la responsabilidad de su exactitud seguirá en las personas, por lo que mantener un documento simple, vivo y conectado constituye una inversión de bajo coste.
