REVISTA PROIECTUS Nº 2

Número 2, Abril 2014

DIRECCIÓN DE PROYECTOS

ÁGILES

ENTREVISTA: MIKE GRIFFITHS, MIEMBRO DEL COMITÉ DE DIRECCIÓN CERTIFICACIÓN PMI-ACP

®

www.proiectus.es

LA VELOCIDAD, LA BOTELLA, LAS PELOTAS, LA ARENA… E ¿ITIL? LA GESTIÓN DE RIESGOS EN MEGAPROYECTOS GESTIÓN DE PRESUPUESTOS EN OBRA PÚBLICA

COACHING A EQUIPOS ÁGILES GESTIÓN DE PROYECTOS Y PROGRAMAS CON OPENPPM ISSN 2340-9363

www.proiectus.es

Número 2, Abril 2014

DIRECCIÓN DE LA REVISTA Iván Samuel Tejera Santana ivan.tejera@proiectus.es

EQUIPO EDITORIAL

ITPROIECTUS www.proiectus.es

COMUNICACIÓN Y DIFUSIÓN Antonio Martel Rodríquez Lucas Ferrera Hernández ASESORAMIENTO LEGAL Javier Rodríguez Batllori Laffitte TRADUCCIÓN Mónica Khiani Ashok

COLABORADORES Luis Antonio Salazar-Caraballo Davide Mazzanti Jose Barato Arroyo Antonio Domingo Medina Díaz Eduardo Gutiérrez Bahillo Mario Coquillat de Travesedo Antonio Pedro Dorta Alonso Agustín Tapia Quesada Manuel Vara González Alejandro Forcades Pons Mike Griffiths

2

www.proiectus.es

5

Número 2, Abril 2014

RESPUESTA AL CAMBIO SOBRE SEGUIR UN PLAN Luis Antonio Salazar-Caraballo, ISI Scrum Master

10

CÓMO CONVERTIR A TU PEOR CLIENTE EN TU MEJOR ALIADO Davide Mazzanti

13

EL DIRECTOR DE PROYECTOS ÁGIL Jose Barato Arroyo, PMP®, PMI-ACP®

18

EL CAMINO HACIA LA ORGANIZACIÓN ÁGIL Antonio Domingo Medina Díaz, CAPM®

22

GESTIÓN DEL PRESUPUESTO EN OBRAS PÚBLICAS Eduardo Gutiérrez Bahillo, PMP®

28

LA GESTIÓN DE RIESGOS EN MEGAPROYECTOS Mario Coquillat de Travesedo, PMP®, PMI-RMP®

31

LOS ROLES DE BELBIN Y LA DIRECCIÓN DE PROYECTOS Antonio Pedro Dorta Alonso, PMP®

38

JEFE DE PROYECTO, ¿Y AHORA QUÉ?

Antonio Martel Rodríguez, PSM® I

41

LA VELOCIDAD, LA BOTELLA, LAS PELOTAS, LA ARENA… E ¿ITIL? Agustin Tapia Quesada

46

COACHING A EQUIPOS ÁGILES Iván Samuel Tejera Santana, PMP®, PSM® I

49

LA IMPORTANCIA DEL PLAN DE PRIORIZACIÓN EN LA GESTIÓN DE LA CARTERA DE PROYECTOS Manuel Vara González, PMP®

54

ENTREVISTA: OPENPPM, HERRAMIENTA GESTIÓN DE PROYECTOS Y PROGRAMAS Alejandro Forcades Pons, Director General SM2 Baleares

58

ENTREVISTA: MIEMBRO DEL COMITÉ DE DIRECCIÓN DE LA CERTIFICACIÓN PMI-ACP® Mike Griffiths, PMP®, PMI-ACP® 3

www.proiectus.es

Número 2, Abril 2014

CARTA DEL DIRECTOR Bienvenid@s a este segundo número de la revista PROIECTUS, publicación MADE IN CANARIAS desarrollada por y para profesionales vinculados a la Dirección de Proyectos.

Han pasado cuatro meses desde la presentación oficial del primer número de la revista en las I Jornadas de Dirección de Proyectos. Desde entonces, las miles de impresiones en slideshare y el deseo de continuar potenciando la figura del Director de Proyectos se han constituido en nuestro aval para continuar apostando por el desarrollo de la revista.

Condicionados por la repercusión del primer número, en este segundo número hemos querido subir el listón dando la oportunidad de participar a un mayor número de profesionales, lo que sin duda nos ha permitido enriquecer los contenidos de la revista con una mayor calidad y heterogeneidad de artículos.

Director revista PROIECTUS Iván S. Tejera Santana

Síntoma de este crecimiento es el hecho de que más de un 90% de los colaboradores de la revista cuenta con algún tipo de certificación en Dirección de Proyectos, señal inequívoca de que estamos consiguiendo que Directores de Proyecto con experiencia compartan conocimiento con otros profesionales que se inician en la profesión.

Si en el anterior número pudimos entrevistar a la Jefa del Proyecto de Traducción de la Guía de Fundamentos para la Dirección de Proyectos PMBOK®5, en esta ocasión, contamos con la inestimable colaboración de Mike Griffiths, miembro del Comité de Dirección encargado de definir las habilidades, herramientas y técnicas que conforman los contenidos del examen PMI-ACP® (Agile Certified Practitioner).

Tod@s los que formamos el equipo PROIECTUS esperamos que este número os resulte igual de interesante que el anterior, a fin de cuentas, si la revista existe es gracias a vosotros.

Lo realmente importante no es llegar a la cima, sino saber mantenerse en ella.

4

www.proiectus.es

Número 2, Abril 2014

LUIS ANTONIO SALAZAR-CARABALLO, PSM® Consultor en Metodologías y Arquitecturas de Software de Intergrupo, en

Colombia. Conduce evaluaciones de la situación actual de los procesos de desarrollo de software y propone e implanta soluciones para la mejora de los procesos

de

TI,

incluyendo

estrategias

para

gerencia

de

proyectos,

administración de riesgos y manejo del entorno de los proyectos con marcos de gestión ágiles. Actualmente es agility champion de Intergrupo.

RESPUESTA AL CAMBIO SOBRE SEGUIR UN PLAN “Los planes tienen poca importancia, la planificación es esencial”. Winston Churchill

sino que perdería muchos otros, lo que podría golpear severamente sus márgenes de ganancia durante el primer semestre del año.

Para suerte de Natalia, el señor Pérez había hecho su tarea, ya sabía que debía actualizar las herramientas de software de mercadeo y ventas para soportar una promoción agresiva que debería estar al aire en la TV y en las redes sociales dos horas antes que la de su competidor.

BASADO EN HECHOS HISTÓRICOS Natalia es gerente de proyectos de una importante compañía proveedora de servicios de tecnología. Es la encargada de la operación en uno de los clientes más grandes de la empresa: un conglomerado de telefonía móvil.

Hacia el final de esta mañana la llamó el director de mercadeo de esa organización bastante alarmado: 

Natalia, te paso a Juan Pérez de móviles del Sur.



Hola Juan, ¿en qué te puedo ayudar?

Lo que siguió fue toda una perorata que inquietó a Natalia. El cliente le contó cómo durante la mañana se enteró de la Promoción Rumbo al Mundial Brasil 2014 que su más encarnizado competidor sacaría a la luz la noche de ese día. Pérez sabía que de no responder efectiva y rápidamente no solo dejaría de ganar cientos o miles de clientes,

Fuente: www.freedigitalphotos.net Autor: Vichaga Kiatying-Angs

5

www.proiectus.es

Número 2, Abril 2014

Mientras Pérez hablaba, Natalia revisaba rápidamente el proceso de control de cambio de la compañía y concluyó que podría entregarle una propuesta de trabajo que incluyera el impacto de la actualización del software en costo y presupuesto a su cliente pero solo hasta el día siguiente. Era inaudito, mientras Juan Pérez estaba buscando una respuesta ágil y eficiente que concluyera con un resultado de valor en las próximas 8 horas, Natalia se enfrentaba a la disyuntiva de seguir un proceso clásico de estimación a priori y modificación del plan de trabajo, previo análisis de impacto y de costos, que redundaría en una pérdida tanto para su compañía como para la de su cliente, o simplemente responderle firme y positivamente que cumpliría la meta establecida para las siguientes horas.

A través de este trabajo hemos aprendido a valorar: 

Individuos e interacciones sobre procesos y herramientas



Software funcionando documentación extensiva

sobre



Colaboración con el negociación contractual

sobre



Respuesta ante el cambio sobre seguir un plan

cliente

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

El resultado de este trabajo, fruto de la colaboración de 17 personajes reconocidos en la industria del software en 2001, serviría a Natalia como pilar fundamental para encontrar una solución de valor para su cliente. Los Valores y Principios Ágiles enfatizan en la importancia de colaboración e interacción en el desarrollo de software y, de otro lado, el trabajo creativo involucra comúnmente alguna forma de colaboración y puede entenderse como una interacción entre un individuo y un contexto sociocultural.

EL MANIFIESTO DE DESARROLLO ÁGIL DE SOFTWARE Por suerte para Natalia, ella también había hecho su tarea. En los últimos tiempos había empezado un proceso de transformación en sus equipos que incluía una forma de ver el mundo de manera distinta a como lo venían haciendo en la compañía. Se trataba de todo un ecosistema basado en una cadena de valores y principios que rompían con los esquemas tradicionales de hacer software.

Todo empezaba con el así llamado Manifiesto por el Desarrollo Ágil de Software o, simplemente, Manifiesto Ágil, el cual le daría la clave para ganar ese día:

Los proyectos tradicionales están plagados de equipos conducidos por gerentes, organizados en una estructura jerárquica con múltiples capas de autoridad. Esta gerencia es del estilo de “comando y control” y los roles se basan en tareas funcionales que, en el caso del software, son los programadores, los diseñadores, los analistas, etc. El trabajo se delega a los miembros del equipo por sus jefes. Las prácticas en estos equipos incluyen

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros.

6

www.proiectus.es

Número 2, Abril 2014

copiosa documentación, especificaciones previas y planeación detallada. Las líneas de comunicación son indirectas entre las distintas capas de la jerarquía organizacional y el empoderamiento es algo invisible para la mayoría de los participantes, lo mismo que el estado general del proyecto.

Recordó así uno de los Principios acompañaban a esos valores ágiles:

que

PRINCIPIO ÁGIL #1 “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor”

El primero de los valores “Individuos y sus interacciones”, le indicaba a Natalia que necesitaba un equipo cooperativo, multifuncional y auto-suficiente, experto, altamente productivo y creativo que se comunicara con su cliente y trabajara con él el resto de la tarde, no solo en la extracción de conocimiento típica de los proyectos actuales, sino en todo el ciclo de producción que le permitiera a Móviles del Sur poner en funcionamiento una solución automatizada que soportara su ambicioso programa de retención y captura de clientes con motivo del evento mundialista de los próximos meses.

Natalia sabía que la filosofía ágil tiene la habilidad de amplificar la productividad de los equipos de software hasta una escala de gran magnitud, a través del empoderamiento de las personas, fomentando un entorno orientado-al-equipo y enfocándose en la transparencia del proyecto y en los resultados. Estos proyectos pasaron de ser dirigidos-por-el-plan a estar enfocados en el producto, uno priorizado por y de valor para el cliente. Estos equipos se identifican a sí mismos como una unidad social dentro de la organización de la cual hacen parte y a quienes se les confía la ejecución del trabajo y se les proporciona el entorno y el apoyo que necesitan, para mantenerlos motivados, como invoca otro de los principios del Manifiesto Ágil, y para aumentar su apego emocional a la empresa.

Si bien se trata de un conjunto de Valores, el último de estos, pero no por eso menos importante, no devalúa la planificación, en la práctica solo se adhiere al plan. La planificación es valiosa en sí misma; y dado que el plan nos asiste en la tarea de reconocer cuándo las cosas han cambiado, también nos ayuda a entender las implicaciones del cambio, cómo tenemos que ajustarnos y cuál es el costo probable. Lo importante es que, a medida que hacemos planes, entendamos que el plan puede cambiar.

Fuente: www.freedigitalphotos.net Autor: Salvatores Vuono

7

www.proiectus.es

Número 2, Abril 2014

La planificación es una actividad continua que incluye: •

Reuniones de planificación de iteración

•

Reuniones diarias

•

Reuniones de revisión

•

Retrospectivas

•

Evaluación de riesgos

producción. Si son bien manejados, los cambios brindan muchos beneficios a los usuarios, el primero de ellos, ventaja competitiva.

Los cambios son una herramienta invaluable para crear productos inmejorables.

Planificación clásica vs Planificación ágil Cada una de esas ceremonias sirve no solo para planear sino también para inspeccionar el estado del proyecto y crear mecanismos de adaptación en caso de ser necesario. El grueso de los practicantes de la industria y quienes la miran desde los tejados, cree que los equipos ágiles son desorganizados, informales, que no documentan y sobre todo que no planean. Todo eso se debe en parte a la mala lectura que le dan al mismísimo Manifiesto Ágil. Pero no es así. Contrario a lo que ocurre en los modelos tradicionales de planificación, donde se planea al comienzo, se elaboran planes de dos, tres o más niveles, y se hace seguimiento a ese plan durante el resto del proyecto, un seguimiento que raya en el acoso, los equipos ágiles planean todos los días.

Fuente: www.freedigitalphotos.net Autor: hin255

Era precisamente lo que necesitaba Juan Pérez ese día. Otro de los principios ágiles llevó a Natalia a esa conclusión: PRINCIPIO ÁGIL #2

En parte eso se debe a que los equipos ágiles saben que los cambios hacen parte inherente, son constituyente primario del ADN, del ciclo de vida del software. Los cambios pueden ocurrir en cualquier momento, desde las etapas iniciales del proyecto, aun cuando apenas se están conociendo las necesidades del usuario, hasta las fases tardías del proyecto, quizás cuando estamos a punto de salir a

“Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente” En cambio, los enfoques tradicionales de gerencia de proyectos presentan los cambios como un monstruo con el que hay luchar a sangre y fuego. Los procedimientos rigurosos de control de cambio, típicos de estos 8

www.proiectus.es

Número 2, Abril 2014

enfoques, causan la pérdida de oportunidad que los clientes tienen para ganar más mercado y para crear mejores productos. En general, a medida que el tiempo avanza, la habilidad de hacer cambios disminuye y cuesta más. Esto es lo que enfrentan los procesos ágiles, aunque sin dejar de planear.

Los métodos ágiles promueven planes más livianos y de alto nivel a largo plazo, mientras que atienden la elaboración de agendas bien detalladas a corto plazo, las de la iteración actual, que solo tarda unos pocos días o muy pocas semanas. En Scrum, por ejemplo, las iteraciones tardan máximo cuatro semanas y con frecuencia mucho menos que eso.

resonancia no solo en su cliente sino en sus usuarios, uno que haga que la gente experimente distintas reacciones de gozo al usarlo, sin hablar de los ingresos en que redundaría su uso. No se trataba solo de actualizar un pedazo de software existente, sino de producir algo no ordinario que tuviera la capacidad de atraer a una audiencia cada vez mayor. Otro de los principios ágiles fue el último consejo que le dio al equipo antes de despedirlo hacia lo que seguramente sería un éxito total: PRINCIPIO ÁGIL #10 “La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial”

Al principio de los proyectos ágiles se planean las entregas o salidas a producción tempranas, beneficio primario que nos traen los procesos ágiles. Estas salidas a producción pueden ser cada tres meses, pero hoy contamos con la tecnología y plataformas lo suficientemente maduras como para hacer continuous delivery o entregas continuas. Amazon, por ejemplo, la vendedora al detal más grande del mundo, sale a producción cada 11,6 segundos, algo absolutamente asombroso si tenemos en cuenta la cantidad de clientes recurrentes simultáneos que tiene su sitio Web cada segundo. Natalia sabía todo eso, entonces no dudó que podía tener un producto funcionando para antes de las 8 de la noche de ese día, meta principal de su cliente.

REFERENCIAS (1) Mitos, monstruos, leyendas urbanas y otros desvaríos de ágil y scrum.

(2) Planificación del sprint: el primer paso para producir el máximo efecto.

(3) Compendio sobre el scrum diario.

(4) Cultura ágil: ese oscuro objeto del deseo.

(5) Sí, usted está listo para implementar un proyecto ágil.

Resultado final Mientras hacia un recorrido por los acontecimientos de la hora, Natalia convocó a un equipo idóneo, uno que sabía capaz de elaborar un producto que generara 9

