¶ Sobre este marco
Para qué sirve y qué encontrarás en él
¶ 1.1 ¿Para qué sirve este documento?
Este marco entrega una base común para gestionar proyectos de Gobierno Digital. Su propósito es ayudar a las instituciones a ordenar la gestión de sus proyectos, hacer visible su avance y facilitar la toma de decisiones, dejando a cada equipo la elección de su metodología y de su forma de trabajo.
El marco establece un piso mínimo de gestión que debe estar presente en todo proyecto: un vínculo con una prioridad institucional, propósito y resultados claros y medibles, responsabilidades definidas, patrocinio, capacidad de decisión, información para el seguimiento y mecanismos para gestionar riesgos y cambios.
Sobre ese piso común, cada equipo puede organizar su trabajo de acuerdo con las características de su proyecto, utilizando un enfoque predictivo, adaptativo, híbrido u otras prácticas que resulten apropiadas.
¶ 1.2 ¿Qué encontrarás en este documento?
¶ El marco
Un piso común de gestión, distintas formas de trabajo
¶ 2.1 Qué es un proyecto de Gobierno Digital
Los proyectos de Gobierno Digital pueden ser muy distintos entre sí. Algunos desarrollan o evolucionan productos digitales; otros implementan plataformas, integraciones, infraestructura, datos o cambios en servicios y procesos. Algunos parten con un resultado muy definido y permiten anticipar con precisión qué habrá que hacer; otros comienzan con una necesidad clara, pero requieren probar alternativas y ajustar la solución a medida que avanzan.
Lo que todos tienen en común es su razón de existir: un proyecto de Gobierno Digital existe para que algo mejore para alguien. Una persona que hace un trámite, una empresa que cumple una obligación, un funcionario que atiende público, una institución que necesita información para decidir. Ese es el valor público que justifica el proyecto, y nombrarlo desde el comienzo es la manera más simple de no perder el propósito por el camino.
¶ 2.2 Qué propone este marco
Por esa razón, este marco no establece una única manera de trabajar. Establece una base común de gestión: independiente de cómo se organice el trabajo, debe ser posible saber por qué existe el proyecto, a quién beneficia, a qué prioridad institucional responde, qué busca conseguir, quién responde por él, cómo se decidió abordarlo, cómo está avanzando y cuál fue finalmente su resultado.
En simple: no buscamos que todos los proyectos trabajen de la misma manera; buscamos que todos estén bien gestionados.
¶ 2.3 Un proyecto necesita más que una metodología
Ningún enfoque de trabajo, por sí solo, asegura una buena gestión. Para que un proyecto pueda avanzar y tomar decisiones oportunamente, necesita un propósito claro, responsables definidos, patrocinio institucional, capacidad para resolver bloqueos, información sobre su avance y mecanismos para gestionar riesgos y cambios.
Ese es el piso común que establece este marco. Sobre esa base, cada equipo puede organizar y ejecutar el trabajo de la manera que mejor se ajuste a las características de su proyecto.
¶ 2.4 El marco responde tres preguntas
La forma de trabajo se adapta: predictiva, adaptativa o híbrida, según las características de cada proyecto. El marco no cambia. Ese es todo el modelo: de una necesidad a un resultado, con un piso mínimo de gestión que lo sostiene.
¶ 2.5 El marco en una página
¶ 2.6 Un ciclo común, distintas formas de trabajo
El ciclo común tiene cuatro fases: inicio, planificación, ejecución y cierre, y una función que las cruza todas: el monitoreo. No es una secuencia rígida —y no debe confundirse con el modelo en cascada—: el proyecto comienza y termina formalmente, pero entre ambos puntos la planificación y la ejecución se ajustan cuantas veces aparezca nueva información, y el monitoreo acompaña el ciclo completo.
Quiénes participan tampoco depende del enfoque. En todo proyecto hay alguien que lo patrocina y autoriza, alguien que lo conduce, un equipo que lo ejecuta, personas y áreas afectadas por su resultado, y una mirada institucional sobre el portafolio. Esas responsabilidades se describen más abajo, en Quién hace qué.
¶ 2.7 Qué debe quedar registrado
A lo largo de la fase previa y de las cuatro fases el marco pide un número reducido de registros. Vale la pena explicar por qué existen, porque de esa comprensión depende que no terminen convertidos en trámite.
Hay cuatro cosas que suelen mezclarse y que conviene distinguir. La primera es la obligación: aquello que todo proyecto debe cumplir, como iniciar formalmente o dejar constancia de su cierre. La segunda es la información: los datos que deben quedar registrados para poder gestionar el proyecto. La tercera es el instrumento: el documento concreto donde esa información queda escrita. Y la cuarta es la herramienta: el sistema donde ese registro vive.
Las dos primeras son comunes a todos los proyectos, porque de ellas depende que la institución pueda gestionar su portafolio. Las dos últimas pueden variar según el enfoque de trabajo, el tamaño del proyecto y las herramientas de que disponga cada organismo.
La información se define; el instrumento y la herramienta pueden variar.
Cuando esa distinción no está clara aparece el problema de siempre: la misma información termina repetida en un acta, una planilla, un informe mensual y una presentación, y mantenerla al día se vuelve más costoso que el trabajo mismo. El marco define qué información mínima debe existir; lo razonable es que las herramientas institucionales permitan registrarla una sola vez.
Cada fase, de la sección 3 a la 7, cierra con un apartado que dice qué debe quedar registrado en ese momento, cuál es el instrumento y un formato de referencia para él.
Los formatos de referencia de cada fase son eso: una referencia, no un mínimo exigible. Contienen la información que el marco pide, cada una cabe en una página, y se pueden copiar a un documento, a una planilla o a la herramienta institucional. Una institución pequeña puede usar menos campos; lo importante es que las respuestas existan y estén al día, no el formato. Donde una respuesta no aplique, se escribe "no aplica" y por qué: una casilla vacía no dice nada, una casilla explicada sí.
Todos los proyectos de Gobierno Digital comparten un piso mínimo de gestión. La forma de organizar y ejecutar el trabajo se adapta a cada proyecto.
¶ Antes del proyecto: de la necesidad al proyecto
Decidimos si esta necesidad se convierte en un proyecto, y por qué ahora
Las instituciones siempre tienen más necesidades e ideas que capacidad para abordarlas. No todas deben convertirse en proyecto: algunas se resuelven en la operación habitual de un área, otras no responden a ninguna prioridad institucional y otras son buenas ideas cuyo momento no ha llegado.
Este paso ocurre antes de que exista el proyecto. Todavía no hay acta de inicio, jefatura ni equipo: hay una necesidad, y alguien debe decidir si vale la pena convertirla en proyecto.
¶ 3.1 Tres preguntas
La decisión responde tres preguntas:
¶ 3.2 Quién decide
La decisión corresponde al jefe de portafolio, en una instancia de gobernanza en la que participan el directivo máximo de la institución, la jefatura de tecnología, la jefatura de administración y las jefaturas de los procesos de negocio a los que la necesidad afecta. En esa misma instancia se define quién será el patrocinador del proyecto: la contraparte que lo respaldará y responderá por él desde el inicio. Esta es, en la práctica, la fase cero del proyecto, y conviene tratarla con cuidado: lo que se decide aquí condiciona todo lo que sigue.
El resultado puede ser que la necesidad entre al portafolio y pase a Inicio, que se postergue con fecha de revisión, que se resuelva como mejora operativa o que se descarte. En los cuatro casos queda constancia. Decir que no, o todavía no, también es gestionar el portafolio.
¶ 3.3 Qué queda registrado: el registro del portafolio
Necesidad, prioridad institucional a la que responde y decisión de portafolio: entra, se posterga, se resuelve como mejora operativa o se descarta. Instrumento: registro del portafolio (puede ser una planilla). Formato de referencia:
| Campo | Qué se escribe |
|---|---|
| Necesidad | Qué ocurre hoy y a quién le ocurre, en dos o tres líneas. |
| Prioridad institucional a la que responde | Plan, compromiso, obligación legal o normativa, programa de mejoramiento o convenio ADP. Nombrar cuál. |
| Decisión | Entra al portafolio, se posterga, se resuelve como mejora operativa o se descarta, y por qué. |
| Fecha de revisión | Solo si se posterga. |
| Patrocinador designado | Quién respaldará el proyecto si entra. |
| Fecha y quién decidió | Jefe de portafolio e instancia de gobernanza. |
La información es exigible; el formato es de referencia. Cada institución puede adaptar los campos a su tamaño y a su realidad. Descargar la plantilla en Word.
¶ 3.4 Quién hace qué en esta fase
| Tarea | Patrocinador | Jefatura de proyecto | Especialista técnico | Partes interesadas | Jefe de portafolio | Oficina de gestión de proyectos |
|---|---|---|---|---|---|---|
| Identificar y formular la necesidad y su valor público | R | — | — | C | A | C |
| Verificar el vínculo con una prioridad institucional | C | — | — | I | A | R |
| Evaluar si corresponde tratarla como proyecto y si vale la pena ahora | C | — | — | C | A | R |
| Decidir entrada, postergación, mejora operativa o descarte, y dejar constancia | C | — | — | I | A | R |
Antes del proyecto todavía no hay jefatura de proyecto ni especialistas técnicos. El patrocinador es quien plantea la necesidad; el jefe de portafolio decide.
R ejecuta · A aprueba · C es consultado · I es informado. Cómo leer estas matrices: sección 8.4.
La necesidad. Un servicio público entrega cada año cerca de 40 mil copias de un certificado que personas y empresas necesitan para postular a beneficios y licitaciones. Se pide presencialmente y la respuesta demora 12 días hábiles; las pymes reclaman que pierden plazos.
La decisión. Es un proyecto: exige rediseñar el servicio, integrar sistemas y coordinar tres áreas. Responde a la Ley 21.180 y al plan estratégico institucional. Vale la pena ahora: el volumen es alto, el reclamo está documentado y la ley fija plazo. Entra al portafolio y se posterga la renovación del sitio web, que usaba el mismo equipo.
¶ Inicio
Acordamos qué proyecto de Gobierno Digital vamos a realizar
Una vez que la institución decidió que la necesidad se convierte en proyecto, comienza el inicio propiamente tal. Antes de organizar tareas, construir un cronograma o decidir cómo trabajará el equipo, necesitamos ponernos de acuerdo sobre qué proyecto estamos iniciando, para quién y para qué.
¶ 4.1 A quién beneficia
Lo primero es nombrar a quién beneficia: la persona, empresa, funcionario o institución para la cual algo va a mejorar, y qué es lo que mejora. Parece obvio, pero muchas actas describen el sistema que se va a construir y nunca dicen para quién.
El producto es lo que entregamos: la plataforma, el sistema, la integración, el nuevo proceso.
El resultado es lo que cambia para las personas, las empresas o las instituciones gracias a ese producto. Es el resultado lo que el proyecto compromete; el producto es el medio.
¶ 4.2 Un resultado medible
En esta etapa se define ese resultado y cómo reconoceremos que fue alcanzado. La forma más simple de comprobar que un resultado está bien escrito es que se pueda medir:
Esa fórmula es lo que en gestión de proyectos se conoce como un objetivo SMART: específico, medible, alcanzable, relevante y acotado en el tiempo. El ejemplo bueno cumple los cinco. Un equipo que trabaja con OKR puede expresar lo mismo como un objetivo y sus resultados clave: el objetivo dice qué cambia y para quién; los resultados clave ponen la cifra, la línea base y el plazo. El acta de inicio acepta cualquiera de las dos formas; lo que no acepta es un resultado que no se pueda medir.
No siempre existe una cifra de partida. Cuando no la hay, medirla es una de las primeras tareas del proyecto; lo que no debe ocurrir es comprometer un resultado que nadie podrá comprobar. El resultado medible es también la referencia que usa el seguimiento para decir si vamos bien.
¶ 4.3 Criterio de éxito
El criterio de éxito son las condiciones bajo las cuales el proyecto se da por logrado. La principal es el resultado medible comprometido: se cumplió o no se cumplió. Pueden sumarse otras condiciones que también importan a la institución, como terminar dentro del plazo y del presupuesto, alcanzar un nivel de adopción o la satisfacción de quienes usan el servicio. Lo que no puede ocurrir es que el proyecto termine y nadie sepa si fue exitoso. El criterio se escribe en el acta de inicio y se evalúa, tal cual, en el acta de cierre.
¶ 4.4 Alcance, responsables y enfoque
También se establece un primer límite para el proyecto: qué esperamos abordar, qué queda fuera por ahora y qué restricciones importantes debemos considerar, como presupuesto, plazos, normativa o compromisos con terceros.
No se espera que en este momento tengamos todas las respuestas. El detalle de cómo se realizará el trabajo corresponde a la planificación y podrá evolucionar posteriormente. Lo importante es contar con un punto de partida suficientemente claro para que quienes participan compartan el mismo entendimiento del proyecto.
También debe quedar claro quién conducirá el proyecto y quién tiene la autoridad para respaldarlo y tomar las decisiones que excedan al equipo. Y se propone, de manera preliminar, el enfoque de trabajo: la planificación lo fundamentará y concretará.
¶ 4.5 El acta de inicio
Todo esto queda registrado en el Acta de Inicio (en inglés, project charter), junto con la prioridad institucional a la que responde el proyecto, que viene del paso anterior. Su propósito no es agregar documentación al proyecto, sino dejar constancia del acuerdo inicial: qué estamos autorizando, para quién, qué esperamos conseguir y quiénes asumirán la responsabilidad de llevarlo adelante. En 4.6 hay un formato de referencia del acta.
Hay un caso en que el inicio tiene además una exigencia externa. Cuando el proyecto requiere financiamiento por sobre el monto mínimo que fija anualmente la Dirección de Presupuestos, debe presentarse el año anterior al proceso EVALTIC. Esa exigencia no depende de cómo el equipo vaya a trabajar: aplica a cualquier proyecto que solicite ese financiamiento. Los criterios están en la guía técnica de EVALTIC.
¶ 4.6 Qué queda registrado: el acta de inicio (project charter), o el pitch
Necesidad o problema, prioridad institucional, a quién beneficia, resultado esperado y medible, alcance inicial, responsable, restricciones y criterio de éxito. Instrumento: acta de inicio. Formato de referencia:
¶ Acta de inicio (project charter)
| Campo | Qué se escribe |
|---|---|
| Nombre del proyecto | Corto y reconocible. Es el nombre que verá el portafolio. |
| Necesidad o problema | Qué ocurre hoy y a quién le ocurre, en dos o tres líneas. Con una cifra si existe. |
| Prioridad institucional a la que responde | Plan estratégico institucional, compromiso de gobierno, obligación legal o normativa (Ley 21.180, Sistema de Transformación Digital del Estado), programa de mejoramiento de la gestión, convenio de desempeño de Alta Dirección Pública o problema documentado. Nombrar cuál. |
| A quién beneficia y qué mejora | La persona, empresa, funcionario o institución para la que algo cambia, y qué cambia. |
| Resultado comprometido | Qué cambia, para quién, cuánto, desde dónde y para cuándo. Es el criterio de éxito que se evaluará en el cierre. |
| Alcance inicial | Qué incluye y, con la misma claridad, qué queda fuera por ahora. |
| Restricciones | Plazo, presupuesto, normativa, dependencias de terceros. |
| Patrocinador | Quién autoriza, aprueba los cambios al compromiso y decide el cierre. |
| Jefatura del proyecto | Quién lo conduce y responde por el resultado. |
| Participantes y partes interesadas | Áreas, equipos y organismos que participan o son afectados. |
| Enfoque de trabajo propuesto | Predictivo, adaptativo o híbrido, con una línea que diga por qué. La planificación lo confirmará. |
| Fecha y firmas | Patrocinador y jefatura del proyecto. |
La información es exigible; el formato es de referencia. Cada institución puede adaptar los campos a su tamaño y a su realidad. Descargar la plantilla en Word.
Cuando el equipo trabaja con Shape Up
La información es exigible; el formato es de referencia. Cada institución puede adaptar los campos a su tamaño y a su realidad. Descargar la plantilla en Word.
, el acta de inicio puede reemplazarse por un pitch. Es un documento más breve: delimita el problema, propone una solución conceptual y fija el tiempo que la institución está dispuesta a invertir, dejando el detalle de la implementación al equipo durante el ciclo. El marco no cambia: debe seguir siendo posible saber a qué prioridad institucional responde el proyecto, quién lo patrocina y qué resultado compromete.¶ Pitch (Shape Up) · alternativa al acta de inicio
| Sección | Qué se escribe |
|---|---|
| El problema | Qué ocurre hoy, por qué es un problema y a quién afecta directamente: ciudadanía, funcionarios o instituciones. |
| El apetito | El tiempo y el esfuerzo que la institución está dispuesta a invertir, por ejemplo dos o seis semanas. El tiempo es fijo y el alcance se ajusta a él. |
| La solución | La idea central que resuelve el problema, a grandes rasgos. Se acompaña de bocetos de trazo grueso, sin diseño final ni arquitectura definitiva. |
| Madrigueras de conejo | Riesgos técnicos, dependencias o zonas pantanosas que pueden estancar al equipo o consumir el apetito, y cómo abordarlas. |
| Fuera de alcance | Lo que explícitamente no se construirá en este ciclo, para evitar el crecimiento descontrolado del alcance. |
| La apuesta | Qué se resolvió: se apuesta por la iniciativa, se devuelve para ajustar o queda para un ciclo posterior. Quién la patrocina y qué equipo la toma. |
La información es exigible; el formato es de referencia. Cada institución puede adaptar los campos a su tamaño y a su realidad. Descargar la plantilla en Word.
¶ 4.7 Quién hace qué en esta fase
| Tarea | Patrocinador | Jefatura de proyecto | Especialista técnico | Partes interesadas | Jefe de portafolio | Oficina de gestión de proyectos |
|---|---|---|---|---|---|---|
| Definir a quién beneficia y el resultado medible (criterio de éxito) | A | R | C | C | I | C |
| Delimitar el alcance inicial y las restricciones | A | R | C | C | I | C |
| Designar la jefatura del proyecto y confirmar el patrocinio | A | I | I | I | C | R |
| Proponer y justificar el enfoque de trabajo | A | R | C | I | I | C |
| Suscribir el acta de inicio | A | R | I | I | I | C |
R ejecuta · A aprueba · C es consultado · I es informado. Cómo leer estas matrices: sección 8.4.
A quién beneficia. Personas y pymes que necesitan el certificado; también el equipo de atención presencial, que hoy dedica la mitad de su jornada a este trámite.
Resultado comprometido. Al 31 de diciembre de 2027, el 80% de las solicitudes se hacen en línea y se responden en 2 días hábiles o menos. Hoy: 0% en línea, 12 días.
Alcance inicial. Incluye solicitud, pago y entrega en línea con ClaveÚnica. Excluye la digitalización de solicitudes históricas y cualquier cambio al reglamento del certificado.
Responsables. Patrocina la jefatura de la división de atención; conduce la coordinadora de servicios digitales. Restricción principal: el plazo que fija la ley. Enfoque propuesto: híbrido.
¶ Planificación
Definimos cómo abordaremos el proyecto — y cómo organizaremos el trabajo
Una vez que existe un acuerdo sobre el propósito del proyecto, necesitamos decidir cómo vamos a abordarlo. Planificar significa transformar ese acuerdo inicial en una forma concreta de organizar el trabajo.
¶ 5.1 Qué, quién y cuándo
Cualquiera sea su forma, una planificación responde tres preguntas: qué vamos a hacer, quién responde por cada parte y cuándo esperamos tenerla. Una carta Gantt, un backlog priorizado o un roadmap por ciclos son maneras distintas de responder lo mismo. Si alguna de las tres preguntas no tiene respuesta, todavía no hay planificación: hay una lista de intenciones.
¶ 5.2 Aquí se fundamenta y concreta el enfoque
La regla es simple: en el inicio se propone un enfoque preliminar; en la planificación se fundamenta y concreta. Elegir un enfoque no es una declaración de identidad: es una decisión sobre cuánto sabemos al comenzar, cuánto podemos comprometer de antemano y cuánto necesitamos aprender por el camino. Cuando el trabajo se puede anticipar conviene un enfoque predictivo; cuando hay que aprender mientras se avanza, uno adaptativo; cuando se necesitan ambas cosas, uno híbrido. Los criterios para decidirlo se detallan a continuación.
El enfoque puede cambiar durante la ejecución si el diagnóstico inicial resultó equivocado, y ese cambio no altera las obligaciones del marco: las cuatro fases, el monitoreo, sus registros y el mecanismo de seguimiento siguen siendo los mismos.
¶ 5.3 Cómo elegir la forma de trabajo
El marco no impone una forma de trabajo. Lo que pide es que la elección sea consciente y quede fundamentada en la planificación. Tres situaciones cubren la mayoría de los casos.
Cuando podemos anticipar buena parte del trabajo
Si el resultado y la forma de alcanzarlo están razonablemente claros, puede ser conveniente planificar con mayor detalle desde el comienzo, definiendo alcance, actividades, responsables, hitos, plazos y costos. Un enfoque predictivo —cuya forma más conocida es el modelo en cascada— suele responder bien a esta situación.
Cuando necesitamos aprender mientras avanzamos
Si conocemos la necesidad o el resultado que buscamos, pero todavía existe incertidumbre respecto de la solución, puede ser conveniente trabajar en períodos más cortos, entregar progresivamente y ajustar a partir de lo aprendido. Un enfoque adaptativo —los enfoques y prácticas ágiles— suele responder mejor a esta situación. Puede apoyarse en Scrum, Kanban, Shape Up u otras prácticas.
Cuando necesitamos ambas cosas
Muchos proyectos de Gobierno Digital tienen compromisos externos de plazo, presupuesto o alcance y, al mismo tiempo, necesitan iterar para desarrollar la solución. En esos casos, un enfoque híbrido permite combinar planificación anticipada con espacios de adaptación.
Cómo elegir
| Cuando predomina… | Puede convenir… | Porque… |
|---|---|---|
| Resultado y camino relativamente conocidos; compromisos definidos de alcance, plazo o presupuesto | Predictivo | Permite anticipar el trabajo y controlar el avance respecto de lo planificado. |
| Incertidumbre sobre la solución; necesidad de probar, aprender o incorporar retroalimentación | Adaptativo | Permite avanzar progresivamente y ajustar el trabajo según lo aprendido. |
| Compromisos externos definidos, pero incertidumbre relevante en parte de la solución | Híbrido | Permite mantener compromisos generales y adaptar la ejecución donde sea necesario. |
Ante la duda, conviene elegir el enfoque que mejor tolere estar equivocado y revisarlo más adelante. Cambiar de enfoque durante la ejecución es legítimo si el diagnóstico inicial resultó equivocado, y no altera las obligaciones del marco.
Si mañana cambian las prácticas que usamos o aparecen otras nuevas, el marco no cambia: está deliberadamente por encima de las metodologías específicas.
¶ 5.4 Lo que la planificación debe permitir comprender
Este marco no exige una carta Gantt, un backlog o un formato determinado. Lo que exige es que, cualquiera sea el enfoque, la planificación responda las preguntas básicas de gestión. La forma de expresar cada respuesta puede variar:
| Todo proyecto debe poder responder… | La respuesta puede expresarse mediante… |
|---|---|
| ¿Qué queremos conseguir? | Resultado, objetivo, outcome u otra definición equivalente |
| ¿Qué vamos a abordar? | Alcance, entregables, backlog, prioridades u otra forma de organizar el trabajo |
| ¿Cuáles son nuestros límites? | Plazo, presupuesto, capacidad, restricciones o límites definidos por el equipo |
| ¿Cómo sabremos que avanzamos? | Hitos, entregas, incrementos, resultados parciales u otras referencias |
| ¿Qué puede impedir el avance? | Riesgos, bloqueos, impedimentos u otras alertas |
| ¿Quién responde por qué? | Roles y responsabilidades definidos |
Entre esas preguntas, la de los riesgos merece una mención aparte. Identificarlos y hacerse cargo de ellos es parte de gestionar bien cualquier proyecto, y la gestión de riesgos del proyecto se articula con las orientaciones del Documento Técnico N° 70 del Consejo de Auditoría Interna General de Gobierno. Entre un enfoque y otro cambia el vocabulario —riesgos, impedimentos, obstáculos—, no la necesidad de gestionarlos.
Además, la planificación no termina cuando comienza la ejecución. A medida que el proyecto avanza aparecen problemas, información y aprendizajes que no estaban disponibles al comienzo. El equipo puede utilizar esa información para ajustar la manera de trabajar, sin necesidad de tratar cada ajuste como un cambio formal del proyecto.
Solo cuando lo que cambia afecta aquello que efectivamente fue comprometido —por ejemplo, el resultado esperado, un límite relevante de alcance, el presupuesto o un plazo comprometido con terceros— corresponde registrar y aprobar el cambio.
¶ 5.5 Qué queda registrado: la planificación y el registro de riesgos
Qué se busca, qué se abordará, límites, organización del trabajo, referencias de avance y riesgos. Instrumento: plan de gestión, roadmap, backlog, pitch u otro; el marco no fija su formato. Riesgos identificados, su tratamiento y su responsable. Instrumento: registro de riesgos, que se abre aquí y se mantiene durante todo el proyecto. Formato de referencia:
¶ Registro de riesgos (risk register)
| Campo | Qué se escribe |
|---|---|
| Riesgo | Qué podría ocurrir y qué efecto tendría sobre el resultado, el plazo o el presupuesto. |
| Probabilidad e impacto | Alta, media o baja en cada uno. Basta para ordenar cuáles atender primero. |
| Tratamiento | Qué haremos para evitarlo, reducirlo o prepararnos si ocurre. |
| Responsable | Una persona, no un área. |
| Estado | Abierto, en tratamiento, ocurrió o cerrado. Con fecha de la última revisión. |
La información es exigible; el formato es de referencia. Cada institución puede adaptar los campos a su tamaño y a su realidad. Descargar la plantilla en Word.
Instrumentos de apoyo, no exigibles. Para organizar el trabajo de esta fase, el marco publica además cuatro formatos que ninguna institución está obligada a usar: la estructura de desglose del trabajo, que divide el proyecto en entregables; el cronograma, que los ordena en el tiempo con responsable y dependencias; el registro de partes interesadas, que identifica a quienes afectan o son afectados por el proyecto; y el plan de comunicaciones, que define qué se informa, a quién y con qué frecuencia. Un proyecto pequeño puede no usar ninguno.
¶ 5.6 Quién hace qué en esta fase
| Tarea | Patrocinador | Jefatura de proyecto | Especialista técnico | Partes interesadas | Jefe de portafolio | Oficina de gestión de proyectos |
|---|---|---|---|---|---|---|
| Registrar la planificación del proyecto | A | R | C | I | I | C |
| Definir el alcance comprometido | A | R | C | C | I | C |
| Organizar el trabajo según el enfoque elegido | I | A | R | I | I | C |
| Definir hitos o referencias de avance | A | R | C | I | C | C |
| Identificar y evaluar riesgos | A | R | C | C | I | C |
| Estimar y planificar costos | A | R | C | I | C | C |
R ejecuta · A aprueba · C es consultado · I es informado. Cómo leer estas matrices: sección 8.4.
Enfoque. Híbrido: el plazo legal y la integración con el sistema de pagos se planifican con hitos fijos; el diseño del servicio en línea se trabaja en ciclos cortos con pruebas de usuarios.
Referencias de avance. Prototipo validado con usuarios (mes 3), integración con pagos (mes 6), piloto en dos regiones (mes 8), despliegue nacional (mes 10).
Riesgo principal. La integración con pagos depende de un convenio con otra institución. Tratamiento: iniciar la gestión del convenio en el mes 1 y no en el 5. Responsable: la jefatura del proyecto, con apoyo del patrocinador.
¶ Ejecución
Avanzamos, y el monitoreo, que acompaña las cuatro fases, nos dice dónde estamos
Durante la ejecución ocurre el trabajo propiamente tal. El equipo desarrolla los productos, resuelve problemas, coordina dependencias y toma las decisiones necesarias para avanzar. La forma en que lo hace es la que se definió en la planificación, y no necesita ser igual entre proyectos.
Pero ejecutar no basta. El monitoreo —que es transversal y acompaña todo el ciclo, desde el inicio hasta el cierre— es lo que permite saber si el proyecto avanza como esperamos y si existe algo que requiera atención. Es durante la ejecución cuando más se ejercita, y por eso lo describimos aquí.
El monitoreo busca entregar esa visibilidad sin reproducir toda la gestión interna del equipo. No necesitamos conocer cada tarea realizada ni convertir el seguimiento en un reporte de actividades. Necesitamos información suficiente para comprender la situación del proyecto y actuar cuando sea necesario.
¶ 6.1 Cinco preguntas de seguimiento
Por eso el seguimiento se concentra en cinco preguntas sencillas: cómo estamos respecto de lo comprometido, qué avanzó desde la última actualización, cuál es el próximo resultado o hito, qué riesgo o bloqueo puede impedirnos avanzar, y si hay alguna decisión que el equipo necesite escalar. "Lo comprometido" es el resultado medible del acta de inicio: cada vez que sea posible, el avance se informa en esa misma medida, y no como una lista de actividades realizadas.
¶ 6.2 El equipo conserva su instrumento
El marco no exige reemplazar los instrumentos de trabajo del equipo: el seguimiento toma de ellos la información necesaria para responder estas preguntas.
El equipo conserva su instrumento de trabajo; la institución conserva una sola vista de su portafolio. Ninguna de las dos cosas obliga a la otra a cambiar.
Conviene decirlo con claridad, porque afecta la manera en que se reporta: un proyecto que informa un problema a tiempo no está necesariamente mal gestionado. Al contrario, hacer visible una dificultad permite tomar decisiones antes de que se transforme en un problema mayor.
¶ 6.3 Qué queda registrado: el reporte de seguimiento y el registro de cambios
Estado general, avance, próximo hito, riesgos y bloqueos, decisiones necesarias. Instrumento: reporte de seguimiento, con la periodicidad que defina la institución. Cambios que afectan el resultado, los límites, el presupuesto o el plazo comprometido. Instrumento: registro de decisiones y cambios. Formatos de referencia:
¶ Reporte de seguimiento (status report)
| Campo | Qué se escribe |
|---|---|
| Proyecto y fecha | Nombre del proyecto y fecha del reporte. |
| Estado general | En línea, requiere atención o crítico, siempre respecto del resultado y los límites comprometidos. |
| Avance desde el último reporte | Qué ocurrió realmente, en la medida del resultado cuando sea posible. Resultados, no actividades. |
| Próximo resultado o hito | Qué debería ocurrir después y en qué fecha. |
| Riesgos y bloqueos | Qué amenaza o impide avanzar, y qué se está haciendo al respecto. |
| Decisiones necesarias | Qué debe resolver el patrocinador, la jefatura u otra área, y para cuándo se necesita. |
La información es exigible; el formato es de referencia. Cada institución puede adaptar los campos a su tamaño y a su realidad. Descargar la plantilla en Word.
¶ Registro de decisiones y cambios
| Campo | Qué se escribe |
|---|---|
| Qué cambia | Resultado, alcance, presupuesto o plazo comprometido, y en qué medida. |
| Por qué | La causa: nueva información, dependencia externa, decisión institucional. |
| Quién lo solicita | Jefatura del proyecto o patrocinador. |
| Decisión y quién aprueba | Aprobado, rechazado o postergado; el patrocinador aprueba los cambios a lo comprometido. |
| Fecha | Cuándo se decidió y desde cuándo rige. |
La información es exigible; el formato es de referencia. Cada institución puede adaptar los campos a su tamaño y a su realidad. Descargar la plantilla en Word.
Instrumento de apoyo, no exigible. Durante la ejecución la mayor parte de las decisiones se toma en reuniones. El acta de reunión deja constancia de lo acordado y, sobre todo, de los compromisos con responsable y fecha. No la exige el marco, pero evita que un acuerdo se pierda.
¶ 6.4 Quién hace qué en esta fase
| Tarea | Patrocinador | Jefatura de proyecto | Especialista técnico | Partes interesadas | Jefe de portafolio | Oficina de gestión de proyectos |
|---|---|---|---|---|---|---|
| Conducir el trabajo según el enfoque elegido | I | A | R | I | I | I |
| Realizar ajustes de ejecución dentro de los límites | I | A | R | I | I | I |
| Emitir el reporte de seguimiento | I | R | C | I | A | C |
| Monitorear riesgos y bloqueos | I | R | C | C | I | C |
| Resolver las decisiones escaladas | A | R | I | C | C | I |
| Autorizar cambios al compromiso | A | R | C | C | C | C |
| Consolidar la vista de portafolio | I | C | I | I | A | R |
R ejecuta · A aprueba · C es consultado · I es informado. Cómo leer estas matrices: sección 8.4.
Estado general. Requiere atención.
Avance. Piloto operando en dos regiones: 1.200 solicitudes en línea en un mes, respuesta promedio de 2,5 días. El resultado comprometido se ve alcanzable.
Próximo hito. Despliegue nacional, 15 de octubre.
Riesgos y bloqueos. El convenio de pagos lleva tres semanas de atraso en la firma de la otra institución. Sin convenio no hay despliegue nacional.
Decisión necesaria. Que el patrocinador gestione la firma con su contraparte esta semana; si no ocurre, el hito se mueve a noviembre y hay que informar el cambio de plazo.
¶ Cierre
Dejamos constancia del resultado
Los proyectos no terminan simplemente porque dejaron de tener tareas pendientes o porque el equipo comenzó a trabajar en otra cosa. Cerrar un proyecto significa detenerse y dejar constancia de qué ocurrió con aquello que nos propusimos hacer.
Para ello comparamos el resultado obtenido con lo que se acordó al inicio y durante la planificación. Registramos qué se consiguió, qué quedó pendiente y por qué, y qué productos o responsabilidades deben continuar en operación, en otra unidad o eventualmente en otro proyecto.
El cierre también permite recoger aprendizajes que puedan ser útiles más adelante. No se trata de reconstruir toda la historia del proyecto, sino de conservar aquello que vale la pena conocer para operar el resultado obtenido o gestionar mejor proyectos futuros.
¶ 7.1 Tres estados de cierre
No todos los proyectos terminan de la misma manera. Algunos alcanzan el resultado comprometido; otros generan valor, pero cierran con un resultado parcial; y en algunos casos la decisión correcta es no continuar. Cancelar un proyecto cuando ha dejado de ser viable, necesario o conveniente también es una decisión de gestión.
¶ 7.2 El acta de cierre
Lo importante es que el proyecto no simplemente desaparezca del portafolio. La decisión y su resultado deben quedar registrados mediante el Acta de Cierre (en inglés, closure report), incluyendo las transferencias que correspondan y los principales aprendizajes.
¶ 7.3 Qué queda registrado: el acta de cierre (closure report)
Comprometido, obtenido, pendiente, transferencia a operación y aprendizajes. Instrumento: acta de cierre, en cualquiera de los tres estados. Formato de referencia:
¶ Acta de cierre (closure report)
| Campo | Qué se escribe |
|---|---|
| Estado de cierre | Terminado, cierre parcial o cancelado, y la razón en una línea. |
| Lo comprometido | El resultado del acta de inicio, tal como quedó tras los cambios aprobados. |
| Lo obtenido | El resultado medido, en la misma unidad en que se comprometió. |
| Evaluación del criterio de éxito | Se cumplió, se cumplió en parte o no se cumplió, y por qué. |
| Lo pendiente y su destino | Qué quedó sin hacer y si pasa a operación, a otro proyecto o se deja de lado. |
| Transferencia a operación | Qué se entrega, a qué unidad y quién queda a cargo del soporte. |
| Aprendizajes | Dos o tres cosas que conviene saber para operar el resultado o para el próximo proyecto. |
| Fecha y firmas | Patrocinador y jefatura del proyecto. |
¶ 7.4 Quién hace qué en esta fase
| Tarea | Patrocinador | Jefatura de proyecto | Especialista técnico | Partes interesadas | Jefe de portafolio | Oficina de gestión de proyectos |
|---|---|---|---|---|---|---|
| Verificar lo obtenido contra lo comprometido | A | R | C | C | I | C |
| Registrar lo pendiente y su destino | A | R | C | C | I | C |
| Formalizar la transferencia a operación | A | R | C | C | I | I |
| Documentar lecciones aprendidas | I | R | C | C | I | A |
| Adoptar la decisión de cierre | A | R | I | I | C | C |
| Cerrar el registro en el portafolio institucional | I | C | I | I | A | R |
R ejecuta · A aprueba · C es consultado · I es informado. Cómo leer estas matrices: sección 8.4.
Comprometido. 80% de solicitudes en línea y respuesta en 2 días o menos al 31 de diciembre de 2027.
Obtenido. 68% en línea y respuesta en 3 días. La demora en el convenio corrió el despliegue nacional dos meses.
Estado de cierre. Cierre parcial: hay valor real para las personas, menor al comprometido. Lo pendiente —llegar al 80%— pasa a la unidad de atención como meta de operación, no como nuevo proyecto.
Transferencia. El servicio en línea queda en operación a cargo de la unidad de atención, con el equipo de sistemas como soporte.
Aprendizaje. Cuando el proyecto depende de un convenio con otra institución, la firma debe ser un hito propio y temprano, no un supuesto.
¶ Quién hace qué
Quién patrocina, conduce, ejecuta, prioriza y acompaña el proyecto
¶ 8.1 Quién es quién
En todo proyecto hay un conjunto de responsabilidades que alguien debe asumir, aunque se trate de un proyecto pequeño y una misma persona cumpla más de un rol. Lo que sigue no describe cargos ni estructuras: describe responsabilidades.
El patrocinador respalda el proyecto y lo financia. Es quien lo autoriza, quien aprueba los cambios que afectan lo comprometido y quien decide su cierre. La jefatura del proyecto lo conduce día a día y responde por el cumplimiento del resultado. El equipo ejecuta el trabajo y responde por la calidad de lo que entrega.
Alrededor de ellos están las partes interesadas —personas, áreas u organismos afectados por el proyecto o capaces de influir en él—, el jefe de portafolio, que decide qué necesidades se convierten en proyecto, prioriza las iniciativas de la institución y cuida su alineamiento estratégico, y la Oficina de gestión de proyectos (PMO), que sostiene el marco común, acompaña metodológicamente a los equipos y consolida la vista del portafolio.
| Rol | En una línea |
|---|---|
| Patrocinador | Respalda y financia. Autoriza el inicio, los cambios al compromiso y el cierre. |
| Jefatura del proyecto | Conduce el trabajo y responde por el cumplimiento del resultado comprometido. |
| Equipo del proyecto · especialistas técnicos | Ejecutan y responden por la calidad de sus entregables. |
| Partes interesadas | Afectan o son afectadas por el proyecto; aportan expectativas y validan resultados. |
| Jefe de portafolio | Decide qué necesidades entran como proyecto, prioriza el portafolio institucional y cuida el alineamiento estratégico. |
| Oficina de gestión de proyectos (PMO) | Sostiene el marco común, da soporte metodológico y consolida la vista del portafolio. |
Los nombres cambian de un enfoque a otro. La jefatura de proyecto puede llamarse product owner o shaper; el equipo puede organizarse por células o por especialidades. La responsabilidad, en cambio, permanece: alguien autoriza, alguien conduce, alguien ejecuta y alguien responde por el portafolio.
¶ 8.2 El patrocinio directivo importa
Entre los seis roles, el del patrocinador merece una mención aparte. Cuando la alta dirección se compromete con un proyecto —lo respalda, lo financia y resuelve lo que el equipo no puede resolver— la probabilidad de que el proyecto termine bien aumenta de manera significativa. Es la experiencia de la SGD y es también lo que muestra la evidencia disponible.
¶ 8.3 Gobernanza: quién decide qué
Eso es lo que este marco entiende por gobernanza: quién decide qué. No es una capa adicional que haya que aprender. Es tener claro, desde antes del inicio y hasta el cierre, quién autoriza, quién resuelve lo que el equipo no puede resolver y quién mira el portafolio completo.
Lo mismo vale para la información con que estos roles trabajan. El marco define qué información mínima debe existir —estado, responsable, próximo hito, riesgos y decisiones—, cualquiera sea la forma de trabajo del equipo; lo razonable es que las herramientas institucionales permitan registrarla una sola vez, para que quien conduce, quien patrocina y quien mira el portafolio lean lo mismo sin duplicar reportes.
¶ 8.4 Cómo leer las matrices RACI
Al final de cada fase, desde la sección 3 a la 7, hay una matriz que detalla tarea por tarea quién hace qué en ese momento del proyecto. Se leen con cuatro letras: R ejecuta la tarea, A la aprueba, C es consultado antes de decidir e I es informado del resultado.
Son una herramienta de apoyo, no una norma. Cada institución puede ajustar la asignación a su estructura interna; lo que no debería cambiar es que cada obligación tenga un responsable de ejecutarla y alguien que la apruebe.
¶ Cómo lo aplicamos en la SGD
El marco en operación: Asana, PMO y seguimiento de portafolio
En la Secretaría de Gobierno Digital utilizamos Asana como herramienta institucional para registrar y dar seguimiento a nuestro portafolio de proyectos. Asana no constituye el marco ni determina la forma en que cada equipo ejecuta su proyecto: es la herramienta que usamos para mantener la información común de gestión, facilitar el seguimiento y contar con una visión transversal del portafolio.
La distinción importa. La información mínima es obligatoria para todo proyecto; la herramienta donde se registra es una decisión de cada institución.
Sobre esa información opera la gobernanza. La Oficina de Gestión de Proyectos sostiene el estándar, apoya metodológicamente a los equipos y consolida la vista del portafolio; el jefe de portafolio prioriza qué entra y qué sale; y un informe semanal comunica a toda la institución el estado de los proyectos, sin reuniones adicionales. La información nace donde se trabaja y se agrega hacia donde se decide.
¶ Instrumentos y descargas
Todos los formatos del marco, en un solo lugar
Esta tabla reúne los instrumentos que el marco publica. La columna del medio distingue dos cosas distintas. Exigible quiere decir que la información debe existir en esa fase, no que haya que usar este formato: una planilla o la herramienta institucional sirven igual. Apoyo quiere decir que el instrumento ayuda a organizar el trabajo, pero ninguna institución está obligada a usarlo.
Todas las plantillas están en formato Word y se pueden descargar y adaptar libremente. Donde un campo no aplique, conviene escribir «no aplica» y por qué: una casilla vacía no dice nada, una casilla explicada sí.
| Instrumento | Fase | Tipo | Qué registra |
|---|---|---|---|
| Registro del portafolio | Antes del proyecto | Exigible | Deja constancia de si la necesidad entra, se posterga, se resuelve como mejora operativa o se descarta. |
| Acta de inicio | Inicio | Exigible | Autoriza el proyecto y fija a quién beneficia, el resultado comprometido, el alcance y los responsables. |
| Pitch (Shape Up) | Inicio | Alternativa | Reemplaza al acta de inicio cuando el equipo trabaja con Shape Up. Problema, apetito, solución y límites. |
| Plan de gestión del proyecto | Planificación | Exigible | Qué haremos, cómo avanzaremos, cómo trabajaremos y quién responde. El formato puede variar. |
| Registro de riesgos | Planificación · transversal | Exigible | Riesgo, probabilidad e impacto, tratamiento, responsable y estado. |
| Estructura de desglose del trabajo | Planificación | Apoyo | Divide el trabajo en entregables y subentregables, con responsable y estimación. |
| Cronograma del proyecto | Planificación | Apoyo | Ordena fases y actividades en el tiempo, con responsables y dependencias. |
| Registro de partes interesadas | Planificación | Apoyo | Quiénes afectan o son afectados, su interés e influencia y qué necesitan saber. |
| Plan de comunicaciones | Planificación | Apoyo | Qué se comunica, a quién, con qué frecuencia y por qué canal. |
| Informe de avance | Ejecución | Exigible | Las cinco preguntas del seguimiento: estado, avance, próximo hito, riesgos y decisiones. |
| Registro de decisiones y cambios | Ejecución | Exigible | Solo los cambios que afectan lo comprometido: resultado, alcance, presupuesto o plazo. |
| Acta de reunión | Ejecución | Apoyo | Acuerdos y compromisos con responsable y fecha. |
| Acta de cierre del proyecto | Cierre | Exigible | Lo comprometido frente a lo obtenido, pendientes, transferencia y aprendizajes. |
Los archivos están publicados en Drive con acceso de solo lectura: cualquier persona puede abrirlos y descargarlos sin solicitar permiso. Ver la carpeta completa.