A lo largo de cada fase del ciclo de vida de los proyectos debemos estar atentos a  los “problemas” y “oportunidades de mejora” que se presenten  con la finalidad de documentarlos  para luego analizar  y descubrir sus causas raíz, evitando así que los mismos se presenten en etapas posteriores  o proyectos futuros.

Las siguientes preguntas pueden ayudarnos a EXAMINAR las  lecciones aprendidas del proyecto, que históricamente son difíciles de elaborar, e se dejan para el Final  y despues del cierre del proyecto pasan al olvido.

Para que esto no suceda es recomendable plasmar   las lecciones en un documento y asociarlao al proces de cierre del Proyecto, es decir elaborar estos 2 entregables a la vez ( Acta de Cierre y Documento de Lecciones Aprendidas) si pueden estar juntos mejor, obligandonos asi a que sea haga OBLIGATORIA su presentacion y posterior firma por el  Cliente.

Preguntas:

Las 7 “R” de la Gestión de Cambios (para documentar un cambio)

Estoy suponiendo que este esfuerzo es parte de la estrategia de implementación de una  Oficina de proyectos (PMO) por eso no mencionare  los pasos previos para llegar a este punto, solamente  lo que se debe de tener presente para documentar los principales procesos .

Debes de tomar en cuenta como base  los PROCESOS  relacionados con la Gestión de proyectos (42 en la nueva versión del PMBOK) las personas o Sateholders involucrados, la Documentación historica y los sistemas de soporte con que cuente la empresa relacionados al tema (MSProject, Primavera, Excel, otros).

Sobre los sistemas o herramientas puedes comenzar utilizando Microsoft Office (Word, Excel, MsProject) y en otros casos apoyarte con algunos sistemas Open-source o de bajo costo. Si ya tienes algún programa o solución debes de evaluar como? y cuanto? esta se adapta a los procesos y buenas practicas de PMBOK.

El siguiente es un planteamiento de lo que podría ser la estructura  general , en base a las áreas de conocimiento antes mencionadas.

Espero que esta estructura sea util  para sentar las bases y te sirva de guia para dar tus primeros pasos en la formacion de la PMO

1. ¿Que factores se toman primordialmente en cuenta a la hora de planificar un proyecto de IT?

Planificar un proyecto de TI no debería ser diferente al proceso de planificación de cualquier otro tipo de proyecto, debiendo ser este inclusive un poco más riguroso por ser la tecnología de la información un tema  tan dinámica y cambiante en estos días.
Pienso entonces que las consideraciones más importantes a tomar en cuenta a la hora de desarrollar un plan de proyecto de IT deberían ser entre otras;

1. Validar si el alcance del proyecto (a iniciarse) responde a los requerimientos del cliente.
2. Identificar las prioridades del cliente respecto al proyecto (costos, tiempo,calidad) ¿ Cuál de estas es más importante para él?
3. Dar los primeros pasos en conocer la cultura organizacional y sistemas en uso del cliente (entrevistas con los principales stakeholders, revisión de información historica, otros)
4. Involucrar al equipo del proyecto en el desarrollo del Plan (no hacerlo de manera individual).
5. Recordar que un plan de proyecto no es un cronograma, sino que este abarca factores más amplios o planes subsidiarios en áreas tales como alcance, costos, tiempos, calidad, riesgos, recursos humanos, comunicaciones, subcontrataciones (estas últimas el PMBOK las llama “áreas de conocimiento”).

2. ¿Cómo es este proceso de planificación?

El elemento clave para iniciar el proceso de planificación es tener sin duda un EDT bien estructurado (Estructura de Desglose del Trabajo, WBS en inglés). Es decir “lo que esta y lo que no está incluido en el proyecto”, preguntas como ¿Cual es el ciclo de vida del proyecto (trabajo a realizarse a lo largo del proyecto dividido en fases)? o ¿Cuales son los principales entregables a producir? deben ser respondidas y documentados  por todo el equipo antes de iniciar los trabajos. Una clave para desarrollar un buen EDT es dividirlo por lo menos en 3 niveles; fases del ciclo de vida, sub fases y paquetes de trabajo (este ultimo de 40 a 80 hrs como máximo cada uno.)

El proceso de planificación suele ser gradual e iterativo, por definición gradual significa planificar en detalle el trabajo que se tiene que realizar en el corto y mediano plazo (mayor visibilidad) y planificar a  más alto nivel el trabajo a largo plazo (menor visibilidad) lo iterativo nos permite regresar en el proceso a definir en detalle lo que inicialmente estaba planteado de forma general.

El resultado final del proceso de planificación debe ser un plan de proyecto que contenga por lo menos las “línea base” de los  principales áreas de conocimiento del PMBOK, como son el mencionado EDT (alcance), un cronograma base (tiempo), un presupuesto base (costos) y una matriz de riesgos inicial (riesgos).

Finalmente recordemos que el plan es una guía para todo el equipo de proyecto, que nos ira llevando de la mano en la fase de ejecución  y ayudando a corregir desviaciones en la fase de seguimiento y control.

3. ¿Cómo es o debe ser la relación con la Alta Gerencia durante la planificación de una iniciativa de IT? Y durante la implementación?

