DIRECCIÓN DE PROYECTOS

ÁGILES

ENTREVISTA: MIKE GRIFFITHS, MIEMBRO

DEL COMITÉ DE DIRECCIÓN CERTIFICACIÓN PMI-ACP®

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

ww

w.p

roie

ctu

s.e

s

N

úm

ero

2,

Abri

l 2014

ISSN 2340-9363

2

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

3

www.proiectus.es Número 2, Abril 2014

5 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®

4

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.

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.

Director revista PROIECTUS

Iván S. Tejera Santana

5

www.proiectus.es Número 2, Abril 2014

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

RESPUESTA AL CAMBIO SOBRE SEGUIR UN PLAN

“Los planes tienen poca importancia, la

planificación es esencial”. Winston Churchill

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,

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.

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.

6

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.

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:

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

A través de este trabajo hemos aprendido a

valorar:

Individuos e interacciones sobre procesos

y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

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.

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

7

www.proiectus.es Número 2, Abril 2014

Fuente: www.freedigitalphotos.net Autor: Salvatores Vuono

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.

El primero de los valores “Individuos y sus

interacciones”, le indicaba a Natalia que necesitaba un equipo cooperativo, multi-

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

Recordó así uno de los Principios que

acompañaban a esos valores ágiles:

PRINCIPIO ÁGIL #1

“Nuestra mayor prioridad es satisfacer al

cliente mediante la entrega temprana y continua de software con valor”

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.

8

www.proiectus.es Número 2, Abril 2014

Fuente: www.freedigitalphotos.net Autor: hin255

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

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.

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

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.

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

“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

9

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.

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.

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

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”

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.

10

www.proiectus.es Número 2, Abril 2014

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

INTRODUCCIÓN

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.

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

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?

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.

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

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.

11

www.proiectus.es Número 2, Abril 2014

con una emoción que en los adultos suele

manifestarse con agresividad y frustración.

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.

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.

Pero antes de proclamarnos mejores amigos

de nuestro cliente vamos a tener que ganarnos su confianza.

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.

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

12

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.

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.

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.

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.

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.

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.

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.

13

www.proiectus.es Número 2, Abril 2014

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.

Ahora acaba de cerrar su último proyecto y

no está contento. Se trataba de un proyecto de consultoría para una gran empresa. El objetivo principal era posicionarse

tecnológicamente por delante de la competencia. Los representantes del cliente

tenían claro que no debían seguir igual, que debían cambiar, pero no sabían qué ni cómo. Asignaron un comité de expertos internos a

la empresa, pero como no avanzaban se decidió contratar una empresa externa. Su

empresa ganó el concurso gracias al enfoque orientado a la flexibilidad, adaptación y colaboración con el personal por parte del

cliente y también gracias que los currículos de los miembros del equipo destacaban su

experiencia en métodos ágiles.

En este proyecto, usted fue consciente desde

el principio de que no iba a ser fácil elaborar un documento de requisitos completo, era

improbable que el cliente lo aceptase formalmente. Tampoco podía comenzar trabajando una EDT, como es su costumbre.

¿Cómo evitar entonces la corrupción del alcance? La única información clara acerca

del cronograma es que había ciertos hitos y el proyecto duraba nueve meses. Lo único claro sobre los costes era el número de horas

contratado por perfil. Con tanta indeterminación, ¿cómo elaborar el plan para

la dirección del proyecto? El cliente quería mantener reuniones de seguimiento bisemanales. ¿Cómo justificar los avances?

Sus jefes le decían que no se preocupase porque los consultores de su equipo tenían

mucha experiencia en proyectos parecidos, que confiara en que harían un buen trabajo.

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.

14

www.proiectus.es Número 2, Abril 2014

Fuente: commons.wikimedia.org Autor: Hkniberg

Sin embargo, usted se preguntaba: Y

entonces yo, ¿para qué estoy aquí?

Por supuesto, usted ya sabía muy bien para

qué estaba usted allí. Le asignaron como director del proyecto por la misma razón que

