Entregables del proyecto: definición, tipos y ejemplos

Pida a cinco personas de un equipo de proyecto que nombren "los entregables" y normalmente obtendrá cinco respuestas distintas: algunas serán tareas, otras serán objetivos y una probablemente será la fecha de un hito. Esa confusión no es un problema de vocabulario. Es un problema de planificación, porque un entregable es la única unidad de trabajo del proyecto que se acepta o se rechaza formalmente, y si el equipo no logra ponerse de acuerdo sobre qué cuenta como uno, tampoco habrá acuerdo sobre qué significa "terminado".

Key Facts

• La propia guía del PMI sobre declaraciones del alcance describe los entregables como "elementos principales, de nivel resumido, cuya entrega completa y satisfactoria marca la finalización del proyecto", una definición que el PMI ha usado de forma consistente en su guía sobre el alcance del proyecto.
• La Guía del PMBOK, octava edición (PMI, noviembre de 2025) es el estándar vigente y nombra al alcance, el dominio que rige lo que un proyecto debe entregar, como uno de siete dominios de desempeño junto con gobernanza, cronograma, finanzas, partes interesadas, recursos y riesgo.
• La investigación Pulse of the Profession del PMI (2014, serie "The High Cost of Low Performance") encontró que casi la mitad, el 47 %, de los proyectos fallidos no alcanza sus objetivos por una gestión inexacta de los requisitos, la misma brecha que más tarde aparece como entregables que nadie logra ponerse de acuerdo en si realmente estaban terminados.
• La Scrum Guide define un Increment, la versión ágil de un entregable, como utilizable en el momento en que cumple con la Definition of Done del equipo: "En el momento en que un elemento del Product Backlog cumple con la Definition of Done, nace un Increment".

Qué es un entregable del proyecto

Un entregable del proyecto es todo resultado único y verificable, ya sea un producto, un documento, un servicio o un resultado, que un proyecto debe producir y entregar formalmente antes de que esa parte del trabajo se considere completa. Un entregable no es un objetivo ni una tarea. Es una cosa: algo lo bastante específico como para señalarlo, inspeccionarlo y aceptarlo o devolverlo.

La propia guía del PMI sobre declaraciones del alcance plantea los entregables del mismo modo: "elementos principales, de nivel resumido, cuya entrega completa y satisfactoria marca la finalización del proyecto". Esa es, por sí sola, una prueba útil. Si no puede describir algo como un elemento que se entrega y se acepta satisfactoriamente, probablemente no sea un entregable, sino una fase, una actividad o un objetivo disfrazado con el nombre de un entregable.

Los entregables están en el centro de cómo un proyecto se planifica y se controla realmente. Surgen de la declaración del alcance del proyecto, se descomponen mediante la estructura de desglose del trabajo en piezas programables y se aprueban según los criterios de aceptación. Todos los demás artefactos de planificación de un proyecto, el cronograma, el presupuesto, el RACI, existen para que los entregables se produzcan y se acepten a tiempo.

Entregable vs hito vs objetivo vs resultado vs tarea vs requisito

Aquí es donde la mayoría de las páginas sobre proyectos se vuelven vagas, y donde la mayoría de los proyectos realmente se topan con problemas. Seis términos se usan casi como sinónimos en la conversación informal, y cada uno responde a una pregunta genuinamente distinta. Esta es una prueba de una línea para cada uno.

Leer la tabla de izquierda a derecha traza la cadena real de trabajo en la mayoría de los proyectos: un objetivo de negocio justifica el proyecto, el proyecto produce entregables, cada entregable debe satisfacer un conjunto de requisitos, entregarlo exige una serie de tareas, terminarlo se marca con un hito, y si el proyecto tiene éxito, todo ello termina apareciendo como un resultado que el negocio puede señalar. Mezclar estos términos en un plan es la forma en que "construir la página de inicio" (una tarea) termina listada junto a "aumentar la conversión" (un objetivo) en la misma lista de entregables, sin que nadie pueda decir cuál de las dos se acepta formalmente.

La confusión entre entregable e hito es la más común en la práctica. Un gráfico de hitos traza fechas, no volumen de trabajo, y un hito con frecuencia marca cuándo se terminó o se aprobó un entregable. Pero el hito es el marcador, no la cosa en sí. "Página de inicio lanzada" puede ser un hito en un cronograma y referirse a un entregable que se aceptó ese mismo día. Están relacionados, pero no son lo mismo.

Tipos de entregables del proyecto