La alta gerencia suele formar parte de los stakeholders mas importantes y  muchas veces también cumplen el rol de sponsors, como es conocido la participación de los stakeholders es de mayor influencia en las fases tempranas del proyecto y tienden a disminuir al finalizar el mismo, sin embargo pienso que  la clave es  hacer un buen manejo de stakeholders en todas las fases del proyecto, manteniéndolos informados de los avances del proyecto y problemas mayores que puedan afectar la consecución de los resultados

Sabemos que el ciclo de vida de un proyecto es básicamente dividir al proyecto en fases para una mejor administración y control y que además existen características generales sobre costos, riesgos, personal, stakeholders  y otros dependiendo de la fase en la que nos encontramos atravesando en el proyecto.

Veamos el comportamiento de estas variables durante el ciclo de vida de los proyectos :

GRAFICOS

Costos y Staff – menor al principio, crece en la fase intermedia y decrece al final

Cambios  – el costo de hacer un cambio siempre sera mayor mientras el proyecto avanza hacia el final.

Riesgos  – Hay mucha incertidumbre al inicio que decrece a medida que se van completando las fases del proyecto

Influencia de los Stakeholders  – Importante el manejo de los stakeholders desde el inicio del proyecto

Otro de los comentarios provenientes de esta charla fue la manera de cómo interactúan los “procesos de gestión de proyectos” dentro de las fases de un proyecto, coincidiendo que ambos (Ciclo de vida y grupos de procesos) no son lo mismo como algunos pueden pensar.

Tomando la siguiente grafica podemos ver que los procesos de gestión de proyecto no son discretos como se suele graficar en los libros ( figura 1) sino que se traslapan entre si ( figura 2) dándoles una apariencia de repetitivos dentro del ciclo de vida – a que me refiero –  si tomamos el proceso de planificación por ejemplo podemos darnos cuenta que este proceso y sus actividades no solo se da al inicio del proyecto, sino que al inicio de cada fase, dándonos con esto la posibilidad de validar en cada fase si aun se mantiene el alcance y los objetivos iniciales  por los que fue tomando el proyecto.

Figura 1

Figura 2

Otra particularidad es que cada fase o alguna de ellas pueden ser un subproyecto en si y valerse de todo los procesos de la gestión de proyectos como se ve a continuación. Esto es muy importante definirlo desde el principio ya que el resultado de una fase puede necesitar ser aprobado para dar inicio a la subsiguiente, por ejemplo un diseño “no aprobado” puede detener la fase de construcción en un proyecto de desarrollo de software.

Figura 3

Como conclusión del articulo podríamos comentar lo siguiente:

Conoce desde un inicio muy bien cual es el ciclo de vida de tu proyecto, explícaselo a tus clientes y configura como van a interactuar en ellas los procesos de gestión de proyectos.

cuadro 1 : Mapa de Procesos

Definiciones:

• Los procesos de  Inicio y Planificación son la base para definir un buen alcance, identificar a los stakeholders y crear la Línea Base
• El proceso de Ejecución se encargara de ejecutar lo planificado, poner en acción el plan.
• El proceso de Control medirá el rendimiento del proyecto contra el plan y ejecutara acciones correctivas /preventivas y cambios necesarios para corregir las desviaciones sobre la Línea base.
• El proceso de Cierre, verificara y aceptara los productos entregables por cada fase y en forma general sobre el proyecto.

Procesos de Cambios

El proceso de Control mide constantemente las  “varianzas” a la línea base y establece acciones correctivas que son retroalimentadas al proceso de ejecución.

Si la Línea base no se ve afectada el cambio se considera una acción correctiva sin efecto en la triple restricción del proyecto

Si La Línea base se ve afectada el cambio se ejecuta mediante una solicitud  de gestión de cambios, donde es retroalimentado el proceso de planificación para actualizar la línea base.

cuadro 2 : Entregables principales y participantes por cada  una de las fases o grupos de procesos

A mi parecer el valor o beneficio mas importante es el de validar los requerimientos y expectativas del proyecto con los mismo protagonistas. Muchas veces se discute que el proyecto puede haber estado mal dimensionado desde la fase comercial y por lo tanto inicia con mucho riesgo y  en algunas veces pre-destinado al fracaso, es pues aqui donde el Gerente de Proyecto debe tomarse el tiempo para VALIDAR el alcance, primero a lo interno de la organizzacion y luego presentarlo al cliente dentro de la reunion de Kickoff.  Que sucede si el alcance vario? la respuesta es presentar una  ”Solicitud de Cambio” o  en algunos casos  hacer una “Addenda al Contrato”.

Recuerde este ultimo parrafo y atrevase a cuestionar las lineas base de alcance , tiempo y costo, si no lo hace en esta etapa inicial  y usa el Kickoff como una “herramienta de gestion”  tendra despues que iniciar un proyecto con muy pocas posibilidades de exito .

A modo de guia he preparado un Cheklist general de lo que seria “La preparacion de una presentacion de Kickoff” para tus proyectos.  Espero que le sea util y que lo pongas en practica en tu proximo proyecto.