siempre: para echarle la culpa si el proyecto salía mal. Partiendo de esta certeza, usted tenía dos opciones: o bien dirigir el proyecto

de forma predictiva (invirtiendo esfuerzo en elaborar un plan, tomando supuestos donde

hubiera incertidumbre, haciendo que el cliente aceptase una línea base de requisitos, cronograma, coste, haciendo que los trabajos

planificados se hicieran como estaba previsto, etc.) o bien dirigir el proyecto de

forma adaptativa. La opción de esperar y ver qué hacía el equipo nunca ha sido una opción para usted.

Sus colegas le advertían que este proyecto

era adaptativo por naturaleza y no era sensato dirigirlo a la manera tradicional. Sin hacerles caso, usted se empeñó en

documentar, en ceñirse al contrato y al plan de entregables, en usar una EDT, un sistema

integrado de control de cambios, etc. Usted quería supervisar estrechamente el trabajo de los consultores, pero pronto descubrió que

no podía seguirles. ¿Quizá debería haber atendido a esas reuniones que celebraban

todos los días a las nueve de la mañana al lado de la máquina de café?

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

pero no conseguía que escribieran un

documento de requisitos como usted quería. Cuando les preguntaba, nunca sabían decirle lo que iba a ocurrir más allá de las dos

semanas siguientes. ¿Cómo podían trabajar sin un plan a más largo plazo? Un día,

concretamente, les sorprendió jugando a las cartas y querían convencerle de que estaban trabajando… ¿pero dónde vamos a ir a parar?

Sorprendentemente, los representantes del cliente estaban contentos. Uno de ellos

centralizaba la lista de requisitos, que cambiaba continuamente. Esta persona

atendía a la presentación de avances bisemanal, junto con otros interesados, que

podían variar. El equipo explicaba los resultados, y los interesados aceptaban o no, en ese mismo momento. Si algo no se

aceptaba, tan solo se anotaba como pendiente, sin hacer ningún drama. Después

de esa reunión, tenía lugar otra en la que hablaban del trabajo para las siguientes dos semanas, y justo después otra reunión del

equipo sobre lecciones aprendidas. En estas reuniones usted se sentía fuera de lugar, sin

15

www.proiectus.es Número 2, Abril 2014

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

nada que responder, sin nada que aportar. A

partir de cierto momento, dejó de asistir.

Sorprendentemente, el proyecto terminó en

coste y en plazo y el cliente le llamó un buen

día para felicitarle por el buen 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

contrarios al buen fin del proyecto, ahora se

da perfecta cuenta. Por suerte, su equipo no le hizo caso, ahora reconoce que ellos tenían razón y usted no. También le incomoda

pensar en el futuro próximo. Hoy día ya no es tan raro que los proyectos estén

sometidos por naturaleza a continuos cambios en el alcance, y que exijan que los trabajadores del conocimiento entreguen el

máximo valor posible en el menor plazo, ajustándose a las necesidades cambiantes

del cliente. Es más, últimamente le está pareciendo que la gran mayoría de los

proyectos son así.

Su experiencia le dice que, también en este

tipo de proyectos, usted podría aportar un gran valor con su experiencia en gestión. La próxima vez que tenga un proyecto

adaptativo, usted ya no se mantendrá al margen: 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.

16

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.

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

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

presupuestario muy restrictivo. Usted

puede adaptarse a esos nuevos métodos

para contabilizar costes y estimar plazos sobre la base de las iteraciones, es cálculo básico. Un cliente que necesite cumplir un

objetivo de coste muy restrictivo, apreciará sus conocimientos de gestión por

valor ganado (el sobrecoste hasta la fecha es de tantos miles de euros y como sigamos así, el sobrecoste final será de

tantos otros miles de euros, tendríamos que tomar estas acciones para corregir la

tendencia negativa, etc.)

• Sobre todo, alguien tendrá que encargarse

de gestionar las expectativas de los interesados, asegurar que se cumplen los

estándares impuestos por la PMO, gestionar para resolver impedimentos, anticiparse a posibles problemas, etc. Es

