Guía Metodológica Para La Gestión de Proyectos

AGESIC Oficina de Proyectos Proyectos Guía Metodológica para la Gestión de Proyectos Historial de Revisiones Fecha 01/01/09 01/01/10

Versión 1 2

Descripción Versión inicial Versión revisada

14/02/13

3

Se unifica la gestión y registro de interseados

05/12/13

4

Se mejora la redacción y organización de este archivo. Se elimina el detalle de las planillas de cada tema en este archivo dado que ya está en las plantillas. Se agrega la nomenclatura y ubilación del proyecto en el portafolio Se agrega el sub-proceso de gestión de riesgos Se agrega el ROI durante la planificación del proyecto. Directorio: se agrega “rol” en el proyecto. Se agrupan en una planilla c on diferentes hojas los documentos: Directorio, Interesados, Comunicaciones Comunicaciones y Matriz RACI

Autor PMO PMO PMOTecnología

PMO

Se agrega “Aprobado por” en el control de cambios y áreas de conocimietno

11/11/14

5

relacionadas, observaciones y palabras clave de búsqueda en Lecciones Aprendidas. Se unifica unifica Incidentes, Control Control de Cambios y Lecciones Lecciones Aprendidas en una planilla con 3 hojas. Ajustes varios de formatos Actualización cuadro cuadro de Proceso de de Gestión de Proyectos, Proyectos, redacción redacción de párrafo siguiente acorde a los cambios del cuadro (pág. 5). Actualización documentación documentación asociada asociada (Gestión de de Cambios)

Nombre actual del archivo: 00_GuíaMetodologica_v04.odt

Torre Ejecutiva Sur, Liniers 1324 piso 4. Montevideo -Uruguay Tel/Fax: (+598) 2901. 2929* Email: [email protected] Email: [email protected] – Web: www.agesic.gub.uy

PMO

INVENTARIO DE DOCUMENTOS

Índice NOMENCLATURA DE DOCUMENTOS ........................................................................ 3 Proceso de Gestión de Proyectos ................................................................................. 4 Resumen Ejecutivo ...................................................................................................... 9 Acta de Constitución del Proyecto ............................................................................... 9 Declaración de Alcance del Proyecto ............................................................................ 9 Gestión de cambios .................................................................................................... 10 Directorio, Interesados, Comunicaciones, Matriz RACI ............................................... 10 Cronograma ................................................................................................................ 11 EDT – Estructura de desglose del trabajo ................................................................... 12 Presupuesto .............................................................................................................. 12 Análisis de Riesgos .................................................................................................... 12 Cambios, Incidentes y Lecciones Aprendidas ............................................................. 13 Plan de proyecto ....................................................................................................... 14 Informe de cierre......................................................................................................... 14 Otros Documentos ...................................................................................................... 15 0Actas de reuniones ................................................................................................ 15 1Informes de avance ............................................................................................... 15 2Registro de horas ................................................................................................. 16 3Glosario................................................................................................................. 16

Torre Ejecutiva Sur, Liniers 1324 piso 4. Montevideo -Uruguay Tel/Fax: (+598) 2901. 2929* Email: [email protected] – Web: www.agesic.gub.uy

2

INVENTARIO DE DOCUMENTOS NOMENCLATURA DE DOCUMENTOS La AGESIC ha elaborado recomendaciones de formatos de archivo a utilizar en las aplicaciones de ofimática por el Estado uruguayo. Todos los documentos referidos en esta Guía Metodológica deben seguir dicha norma. Esta norma recomienda la adopción de una política de almacenamiento e intercambio de documentos en medios digitales, y el apoyo y asesoramiento a los organismos públicos en la implementación y seguimiento de esta política. Dicho documento propone utilizar los estándares abiertos ODF y PDF para la creación, almacenamiento e intercambio de documentos de ofimática dentro de las instituciones estatales y en su relación con el resto de la sociedad. En particular la nomenclatura de los documentos es: {id_doc}_{nombre corto del proyecto}_{texto estándar}_v{número de versiónXX}.{ext}

El identificador de documento será de dos cifras. El nombre corto tendrá hasta 8 caracteres y será un identificatorio de los documentos del proyecto. El texto estándar identifica el contenido del documento y es uno de los que se indican más abajo. El número de versión se inicia en 01. El formato de archivo de documentos aprobados debe ser PDF. En el caso de documentos en elaboración se deben utilizar formatos de Open Document. Sólo en caso de intercambiar documentos de trabajo con otras Instituciones se puede utilizar temporalmente formatos propietarios. Se detallan a continuación las extensiones de archivos OASIS: Documentos / plantillas Tipo de fichero Texto Hoja de cálculo Presentación Dibujo Gráfica Fórmula matemática Imagen Documento maestro