Una vez que ha confirmado que algo es realmente un entregable, todavía conviene clasificarlo. Cuatro ejes aparecen en casi todos los proyectos, y saber en qué cuadrante se ubica un entregable le dice quién lo revisa, con qué formalidad se acepta y cuánta visibilidad necesita fuera del equipo de entrega.

Entregables internos vs externos

Los entregables externos conllevan más riesgo si los criterios de aceptación son vagos, porque los desacuerdos pueden convertirse en disputas contractuales y no en fricción interna. Esa es en buena parte la razón por la que una declaración de trabajo suele enumerar los entregables externos de forma explícita, con los términos de aprobación adjuntos, mientras que los entregables internos a menudo se pueden aceptar con un mensaje de Slack y una casilla marcada.

De proceso, de producto, tangibles, intangibles, intermedios y finales

La mayoría de los entregables reales se ubican en la intersección de más de un eje. Un informe de pruebas UAT es un entregable de proceso, tangible y normalmente intermedio. Una app móvil lanzada es un entregable de producto, tangible y final. Nombrar el tipo desde el principio le ayuda a decidir, antes de que comience el trabajo, quién lo revisa y qué tan estricta debe ser esa revisión.

Del alcance al entregable aprobado: cómo se derivan los entregables

Los entregables no se inventan a mitad del proyecto. Se derivan a través de una cadena específica, y saltarse un eslabón de esa cadena es de donde provienen la mayoría de las conversaciones de "espere, ¿quién acordó esto?".

La declaración del alcance del proyecto es donde cada entregable se nombra por primera vez, como una frase nominal (una cosa), nunca como una actividad (un verbo). La estructura de desglose del trabajo toma entonces esos entregables nombrados y los descompone hasta que cada paquete de trabajo es lo bastante pequeño como para que un responsable lo estime y lo complete con confianza. En proyectos donde el alcance completo no se puede conocer de antemano, los equipos usan la planificación por olas sucesivas para mantener los entregables a corto plazo totalmente detallados y dejar los posteriores intencionalmente gruesos, refinándolos solo a medida que se acerca su ola. Cuando un paquete de trabajo se termina, debería corresponder claramente a un entregable nombrado en la declaración original del alcance. Si no es así, suele tratarse de una expansión del alcance o de un entregable que nadie planificó.

Ejemplos de entregables de proyecto por industria

Los nombres de los entregables cambian por completo según la industria, pero la forma subyacente, una cosa específica y aceptable, no. Así se ven los entregables reales en seis ámbitos comunes.

Observe el patrón en la columna de aprobador. Siempre se nombra a alguien específico, nunca "el equipo" ni "las partes interesadas". Un entregable sin un aprobador nombrado en realidad no se está gestionando como entregable, es solo trabajo en una lista esperando a que alguien note que ya está terminado. Asignar a ese responsable es justamente para lo que se diseñó un RACI: cada entregable necesita exactamente una persona responsable de lograr su aceptación, incluso cuando varias personas contribuyen a producirlo.

Cómo se acepta realmente un entregable

Aquí es donde la mayoría de los proyectos realmente fallan, no en la construcción, sino en la entrega. Un entregable "terminado" según el criterio del propio equipo y un entregable "aceptado" por quien posee la decisión son dos eventos distintos, y tratarlos como uno solo es como surgen las disputas.

Definition of Done vs criterios de aceptación formales

Una Definition of Done es el estándar de calidad propio del equipo: código revisado, probado, documentado, lo que sea que el equipo siempre exija antes de dar algo por terminado. Los criterios de aceptación son específicos de un entregable y pertenecen a la persona que tiene la autoridad para decir que sí. Un entregable puede cumplir por completo la Definition of Done del equipo y aun así fallar en la aceptación formal, porque el aprobador lo verifica contra un estándar distinto, específico del entregable. Ambas puertas deben superarse. Ninguna sustituye a la otra.

Quién aprueba realmente

La aceptación no es una corazonada, es una decisión tomada por una persona específica con la autoridad para tomarla. Para los entregables internos, suele ser un gerente o un revisor par. Para los entregables externos de cara al cliente, normalmente se nombra en la propia declaración de trabajo, junto con lo que sucede si el entregable es rechazado: una ventana definida para corregirlo, una fecha de nueva revisión y, a veces, un hito de pago vinculado a la firma. Los proyectos que omiten nombrar a un aprobador de antemano tienden a descubrir, en el peor momento posible, que tres personas distintas creen ser quien tiene la autoridad de aprobación, y ninguna está de acuerdo con las demás.

Documentar los entregables: el registro de entregables