decir: la gestión de proyectos de toda la vida.

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

17

www.proiectus.es Número 2, Abril 2014

referenciadas sabría aplicarlas, si se diera el

caso.

Hasta la fecha, PMI no ha editado un

estándar para gestionar proyectos ágiles, y tampoco hay comunicación publicada en ese

sentido. En su lugar, PMI se limita a recomendar una serie de once libros de referencia muy reconocidos sobre prácticas

ágiles. Con tanta buena literatura ya disponible, quizá sea el enfoque correcto, si

bien son libros muy enfocados en proyectos de tecnología de la información. Por otro lado, y por desgracia para los que no

tenemos buen nivel de inglés, estos once libros no están traducidos al español, y peor

aún, el examen PMI-ACP aún no cuenta con la ayuda de traducción al español. Por el momento el candidato a la certificación PMI-

ACP debe prepararse para estudiar 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

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.

Revista PROIECTUS, Número 1, Septiembre 2013

18

www.proiectus.es Número 2, Abril 2014

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

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

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

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.

19

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.

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.

Lean en cambio, tiene un alcance más amplio

y es más transversal que Scrum. Lean no

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

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

20

www.proiectus.es Número 2, Abril 2014

esta andadura y por el que nuestras

inversiones tengan un objetivo en el tiempo?

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

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

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.

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

21

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.

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.

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

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

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

22

www.proiectus.es Número 2, Abril 2014

Autor: Eduardo Gutiérrez Bahillo

GESTIÓN DEL PRESUPUESTO EN OBRAS PÚBLICAS

INTRODUCCIÓN

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.

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 detalle, se encuentra

con el difícil reto de convertir en rentable una empresa que, a

priori, no lo es, por los motivos que señalaremos a lo largo de este escrito.

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.

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.

Para explicar cómo afecta la normativa por la que se rigen las

administraciones públicas a algunas de las fases de la dirección de proyectos tomaremos

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.

23

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 ADJUDICACIÓN. EL

PUNTO DE PARTIDA

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.

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.

En el presupuesto figuran, de manera

resumida, los siguientes documentos:

• Mediciones.

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

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.

Los precios unitarios son los que se aplicarán a las unidades realmente ejecutadas que

aparecen en el diseño.

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

24

www.proiectus.es Número 2, Abril 2014

Autor: Eduardo Gutiérrez Bahillo

en los términos que establece la ley, el coste

total del proyecto.

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…

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.

Así, debido a la fuerte competencia y al exhaustivo conocimiento que las empresas

constructoras tienen sobre las normativas, regulaciones y procedimientos de la

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.

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.

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.

25

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.

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.

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

Obra?

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.

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.

Además, como complementos adicionales de la gestión económica de la obra tenemos el

programa de anualidades y la forma de pago.

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.

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.

ESTRATEGIAS PARA MEJORAR EL CPI DEL PROYECTO

Fundamentalmente hay 3 estrategias para mejorar el CPI del proyecto.

• Liquidación positiva.

• Modificaciones del contrato

• 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

26

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.

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.

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.

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.

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:

• Imposibilidad de ejecutar el objeto del contrato por errores u omisiones en la

redacción del diseño

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

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.

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.

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.

Los requisitos que deben cumplir estas obras

complementarias son que no puedan separarse del contrato principal ni técnica ni

económicamente.

27

www.proiectus.es Número 2, Abril 2014

Autor: Eduardo Gutiérrez Bahillo

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.

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

principal.

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

obra.

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.

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

28

www.proiectus.es Número 2, Abril 2014

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.

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.

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.

Vamos a analizar a modo de caso práctico, la

situación del proyecto desde el punto de vista

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.

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.

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

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.

29

www.proiectus.es Número 2, Abril 2014

Fuente: Wikimedia Commons Autor: Stan Shebs

esperar a una exhaustiva definición del

alcance, que precisó de un largo proceso (14 meses) durante la fase de oferta.

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.

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.

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

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

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.

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

30

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

31

www.proiectus.es Número 2, Abril 2014

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.

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.

¿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

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.

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

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

