View
201
Download
2
Category
Preview:
DESCRIPTION
Revista sobre dirección de proyectos ágiles
Citation preview
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
Recommended