www.proiectus.es

Número 2, Abril 2014

DAVIDE MAZZANTI Project Manager para Teléfonica y Vodafone.

Business Engineer, graduado por la Universidad de Bologna, ha desarrollado su carrera profesional entre las ciudades de Las Palmas de Gran Canaria, Milán y Alemania. Experto en innovación.

CÓMO CONVERTIR A TU PEOR CLIENTE EN TU MEJOR ALIADO INTRODUCCIÓN

en el menor tiempo posible. Pero a menudo sucede que las cosas se complican bastante y la relación con nuestro cliente termina convirtiéndose en una pesadilla. ¿Cómo solucionarlo? Y mejor todavía, ¿cómo evitarlo desde el principio?

La primera y única clase de baile que tuve en mi vida me enseñó una lección bastante importante. El profesor nos explicó que el baile es cosa de dos. Da igual que seas el mejor bailarín de este mundo, si no tienes una buena complicidad con tu pareja tu actuación está destinada al desastre.

MIEDO AL CAMBIO El cambio es un estado traumático. ¿Quién recuerda el pasaje de la infancia a la adolescencia como un momento sereno de su vida? Como seres humanos solemos preferir estabilidad y situaciones que podamos controlar. Mientras que el cambio nos obliga a salir de nuestra zona de seguridad, nos expone a nuevos problemas y a nuevas amenazas.

La misma lección la podemos aplicar a la gestión de proyectos, asociando un proyecto a un gran baile. En el escenario hay un amplio grupo de bailarines siguiendo una coreografía, pero al centro de la atención se encuentran el Project Manager y el cliente.

Estos dos bailarines son los responsables de la actuación, y de ellos depende el éxito de la misma. Es muy importante que entiendan desde el principio que luchan por un mismo objetivo. Ambos van a tener que aprender cómo moverse al unísono para conseguir una óptima representación.

Como Project Managers estamos acostumbrados a estas situaciones, y posiblemente incluso nos guste esa sensación de miedo cada vez que nos adentramos en un nuevo proyecto. Vamos a tener que ser muy empáticos para no olvidarnos de que nuestros clientes no viven el cambio con la misma seguridad que nosotros. Es bastante probable que lo vivan con incertidumbre, y

Como Project Managers sabemos que nuestro cliente es nuestro stakeholder más importante. Sabemos también que tenerlo de nuestro lado significa poder desarrollar nuestro proyecto de la forma más eficiente y 10

www.proiectus.es

Número 2, Abril 2014

con una emoción que en los adultos suele manifestarse con agresividad y frustración.

Pero antes de proclamarnos mejores amigos de nuestro cliente vamos a tener que ganarnos su confianza.

Estas emociones son las principales causas de las malas relaciones entre Project Manager y cliente. Aunque creamos tener el proyecto perfectamente controlado, si el cliente no se encuentra cómodo con nosotros encontrará la forma de complicarnos la vida.

Es posible que empiece a cuestionarnos cualquier decisión, nos bloquee las obras o que incluso vaya a quejarse de la gestión del proyecto a nuestros superiores. Son señales de que no hemos dedicado suficiente tiempo a conocer a nuestro cliente, limitándonos a trabajar en los aspectos más concretos del proyecto.

FALTA DE CONFIANZA A menudo se nos olvida que cada día llevamos puesto un uniforme. No es tan llamativo como la divisa de un policía o de un paramédico, pero igualmente nos identifica de forma inequivocable. Mientras nos estamos encargando de la dirección de un proyecto nos convertimos en la cara pública de nuestra empresa.

Esta posición puede resultar bastante incómoda, sobre todo si nos paramos a reflexionar sobre la reputación de nuestra empresa en el mundo exterior. Si es una empresa grande, posiblemente haya cometido algún fallo en el pasado o haya salido en la prensa por alguna situación embarazosa. Puede suceder también que nuestra empresa sea más pequeña y no tenga una gran relevancia pública. En ambos casos heredamos una carga negativa que nos penaliza incluso antes de empezar.

Para evitar que todo esto ocurra, vamos a asegurarnos de que le acompañamos a lo largo del proceso de cambio. Vamos a ser su ancla, su estrella polar. Nos convertiremos durante todo el proyecto en el punto de referencia para cualquier asunto relacionado con el mismo. Y deberemos tener los ojos bien abiertos para captar cualquier señal de frustración e inseguridad.

Antes de intentar ganarnos la confianza de nuestro cliente vamos a tener que esforzarnos en superar el muro de prejuicio que nos separa. ¿Cómo? Aprovechando esa divisa que llevamos puesta y convirtiéndonos en el único punto de contacto entre el cliente y cualquier necesidad pueda tener con relación a nuestra empresa.

Digamos que nuestro cliente necesita un certificado emitido por nuestro departamento de administración o que no está satisfecho con algún trabajo realizado antes de nuestra llegada. Ambos ejemplos tocan temas que están fuera de nuestra jurisdicción como 11

www.proiectus.es

Número 2, Abril 2014

Project Managers pero no están fuera de nuestro alcance como representantes de la empresa. En vez de ignorar las peticiones del cliente podemos involucrarnos para ayudarle a solucionar sus problemas gracias a nuestros contactos internos. No importa lo sencilla o complicada que sea una determinada tarea: vamos a convertirnos en la única interfaz a la que tendrá que acudir.

Por eso mi consejo es dedicar todo el tiempo necesario a la gestión del cliente. Cada hora destinada a estrechar nuestra relación con él es una inversión a largo plazo sobre la estabilidad del proyecto. Mientras más nos apoye, más delegará en nosotros la ejecución de las diferentes fases del proyecto, sin cuestionar los detalles. Su fe en nuestra profesionalidad le ayudará a mantenerse al margen de la operatividad.

La parte difícil está en la superación del binomio Project Manager/Alcance del proyecto. Vamos a tener que salir de nuestro pequeño entorno delimitado por las fronteras del proyecto y extender nuestro radio de acción a toda la empresa. De esta forma le estaremos restando complejidad al cliente, dejando que se enfoque únicamente en los temas importantes. Lentamente veremos que su confianza en nuestra habilidad de solucionar problemas irá creciendo.

No debemos olvidarnos de informarle tempestivamente apenas surja cualquier obstáculo y de prepararle detallados informes de seguimiento durante las fases más críticas. La confianza es un bien muy valioso, que cuesta mucho esfuerzo conseguir y que podemos perder en pocos segundos si no tenemos el suficiente cuidado.

En definitiva, el clásico error de muchos Project Managers es centrarse en las metodologías y olvidarse de quien les rodea.

Al estar rodeados por tablas de excel, diagramas de Gantt y Backlog de productos tienden a olvidarse de que los proyectos no son solo datos y fórmulas.

Son principalmente personas, con todas sus fortalezas y debilidades.

EL MEJOR ALIADO Fortalecer la relación con nuestro cliente puede ayudarnos a descubrir algunos detalles de la organización que se mueve detrás de él. No es de sorprender que muchas de las inversiones de ruta a mitad de un proyecto no sean decisiones directas de nuestro cliente, sino el resultado de discusiones internas en la empresa.

Nuestras habilidades más intangibles, o soft skills, son iguales de importantes que nuestra aplicación de las correctas metodologías de gestión de proyecto. Con la dificultad adicional de que no podemos simplemente pedir que los demás crean en nosotros. Cada vez que empecemos un nuevo proyecto vamos a tener que volver a ganarnos la confianza de nuestro nuevo cliente.

Conocer los detalles de su organización, cómo se mueve y con qué ritmo se toman las decisiones, es un valioso recurso que nos ayuda a reducir el riesgo y tomar las adecuadas medidas preventivas. Gracias a esta información, nuestro cliente nos está regalando tiempo extra para prepararnos cada vez que haya un eventual cambio de programa.

12

www.proiectus.es

Número 2, Abril 2014

JOSE BARATO ARROYO Jose Barato es el Director de PMPeople, empresa especializada en formación,

consultoría y gestión de proyectos. Desde 2009, participa en el proyecto opensource TALAIA OpenPPM, consistente en la creación, difusión y servicio sobre un producto de software libre para gestionar proyectos, programas y portfolios consistente con los estándares de PMI.

EL DIRECTOR DE PROYECTOS ÁGIL 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 a 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.

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.

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 13

www.proiectus.es

Número 2, Abril 2014

Sin embargo, usted se preguntaba: Y entonces yo, ¿para qué estoy aquí?

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?

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é?

Fuente: commons.wikimedia.org Autor: Hkniberg

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 aprendidas. En estas reuniones usted se sentía fuera de lugar, sin

Usted se perdía sobre todo con la terminología que empleaban. ¿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, 14

www.proiectus.es

Número 2, Abril 2014

nada que responder, sin nada que aportar. A partir de cierto momento, dejó de asistir.

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í.

Sorprendentemente, el proyecto terminó en

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: Pero el ritmo vertiginoso al que se mueve el mercado en el que operan hace que las estrategias de cambio que necesitan implementar las organizaciones para mantenerse en vanguardia, o no quedarse atrás, magnifica el impacto de la falta de conexión entre las estrategias y las operaciones del día a día.

Fuente: commons.wikimedia.org Autor: Rakuten, Inc.

coste y en plazo y el cliente le llamó un buen día para felicitarle por el buen trabajo 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.

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.

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 15

www.proiectus.es

Número 2, Abril 2014

• 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 (PO)? Pues venga, seamos Product Owner si así lo exige el proyecto.

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.)

• 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-organizado, 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 sea 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.

• 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.

Con la certificación PMI-ACP® PMI Agile Certified Practitioner (Practicante Certificado en Agile por PMI), PMI está consiguiendo que el Director de Proyectos vuelva a ser la figura central de los proyectos adaptativos.

Para conseguir esta acreditación, el candidato debe demostrar que ha practicado proyectos ágiles, por supuesto, pero quizá sea más importante que debe demostrar que tiene un conocimiento estructurado sobre las técnicas, herramientas, conocimientos, habilidades y actividades necesarias en proyectos ágiles. Algunas prácticas ya las habrá aplicado, y el resto de prácticas

• En este proyecto ha sido muy fácil el control de costes, no había un objetivo presupuestario muy restrictivo. Usted 16

www.proiectus.es

Número 2, Abril 2014

referenciadas sabría aplicarlas, si se diera el caso.

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 formación, etc. El resultado es siempre el mismo para el pobre Director de Proyectos: nos acusan de todo y no tenemos buena defensa.

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 PMIACP debe prepararse para estudiar libros y practicar 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

17

www.proiectus.es

Número 2, Abril 2014

ANTONIO MEDINA Ingeniero Superior en Computer Systems por la Universidad de Birmingham (Reino Unido, 2007), Máster en Information Systems and Management por

Warwick Business School (Reino Unido, 2010) y Máster en Consultoría y Asesoramiento a Empresas por la Escuela de Organización Industrial (España, 2011). Está certificado como ITIL Expert, Certified Associate in Project Management por PMI, Integración de Procesos por SAP y como Lean IT Expert.

EL CAMINO HACIA LA ORGANIZACIÓN ÁGIL Poco a poco estamos viéndonos inmersos en la vorágine del pensamiento Agile. Ahora, más que nunca, los datos demuestran que por fin este concepto comienza a desplazar a ideas más clásicas de gestión de proyectos, basadas en modelos predictivos y en el control exhaustivo de planes de proyecto estáticos y de largo plazo. Ideas afianzadas desde hace tiempo y que casi se consideraban como dogmas. Sin embargo, los últimos datos publicados en la séptima encuesta anual sobre Agile Development, llevada a cabo precisamente por PMI (principal impulsor y defensor de metodologías de gestión de proyectos predictivas), muestran que las empresas han incrementado sus planes de implementar Agile del 59% en 2011 al 83% en 2012 (y la tendencia sigue in crescendo).

Aunque a todos nos suena muy bien, conseguir estos resultados es otra historia diferente, que pocas veces se alcanzan y que dependen principalmente del compromiso que estas organizaciones estén dispuestos a asumir en el cambio hacia un modelo Agile.

Precisamente, uno de los principales escollos que suelen padecer estas organizaciones, que intuyen que quieren hacer Agile pero no conocen los detalles de qué tienen que hacer para conseguirlo, suele ser que no tienen claro el propósito ni el alcance de cada uno de los conceptos que se engloban en este pensamiento.

Tal y como Mary Poppendieck comenta en su obra sobre Lean Software Development, tanto Lean como Scrum comparten muchas características, incluyendo el énfasis en el cliente y la gestión de tareas de forma visual, pero tanto uno como otro, difieren en dos áreas principales: alcance y foco. Desde luego, el ámbito de actuación de Scrum y de Lean combinados puede abarcar todas las capas de actividad de una organización, pero por sí sólo Scrum no establece los mecanismos para introducir la mejora continua, el liderazgo de los empleados ni el

¿Y por qué las empresas, principalmente las americanas, están adoptando estos modelos nuevos de pensamiento? Los principales beneficios esperados que citan los encuestados de la encuesta anterior son un menor time-to-market, la optimización de la gestión de prioridades en entornos cambiantes, y un mejor alineamiento y entendimiento entre la TI y el negocio.

18

www.proiectus.es

Número 2, Abril 2014

análisis de desperdicios, ni Lean es el mejor candidato para conseguir alcanzar un enfoque ágil de desarrollo como el planteado por Scrum o XP.

establece un marco de trabajo ni una metodología, sino que analiza de forma continua los procesos, tanto el de desarrollo, como el resto de procesos implicados, que apoyan o que alimentan el desarrollo tanto como entrada o como salida (Compras, Service Desk, QA, etc.) e intenta descubrir los focos de ineficiencias de extremo a extremo del proceso. En este caso, Lean se centra en analizar el entorno e intentar facilitar que cualquier proceso fluya sin interrupciones, aspirando a conseguir la excelencia operativa de toda la organización.

Lean afecta a toda la organización, desde el origen de la demanda hasta la puesta en producción y la aceptación de la petición y a todos los niveles (prácticas, organización y políticas y principios).

OBJETIVOS DE SCRUM Y DE LEAN Pero empecemos por el principio. ¿Para qué sirve, o qué objetivos tiene Scrum? ¿Y Lean?

Scrum es un marco de trabajo bajo el cual se define una metodología de desarrollo ágil, iterativo e incremental. Es decir, se centra exclusivamente en conseguir mejorar las entregas de proyectos de desarrollo de sistemas de información. En comparación con otras metodologías de desarrollo de software, aporta el valor importantísimo de incorporar varias entregas o prototipos antes de la entrega final que se van entregando y aceptando por iteraciones, llamadas sprints, por parte del cliente, gestionando sus expectativas y negociando los requerimientos de forma periódica y consiguiendo que el desarrollo de software deje de ser una caja negra para los usuarios finales y un horizonte interminable para los desarrolladores. Con esto el riesgo de un “¡Pero si esto no es lo que había pedido!” se minimiza en mayor medida, ya que se va presentando de forma periódica al cliente prototipos del producto final. Scrum propone, de manera similar a Lean, realizar reuniones rápidas diarias operativas para fijar objetivos diarios y reuniones de retrospectivas (que en Lean se podría trasladar a la reunión semanal de seguimiento de mejoras). Por lo tanto, Scrum se centra y daría respuesta a las necesidades de mejorar las actividades de la capa de desarrollo de proyectos de TI.

QUIERO HACERLO: DÓNDE COMIENZO Y CÓMO Entonces, cuando una organización se plantee comenzar la andadura hacia la eficiencia y la mejora continua, ¿por dónde debería empezar? ¿Por Lean o por Scrum? ¿Y existe algún camino lógico por el que realizar

Lean en cambio, tiene un alcance más amplio y es más transversal que Scrum. Lean no 19

www.proiectus.es

Número 2, Abril 2014

esta andadura y por el que nuestras inversiones tengan un objetivo en el tiempo?

metodologías de gestión para responder a entornos con un alto componente de cambio.

Es en ese momento, cuando el nivel de madurez de la filosofía Lean ha conseguido penetrar en la cultura de la empresa y en la mentalidad de las personas, donde estos mismos equipos son los que proponen y aspiran a adoptar Scrum para sus proyectos de desarrollo. Y el Tablero de Mejoras de Lean se convierte en la herramienta de seguimiento perfecta para que se consiga esta implantación de forma gradual, ya sea a través de un piloto en una entrega o empezando con algún proyecto pequeño y de bajo riesgo para el negocio. Así mismo, al incorporar Scrum, se incorporan las retrospectivas, que se realizan al final de cada Sprint o iteración y donde se analiza qué ha ido bien, qué ha ido mal y que se podría mejorar para la siguiente entrega.