32

www.proiectus.es Número 2, Abril 2014

Fuente: Wikimedia Commons Autor: Allan Edwards

los roles pueden producir fricción y conflicto

cuando tienen lugar simultáneamente. En definitiva, se trata de una cuestión de equilibrio.

¿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:

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.

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.

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.

33

www.proiectus.es Número 2, Abril 2014

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

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.

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

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

34

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.

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.

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.

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

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

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

Por el contrario, el Monitor Evaluador tiende

a ser lento en la toma de decisiones, ya que quiere conocer el detalle de cada alternativa

35

www.proiectus.es Número 2, Abril 2014

Fuente: Wikimedia Commons Autor: Antonio Silverio

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.

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

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.

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.

A continuación se muestran algunas

propuestas prácticas de cómo aprovechar las características personales de cada rol en determinadas circunstancias:

Coordinador

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.

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.

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.

36

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.

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.

Investigador de Recursos

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.

Implementador

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.

Finalizador

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

establecidos.

Resulta extremadamente necesario en tareas

que requieren un alto grado de concentración y exactitud.

Especialista

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.

Monitor-Evaluador

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?

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

En el sitio web oficial de Belbin es posible realizar diferentes cuestionarios de auto-

percepció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.

37

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.

38

www.proiectus.es Número 2, Abril 2014

JEFE DE PROYECTO, ¿Y AHORA QUÉ?

INTRODUCCIÓN

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!

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,

pero… ¿cómo vamos a ser capaces de poner

en vereda todo esto?

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.

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

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.

39

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

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.

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.

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

trabajadores. Sí, los jefes de proyecto

también.

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.

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.

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.

Si por presiones externas, comprometemos

para tres meses una tarea que en condiciones normales tardaríamos seis,

40

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?

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.

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.

• 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

(1) The mythical man-month, Frederick Brooks

(2) Contagiar la no interrupción en el equipo

(3) Las ocho actitudes del jefe excelente

41

www.proiectus.es Número 2, Abril 2014

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.

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.

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

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.

Al empezar la semana

A mediados de semana

Al terminar la semana

42

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.

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.

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.

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.

Escenario iterativo con SCRUM

43

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?

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.

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

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…”.

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

Ha pasado que ahora tu proyecto tiene dos

objetivos producir un software y ofrecer un servicio. Un servicio de soporte para los

Escenario desarrollo sin cumplir objetivos

44

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.

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.

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.

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.

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.

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

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:

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

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

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

45

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

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.

Escenario desarrollo con SCRUM e ITIL

46

www.proiectus.es Número 2, Abril 2014

COACHING A EQUIPOS ÁGILES

INTRODUCCIÓN

¿Qué le ocurre a un Project Manager acostumbrado a dar órdenes y asignar tareas

cuando se integra en un equipo ágil?

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

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.

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

la interacción entre los miembros del equipo con objeto de mejorar la calidad de los

productos que se desarrollan.

FACILITAR LAS REUNIONES DIARIAS

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:

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

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

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.

47

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.

Como resultado de estas reuniones, los miembros del equipo coordinan los esfuerzos al tiempo que adquieren un compromiso con

el resto de compañeros.

FACILITAR LAS REUNIONES DE PLANIFICACIÓN DEL SPRINT

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.

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?

¿Cuáles son las historias de usuario y sus

condiciones de satisfacción?

¿Qué es un punto de historia para el

equipo?

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

¿Qué tareas hay que realizar para 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?

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.

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.

48

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.

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:

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

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

producto?

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

Finalizada la reunión, compartiremos los

comportamientos observados con el resto de miembros del equipo al objeto de poder

mejorar su desempeño.

FACILITAR LAS REUNIONES DE

RETROSPECTIVA

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.

En estas reuniones el equipo debe responder

a las siguientes preguntas:

¿Qué se ha hecho bien?

¿Qué se debe mejorar?

¿Qué se debe mejorar en el siguiente sprint?

¿Qué problemas impiden avanzar adecuadamente?

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

