.png)
Imagine este caso: Usted es Director de Proyectos. Cuenta con mucha experiencia dirigiendo proyectos y siente verdadera vocación por esta actividad, que considera su profesión. Ya hace más de diez años que se certificó PMP®. Usted ha tenido continuas muestras de reconocimiento en sus proyectos, dentro y fuera de su empresa. Incluso ha impartido algún curso sobre fundamentos de gestión de proyectos, sobre gestión de riesgos, sobre la herramienta Microsoft® Project©, etc. También ha participado como voluntario en algún proyecto de PMI®, y le han invitado como ponente en un par de congresos. Todo parece indicarle que es un buen profesional, muy respetado. Cuando usted habla de algo relacionado con la gestión de proyectos, la gente le escucha con atención. Muchos colegas valoran su opinión experta.
Ahora acaba de cerrar su último proyecto y no está contento. Se trataba de un proyecto de consultoría para una gran empresa. El objetivo principal era posicionarse tecnológicamente por delante de la competencia. Los representantes del cliente tenían claro que no debían seguir igual, que debían cambiar, pero no sabían qué ni cómo. Asignaron un comité de expertos internos a la empresa, pero como no avanzaban se decidió contratar una empresa externa. Su empresa ganó el concurso gracias al enfoque orientado a la flexibilidad, adaptación y colaboración con el personal por parte del cliente y también gracias que los currículos de los miembros del equipo destacaban su experiencia en métodos ágiles.
En este proyecto, usted fue consciente desde el principio de que no iba a ser fácil elaborar un documento de requisitos completo, era improbable que el cliente lo aceptase formalmente. Tampoco podía comenzar trabajando una EDT, como es su costumbre. ¿Cómo evitar entonces la corrupción del alcance? La única información clara acerca del cronograma es que había ciertos hitos y el proyecto duraba nueve meses. Lo único claro sobre los costes era el número de horas contratado por perfil. Con tanta indeterminación, ¿cómo elaborar el plan para la dirección del proyecto? El cliente quería mantener reuniones de seguimiento bisemanales. ¿Cómo justificar los avances? Sus jefes le decían que no se preocupase porque los consultores de su equipo tenían mucha experiencia en proyectos parecidos, que confiara en que harían un buen trabajo.
Sin embargo, usted se preguntaba: Y entonces yo, ¿para qué estoy aquí?
Por supuesto, usted ya sabía muy bien para qué estaba usted allí. Le asignaron como director del proyecto por la misma razón que siempre: para echarle la culpa si el proyecto salía mal. Partiendo de esta certeza, usted tenía dos opciones: o bien dirigir el proyecto de forma predictiva (invirtiendo esfuerzo en elaborar un plan, tomando supuestos donde hubiera incertidumbre, haciendo que el cliente aceptase una línea base de requisitos, cronograma, coste, haciendo que los trabajos planificados se hicieran como estaba previsto, etc.) o bien dirigir el proyecto de forma adaptativa. La opción de esperar y ver qué hacía el equipo nunca ha sido una opción para usted.Sus colegas le advertían que este proyecto era adaptativo por naturaleza y no era sensato dirigirlo a la manera tradicional. Sin hacerles caso, usted se empeñó en documentar, en ceñirse al contrato y al plan de entregables, en usar una EDT, un sistema integrado de control de cambios, etc. Usted quería supervisar estrechamente el trabajo de los consultores, pero pronto descubrió que no podía seguirles. ¿Quizá debería haber atendido a esas reuniones que celebraban todos los días a las nueve de la mañana al lado de la máquina de café?
Usted se perdía sobre todo con la terminología que usaban. ¿Qué significarían esos términos tales como sprint, pila de producto, quemado de tareas, impedimento, retrospectiva, historias de usuario, etc.? ¿Por qué medían el tamaño de los requisitos en puntos de historia y no en esfuerzo? Tenían la pared llena de post-its, pero no conseguía que escribieran un documento de requisitos como usted quería. Cuando les preguntaba, nunca sabían decirle lo que iba a ocurrir más allá de las dos semanas siguientes. ¿Cómo podían trabajar sin un plan a más largo plazo? Un día, concretamente, les sorprendió jugando a las cartas y querían convencerle de que estaban trabajando… ¿pero dónde vamos a ir a parar?
Sorprendentemente, los representantes del cliente estaban contentos. Uno de ellos centralizaba la lista de requisitos, que cambiaba continuamente. Esta persona atendía a la presentación de avances bisemanal, junto con otros interesados, que podían variar. El equipo explicaba los resultados, y los interesados aceptaban o no, en ese mismo momento. Si algo no se aceptaba, tan solo se anotaba como pendiente, sin hacer ningún drama. Después de esa reunión, tenía lugar otra en la que hablaban del trabajo para las siguientes dos semanas, y justo después otra reunión del equipo sobre lecciones apredidas. En estas reuniones usted se sentía fuera de lugar, sin nada que responder, sin nada que aportar. A partir de cierto momento, dejó de asistir.
Sorprendentemente, el proyecto terminó en coste y en plazo y el cliente le llamó un buen día para felicitarle por el buen cierre que había realizado su equipo: Aunque quedaban temas pendientes, como eran de menor importancia, ya no les merecía la pena seguir empleando recursos por su lado, y también nos liberaban por el nuestro. Y no menos sorprendente resultó la satisfacción de los propios integrantes del equipo, como usted mismo pudo comprobar en la cena de celebración de fin de proyecto. Allí había surgido un equipo sinérgico y cohesionado, sin duda, listo para el siguiente proyecto sin apenas supervisión. Su empresa había experimentado un gran retorno en forma de crecimiento profesional y capacitación personal. Usted brindó por ello.
.jpg)
Así pues, el proyecto fue un rotundo éxito, pero usted no está contento. Tiene la sensación incómoda de que el proyecto ha sido un éxito no gracias a usted, sino a pesar de usted. Usted quiso imponer unos métodos contrarios al buen fin del proyecto, ahora se da perfecta cuenta. Por suerte, su equipo no le hizo caso, ahora reconoce que ellos tenían razón y usted no. También le incomoda pensar en el futuro próximo. Hoy día ya no es tan raro que los proyectos estén sometidos por naturaleza a continuos cambios en el alcance, y que exijan que los trabajadores del conocimiento entreguen el máximo valor posible en el menor plazo, ajustándose a las necesidades cambiantes del cliente. Es más, últimamente le está pareciendo que la gran mayoría de los proyectos son así.Su experiencia le dice que, también en este tipo de proyectos, usted podría aportar un gran valor con su experiencia en gestión. La próxima vez que tenga un proyecto adaptativo, usted ya no se mantendrá al margen:
- En el proyecto que acaba de terminar, el cliente centralizaba los requisitos, pero esto no es habitual. ¿No podría usted desempeñar este rol? ¿Cómo lo llamaban? ¿Product Owner? Pues venga, seamos Product Owner si así lo exige el proyecto.
- También ha habido suerte porque en este caso, el equipo ya estaba prácticamente formado. ¿Qué habría pasado si, como suele ser habitual, los miembros del equipo deben descubrir y crecer en su asignación particular durante el proyecto? Ya ha comprobado la ventaja de tener un equipo auto-gestionado, pero usted sabe que esto no ocurre por generación espontánea, hay que facilitarlo. Quizá un liderazgo servicial sea lo más aplicable en el contexto de los proyectos no predictivos. Siguiendo la teoría del liderazgo adaptado a la situación, le parece adecuado que su estilo atraviese las conocidas fases: 1) dirigir estrechamente; 2) coaching; 3) dar soporte y 4) delegar. Acompasadamente con estas fases de liderazgo, espera que su equipo atravesará las consabidas fases del modelo de Tuckman: 1) formación; 2) turbulencia; 3) normalización y 4) desempeño. Usted espera que lo más normal será llegar al estado 3) normalización, a partir de la tercera iteración. ¿Quizá sea buena idea que el rol de ScrumMaster vaya rotando entre los miembros del equipo desde la iteración 3? Esto fomentaría la aparición de un equipo auto-organizado. Comencemos el proyecto siendo ScrumMaster si es necesario.
- En este proyecto ha sido muy fácil el control de costes, no había un objetivo presupuestario muy restrictivo. Usted puede adaptarse a esos nuevos métodos para contabilizar costes y estimar plazos sobre la base de las iteraciones, es cálculo básico. Un cliente que necesite cumplir un objetivo de coste muy restrictivo, apreciará sus conocimientos de gestión por valor ganado (el sobrecoste hasta la fecha es de tantos miles de euros y como sigamos así, el sobrecoste final será de tantos otros miles de euros, tendríamos que tomar estas acciones para corregir la tendencia negativa, etc.)
- Sobre todo, alguien tendrá que encargarse de gestionar las expectativas de los interesados, asegurar que se cumplen los estándares impuestos por la PMO, gestionar para resolver impedimentos, anticiparse a posibles problemas, etc. Es decir: la gestión de proyectos de toda la vida.
.png&container=blogger&gadget=a&rewriteMime=image%2F*)
Los métodos ágiles han venido para quedarse. Ya se llevan practicando más de 15 años con notables resultados no solo en el campo de los proyectos de las tecnologías de la información, sino en cualquier proyecto del trabajador del conocimiento. Si usted se forma en Scrum, por ejemplo, ya tendría unos valiosos recursos para saber cómo comportarse en un proyecto adaptativo. A pesar de que los métodos ágiles tienen su origen en la gestión de productos, más que en la gestión de proyectos, esta brecha no parece difícil de salvar.
.png)
Hasta la fecha, PMI no ha editado un estándar para gestionar proyectos ágiles, y tampoco hay comunicación publicada en ese sentido. En su lugar, PMI se limita a recomendar una serie de once libros de referencia muy reconocidos sobre prácticas ágiles. Con tanta buena literatura ya disponible, quizá sea el enfoque correcto, si bien son libros muy enfocados en proyectos de tecnología de la información. Por otro lado, y por desgracia para los que no tenemos buen nivel de inglés, estos once libros no están traducidos al español, y peor aún, el examen PMI-ACP aún no cuenta con la ayuda de traducción al español. Por el momento el candidato a la certificación PMI-ACP debe prepararse para estudiar muchos libros y practicar muchas preguntas en inglés.
Actualmente hay muy pocos libros dirigidos a preparar el examen PMI-ACP, y que a la vez sirvan para divulgar los métodos ágiles para quienes no tengan la intención de certificarse. Ya llegarán. Mientras tanto, usted no puede esperar. Piense que en cualquier momento le va a tocar dirigir un proyecto adaptativo, y conviene estar preparado.
No hay profesión en el mundo más orientada a objetivos que la gestión de proyectos. Es esta una profesión muy poco agradecida. Si los objetivos se consiguen, como tenía que ser, para eso nos ponen al mando, nadie nos felicitará. Pero si no se consiguen, entonces la culpa es solo nuestra. Mientras todo vaya bien, nadie se quejará, pero si algo sale mal (y en los proyectos puede haber muchas cosas que salgan muy mal), de repente, todo el mundo habla de gestión de riesgos, escasa documentación, falta de liderazgo, auditorías de calidad, problemas de comunicación, ausencia de habilidades sociales, necesidad de coaching, etc. El resultado es siempre el mismo para el pobre Director de Proyectos: nos acusan de todo y no tenemos buena defensa.
Como pasa con el resto de áreas de conocimiento de gestión de proyectos, todo lo que necesita saber para gestionar proyectos adaptativos ya está inventado. Adaptémonos los Directores de Proyectos a esta forma de gestionar porque si no, cuando le acusen de gestionar un proyecto adaptativo como si fuera predictivo, deberá asumir que la culpa es solo suya.
Por: http://jose-barato.blogspot.com/2013/08/el-director-de-proyectos-agil.html#more
Visite: www.altus.com.co