Cualquier iniciativa de mejora que se detecte en estas retrospectivas encuentra de forma natural también un mecanismo para gestionar y llevar adelante estas mejoras en el Tablero de Mejoras.

De nuevo, para tomar esta decisión, entra en juego el alcance y el foco. Un equipo gestionado por Scrum tendrá el potencial para mejorar la entrega en proyectos y aumentar la satisfacción del negocio, pero sólo realizará retrospectivas para mejorar únicamente su ciclo de desarrollo. Por sí sola, la metodología de Scrum no da pie inicialmente a desarrollar ideas que puedan mejorar la eficiencia operativa de la organización a través de toda su cadena de valor, sino que su alcance se centra exclusivamente en el proceso de desarrollo.

Por lo tanto, y desde la experiencia que hemos adquirido en nuestra Firma en transformaciones Lean, el camino más lógico para cualquier organización debería ser el de comenzar con Lean.

A través de las iniciativas Lean se establecen una serie de mecanismos para la introducción, gestión y seguimiento de la mejora continua en todos los ámbitos de la cadena de valor de una empresa o de un departamento de TI. Estos mecanismos no dejan de ser sino los ya conocidos Tableros de Mejora, donde con una frecuencia periódica, un Lean Coach (o Facilitador) dirige a los equipos Kaizen (o de Mejora) hacia la consecución de una serie de pequeños proyectos de mejora para conseguir elevar el valor entregado al cliente (el cual puede venir dado en función de tiempo, calidad o coste).

La conclusión es que, efectivamente, no sólo Lean y Scrum tienen muchas cosas en común, sino que siguiendo un camino homólogo al explicado en los párrafos anteriores se puede conseguir combinarlos y aprovechar tanto la mejora continua a nivel departamental u organizacional como obtener los beneficios de entregas más rápidas y con una mayor aceptación del usuario que provee Scrum.

Lejos quedan ya los días en que la empresa era la única responsable de la formación de sus trabajadores. Aunque aún quedan empresas que siguen realizando esta práctica, las circunstancias actuales han

Una vez establecidos estos Tableros de Mejora, hemos encontrado que en varios equipos Kaizen se produce una evolución natural hacia la mejora de la eficiencia de sus 20

www.proiectus.es

Número 2, Abril 2014

provocado que éste no sea un hecho habitual. Por tanto, para mantenerte actualizado debes ser tú quien tome las riendas de tu educación.

(Quality assurance, despliegues, bases de datos, etc.), logrando tener equipos que representen la Cadena de Valor de la TI. Todo esto son pequeños pasos en un camino mucho más largo, que incluso hoy por hoy sigue construyéndose a través de la innovación abierta y compartida que en los últimos años se ha extendido a través de comunidades de práctica globales. Sin ir más lejos, en el European Lean IT Summit celebrado este año en París, Steve Bell, una de las principales referencias en esta área, introdujo los próximos retos que Lean IT debe abordar: la incorporación de los ERP en las iniciativas Lean y su escalado hacia los niveles de dirección a través de salas de mando o de control conocidas como salas Obeya.

ASPIRANDO A MÁS: COMBINANDO LEAN, SCRUM… Y AGILE PROJECT MANAGEMENT Si el foco de Lean está en la excelencia operativa a nivel organizacional y el de Scrum en agilizar los proyectos de desarrollo, el de Agile Project Management está en habilitar la gestión de proyectos basados en Scrum y que se ejecuten en organizaciones Lean. Agile Project Management reduce sustancialmente el peso del plan en favor de la gestión de prioridades cambiantes y está mejor adaptado a este nuevo pensamiento.

Introducir Agile Project Management requiere un nivel de madurez en pensamiento Agile elevado, al igual que con el caso de Scrum, y podría ser un buen enfoque abordar la implantación de ambos de forma unísona.

No todas las empresas están preparadas para adoptar este modelo, especialmente si se duda de que el compromiso sea firme y no existan sponsors o campeones con influencia para que se realice esta visión. No en vano, las principales barreras para adoptar enfoques Agile siguen siendo las de siempre (obtenido de la séptima encuesta anual sobre Agile de PMI): resistencia al cambio, culturas corporativas diametralmente opuestas a este pensamiento y transformaciones incompletas o que se abandonan a mitad de camino y que no logran explotar el verdadero potencial del modelo mostrado. Para concluir, nuestra recomendación, que sirve para cerrar el círculo de este artículo, sería empezar por Lean para introducir un cambio disruptivo y transversal, y gradualmente, sus equipos comenzarán a adoptar otras técnicas ágiles como Scrum por propia iniciativa (como una mejora generada desde Lean).

Existen técnicas y herramientas para dar soporte y apoyar este modelo que combina Lean, Agile Project Management y Scrum. La gran mayoría son herramientas de gestión visual compartidas como los Tableros Kanban o Diarios – que pueden ser tanto físicos como virtuales -, sobre las cuales se reporta el avance del día anterior y se estima el del día vigente. Sobre estos datos el Scrum Master o el Jefe de Proyecto puede desarrollar gráficas de trabajo pendiente para cumplir con la fecha de entrega de la iteración, conocidas como gráficas Burndown. Y sobre todo, los equipos de proyecto han de convertirse en equipos integrados Dev/Ops, es decir, equipos que combinen roles de desarrollo con roles relacionados con las operaciones

21

www.proiectus.es

Número 2, Abril 2014

EDUARDO GUTIÉRREZ BAHILLOngeniero de Caminos, Canales y Puertos por Jefe de Obra Senior en Ferrovial Agroman certificado como Project Management Professional (PMP). En sus casi 15 años de desarrollo profesional ha estado

involucrado en diversos proyectos de construcción, tanto para clientes públicos como para privados. Actualmente desempeña el puesto de Gerente de la UTE Adeje -Santiago del Teide, encargado del tramo sur de las obras del Anillo Insular de Tenerife con un presupuesto de 190 millones de euros.

GESTIÓN DEL PRESUPUESTO EN OBRAS PÚBLICAS INTRODUCCIÓN

Para enmarcar más adecuadamente este artículo nos referiremos a la mayoría de los contratos de obra que se firman con la administración y que suponen el compromiso de ejecutar una obra con un diseño que, previamente ha sido aprobado por la administración y que el contratista se encuentra como punto de partida de su contrato.

Este artículo surge como continuación del titulado “Dirección de proyectos en obra pública” publicado en el primer número de la revista PROIECTUS. Entre las responsabilidades del Jefe de Obra, como director de proyecto de construcción perteneciente a la empresa contratista, se encuentra la gestión del presupuesto, así como el control de los costes y la optimización de la cuenta de resultados de la obra asociada al proyecto.

Recordamos de nuevo que este sector está fuertemente regulado por la Ley de contratos con el Sector Público [1], ya que la financiación para el desarrollo de estos proyectos es de carácter público y tiene que atender a principios fundamentales del derecho y buen uso de los recursos públicos.

Así pues, el artículo se ciñe a las responsabilidades del contratista, que, dentro de los parámetros que fija la ley y sobre los que entraremos más en Autor: Eduardo Gutiérrez Bahillo detalle, se encuentra con el difícil reto de Para explicar cómo convertir en rentable una empresa que, a afecta la normativa por la que se rigen las priori, no lo es, por los motivos que administraciones públicas a algunas de las señalaremos a lo largo de este escrito. fases de la dirección de proyectos tomaremos 22

www.proiectus.es

Número 2, Abril 2014

como referencia contratos de servicios de más de 60.000 €, para los cuales la Ley de Contratos del Sector Público garantiza los principios de publicidad y concurrencia a través de procedimientos abiertos. Para contratos de menor cuantía, aunque no están obligadas a ello (los suelen hacer por mera eficiencia administrativa), las administraciones públicas suelen optar por procedimientos negociados sin publicidad o compras directas (cuando los importes están son inferiores a 18.000 €).

PROCEDIMIENTO DE PUNTO DE PARTIDA

ADJUDICACIÓN.

Precios unitarios

•

Presupuesto total

De la multiplicación de las mediciones por los precios unitarios, resulta el PEM (Presupuesto de ejecución material). Además del PEM, se establece en el presupuesto un porcentaje de Gastos Generales, que se supone que son los Costes no asociados directamente a las unidades de obra, como pueden ser, equipo del proyecto, oficinas, preparaciones de terrenos, vallados, sistema de calidad, etc…

Los Gastos Generales vienen fijados en el presupuesto y oscilan entre el 12-18% del PEM. El otro porcentaje que se añade es el Beneficio industrial, que recoge la lícita pretensión del contratista de lucrarse con la ejecución del contrato. Normalmente, el Beneficio Industrial es del 6%. Veremos más adelante que este concepto es idílico y no atiende a la realidad.

EL

Toda esta aventura de la construcción comienza con la adjudicación del contrato de obra.

Destaco, nuevamente, la naturaleza del contrato y los criterios para su adjudicación, generalmente mediante concurso público.

Estos criterios se basan en los principios de publicidad, libertad de acceso a las licitaciones, transparencia de los procedimientos, no discriminación, igualdad de trato entre los candidatos, capacidad y méritos de los licitadores, todo ello orientado a la salvaguarda de la libre competencia y a la selección de la oferta económica y técnicamente más ventajosa.

Así pues, una vez aplicados los porcentajes mencionados más el IVA se obtiene el PEC (Presupuesto de ejecución por Contrata) Ahora bien, lo que más puede llamar la atención del lector, es que de todos los elementos mencionados, los contractuales son los precios unitarios y el presupuesto total.

Las mediciones no son contractuales.

En el momento de la licitación, el documento clave es el diseño del proyecto, y dentro de la gestión económica, el presupuesto asignado a ese diseño.

Los precios unitarios son los que se aplicarán a las unidades realmente ejecutadas que aparecen en el diseño.

En el presupuesto figuran, de manera resumida, los siguientes documentos: •

•

El presupuesto total se emplea para estimar la cantidad total que la administración gastará en el proyecto, así como para limitar,

Mediciones.

23

www.proiectus.es

Número 2, Abril 2014

en los términos que establece la ley, el coste total del proyecto.

administración, las ofertas económicas que se presentan están por debajo del coste real y no es raro encontrar rebajas del 30% en las presentaciones de las ofertas.

BAJA EN LA ADJUDICACIÓN DE OBRAS En el momento en el que se licita una obra, las empresas hacen un estudio económico a modo de previsión futura para estimar lo que costará ejecutar el proyecto tal y como figura en el diseño aprobado por la administración.

Además, las empresas estudian y proponen el equipo director del proyecto así como los medios que se van a emplear para la misma y el plazo que estimado. También, según los pliegos de bases, a veces se valora el Estudio de Seguridad y Salud propuesto, las medidas medioambientales, etc…

En este punto, conviene aclarar que eso no significa exactamente que se hace una oferta con un coste inferior al coste real en un 30%.

Por poner un ejemplo, partiendo de un presupuesto total de 100, una empresa hace el estudio económico y estima un coste de 80, pues bien, su oferta final podrá ser de 75, por ejemplo. Realmente no está un 25% por debajo del coste real, sino un 6,25%.

Finalmente, el presupuesto que se firma una vez ganada la licitación es el resultante de aplicar a todos los precios unitarios y al presupuesto total un valor que se llama “Coeficiente de Adjudicación” y que es el resultado de dividir el presupuesto de la oferta económica del ganador entre el presupuesto total contemplado en el diseño de partida. Este coeficiente en la inmensa mayoría de los casos es menor que uno.

Todo este procedimiento explicado aquí es el motivo principal por el que las empresas constructoras extranjeras no pueden competir en el mercado español, porque no entienden que esta práctica pueda producirse con un resultado final positivo.

Autor: Eduardo Gutiérrez Bahillo

Casi siempre, y más en los momentos actuales de fuerte restricción del gasto público, suele ponderarse altamente la oferta económica más ventajosa.

Entonces, ¿por qué se produce esta práctica? ¿cómo se consigue finalmente ganar dinero?

Fundamentalmente y resumiendo mucho la situación, por la imperfección en los diseños de los proyectos de construcción.

Así, debido a la fuerte competencia y al exhaustivo conocimiento que las empresas constructoras tienen sobre las normativas, regulaciones y procedimientos de la 24

www.proiectus.es

Número 2, Abril 2014

Pero, entonces, ¿significa esto que se puede cambiar por completo el alcance y las especificaciones del proyecto? Pues la respuesta es bien sencilla: si no se cambia el diseño el fracaso será seguro, ahora bien, existen numerosas limitaciones legales y restricciones a todos estos cambios.

El programa de anualidades, para contratos que comprometan, por su plazo, varios ejercicios económicos queda establecido en el Pliego de Bases Administrativas que son las que regulan el procedimiento de licitación. En él se establece el reparto anual del presupuesto, si bien es cierto que la ley permite que el contratista ejecute, bajo su responsabilidad, obras por encima del importe designado en un año determinado, esta práctica suele desaconsejarse porque supone que la contrata tiene que financiar parte del proyecto.

GESTIÓN ECONÓMICA DE LA OBRA. DIFERENCIA DE ENFOQUE CON LA TEORÍA DEL PMI (PROJECT MANAGEMENT INSTITUTE) En la gestión económica del presupuesto, siguiendo la técnica del Valor Ganado (EV), desde el análisis inicial, en el minuto uno del proyecto, habría que proceder a su rescisión, ya que, queda demostrado que el valor previsto del presupuesto es mayor que el planificado y, por tanto, estamos desde el primer momento en una situación de pérdidas económicas.

La forma de pago está regulada también por la Ley de medidas de lucha contra la morosidad [2]. En esta ley se establece que la Administración tiene que pagar antes de 30 días desde la firma de la Certificación (es como se llama la factura que se le pasa a la administración), mientras que el contratista está obligado a pagar a sus proveedores antes de 60 días, sobre la fecha de factura.

¿Cuál es, por tanto el objetivo del Jefe de Obra?

ESTRATEGIAS PARA MEJORAR EL CPI DEL PROYECTO

Fundamentalmente se trata de gestionar el proyecto a lo largo de todo su ciclo de vida para que al final, cuando se cierre la obra, el CPI sea mayor o igual a 1, y, además, cuanto más beneficio económico se saque del proyecto, mejor.

Fundamentalmente hay 3 estrategias para mejorar el CPI del proyecto.

• Liquidación positiva.

• Modificaciones del contrato

Aprovecho para recordar que el CPI (Indice de Desempeño del Costo), según la técnica del Valor Ganado, es la relación entre el Valor Ganado (EV) en un momento determinado y el Coste Real (AC) en ese momento.

• Contratación de obras complementarias.

Liquidación positiva Como habéis podido entender, el presupuesto adjudicado está por debajo del coste real en su conjunto, pero esto no significa que en todas las unidades del contrato se pierda dinero. Los precios unitarios no siempre atienden a la realidad

Además, como complementos adicionales de la gestión económica de la obra tenemos el programa de anualidades y la forma de pago.

25

www.proiectus.es

Número 2, Abril 2014

del coste de la misma manera, así que hay partidas “beneficiosas”, porque incluso aplicando el coeficiente de adjudicación, te pagan más de lo que te cuesta, y hay partidas “perjudiciales” en las que lo que te cuesta está por encima de lo que te pagan.

Así que una estrategia clara es identificar las partidas buenas y malas de manera que se oriente el proyecto hacia aumentar la ejecución de las partidas buenas y se reduzca la ejecución de las partidas malas.

• Imposibilidad de ejecución por circunstancias de carácter geológico, hídrico, arqueológico o medioambiental puestas de manifiesto con posterioridad a la perfección del contrato.

• Fuerza Mayor • Avances técnicos que mejoren y que hayan aparecido con posterioridad a la fecha del contrato.

• Adecuaciones a especificaciones técnicas, medioambientales, urbanísticas o de seguridad con posterioridad a la fecha del contrato.

Esta estrategia se enmarca dentro de las unidades contratadas y no contempla la creación de partidas nuevas. La Ley establece un límite del 10% al incremento de partidas contempladas en el proyecto.

La suma de todas las modificaciones que se hagan a lo largo de la vida del proyecto no pueden superar en su conjunto el 10% del presupuesto total.

Como he dicho anteriormente, las mediciones no son contractuales y si realmente se ejecutan más unidades de las previstas en el contrato, estaremos dentro de los límites legales si no se supera en su conjunto el 10% del presupuesto.