Extensión .odt .ods .odp .odg .odc .odf .odi .odm

Todos los documentos de la PMO para los cuales existe un formulario estándar, contienen los ítem que los proyectos de porte mediano requieren. Los mismos deben ser instanciados al proyecto particular, y es posible que algunos de los títulos deben ser eliminados porque no corresponde su descripción.


3

INVENTARIO DE DOCUMENTOS PROCESO DE GESTIÓN DE PROYECTOS El siguiente diagrama representa el proceso de gestión de proyectos 1:

Participan tres roles en el proceso: Gerente de Proyecto (PMO), PMO Transversal y PMO Federada o del proyecto. A continuación se detallan cada uno de los pasos del proceso para cada rol. Lo que sigue está basado en el ingreso de información en Siges2 (Sistema de Seguimiento y Control del Portafolio: https://siges.agesic.gub.uy), en particular se resaltan los temas puntuales de la Metodología. 1.

Gerente de Proyecto (PM): 1.1. Solicitud de Alta: El Gerente de Proyecto mediante un formulario solicita el alta de su proyecto ingresando la siguiente información: Área de la Organización responsable del Proyecto (por defecto el área del PM)



Nombre del Proyecto (según los estándares establecidos por la organización)



Adjunto Gerente (otro usuario que tendrá los mismos permisos que el PM para el proyecto) 

Sponsor del Proyecto



El usuario que está realizando la solicitud queda automáticamente como

 1

En el caso de contar con una Estructura de PMO Federada, de no contar con la

misma la PMO asume las actividades de las PMO Federadas. 2

SIGES es un Sistema de Información para la Dirección de Proyectos, aquí se esta-

blecen las funcionalidades mínimas para poder gestionar la metodología y dese mpeñar los roles establecidos. Torre Ejecutiva Sur, Liniers 1324 piso 4. Montevideo -Uruguay Tel/Fax: (+598) 2901. 2929* Email: [email protected] – Web: www.agesic.gub.uy

4

INVENTARIO DE DOCUMENTOS Gerente del Proyecto, el PM no podrá modificar este dato En caso que el proyecto pertenezca a un programa se deberá indicar a cual (el programa deberá estar previamente activado en el sistema) 

En caso que el proyecto pertenezca a un programa ingresar el peso que el proyecto tendrá dentro del programa 

Permisos de Lectura: podrá indicar qué áreas pueden ver la información y qué áreas no pueden ver la información del proyecto. Esto solamente aplica para 

“usuarios comunes” (ver más adelante la definición de roles) Esta acción dispara una solicitud a la PMO Transversal para que configure y apruebe el proyecto (3.1).

1.2. Inicio: carga la información de Inicio del Proyecto: Objetivo



Público Objetivo



nvolucrados (ver especificación más adelante)



Metodología: Resumen ejecutivo o, Acta de Constitución y Alcance del Proyecto Situación Actual3 (texto)



Una vez cargada la información de Inicio el PM realizará una solicitud a la PMO Transversal para pasar el proyecto a Planificación (2.2).

1.3. Planificación: carga la información de Planificación del Proyecto:

Metodología: Involucrados, Matriz RACI y Comunicaciones Metodología: Riesgos Metodología: Cronograma, Productos4 y EDT Metodología: Presupuesto Metodología: Cálculo del ROI Herramienta_vxxxxxxxxxxxxx.xlsb)

