10 Replies to “El Acta de Constitución de Proyecto”
Hola Toni, miuy util la información. Pero me surge una duda sobre el enfoque del documento. En todo momento das por sentado que tu eres el proveedor que ejecutará el proyecto. Esto quiere decir que yo, como unidad de sistemas de mi empresa y cliente ¿debo esperar/exigir este documento a mi proveedor? Por otro lado, ¿debo usar este documento para obtener la aprobación de mis clientes internos?
“Esto quiere decir que yo, como unidad de sistemas de mi empresa y cliente ¿debo esperar/exigir este documento a mi proveedor?”.
En mi opinión, claramente sí (salvo proyectos muy cortos o de muy bajo alcance). Demuestra buen hacer por parte del proveedor y, además, sirve para “asentar” los aspectos más importantes del proyecto nada más comenzar. El Acta de Constitución de Proyecto permitirá abordar los aspectos clave de una manera breve pero introductoria: qué se espera del proyecto (objetivos), quién participará, cuándo, cuáles son los principales requisitos, etc.
Es habitual que se barajen muchas opciones y alternativas durante la fase comercial, y esto suele dejar muchas cosas en el aire. Para evitar esa sensación y reducir incertidumbre, presentar los aspectos más importantes en una primera reunión, con un documento general, me ha servido de mucho.
Desde la perspectiva de cliente, te recomiendo que lo solicites por escrito, que estipule con detalle el alcance y el cronograma y, además, que recoja los riesgos principales. Este último apartado suele descuidarse mucho, y que lo requieras al comienzo del proyecto, ayudará a marcar bien el terreno.
“Por otro lado, ¿debo usar este documento para obtener la aprobación de mis clientes internos?”. Esto depende muchísimo de cómo es la organización donde trabajas (tu posición en su organigrama, la cultura de la empresa, tu nivel informal de autoridad, el número de trabajadores, etc.). Pero rara vez le he encontrado perjuicios, por lo que te diría que lo propondría siempre.
De cara a la dirección, se trata de un documento ideal para plasmar qué se espera del proyecto, qué recursos se necesita y cuándo deben esperar resultados. De cara a los compañeros implicados, es interesante para saber para qué no es este proyecto (muy importante de cara a evitar confusiones posteriores), para cuándo está previsto tenerlo y qué se espera de cada participante.
Una puntualización: de cara a hablar con clientes internos, yo no me centraría en el documento de Acta de Constitución en sí (los alérgicos a la burocracia te mostrarán resistencia, y los enamorados de la burocracia te pedirán que amplíes el documento ad infinitum). En su lugar, propón una reunión de “presentación interna de proyecto”, y el orden del día será en esencia el contenido del Acta. Conseguirás tu objetivo y no correrás el riesgo de que nadie se centre en exceso en la forma.
En cualquier caso, no tengas en mente un documento muy extenso. Es muy frecuente que con dos o tres páginas sea suficiente para recoger de forma breve todos los aspectos (además, hacerlo muy extenso sólo sirve para que menor cantidad de gente lo lea, y se confundiría este documento con el Plan de Proyecto).
En mi caso personal, suelo realizarlo con una presentación en PowerPoint (me obliga a esquematizar y estructurar, y es más agradable de revisar que un Word) y realizo una exposición en la primera reunión del proyecto (KickOff Meeting) con todos los interesados.
Por último, existe un texto que puede darte una visión muy interesante sobre esto en el libro “Agile Samurai” de J. Rasmusson, en el apartado “Project Inception”. Presenta una visión sobre cómo generar una visión adecuada y unificado en un equipo ágil. Tal vez te resulte interesante.
Estimado Tony, soy gerente de programa en mi organziación. Te comento que si bien el acta de constitución depende de un equipo, quién debería ser el responsable de tenerala a tiempo, ya que se entiende que la misma debería estar autorizada previo el inicio del proyecto?. A qué área debería pertenecer esta persona?.
Tu pregunta es muy interesante y, como en casi muchos otros aspectos de la gestión de proyectos, depende en gran medida de la cultura de la organización, así como del sector en el que se mueve la misma.
El Acta de Constitución, como tal, autoriza el inicio del proyecto al ser firmada, por lo tanto como bien dices es imprescindible disponer de ella antes de que comience el proyecto en sí.
Según el PMBOK, “los proyectos son autorizados por alguien externo al proyecto, tal como un patrocinador, una oficina de dirección de proyectos (PMO) o un comité ejecutivo[…]. Cualquiera de ellos elaborará el acta de constitución del proyecto o delegará esta tarea al director del proyecto“. Por lo tanto, en el caso que tú comentas, el acta de constitución podría ser preparado por ti mismo, por el patrocinador (quien financia el proyecto) o por el director de proyectos que asignes (como gerente de programa) para llevarlo a cabo.
En la práctica habitual de muchas empresas, sin embargo, es el propio director de proyectos el que redacta el Acta y la presenta al cliente o patrocinador para su aprobación. Pero esta no tiene por qué ser la única forma y mucho menos tampoco tiene que ser la “más correcta”.
En mi caso particular (lo menciono por aquello de dar ejemplos concretos, no para sentar cátedra), cuando soy el responsable de un proyecto, yo personalmente redacto el Acta de Constitución. Me permite, entre otras cosas, un trabajo de reflexión previo (al recopilar la documentación existente, obligarme a identificar bien a los interesados, considerar las restricciones del proyecto, leer las condiciones de la oferta o el contrato,…) que luego me resulta muy útil para la planificación. Además, redactar el documento y exponerlo me permite presentarme a los clientes como responsable, explicar mis atribuciones y obligaciones, repasar los documentos preliminares (contrato, oferta) y leer los detalles del acta con una mayor preparación y solidez.
En cambio, si fuera un gerente de programa, probablemente delegaría esta labor a cada director de proyecto que estuviera a mi cargo. Precisamente por los mismos motivos que comento en el párrafo anterior, pero también porque sería la mejor manera de involucrar a esa persona desde el “instante 0” del proyecto.
En tu comentario has destacado “tenerla a tiempo”. Permíteme dar una señal de aviso: si el problema no es elegir quien redacta el documento, sino que quien debe tenerlo no cumple con la fecha prevista… hay que tener cuidado, porque el verdadero problema puede ser otro. Para mí sería un síntoma de que puedo tener riesgos importantes de incumplir en tiempo los entregables (técnicos o administrativos) del proyecto. ¡Ojo avizor!
Muchas gracias por la información. Uno de los aspectos que me deja más intranquilo es el de fijar un coste y un cronograma del proyecto en el Acta de Constitución. En el Plan de Proyecto es dónde se analiza en detalle el alcance del proyecto, el WBS, se definen las tareas, los recursos necesarios para ejecutarlas, el presupuesto y los riesgos.
Me parece muy arriesgado comprometer un presupuesto con la poca información de la que se dispone en el momento de lareparación del Acta del Proyecto. Si, el origen del proyecto es una oferta a un cliente el presupuesto ya está establecido en ella, pero si se trata de un proyecto interno y novedoso, comprometer el presupuesto del proyecto y el cronograma sin haberlo estudiado a fondo es arriesgado.
Entiendo que no es posible modificar el presupuesto o el cronograma una vez realizado todo el análisis que implica el Plan de Proyecto, ¿no? ¿Cómo gestionas esta incertidumbre inicial? Me parece interesante la propuesta de realizar una Acta de Constitución para cada Fase.
Tienes razón en que muchas veces resulta complicado establecer un calendario del proyecto y un presupuesto detallados, que al mismo tiempo sean precisos y con tan poca información disponible (en las etapas iniciales). En líneas generales, a los técnicos nos gusta dar datos rigurosos únicamente cuando verdaderamente podemos hacerlo.
Sin embargo, desde la perspectiva de un proyecto interno, muchas veces se requiere una aprobación inicial del proyecto para poder comenzarlo. Y para dicha aprobación, un gestor, gerente o directivo (como lo queramos llamar) difícilmente va a dar luz verde a una iniciativa sin saber si va a durar 3 meses o 5 años, y sin saber si va a costar 100 o 300. De hecho, en muchas organizaciones se necesita priorizar entre los numerosos posibles proyectos disponibles (es decir, ya no se trata de si decir que sí o que no, sino elegir aquellos que proporcionen mejor retorno, se ejecuten antes o simplemente sean más económicos).
Por otro lado, el aspecto temporal y económico es aún más importante si cabe en proyectos externos (aquellos en los que el cliente pertenece a otra organización). Simplemente porque nadie compra algo que no sabe lo que cuesta ni cuando lo va a tener. De hecho, muchas veces el cliente puede solicitar un presupuesto cerrado y una fecha límite, aun sin tener del todo claro el alcance (y luego pasa lo que pasa, claro).
¿Cómo resolver esta situación?
En mi opinión y en mi humilde experiencia, procuro afrontarlo desde la perspectiva humana y no técnica: realizo una estimación lo más ajustada a los datos disponibles, pero luego cuando la presento explico bajo qué circunstancias o premisas estoy dando esas cifras, y cómo podrían variar en un futuro. Un ejemplo concreto es cuando hago referencias explícitas a determinados aspectos del alcance (“sin la solución de intercambios de ficheros EDI, podríamos acelerar la implantación del sistema un mes” o “podríamos incorporar también la funcionalidad X, pero debido a que nos falta aún el detalle de cómo abordarlo, podemos estar hablando de entre 1 y 3 meses más en el plazo que ven aquí escrito”).
En cualquier caso, recuerda que siempre es posible plantear modificaciones de cronograma y de presupuesto a lo largo de todo el proyecto. Siempre. Puede realizarse de manera informal o formal (desde reuniones de viva voz hasta procedimientos de control de cambios). Lo que sí es importante es plantear desde el minuto 0 qué tipo de variaciones puede haber en el proyecto y cómo se van a gestionar a nivel de procedimientos (para evitar malas interpretaciones, confusiones o falsas expectativas en ninguno de los interesados). Esta ‘variabilidad’ es la que hay que intentar sistematizar mediante la gestión de riesgos del proyecto, recoger por escrito en el plan de gestión del proyecto y asegurar que es sabida por quien debe saberlo en la gestión de las comunicaciones.
No es un enfoque ideal y sin conflictos, pero parece mucho mejor planteamiento que intentar acertar a la primera cuando te piden una estimación.
Realmente esta muy interesante el articulo, soy estudiante de un postgrado y en la actualidad estamos viendo la materia de Gerencia de Proyecto y lo que indicas en el articulo es de gran ayuda.
Hola Toni, miuy util la información. Pero me surge una duda sobre el enfoque del documento. En todo momento das por sentado que tu eres el proveedor que ejecutará el proyecto. Esto quiere decir que yo, como unidad de sistemas de mi empresa y cliente ¿debo esperar/exigir este documento a mi proveedor? Por otro lado, ¿debo usar este documento para obtener la aprobación de mis clientes internos?
Hola Jose Manuel,
Gracias por comentar tus dudas.
“Esto quiere decir que yo, como unidad de sistemas de mi empresa y cliente ¿debo esperar/exigir este documento a mi proveedor?”.
En mi opinión, claramente sí (salvo proyectos muy cortos o de muy bajo alcance). Demuestra buen hacer por parte del proveedor y, además, sirve para “asentar” los aspectos más importantes del proyecto nada más comenzar. El Acta de Constitución de Proyecto permitirá abordar los aspectos clave de una manera breve pero introductoria: qué se espera del proyecto (objetivos), quién participará, cuándo, cuáles son los principales requisitos, etc.
Es habitual que se barajen muchas opciones y alternativas durante la fase comercial, y esto suele dejar muchas cosas en el aire. Para evitar esa sensación y reducir incertidumbre, presentar los aspectos más importantes en una primera reunión, con un documento general, me ha servido de mucho.
Desde la perspectiva de cliente, te recomiendo que lo solicites por escrito, que estipule con detalle el alcance y el cronograma y, además, que recoja los riesgos principales. Este último apartado suele descuidarse mucho, y que lo requieras al comienzo del proyecto, ayudará a marcar bien el terreno.
“Por otro lado, ¿debo usar este documento para obtener la aprobación de mis clientes internos?”. Esto depende muchísimo de cómo es la organización donde trabajas (tu posición en su organigrama, la cultura de la empresa, tu nivel informal de autoridad, el número de trabajadores, etc.). Pero rara vez le he encontrado perjuicios, por lo que te diría que lo propondría siempre.
De cara a la dirección, se trata de un documento ideal para plasmar qué se espera del proyecto, qué recursos se necesita y cuándo deben esperar resultados. De cara a los compañeros implicados, es interesante para saber para qué no es este proyecto (muy importante de cara a evitar confusiones posteriores), para cuándo está previsto tenerlo y qué se espera de cada participante.
Una puntualización: de cara a hablar con clientes internos, yo no me centraría en el documento de Acta de Constitución en sí (los alérgicos a la burocracia te mostrarán resistencia, y los enamorados de la burocracia te pedirán que amplíes el documento ad infinitum). En su lugar, propón una reunión de “presentación interna de proyecto”, y el orden del día será en esencia el contenido del Acta. Conseguirás tu objetivo y no correrás el riesgo de que nadie se centre en exceso en la forma.
En cualquier caso, no tengas en mente un documento muy extenso. Es muy frecuente que con dos o tres páginas sea suficiente para recoger de forma breve todos los aspectos (además, hacerlo muy extenso sólo sirve para que menor cantidad de gente lo lea, y se confundiría este documento con el Plan de Proyecto).
En mi caso personal, suelo realizarlo con una presentación en PowerPoint (me obliga a esquematizar y estructurar, y es más agradable de revisar que un Word) y realizo una exposición en la primera reunión del proyecto (KickOff Meeting) con todos los interesados.
Por último, existe un texto que puede darte una visión muy interesante sobre esto en el libro “Agile Samurai” de J. Rasmusson, en el apartado “Project Inception”. Presenta una visión sobre cómo generar una visión adecuada y unificado en un equipo ágil. Tal vez te resulte interesante.
Espero haberte sido de ayuda 🙂
Estimado Tony, soy gerente de programa en mi organziación. Te comento que si bien el acta de constitución depende de un equipo, quién debería ser el responsable de tenerala a tiempo, ya que se entiende que la misma debería estar autorizada previo el inicio del proyecto?. A qué área debería pertenecer esta persona?.
saludos cordiales,
Carlos.
Hola Carlos,
Disculpa que haya tardado en responderte.
Tu pregunta es muy interesante y, como en casi muchos otros aspectos de la gestión de proyectos, depende en gran medida de la cultura de la organización, así como del sector en el que se mueve la misma.
El Acta de Constitución, como tal, autoriza el inicio del proyecto al ser firmada, por lo tanto como bien dices es imprescindible disponer de ella antes de que comience el proyecto en sí.
Según el PMBOK, “los proyectos son autorizados por alguien externo al proyecto, tal como un patrocinador, una oficina de dirección de proyectos (PMO) o un comité ejecutivo[…]. Cualquiera de ellos elaborará el acta de constitución del proyecto o delegará esta tarea al director del proyecto“. Por lo tanto, en el caso que tú comentas, el acta de constitución podría ser preparado por ti mismo, por el patrocinador (quien financia el proyecto) o por el director de proyectos que asignes (como gerente de programa) para llevarlo a cabo.
En la práctica habitual de muchas empresas, sin embargo, es el propio director de proyectos el que redacta el Acta y la presenta al cliente o patrocinador para su aprobación. Pero esta no tiene por qué ser la única forma y mucho menos tampoco tiene que ser la “más correcta”.
En mi caso particular (lo menciono por aquello de dar ejemplos concretos, no para sentar cátedra), cuando soy el responsable de un proyecto, yo personalmente redacto el Acta de Constitución. Me permite, entre otras cosas, un trabajo de reflexión previo (al recopilar la documentación existente, obligarme a identificar bien a los interesados, considerar las restricciones del proyecto, leer las condiciones de la oferta o el contrato,…) que luego me resulta muy útil para la planificación. Además, redactar el documento y exponerlo me permite presentarme a los clientes como responsable, explicar mis atribuciones y obligaciones, repasar los documentos preliminares (contrato, oferta) y leer los detalles del acta con una mayor preparación y solidez.
En cambio, si fuera un gerente de programa, probablemente delegaría esta labor a cada director de proyecto que estuviera a mi cargo. Precisamente por los mismos motivos que comento en el párrafo anterior, pero también porque sería la mejor manera de involucrar a esa persona desde el “instante 0” del proyecto.
En tu comentario has destacado “tenerla a tiempo”. Permíteme dar una señal de aviso: si el problema no es elegir quien redacta el documento, sino que quien debe tenerlo no cumple con la fecha prevista… hay que tener cuidado, porque el verdadero problema puede ser otro. Para mí sería un síntoma de que puedo tener riesgos importantes de incumplir en tiempo los entregables (técnicos o administrativos) del proyecto. ¡Ojo avizor!
¡Espero haberte sido de ayuda!
Saludos,
Toni
Hola Toni,
Muchas gracias por la información. Uno de los aspectos que me deja más intranquilo es el de fijar un coste y un cronograma del proyecto en el Acta de Constitución. En el Plan de Proyecto es dónde se analiza en detalle el alcance del proyecto, el WBS, se definen las tareas, los recursos necesarios para ejecutarlas, el presupuesto y los riesgos.
Me parece muy arriesgado comprometer un presupuesto con la poca información de la que se dispone en el momento de lareparación del Acta del Proyecto. Si, el origen del proyecto es una oferta a un cliente el presupuesto ya está establecido en ella, pero si se trata de un proyecto interno y novedoso, comprometer el presupuesto del proyecto y el cronograma sin haberlo estudiado a fondo es arriesgado.
Entiendo que no es posible modificar el presupuesto o el cronograma una vez realizado todo el análisis que implica el Plan de Proyecto, ¿no? ¿Cómo gestionas esta incertidumbre inicial? Me parece interesante la propuesta de realizar una Acta de Constitución para cada Fase.
Muchas gracias por adelantado.
Un saludo,
Jordi
Muy buenas Jordi,
Muchas gracias por tu comentario.
Tienes razón en que muchas veces resulta complicado establecer un calendario del proyecto y un presupuesto detallados, que al mismo tiempo sean precisos y con tan poca información disponible (en las etapas iniciales). En líneas generales, a los técnicos nos gusta dar datos rigurosos únicamente cuando verdaderamente podemos hacerlo.
Sin embargo, desde la perspectiva de un proyecto interno, muchas veces se requiere una aprobación inicial del proyecto para poder comenzarlo. Y para dicha aprobación, un gestor, gerente o directivo (como lo queramos llamar) difícilmente va a dar luz verde a una iniciativa sin saber si va a durar 3 meses o 5 años, y sin saber si va a costar 100 o 300. De hecho, en muchas organizaciones se necesita priorizar entre los numerosos posibles proyectos disponibles (es decir, ya no se trata de si decir que sí o que no, sino elegir aquellos que proporcionen mejor retorno, se ejecuten antes o simplemente sean más económicos).
Por otro lado, el aspecto temporal y económico es aún más importante si cabe en proyectos externos (aquellos en los que el cliente pertenece a otra organización). Simplemente porque nadie compra algo que no sabe lo que cuesta ni cuando lo va a tener. De hecho, muchas veces el cliente puede solicitar un presupuesto cerrado y una fecha límite, aun sin tener del todo claro el alcance (y luego pasa lo que pasa, claro).
¿Cómo resolver esta situación?
En mi opinión y en mi humilde experiencia, procuro afrontarlo desde la perspectiva humana y no técnica: realizo una estimación lo más ajustada a los datos disponibles, pero luego cuando la presento explico bajo qué circunstancias o premisas estoy dando esas cifras, y cómo podrían variar en un futuro. Un ejemplo concreto es cuando hago referencias explícitas a determinados aspectos del alcance (“sin la solución de intercambios de ficheros EDI, podríamos acelerar la implantación del sistema un mes” o “podríamos incorporar también la funcionalidad X, pero debido a que nos falta aún el detalle de cómo abordarlo, podemos estar hablando de entre 1 y 3 meses más en el plazo que ven aquí escrito”).
En cualquier caso, recuerda que siempre es posible plantear modificaciones de cronograma y de presupuesto a lo largo de todo el proyecto. Siempre. Puede realizarse de manera informal o formal (desde reuniones de viva voz hasta procedimientos de control de cambios). Lo que sí es importante es plantear desde el minuto 0 qué tipo de variaciones puede haber en el proyecto y cómo se van a gestionar a nivel de procedimientos (para evitar malas interpretaciones, confusiones o falsas expectativas en ninguno de los interesados). Esta ‘variabilidad’ es la que hay que intentar sistematizar mediante la gestión de riesgos del proyecto, recoger por escrito en el plan de gestión del proyecto y asegurar que es sabida por quien debe saberlo en la gestión de las comunicaciones.
No es un enfoque ideal y sin conflictos, pero parece mucho mejor planteamiento que intentar acertar a la primera cuando te piden una estimación.
Espero haberte sido de ayuda.
Saludos,
Toni
Toni, como estas?
Realmente esta muy interesante el articulo, soy estudiante de un postgrado y en la actualidad estamos viendo la materia de Gerencia de Proyecto y lo que indicas en el articulo es de gran ayuda.
Saludos.
Gracias por el feedback, Eric!
no puedo encontrar un acta
Buenas,
En la sección de Recursos puedes encontrar una.
Saludos!