El efecto que se consigue modificando los contratos es la aparición de precios unitarios nuevos, no contemplados en el presupuesto inicial y que son beneficiosos económicamente. Si bien es cierto que el que fija los precios nuevos es la propia Administración, normalmente son negociados y aceptados por el contratista.

Modificaciones del Contrato Este procedimiento está cada vez más vigilado y controlado por la Administración que ha visto en el pasado como las obras se alteraban aumentándose de manera incontrolada su presupuesto.

Contratación de obras Complementarias La legislación vigente contempla la posibilidad de que el contrato pueda ampliarse para recoger obras de carácter complementario porque son necesarias para cumplir la totalidad del alcance del contrato.

Existe un procedimiento específico para la aprobación de modificaciones en los contratos que está regulado por Ley. El promotor de los modificados en los proyectos es la propia Administración y sólo están contempladas las siguientes causas:

Los requisitos que deben cumplir estas obras complementarias son que no puedan separarse del contrato principal ni técnica ni económicamente.

• Imposibilidad de ejecutar el objeto del contrato por errores u omisiones en la redacción del diseño 26

www.proiectus.es

Número 2, Abril 2014

Vamos a suponer que en la ejecución de una carretera no se ha contemplado la ejecución de un paso superior que conecte ambos lados de la carretera para dar acceso a un grupo de viviendas. Está claro que en este caso, con la ejecución de la carretera, se va a producir un aislamiento de un grupo de viviendas porque por efecto de la ejecución del contrato, se van a quedar sin acceso, además, para su ejecución, se deberá invadir la carretera en obras, por lo que no puede separarse técnicamente del contrato. Así pues, se requeriría incluir en el contrato principal la ejecución de esta nueva obra como obra complementaria.

CONCLUSIONES  Las presiones del Jefe de Obra son muy grandes.  La gestión económica de los contratos no se limita al control de los costes.  Su labor está fuertemente circunscrita a restricciones de índole regulatorio.

REFERENCIAS (1) Real Decreto Legislativo 3/2011 de 14 de noviembre por el que se aprueba el texto refundido de la Ley de Contratos con el Sector Público.

La ley permite la contratación de obras complementarias con un límite de un 50% del valor del presupuesto del contrato principal.

(2) Ley de 4 de julio de medidas de lucha contra la morosidad en las operaciones comerciales.

Esta estrategia puede permitir, de nuevo, la inclusión de unidades nuevas que resultarán económicamente más ventajosas para la obra.

Autor: Eduardo Gutiérrez Bahillo

27

www.proiectus.es

Número 2, Abril 2014

MARIO COQUILLAT DE TRAVESEDO Mario Coquillat es un profesional experimentado en gestión de proyectos,

certificado PMP® y PMI-RMP®. Miembro del Comité CTN 157/ SC1 Project Management de Aenor, participó como Comité Espejo en la nueva ISO 21500 “Directrices para la dirección y gestión de proyectos” y participa actualmente en el TC-258 - project, programme and portfolio management.

LA GESTIÓN DE RIESGOS EN MEGAPROYECTOS En el entorno global en el que nos encontramos, donde los proyectos son cada vez más complejos y multiculturales, realizar una adecuada gestión de los riesgos se está convirtiendo en una actividad cada vez más esencial para garantizar el éxito de los mismos.

de la gestión de riesgos, para que veáis que se obtienen conclusiones muy interesantes.

EL CONTRATO La modalidad contractual elegida por el cliente (1) fue precio cerrado con ajuste económico del precio unitario de cinco partidas, dada la duración del proyecto y la volatilidad de las mismas (lo que se denomina en el sector escalamiento), frente a un contrato reembolsable, donde se paga lo realizado más honorarios.

Tanto la ISO 21500: Directrices para la dirección y gestión de proyectos como el PMBOK® (y especialmente el Practice Standard for Project Risk Management) a nivel de proyecto, como la ISO 31000: Gestión del riesgo. Principios y directrices a nivel de la organización, permiten acometer la gestión de riesgos de una manera sistemática, transparente y fiable dentro de cualquier alcance y en cualquier contexto.

En el primer caso, la mayor parte del riesgo la asume el contratista que oferta, y exige por parte del cliente una buena definición del alcance, si bien el riesgo de parte de la volatilidad de las materias primas (lo que se denominan riesgos especulativos o del negocio) lo asumió el cliente. Estas fueron el acero estructural, acero de refuerzo, cemento, mano de obra y diesel y de hecho implicaron un aumento del precio inicial del contrato.

Podemos encontrar casos de total actualidad, como el megaproyecto que incluye el diseño y construcción del tercer juego de esclusas del Canal de Panamá, donde lo anteriormente mencionado se pone de manifiesto.

En el segundo caso, la mayor parte del riesgo lo asume el cliente, y de hecho en algún momento el cliente se planteó esta opción para acelerar el inicio del proyecto y no

Vamos a analizar a modo de caso práctico, la situación del proyecto desde el punto de vista

28

www.proiectus.es

Número 2, Abril 2014

esperar a una exhaustiva definición del alcance, que precisó de un largo proceso (14 meses) durante la fase de oferta.

En una de las reclamaciones planteadas por el contratista, toman como punto de partida el informe geológico y geotécnico del terreno suministrado por el Cliente, entendiendo que las desviaciones con respecto al mismo deben ser asumidas por el Cliente. Será preciso leer con exactitud las cláusulas correspondientes del contrato para poder delimitar que parte de riesgo del suelo asumió cada uno de los firmantes. Según se puede leer en prensa, existe una clausula según la cual el Cliente se compromete a pagar sobrecostes en caso de encontrarse condiciones físicas o topográficas imprevisibles durante del desarrollo de las obras (2).

RIESGO DEL SUELO En los proyectos de construcción, el cliente habitualmente suministra un informe geotécnico y geológico preliminar del terreno en el que se van a realizar los trabajos.

Quedará por determinar si las reclamaciones corresponden a riesgos imprevisibles como los denominados “cisnes negros” (en inglés black shawn), pudiendo ser esto dirimido por el tribunal de arbitraje que establece el contrato para resolución de disputas.

RIESGO PROVENIENTE DE UN SUPUESTO

Fuente: Wikimedia Commons Autor: Stan Shebs

Otra de las reclamaciones del contratista se refiere a la naturaleza del basalto.

El contratista asumió en fase de oferta, en base según sus reclamaciones a los datos del cliente, que el basalto procedente de las excavaciones de las esclusas de Pacífico sería machacado y procesado para obtener el árido de todo el hormigón de la obra.

Posteriormente, el contratista debe complementar, si lo estima conveniente, la información con informes adicionales asumiendo el riesgo del suelo, es decir, si por ejemplo los informes iniciales recomiendan un tipo de cimentación superficial y finalmente se precisa una cimentación profunda el contratista debería haber mitigado el riesgo del suelo realizando campañas de ensayos adicionales que le permitieran estimar los costes con menor incertidumbre o en su defecto aceptar activamente el riesgo y establecer contingencias.

Sin embargo, posteriormente al evaluar el supuesto y ver que era falso (al poner la planta de machaqueo en funcionamiento, se evidenció que al someter el basalto a la fracturación se generaba una inesperada y excesiva cantidad de material fino de naturaleza plástica) y que los objetivos de 29

www.proiectus.es

Número 2, Abril 2014

plazo y coste se verían afectados, se constituyó en un riesgo que obligó para mitigar el incumplimiento de plazos, a obtener más basalto del estimado inicialmente (durante el proceso de machaqueo y lavado el basalto sufría unas pérdidas de más del 30% del material fuente), modificar las plantas de machaqueo consideradas en la oferta para asegurar la producción así como llevar al vertedero el exceso generado en machaqueo de finos inútiles.

Si no se consideró como un supuesto y no se tuvo en cuenta su incertidumbre, que debe analizarse a lo largo del proyecto, no se estableció un plan de respuesta ni reservas de contingencia para poner en marcha una vez conocida la verdadera naturaleza del balasto.

Es muy interesante observar como la teoría que estudiamos se puede y deber poner en práctica en los proyectos (tanto pequeños como megaproyectos) para garantizar su éxito. Está en nuestras manos promover su uso dentro de nuestras organizaciones.

REFERENCIAS (1) Entrevista al administrador del Canal de Panamá (2) El contrato permite a SACYR incurrir en sobrecostos

30

www.proiectus.es

Número 2, Abril 2014

ANTONIO PEDRO DORTA ALONSO Ingeniero informático certificado Project Management Professional (PMP)®,

Máster en Administración de Empresas (MBA) y otra formación de posgrado.

Más de 7 años de experiencia como consultor en proyectos de innovación tecnológica (ERP, CRM, EDI, E-Commerce).

LOS ROLES DE BELBIN Y LA DIRECCIÓN DE PROYECTOS Todo director de proyectos se ha enfrentado alguna vez a la difícil situación de distribuir adecuadamente las tareas entre los miembros de su equipo de trabajo, a gestionar las particularidades de cada persona y, en definitiva, a tratar de sacarle el máximo partido a todo el potencial del que dispone.

ante la misma circunstancia. Debido a que un rol es un conjunto de características personales, posee una serie de fortalezas y una serie de debilidades (algunas de ellas son permitidas y otras no deberían tolerarse).

Por ejemplo, una personal con el rol de “cohesionador” posee las fortalezas de ser muy cooperativo y poseer una buena escucha hacia los demás, pero también conlleva una debilidad permitida: a veces se muestra indeciso ante situaciones difíciles que pueden ofender a diferentes personas. Una debilidad no tolerable de un cohesionador es que dicha indecisión puede convertirse en pasividad si se trata del líder del equipo y se le requiere resolver un conflicto entre dos miembros del mismo.

Abarcado dentro de las denominadas habilidades suaves (soft skills) de la dirección de proyectos, la gestión de personas es uno de los retos más habituales a los que se debe enfrentar todo directivo. Un ámbito que resulta fácil de comprender pero muy difícil de dominar.

Existen numerosas estrategias, metodologías y técnicas para gestionar adecuadamente un equipo de trabajo. En este artículo cubriremos una de ellas, la Teoría de roles de Belbin, por su enorme aplicabilidad a la gestión de proyectos.

Es importante destacar que la teoría de Belbin no trata de decirnos que algunos roles sean mejores que otros, sino que una adecuada combinación de los mismos es la que produce equipos de alto rendimiento, con resultados sobresalientes. Esto se debe a que la presencia de determinados roles pueden generar sinergias muy convenientes, mientras que las debilidades de algunos de

¿QUÉ SON LOS ROLES DE BELBIN? La Teoría de Belbin define 9 roles de equipo.

Un rol es un conjunto de comportamientos, un patrón bien definido, distintivo y que suele reaccionar de una forma determinada 31

www.proiectus.es

Número 2, Abril 2014

los roles pueden producir fricción y conflicto cuando tienen lugar simultáneamente. En definitiva, se trata de una cuestión de equilibrio.

 Permite incrementar la eficacia de los equipos de trabajo, a través de un mejor conocimiento personal tanto propio como del resto de compañeros  Favorece la relación con los interesados, considerando las expectativas y necesidades de los mismos bajo el paradigma de los roles de Belbin.  Favorece la gestión del talento en las organizaciones, considerando las características y habilidades particulares de cada persona. ¿CÓMO SURGIÓ LA TEORÍA RELACIONADA CON LOS ROLES DE BELBÍN? El investigador Raymond Meredith Belbin publicó en 1981 un libro titulado “Management Teams: Why They Succeed or Fail” (Gestión de Equipos: Porque tienen éxito o fracasan). En dicha obra, el autor presenta sus conclusiones tras varios años de análisis de cómo las personas interactúan en equipos de trabajo.

Fuente: Wikimedia Commons Autor: Allan Edwards

¿QUÉ PUEDEN APORTARME LOS ROLES DE BELBIN? Fundamentalmente, la aplicación de los roles de Belbin a la dirección de equipos de trabajo puede proporcionar las siguientes ventajas:

Lo que resulta especialmente interesante de dicho estudio es que en lugar de analizar el comportamiento o la actitud de cada persona como un ente aislado, Belbin se centró en estudiar cómo interactuamos con otras personas cuando poseemos un objetivo común. Podríamos afirmar que no se trata de un análisis de personalidad, sino un estudio conductual de cómo trabajamos con los demás.

 Ayuda a establecer relaciones laborales productivas, aprovechando las fortalezas y gestionando las debilidades que posee cada rol.  Favorece los procesos de selección de personal o de miembros de equipo de trabajo, adecuando los mismos según el potencial implícito en cada rol y considerando las tareas a realizar en el proyecto.

32

www.proiectus.es

Número 2, Abril 2014

¿CUÁLES SON LOS ROLES DE BELBÍN?

El rol del Cohesionador es, en muchos aspectos, antagonista al del Impulsor. Se trata de una persona cooperadora, sociable y diplomática, constantemente preocupada del bienestar de cada miembro y de que todas las personas se encuentren cómodas.

Escucha e impide que se agraven los conflictos, y descarga tensión en el ambiente.

A continuación, describimos los 9 roles de Belbin, indicando cómo contribuye al equipo, qué características personales lo definen y qué debilidades habría que gestionar en cada caso.

La debilidad del Cohesionador es su tendencia a evitar los conflictos. Puede llegar a convertirse en una debilidad no permitida, si dicha tendencia se convierte en indecisión en situaciones difíciles y no se afronta situaciones desagradables.

El rol del Coordinador es capaz de identificar el talento y sacar partido de las habilidades de cada miembro del equipo, aclarando las metas y delega las tareas. Posee un carácter maduro, seguro de sí mismo. Dentro de las debilidades permitidas para este rol, destaca que suele ser percibido como manipulador.

Las debilidades que no deben ser permitidas son descargarse de trabajo personal o asumir el mérito de todo el equipo.

El rol del Cerebro es característico de personas creativas e imaginativas. Posee un carácter independiente, listo y original, lo que le impulsa a innovar e inventar.

Contribuye al equipo generando ideas y resolviendo problemas difíciles.

Por otro lado, el Cerebro suele estar absorto en sus pensamientos, ignorando todo lo que le rodea. Su carácter independiente le impulsa a trabajar apartado del resto del equipo. Entre las debilidades no permitidas de este rol, se halla el que suele trabajar de forma poco ortodoxa y que tienden a sobrevalorar sus propias ideas sobre las del resto del equipo. Si el equipo posee muchos cerebros, apenas se relacionarán entre sí y no existirá coordinación.

El Impulsor es una persona retadora, dinámica y extrovertida. Trabaja bien bajo presión y posee iniciativa y coraje para superar los obstáculos. Contribuye al equipo retando a los demás, empujándolos hacia la acción y hacia el éxito.

La parte negativa de este rol es que suele centrarse excesivamente en ganar, lo que puede generar fricción con otros miembros del equipo. Por su carácter tiende a tener poca comprensión ante los demás, y ser propenso a la provocación. Dentro de sus debilidades no permitidas, puede originar con facilidad discusiones y polémicas e incluso abordar los conflictos con agresividad. Dos impulsores en un mismo equipo pueden entrar en conflicto si opinan de forma diferente.

El Investigador de Recursos es una persona extrovertida, entusiasta, comunicativa y negociadora. Está constantemente buscando nuevas oportunidades y desarrollando contactos. Es capaz de obtener nueva información con facilidad.

33

www.proiectus.es

Número 2, Abril 2014

Este rol suele ser excesivamente optimista y pierde rápidamente el interés, por lo que requiere apoyo constante para mantener su entusiasmo. Una debilidad que no debe permitirse es que puede defraudar la confianza de los demás cuando no cumple lo pactado o descuida el seguimiento de los acuerdos.

Su carácter meticuloso les convierte en líderes muy rigurosos o en miembros del equipo con problemas para delegar tareas, llegando a tener fricciones con miembros del equipo que asuman su tarea de forma relajada. Su principal debilidad no permitida es que su perfeccionismo puede derivar en una obsesión hacia los detalles y un exceso desproporcionado de rigor.

El Implementador transforma las ideas en acciones, realiza el trabajo necesario para cumplir los objetivos y tiende a centrarse más en los objetivos del equipo que en sí mismos. Se trata de una persona práctica, confiable y displicinada. Con un carácter conservador y ortodoxo, aborda todo de una forma sistemática.

El Especialista aporta cualidades y conocimientos específicos al equipo.

Asumiendo el rol de experto técnico en determinadas disciplinas, facilita la realización de ciertas tareas y asesora en la toma de decisiones. Generalmente, se trata de una persona entregada a su ámbito de conocimiento, con un alto nivel de compromiso en su aprendizaje.

