Andares de un proyecto

Un proyecto en aprietos

Publicado el Marzo 15th, 2011 en Inicio, Planeación, Alcance, General por admin

aprietos.jpgHace poco vino un colega para pedirme consejo con respecto a un proyecto al que acababa de ser asignado. Al parecer el proyecto no era nuevo, era un proyecto que ya había fracasado y ésta era la “segunda vuelta” que iban a dar, pero con algunos cambios, entre ellos, el contratar a un Administrador de Proyectos profesional a quien pedirían cuentas sobre los resultados del proyecto.

En cuanto llegó le pedí que me explicara cómo les había ido en el primer intento y, de acuerdo a lo que le habían comentado, el me relató lo siguiente:

Entorno del proyecto
Se trata de una escuela que quiere ampliar sus servicios educativos para que los alumnos de preparatoria tengan otros medios de ponerse al corriente con clases que no tomaron o que quisieran repasar. El director y el consejo escolar planearon tener un sistema computacional que les permitiera tomar las clases sin necesidad de un instructor.

Debo mencionar que me interesó mucho el caso porque tocaba tres de mis puntos fuertes: Sistemas Computacionales, Project Management y la industria del aprendizaje asistido por computadora (e-Learning).

De manera que le pedí que me comentara cuales habían sido las acciones que el equipo de proyecto había emprendido antes de llamarlo a él para apoyarles, y el continuó diciendo:

Creación del equipo de proyecto
El director de la escuela armó un equipo para abordar el proyecto. Viendo la necesidad de crear material didáctico eligió a cuatro profesores y un líder de proyecto.

Definición de alcance del proyecto, roles y tiempos
El equipo se concentró originalmente en definir el alcance del proyecto y aclarar todas las dudas que tuvieran con respecto a lo que se haría. Después invitaron al director para que estableciera las prioridades de las actividades, así como para solicitar su apoyo y para motivar a los participantes de este esfuerzo ya que todos los miembros del equipo continuarían con sus actividades normales y, además, estarían desarrollando los entregables del proyecto.

Los integrantes del equipo definieron horarios en los que trabajarían en este esfuerzo y definieron el número de cursos a desarrollar, que se estableció en 18 cursos.

En las primeras reuniones también se detectó que ninguno de los participantes tenía experiencia previa en el modelo de aprendizaje automatizado, si bien eran expertos en la enseñanza y preparación de material, nunca habían participado en un proyecto en el que tuvieran que implementar el marco tecnológico necesario, por lo que decidieron contratar a una empresa que les apoyara con esta parte de los entregables.

Finalmente, el equipo de proyecto definió la fecha de entrega de los cursos para tener un marco de referencia del fin del proyecto.

Inicio del proyecto
El proyecto arrancó con la asignación de algunos maestros adicionales para que apoyaran con la elaboración de los cursos. Los consultores definieron los formatos en los cuales los maestros pondrían la información de acuerdo a su experiencia docente. Adicionalmente los consultores capacitaron a los profesores en el uso de la plataforma tecnológica a emplear para el proyecto.

Desarrollo del proyecto
Los profesores empezaron a desarrollar los cursos por separado y cuando terminaban se los enviaban al equipo del proyecto para que estos los revisaran y aprobaran. Los consultores continuaron apoyando con respuestas a las dudas sobre el uso de la plataforma y cargando archivos en esta.

Durante el tiempo designado los maestros elaboraron los materiales de los cursos hasta terminar. Cuando enviaron los materiales para revisión, el equipo de proyecto notó que aunque todos usaron la misma herramienta para elaborarlos, los cursos no eran uniformes, algunos eran apropiados y apegados a los objetivos del aprendizaje y otros no lo estaban en lo absoluto. Algunos tenían una buena presentación mientras otros no la tenían.

Cambio de rumbo
El líder del proyecto solicitó la presencia del director de la escuela para conocer su opinión y éste determinó que el material creado no cumplía con los objetivos del aprendizaje del alumno y solicitó que le agregaran características de animación y mejores transiciones entre las diapositivas para facilitar el aprendizaje.

Tomando lo anterior como un nuevo rumbo para el proyecto se calcularon las implicaciones y se determinó que la entrega del proyecto se retrasaría, el costo de la consultoría se elevaría y se requeriría que los maestros trabajaran horas extra en el material que ya habían realizado (re-trabajo).

En búsqueda del culpable
Cuando se evaluaron estas implicaciones y se revisaron los cambios presupuestales se intentó encontrar dónde había estado el problema. Los maestros le echaron la culpa a los consultores porque éstos no les estaban dando toda la información acerca de la plataforma que estaban operando. Los consultores le echaron la culpa a que había habido un cambio en el alcance del proyecto. El equipo original del proyecto argumentó que el problema era que no se había ofrecido una compensación monetaria para los maestros por haber trabajado específicamente en ese proyecto. Alguien más argumentó que el problema estaba en el proceso y que era necesario establecer más y mejores puntos de revisión en el mismo.

En ese momento el director autorizó la contratación de un Project Manager externo para hacerse cargo… así es, ese era mi amigo.

¿Te suena familiar este caso?
Desafortunadamente hoy en día todos, y no me da miedo generalizar, todos nos enfrentamos a proyectos de algún tipo, con poca o nada de preparación para enfrentarlos (administrarlos).