(xx_MetodologiaROI_vxx.pdf,

Situación Actual5 (texto)



Una vez cargada la información de Planificación el PM realizará una solicitud a la PMO Transversal para pasar el proyecto a Ejecución (3.3).

1.4. Ejecución: carga la información de Ejecución del Proyecto: Metodología: Mantener actualizada la información del proyecto: Riesgos, Situación Actual, Entregables (% avance, inicio y fin o duración 6), documentos, 

3

Este texto debe reflejar la situación actual respecto a las metas, avance y prospectiva del Proyecto. En caso de tenerlos

4 5

Este texto debe reflejar la situación actual respecto a las metas, avance y prospectiva del Proyecto. Esto se hace en el módulo CRONOGRAMA del SIGES.

6


5

INVENTARIO DE DOCUMENTOS facturas conformadas (pagos) y productos 7. Metodología: En caso que haya algún cambio que impacte en el cronograma, alcance o presupuesto iniciar una solicitud de cambio a través del proceso de gestión de cambios, utilizando el template 04_XXX_SolicitudCambio_vxx.odt para realizar la solicitud y el template 11_XXX_Cambios_incidentes_LA_vxx.ods para el registro y gestión de las solicitudes de cambio 

Metodología, Lecciones Aprendidas: Durante la ejecución se debe ir actualizando el documento de Lecciones Aprendidas. Al solicitar el cierre, la PMO Federada deberá procesar dicho documento y cargar la Lecciones Aprendidas en el repositorio general de Lecciones Aprendidas. 

Cierre del Proyecto: Cierre Completo: Una vez finalizada la Ejecución del proyecto (esto implica como mínimo cerrar todos los pagos, entregables, registrar las Lecciones Aprendidas y actualizar la situación actual) el PM solicitará el cierre del proyecto lo cual disparará la petición a la PMO Federada (2.4). Cierre con temas pendientes: En caso que no se haya realizado el 100% del alcance definido para el proyecto, por lo que podrán quedar entregables y/o pagos sin cerrar, el PM deberá cargar las Lecciones Aprendidas y explicar la situación en la situación actual del proyecto. Esto disparará la petición a la PMO Federada para que cierre el Proyecto (2.4).

1.5. Realiza el Seguimiento y Control a nivel del Proyecto. Como parte de este trabajo es modificar la duración y fechas de los entregables en caso que se requiera (el sistema los comparará con la última línea base), gestionar los riesgos, comunicaciones, interesados, presupuesto, etc. 2.

PMO Federada: 2.1. Configuración y Activación del Proyecto: Una vez notificada por la PMO Transversal, la PMO Federada configura la siguiente información para el Proyecto: Podrá modificar el Gerente de Proyecto y Adjunto Gerente



Deberá establecer (y lo podrá modificar durante la vida del proyecto) los tiempos de actualización, semáforo utilizado para cuando la información no está actualizada en 2 niveles (amarillo y rojo) 

Metodología: Configurar la metodología exigida para el proyecto según el grupo de procesos en que el proyecto se encuentre (Inicio, Planificación, Ejecución, Cierre) Deberá ingresar el Presupuesto aprobado para el proyecto, la fuente de financiamiento y la moneda (deglosado en cada uno de estos componentes). 

Configura las notificaciones a utilizar para el proyecto



Esta acción activará el proyecto y le enviará la correspondiente notificación al PM y a la PMO Transversal. 7

En caso de haberlos cargado


6

INVENTARIO DE DOCUMENTOS 2.2. Replanificación: En caso de necesitar una replanificación, la PMO Federada deberá hacer una solicitud a la PMO Transversal. Como parte de dicha solicitud se deberá ingresar la siguiente información: En primer lugar la PMO Federada deberá indicar si desea guardar una copia de la línea base actual. En caso de seleccionar esta opción, deberá ingresar un texto explicativo sobre la replanificación. Para la primer replanificación, es decir, en el caso que haya una sola línea base el sistema no permitirá elegir si se desea guardar una copia, lo marcará como seleccionado y no dejará modificar esta opción. 

Esta acción disparará una notificación a la PMO Transversal para que esta pase el proyecto a Planificación.

2.3.

Cancelar el proyecto: En caso de querer eliminar el proyecto, la PMO Federada del Proyecto enviará la petición a la PMO Transversal (3.4).

2.4. Cierre del Proyecto: Cuando el PM realiza la solicitud de cierre del proyecto, la misma le llegará a la PMO Federada. La PMO Federada deberá realizar lo siguiente: Verificar que estén todos los ítems del proyecto cerrado. En caso que falten temas por cerrar, verificar que esté la explicación correspondiente en la situación actual del proyecto 

Verificar que se haya cumplido la metodología exigida para el proyecto



Verificar que el PM haya registrado las Lecciones Aprendidas del proyecto



Procesar las Lecciones Aprendidas del proyecto cargadas por el PM y alimentar el repositorio general de Lecciones Aprendidas 

Una vez realizadas estas acciones deberá enviar la solicitud de cierre a la PMO Transversal (3.5).

2.5. Seguimiento y Control: La PMO Federada realizará el Seguimiento y Control del Proyecto con la colaboración del PM con el objetivo de colaborar con el Seguimiento y Control del Portafolio. 3.

PMO Transversal: 3.1. Configuración y aprobación del proyecto: La PMO Transversal configura el proyecto y en tal caso podrá modificar la información ingresada en el paso 1.1 por el PM. Una vez configurado lo aprueba. La información a configurar por la PMO Transversal es la siguiente: Podrá modificar toda la información cargada por el PM en 1.1



Deberá establecer la PMO Federada del proyecto (debe ser un usuario del sistema con rol de PMO Federada) 

Cargar la información relativa a la clasificación del proyecto asociándole áreas temáticas. Se trata de un sis tema de “tags” que se crearán en la Administración del sistema, donde la PMO Transversal podrá asociar algunos de ellos al proyecto. El objetivo es poder realizar búsquedas o filtros por 

determinado “tag” o tema.

Metodología: La PMO Trasnversal y la PMO Federada podrán configurar la Torre Ejecutiva Sur, Liniers 1324 piso 4. Montevideo -Uruguay Tel/Fax: (+598) 2901. 2929* Email: [email protected] – Web: www.agesic.gub.uy

7

INVENTARIO DE DOCUMENTOS metodología exigida para el proeycto en función de la complejidad y tipología del mismo. En caso de no configurarla, el sistema tomará la configuración por defecto. Una vez la PMO Transversal apruebe el proyecto, el sistema le enviará una notificación a la PMO Federada para que configure lo que corresponda y active finalmente el proyecto (2.1). Luego de este paso el proyecto continuará oculto (solamente visible para las PMOs) hasta que la PMO Federada lo active.

3.2. A la PMO Transversal le llega la solicitud y mueve el proyecto a Planificación. Se requiere el comienzo de las actividades de Planificación del Proyecto. 3.3. A la PMO Transversal le llega la solicitud y mueve el proyecto a Ejecución. En este momento el sistema toma el cronograma cargado por el PM como la línea base del proyecto. En caso que el proyecto haya estando antes en Ejecución, es decir, se haya replanificado, esta nueva línea base será la línea base activa del proyecto y la anterior se guardará como histórico. Esta acción le disparará una notificación al PM y a la PMO Federada.

3.4. La PMO Transversal recibe la solicitud y cerrará el proyecto. Para esto es necesario que la PMO Federada haya procesado las Lecciones Aprendidas. En caso que al proyecto le haya quedado algún ítem por cerrar (por ejemplo: un pago, un entregable) porque no se realizó y que esto esté debidamente documentado en la situación actual, la PMO Transversal lo cerrará de todas formas. Esta acción le disparará una notificación al PM y a la PMO Federada. 3.5. En caso que la PMO Federada lo solicite, la PMO Transversal podrá borrar el proyecto. 3.6. La PMO Transversal realizará el Seguimiento y Control del proyecto con el apoyo de la PMO Federada y el PM como parte del Seguimiento y Control del Portafolio. El fin de mostrar el detalle del proceso de gestión de proyectos es que se comprenda cómo y dónde encajan los diferentes elementos de la metodología. A modo de resumen según el grupo de procesos en que el proyecto se encuentre, la metodología se deberá trabajar de la siguiente forma (se explica el caso por defecto, podrá variar dependiendo de cómo la configure la PMO Federada en cada caso):

Inicio PMO Transversal: chequea la nomenclatura del proyecto y comunica la ubicación del mismo (dependencias y necesidades) PM: Resumen Ejecutivo o Acta de Constitución + Alcance del Proyecto

Planificación PM: Cronograma PM: Interesados PM: Análisis de Riesgos, Presupuesto PM: Indicadores y metodologías para la medición del impacto del proyecto en tiempo y costo para el Estado y la Ciudadanía, cálculo del ROI. Torre Ejecutiva Sur, Liniers 1324 piso 4. Montevideo -Uruguay Tel/Fax: (+598) 2901. 2929* Email: [email protected] – Web: www.agesic.gub.uy

8

INVENTARIO DE DOCUMENTOS Ejecución PM: Actualización del cronograma en % de avance por tarea y estimación de nuevas fechas para las tareas no termiandas. PM: Actualización de riesgos, al menos 1 vez al mes PM: Actualización de los pagos (aprobar el pago cuando llegue en forma correcta la correspondiente factura) y/o actualización de la fecha estimada de pago e importe en caso que sea necesario. PM: Actualizar el sistema en todo lo que corresponda. PM: Lecciones Aprendidas: mantener actualizado el documento de lecciones aprendidas

Solicitud de Cierre: luego que el PM solicita el cierre del proyecto PMO Federada: Procesar el log de Lecciones Aprendidas del proyecto alimentando el repositorio central de la organización de Lecciones Aprendidas

RESUMEN EJECUTIVO El resumen ejecutivo es un breve análisis de los aspectos más importantes del proyecto y es lo primero o a veces único que lee el público en general. En pocas palabras, es un breve documento donde se debe describir el producto o servicio a entregar el objetivo y público objetivo, bajo qué meta estratégica se enmarca el proyecto y luego un breve resumen de los principales hitos o entregables, presupuesto, riesgos y dependencias. En general en la metodología el Resumen Ejecutivo sustituye al Acta de Constitución y Documento de Alcance del Proyecto. El Resumen Ejecutivo está orientado a público en general por lo que su relato debe tener en cuenta esta situación (debe ser comprensible para público en general). La plantilla de este documento es la siguiente:

01_XXX_Resumen_Ejecutivo_vxx.odt

ACTA DE CONSTITUCIÓN DEL PROYECTO El objetivo principal de este documento es reconocer formalmente la existencia del proyecto e identificar al Director del mismo. La responsabilidad sobre su contenido es de quien actúa como Patrocinador. Su elaboración es una instancia formal de transferencia de conocimiento entre ambos. El acta de constitución, a diferencia del Resumen Ejecutivo le da un tono más formal a la existencia del proyecto. Este documento no debe exceder las 2-3 páginas, su plantilla es la siguiente:

02_XXX_Acta_de_Constitucion_vxx.odt


9

INVENTARIO DE DOCUMENTOS DECLARACIÓN DE ALCANCE DEL PROYECTO La Declaración del alcance del proyecto contiene la descripción del alcance del proyecto. El proceso de desarrollar el enunciado del Alcance del Proyecto aborda y documenta las características y los límites del proyecto, y sus productos y servicios relacionados, así como los criterios de aceptación acordados. Se debe incluir los elementos que NO incluye el alcance del proyecto con el objetivo de evitar posibles malentendidos durante la ejecución del mismo. La plantilla para este documento es la siguiente:

03_XXX_Alcance_vxx_vxx.odt

0 GESTIÓN DE CAMBIOS En caso que durante la ejecución del proyecto ocurran cambios que impacten en el presupuesto, cronograma y/o alcance, el Gerente de Proyecto debe iniciar una solicitud de

cambio

en

el

proceso

de

gestión

de

cambios

utilizando

la

plantilla

a

del

archivo

04_XXX_SolicitudCambio_vxx.odt.

La

gestión

de

las

Solicitudes

de

Cambio

se

realiza

traves

11_XXX_Cambios_incidentes_LA_vxx.ods , que debe ser actualizado mensualmente.

DIRECTORIO, INTERESADOS, COMUNICACIONES, MATRIZ RACI Un mismo archivo centraliza todos estos temas ya que de por sí están muy relacionados. El Directorio de Proyecto o Agenda es un documento que registra todos los contactos de interés para el proyecto: nombre de la persona de contacto, el nombre de la Organización a la que pertenece la persona, su correo electrónico, teléfonos fijos y móviles, la dirección física y las Observaciones a tener en cuenta. Interesados (Stakeholders): Los interesados son todas aquellas personas u organizaciones que se pueden ver afectados por el proyecto o las actividades de la ejecución del proyecto tanto en forma negativa como positiva. Es fundamental para el éxito del proyecto identificarlos y gestionar la comunicación en base a una estrategia definida con el objetivo de maximizar los interesados positivos y minimizar y en lo posible hacer cambiar de parecer a los interesados negativos. El objetivo de este documento es identificar a los interesados, determinar sus requisitos y expectativas y, en la medida de lo posible, gestionar su influencia en relación con los requisitos para asegurar un proyecto exitoso. Se describe en una matriz la Identificación de interesados, pudiendo elaborarse un cuadro inicial con la siguiente información: Identificación de Interesados, sus expectativas y que grado de influencia que tienen en el proyecto.


10

INVENTARIO DE DOCUMENTOS La Matriz de Comunicaciones refleja todas las comunicaciones efectuadas durante el transcurso del proyecto registrando: la fase en que debe realizarse, con que frecuencia, información a comunicar, responsable, etc. Es un documento especialmente importante teniendo en cuenta que la mayor causa de fracaso en los proyectos se debe a problemas de comunicación. La Matriz RACI es una matriz de asignación de responsabilidades y se usa para ilustrar las conexiones entre el trabajo que debe realizarse y los miembros del equipo del proyecto. El nombre que recibe el diagrama (RACI) es debido a que los nombres de los roles que se documentan son: Responsible (Responsable) - Responsable de Ejecución - La o las personas  responsables de que el trabajo esté hecho.  Accountable (Responsable Directo) - Responsable de Cumplimiento – Sólo una (1) persona puede ser responsable directo de cada tarea.  Consult (Consultado) – Aquellas personas a quienes se les consulta porque participan en la planificación y la toma de decisiones de la tarea. Inform (Informado) – Las personas a las cuales se les debe informar periódi camente el estado de progreso de la tarea, las decisiones, y otras informaciones relacionadas a coordinar el trabajo y facilitar la colaboración. En el eje horizontal se especifican las personas o el grupo de personas y en el eje vertical se especifican las actividades a asignar. Los valores que definen el rol asignado son R, A, C e I. Es una buena práctica en las columnas especificar los roles dado que las personas pueden cambiar durante el proyecto y a la vez, en el directorio aclarar el rol de cada persona. Debe estar elaborado el cronograma del proyecto previamente a la construcción de la Matriz RACI. Este documento es de carácter reservado, para uso del Director de Proyecto y un equipo reducido de miembros, su planilla es:

05_XXX_Interesados_Comunicaciones_RACI_vxx.ods

1 CRONOGRAMA El desarrollo del C ronograma del proyecto es un proceso iterativo, determina las fechas de inicio y finalización planificadas para las actividades del proyecto. El desarrollo del cronograma exige que se revisen y se corrijan las estimaciones de duración y las estimaciones de los recursos para crear un cronograma del proyecto aprobado que pueda servir como línea base con respecto a la cual poder medir el avance. En lo que respecta al cronograma, este hito podría ser el punto de inflexión entre la planificación y la ejecución del proyecto. El desarrollo del cronograma continúa a lo largo del proyecto, a medida que el trabajo avanza, el plan de gestión del proyecto cambia, y los eventos de riesgo anticipados ocurren o desaparecen al tiempo que se identifican nuevos riesgos. En general el Cronograma se representa mediante un diagrama de Gantt. Torre Ejecutiva Sur, Liniers 1324 piso 4. Montevideo -Uruguay Tel/Fax: (+598) 2901. 2929* Email: [email protected] – Web: www.agesic.gub.uy

11

INVENTARIO DE DOCUMENTOS Recomendamos la utilización de la herramienta ProjectLibre que se puede obtener en http://www.projectlibre.org/. Documento a generar:

06_XXX_Cronograma_vxx.pod

EDT – ESTRUCTURA DE DESGLOSE DEL TRABAJO La EDT es una descomposición jerárquica, orientada al producto entregable, del traba jo que será ejecutado por el equipo del proyecto, para lograr los objetivos del proyecto y crear los productos entregables requeridos. Organiza y define el alcance total del proyecto, subdivide el trabajo del proyecto en porciones de trabajo más pequeñas y fáciles de manejar, donde cada nivel descendente representa una definición cada vez más detallada del trabajo del proyecto. La descomposición es la subdivisión de los productos entregables de un proyecto en componentes más pequeños y fáciles de manejar. La EDT puede ser gestionada a partir del cronograma, utilizando Project, Open Project o Project Libre utilizando la vista WBS (el tal caso se solicita imprimirla en pdf y subirla al sistema como EDT) o utilizando la siguiente plantilla:

06_XXX_EDT_vxx.odt

PRESUPUESTO El documento de Presupuesto contiene todos los costos del Proyecto. Enumera determinada información que debe ser adaptada a cada proyecto, no siendo siempre válida la descripción del formulario modelo. En caso que no se utilice el módulo de presupuesto del sistema de seguimiento y control del portafolio y se solicite se deberá utilizar la siguiente plantilla:

08_XXX_Presupuesto_vxx.ods

ANÁLISIS DE RIESGOS El documento de Análisis de Riesgo tiene como objetivo la Gestión de los Riesgos del Proyecto con el fin de aumentar la probabilidad y el impacto de los eventos positivos, y disminuir la probabilidad y el impacto de los eventos adversos para el proyecto. El Análisis de Riesgo está comprendido por una Lista de Riesgos que registra todos los riegos con los siguientes detalles de cada uno: una descripción que lo identifica, la fecha de registrado, la probabilidad de ocurrencia, el impacto de su ocurrencia y el índice de riesgo que se calcula automáticamente a partir de los campos anteriores. Torre Ejecutiva Sur, Liniers 1324 piso 4. Montevideo -Uruguay Tel/Fax: (+598) 2901. 2929* Email: [email protected] – Web: www.agesic.gub.uy

12

INVENTARIO DE DOCUMENTOS Tener el cuenta que dicho valor debe ser menor a 100 %. Luego aparece el efecto que produce en la fase ó el proyecto, la estrategia de mitigación, evento disparador que nos permite anticipar su ocurrencia y el plan de contingencia asociado. En la hoja 2 aparece una matriz gráfica, que permite visualizar gráficamente el nivel de riesgo tiene el proyecto tomando como indicadores la probabilidad de ocurrencia del riesgo y el grado de impacto que produce en el proyecto de acuerdo a los criterios definidos. Los indicadores que interesan en la gestión de riesgos de un proyecto son los siguientes: Índice de Riesgo del proyecto = promedio del impacto/probabilidad de cada  riesgo detectado. Este indicador ilustra el grado de exposición al riesgo del proyecto. Cantidad de Riesgos altos: Cantidad de riesgos identificados que tienen una  probabilidad de ocurrencia alta y un impacto alto en el proyecto. Estos son los riesgos más importantes del proyecto.  Fecha de actualización de la planilla de riesgos: Interesa que la misma sea revisada y actualizada al menos una vez por mes. Si bien el índice puede ser bajo, el proyecto puede tener unos pocos riesgos altos que tendrán que ser seguidos de cerca dado que algunos de ellos podría hacer fracasar al proyecto. Es por esto que también interesa el segundo indicador. Por otro lado, la gestión de riesgos es una tarea viva a lo largo de la vida del proyecto, los riesgos se van moviendo en probabilidad/impacto y van surgiendo nuevos riesgos. En caso que este trabajo no se realice durante la ejecución o se deje pasar mucho tiempo se corre el peligro de no tener gestionados los riesgos, por lo tanto también interesa la fecha de actualización del análisis de riesgos. Desde la versión 4.0 de la metodología, se estableció e implantó en la organización un sub-proceso de gestión de riesgos avanzado que se detalla en el archivo 09_XXX_ProcesoGestionRiesgos_vxx.xls La plantilla para gestionar los riesgos del proyectos es la siguiente:

09_XXX_Riesgos_vxx.ods y 09_XXX_Riesgos_vxx.xlsx

CAMBIOS, INCIDENTES Y LECCIONES APRENDIDAS Se unifican los tres temas en una planilla con tres hojas.

Cambios: Como se estableció anteriormente, se utilizará el proceso de gestión de cambios definido en la organización. El objetivo en esta instancia es que el Gerente de Proyecto lleve un registro de todas las solicitudes de cambio independientemente si fueron aprobadas o no. Cada registro debe tener un hipervínculo al archivo de solicitud de cambio. La hoja “Control de Cambios” debe utilizarse para esta finalidad. Para re alizar las solicitudes de cambio se usa el template: 04_XXX_SolicitudCambio_vxx.odt


13

INVENTARIO DE DOCUMENTOS Incidentes: se debe enumerar una descripción breve del incidente, la fecha de ocurrencia, el estado, comentarios pertinentes, el responsable, fecha límite y la f echa de resolución. Esta planilla es la bitácora del día a día del proyecto. Algunos incidentes dispararán solicitudes de cambio dependiendo del impacto que tengan sobre el proyecto. Antes de finalizar el proyecto, el Gerente de Proyecto debe apoyarse en los incidentes para elaborar las Lecciones Aprendidas que luego serán procesadas por la PMO Federada y volcadas al repositorio central de la organización. Se debe utilizar la hoja “Incidentes” para este fin.

Lecciones Aprendidas: Previo a solicitar el cierre del proyecto, el Gerente de Proyecto en base al registro de incidentes deberá generar las lecciones aprendidas. Para cada una deberá indicar la categoría (a evitar o a repetir), la descripción, la fecha de ocurrencia, las áreas de conocimiento afectadas, observaciones y asociarle palabras clave de búsqueda. La plantilla para el registro de cambios, los incidentes y las Lecciones Aprendidas es la siguiente:

11_XXX_Cambios_incidentes_LA_vxx.ods

PLAN DE PROYECTO El Plan de Proyecto es un documento formalmente aprobado que define cómo se ejecuta, supervisa y controla un proyecto. El mismo debe ser instanciado especialmente de acuerdo a las características del proyecto, teniendo especial cuidado en no excederse en su descripción. Debe mencionarse el proceso de control de cambios definido a nivel de la organización así como todos los demás activos a utilizar. Para el plan del proyecto se debe utilizar la siguiente plantilla:

12_XXX_Plan_Proyecto_vxx.odt

INFORME DE CIERRE El informe de cierre debe tener los siguientes puntos: Productos obtenidos: Enumerar y detallar todos los productos obtenidos por el proyecto. •

Resultados alcanzados: breve descripción sobre los resultados logrados en el proyecto. •

Actividades de transferencia realizadas: Enumerar una a una con una breve descripción las actividades de transferencia realizadas. En cada una hacer referencia a la documentación generada. •

Principales lecciones aprendidas: a partir de las lecciones aprendidas del proyecto, destacar las más importantes y agregar la estrategia a seguir recomendada para futuros gerentes de proyectos que utilicen esta información para sus proyectos. •


14

INVENTARIO DE DOCUMENTOS Temas sin terminar: En caso que no se haya finalizado algún producto, servicio, entregable, documento o pago debe destacarte explícitamente en este documento relatando las razones por las que no se concluyeron, el impacto que esto ocasionó e indicar (en caso que corresponda) a qué proyecto se transfirió el trabajo pendiente. •

Para elaborar el informe de cierre se debe utilizar la siguiente plantilla:

13_XXX_Informe_Cierre_vxx.odt

OTROS DOCUMENTOS 2 3 Actas de reuniones El documento de Actas de Reuniones describe toda la información relevante que arroja cada reunión realizada en el marco de cada proyecto. Se debe detallar la asistencia a la reunión con las personas citadas y el porcentaje de participación; describir la agenda, el desarrollo y cada una de las resoluciones tomadas -si las hubo- durante la reunión; enumerar las tareas asignadas -si las hubocon sus responsables y la fecha de entrega; describir los temas que quedaron pendientes de discusión –si los hubo-, realizar una evaluación de la reunión indicando un índice de productividad entre 0 y 5 y por ultimo citar los datos de la próxima reunión pautada (fecha, hora, lugar y agenda tentativa). En la reunión siguiente se debe revisar el estado de las tareas asignadas previamente. Plantilla: 20_XXX_ActaReunion_YYYYMMDD_vxx.odt

4

Informes de avance

El documento Informe de Avance forma parte de las Comunicaciones del Proyecto que busca asegurar la generación, recogida, distribución, almacenamiento, recuperación y destino final de la información del proyecto en tiempo y forma. El modelo del documento corresponde a un informe detallado de avance para poder conocer cuál es el estado actual del proyecto. El nombre del informe de avance indicará el número y la fecha a la que corresponde. Plantilla: 21_XXX_Avance_YYYYMMDD_vxx.odt

5

Registro de horas


15

INVENTARIO DE DOCUMENTOS La matriz Registro de Horas detalla la actividad realizada por las personas en el/los proyecto/s y el tiempo dedicado a cada una de ellas medido en horas. La matriz Mensual por Persona registra la dedicación (en horas) por cada persona a cada proyecto y en cada día del mes. Se enumeran el nombre de la persona, el mes y año de registro, el nombre del proyecto, el nombre de la actividad realizada, su identificador y para cada día del mes se registra el tiempo insumido en horas. La matriz Acumulado Anual registra un acumulado mensual de la dedicación (en horas) de cada persona a cada proyecto. Se enumeran el año, el proyecto, la persona y para cada mes del año se registra el tiempo insumido en horas. Notar que en el nombre del archivo debe aparecer el nombre de la persona. Plantilla: 22_XXX_Registro_Horas_NOMBREPERSONA.ods

6

Glosario

El Glosario es un documento diccionario con la definición de todos los términos, siglas o palabras particulares propias del proyecto que son utilizadas en la documentación que lo acompañan. Esto es de gran importancia para poder entender y realizar un seguimiento correcto al proyecto. Plantilla: 23_XXX_Glosario.odt


16

Guía Metodológica Para La Gestión de Proyectos

Recommend Documents