Entre las debilidades que posee el Implementador, destaca que a veces se muestra inflexible antes nuevos cambios y situaciones. Ello se debe a que hacer las cosas de un modo distinto frena su eficacia, lo que le motiva a mostrar resistencia al cambio. Una debilidad a no permitir es que su resistencia puede incluso obstaculizar la innovación.

Los Especialistas tienden a centrarse en una única cosa cada vez y sólo contribuyen cuando se trata de un tema que dominan, explayándose en tecnicismos. Su debilidad no permitida es su nulo interés en el trabajo de los demás, ignorando todo factor externo a su ámbito de competencia.

El rol del Finalizador tiene cierta semejanza con el del Implementador, pero su esencia es muy distinta. Se trata de una persona esmerada, concienzuda y perfeccionista, obsesionada por llegar a los plazos establecidos. La ansiedad es su verdadero motor para motivarse, preocupándose hasta alcanzar un resultado satisfactorio y cumplir con la fecha prevista.

El Monitor Evaluador es una persona seria, prudente y con mucho autocontrol, gracias a que enfoca la realidad de una forma muy lógica y analítica. Contribuye al equipo evaluando todas las opciones y estableciendo diagnósticos precisos. Por ello, resulta muy útil en el análisis de problemas y para evaluar ideas y sugerencias. Posee un talento innato para sopesar las ventajas y las desventajas de cada alternativa, emitiendo juicios bien fundamentados.

El Finalizador busca los errores y perfecciona los resultados, terminando las tareas inacabadas y las omisiones. Por otro lado, entre sus debilidades destaca el que tiende a preocuparse excesivamente en los detalles.

Por el contrario, el Monitor Evaluador tiende a ser lento en la toma de decisiones, ya que quiere conocer el detalle de cada alternativa 34

www.proiectus.es

Número 2, Abril 2014

posible. Eso le impide tener iniciativa y no resulta inspirador al resto del equipo. Entre sus debilidades no permitidas, puede ser excesivamente crítico e incluso destructivo debido a su pesimismo, favoreciendo la no acción ante el riesgo.

A continuación se muestran algunas propuestas prácticas de cómo aprovechar las características personales de cada rol en determinadas circunstancias:

¿QUÉ APLICABILIDAD TIENEN LOS ROLES DE BELBIN EN LOS PROYECTOS?

Como puede deducirse fácilmente, resulta ideal para la asignación de tareas y para mantener la gestión de la integración del proyecto.

Coordinador

Evidentemente, un director de proyectos no siempre puede conformar el equipo de trabajo en base únicamente a sus deseos. La gran mayoría de las veces, se encuentra con un equipo de personas ya asignadas, cuyo trabajo requiere ser coordinado.

Resulta ideal una persona con este rol para conseguir reuniones productivas.

En equipos ágiles puede resultar también un rol crucial si los miembros del equipo aún no conforman un equipo auto-gestionado.

Sin embargo, un conocimiento adecuado en el ámbito de recursos humanos, como los roles de Belbin, le permitirán obtener el mayor rendimiento posible, prevenir conflictos entre sus miembros y delegar eficientemente.

Impulsor Resulta ideal para hacer prosperar al equipo bajo presión, inyectando vitalidad al grupo.

Su energía favorece que el equipo mantenga un adecuado rendimiento, y al no poseer miedo al conflicto lo hace idóneo para tomar decisiones poco populares.

También resulta conveniente su entusiasmo al comienzo de todo proyecto, ya que su carácter enérgico facilita alinear a las personas hacia el éxito y comenzar a ganar velocidad.

Cohesionador Favorece el buen ambiente de trabajo, lo que resulta adecuado en cualquier momento de ejecución del proyecto. Normalmente se aprecia este rol cuando existe su ausencia, ya que el equipo sufre crisis internas.

Fuente: Wikimedia Commons Autor: Antonio Silverio

35

www.proiectus.es

Número 2, Abril 2014

También puede resultar muy conveniente en reuniones donde se requiere una figura que busque resolver conflictos mediante la colaboración o la reconciliación.

Resulta extremadamente necesario en tareas que requieren un alto grado de concentración y exactitud.

Especialista

Cerebro Es conveniente al inicio de un proyecto, para poder idear estrategias de ejecución o para el diseño de alternativas. También resulta práctico en situaciones complejas en las que se necesita soluciones creativas.

Favorece la realización de tareas muy específicas o que demandan un alto nivel de expertise. Su participación suele ser muy valiosa para resolver problemas en el ámbito que domina y para gestionar riesgos relacionados con dicho ámbito.

Investigador de Recursos

Monitor-Evaluador

Es excelente estableciendo relaciones personales, creando redes de contactos y buscando oportunidades de colaboración.

Estas habilidades pueden resultar de gran interés en la gestión de los interesados y en la gestión de las adquisiciones del proyecto.

En definitiva, puede ser una figura ideal para la relación del equipo de trabajo con el exterior.

Este rol resulta muy conveniente para monitorizar el progreso del proyecto, evaluar los riesgos y el control de la calidad.

Su carácter concienzudo lo convierte en una pieza clave en cualquier comité de control de gestión de cambios. ¿CÓMO SABES CUÁLES SON LOS ROLES BELBIN DE UNA PERSONA?

Implementador

Es importante tener en cuenta que muy pocas personas poseen las características de un único rol del equipo. En realidad, lo habitual es que cada persona destaque en dos o tres roles, considerados primarios (lo que genera, por cierto, una enorme cantidad de posibilidades diferentes de comportamientos por combinación).

Este rol resulta crítico para conseguir que las cosas se hagan. Es quien transforma el plan de proyecto en realidad a través de construir los entregables requeridos. Sin la presencia de un implementador, es probable que el trabajo duro nunca se realice adecuadamente.

En el sitio web oficial de Belbin es posible realizar diferentes cuestionarios de autopercepción (cómo nos vemos a nosotros mismos) y cuestionarios con valoraciones de nuestros compañeros de trabajo (aporta mayor objetividad a los resultados). También resulta interesante por la posibilidad de consultar multitud de recursos adicionales.

Finalizador Un rol fundamental para poder cumplir con el calendario del proyecto, ya que transmiten urgencia para alcanzar los plazos establecidos.

36

www.proiectus.es

Número 2, Abril 2014

A continuación mostramos en una tabla resumen la repercusión de cada una de estas ventajas en los procesos y áreas de la gestión de un proyecto.

Para ello, consideraremos la clasificación propuesta por el Project Management Institute en su versión 5 de su obra PMBOK:

CONCLUSIONES El éxito o fracaso de los equipos de trabajo depende de su capacidad para detectar, gestionar y coordinar las contribuciones de cada miembro del equipo.

A través de una adecuada gestión del equipo de trabajo, un director de proyectos puede obtener el mayor rendimiento posible del esfuerzo aplicado, prevenir posibles conflictos y delegar eficientemente las tareas. En ese sentido, Belbin y sus 9 patrones de conducta pueden aportar un enfoque práctico de cómo llevar a cabo este reto de una forma eficaz.

37

www.proiectus.es

Número 2, Abril 2014

ANTONIO MARTEL RODRÍGUEZ Antonio Martel. Gestor de proyectos software especializado en soluciones Java y de Business Intelligence. Scrum Master certificado con un amplio portfolio de proyectos internacionales y para la administración pública local y regional.

JEFE DE PROYECTO, ¿Y AHORA QUÉ?

INTRODUCCIÓN

pero… ¿cómo vamos a ser capaces de poner en vereda todo esto?

Nos acaban de nombrar jefe de proyecto. Lo han hecho porque hemos tenido una buena trayectoria como técnicos en nuestro campo y nos han querido premiar con esta responsabilidad. En realidad no sabemos gran cosa de lo que tenemos que hacer a partir de ahora, sólo sabemos que el jefe de proyecto es „el que manda‟ y el que siempre nos exigía responsabilidades. Lo buscamos en la Wikipedia y encontramos que nuestra misión es la de cumplir con los objetivos del proyecto gestionando el coste, el tiempo, el alcance, ¡casi nada!

Podemos tomar una actitud de supervisión llevando una contabilidad exhaustiva y precisa de gastos y horas empleadas, asignando y desasignando recursos y limitándonos a exigir al equipo de trabajo que cumpla con los plazos estimados.

Lamentablemente, seguir a pies juntillas un cronograma hecho antes de saber casi nada del proyecto, no va a hacer más fácil que se puedan cumplir esos plazos. Contar que ya hemos registrado dos mil horas en la aplicación de gestión de incidencias tampoco nos va a decir si estamos construyendo el producto que el cliente necesita o si vamos por buen camino.

Hasta ahora, del coste de un proyecto no sabíamos prácticamente nada, de esas cosas se encargaba nuestro jefe, y siempre nos explicaba que íbamos mal en asuntos de dinero. Sobre el tiempo para realizar el proyecto sólo sabíamos que siempre incumplíamos los plazos y que para cada entrega solíamos tener que trabajar varios fines de semana. En cuanto al alcance, era habitual que terminásemos haciendo una cosa muy diferente a la prevista al principio y que nuevos requisitos entrasen y saliesen continuamente de la lista de tareas. Todo esto es ahora es nuestra responsabilidad,

Cuanto más tiempo paso gestionando proyectos más pienso que la labor del jefe de proyecto no está solo en pedir explicaciones y exigir responsabilidades sino en ayudar a cumplir esos encargos. Facilitar el trabajo a los demás y buscar la forma más fácil de hacer el trabajo no es sencillo pero por algo nos han dado esta responsabilidad.

Nuestro trabajo sería más fácil si siempre contásemos con un equipo muy 38

www.proiectus.es

Número 2, Abril 2014

experimentado para el que no hay tarea que se le resista. No necesitaríamos dedicar semanas enteras a formación ni tendríamos que preocuparnos por facilitar el trabajo.

Ellos nos facilitan el nuestro. Sólo tendríamos que sentarnos a esperar a que terminen el proyecto pero ¿de dónde vamos a sacar equipos así?

trabajadores. también.

Sí,

los

jefes

de

proyecto

Para evitar esto creo que seguir metodologías ágiles como Scrum me ha ayudado bastante: Cada dos semanas debemos hacer una entrega de lo que estamos haciendo. Una entrega revisada y comprobada. No podemos dejar todo para el final del proyecto y luego ver que no funciona. Sería como diseñar y construir un coche de una sola pieza sin haber probado primero que el motor funciona, que el sistema eléctrico es capaz de arrancar el coche o no saber si el sistema de frenado puede parar el coche de forma eficiente en la distancia requerida.

Lamentablemente el talento y la experiencia no crece en los árboles. Podrías empezar a pagar más y más a tu equipo de trabajo para atraer a los mejores pero esto mismo lo van a comenzar a hacer también tus competidores para retener a sus profesionales y, no nos engañemos, tu empresa no es Google. Esto sólo se lo pueden permitir empresas con pingües beneficios como ésa y por mucho que paguen siempre habrá muy buenos profesionales trabajando para otras compañías.

Otra práctica que creo que también ayuda mucho a mejorar la productividad es el hábito de mantener reuniones diarias con los miembros del equipo de trabajo. Esto nos ayuda a que todos seamos conscientes de lo que tenemos que hacer cada día, de los problemas que están surgiendo pero, sobre todo, nos hace ver lo cerca que está la siguiente entrega.

Tu equipo de trabajo y tú, que formas parte de él, con todos los inconvenientes que tengáis tendrán que hacer el trabajo lo mejor que puedan. Esa es tu principal tarea ahora: sacar el mejor partido a tu equipo. Estoy seguro de que podrán hacer grandes cosas con un poco de esfuerzo. Ya se sabe, a largo plazo no triunfan los más brillantes sino los talentos medios que vencen habitualmente la pereza.

DAR TRANQUILIDAD AL EQUIPO DE TRABAJO Esto ya lo avisaba Frederick Brooks en su libro “The mythical Man-month”: Es necesario reservar el tiempo suficiente para hacer las tareas. Si damos menos tiempo del necesario para acabar una tarea, no solo la calidad se puede resentir sino que podríamos tardar aún más del que habríamos necesitado si hubiésemos planificado el tiempo suficiente.

Siempre podremos hacer algo para sacar el mejor partido del gran equipo con el que contamos: AYUDAR A SER MÁS PRODUCTIVOS La procrastinación o la pereza para acometer las tareas más difíciles y el pequeño caos para organizar nuestras tareas diarias son dificultades que tenemos todos los

Si por presiones externas, comprometemos para tres meses una tarea que en condiciones normales tardaríamos seis, 39

www.proiectus.es

Número 2, Abril 2014

podemos acabar haciéndola en nueve. Al cumplirse los tres meses previstos y ver que la tarea aún no está acabada, la presión y el estrés aumentarán y esto hará sufrir la calidad del producto. También tendríamos la tentación de añadir más personas al equipo para acabar antes el trabajo, pero esto no es gratis. Varios miembros deberán parar durante semanas o meses para formar a los nuevos integrantes, tiempo durante el cual ni los nuevos ni los antiguos miembros del equipo estarán avanzando sus tareas. Otra tentación sería la de darles menos tiempo de formación a los nuevos pero ¿llegarán a ser totalmente productivos antes de que acabe el trabajo?

• Acortar las interrupciones al mínimo posible siendo conciso en la exposición y llevando todo lo necesario para resolver la cuestión ya preparado al momento de la reunión.

MANTENER EL BUEN HUMOR Esta es la parte más difícil de cumplir. Todos tenemos nuestras presiones y nuestros problemas pero intentando bajar los niveles de estrés a lo justo, dando tranquilidad al equipo y recordando que dirigir es facilitar y no controlar intentaremos conseguir que el trabajo no sea siempre tan cansado, sino quizás divertido.

REFERENCIAS

Otra forma de aportar tranquilidad a los equipos de trabajo es no interrumpiéndolos.

Esta es una de las cosas que más me ha costado aprender. Las prisas del trabajo diario nos hacen ver que cada cosa que llega a la bandeja de correo es aún más importante que la anterior y andamos todo el día pidiendo a unos y a otros que paren lo que están haciendo para apagar el último incendio.

(1) The mythical Brooks

man-month,

Frederick

(2) Contagiar la no interrupción en el equipo (3) Las ocho actitudes del jefe excelente

Con interrupciones constantes no hay un poco de sosiego para acabar tareas que requieren concentración. Para evitar estas interrupciones procuro: • Concentrarlas todas en un único momento del día. Preferiblemente a última hora del día.

• Pedir con antelación suficiente que me reserven esa última hora de la jornada de forma que puedan organizar el resto de sus tareas en el tiempo restante.

40

www.proiectus.es

Número 2, Abril 2014

AGUSTÍN TAPIA QUESADA Licenciado en Informática y Experto universitario en Ingeniería del Software con más de 10 de experiencia en dirección de proyectos y servicios TIC, tanto

en el sector privado como en el público. Actualmente Responsable de Área de Desarrollo

de

Open

Canarias

dirigiendo

los

proyectos

y

servicios

de

Administración Pública, Turismo y Sanidad.

LA VELOCIDAD, LA BOTELLA, LAS PELOTAS, LA ARENA… E ¿ITIL? En un mundo laboral donde es necesario dar respuesta casi inmediata a todo lo que nos llega, es posible que esta labor del “día a día” nos consuma tanto tiempo que no seamos capaz de sacar el trabajo según lo habíamos planificado.

Pensemos en un periodo de tiempo concreto, nuestra agenda semanal, como una botella; el trabajo u objetivos que pretendemos sacar como pelotas; y finalmente, el día a día, como arena.

Al empezar la semana

Empieza la semana, la idea es ir rellenando la botella con las pelotas y con la arena según vayamos terminando trabajo según avance la semana.

A mediados de semana pasa que, aunque hayamos metido algunas pelotas en la botella, la arena entrará tanto en la botella tanto que llegará un momento que ya no cabrán más pelotas... el día a día nos ha comido.

A mediados de semana

¿Otro enfoque? Metamos primero las pelotas en la botella, reservemos de modo inflexible tiempo, reservemos en nuestra agenda, antes de empezar la semana. La arena, según surja, irá rellenando los huecos... ¿resultado al acabar la semana? Objetivos realizados, día a día contenido.

Al terminar la semana

41

www.proiectus.es

Número 2, Abril 2014

Vale, esta metáfora es muy conocida, aplicada además a otros sectores de la vida, como las cosas importantes, la familia, los amigos, etc. vamos que no estoy hablando de nada nuevo, ni inventando nada.

