El presente documento es un documento integrador y guía general de la gestión particular del proyecto.
Este documento está compuesto de las siguientes partes:
El Plan de Gestión de Proyecto, es un documento o conjunto de documentos vivo, tanto entre proyectos, como durante el proyecto. Es principalmente un índice de referencia de diferentes entregables que se irán realizando y actualizando durante el proyecto. A la finalización del proyecto, el Plan de Proyecto quedará finalizado y podrá ser consultado como bitácora ya que contendrá: intervinientes, presupuesto, alcance, tareas, desviaciones, riesgos, costes finales, tiempos, etc.
En cada proyecto este documento deberá ser revisado para que se adapte a las necesidades particulares de tamaño, velocidad, cantidad de interlocutores, visibilidad o costes.
Por tanto, el presente documento debe ser tomado como una plantilla.
El Plan de Gestión de Proyecto incluye 10 subplanes, que más abajo se detallan. Si bien toda la gestión del proyecto pivotará sobre las 4 componentes básicos o baselines (que se deben tener definidos en los primeros días del proyecto):
- Alcance
- Costes
- Plazo
- Calidad
Las líneas base no se deben entender como algo fijo a lo largo del proyecto puede haber cambios. Si bien, dichos cambios no serán gratuitos. Es decir, las líneas base aunque no son estáticas, sí que son difícilmente variables; ya que por el contrario se perdería la esencia del proyecto: meter en tiempo y costes una cantidad de entregables.
En estos casos, las líneas base se actualizarán para mostrar cómo habría sido la planificación inicial si hubiéramos tenido en cuenta dichos cambios desde el principio.
1.1. Acta de Constitución de Proyecto (obligatorio)
El acta de constitución de proyecto será un documento que describa brevemente el proyecto, y que alinea de partida a todos los intervinientes, y además servirá de arranque de tareas así como justificación de necesidades para la contratación.
1.1.1. Tareas asociadas
- [ ] Elaboración del Acta de Constitución de Proyecto
- [ ] Distribución del Acta de Constitución de Proyecto a los stateholders.
1.1.2. Documentos de apoyo
1.2. Plan de gestión de cambios (obligatorio)
Los cambios en alcance y tiempo deberán ser gestionados como «Cambios de Alcance» como se describe en «Plan de Gestión de Alcance».
Tipos de Cambios a gestionar:
- Personal de IT
- Personal Interesado del Departamento Usuario
- Personal del Proveedor
- Cambios contractuales con el proveedor.
- Impacto de otros proyectos
Cualquier cambio la deberá aprobar el Responsable de Aplicaciones o en su defecto el Director de Tecnología. Para dicha aprobación se ha acordado internamente el siguiente proceso:
- El equipo de proyecto realiza una breve descripción del cambio propuesto con respecto a la línea base aplicable.
- El equipo de proyecto estima o, si es posible, acuerda con los proveedores las repercusiones que dicho cambio tendría en alcance, plazo y costes para el proyecto.
- La información anterior es introducida en una “propuesta de cambio”, documento estándar del proyecto. Dicha propuesta de cambio será firmada por el jefe de proyecto o responsable de Aplicaciones.
- Finalmente, la descripción del alcance, el presupuesto y el programa del proyecto serán actualizados para considerar las propuestas de cambio aprobadas por el responsable.
1.2.1. Documentos de Apoyo:
- Protocolo de Gestión de Cambios o Plantilla para el Plan de Gestión de Cambios
1.2.2. Tareas Asociadas:
▪ Realizar documento de gestión de cambios (o revisar que la plantilla es suficiente)
▪Enviar a los proveedores y usuarios el plan de gestión de cambios para asegurarnos que no habrá cambios en el proyecto sin su correspondiente gestión.
1.3. Plan de gestión de alcance (obligatorio)
La gestión del alcance es posiblemente la más importante de todas las tareas de un Jefe de Proyecto. En el fondo, es la esencia del proyecto: “qué vamos a hacer”. Por tanto, también es la base de la satisfacción del usuario.
Un correcto entendimiento, acuerdo entre los usuarios y el departamento de IT, y muy posiblemente con un proveedor de IT es clave para el éxito del proyecto. Por mucho dinero que pongamos sobre la mesa, podemos fracasar. Tanto es así que es la base del fracaso de Agile en las organizaciones.
El alcance formal del proyecto tiene 4 partes:
- Preparación de la Declaración del Alcance (scope statement). Esta parte explica cómo se va a preparar el documento correspondiente.
- Desarrollo de la estructura del proyecto. Detalla de qué manera se desglosarán y analizarán las actividades necesarias para cumplir el objetivo del proyecto, todas las cuales pertenecen al alcance. En IT es bien sencillo, todos los proyectos tienen la misma estructura:
- Lanzamiento
- Análisis
- Preparación de entornos
- Diseño
- Desarrollo
- Pruebas Unitarias
- Pruebas de Integración
- Pruebas de Usuario
- Paso a Producción
- Control del alcance. Cómo pretendemos controlar que estamos cumpliendo con el alcance acordado (cuando los usuarios posiblemente vayan cambiando de opinión por el camino o salen nuevas necesidades) y cómo vamos a tratar los cambios en el mismo.
- Aceptación de la entrega. Sin criterios de aceptación cualquiera puede decir que ha entregado y cualquiera puede decir que está incompleto el alcance. Hay que definir muy bien, qué se considera una entrega exitosa y una entrega fallida. Este punto: es posiblemente lo más difícil de TODA la gestión de proyecto.
1.3.1. Documentos de Apoyo
- Plantilla de Plan de Gestión de Alcance
1.3.2. Tareas Asociadas
- [ ] Cumplimentar Declaración de Alcance
1.4. Plan de gestión de requisitos
Si la gestión de Alcance es lo más importante, la gestión de requisitos es lo siguiente más importante, ya que en el fondo es detallar el Alcance en piezas más pequeñas, e incluso con requisitos totalmente fuera del alcance para el usuario, como por ejemplo, temas de seguridad, control, arquitectura de sistemas, etc.
El plan de gestión de requisitos, por tanto, será el documento por el que se enumerarán todos los requisitos solicitados por los peticionarios.
Este documento es vital, y la que será la base para:
- adquisiciones o licitaciones a proveedores
- Aseguramiento de la calidad, ya que será la base para el plan de pruebas.
- Aseguramiento de la satisfacción del usuario y la gestión de sus expectativas.
- Elaboración de la planificación
- Elaboración del presupuesto
Visto en perspectiva, un plan de gestión de requisitos es necesario para proyectos de desarrollo de productos software, en los que creamos un entregable basándonos no en una descripción del mismo sino en una descripción de las funcionalidades que esperamos que sean cumplimentadas.
1.4.1. Documentos de apoyo:
- Plantilla de Plan de Gestión de Requisitos
1.4.2. Tareas asociadas:
- [ ] Elaboración de documento de requisitos
- [ ] Aceptación por el usuario del Documento de Requisitos
- [ ] Aseguramiento de que los requisitos aceptados se entregan por el proveedor (Calidad)
1.5. Plan de gestión de la planificación
Con la planificación (ej. diagrama de Gantt) ya nos meteremos en “harina” y el Jefe de Proyecto comienza a tomar decisiones y se empieza a estrechar el circulo (recuerda que el alcance hay que meterlo en un tiempo y un presupuesto).
La planificación inicial será creada conjuntamente con el equipo de proyecto, el proveedor, y aprobado por el jefe de proyecto. Tras la fase de licitación, la planificación se detallará para incluir los trabajos de cada una de las empresas subcontratadas, si las hubiera.
A todos nos gustaría hacer las planificaciones sumando las planificaciones de cada una de las partes, y lo que salga. PUES NO. La realidad y la experiencia nos dice que los proyectos siempre tienen que estar para antes de la primera estimación (habitualmente la más generosa) y es labor del jefe de proyecto empezar a trabajar y ver cómo se paraleliza, cómo se fasea, cómo se “pulen” algunos requisitos para que “algo menos” sea mucho más rápido de implantar.
Esa negociación es parte fundamental de las tareas del jefe de proyecto.
La planificación será supervisada constantemente, aunque una actualización oficial será preparada una vez al mes, conteniendo información sobre el estado de las actividades, retrasos, curvas de avance, camino crítico y plazo actualizado de la finalización del proyecto.
Además, el Jefe de Proyecto preparará extractos del mismo conteniendo la información relevante para cada departamento que lo requiera.
Cada nueva actualización del programa considerará los cambios aprobados durante el mes transcurrido tanto en la línea base como en el programa actual.
1.5.1. Documentos de apoyo:
- Plan de gestión de la Planificación o Planificación
1.5.2. Tareas asociadas:
- Hacer planificación iniciar de proyecto.
- Hacer actualización de planificación (y buscar las excusas para justificar los cambios, que seguro que serán a peor).
1.6. Plan de gestión de costes (obligatorio)
Un proyecto no está gestionado si no se gestionan los costes. Y un Jefe de Proyecto no es un Jefe de Proyecto si no tiene la responsabilidad (y la aplica) de gestionar los costes.
Los costes son administrados directamente por el equipo de Governance de IT, y por los departamentos de compras y finanzas.
Si bien, el jefe de proyecto será el responsable de ajustar los costes del proyecto al presupuesto, y por ello deberá preparar un plan de costes que contenga el estado actual de los gastos y compras realizados en el proyecto y un pronóstico fiable de los gastos futuros para la finalización del proyecto.
En ocasiones, el jefe de proyecto (sobre todo si trabaja en consultora) se va a encontrar con situaciones imposibles: el comercial ha vendido el proyecto por un importe imposible de realizar (el famoso ”Proyecto Estratégico”) en cliente se nos suelen pedir plazos imposibles. Para lidiar con esta situación es muy conveniente hacer muy bien el plan de gestión de costes. En consultora estará muy asociado con
Dicho pronóstico será actualizado mensualmente.
Variaciones en el presupuesto total asignado al proyecto deberán ser informadas claramente incluyendo sus causas y discutidas el responsable de Aplicaciones para la aprobación del nuevo presupuesto.
El estado actual de gastos se extraerá del ERP (por el equipo Governance de IT) y el cálculo hasta el final del proyecto será realizado en la plantilla estándar “costes de proyecto” preparada en Excel para tal efecto.
1.6.1. Documentos de apoyo:
- Plan de Gestión de Costes (Excel)
1.6.2. Tareas asociadas:
- [ ] Elaboración del Plan de Costes
- [ ] Actualización semanal y Mensual de plan de costes.
- [ ] Informar mensualmente a Gerencia de IT del plan de costes en la reunión de revisión de proyectos.
1.7. Plan de gestión de calidad / Plan de Pruebas (obligatorio)
El Jefe de Proyecto será la persona encargada de la calidad en el proyecto, el cual elaborará un plan de certificación identificando todos los requisitos y los criterios de aceptación. Para ello, concretamente en los desarrollos deI IT, recibe el nombre de Plan de Pruebas.
Las empresas contratadas deberán cumplir con los estándares de calidad requeridos por nuestra empresa. Para asegurar tal requisito, los procesos de compra definen que se deberá realizar una auditoría de los nuevos suministradores antes de su contratación.
Hay que recordad que la “calidad” es entregar lo que “se ha dicho que se va a entregar” lo cual cubrimos con una correcta gestión del alcance y de los requisitos. Pero también la “calidad” es entregar el software con unos “requisitos” no escritos y esperados, y que son interpretados como falta de calidad, como por ejemplo:
- Lentitud en procesos:
- posiblemente por no hacer un buen performance de las querries de BB.DD.
- No tener unos servidores o comunicaciones bien dimensionadnos.
- Problemas de usabilidad a lo largo del aplicativo.
- Problemas de compatibilidad con navegadores o Java o plugins de terceros.
Estos puntos anteriores deben estar incluidos en el plan de Pruebas.
las entregas se ajustan a lo solicitado
que la usabilidad de lo entregado se adapta a la dinámica del usuario ▪ que está libre de errores:
Errores Funcionales: el software no hace lo que debería hacer
Errores Técnicos: el software hace lo que debe hacer pero ocasionalmente falla, dejando el sistema no disponible o genera inconsistencia de datos o permite progresar a estados inconsistentes.
Errores de Integración: en la transmisión con otros sistemas
Errores de reporting: a la hora de la extracción de información para realizar informes de gestión.
Lentitud excesiva del sistema: lo cual dificulta su utilización o explotación operativa.
Pruebas de Regresión: donde aseguremos que las nuevas funcionalidades no han afectado a funcionalidades ya implementadas.
Para realizar el plan de pruebas utilizaremos la Metodología de Gestión de Pruebas en «V», donde por cada requisito funcional (Ver Plan de Gestión de Requisitos) debe haber al menos una prueba que contenga la funcionalidad solicitada. Generalmente por cada requisito funcional habrá varias pruebas asociadas.
1.7.1. Documentos de apoyo:
- Plantilla de Pruebas. Se aconseja que por cada aplicativo, tener una única plantilla que vaya pasando de proyecto en proyecto, para así tener la funcionalidad completa, y poder hacer las pruebas de regresión.
1.7.2. Tareas Asociadas:
- Realizar el plan de pruebas.
- Asegurarse de que se las pruebas se han realizado, tanto las de usuarios como las de integración con sus correspondientes evidencias.
1.8. Plan de gestión de comunicaciones (obligatorio)
Para mantener controlado el proyecto, se debe mantener controlados a los intervinientes, y la mejor manera de hacerlo es informando puntual y precisamente a cada uno de ellos. Esta habilidad es más política que técnica, pero es tremendamente importante y muy olvidada, ya que los Jefe de Proyecto de IT muchas veces sus habilidades sociales brillan por su ausencia.
Por tanto, el jefe de proyecto se encargará de preparar una matriz de stakeholders (Matriz RACI). Dicha matriz contiene información sobre la importancia, capacidad de influencia, necesidades de información y actitud ante el proyecto de cada uno de los actores identificados.
El plan de gestión de comunicaciones consiste en la planificación del tipo de comunicación y la frecuencia de la misma con cada uno de los stakeholders identificados en la matriz anterior. El jefe de proyecto deberá revisar el plan de gestión de comunicaciones como mínimo una vez al mes, reevaluando la posición de cada uno de los actores con respecto al proyecto para identificar posibles cambios de manera prematura y actuar al respecto.
Es importante recordar que el plan de comunicaciones considerará al propio equipo de trabajo como una serie de stakeholders de gran importancia para conseguir el éxito en el proyecto.
1.8.1. Documentos de apoyo:
- Plan de Comunicación
- Matriz RACI
1.8.2. Tareas asociadas:
- Elaboración de Matriz RACI
1.9. Plan de gestión de riesgos (obligatorio)
Un jefe de proyecto realmente aporta valor, cuando es capaz de anticiparse a los problemas (=riesgos) del proyecto, y tienen pensado un Plan B.
Esto si lo sistematizamos implicaría que el Jefe de Proyecto deberá elaborar la Matriz de Riesgos y mantenerla actualizada.
La lista de riesgos estándar será utilizada en este proyecto.
El Jefe de Proyecto será encargado de actualizar mensualmente dicha lista con información sobre el impacto máximo, la probabilidad y las acciones a realizar o planes de contingencia asignados a cada riesgo y a cada oportunidad.
La lista será revisada mensualmente en la reunión de revisión del proyecto, y los posibles costes evaluados serán reservados como posibles costes para el proyecto.
El plan de acción para reducir los riesgos y aumentar las oportunidades deberá ser considerado como una lista de acciones relacionadas con el proyecto (Planes de Contingencia). A dichas acciones se asignará un responsable y un plazo de ejecución.
1.9.1. Documentos de apoyo:
- Matriz de Riesgos
1.9.2. Tareas asociadas:
- Hacer matriz de riesgos
- Mantener actualizada mensualmente la Matriz de Riesgos
1.10. Plan de gestión de adquisiciones y compras (obligatorio)
En la mayor parte de los proyectos de IT se contará con proveedores, por tanto se deberá seguir el procedimiento de compras.
El diseño en detalle, la supervisión y los diferentes trabajos y suministros para la construcción del edificio serán separados en lotes (si por tamaño tiene sentido) y comprados por el departamento de compras.
Será requerido un mínimo de tres ofertas para cada lote.
La evaluación de las ofertas será mediante el precio final considerando los riesgos asociados a cada suministrador.
1.10.1. Documentos de Apoyo:
- Protocolo interno de Compras.