Mi amigo es un PM novato y afortunadamente el proyecto que dejaron en sus manos es un proyecto pequeño.  ¿Qué le habrías aconsejado?, ¿por dónde empezar?

Con respeto a tus propias opiniones me permito comentarte lo que yo le sugerí.

Mis preguntas
Antes de recomendar nada, le hice a mi amigo un par de preguntas. La primera de ellas fue: ¿Tienes un Project Charter? La constitución del proyecto o Project Charter es un documento en el que se esboza información importante del proyecto en términos del alcance, tiempos, involucrados, pero sobre todo, se establece claramente  la autoridad que adquiere el Project Manager sobre el equipo del proyecto y lo responsabiliza de tomar las decisiones que favorezcan a que el proyecto se termine dentro de las definiciones de alcance, tiempo, costo y calidad. Este documento, que debe estar firmado por el director de la escuela también sirve para definir el rol del director y otros interesados.

Mi segunda pregunta fue: ¿Tienes un WBS? La estructura de descomposición del trabajo o Work Breakdown Structure (WBS) es un documento que ayuda a descomponer el objetivo final del proyecto en partes más pequeñas y manejables y que puede ser usado no sólo para la planeación del proyecto, sino para el seguimiento, la presentación de avances y la definición de los responsables de cada paquete de trabajo. Con un WBS puedes saber cuánto costará el desarrollo de cada entregable y cuanto se retrasara el proyecto si una tarea se retrasa.

Desde luego que hay muchas otras herramientas que ayudan en la organización de un proyecto, pero para este caso y en general para proyectos pequeños elaborados en organizaciones informales o donde se tiene poco conocimiento del control de proyectos, estas dos herramientas son vitales. Los beneficios que traen, entre otros, son los siguientes:

  • Establece jerarquía dentro del equipo de proyecto
  • Comunica los acuerdos con respecto al alcance del proyecto
  • Define responsables por cada parte del proyecto
  • Identifica la parte emproblemada del proyecto

Adicional a estas dos herramientas yo agregaría un nivel mayor de detalle en las expectativas de calidad de cada curso. Hay tantas formas de hacer las cosas como participante en las actividades del proyecto, así que se requiere un estándar como punto de partida. La verificación de la calidad en los sistemas es muy sencillo, sólo es necesario establecer a un nivel aceptable de detalle cuales son las expectativas del usuario o cliente y verificar que el producto final cumpla con ellas.

Si se cuenta con las herramientas adecuadas de trabajo, seguramente se contará con un sistema que ayude en la elaboración de WBS y que permita agregar especificaciones por cada entregable, de tal manera que no se requeriría otra herramienta, sino solamente una disciplina por agregar la información allí y mantenerla vigente a lo largo del proyecto.

Aún más, debe establecerse un proceso de integración de cambios, esto es, un procedimiento por el cual se detalle cómo vamos a proceder cuando haya un cambio solicitado para alguno o varios de los entregables del proyecto. Comúnmente este proceso luce así:

  1. Un usuario solicita un cambio
  2. El cambio se recibe en un formato específico
  3. El cambio se evalúa y se pronostican los cambios en el enunciado de alcance, duración del proyecto y costo
  4. Se procede a la autorización del cambio.
  5. Si el cambio es autorizado por el equipo ejecutivo del proyecto, se integran los cambios en el WBS, Enunciado de Alcance, Cronograma, Documento de Riesgos, etc.
  6. Si se rechaza, se notifica a los interesados.

Mi amigo estaba muy bien familiarizado tanto con las herramientas como con los procesos a implementar, así que no fue difícil que supiera cuál era el siguiente paso a dar. Sin embargo me hizo una observación: “Cuando dominas las herramientas y técnicas de administración de proyectos es fácil caer en la tentación de establecer todo un complicado proceso de administración de proyectos cuando lo que necesitas es abrir los canales de comunicación, definir los roles y las responsabilidades de la gente y documentar los acuerdos de manera formal”.

¿Cuántas veces hemos sobredimensionado un proyecto sólo para hacer uso del software de administración de proyectos en el que nos acabamos de certificar?, ¿o sólo para implementar la metodología que utiliza aquella súper compañía que ha sido exitosísima a nivel mundial?

La administración de proyectos parte de la necesidad de hacer que el proyecto sea exitoso y es un medio para lograrlo, no el fin último de un proyecto. Si en el futuro te encuentras con un reto de este tipo o más complicado, te invito a contestar las siguientes preguntas: ¿Cuál es el objetivo final del proyecto?, ¿Qué puedo hacer para ayudar a conseguir el objetivo del proyecto?, ¿Cómo puedo usar mis habilidades y técnicas en administración de proyectos para conseguir el resultado esperado?

¿Qué recomendaciones le darías a mi amigo para la etapa de ejecución, control y cierre de su proyecto?

Por Fernando Valdez

 
© LiderDeProyecto.com - Todos los derechos reservados. "PMI" y el logo de PMI son marcas registras en los EUA y en otros países; "PMP" y el logo PMP son marcas registradas de certificación; PMBOK® es una marca registrada en los EUA y en otros países. CMMI® es una marca registrada en los EUA y en otros países por el Carnegie Mellon® Software Engineering Institute. UML® y OMG® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada en los EUA y en otros países por IBM Corp.