Hablemos ahora de Desarrollo de Software, la metáfora me sirve para ilustrar algunas situaciones que se dan en muchos de estos proyectos. En los últimos años casi todos los proyectos se abordan en un ciclo de vida iterativo (e incremental). Aunque en todas las metodologías “pesadas” siempre se ha contemplado este ciclo de vida, parece que es ahora, y gracias a la casi implantación casi unánime de las metodologías ágiles en los proyectos de software, cuando ya se ha institucionalizado el ciclo de vida iteraciones.

Ya casi no se concibe un proyecto que no esté basado en iteraciones.

Escenario iterativo con SCRUM

Hasta aquí un poco todo son ventajas en lo relativo a un enfoque iterativo-incremental.

La cantidad de trabajo productivo que un equipo es capaz de sacar adelante en una Iteración es lo que se le denomina Velocidad.

De algún modo, la velocidad se puede medir por el número de pelotas que somos capaces de sacar adelante en una iteración, de este modo nos centraremos primero en las pelotas e iremos despachando la arena para poder terminar la iteración con la botella llena de pelotas y parte de la arena que haya podido surgir. ¿Cuál es la arena en proyecto de Desarrollo de Software? La atención telefónica al cliente, las dudas, las reuniones, los informes, las presentaciones...todo aquello que surge en un proyecto de desarrollo de software que hace el equipo pero que no está relacionado directamente con producir software.

El objetivo de las iteraciones es buscar que el personal que recibe el software lo vea funcionando lo antes posible (software funcionando sobre documentación extensiva), que cada periodo vaya viendo como su software va incrementando en funcionalidad.

Un producto y sus incrementos. Esto nos permite, al equipo de trabajo, percibir lo antes posible el feedback del cliente y nos permite hacer los ajustes para que el software esté alineado con lo que se espera.

Al mismo tiempo, nos permite identificar problemas tecnológicos en las primeras fases del proyecto, para poner un software en producción debo resolver un montón de aspectos tecnológicos, todos ellos deben quedar resueltos en las primeras entregas.

Cuanto antes aparezcan más tiempos tendremos para resolverlos.

La teoría dice la velocidad de un equipo de trabajo va mejorando a lo largo de la vida de un proyecto, cada vez el equipo se conoce mejor, conoce mejor el problema, la tecnología, el cliente, etc. Esa es la teoría, y aparentemente tiene sentido.

42

www.proiectus.es

Número 2, Abril 2014

¿La práctica? En muchos proyectos pasa justo al contrario, la velocidad empieza a empeorar progresivamente, la presión empieza a aumentar y los errores a aparecer.

El clima con nuestro cliente se deteriora, nuestro equipo se estresa, etc. de repente todo parece haberse torcido. ¿Qué ha pasado?

dedicación de antes, se le llena de arena la botella antes de poder meter parte de las pelotas.

Encima nuestro cliente no entiende cómo antes los incrementos del producto eran muy importantes, y ahora cada iteración mejora algunos aspectos ya desarrollados pero incorpora pocas funcionalidades. “Me dijeron que la velocidad iría mejorando…”. “Tu equipo se está relajando, están perdiendo la intensidad…”.

Volvamos a la definición de velocidad, cantidad de trabajo productivo que un equipo es capaz de sacar adelante en una iteración.

En un esquema iterativo-incremental, hemos puesto en producción un software en el primer tercio de vida del proyecto. Este software, en las primeras iteraciones, lo usaban algunos usuarios de referencia, en las últimas se ha ido implantando en la organización, ahora ya lo usa toda la organización.

Ahora, al equipo de trabajo lo llaman todos los usuarios para preguntar dudas por el software, para comunicar incidencias, a los desarrolladores los llaman los de sistemas para participar en reuniones de arquitectura.... un usuario, cansado de que no lo atiendan, además se ha plantado en el despacho y se ha pegado media mañana con parte del equipo para entender una funcionalidad.

Por otro lado, sobre funcionalidades ya entregadas surgen una serie de ajustes que nuestro cliente entiende necesarias.

Escenario desarrollo sin cumplir objetivos

¿Qué ha pasado? ¿no me sirve el esquema iterativo-incremental del que todo el mundo habla? ¿resulta que el enfoque interativo incremental es malo?

Ha pasado que los granos de fina arena del principio se han convertido en cantos rodados, casi tan grandes como las propias pelotas. Es decir, ahora tiene tanta importancia para el proyecto dar soporte a tus usuarios como seguir desarrollando el producto.

En definitiva, el equipo de trabajo al principio del proyecto dedicaba casi todo su tiempo a desarrollar, a producir, a meter pelotas en la botella, ahora, sin embargo, le surgen un montón de tareas menores, que sin ser de impacto de modo aislado sí evitan que el equipo esté desarrollando con la misma

Ha pasado que ahora tu proyecto tiene dos objetivos producir un software y ofrecer un servicio. Un servicio de soporte para los 43

www.proiectus.es

Número 2, Abril 2014

usuarios de tu aplicación. Este servicio precisamente tiene como objetivo dar ayuda a los usuarios, resolver dudas, canalizar peticiones de mejora, nuevas funcionalidades, etc. y también ayudar a resolver incidencias de infraestructura.

¿Has oído hablar de ITIL? ITIL es casi un estándar de facto en la gestión de servicios TI, el alcance de ITIL va mucho más que un servicio de soporte de una aplicación, pero como marco de referencia para empezar a organizarlo nos puede ayudar mucho.

Si tu equipo de trabajo acaba haciendo todo esto en un proyecto de software asume entonces que tienes dos objetivos, producir software y ofrecer un servicio de soporte.

Aunque hay que reconocer que ITIL asustar, sobre todo a los defensores de los enfoques ágiles, yo creo que sí que nos puede ayudar en muchas cosas, pero principalmente:

En esta situación puedes optar por dos caminos: uno que se separe hacia un departamento especializado de atención a usuarios el servicio de soporte; dos, que el propio equipo que desarrolla deba prestar este servicio.

• A determinar qué sí que tenemos que hacer o que no; a determinar realmente cuales son las responsabilidades del equipo en las tareas de soporte, qué debemos hacer y para quién y qué no. Un Catálogo de Servicios, aunque no sea de modo explícito, determinará realmente cuales son las responsabilidades del Equipo, a quién debemos prestar esos servicios y bajo qué condiciones (Niveles de Servicio), tiempos de respuesta, horarios, tiempos de resolución, etc.

Si estamos en el caso 1, perfecto, nos quitamos arena, volveremos a dar la velocidad a nuestro proyecto que habíamos perdido.

Si estamos en el caso 2, la arena efectivamente es piedra, es pelota. Hay que establecer iteración por iteración un tiempo bloqueado para garantizar este soporte. Este caso es el que nos toca, ¿cómo vamos a montar un servicio de soporte si el proyecto no ha terminado? Desde luego que es difícil conseguirlo.

• A saber diferenciar una Error de una Necesidad, una Incidencia de una Petición de Servicio. No es lo mismo que nos estén transmitiendo un error de nuestro software que impide a un usuario a realizar una función; que una necesidad de mejora, una consulta, etc. Obviamente, la incidencia va primero!

Cada iteración, por tanto, tendrá reservada una parte del tiempo del equipo para soporte y otra para desarrollo. ¿Cuánta parte? Si llega una petición ¿la atiendo sobre la marcha? ¿tengo que responder a todos los usuarios? ¿todo el mundo nos puede pedir cambios?

Muchas preguntas y pocas respuestas.

• A saber gestionar, a quién escalar (dentro o fuera de nuestro equipo), a quien pedir autorización, etc. Un Proceso de Gestión de Incidencias y de Peticiones de Servicio nos ayudará a gestionar todo esto. A tener estadísticas del volumen de actividad de estos procesos y el tiempo que nos consume.

44

www.proiectus.es

Número 2, Abril 2014

• A abordar o no una petición de cambio.

Una aplicación la pueden usar distintos tipos de usuario, cada uno con sus necesidades.

He vivido en más de una ocasión cómo se aborda un cambio en una iteración, para volver a deshacerlo en iteraciones siguientes, para volver a aplicarlo más adelante, ¿cuál era el problema? Que no había un Proceso de Gestión de Peticiones de Cambio bien establecido y casi que simplemente cuando un usuario lo pedía se abordaba... Por cierto, y un Cambio de una funcionalidad ya hecha, entregada y cobrada...¿entra dentro del alcance de nuestro proyecto?

ITIL nos debe ayudar a transformar la arena en pelotas, a transformar trabajo no planificado sin control, en paquetes de trabajo controlado que podamos gestionar.

No tenía como objetivo explicar ITIL sino de ilustrar que, adoptado con mesura, ITIL nos puede ser muy útil para controlar determinados proyectos donde podamos estar teniendo conflictos de prioridades, donde, en definitiva, la arena nos esté llenando todas las botellas sin poder abordar las pelotas como nos gustaría.

ITIL también nos puede ayudar a gestionar nuestro ciclo de versiones, a preparar nuestro sistema para dimensionarlo correctamente para el volumen de actividad esperado, etc. etc. La adopción de ITIL en un proyecto puede abordarse de modo incremental poco a poco introduciendo aquellos procesos que nos vayan haciendo falta... y parar donde creamos conveniente, una pequeña parte o acabar adoptando el marco completo en todas sus Fases.

Escenario desarrollo con SCRUM e ITIL

45

www.proiectus.es

Número 2, Abril 2014

IVÁN SAMUEL TEJERA SANTANA Ingeniero Superior de Telecomunicaciones por la Universidad de Las Palmas de Gran Canaria, Master Executive in Project Management por la Universidad de Valencia

e ingeniero

certificado PMP®, PSM®,

ITIL® y

SCJP®.

Iván

ha

desarrollado su carrera profesional en multinacionales relacionadas con el sector de las Tecnologías de la Información, siendo actualmente gerente de su propia empresa de Consultoría y Formación en Dirección de Proyectos.

COACHING A EQUIPOS ÁGILES INTRODUCCIÓN

la interacción entre los miembros del equipo con objeto de mejorar la calidad de los productos que se desarrollan.

¿Qué le ocurre a un Project Manager acostumbrado a dar órdenes y asignar tareas cuando se integra en un equipo ágil?

FACILITAR LAS REUNIONES DIARIAS

Pues le pueden ocurrir dos cosas, o que se resista a perder su autoridad obstaculizando la aplicación de metodologías ágiles, o que no le quede más remedio que adaptarse a la nueva situación.

El objetivo de esta reunión es facilitar la transferencia de información y la colaboración entre los miembros del equipo para aumentar su productividad.

En estas reuniones cada miembro del equipo responde a las siguientes preguntas:

El carácter autoorganizado de un equipo ágil relega a un segundo plano la figura del Director de Proyectos, acostumbrado hasta ese momento a actuar como intermediario frente al cliente y a ejercer su autoridad mediante la asignación de tareas a los miembros del equipo.

 ¿Qué he hecho desde la última reunión?  ¿Qué voy a hacer antes de la siguiente?  ¿Qué impedimentos están bloqueando o ralentizando mi trabajo?

Ante este nuevo escenario, es lícito que un Jefe de Proyecto se plantee en un momento dado qué es lo que puede aportar de valor al equipo. La respuesta es simple: ayudar a que dicho equipo sea cada vez mejor creando las condiciones adecuadas para fomentar la innovación y la generación de ideas.

Nuestra labor cómo Agile Coach es asegurar que la duración de la reunión diaria no supera los 15 minutos, que cada miembro del equipo responda a las preguntas anteriores y que no se establezcan debates sobre cómo se ha de resolver un problema.

Salvo en las fases iniciales, dónde nuestra función es enseñar a los miembros del equipo a llevar a cabo estas reuniones, por lo

El Director de Proyectos deja de actuar como tal, y asume el rol de Agile Coach, mejorando 46

www.proiectus.es

Número 2, Abril 2014

general, nos situaremos en un segundo plano interviniendo sólo en aquellos momentos que así lo requieran, como por ejemplo, en caso de que se ignore o interrumpa a un compañero mientras habla.



¿Cuáles son las historias de usuario y sus condiciones de satisfacción?



¿Qué es un punto de historia para el equipo?

Como resultado de estas reuniones, los miembros del equipo coordinan los esfuerzos al tiempo que adquieren un compromiso con el resto de compañeros.



¿En cuántos puntos de historia se estima cada historia de usuario?



¿Qué tareas hay que realizar resolver las historias de usuario?



¿Qué entendemos por Hecho cuando nos referimos a la resolución de una historia de usuario?



¿Cuál es el compromiso final del equipo para este sprint?

FACILITAR LAS REUNIONES PLANIFICACIÓN DEL SPRINT

DE

Para facilitar las reuniones de planificación del sprint, un Agile Coach debe velar por que el Dueño del Producto (Product Owner) haya preparado correctamente la Pila de Producto (Product Backlog), ¿esto qué quiere decir?

Pues que las Historias de Usuario (Story User) que conforman la Pila de Producto han de haber sido convenientemente detalladas y priorizadas. No hay nada más frustrante que llegar a una reunión de planificación de un sprint y encontrarnos a un dueño de producto incapaz de dar respuestas a las preguntas del equipo de desarrollo.

Una vez más, el Agile Coach se encargará de ir gestionando los tiempos para evitar que las reuniones se eternicen.

Será nuestra responsabilidad ayudar al dueño del producto a definir historias de usuario que aporten valor real a su negocio.

Igualmente, nos ocuparemos de ayudar al equipo de desarrollo a definir las tareas que han de ser acometidas para resolver una historia de usuario determinada sugiriendo el uso mapas mentales, la definición de tareas silenciosas, etc.

Además, hemos de facilitar un guión que sirva para conducir la reunión de planificación del sprint y saber cuándo la misma ha alcanzado sus objetivos: 

¿Cuál es el objetivo del sprint?



¿Quiénes son los miembros del equipo de desarrollo?



¿Cuál es la capacidad total del equipo para este sprint?



¿Cuáles son las historias de usuario de la pila de producto que aportan mayor valor al dueño del producto?

para

FACILITAR LAS REUNIONES DE REVISIÓN DEL SPRINT Durante estas reuniones, el equipo muestra al dueño de producto las funcionalidades desarrolladas durante el sprint sin que para ello sea necesario preparar presentaciones impactantes al estilo Steve Jobs.

47

www.proiectus.es

Número 2, Abril 2014

El equipo adquirió un compromiso al inicio del sprint, ahora es el momento de mostrar el trabajo realizado, obtener la aceptación del dueño del producto e informar de los “grandes” impedimentos que ni el Agile Coach ni el Dueño de Producto pudieron resolver durante el sprint.

FACILITAR LAS RETROSPECTIVA

¿Cómo es la interacción miembros del equipo?



¿Cómo es la interacción entre los miembros del equipo y el dueño del producto?



entre

En estas reuniones el equipo debe responder a las siguientes preguntas:

los

¿Se presta atención a la persona que habla?



¿Alguno de los participantes en la reunión es ignorado?



Cuando un miembro del equipo quiere tomar posesión de la palabra, ¿lo consigue?



¿Qué malinterpretaciones de conceptos ágiles se observan en las conversaciones?

DE

Y llegamos al momento de hacer balance y de evaluar cómo se hicieron las cosas. Aquí el papel del Agile Coach es determinante para ayudar al equipo a identificar los problemas experimentados y consensuar mejoras aplicables en posteriores sprints.

Durante la reunión de revisión del sprint, lo mejor que podemos hacer es sentarnos al final de la sala, permanecer en silencio, observar e intentar dar respuesta a preguntas tales como: 

REUNIONES



¿Qué se ha hecho bien?



¿Qué se debe mejorar?



¿Qué se debe mejorar en el siguiente sprint?



¿Qué problemas adecuadamente?

impiden

avanzar

CONCLUSIÓN Si alguna vez tenéis la oportunidad de entrenar a un equipo ágil, recordad que las personas trabajan mejor cuando tienen la oportunidad de autoorganizar su trabajo.

Nuestra función como Agile Coach es proporcionarles los medios adecuados para obtener de ellos el máximo rendimiento.

REFERENCIAS

Finalizada la reunión, compartiremos los comportamientos observados con el resto de miembros del equipo al objeto de poder mejorar su desempeño.

(1)

48

Coaching Agile Teams. A companion for ScrumMasters, Agile Coaches, and Project Manager in Transition.

www.proiectus.es

Número 2, Abril 2014

