Disponer de una metodología de Gestión de Proyectos para un departamento de IT, parece sencillo, ya que tenemos múltiples opciones. Sobre todo gracias a la irrupción de SCRUM o Agile como tendencias.
Pero muchas organizaciones descubre que Agile es muy difícil de implantar tanto por la cultura de empresas, como por lo complicado que resulta tener un entregable aceptable con un presupuesto cerrado. Por eso muchas empresas se pregunta ¿es agile para mi?. Y muchas otras vuelven a las metodologías clásicas, mucho más compatibles con los departamentos financieros, y las expectativas generales de compañía.
Por eso, en esa serie de artículos desarrollo una metodología de gestión para un departamento de IT para una empresa aproximadamente con 1.000 usuarios. Es decir, hay un flujo constante de proyectos, un presupuesto con el que se pueden hacer cosas, y un elenco de departamentos que demandan servicios y fiabilidad.
No solo es una metodología es el diseño completo de un departamento de Desarrollo Software de Aplicaciones IT.
1.1. Objetivo de este documento:
El presente documento será la guía metodológica por la se regirán todos los proyecto de aplicaciones del departamento de IT. Este documento está compuesto de las siguientes partes:
Este documento está compuesto de las siguientes partes:
Con la aplicación de esta metodología se pretende alcanzar los siguientes objetivos:
- Unificación de criterios
- Una correcta gestión y trazabilidad de los desarrollos, mejoras, cambios o ampliaciones en las aplicaciones de la compañía.
- Una gestión trasparente de la gestión económica
- Una gestión unificada y coordinada de las expectativas de los departamentos de mangantes.
- Una coordinación mejorada con los departamentos de Compras y Compliance
- Una sistematización y homogeneización de los requisitos mínimos de implementación
- Una correcta gestión de la calidad de los entregables
- Una adecuada coordinación entre el proceso de construcción de software y su posterior mantenimiento y operación.
La presente metodología está basada en la metodología PMI, pero se le han aplicado simplificaciones y ajustes para que sea totalmente práctica en el uso diario de la compañía. A su vez, el documento está diseñado como un conjunto de plantillas y guías con sus correspondientes explicaciones que deberán ser eliminadas durante la ejecución del proyecto.
1.2. Ámbito de aplicación
En la actual organización del departamento de IT se desarrollan multitud de proyectos y de diferentes tipologías y con diversos interesados o usuarios finales.
El ámbito de aplicación de esta metodología será:
- Todos los proyectos de desarrollo de software. Es decir, trabajos de más de 120 horas/hombre.
- Quedan excluidos los evolutivos que esté incluidos en los contratos de mantenimiento de aplicaciones (AM), es decir, trabajos de menos de 120 horas/hombre.
- Los evolutivos dentro de los contratos de AM tendrán una gestión simplificada. Ver apartado “Gestión Simplificada de Evolutivos en AM”
- También se aplicará en caso de que un proyecto sea de menos de 120 horas pero que implique a más de un equipo de IT (Ej: Arquitectura, Aplicaciones u Operaciones/Producción) y cuya suma total supere las 120 horas se deberá aplicar la presente metodología.
Esta metodología será de obligado cumplimiento para todos los Jefes de Proyecto del grupo de Aplicaciones del Departamento de IT.
La aplicación de esta metodología tiene un impacto a 3 niveles de gestión:
1.3. Fases Mínimas de un Proyecto de IT
En cualquier proyecto de IT, y especialmente de desarrollo de software, se deben incluir obligatoriamente las siguientes fases:
- Fase de Inicio del Proyecto
- Fase de Planificación
- Fase de Ejecución del proyecto. Dentro de esta fase, de forma sistemática se deben cumplir al menos las siguientes sub-fases:
- Análisis
- Diseño
- Desarrollo o Construcción
- Pruebas
- Pruebas Unitarias
- Pruebas de Integración
- Pruebas de Usuario
- Paso a Producción
- Garantía
- Paso a Mantenimiento
- Fase de Control (paralela a Fase de Ejecución)
- Fase de Cierre.
En la planificación de TODOS los proyectos se deben incluir las fases anteriormente detalladas.
NOTA: Erróneamente se considera que un proyecto comienza cuando comienza su construcción o contratación. Por el contrario, un proyecto comienza cuando se levanta el “Acta de Constitución de Proyecto”, que básicamente identifica el momento donde la necesidad, viabilidad y presupuesto son suficientes y la organización da luz verde para su inicio. Después vendrá las contrataciones, definiciones, pruebas, etc.
1.4. Tareas a alto nivel en la gestión de proyectos.
La gestión de proyectos es una tarea sistemática donde para cubrir con eficacia cada una de las fases se deben completar diferentes tareas. En la presente metodología, la mayor parte de dichas tareas están expresadas en forma de “documentos” o “planes”.
La finalidad de estos documentos no es “generar papel”, sino dedicar tiempo a pensar, planificar y comunicar adecuadamente, lo cual incrementa las probabilidades de éxito del proyecto.
Para ayudar a la gestión de los proyectos a continuación se enumeran las tareas a alto nivel que debe ejecutar el jefe de proyecto.
Las responsabilidades serán:
- Por defecto, todas las tareas deberán ser realizadas por el Jefe de Proyecto (JP) y será el Jefe de Proyecto el/la encargado/a de asegurarse su finalización.
- O bien por la Gerencia (G), a saber, Dirección de Aplicaciones o Dirección de IT.
- O bien por el Proveedor (p)
| Área | Inicio | Planificación | Ejecución | Control | Cierre |
| Integración y Coordinación General | Desarrollar Acta de Constitución de Proyecto (JP) | Desarrollar Plan para la Dirección de Proyecto (JP) | Dirigir y gestionar la Ejecución del proyecto (JP) | Monitorear y controlar el avance del proyecto (G), Realizar el control Integrado de Cambios (JP) | Cerrar el proyecto (JP) |
| Alcance | Recogida de Requisitos (JP), Definir el Alcance (JP), Crear EDT (esquema de descomposición de tareas) (p) | Verificar el Alcance (JP), Controlar el Alcance (JP) | |||
| Planificación | Definir Actividades (p), Secuenciar Actividades (JP, P), Estimar Recursos de las Actividades (JP, p), Estimar Duración de Actividades (JP, P), Desarrollar Cronograma (JP, P) | Controlar el Cronograma (JP) | |||
| Costes | Estimar costes (JP, P), determinar presupuesto (G) | Controlar los Costes (JP) | |||
| Calidad | Planificar la Calidad (JP, P) | Asegurar la Calidad (JP) | Control de Calidad (JP) | ||
| RRHH | Planificar los RR.HH. (JP) | Adquirir el equipo de proyecto (p), Desarrollar el Equipo de proyecto (p) | Gestionar el equipo de proyecto (p) | ||
| Comunicaciones | Registro de Interesados (JP) | Planificar las Comunicaciones (JP) | Distribuir información (JP), Gestionar las expectativas de los interesados (JP) | Informar el desempeño (JP) | |
| Riesgos | Planificar la Gestión de Riesgos (JP), Identificar los Riesgos (JP), Realizar análisis Cualitativo de los Riesgos (JP), Realizar análisis Cuantitativo de los Riesgos (JP), Planificar la Respuesta a los Riesgos (JP) | Monitorizar y controlar los riesgos (JP) | |||
| Adquisiciones | Planificar las Adquisiciones (JP) | Ejecutar las adquisiciones (JP) | Administrar las adquisiciones (JP) | Cerrar las adquisiciones (JP) |
1.5. Check List de Tareas para gestión de proyecto
Lanzamiento:
- Acta de Constitución de Proyecto
- Creación (copia) de Árbol de Directorios el proyecto en Teams o directorio compartido.
- Distribución del Acta de Constitución de Proyecto a los stateholders.
- Elaboración del Plan de Gestión de Cambios. Puede ser únicamente revisión de la plantilla adjunta, la cual sigue el protocolo habitual de actuación.
- Cumplimentar Declaración de Alcance
- 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)
- Elaboración de la Planificación (versión inicial)
- Actualización de la Planificación semanalmente para la reunión de seguimiento de Aplicaciones (tarea periódica)
- Elaboración del Plan de Costes
- Actualización Mensual de plan de costes. (tarea periódica)
- Informar mensualmente a Gerencia de IT del plan de costes en la reunión de revisión de proyectos.
- Preparación de plan de calidad/Plan de Pruebas.
- Distribución a los proveedores el plan de calidad y especialmente los criterios de aceptación.
- Elaboración de la Matriz RACI del proyecto. Plan de Comunicación
- Elaboración de Matriz de Riesgos
- Actualización mensual de Matriz de Riesgos.
Ejecución:
- Reunión Semanal de Avance de Proyectos con la Gerencia de IT. (tarea periodica)
- Reunión semanal de avance de Proyecto con el/los proveedores. (tarea periodica)
- Reunión semanal de avance de Proyecto con el/los usuarios. (tarea periodica)
Cierre:
- Acta de Finalización de Proyecto
- Repaso de Entregables
- Repaso de Documentación en repositorios oficiales
- Repaso de Pedidos y Facturas pendientes de pagar.
- Envío de Acta de Finalización de Proyecto a los stateholders.
- Encuesta de satisfacción
- Lecciones aprendidas. Distribuir entre los stateholders
- Lecciones aprendidas. Almacenar junto con el resto de documentación del proyecto.
1.6. Herramientas corporativas para la gestión:
Documentación:
La documentación de cada proyecto debe utilizar las siguientes herramientas:
Documentación del Proyecto: Microsoft Teams en su repositorio de ficheros compartidos (sharepoint).
Árbol de Directorio:
Se seguirá el siguiente criterio: En el grupo “Aplicaciones IT”, cada Sistema tendrá un canal. Dentro del Canal, se abrirá un proyecto, siguiendo la siguiente estructura:
- Estructura:
- Aplicaciones IT
- Aplicación (Ej: Saleforce)
- Proyecto (Ej: PEGASO.2020.01 – Sigue nomenglatura <Sistema>.<año>.<reléase o fase>)
- Aplicación (Ej: Saleforce)
- Lanzamiento
- Acta de Constitución de Proyecto
- Configuraciones
- Cambios
- Plan de Gestión de Cambios
- Alcance
- Documentos de definición de alcance.
- Requisitos
- Documentos de levantamiento de requisitos
- Planificación
- Documentos o enlace a planificación
- Costes
- Hoja de control de costes
- Calidad – Plan de Pruebas
- Plan de Pruebas por cada entregable
- Mejora de Procesos (opcional)
- RRHH (opcional)
- Comunicaciones
- Matriz RACI
- Riesgos
- Matrix de Riesgos
- Adquisiciones
- RFQ para la adquisición de servicios
- Presupuestos de adquisición y aceptación (oferta firmada)
- Ejecución
- Reunión Seguimiento Semanal (documento PPT actualizado).
- Supervisión
- Cierre
- Acta de finalización de proyecto
- Aplicaciones IT
- Planificación de Proyecto
- En documentación del proyecto.
- También se puede utilizar diagramas de Gantt, ya sea con Microsoft Project o plantillas de Microsoft Excel.
Tareas:
- Asignación de Tareas:
- Tareas de desarrollo a proveedores: Jira. Se creará un proyecto en Jira Desarrollo con un Canvan para su seguimiento. Se dejará a elección del proveedor si desea gestionar el proyecto por sprints o fases.
- Tareas de Integración al grupo PdA (Pool de Aplicaciones): JIRA
- Para tareas generales o recurrentes se puede utilizar: Outlook (reuniones recurrentes) o Microsoft Teams Planner.
Comunicación:
- Interna:
- Microsoft Teams:
- Actas de reunión
- Plan de Pruebas
- Definición de Requisitos
- Email (oficial)
- Según se indique en la matriz RACI para comunicaciones
- Microsoft Teams:
- Externa / Con proveedores
- Email (oficial)