Un registro de entregables (a veces llamado tracker o bitácora de entregables) es la única fuente de verdad de cada entregable de un proyecto: qué es, quién es su responsable, cuándo vence, qué significa "aceptado" y en qué estado se encuentra. Sin uno, el estado de los entregables vive en correos dispersos y en quien se acuerde de preguntar.

Mantenga el registro actualizado con la misma cadencia que su informe de estado del proyecto, para que el estado de los entregables nunca esté desactualizado cuando las partes interesadas pregunten por él. Cuando los criterios de aceptación viven en el registro y no en la bandeja de entrada de alguien, una entrega en disputa se convierte en una consulta de dos minutos en lugar de un concurso de memoria. Para los entregables vinculados a requisitos específicos de producto o contractuales, cruce el registro con una matriz de trazabilidad de requisitos de modo que cada requisito pueda rastrearse hasta el entregable que debe satisfacerlo, y cada entregable pueda rastrearse hasta el requisito que justificó construirlo.

Problemas comunes con los entregables

La mayoría de las disputas sobre entregables se remontan a un pequeño número de infractores reincidentes. Nombrarlos facilita detectarlos antes de que le cuesten a alguien una semana de retrabajo.

La expansión del alcance merece su propio recuadro aquí, porque rara vez llega como un nuevo entregable evidente. Casi siempre llega disfrazada de una pequeña adición a uno existente, un "campo extra rápido" en el formulario, una diapositiva más en la presentación, una página que nadie había incluido en el alcance. Cada una de esas adiciones cambia lo que el entregable realmente es, lo que significa que también cambia lo que debería significar "aceptado".

Entregables en entornos ágiles: incrementos y Definition of Done

Los equipos ágiles no suelen usar la palabra "entregable" en el día a día, pero el concepto no desaparece, se rebautiza y se entrega con mayor frecuencia. En Scrum, la unidad equivalente es el Increment: una pieza de producto que es utilizable y potencialmente lanzable en el momento en que cumple con la Definition of Done del equipo.

La Scrum Guide es explícita en que este estándar no es opcional: "El trabajo no puede considerarse parte de un Increment a menos que cumpla con la Definition of Done", y una vez que lo cumple, "en el momento en que un elemento del Product Backlog cumple con la Definition of Done, nace un Increment". Esa es una versión más estricta y continua de la misma lógica de entrega que rige a un entregable tradicional. La diferencia no está en si ocurre la aceptación, sino en con qué frecuencia y en quién la verifica. Un proyecto predictivo puede aceptar formalmente cinco entregables a lo largo de un año. Un equipo Scrum plantea la misma pregunta de aceptación en cada sprint, a veces todos los días, solo que a una escala mucho menor cada vez.

Mejores prácticas

• Nombre los entregables como cosas, nunca como actividades. Si el nombre comienza con un verbo, pertenece a la EDT o a la lista de tareas, no a la lista de entregables.
• Redacte los criterios de aceptación antes de que comience el trabajo, no después. Los criterios escritos retroactivamente describen lo que se construyó, no lo que realmente se necesitaba.
• Asigne exactamente un responsable por entregable. La responsabilidad compartida es como los entregables se estancan en silencio sin que nadie se sienta personalmente responsable.
• Separe explícitamente "terminado" de "aceptado". El estándar de calidad propio del equipo y la aprobación formal de una parte interesada son dos verificaciones distintas, y ambas deben superarse.
• Mantenga un registro de entregables vivo, no la memoria. El estado, el responsable, la fecha límite y los criterios de aceptación deben vivir en un solo lugar que todos puedan consultar.
• Trate cada "pequeña adición" como una cuestión de alcance. La forma más rápida en que la expansión del alcance entra en un proyecto es mediante cambios a un entregable existente que nunca pasan por el control de cambios.
• Ajuste la formalidad de la aceptación al tipo de entregable. Un entregable final de cara al cliente merece una revisión más estricta que un borrador intermedio interno; reserve el proceso más pesado para donde está realmente el riesgo.
• Rastree los entregables hacia los requisitos, no solo hacia adelante hacia las tareas. Una matriz de trazabilidad de requisitos detecta los entregables que existen sin motivo documentado y los requisitos para los que nadie construyó nunca un entregable.

Un entregable es la palabra de un plan de proyecto que nunca debería ser ambigua, porque es aquello para cuya producción se paga a todos, y aquello que otra persona debe acordar que realmente está terminado. Nombre los entregables como cosas, redacte sus criterios de aceptación antes de que alguien empiece a construir y asigne a cada uno exactamente un responsable y un aprobador. Si lo logra, la mayoría de las conversaciones de "¿esto realmente está terminado?" que consumen las últimas semanas de un proyecto simplemente dejan de ocurrir.