MANUEL VARA GONZÁLEZ Manuel Vara González es responsable de proyectos en Nartex Software, con más de 15 de experiencia profesional. Licenciado en Administración de Empresas por

la Universidad Autónoma de Madrid, Master en Dirección Financiera y Control de Gestión por la Escuela de Organización Industrial, es Stanford Certified Project Manager (SCPM) por la Universidad de Stanford (USA) y certificado Project Management Professional (PMP) por el Project Management Institute.

LA IMPORTANCIA DEL PLAN DE PRIORIZACIÓN EN LA GESTIÓN DE LA CARTERA DE PROYECTOS gestionados como un grupo con objeto de alcanzar los objetivos estratégicos”

INTRODUCCIÓN En los últimos años estamos asistiendo a importantes cambios culturales en las organizaciones, uno de ellos es la adopción de la gestión por proyectos y programas.

Esta tendencia que reconoce la importancia de los programas y proyectos como activos estratégicos en las organizaciones está aumentando y seguirá aumentando en el futuro. Cada vez menos organizaciones trabajan en proyectos individuales, aislados, y la mayor parte, en cambio, han adoptado un enfoque basado en la gestión de programas y proyectos, identificándola como una competencia crítica para el éxito estratégico de la organización.

Como vemos, es en este punto donde empieza a cobrar una gran relevancia la necesidad de elegir correctamente los programas y proyectos ya que será donde vaya una gran parte de nuestras inversiones siendo más interesante para nuestra organización dedicar nuestros recursos en programas y proyectos alineados con nuestras estrategias.

EL PLAN DE PRIORIZACIÓN DEL PORTAFOLIO Una de las técnicas con las que contamos para apoyarnos a la hora de elegir nuestros proyectos es el análisis de priorización. El estándar de PMI para la gestión de cartera de proyectos define el análisis de priorización como "una técnica para comparar y clasificar los componentes del portafolio, con base en sus resultados de evaluación y otras consideraciones de gestión, para asegurar la alineación con la estrategia y los objetivos de la organización. "

Es por tanto muy importante saber traducir nuestras estrategias en acciones e iniciativas y para ello disponemos de una herramienta muy valiosa; la gestión de la cartera de proyectos, también conocida como portafolio.

La propia guía de gestión de proyectos PMBOK lo define de la siguiente forma: “Un

portafolio consiste en proyectos, programas, subconjuntos de portafolios y operaciones

49

www.proiectus.es

Número 2, Abril 2014

También indica que el Plan Estratégico de la cartera debe contener un modelo de priorización que guíe las decisiones acerca de los componentes de la cartera y cómo se deberían monitorizar en todo momento para añadir nuevos, modificar o rescindir los actuales, así como gestionar las prioridades y el equilibrio de los componentes de la cartera de proyectos de la organización de forma dinámica.

completa • Las decisiones deben estar basadas en hechos, obtenidos con el apoyo de un procedimiento aplicado consistentemente.

• Tendrán que tomarse decisiones difíciles.

En algunos casos, la falta de recursos conducirá a cortar algunos de los componentes de la cartera de proyectos.

Con el fin de asegurar la prioridad adecuada, se debería definir un plan que especifique los dominios, los criterios de priorización, los requisitos de las propuestas para cada proyecto candidato o programa, los valores ponderados y las escalas para los anclajes de puntuación.

La organización establece directa o indirectamente la prioridad de cada componente de la cartera de proyectos a través de definición de la estrategia. El gestor de la cartera de proyectos utilizará esta priorización en todo el manejo de la cartera de planificar adecuadamente la cartera, evaluar el impacto de los cambios estratégicos, y tomar medidas correctivas.

A continuación vamos a describir en detalle cada uno de estos pasos:

Antes de diseñar un modelo de priorización para la gestión de la cartera tenemos que tener en cuenta algunas consideraciones importantes:

1. Establecer dominios Un dominio es la agrupación de los proyectos a los que se aplica un conjunto estándar de criterios para la priorización (Geoghan y Snow, 2001). Los dominios se pueden definir de muchas maneras, algunos ejemplos son:

• Deben ser definidos diferentes tipos de proyectos para poder agruparlos de forma coherente.

Empresarial

• Las decisiones de priorización deben estar conscientemente alineadas con las estrategias de negocio

 Mercados objetivo  Tipos de productos / servicios

• La información que facilite el proyecto o programa candidato deberá ser veraz y

 Conocimientos técnicos

50

www.proiectus.es

Número 2, Abril 2014

 Industria

 Una definición clara de los parámetros de dominio es esencial

 Los objetivos de inversión

 Podemos utilizar características de proyecto para definir los parámetros de dominio:

Unidad de Negocio  Área Funcional

 Tipo de Proyecto

 Tipo de Cliente

 Principal fuente de recursos

 Categoría de gastos

 Contribución Negocios

 Los clientes internos / externos

 Requiere de inversiones

 Ubicación geográfica

 Tamaño / nivel de esfuerzo

Enfoque del producto

 Duración del esfuerzo

 La base de clientes

 Fase del ciclo de vida del proyecto

 Segmento de mercado

 Grado de definición

 Competencia

3. Identificar organización

2. Definir los parámetros de dominio para cada proyecto

las

estrategias

de

la

Si la organización ya ha realizado el análisis de alineación estratégica para su cartera de programas y proyectos, será más fácil identificar las estrategias implicadas en la gestión, si no, tendríamos que hacerlo ahora.

Las estrategias actuales podrían ser detectadas en los informes anuales, en la visión y misión de la empresa, en la historia corporativa o en la cultura empresarial.

Los parámetros de dominio son el conjunto de características únicas que se usan para definir qué proyectos pertenecen a un dominio específico.

Para asegurar la exactitud de un dominio que tenemos que estar seguros de lo siguiente:  Todos los trabajos de proyecto encajan dentro de un dominio específico  Cada dominio puede enfatizar ciertas estrategias de negocio de manera diferente

4. Definir los criterios de priorización Las estrategias de la organización deben guiar la definición criterios de priorización, y estos deben ser suficientemente significativos.

 Los criterios de priorización de proyectos y escalas de puntuación son específico de cada dominio

51

www.proiectus.es

Número 2, Abril 2014

Este es un paso importante, ya que los criterios de priorización impulsan el proceso de gestión de cartera, proporcionando información importante para la autorización de las asignaciones de recursos y el orden de prioridades de los proyectos.

Algunas características crear estos criterios son: I.

importantes

de ellos, por lo que debemos definir una serie de contenidos mínimos para aquellos programas o proyectos preseleccionados, elaborando una propuesta ajustada a dichos contenidos y los requisitos de cumplimiento en términos de las estrategias identificadas previamente.

para

Podemos concretar cómo el proyecto o programa se ajusta o apoya el plan estratégico de la compañía. Para obtener esta información podemos definir un plan de alto nivel del componente del portafolio.

Pocos en número

II. No solapados entre si III. Claramente comprensibles

El plan de alto nivel debe contener hitos clave, las posibles alternativas de calendarios de ejecución, las estimaciones de recursos preliminares, los supuestos y las restricciones principales y las evaluaciones de riesgo de alto nivel.

IV. Claramente medibles V. Apropiados para cada dominio Los criterios de priorización de los componentes de la cartera pueden tener un carácter tangible o intangible, en la siguiente tabla podemos ver algunos ejemplos:

En la definición de la propuesta de proyecto o programa, podemos considerar los principales objetivos y resultados esperados, tales como mercado de destino, penetración de mercado, rentabilidad, satisfacción del cliente y el cumplimiento normativo.

6. Establecer los valores ponderados.

El uso de técnicas de ponderación permitirá que los componentes del portafolio se clasifiquen de acuerdo a los criterios de priorización.

Algunas consideraciones importantes:  No todas las estrategias han sido creadas de igual forma.

5. Definir los requisitos de las propuestas.

 La detección de funcionalidades duplicadas entre componentes de la cartera de

Para seleccionar los componentes del portafolio, necesitaremos saber más acerca 52

www.proiectus.es

proyecto es duplicidades.

Número 2, Abril 2014

crítica

para

eliminar

• Retorno de la inversión

 El orden de importancia de los criterios se expresa utilizando un determinado peso para cada criterio.  Los criterios comunes a más de un dominio, aunque estén dentro de una misma cartera pueden tener diferentes pesos.

5 = Introducción al mercado objetivo

5 = ROI Positivo



1 = difícil de adquirir



3 = fácil adquisición



5 = Sin nueva tecnología

REFERENCIAS

 Penetración en el mercado





El análisis de priorización es una de las técnicas críticas para el proceso de selección de los componentes finales de un portafolio.

El PMI destaca la importancia de usar un modelo de priorización alineado con la estrategia de la organización, para ello es fundamental contar un plan de priorización bien definido que dirija la ejecución del modelo de priorización de acuerdo con las estrategias a seguir.

Debemos evaluar los componentes del portafolio mediante una escala definida previamente donde cada valor tenga una explicación de su significado. Por ejemplo, podemos crear una escala de tres valores para cada uno de los criterios de priorización y seleccionar uno cuando lo apliquemos a cada uno de los componentes preseleccionados:

3 = El crecimiento en los mercados existentes

3 = Punto de Equilibrio

CONCLUSIONES

7. Definir las escalas de puntuación y su significado





Una vez completados estos pasos tendremos definido nuestro plan y listo para aplicarlo en la evaluación de los componentes de nuestro portafolio.

Para cada uno de los criterios de priorización podemos establecer un peso en función de una determinada lista de valores, por ejemplo, elegir un valor de la lista compuesta por 0,5 - 1 - 1,5.

1 = Sin nuevos mercados

1 = ROI negativo

• Utiliza la tecnología existente

 Los criterios de ponderación deben ser fáciles de aplicar; el propósito fundamental es proporcionar finalmente un ranking proyectos.





53

(2)

PMBOK 5th. Edition.

(3)

The Standard for Portfolio Management 3rd. Edition.

(4)

Tom Geoghan & Bruce Snow (2001).

Mastering the Project Portfolio. Stanford Advanced Project Management.

www.proiectus.es

Número 2, Abril 2014

ALEJANDRO FORCADES PONS Alejandro Forcades, Consejero Delegado de SM2, empresa líder en Baleares en Tecnologías de la Información, Diplomado en Ciencias Empresariales por la UIB, PDG por el IESE (Universidad de Navarra) y Certified for e-business – solution advisor - por IBM. Ha trabajado durante 8 años en la multinacional de consultoría y servicios informáticos Atos, fue subdirector de la empresa de seguros sanitarios Novomedic (Grupo Sanitas) y trabajó como Consultor Estratégico en el área de nuevos proyectos del Grupo Roxa.

EN ESTE NÚMERO ENTREVISTAMOS A… ALEJANDRO

FORCADES

PONS,

DIRECTOR

La gestión de proyectos está protagonizando un importante auge en nuestro país. En una época de crisis como la actual, llama la atención que España destaque en número de Project Managers y proliferen las asociaciones de gestión de proyectos. Las cifras hablan por sí solas: El número de certificados españoles PMP® (Project Management Professionals) supera los 4600, por delante de Francia (3700) e Italia (4300).

Si bien aún estamos lejos de Reino Unido (6500) y Alemania (10.000). Según datos del PMI® (Project Management Institute), el número de afiliados en 2012 creció un 39% en España, mientras que el crecimiento medio a nivel mundial fue del 7%. Sólo en el capítulo de Madrid de PMI, el número de socios se ha triplicado en tres años, hasta llegar a los 1400 en la actualidad. Quizá las razones detrás de este importante crecimiento puedan encontrarse en la necesidad de mejorar el currículum que tienen actualmente nuestros profesionales, al ser las acreditaciones de PMI altamente reconocidas en todo el mundo, pero hay que tener en cuenta que estos exámenes tienen

GENERAL

SM2

BALLEARES

S.A.

una alta tasa de suspensos (2-3 de cada 5) y que los cursos para preparar el examen son caros (el precio medio por alumno supera los mil euros).

España también es noticia en el sector de la gestión de proyectos por otra razón: Un proyecto subvencionado con fondos públicos del Plan Avanza 2 del año 2009, dio sus frutos y hoy día es un negocio sostenible basado en una herramienta de software libre.

El software que se desarrolló durante los años 2009-2010 por un consorcio encabezado por la empresa SM2 Baleares, se bautizó con el nombre de OpenPPM (PPM significa Project Portfolio Management), está publicado para su descarga gratuita por Internet en la dirección openppm.sourceforge.net, y es la pieza central de una línea de servicios denominada TALAIA™ (atalaya, en catalán), que presta servicios a varios clientes españoles, entre los que se encuentran: Iberostar, Riu Hotels & Resorts, Govern de les Illes Balears, Consell de Mallorca, Barceló Viajes e IBSalut.

54

www.proiectus.es

Número 2, Abril 2014

TALAIA se anuncia con frases como “la

Y sobre esta base argumentaron la solicitud de la ayuda Avanza2. ¿Acudieron a la ayuda individualmente como SM2?

herramienta pensada por y para Project Managers”, o “consistente con los estándares de PMI e ISO”, o bien “la única herramienta opensource para gestionar proyectos, programas y portfolios”. Para profundizar un

Inicialmente se constituyó un consorcio de cinco empresas. Más tarde, cuando se produjo la adjudicación, quedamos solo dos.

Hay que decir que el motivo para solicitar la ayuda no se reducía exclusivamente a la herramienta. El objetivo del proyecto era doble: además de desarrollar un producto sin coste de licencia y de software abierto para gestionar proyectos, programas y carteras sobre los estándares de PMI, también se pretendía constituir el capítulo Balear de PMI, ya que aquí en Baleares había, y sigue habiendo, un gran interés de muchos profesionales en gestión de proyectos por hacer comunidad. El objetivo inicial era ser el cuarto capítulo español, después de Madrid, Barcelona y Valencia. Finalmente no quedó el capítulo, sino la asociación denominada “Project Managers de les Illes Balears”, que en la actualidad cuenta con más de 50 socios y sigue creciendo.

poco más en TALAIA entrevistamos a D.Alejandro Forcades Pons, Director General de SM2 Baleares: Hablemos en primer lugar de los orígenes. ¿Cómo surgió la idea de TALAIA?

En el año 2009 detectamos la necesidad de que las empresas gestionaran proyectos con herramientas corporativas, pero sin tener que pagar precios de licencia y mantenimiento muy elevados.

Una herramienta de gestión de proyectos corporativa no tiene una funcionalidad equivalente a un ERP, pero los precios de mercado eran equivalentes. Eso resultaba prohibitivo para las organizaciones de la Administración Pública y también para muchas PyMEs. Pero la necesidad de gestionar por proyectos seguía estando ahí, y más en tiempos de crisis, porque ya no se podía perder dinero terminando los proyectos tarde y sin calidad, por ejemplo, o porque es más importante decidir bien si un proyecto lo hacemos o no, lo retrasamos, lo cancelamos, etc. Entonces, las organizaciones que no se podían permitir el lujo de adquirir una herramienta PPM de mercado, buscaban por Internet y seleccionaban herramientas opensource tipo DotNet u Openproj, que ya estaban disponibles por aquel entonces. El problema con estas herramientas era que eran soluciones parciales y no ofrecían todo lo que necesita un Project Manager.

¿Cuál es el valor diferencial de TALAIA? Yo diría que TALAIA aporta tres puntos diferenciales: 1) es la primera herramienta de código abierto que permite gestionar proyectos individuales y programas de proyectos, conforme a estándares; 2) sirve para todos los roles relacionados con la gestión de proyectos y 3) es un enfoque de servicio que se adapta a la madurez del cliente, sin imponerle que cambie radicalmente su forma de gestionar.

55

www.proiectus.es

Número 2, Abril 2014

Por favor, desarrolle un poco cada uno de los puntos. ¿Qué significa “conforme a estándares”?

quien ha vendido el proyecto o la inversión querrá monitorizar sus objetivos anuales, el responsable de recursos querrá anticiparse a las fluctuaciones de capacidad, la PMO querrá monitorizar todos los proyectos en su ámbito, homogeneizar los métodos, conceder permisos de acceso a usuarios, etc.

Conforme a estándares significa ni más ni menos que no hay que inventar la rueda.

Todo lo que necesita un Project Manager ya está inventado. PMI lleva casi 50 años estructurando el conocimiento necesario para gestionar proyectos en su famosa guía PMBOK® (Project Management Body of Knowlege) estándar ANSI que ya va por su quinta edición y que es totalmente consistente con el nuevo estándar ISO 21500. Todo Project Manager ya sabe lo que debe hacer para gestionar alcance, tiempos, costes, calidad, recursos, comunicaciones, riesgos, contrataciones, interesados, etc.