(1) Coaching Agile Teams. A companion for ScrumMasters, Agile Coaches, and

Project Manager in Transition.

49

www.proiectus.es Número 2, Abril 2014

LA IMPORTANCIA DEL PLAN DE PRIORIZACIÓN EN LA

GESTIÓN DE LA CARTERA DE PROYECTOS

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.

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

gestionados como un grupo con objeto de alcanzar los objetivos estratégicos”

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

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.

50

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.

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.

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

importantes:

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

• Las decisiones de priorización deben estar

conscientemente alineadas con las estrategias de negocio

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

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.

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

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:

Empresarial

Mercados objetivo

Tipos de productos / servicios

Conocimientos técnicos

51

www.proiectus.es Número 2, Abril 2014

Industria

Los objetivos de inversión

Unidad de Negocio

Área Funcional

Tipo de Cliente

Categoría de gastos

Los clientes internos / externos

Ubicación geográfica

Enfoque del producto

La base de clientes

Segmento de mercado

Competencia

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

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

Los criterios de priorización de proyectos y

escalas de puntuación son específico de cada dominio

Una definición clara de los parámetros de

dominio es esencial

Podemos utilizar características de

proyecto para definir los parámetros de dominio:

Tipo de Proyecto

Principal fuente de recursos

Contribución Negocios

Requiere de inversiones

Tamaño / nivel de esfuerzo

Duración del esfuerzo

Fase del ciclo de vida del proyecto

Grado de definición

3. Identificar las estrategias de la organización

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.

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.

52

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 importantes para crear estos criterios son:

I. Pocos en número

II. No solapados entre si

III. Claramente comprensibles

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:

5. Definir los requisitos de las propuestas.

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

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.

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.

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.

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.

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

53

www.proiectus.es Número 2, Abril 2014

proyecto es crítica para eliminar

duplicidades.

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.

Los criterios de ponderación deben ser fáciles de aplicar; el propósito

fundamental es proporcionar finalmente un ranking proyectos.

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.

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

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:

Penetración en el mercado

1 = Sin nuevos mercados

3 = El crecimiento en los mercados existentes

5 = Introducción al mercado objetivo

• Retorno de la inversión

1 = ROI negativo

3 = Punto de Equilibrio

5 = ROI Positivo

• Utiliza la tecnología existente

1 = difícil de adquirir

3 = fácil adquisición

5 = Sin nueva tecnología

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

portafolio.

CONCLUSIONES

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.

REFERENCIAS

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

54

www.proiectus.es Número 2, Abril 2014

EN ESTE NÚMERO ENTREVISTAMOS A…

ALEJANDRO FORCADES PONS, DIRECTOR GENERAL SM2 BALLEARES S.A.

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

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 IB-Salut.

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.

55

www.proiectus.es Número 2, Abril 2014

TALAIA se anuncia con frases como “la 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

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.

Y sobre esta base argumentaron la solicitud

de la ayuda Avanza2. ¿Acudieron a la ayuda individualmente como SM2?

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.

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

56

www.proiectus.es Número 2, Abril 2014

Por favor, desarrolle un poco cada uno de los

puntos. ¿Qué significa “conforme a estándares”?

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

¿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,

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.

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

57

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?

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.

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.

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.

58

www.proiectus.es Número 2, Abril 2014

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.

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?

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.

The intended purpose is to create a credible, robust credential that participants and hiring

managers can trust to demonstrate a base

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.

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?

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.

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.

59

www.proiectus.es Número 2, Abril 2014

The advent of fixed price work packages and

more granular SOWs make the process easier too.

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?

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.

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.

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

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.

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.

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.

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.

60

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

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.

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.

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.

What techniques can teams apply to

minimize the technical debt generated throughout the project?

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:

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

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

61

www.proiectus.es Número 2, Abril 2014

since people often miss being on a high

performing team.

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.

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.

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,

62

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.

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.

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.

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.

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.

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 off-putting or intimidating are counter

productive.

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.

63

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.

64

www.proiectus.es Número 2, Abril 2014

ENTIDADES COLABORADORAS

65

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