Sabe, por ejemplo, que el sobrecoste de un proyecto se puede calcular según el estándar Earned Value Management (estándar ANSI 748), pero en la herramienta de gestión de proyectos que le impone su empresa, y por la cual se está pagando mucho dinero, esto se calcula de otra manera, ¿por qué?

Y por último, ¿el punto relativo a “adaptarse a la madurez de los clientes”?

Este punto es muy interesante. Fíjese. El año pasado tuve una conversación con un potencial cliente de una gran empresa.

Tenían un plan para institucionalizar la gestión de proyectos en toda la organización.

Un volumen y complejidad impresionantes, estábamos hablando de varios cientos de proyectos ejecutándose a la vez. Habían evaluado varias herramientas y finalmente habían seleccionado una herramienta de mercado. Nosotros llegamos tarde con TALAIA. Pues bien, en 2012, ya le habían pedido al proveedor trabajar con la versión beta de 2014, porque sabían que las adaptaciones que tendrían que hacer en sus procesos para usar la herramienta llevarían 2 años, como mínimo. Este enfoque a mí me parece bien cuando se trata de adquirir un ERP. Todos sabemos que cuando una empresa compra un ERP, debe cambiar sus procesos para adaptarse a la herramienta.

Este enfoque tiene grandes ventajas relacionados con el ritmo del cambio y el compliance. Sin embargo, este enfoque a mí no me parece acertado cuando se trata de gestionar proyectos. Los proyectos no fallan o aciertan por las herramientas, sino por la capacidad de las personas que los gestionan, principalmente. Un Project Manager necesita gestionar el proyecto, no la herramienta. Si le hacemos seguir unos flujos muy

¿Sirve para todos los roles relacionados con la gestión de proyectos”?

Los proyectos son esfuerzos organizacionales colaborativos. Una herramienta PPM está incompleta si la usa solamente el Project Manager pero carece de interés para el director de la organización o departamento, el director de la cartera, del programa, el patrocinador, el responsable de recursos, los interesados, la PMO, etc. Todos estos roles tienen un interés diferente sobre la misma información del proyecto, y su forma de gestionar es distinta. Por ejemplo: un miembro del equipo usará la herramienta para declarar sus horas y gastos incurridos, 56

www.proiectus.es

Número 2, Abril 2014

complejos, los cumplirá, por supuesto, pero perderá poco tiempo porque tendrá otras cosas que atender más urgentes. Miraremos el proyecto en la herramienta y lo veremos “todo verde” pero ¿tendremos información fiable?

Si no venden licencias, ¿dónde está su negocio?

TALAIA basa su modelo de negocio exclusivamente en la venta de servicios asociados a la implantación de la herramienta. Por lo tanto el cliente solo paga por lo que necesita y le aporta valor. Nuestro enfoque permite definir con el cliente los servicios necesarios y dimensionar el proyecto de implantación con un enfoque lean startup ajustando los plazos a la capacidad de inversión de cada cliente. Eso nos permite realizar implantaciones incrementales al alcance de muchas empresas.

Pero, ¿Cómo se le da la vuelta al enfoque?¿Con TALAIA ya no hace falta que el cliente cambie sus procesos?

Por supuesto que hace falta, pero no empezamos por ahí. Cuando un cliente nos pide ayuda a nosotros, generalmente es porque tiene un problema. Unos necesitan una visión global de toda la cartera, otros tienen el problema puntual de tener que justificar muchos proyectos a la vez para el siguiente año, otros no dan abasto con la demanda no planificada, o necesitan controlar las horas incurridas de los recursos en proyectos, quieren homogeneizar el ciclo de vida, sufren continuas crisis y deben empezar a gestionar los riesgos, etc.

Nosotros iniciamos típicamente el servicio con un “quick-win” que resuelve ese problema con la ayuda de TALAIA, y en menos de 2 meses ya tenemos usuarios accediendo, gestionando y colaborando en sus proyectos. En esta fase inicial, generalmente no hay grandes cambios en los procesos, sino que adaptamos TALAIA para que se siga trabajando igual, pero de manera eficiente y efectiva. Esta fase inicial suele concluir con una hoja de ruta para las fases siguientes. Nosotros vemos TALAIA como un servicio continuo orientado a la generación de valor, no a vender licencias.

Por su lista de clientes, parece que el servicio TALAIA está muy localizado en Baleares. ¿Cómo ven el mercado en el resto de España? ¿Están pensando en el negocio internacional?

En una fase inicial es lógico centrarse en tus clientes, la mayoría grandes compañías internacionales y globalizadas, pero con sus centros de operaciones en Baleares. A los pocos meses y gracias a la potencia de Internet (SourceForge) y a las peticiones de todo el mundo recibidas a través de nuestra página Web, decidimos desarrollar una red de distribución global. En España contamos ya con varios distribuidores especialistas en PPM, y a nivel internacional tenemos ya cerrados acuerdos en Alemania, Chile, Uruguay y México. Y negociando en Australia, Colombia, Perú y Brasil.

57

www.proiectus.es

Número 2, Abril 2014

MIKE GRIFFITHS Mike Griffiths is a world-renowned project manager, trainer, consultant and writer,

holding multiple project management and Agile-related certifications. He is also a regular columnist and Agile contributor at Gantthead.com, the world's leading online community for IT project managers.

IN THIS ISSUE WE INTERVIEW… MIKE GRIFFITHS, PMI-ACP® STEERING COMMITEE Mike was on the original PMI-ACP® Steering Committee, which defined the agile-related knowledge, skills, tools and techniques to be tested by the PMI-ACP® exam. He also helped to create the new PMBOK® v5 Guide, as well as the Software Extension to the PMBOK Guide.

level of agile training, agile experience and agile knowledge and skills. Most companies today don‟t use a single methodology, but instead leverage elements of agile, lean and kanban where they best fit. An advantage of being later to market with the PMI-ACP was that it could choose to include the widespread and most practical elements from a variety of methodologies.

As a member of the PMI-ACP Steering Committee, what benefits does the PMI-ACP certification offer compared to other certifications promoted by organizations like the Scrum Alliance, Scrum.org or the International Scrum Institute? What is the intended purpose of the certification?

In Canary Island, most of the software development contracts that are signed off, have as a client the Public Administration.

Usually, in this type of public tenders, the scope as well as the cost of the project are pre-fixed in advance, which in turn makes agile management difficult. What would you recommend/do in order to achieve an agile management of the project?

The PMI-ACP® is not focussed on a single methodology. It combines elements from multiple agile approaches along with Lean and Kanban. The credential is well structured and requires education, practical experience and evaluation. Unlike Scrum certifications it meets the ISO/IEC 17024 standards that hiring managers look for in a rigorous, defendable credential.

Contracting for agile projects used to be a problem. I remember my first DSDM project was for the British Government who had similar rigid views about contracts and we had to build new agile contacts from scratch.

However there are now many examples and no need to reinvent the wheel. Agile methods provide very practical tools for meeting a fixed timeline, fixed scope or fixed budget.

The intended purpose is to create a credible, robust credential that participants and hiring managers can trust to demonstrate a base 58

www.proiectus.es

NĂşmero 2, Abril 2014

The advent of fixed price work packages and more granular SOWs make the process easier too.

scope using Feature Gathering workshops to generate a candidate feature lists. Once we have agreement that we have likely captured 80% of the core features, it is typically time to create our backlog and start drafting a roadmap knowing full well we need some slack and contingency for the remaining 20% of features that will emerge.

This workbook provides an excellent primer on agile contracts for people wanting to learn more.

What do you think should be done if we are looking to manage a project following agile methodologies and the client requests the Project Plan prior to the beginning of the project?

There is always a temptation to iterate through feature gathering workshops until people think they have generated 100% of the likely features, people think that is the right thing to do, but all that really happens is that we get suggestions for speculative features that go unused or represent gold plating. The true additional features will emerge as demos and evaluation of early solution iterations reveal omissions.

I think a client asking for a project plan is a perfectly natural request before starting work on a project. Agile projects are still planned but with detail appropriate to the quality of the input data. It would be misleading to present a seemingly concrete plan if it was based on an incomplete view of true requirements and technical risks or uncertainty.

It takes discipline and courage to find that point of the diminishing credibility of features and switch to backlog building and exploration. It is worth it though, since this leads to the quicker discovery of the true business requirements as opposed to the initially anticipated ones.

So my response to a request for a plan is to engage that person in release planning with story maps and then the development of iteration plans mindful of the quality of the input data. Stakeholders are typically receptive after being educated on the uncertainties of early plans and the processes for getting some rate of progress feedback and then updating plans.

I use workshops rather than interviews to gather candidate features since there is less likelihood to gold plate requirements in the presence of your business peers, and outputs with unknown consumers can be quickly killed off to simplify designs.

Given that at the beginning of a project you usually don't have a detailed Product Backlog, what process should be followed in order to obtain a Product Roadmap?

I like to use visioning exercises like “Design the product box� during kick-off sessions to start gaining stakeholder consensus on project scope. Then further elaborate on this 59

www.proiectus.es

Número 2, Abril 2014

Is it possible to manage a project in an agile manner if in the Sprint Planning Meetings the whole development team is not present (team members are missing)?

What techniques can teams minimize the technical debt throughout the project?

apply to generated

Technical debt eventually robs us of delivery capability and so needs to be kept to a practical minimum. Some basic techniques for ensuring a clean design and reducing technical debt include:

Yes, it is possible, but it is not optimal. We want the whole team present not only to provide necessary input, without which we might miss something and make mistakes, but also to build a better sense of ownership and commitment to these plans and estimates. Involving people in problem solving, planning and estimating is the best way to increase their commitment to meeting deadlines.

 Employ a Simple Design – factor in anticipated changes, but remain adaptable for unanticipated changes.  Frequent Integration – test that product features fit together often  Ruthless Testing – test first development, automated tests, etc. Find issues early on the “Cost of change curve”  Regular Refactoring – little and often, approved by PM and business. Refactoring should be like “daily hygiene, not spring cleaning” in other words done frequently not left and batched up.

What would you tell a client that wants to modify user stories in the middle of a Sprint?

I would tell the client “OK, let‟s ask the team”. Scrum has a protectionist view of changing stories during a sprint. It discourages this practice and instead recommends adding changes to the backlog or even terminating the sprint. Other agile methods are less controlling; in DSDM for instance we would take the change to the team and ask them about the impact. Maybe it is something that is easily accommodated in which case why would we not do it?

Alternatively, maybe it is more fundamental and a pause and rethink at the end of the iteration would make sense.

What does the Situational Leadership Model consist of?

Situational leadership simply means adjusting your leadership approach based on the circumstances at the time. Everyone does it to a certain extent, but there are some guidelines we teach that help prompt new leaders of some common things to look out for.

My view is quite pragmatic, if the client and team are onsite then let‟s discuss it. If the modification is easy then undertake it. If however the change is more significant or the cost of undoing / redoing work right now is high, then we should explain this to the client and let them decide what they want to do.

As an example, most people have heard of the team stages of Forming, Norming, Storming and Performing. These come originally from Bruce Tuckman and are followed by the disengagement phase of Adjourning or what I like to call Mourning 60

www.proiectus.es

Número 2, Abril 2014

since people often miss being on a high performing team.

Using this model we can see that Tuckman‟s Forming phase maps to Blanchard/Hersey‟s Directing phase. So, early on the role of an agile team leader is to directly help with project activities and paint a clear tactical picture explaining what needs to be done.

Also it helps to ask lots of “Help me see it” and “Where is the problem?” type questions to assist team members identify and articulate the issues.

As teams pass into the Storming phase we generally witness plenty of disagreement, open conflict, harsh dialogue. The Coaching role is important here to help team members resolve conflicts without damaging relationships, but generally some conflict is good so don‟t molly coddle them too much.

Let the disputes occur, but act as referee or safety valve to ensure things do not go too far.

Here we see that teams start in the lower right Forming quadrant as they learn about each other. Then they move through Storming (challenging each other) and Norming (learning how to work with each other), before finally arriving at the Performing phase (working as one). As leaders we can help the team through this process by adjusting our focus based on the matching overlay model from Ken Blanchard and Paul Hersey.

At the Norming phase it means that the team has found ways to create rules to help govern itself. This is not an opportunity for the lead to go on cruise control, but instead play a more Supporting role. The team will still need help with conflict resolution, as well as reminders to enforce the rules (norms) they have just created. This is a good time to challenge teams with high level goals such as “Team tracks velocity”, “Everyone owns testing”, and tackling issues raised at retrospectives.

The final Performing stage is not a given, many (if not most) project teams are never allowed to reach this phase because organizations make too many changes to them which send them through the Storming and Norming phases again. Perfoming teams are autonomous, empowered, self-managing, 61

www.proiectus.es

Número 2, Abril 2014

self-policing and require little more than a direction to be pointed in and regular recognition / thanks to be high-performing.

Blanchard/Hersey‟s Deligative leadership style in this phase speaks to bringing work and challenges to the team for them to solve.

What software tools would you recommend our readers to manage projects using agile methodologies (Scrum, Kanban)?

That‟s a little like asking what car should I buy? It really depends on your circumstances and needs. Small, collocated teams can get by just fine with cards on a wall or Excel based tools. Larger, geographically dispersed teams can greatly benefit from the online collaboration and tracking facilities of dedicated tools.

Of course this is a simplification and people and teams are complex and messy. Really the best we can do is be aware of these models and look for elements of them arising and then act accordingly. Some general pointers are better than no map at all, but don‟t expect teams to proceed in an orderly fashion and follow stereotypical stages.

The agile tools market has exploded with offerings and add-ons. Like word processors, most offerings contain features you do not need or only infrequently use. Tool evaluations that aim to count or rank systems based on capabilities often fail to see the costs of complications, unnecessary features and learning effort. Decide what you really need, switch on a bare minimum set of functionality and let needs dictate enabling new features. Software engineers often make horrible tool choices because they are attracted to “new shiny objects” which, while fun to play with, need updating and if people don‟t understand them or find them offputting or intimidating are counter productive.

You helped create the Dynamic Systems Development Method (DSDM). As it was one of the first Agile methodologies, it is probably unknown to many of our readers. Could you please explain what it consists of?

DSDM is wider and deeper than most methodologies. By that I mean it covers more of the product lifecycle with tools for assessing upfront feasibility and coverage for roles like sponsor and ambassador user, rather than just a product owner role. It is an enterprise friendly wrapper for agile practices and uses terminology more in keeping with most organizations. So there are no “planning games” or “extreme” anything that might strike some stakeholders as unprofessional terms.

We have all seen Microsoft Project Plans that are so complicated that no one wants to edit them in case they break something. The same thing can happen with agile tools, we want simplicity and inclusion, not specialization and exclusion. The benefits come from shared insight.

After the Feasibility Study portion of the project, it works much like other agile approaches, working from a prioritized list of features in short timeboxed iterations of development followed by demos and adaptation.

62

www.proiectus.es

NĂşmero 2, Abril 2014

A Project requires a complex architecture to be defined which will be used to determine the rest of the project work, how can we lay out partial and recurring deliverables?

The definition of architecture is usually undertaken during the iteration 0 period of the project. This is when tool set-up, proof of concepts and connectivity tests are done. It builds a skeleton of structure that features can be developed on later. Unlike subsequent iterations, iteration 0 may not take the standard one week or two weeks; instead it takes as long as necessary to set up the core tools and prove that key elements of the solution will work.

63

www.proiectus.es

Número 2, Abril 2014

ENTIDADES COLABORADORAS

64

www.proiectus.es

Número 2, Abril 2014

Esta publicación está disponible bajo Licencia Creative Commons Atribución-NoComercial-CompartirIgual 3.0 Unported (CC BY-SA 3.0). Usted es libre de compartir, copiar, distribuir, y comunicar públicamente la obra y hacer obras derivadas; bajo las condiciones de reconocer los créditos de la obra de la manera especificada por el autor o el licenciante (pero no de una manera que sugiera que tiene su apoyo o que apoyan el uso que hace de su obra), y si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta.

Texto de reconocimiento de los créditos de la obra Se ha de indicar la fuente de la información (www.proiectus.es) y el nombre y apellidos del autor del artículo referenciado.

ISSN 2340-9363 Lugar de Edición: Las Palmas de Gran Canaria Empresa Editora: IVAN TEJERA PROIECTUS S.L.U. URL: http://www.proiectus.es E-mail: revista@proiectus.es

65