ÁGILES - ITPROIECTUS

Número 2, Abril 2014
DIRECCIÓN DE PROYECTOS
ÁGILES
ENTREVISTA: MIKE GRIFFITHS, MIEMBRO
DEL COMITÉ DE DIRECCIÓN CERTIFICACIÓN PMI-ACP
®
www.proiectus.es
LA VELOCIDAD, LA BOTELLA, LAS PELOTAS, LA ARENA… E ¿ITIL?
LA GESTIÓN DE RIESGOS EN MEGAPROYECTOS
GESTIÓN DE PRESUPUESTOS EN OBRA PÚBLICA
COACHING A EQUIPOS ÁGILES
GESTIÓN DE PROYECTOS Y PROGRAMAS CON OPENPPM
ISSN 2340-9363
www.proiectus.es
Número 2, Abril 2014
DIRECCIÓN DE LA REVISTA
Iván Samuel Tejera Santana
[email protected]
EQUIPO EDITORIAL
ITPROIECTUS
www.proiectus.es
COMUNICACIÓN Y DIFUSIÓN
Antonio Martel Rodríquez
Lucas Ferrera Hernández
ASESORAMIENTO LEGAL
Javier Rodríguez Batllori Laffitte
TRADUCCIÓN
Mónica Khiani Ashok
COLABORADORES
Luis Antonio Salazar-Caraballo
Davide Mazzanti
Jose Barato Arroyo
Antonio Domingo Medina Díaz
Eduardo Gutiérrez Bahillo
Mario Coquillat de Travesedo
Antonio Pedro Dorta Alonso
Agustín Tapia Quesada
Manuel Vara González
Alejandro Forcades Pons
Mike Griffiths
2
www.proiectus.es
5
Número 2, Abril 2014
RESPUESTA AL CAMBIO SOBRE SEGUIR UN PLAN
Luis Antonio Salazar-Caraballo, ISI Scrum Master
10
CÓMO CONVERTIR A TU PEOR CLIENTE EN TU MEJOR ALIADO
Davide Mazzanti
13
EL DIRECTOR DE PROYECTOS ÁGIL
Jose Barato Arroyo, PMP®, PMI-ACP®
18
EL CAMINO HACIA LA ORGANIZACIÓN ÁGIL
Antonio Domingo Medina Díaz, CAPM®
22
GESTIÓN DEL PRESUPUESTO EN OBRAS PÚBLICAS
Eduardo Gutiérrez Bahillo, PMP®
28
LA GESTIÓN DE RIESGOS EN MEGAPROYECTOS
Mario Coquillat de Travesedo, PMP®, PMI-RMP®
31
LOS ROLES DE BELBIN Y LA DIRECCIÓN DE PROYECTOS
Antonio Pedro Dorta Alonso, PMP®
38
JEFE DE PROYECTO, ¿Y AHORA QUÉ?
Antonio Martel Rodríguez, PSM® I
41
LA VELOCIDAD, LA BOTELLA, LAS PELOTAS, LA ARENA… E ¿ITIL?
Agustin Tapia Quesada
46
COACHING A EQUIPOS ÁGILES
Iván Samuel Tejera Santana, PMP®, PSM® I
49
LA IMPORTANCIA DEL PLAN DE PRIORIZACIÓN EN LA GESTIÓN DE LA CARTERA DE
PROYECTOS
Manuel Vara González, PMP®
54
ENTREVISTA: OPENPPM, HERRAMIENTA GESTIÓN DE PROYECTOS Y PROGRAMAS
Alejandro Forcades Pons, Director General SM2 Baleares
58
ENTREVISTA: MIEMBRO DEL COMITÉ DE DIRECCIÓN DE LA CERTIFICACIÓN PMI-ACP®
Mike Griffiths, PMP®, PMI-ACP®
3
www.proiectus.es
Número 2, Abril 2014
CARTA DEL DIRECTOR
Bienvenid@s a este segundo número de la revista PROIECTUS, publicación MADE IN
CANARIAS desarrollada por y para profesionales vinculados a la Dirección de Proyectos.
Han pasado cuatro meses desde la presentación oficial
del primer número de la revista en las I Jornadas de
Dirección de Proyectos. Desde entonces, las miles de
impresiones en slideshare y el deseo de continuar
potenciando la figura del Director de Proyectos se han
constituido en nuestro aval para continuar apostando por
el desarrollo de la revista.
Condicionados por la repercusión del primer número, en
este segundo número hemos querido subir el listón
dando la oportunidad de participar a un mayor número
de profesionales, lo que sin duda nos ha permitido
enriquecer los contenidos de la revista con una mayor
calidad y heterogeneidad de artículos.
Director revista PROIECTUS
Iván S. Tejera Santana
Síntoma de este crecimiento es el hecho de que más de un 90% de los colaboradores de la
revista cuenta con algún tipo de certificación en Dirección de Proyectos, señal inequívoca de que
estamos consiguiendo que Directores de Proyecto con experiencia compartan conocimiento con
otros profesionales que se inician en la profesión.
Si en el anterior número pudimos entrevistar a la Jefa del Proyecto de Traducción de la Guía de
Fundamentos para la Dirección de Proyectos PMBOK®5, en esta ocasión, contamos con la
inestimable colaboración de Mike Griffiths, miembro del Comité de Dirección encargado de definir
las habilidades, herramientas y técnicas que conforman los contenidos del examen PMI-ACP®
(Agile Certified Practitioner).
Tod@s los que formamos el equipo PROIECTUS esperamos que este número os resulte igual
de interesante que el anterior, a fin de cuentas, si la revista existe es gracias a vosotros.
Lo realmente importante no es llegar a la cima, sino saber mantenerse en ella.
4
www.proiectus.es
Número 2, Abril 2014
LUIS ANTONIO SALAZAR-CARABALLO, PSM®
Consultor en Metodologías y Arquitecturas de Software de Intergrupo, en
Colombia. Conduce evaluaciones de la situación actual de los procesos de
desarrollo de software y propone e implanta soluciones para la mejora de los
procesos
de
TI,
incluyendo
estrategias
para
gerencia
de
proyectos,
administración de riesgos y manejo del entorno de los proyectos con marcos de
gestión ágiles. Actualmente es agility champion de Intergrupo.
RESPUESTA AL CAMBIO SOBRE SEGUIR UN PLAN
“Los planes tienen poca importancia, la
planificación es esencial”. Winston Churchill
sino que perdería muchos otros, lo que
podría golpear severamente sus márgenes de
ganancia durante el primer semestre del año.
Para suerte de Natalia, el señor Pérez había
hecho su tarea, ya sabía que debía actualizar
las herramientas de software de mercadeo y
ventas para soportar una promoción agresiva
que debería estar al aire en la TV y en las
redes sociales dos horas antes que la de su
competidor.
BASADO EN HECHOS HISTÓRICOS
Natalia es gerente de proyectos de una
importante compañía proveedora de servicios
de tecnología. Es la encargada de la
operación en uno de los clientes más grandes
de la empresa: un conglomerado de telefonía
móvil.
Hacia el final de esta mañana la llamó el
director de mercadeo de esa organización
bastante alarmado:

Natalia, te paso a Juan Pérez de móviles
del Sur.

Hola Juan, ¿en qué te puedo ayudar?
Lo que siguió fue toda una perorata que
inquietó a Natalia. El cliente le contó cómo
durante la mañana se enteró de la Promoción
Rumbo al Mundial Brasil 2014 que su más
encarnizado competidor sacaría a la luz la
noche de ese día. Pérez sabía que de no
responder efectiva y rápidamente no solo
dejaría de ganar cientos o miles de clientes,
Fuente: www.freedigitalphotos.net
Autor: Vichaga Kiatying-Angs
5
www.proiectus.es
Número 2, Abril 2014
Mientras Pérez hablaba, Natalia revisaba
rápidamente el proceso de control de cambio
de la compañía y concluyó que podría
entregarle una propuesta de trabajo que
incluyera el impacto de la actualización del
software en costo y presupuesto a su cliente
pero solo hasta el día siguiente. Era inaudito,
mientras Juan Pérez estaba buscando una
respuesta ágil y eficiente que concluyera con
un resultado de valor en las próximas 8
horas, Natalia se enfrentaba a la disyuntiva
de seguir un proceso clásico de estimación a
priori y modificación del plan de trabajo,
previo análisis de impacto y de costos, que
redundaría en una pérdida tanto para su
compañía como para la de su cliente, o
simplemente
responderle
firme
y
positivamente
que
cumpliría
la
meta
establecida para las siguientes horas.
A través de este trabajo hemos aprendido a
valorar:

Individuos e interacciones sobre procesos
y herramientas

Software
funcionando
documentación extensiva
sobre

Colaboración
con
el
negociación contractual
sobre

Respuesta ante el cambio sobre seguir un
plan
cliente
Esto es, aunque valoramos los elementos de
la derecha, valoramos más los de la
izquierda.
El resultado de este trabajo, fruto de la
colaboración de 17 personajes reconocidos
en la industria del software en 2001, serviría
a Natalia como pilar fundamental para
encontrar una solución de valor para su
cliente. Los Valores y Principios Ágiles
enfatizan en la importancia de colaboración e
interacción en el desarrollo de software y, de
otro lado, el trabajo creativo involucra
comúnmente alguna forma de colaboración y
puede entenderse como una interacción
entre
un
individuo
y
un
contexto
sociocultural.
EL MANIFIESTO DE DESARROLLO ÁGIL DE
SOFTWARE
Por suerte para Natalia, ella también había
hecho su tarea. En los últimos tiempos había
empezado un proceso de transformación en
sus equipos que incluía una forma de ver el
mundo de manera distinta a como lo venían
haciendo en la compañía. Se trataba de todo
un ecosistema basado en una cadena de
valores y principios que rompían con los
esquemas tradicionales de hacer software.
Todo empezaba con el así llamado Manifiesto
por el Desarrollo Ágil de Software o,
simplemente, Manifiesto Ágil, el cual le daría
la clave para ganar ese día:
Los proyectos tradicionales están plagados
de
equipos
conducidos
por
gerentes,
organizados en una estructura jerárquica con
múltiples capas de autoridad. Esta gerencia
es del estilo de “comando y control” y los
roles se basan en tareas funcionales que, en
el caso del software, son los programadores,
los diseñadores, los analistas, etc. El trabajo
se delega a los miembros del equipo por sus
jefes. Las prácticas en estos equipos incluyen
Estamos descubriendo formas mejores de
desarrollar software tanto por nuestra propia
experiencia como ayudando a terceros.
6
www.proiectus.es
Número 2, Abril 2014
copiosa
documentación,
especificaciones
previas y planeación detallada. Las líneas de
comunicación son indirectas entre las
distintas capas de la jerarquía organizacional
y el empoderamiento es algo invisible para la
mayoría de los participantes, lo mismo que el
estado general del proyecto.
Recordó así uno de los Principios
acompañaban a esos valores ágiles:
que
PRINCIPIO ÁGIL #1
“Nuestra mayor prioridad es satisfacer al
cliente mediante la entrega temprana y
continua de software con valor”
El primero de los valores “Individuos y sus
interacciones”, le indicaba a Natalia que
necesitaba un equipo cooperativo, multifuncional
y
auto-suficiente,
experto,
altamente productivo y creativo que se
comunicara con su cliente y trabajara con él
el resto de la tarde, no solo en la extracción
de conocimiento típica de los proyectos
actuales, sino en todo el ciclo de producción
que le permitiera a Móviles del Sur poner en
funcionamiento una solución automatizada
que soportara su ambicioso programa de
retención y captura de clientes con motivo
del evento mundialista de los próximos
meses.
Natalia sabía que la filosofía ágil tiene la
habilidad de amplificar la productividad de los
equipos de software hasta una escala de gran
magnitud, a través del empoderamiento de
las personas, fomentando un entorno
orientado-al-equipo y enfocándose en la
transparencia del proyecto y en los
resultados. Estos proyectos pasaron de ser
dirigidos-por-el-plan a estar enfocados en el
producto, uno priorizado por y de valor para
el cliente. Estos equipos se identifican a sí
mismos como una unidad social dentro de la
organización de la cual hacen parte y a
quienes se les confía la ejecución del trabajo
y se les proporciona el entorno y el apoyo
que necesitan, para mantenerlos motivados,
como invoca otro de los principios del
Manifiesto Ágil, y para aumentar su apego
emocional a la empresa.
Si bien se trata de un conjunto de Valores, el
último de estos, pero no por eso menos
importante, no devalúa la planificación, en la
práctica solo se adhiere al plan. La
planificación es valiosa en sí misma; y dado
que el plan nos asiste en la tarea de
reconocer cuándo las cosas han cambiado,
también
nos
ayuda
a
entender
las
implicaciones del cambio, cómo tenemos que
ajustarnos y cuál es el costo probable. Lo
importante es que, a medida que hacemos
planes, entendamos que el plan puede
cambiar.
Fuente: www.freedigitalphotos.net
Autor: Salvatores Vuono
7
www.proiectus.es
Número 2, Abril 2014
La planificación es una actividad continua que
incluye:
•
Reuniones de planificación de iteración
•
Reuniones diarias
•
Reuniones de revisión
•
Retrospectivas
•
Evaluación de riesgos
producción. Si son bien manejados, los
cambios brindan muchos beneficios a los
usuarios, el primero de ellos, ventaja
competitiva.
Los
cambios
son
una
herramienta invaluable para crear productos
inmejorables.
Planificación clásica vs Planificación ágil
Cada una de esas ceremonias sirve no solo
para planear sino también para inspeccionar
el estado del proyecto y crear mecanismos
de adaptación en caso de ser necesario. El
grueso de los practicantes de la industria y
quienes la miran desde los tejados, cree que
los equipos ágiles son desorganizados,
informales, que no documentan y sobre todo
que no planean. Todo eso se debe en parte a
la mala lectura que le dan al mismísimo
Manifiesto Ágil. Pero no es así. Contrario a lo
que ocurre en los modelos tradicionales de
planificación, donde se planea al comienzo,
se elaboran planes de dos, tres o más
niveles, y se hace seguimiento a ese plan
durante el resto del proyecto, un seguimiento
que raya en el acoso, los equipos ágiles
planean todos los días.
Fuente: www.freedigitalphotos.net
Autor: hin255
Era precisamente lo que necesitaba Juan
Pérez ese día. Otro de los principios ágiles
llevó a Natalia a esa conclusión:
PRINCIPIO ÁGIL #2
En parte eso se debe a que los equipos ágiles
saben que los cambios hacen parte
inherente, son constituyente primario del
ADN, del ciclo de vida del software. Los
cambios
pueden
ocurrir
en
cualquier
momento, desde las etapas iniciales del
proyecto, aun cuando apenas se están
conociendo las necesidades del usuario,
hasta las fases tardías del proyecto, quizás
cuando estamos a punto de salir a
“Aceptamos que los requisitos cambien,
incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para
proporcionar ventaja competitiva al cliente”
En cambio, los enfoques tradicionales de
gerencia de proyectos presentan los cambios
como un monstruo con el que hay luchar a
sangre y fuego. Los procedimientos rigurosos
de control de cambio, típicos de estos
8
www.proiectus.es
Número 2, Abril 2014
enfoques, causan la pérdida de oportunidad
que los clientes tienen para ganar más
mercado y para crear mejores productos. En
general, a medida que el tiempo avanza, la
habilidad de hacer cambios disminuye y
cuesta más. Esto es lo que enfrentan los
procesos ágiles, aunque sin dejar de planear.
Los métodos ágiles promueven planes más
livianos y de alto nivel a largo plazo,
mientras que atienden la elaboración de
agendas bien detalladas a corto plazo, las de
la iteración actual, que solo tarda unos pocos
días o muy pocas semanas. En Scrum, por
ejemplo, las iteraciones tardan máximo
cuatro semanas y con frecuencia mucho
menos que eso.
resonancia no solo en su cliente sino en sus
usuarios, uno que haga que la gente
experimente distintas reacciones de gozo al
usarlo, sin hablar de los ingresos en que
redundaría su uso. No se trataba solo de
actualizar un pedazo de software existente,
sino de producir algo no ordinario que tuviera
la capacidad de atraer a una audiencia cada
vez mayor. Otro de los principios ágiles fue el
último consejo que le dio al equipo antes de
despedirlo hacia lo que seguramente sería un
éxito total:
PRINCIPIO ÁGIL #10
“La simplicidad, o el arte de maximizar la
cantidad de trabajo no realizado, es esencial”
Al principio de los proyectos ágiles se
planean las entregas o salidas a producción
tempranas, beneficio primario que nos traen
los procesos ágiles. Estas salidas a
producción pueden ser cada tres meses, pero
hoy
contamos
con
la
tecnología
y
plataformas lo suficientemente maduras
como para hacer continuous delivery o
entregas continuas. Amazon, por ejemplo, la
vendedora al detal más grande del mundo,
sale a producción cada 11,6 segundos, algo
absolutamente asombroso si tenemos en
cuenta la cantidad de clientes recurrentes
simultáneos que tiene su sitio Web cada
segundo. Natalia sabía todo eso, entonces no
dudó
que
podía
tener
un
producto
funcionando para antes de las 8 de la noche
de ese día, meta principal de su cliente.
REFERENCIAS
(1) Mitos, monstruos, leyendas urbanas y
otros desvaríos de ágil y scrum.
(2) Planificación del sprint: el primer paso
para producir el máximo efecto.
(3) Compendio sobre el scrum diario.
(4) Cultura ágil: ese oscuro objeto del deseo.
(5) Sí, usted está listo para implementar un
proyecto ágil.
Resultado final
Mientras hacia un recorrido por los
acontecimientos de la hora, Natalia convocó
a un equipo idóneo, uno que sabía capaz de
elaborar
un
producto
que
generara
9
www.proiectus.es
Número 2, Abril 2014
DAVIDE MAZZANTI
Project Manager para Teléfonica y Vodafone.
Business Engineer, graduado por la Universidad de Bologna, ha desarrollado su
carrera profesional entre las ciudades de Las Palmas de Gran Canaria, Milán y
Alemania. Experto en innovación.
CÓMO CONVERTIR A TU PEOR CLIENTE EN TU MEJOR ALIADO
INTRODUCCIÓN
en el menor tiempo posible. Pero a menudo
sucede que las cosas se complican bastante y
la relación con nuestro cliente termina
convirtiéndose en una pesadilla. ¿Cómo
solucionarlo? Y mejor todavía, ¿cómo evitarlo
desde el principio?
La primera y única clase de baile que tuve en
mi vida me enseñó una lección bastante
importante. El profesor nos explicó que el
baile es cosa de dos. Da igual que seas el
mejor bailarín de este mundo, si no tienes
una buena complicidad con tu pareja tu
actuación está destinada al desastre.
MIEDO AL CAMBIO
El cambio es un estado traumático. ¿Quién
recuerda el pasaje de la infancia a la
adolescencia como un momento sereno de su
vida? Como seres humanos solemos preferir
estabilidad y situaciones que podamos
controlar. Mientras que el cambio nos obliga
a salir de nuestra zona de seguridad, nos
expone a nuevos problemas y a nuevas
amenazas.
La misma lección la podemos aplicar a la
gestión de proyectos, asociando un proyecto
a un gran baile. En el escenario hay un
amplio grupo de bailarines siguiendo una
coreografía, pero al centro de la atención se
encuentran el Project Manager y el cliente.
Estos dos bailarines son los responsables de
la actuación, y de ellos depende el éxito de la
misma. Es muy importante que entiendan
desde el principio que luchan por un mismo
objetivo. Ambos van a tener que aprender
cómo moverse al unísono para conseguir una
óptima representación.
Como
Project
Managers
estamos
acostumbrados a estas situaciones, y
posiblemente incluso nos guste esa sensación
de miedo cada vez que nos adentramos en
un nuevo proyecto. Vamos a tener que ser
muy empáticos para no olvidarnos de que
nuestros clientes no viven el cambio con la
misma seguridad que nosotros. Es bastante
probable que lo vivan con incertidumbre, y
Como Project Managers sabemos que nuestro
cliente
es
nuestro
stakeholder
más
importante. Sabemos también que tenerlo de
nuestro lado significa poder desarrollar
nuestro proyecto de la forma más eficiente y
10
www.proiectus.es
Número 2, Abril 2014
con una emoción que en los adultos suele
manifestarse con agresividad y frustración.
Pero antes de proclamarnos mejores amigos
de nuestro cliente vamos a tener que
ganarnos su confianza.
Estas emociones son las principales causas
de las malas relaciones entre Project
Manager y cliente. Aunque creamos tener el
proyecto perfectamente controlado, si el
cliente no se encuentra cómodo con nosotros
encontrará la forma de complicarnos la vida.
Es posible que empiece a cuestionarnos
cualquier decisión, nos bloquee las obras o
que incluso vaya a quejarse de la gestión del
proyecto a nuestros superiores. Son señales
de que no hemos dedicado suficiente tiempo
a conocer a nuestro cliente, limitándonos a
trabajar en los aspectos más concretos del
proyecto.
FALTA DE CONFIANZA
A menudo se nos olvida que cada día
llevamos puesto un uniforme. No es tan
llamativo como la divisa de un policía o de un
paramédico, pero igualmente nos identifica
de forma inequivocable. Mientras nos
estamos encargando de la dirección de un
proyecto nos convertimos en la cara pública
de nuestra empresa.
Esta posición puede resultar bastante
incómoda, sobre todo si nos paramos a
reflexionar sobre la reputación de nuestra
empresa en el mundo exterior. Si es una
empresa
grande,
posiblemente
haya
cometido algún fallo en el pasado o haya
salido en la prensa por alguna situación
embarazosa. Puede suceder también que
nuestra empresa sea más pequeña y no
tenga una gran relevancia pública. En ambos
casos heredamos una carga negativa que nos
penaliza incluso antes de empezar.
Para evitar que todo esto ocurra, vamos a
asegurarnos de que le acompañamos a lo
largo del proceso de cambio. Vamos a ser su
ancla, su estrella polar. Nos convertiremos
durante todo el proyecto en el punto de
referencia para cualquier asunto relacionado
con el mismo. Y deberemos tener los ojos
bien abiertos para captar cualquier señal de
frustración e inseguridad.
Antes de intentar ganarnos la confianza de
nuestro
cliente
vamos
a
tener
que
esforzarnos en superar el muro de prejuicio
que nos separa. ¿Cómo? Aprovechando esa
divisa que llevamos puesta y convirtiéndonos
en el único punto de contacto entre el cliente
y cualquier necesidad pueda tener con
relación a nuestra empresa.
Digamos que nuestro cliente necesita un
certificado emitido por nuestro departamento
de administración o que no está satisfecho
con algún trabajo realizado antes de nuestra
llegada. Ambos ejemplos tocan temas que
están fuera de nuestra jurisdicción como
11
www.proiectus.es
Número 2, Abril 2014
Project Managers pero no están fuera de
nuestro alcance como representantes de la
empresa. En vez de ignorar las peticiones del
cliente podemos involucrarnos para ayudarle
a solucionar sus problemas gracias a
nuestros contactos internos. No importa lo
sencilla
o
complicada
que
sea
una
determinada tarea: vamos a convertirnos en
la única interfaz a la que tendrá que acudir.
Por eso mi consejo es dedicar todo el tiempo
necesario a la gestión del cliente. Cada hora
destinada a estrechar nuestra relación con él
es una inversión a largo plazo sobre la
estabilidad del proyecto. Mientras más nos
apoye, más delegará en nosotros la ejecución
de las diferentes fases del proyecto, sin
cuestionar los detalles. Su fe en nuestra
profesionalidad le ayudará a mantenerse al
margen de la operatividad.
La parte difícil está en la superación del
binomio
Project
Manager/Alcance
del
proyecto. Vamos a tener que salir de nuestro
pequeño entorno delimitado por las fronteras
del proyecto y extender nuestro radio de
acción a toda la empresa. De esta forma le
estaremos restando complejidad al cliente,
dejando que se enfoque únicamente en los
temas importantes. Lentamente veremos que
su confianza en nuestra habilidad de
solucionar problemas irá creciendo.
No debemos olvidarnos de informarle
tempestivamente apenas surja cualquier
obstáculo y de prepararle detallados informes
de seguimiento durante las fases más
críticas. La confianza es un bien muy valioso,
que cuesta mucho esfuerzo conseguir y que
podemos perder en pocos segundos si no
tenemos el suficiente cuidado.
En definitiva, el clásico error de muchos
Project Managers es centrarse en las
metodologías y olvidarse de quien les rodea.
Al estar rodeados por tablas de excel,
diagramas de Gantt y Backlog de productos
tienden a olvidarse de que los proyectos no
son
solo
datos
y
fórmulas.
Son
principalmente personas, con todas sus
fortalezas y debilidades.
EL MEJOR ALIADO
Fortalecer la relación con nuestro cliente
puede ayudarnos a descubrir algunos detalles
de la organización que se mueve detrás de
él. No es de sorprender que muchas de las
inversiones de ruta a mitad de un proyecto
no sean decisiones directas de nuestro
cliente, sino el resultado de discusiones
internas en la empresa.
Nuestras habilidades más intangibles, o soft
skills, son iguales de importantes que
nuestra
aplicación
de
las
correctas
metodologías de gestión de proyecto. Con la
dificultad adicional de que no podemos
simplemente pedir que los demás crean en
nosotros. Cada vez que empecemos un
nuevo proyecto vamos a tener que volver a
ganarnos la confianza de nuestro nuevo
cliente.
Conocer los detalles de su organización,
cómo se mueve y con qué ritmo se toman las
decisiones, es un valioso recurso que nos
ayuda a reducir el riesgo y tomar las
adecuadas medidas preventivas. Gracias a
esta información, nuestro cliente nos está
regalando tiempo extra para prepararnos
cada vez que haya un eventual cambio de
programa.
12
www.proiectus.es
Número 2, Abril 2014
JOSE BARATO ARROYO
Jose Barato es el Director de PMPeople, empresa especializada en formación,
consultoría y gestión de proyectos. Desde 2009, participa en el proyecto
opensource TALAIA OpenPPM, consistente en la creación, difusión y servicio
sobre un producto de software libre para gestionar proyectos, programas y
portfolios consistente con los estándares de PMI.
EL DIRECTOR DE PROYECTOS ÁGIL
Imagine este caso: Usted es Director de
Proyectos. Cuenta con mucha experiencia
dirigiendo proyectos y siente verdadera
vocación por esta actividad, que considera su
profesión. Ya hace más de diez años que se
certificó PMP®. Usted ha tenido continuas
muestras
de
reconocimiento
en
sus
proyectos, dentro y fuera de su empresa.
Incluso ha impartido algún curso sobre
fundamentos de gestión de proyectos, sobre
gestión de riesgos, sobre la herramienta
Microsoft
Project©,
etc.
También
ha
participado como voluntario en algún
proyecto de PMI®, y le han invitado como
ponente a un par de congresos. Todo parece
indicarle que es un buen profesional, muy
respetado. Cuando usted habla de algo
relacionado con la gestión de proyectos, la
gente le escucha con atención. Muchos
colegas valoran su opinión experta.
la empresa, pero como no avanzaban se
decidió contratar una empresa externa. Su
empresa ganó el concurso gracias al enfoque
orientado a la flexibilidad, adaptación y
colaboración con el personal por parte del
cliente y también gracias que los currículos
de los miembros del equipo destacaban su
experiencia en métodos ágiles.
En este proyecto, usted fue consciente desde
el principio de que no iba a ser fácil elaborar
un documento de requisitos completo, era
improbable que el cliente lo aceptase
formalmente. Tampoco podía comenzar
trabajando una EDT, como es su costumbre.
¿Cómo evitar entonces la corrupción del
alcance? La única información clara acerca
del cronograma es que había ciertos hitos y
el proyecto duraba nueve meses. Lo único
claro sobre los costes era el número de horas
contratado
por
perfil.
Con
tanta
indeterminación, ¿cómo elaborar el plan para
la dirección del proyecto? El cliente quería
mantener
reuniones
de
seguimiento
bisemanales. ¿Cómo justificar los avances?
Sus jefes le decían que no se preocupase
porque los consultores de su equipo tenían
mucha experiencia en proyectos parecidos,
que confiara en que harían un buen trabajo.
Ahora acaba de cerrar su último proyecto y
no está contento. Se trataba de un proyecto
de consultoría para una gran empresa. El
objetivo
principal
era
posicionarse
tecnológicamente
por
delante
de
la
competencia. Los representantes del cliente
tenían claro que no debían seguir igual, que
debían cambiar, pero no sabían qué ni cómo.
Asignaron un comité de expertos internos a
13
www.proiectus.es
Número 2, Abril 2014
Sin embargo, usted se preguntaba: Y
entonces yo, ¿para qué estoy aquí?
pero no conseguía que escribieran un
documento de requisitos como usted quería.
Cuando les preguntaba, nunca sabían decirle
lo que iba a ocurrir más allá de las dos
semanas siguientes. ¿Cómo podían trabajar
sin un plan a más largo plazo? Un día,
concretamente, les sorprendió jugando a las
cartas y querían convencerle de que estaban
trabajando… ¿pero dónde vamos a ir a parar?
Por supuesto, usted ya sabía muy bien para
qué estaba usted allí. Le asignaron como
director del proyecto por la misma razón que
siempre: para echarle la culpa si el proyecto
salía mal. Partiendo de esta certeza, usted
tenía dos opciones: o bien dirigir el proyecto
de forma predictiva (invirtiendo esfuerzo en
elaborar un plan, tomando supuestos donde
hubiera incertidumbre, haciendo que el
cliente aceptase una línea base de requisitos,
cronograma, coste, haciendo que los trabajos
planificados
se
hicieran
como
estaba
previsto, etc.) o bien dirigir el proyecto de
forma adaptativa. La opción de esperar y ver
qué hacía el equipo nunca ha sido una opción
para usted.
Sus colegas le advertían que este proyecto
era adaptativo por naturaleza y no era
sensato dirigirlo a la manera tradicional. Sin
hacerles caso, usted se empeñó en
documentar, en ceñirse al contrato y al plan
de entregables, en usar una EDT, un sistema
integrado de control de cambios, etc. Usted
quería supervisar estrechamente el trabajo
de los consultores, pero pronto descubrió que
no podía seguirles. ¿Quizá debería haber
atendido a esas reuniones que celebraban
todos los días a las nueve de la mañana al
lado de la máquina de café?
Fuente: commons.wikimedia.org
Autor: Hkniberg
Sorprendentemente, los representantes del
cliente estaban contentos. Uno de ellos
centralizaba la lista de requisitos, que
cambiaba continuamente. Esta persona
atendía a la presentación de avances
bisemanal, junto con otros interesados, que
podían variar. El equipo explicaba los
resultados, y los interesados aceptaban o no,
en ese mismo momento. Si algo no se
aceptaba, tan solo se anotaba como
pendiente, sin hacer ningún drama. Después
de esa reunión, tenía lugar otra en la que
hablaban del trabajo para las siguientes dos
semanas, y justo después otra reunión del
equipo sobre lecciones aprendidas. En estas
reuniones usted se sentía fuera de lugar, sin
Usted se perdía sobre todo con la
terminología
que
empleaban.
¿Qué
significarían esos términos tales como sprint,
pila de producto, quemado de tareas,
impedimento, retrospectiva, historias de
usuario, etc.? ¿Por qué medían el tamaño de
los requisitos en puntos de historia y no en
esfuerzo? Tenían la pared llena de post-its,
14
www.proiectus.es
Número 2, Abril 2014
nada que responder, sin nada que aportar. A
partir de cierto momento, dejó de asistir.
contrarios al buen fin del proyecto, ahora se
da perfecta cuenta. Por suerte, su equipo no
le hizo caso, ahora reconoce que ellos tenían
razón y usted no. También le incomoda
pensar en el futuro próximo. Hoy día ya no
es tan raro que los proyectos estén
sometidos por naturaleza a continuos
cambios en el alcance, y que exijan que los
trabajadores del conocimiento entreguen el
máximo valor posible en el menor plazo,
ajustándose a las necesidades cambiantes
del cliente. Es más, últimamente le está
pareciendo que la gran mayoría de los
proyectos son así.
Sorprendentemente, el proyecto terminó en
Su experiencia le dice que, también en este
tipo de proyectos, usted podría aportar un
gran valor con su experiencia en gestión. La
próxima vez que tenga un proyecto
adaptativo, usted ya no se mantendrá al
margen: Pero el ritmo vertiginoso al que se
mueve el mercado en el que operan hace que
las estrategias de cambio que necesitan
implementar
las
organizaciones
para
mantenerse en vanguardia, o no quedarse
atrás, magnifica el impacto de la falta de
conexión entre las estrategias y las
operaciones del día a día.
Fuente: commons.wikimedia.org
Autor: Rakuten, Inc.
coste y en plazo y el cliente le llamó un buen
día para felicitarle por el buen trabajo que
había realizado su equipo: Aunque quedaban
temas pendientes, como eran de menor
importancia, ya no les merecía la pena seguir
empleando
recursos.
Y
no
menos
sorprendente resultó la satisfacción de los
propios integrantes del equipo, como usted
mismo pudo comprobar en la cena de
celebración de fin de proyecto. Allí había
surgido un equipo sinérgico y cohesionado,
sin duda, listo para el siguiente proyecto sin
apenas supervisión. Su empresa había
experimentado un gran retorno en forma de
crecimiento
profesional
y
capacitación
personal. Usted brindó por ello.
Así pues, el proyecto fue un rotundo éxito,
pero usted no está contento. Tiene la
sensación incómoda de que el proyecto ha
sido un éxito no gracias a usted, sino a pesar
de usted. Usted quiso imponer unos métodos
15
www.proiectus.es
Número 2, Abril 2014
• En el proyecto que acaba de terminar, el
cliente centralizaba los requisitos, pero
esto no es habitual. ¿No podría usted
desempeñar este rol? ¿Cómo lo llamaban?
¿Product Owner (PO)? Pues venga, seamos
Product Owner si así lo exige el proyecto.
puede adaptarse a esos nuevos métodos
para contabilizar costes y estimar plazos
sobre la base de las iteraciones, es cálculo
básico. Un cliente que necesite cumplir un
objetivo
de
coste
muy
restrictivo,
apreciará sus conocimientos de gestión por
valor ganado (el sobrecoste hasta la fecha
es de tantos miles de euros y como
sigamos así, el sobrecoste final será de
tantos otros miles de euros, tendríamos
que tomar estas acciones para corregir la
tendencia negativa, etc.)
• También ha habido suerte porque en este
caso, el equipo ya estaba prácticamente
formado. ¿Qué habría pasado si, como
suele ser habitual, los miembros del
equipo deben descubrir y crecer en su
asignación particular durante el proyecto?
Ya ha comprobado la ventaja de tener un
equipo auto-organizado, pero usted sabe
que esto no ocurre por generación
espontánea, hay que facilitarlo. Quizá un
liderazgo servicial sea lo más aplicable en
el
contexto
de
los
proyectos
no
predictivos. Siguiendo la teoría del
liderazgo adaptado a la situación, le
parece adecuado que su estilo atraviese
las
conocidas
fases:
1)
dirigir
estrechamente; 2) coaching; 3) dar
soporte y 4) delegar. Acompasadamente
con estas fases de liderazgo, espera que
su equipo atravesará las consabidas fases
del modelo de Tuckman: 1) formación; 2)
turbulencia;
3)
normalización
y 4)
desempeño. Usted espera que lo más
normal
sea
llegar
al
estado
3)
normalización, a partir de la tercera
iteración. ¿Quizá sea buena idea que el rol
de ScrumMaster vaya rotando entre los
miembros del equipo desde la iteración 3?
Esto fomentaría la aparición de un equipo
auto-organizado. Comencemos el proyecto
siendo ScrumMaster si es necesario.
• Sobre todo, alguien tendrá que encargarse
de gestionar las expectativas de los
interesados, asegurar que se cumplen los
estándares
impuestos
por la
PMO,
gestionar para resolver impedimentos,
anticiparse a posibles problemas, etc. Es
decir: la gestión de proyectos de toda la
vida.
Con la certificación
PMI-ACP® PMI Agile
Certified
Practitioner
(Practicante Certificado
en Agile por PMI), PMI
está consiguiendo que
el
Director
de
Proyectos vuelva a ser
la figura central de los
proyectos adaptativos.
Para conseguir esta
acreditación,
el
candidato debe demostrar que ha practicado
proyectos ágiles, por supuesto, pero quizá
sea más importante que debe demostrar que
tiene un conocimiento estructurado sobre las
técnicas,
herramientas,
conocimientos,
habilidades y actividades necesarias en
proyectos ágiles. Algunas prácticas ya las
habrá aplicado, y el resto de prácticas
• En este proyecto ha sido muy fácil el
control de costes, no había un objetivo
presupuestario muy restrictivo. Usted
16
www.proiectus.es
Número 2, Abril 2014
referenciadas sabría aplicarlas, si se diera el
caso.
esta una profesión muy poco agradecida. Si
los objetivos se consiguen, como tenía que
ser, para eso nos ponen al mando, nadie nos
felicitará. Pero si no se consiguen, entonces
la culpa es solo nuestra. Mientras todo vaya
bien, nadie se quejará, pero si algo sale mal
(y en los proyectos puede haber muchas
cosas que salgan muy mal), de repente, todo
el mundo habla de gestión de riesgos, escasa
documentación, falta de liderazgo, auditorías
de calidad, problemas de comunicación,
ausencia de habilidades sociales, necesidad
de formación, etc. El resultado es siempre el
mismo para el pobre Director de Proyectos:
nos acusan de todo y no tenemos buena
defensa.
Hasta la fecha, PMI no ha editado un
estándar para gestionar proyectos ágiles, y
tampoco hay comunicación publicada en ese
sentido. En su lugar, PMI se limita a
recomendar una serie de once libros de
referencia muy reconocidos sobre prácticas
ágiles. Con tanta buena literatura ya
disponible, quizá sea el enfoque correcto, si
bien son libros muy enfocados en proyectos
de tecnología de la información. Por otro
lado, y por desgracia para los que no
tenemos buen nivel de inglés, estos once
libros no están traducidos al español, y peor
aún, el examen PMI-ACP aún no cuenta con
la ayuda de traducción al español. Por el
momento el candidato a la certificación PMIACP debe prepararse para estudiar libros y
practicar preguntas en inglés.
Actualmente hay muy pocos libros dirigidos a
preparar el examen PMI-ACP, y que a la vez
sirvan para divulgar los métodos ágiles para
quienes
no
tengan
la
intención
de
certificarse. Ya llegarán. Mientras tanto,
usted no puede esperar. Piense que en
cualquier momento le va a tocar dirigir un
proyecto adaptativo, y conviene estar
preparado.
No hay profesión en el mundo más orientada
a objetivos que la gestión de proyectos. Es
17
www.proiectus.es
Número 2, Abril 2014
ANTONIO MEDINA
Ingeniero Superior en Computer Systems por la Universidad de Birmingham
(Reino Unido, 2007), Máster en Information Systems and Management por
Warwick Business School (Reino Unido, 2010) y Máster en Consultoría y
Asesoramiento a Empresas por la Escuela de Organización Industrial (España,
2011). Está certificado como ITIL Expert, Certified Associate in Project
Management por PMI, Integración de Procesos por SAP y como Lean IT
Expert.
EL CAMINO HACIA LA ORGANIZACIÓN ÁGIL
Poco a poco estamos viéndonos inmersos en
la vorágine del pensamiento Agile. Ahora,
más que nunca, los datos demuestran que
por fin este concepto comienza a desplazar a
ideas más clásicas de gestión de proyectos,
basadas en modelos predictivos y en el
control exhaustivo de planes de proyecto
estáticos y de largo plazo. Ideas afianzadas
desde hace tiempo y que casi se
consideraban como dogmas. Sin embargo,
los últimos datos publicados en la séptima
encuesta anual sobre Agile Development,
llevada a cabo precisamente por PMI
(principal
impulsor
y
defensor
de
metodologías de gestión de proyectos
predictivas), muestran que las empresas han
incrementado sus planes de implementar
Agile del 59% en 2011 al 83% en 2012 (y la
tendencia sigue in crescendo).
Aunque a todos nos suena muy bien,
conseguir estos resultados es otra historia
diferente, que pocas veces se alcanzan y que
dependen principalmente del compromiso
que estas organizaciones estén dispuestos a
asumir en el cambio hacia un modelo Agile.
Precisamente, uno de los principales escollos
que suelen padecer estas organizaciones,
que intuyen que quieren hacer Agile pero no
conocen los detalles de qué tienen que hacer
para conseguirlo, suele ser que no tienen
claro el propósito ni el alcance de cada uno
de los conceptos que se engloban en este
pensamiento.
Tal y como Mary Poppendieck comenta en su
obra sobre Lean Software Development,
tanto Lean como Scrum comparten muchas
características, incluyendo el énfasis en el
cliente y la gestión de tareas de forma visual,
pero tanto uno como otro, difieren en dos
áreas principales: alcance y foco. Desde
luego, el ámbito de actuación de Scrum y de
Lean combinados puede abarcar todas las
capas de actividad de una organización, pero
por sí sólo Scrum no establece los
mecanismos para introducir la mejora
continua, el liderazgo de los empleados ni el
¿Y por qué las empresas, principalmente las
americanas, están adoptando estos modelos
nuevos de pensamiento? Los principales
beneficios
esperados
que
citan
los
encuestados de la encuesta anterior son un
menor time-to-market, la optimización de la
gestión
de
prioridades
en
entornos
cambiantes, y un mejor alineamiento y
entendimiento entre la TI y el negocio.
18
www.proiectus.es
Número 2, Abril 2014
análisis de desperdicios, ni Lean es el mejor
candidato para conseguir alcanzar un
enfoque ágil de desarrollo como el planteado
por Scrum o XP.
establece un marco de trabajo ni una
metodología, sino que analiza de forma
continua los procesos, tanto el de desarrollo,
como el resto de procesos implicados, que
apoyan o que alimentan el desarrollo tanto
como entrada o como salida (Compras,
Service Desk, QA, etc.) e intenta descubrir
los focos de ineficiencias de extremo a
extremo del proceso. En este caso, Lean se
centra en analizar el entorno e intentar
facilitar que cualquier proceso fluya sin
interrupciones, aspirando a conseguir la
excelencia operativa de toda la organización.
Lean afecta a toda la organización, desde el
origen de la demanda hasta la puesta en
producción y la aceptación de la petición y a
todos los niveles (prácticas, organización y
políticas y principios).
OBJETIVOS DE SCRUM Y DE LEAN
Pero empecemos por el principio. ¿Para qué
sirve, o qué objetivos tiene Scrum? ¿Y Lean?
Scrum es un marco de trabajo bajo el cual se
define una metodología de desarrollo ágil,
iterativo e incremental. Es decir, se centra
exclusivamente en conseguir mejorar las
entregas de proyectos de desarrollo de
sistemas de información. En comparación con
otras metodologías de desarrollo de software,
aporta el valor importantísimo de incorporar
varias entregas o prototipos antes de la
entrega final que se van entregando y
aceptando por iteraciones, llamadas sprints,
por parte del cliente, gestionando sus
expectativas y negociando los requerimientos
de forma periódica y consiguiendo que el
desarrollo de software deje de ser una caja
negra para los usuarios finales y un horizonte
interminable para los desarrolladores. Con
esto el riesgo de un “¡Pero si esto no es lo
que había pedido!” se minimiza en mayor
medida, ya que se va presentando de forma
periódica al cliente prototipos del producto
final. Scrum propone, de manera similar a
Lean, realizar reuniones rápidas diarias
operativas para fijar objetivos diarios y
reuniones de retrospectivas (que en Lean se
podría trasladar a la reunión semanal de
seguimiento de mejoras). Por lo tanto, Scrum
se centra y daría respuesta a las necesidades
de mejorar las actividades de la capa de
desarrollo de proyectos de TI.
QUIERO HACERLO: DÓNDE COMIENZO Y
CÓMO
Entonces, cuando una organización se
plantee comenzar la andadura hacia la
eficiencia y la mejora continua, ¿por dónde
debería empezar? ¿Por Lean o por Scrum? ¿Y
existe algún camino lógico por el que realizar
Lean en cambio, tiene un alcance más amplio
y es más transversal que Scrum. Lean no
19
www.proiectus.es
Número 2, Abril 2014
esta andadura y por el que nuestras
inversiones tengan un objetivo en el tiempo?
metodologías de gestión para responder a
entornos con un alto componente de cambio.
Es en ese momento, cuando el nivel de
madurez de la filosofía Lean ha conseguido
penetrar en la cultura de la empresa y en la
mentalidad de las personas, donde estos
mismos equipos son los que proponen y
aspiran a adoptar Scrum para sus proyectos
de desarrollo. Y el Tablero de Mejoras de
Lean se convierte en la herramienta de
seguimiento perfecta para que se consiga
esta implantación de forma gradual, ya sea a
través de un piloto en una entrega o
empezando con algún proyecto pequeño y de
bajo riesgo para el negocio. Así mismo, al
incorporar
Scrum,
se
incorporan
las
retrospectivas, que se realizan al final de
cada Sprint o iteración y donde se analiza
qué ha ido bien, qué ha ido mal y que se
podría mejorar para la siguiente entrega.
Cualquier iniciativa de mejora que se detecte
en estas retrospectivas encuentra de forma
natural
también
un
mecanismo
para
gestionar y llevar adelante estas mejoras en
el Tablero de Mejoras.
De nuevo, para tomar esta decisión, entra en
juego el alcance y el foco. Un equipo
gestionado por Scrum tendrá el potencial
para mejorar la entrega en proyectos y
aumentar la satisfacción del negocio, pero
sólo realizará retrospectivas para mejorar
únicamente su ciclo de desarrollo. Por sí sola,
la metodología de Scrum no da pie
inicialmente a desarrollar ideas que puedan
mejorar la eficiencia operativa de la
organización a través de toda su cadena de
valor, sino que su alcance se centra
exclusivamente en el proceso de desarrollo.
Por lo tanto, y desde la experiencia que
hemos adquirido en nuestra Firma en
transformaciones Lean, el camino más lógico
para cualquier organización debería ser el de
comenzar con Lean.
A través de las iniciativas Lean se establecen
una
serie
de
mecanismos
para
la
introducción, gestión y seguimiento de la
mejora continua en todos los ámbitos de la
cadena de valor de una empresa o de un
departamento de TI. Estos mecanismos no
dejan de ser sino los ya conocidos Tableros
de Mejora, donde con una frecuencia
periódica, un Lean Coach (o Facilitador)
dirige a los equipos Kaizen (o de Mejora)
hacia la consecución de una serie de
pequeños
proyectos
de
mejora
para
conseguir elevar el valor entregado al cliente
(el cual puede venir dado en función de
tiempo, calidad o coste).
La conclusión es que, efectivamente, no sólo
Lean y Scrum tienen muchas cosas en
común, sino que siguiendo un camino
homólogo al explicado en los párrafos
anteriores se puede conseguir combinarlos y
aprovechar tanto la mejora continua a nivel
departamental
u
organizacional
como
obtener los beneficios de entregas más
rápidas y con una mayor aceptación del
usuario que provee Scrum.
Lejos quedan ya los días en que la empresa
era la única responsable de la formación de
sus trabajadores. Aunque aún quedan
empresas que siguen realizando esta
práctica, las circunstancias actuales han
Una vez establecidos estos Tableros de
Mejora, hemos encontrado que en varios
equipos Kaizen se produce una evolución
natural hacia la mejora de la eficiencia de sus
20
www.proiectus.es
Número 2, Abril 2014
provocado que éste no sea un hecho
habitual. Por tanto, para mantenerte
actualizado debes ser tú quien tome las
riendas de tu educación.
(Quality assurance, despliegues, bases de
datos, etc.), logrando tener equipos que
representen la Cadena de Valor de la TI.
Todo esto son pequeños pasos en un camino
mucho más largo, que incluso hoy por hoy
sigue construyéndose a través de la
innovación abierta y compartida que en los
últimos años se ha extendido a través de
comunidades de práctica globales. Sin ir más
lejos, en el European Lean IT Summit
celebrado este año en París, Steve Bell, una
de las principales referencias en esta área,
introdujo los próximos retos que Lean IT
debe abordar: la incorporación de los ERP en
las iniciativas Lean y su escalado hacia los
niveles de dirección a través de salas de
mando o de control conocidas como salas
Obeya.
ASPIRANDO A MÁS: COMBINANDO LEAN,
SCRUM… Y AGILE PROJECT MANAGEMENT
Si el foco de Lean está en la excelencia
operativa a nivel organizacional y el de
Scrum en agilizar los proyectos de desarrollo,
el de Agile Project Management está en
habilitar la gestión de proyectos basados en
Scrum y que se ejecuten en organizaciones
Lean. Agile Project Management reduce
sustancialmente el peso del plan en favor de
la gestión de prioridades cambiantes y está
mejor adaptado a este nuevo pensamiento.
Introducir Agile Project Management requiere
un nivel de madurez en pensamiento Agile
elevado, al igual que con el caso de Scrum, y
podría ser un buen enfoque abordar la
implantación de ambos de forma unísona.
No todas las empresas están preparadas para
adoptar este modelo, especialmente si se
duda de que el compromiso sea firme y no
existan sponsors o campeones con influencia
para que se realice esta visión. No en vano,
las
principales
barreras
para adoptar
enfoques Agile siguen siendo las de siempre
(obtenido de la séptima encuesta anual sobre
Agile de PMI): resistencia al cambio, culturas
corporativas diametralmente opuestas a este
pensamiento y transformaciones incompletas
o que se abandonan a mitad de camino y que
no logran explotar el verdadero potencial del
modelo mostrado. Para concluir, nuestra
recomendación, que sirve para cerrar el
círculo de este artículo, sería empezar por
Lean para introducir un cambio disruptivo y
transversal, y gradualmente, sus equipos
comenzarán a adoptar otras técnicas ágiles
como Scrum por propia iniciativa (como una
mejora generada desde Lean).
Existen técnicas y herramientas para dar
soporte y apoyar este modelo que combina
Lean, Agile Project Management y Scrum. La
gran mayoría son herramientas de gestión
visual compartidas como los Tableros Kanban
o Diarios – que pueden ser tanto físicos como
virtuales -, sobre las cuales se reporta el
avance del día anterior y se estima el del día
vigente. Sobre estos datos el Scrum Master o
el Jefe de Proyecto puede desarrollar gráficas
de trabajo pendiente para cumplir con la
fecha de entrega de la iteración, conocidas
como gráficas Burndown. Y sobre todo, los
equipos de proyecto han de convertirse en
equipos integrados Dev/Ops, es decir,
equipos que combinen roles de desarrollo con
roles relacionados con las operaciones
21
www.proiectus.es
Número 2, Abril 2014
EDUARDO GUTIÉRREZ BAHILLOngeniero de Caminos, Canales y Puertos por
Jefe de Obra Senior en Ferrovial Agroman certificado como Project Management
Professional (PMP). En sus casi 15 años de desarrollo profesional ha estado
involucrado en diversos proyectos de construcción, tanto para clientes públicos
como para privados. Actualmente desempeña el puesto de Gerente de la UTE
Adeje -Santiago del Teide, encargado del tramo sur de las obras del Anillo
Insular de Tenerife con un presupuesto de 190 millones de euros.
GESTIÓN DEL PRESUPUESTO EN OBRAS PÚBLICAS
INTRODUCCIÓN
Para enmarcar más adecuadamente este
artículo nos referiremos a la mayoría de los
contratos de obra que se firman con la
administración y que suponen el compromiso
de ejecutar una obra con un diseño que,
previamente ha sido aprobado por la
administración y que el contratista se
encuentra como punto de partida de su
contrato.
Este artículo surge como continuación del
titulado “Dirección de proyectos en obra
pública” publicado en el primer número de la
revista PROIECTUS.
Entre las responsabilidades del Jefe de Obra,
como director de proyecto de construcción
perteneciente a la empresa contratista, se
encuentra la gestión del
presupuesto, así como
el control de los costes
y la optimización de la
cuenta de resultados de
la obra asociada al
proyecto.
Recordamos de nuevo
que este sector está
fuertemente regulado
por la Ley de contratos
con el Sector Público
[1],
ya
que
la
financiación para el
desarrollo de estos
proyectos
es
de
carácter
público
y
tiene que atender a
principios
fundamentales
del
derecho y buen uso de
los recursos públicos.
Así pues, el artículo se
ciñe
a
las
responsabilidades
del
contratista, que, dentro
de los parámetros que
fija la ley y sobre los
que entraremos más en
Autor: Eduardo Gutiérrez Bahillo
detalle, se encuentra
con el difícil reto de
Para explicar cómo
convertir en rentable una empresa que, a
afecta la normativa por la que se rigen las
priori, no lo es, por los motivos que
administraciones públicas a algunas de las
señalaremos a lo largo de este escrito.
fases de la dirección de proyectos tomaremos
22
www.proiectus.es
Número 2, Abril 2014
como referencia contratos de servicios de
más de 60.000 €, para los cuales la Ley de
Contratos del Sector Público garantiza los
principios de publicidad y concurrencia a
través de procedimientos abiertos. Para
contratos de menor cuantía, aunque no están
obligadas a ello (los suelen hacer por mera
eficiencia
administrativa),
las
administraciones públicas suelen optar por
procedimientos negociados sin publicidad o
compras directas (cuando los importes están
son inferiores a 18.000 €).
PROCEDIMIENTO DE
PUNTO DE PARTIDA
ADJUDICACIÓN.
Precios unitarios
•
Presupuesto total
De la multiplicación de las mediciones por los
precios unitarios, resulta el PEM (Presupuesto
de ejecución material). Además del PEM, se
establece en el presupuesto un porcentaje de
Gastos Generales, que se supone que son los
Costes no asociados directamente a las
unidades de obra, como pueden ser, equipo
del proyecto, oficinas, preparaciones de
terrenos, vallados, sistema de calidad, etc…
Los Gastos Generales vienen fijados en el
presupuesto y oscilan entre el 12-18% del
PEM. El otro porcentaje que se añade es el
Beneficio industrial, que recoge la lícita
pretensión del contratista de lucrarse con la
ejecución del contrato. Normalmente, el
Beneficio Industrial es del 6%. Veremos más
adelante que este concepto es idílico y no
atiende a la realidad.
EL
Toda esta aventura de la construcción
comienza con la adjudicación del contrato de
obra.
Destaco, nuevamente, la naturaleza del
contrato y los criterios para su adjudicación,
generalmente mediante concurso público.
Estos criterios se basan en los principios de
publicidad, libertad de acceso a las
licitaciones,
transparencia
de
los
procedimientos, no discriminación, igualdad
de trato entre los candidatos, capacidad y
méritos de los licitadores, todo ello orientado
a la salvaguarda de la libre competencia y a
la selección de la oferta económica y
técnicamente más ventajosa.
Así pues, una vez aplicados los porcentajes
mencionados más el IVA se obtiene el PEC
(Presupuesto de ejecución por Contrata)
Ahora bien, lo que más puede llamar la
atención del lector, es que de todos los
elementos mencionados, los contractuales
son los precios unitarios y el presupuesto
total.
Las mediciones no son contractuales.
En el momento de la licitación, el documento
clave es el diseño del proyecto, y dentro de
la gestión económica, el presupuesto
asignado a ese diseño.
Los precios unitarios son los que se aplicarán
a las unidades realmente ejecutadas que
aparecen en el diseño.
En el presupuesto figuran, de manera
resumida, los siguientes documentos:
•
•
El presupuesto total se emplea para estimar
la cantidad total que la administración
gastará en el proyecto, así como para limitar,
Mediciones.
23
www.proiectus.es
Número 2, Abril 2014
en los términos que establece la ley, el coste
total del proyecto.
administración, las ofertas económicas que
se presentan están por debajo del coste real
y no es raro encontrar rebajas del 30% en
las presentaciones de las ofertas.
BAJA EN LA ADJUDICACIÓN DE OBRAS
En el momento en el que se licita una obra,
las empresas hacen un estudio económico a
modo de previsión futura para estimar lo que
costará ejecutar el proyecto tal y como figura
en el diseño aprobado por la administración.
Además, las empresas estudian y proponen
el equipo director del proyecto así como los
medios que se van a emplear para la misma
y el plazo que estimado. También, según los
pliegos de bases, a veces se valora el Estudio
de Seguridad y Salud propuesto, las medidas
medioambientales, etc…
En este punto, conviene aclarar que eso no
significa exactamente que se hace una oferta
con un coste inferior al coste real en un
30%.
Por poner un ejemplo, partiendo de un
presupuesto total de 100, una empresa hace
el estudio económico y estima un coste de
80, pues bien, su oferta final podrá ser de
75, por ejemplo. Realmente no está un 25%
por debajo del coste real, sino un 6,25%.
Finalmente, el presupuesto que se firma una
vez ganada la licitación es el resultante de
aplicar a todos los precios unitarios y al
presupuesto total un valor que se llama
“Coeficiente de Adjudicación” y que es el
resultado de dividir el presupuesto de la
oferta económica del ganador entre el
presupuesto total contemplado en el diseño
de partida. Este coeficiente en la inmensa
mayoría de los casos es menor que uno.
Todo este procedimiento explicado aquí es el
motivo principal por el que las empresas
constructoras
extranjeras
no
pueden
competir en el mercado español, porque no
entienden que esta práctica pueda producirse
con un resultado final positivo.
Autor: Eduardo Gutiérrez Bahillo
Casi siempre, y más en los momentos
actuales de fuerte restricción del gasto
público, suele ponderarse altamente la oferta
económica más ventajosa.
Entonces, ¿por qué se produce esta práctica?
¿cómo se consigue finalmente ganar dinero?
Fundamentalmente y resumiendo mucho la
situación, por la imperfección en los diseños
de los proyectos de construcción.
Así, debido a la fuerte competencia y al
exhaustivo conocimiento que las empresas
constructoras tienen sobre las normativas,
regulaciones
y
procedimientos
de
la
24
www.proiectus.es
Número 2, Abril 2014
Pero, entonces, ¿significa esto que se puede
cambiar por completo el alcance y las
especificaciones del proyecto? Pues la
respuesta es bien sencilla: si no se cambia el
diseño el fracaso será seguro, ahora bien,
existen numerosas limitaciones legales y
restricciones a todos estos cambios.
El programa de anualidades, para contratos
que comprometan, por su plazo, varios
ejercicios económicos queda establecido en el
Pliego de Bases Administrativas que son las
que regulan el procedimiento de licitación. En
él se establece el reparto anual del
presupuesto, si bien es cierto que la ley
permite que el contratista ejecute, bajo su
responsabilidad, obras por encima del
importe designado en un año determinado,
esta práctica suele desaconsejarse porque
supone que la contrata tiene que financiar
parte del proyecto.
GESTIÓN
ECONÓMICA
DE
LA
OBRA.
DIFERENCIA DE ENFOQUE CON LA TEORÍA
DEL
PMI
(PROJECT
MANAGEMENT
INSTITUTE)
En la gestión económica del presupuesto,
siguiendo la técnica del Valor Ganado (EV),
desde el análisis inicial, en el minuto uno del
proyecto, habría que proceder a su rescisión,
ya que, queda demostrado que el valor
previsto del presupuesto es mayor que el
planificado y, por tanto, estamos desde el
primer momento en una situación de
pérdidas económicas.
La forma de pago está regulada también por
la Ley de medidas de lucha contra la
morosidad [2]. En esta ley se establece que
la Administración tiene que pagar antes de
30 días desde la firma de la Certificación (es
como se llama la factura que se le pasa a la
administración), mientras que el contratista
está obligado a pagar a sus proveedores
antes de 60 días, sobre la fecha de factura.
¿Cuál es, por tanto el objetivo del Jefe de
Obra?
ESTRATEGIAS PARA MEJORAR EL CPI DEL
PROYECTO
Fundamentalmente se trata de gestionar el
proyecto a lo largo de todo su ciclo de vida
para que al final, cuando se cierre la obra, el
CPI sea mayor o igual a 1, y, además, cuanto
más beneficio económico se saque del
proyecto, mejor.
Fundamentalmente hay 3 estrategias para
mejorar el CPI del proyecto.
• Liquidación positiva.
• Modificaciones del contrato
Aprovecho para recordar que el CPI (Indice
de Desempeño del Costo), según la técnica
del Valor Ganado, es la relación entre el
Valor Ganado (EV) en un momento
determinado y el Coste Real (AC) en ese
momento.
• Contratación de obras complementarias.
Liquidación positiva
Como
habéis
podido
entender,
el
presupuesto adjudicado está por debajo del
coste real en su conjunto, pero esto no
significa que en todas las unidades del
contrato se pierda dinero. Los precios
unitarios no siempre atienden a la realidad
Además, como complementos adicionales de
la gestión económica de la obra tenemos el
programa de anualidades y la forma de pago.
25
www.proiectus.es
Número 2, Abril 2014
del coste de la misma manera, así que hay
partidas
“beneficiosas”,
porque
incluso
aplicando el coeficiente de adjudicación, te
pagan más de lo que te cuesta, y hay
partidas “perjudiciales” en las que lo que te
cuesta está por encima de lo que te pagan.
Así que una estrategia clara es identificar las
partidas buenas y malas de manera que se
oriente el proyecto hacia aumentar la
ejecución de las partidas buenas y se reduzca
la ejecución de las partidas malas.
• Imposibilidad
de
ejecución
por
circunstancias de carácter geológico, hídrico,
arqueológico o medioambiental puestas de
manifiesto con posterioridad a la perfección
del contrato.
• Fuerza Mayor
• Avances técnicos que mejoren y que
hayan aparecido con posterioridad a la fecha
del contrato.
• Adecuaciones a especificaciones técnicas,
medioambientales,
urbanísticas
o
de
seguridad con posterioridad a la fecha del
contrato.
Esta estrategia se enmarca dentro de las
unidades contratadas y no contempla la
creación de partidas nuevas. La Ley
establece un límite del 10% al incremento
de partidas contempladas en el proyecto.
La suma de todas las modificaciones que se
hagan a lo largo de la vida del proyecto no
pueden superar en su conjunto el 10% del
presupuesto total.
Como he dicho anteriormente, las mediciones
no son contractuales y si realmente se
ejecutan más unidades de las previstas en el
contrato, estaremos dentro de los límites
legales si no se supera en su conjunto el
10% del presupuesto.
El efecto que se consigue modificando los
contratos es la aparición de precios unitarios
nuevos, no contemplados en el presupuesto
inicial
y
que
son
beneficiosos
económicamente. Si bien es cierto que el que
fija los precios nuevos es la propia
Administración, normalmente son negociados
y aceptados por el contratista.
Modificaciones del Contrato
Este procedimiento está cada vez más
vigilado y controlado por la Administración
que ha visto en el pasado como las obras se
alteraban
aumentándose
de
manera
incontrolada su presupuesto.
Contratación de obras Complementarias
La
legislación
vigente
contempla
la
posibilidad de que el contrato pueda
ampliarse para recoger obras de carácter
complementario porque son necesarias para
cumplir la totalidad del alcance del contrato.
Existe un procedimiento específico para la
aprobación
de
modificaciones
en
los
contratos que está regulado por Ley. El
promotor de los modificados en los proyectos
es la propia Administración y sólo están
contempladas las siguientes causas:
Los requisitos que deben cumplir estas obras
complementarias son que no puedan
separarse del contrato principal ni técnica ni
económicamente.
• Imposibilidad de ejecutar el objeto del
contrato por errores u omisiones en la
redacción del diseño
26
www.proiectus.es
Número 2, Abril 2014
Vamos a suponer que en la ejecución de una
carretera no se ha contemplado la ejecución
de un paso superior que conecte ambos lados
de la carretera para dar acceso a un grupo de
viviendas. Está claro que en este caso, con la
ejecución de la carretera, se va a producir un
aislamiento de un grupo de viviendas porque
por efecto de la ejecución del contrato, se
van a quedar sin acceso, además, para su
ejecución, se deberá invadir la carretera en
obras, por lo que no puede separarse
técnicamente del contrato. Así pues, se
requeriría incluir en el contrato principal la
ejecución de esta nueva obra como obra
complementaria.
CONCLUSIONES
 Las presiones del Jefe de Obra son muy
grandes.
 La gestión económica de los contratos no
se limita al control de los costes.
 Su labor está fuertemente circunscrita a
restricciones de índole regulatorio.
REFERENCIAS
(1) Real Decreto Legislativo 3/2011 de 14 de
noviembre por el que se aprueba el texto
refundido de la Ley de Contratos con el
Sector Público.
La ley permite la contratación de obras
complementarias con un límite de un 50%
del valor del presupuesto del contrato
principal.
(2) Ley de 4 de julio de medidas de lucha
contra la morosidad en las operaciones
comerciales.
Esta estrategia puede permitir, de nuevo, la
inclusión de unidades nuevas que resultarán
económicamente más ventajosas para la
obra.
Autor: Eduardo Gutiérrez Bahillo
27
www.proiectus.es
Número 2, Abril 2014
MARIO COQUILLAT DE TRAVESEDO
Mario Coquillat es un profesional experimentado en gestión de proyectos,
certificado PMP® y PMI-RMP®. Miembro del Comité CTN 157/ SC1 Project
Management de Aenor, participó como Comité Espejo en la nueva ISO 21500
“Directrices para la dirección y gestión de proyectos” y participa actualmente en
el TC-258 - project, programme and portfolio management.
LA GESTIÓN DE RIESGOS EN MEGAPROYECTOS
En el entorno global en el que nos
encontramos, donde los proyectos son cada
vez más complejos y multiculturales, realizar
una adecuada gestión de los riesgos se está
convirtiendo en una actividad cada vez más
esencial para garantizar el éxito de los
mismos.
de la gestión de riesgos, para que veáis que
se obtienen conclusiones muy interesantes.
EL CONTRATO
La modalidad contractual elegida por el
cliente (1) fue precio cerrado con ajuste
económico del precio unitario de cinco
partidas, dada la duración del proyecto y la
volatilidad de las mismas (lo que se
denomina en el sector escalamiento), frente
a un contrato reembolsable, donde se paga
lo realizado más honorarios.
Tanto la ISO 21500: Directrices para la
dirección y gestión de proyectos como el
PMBOK® (y especialmente el Practice
Standard for Project Risk Management) a
nivel de proyecto, como la ISO 31000:
Gestión del riesgo. Principios y directrices a
nivel de la organización, permiten acometer
la gestión de riesgos de una manera
sistemática, transparente y fiable dentro de
cualquier alcance y en cualquier contexto.
En el primer caso, la mayor parte del riesgo
la asume el contratista que oferta, y exige
por parte del cliente una buena definición del
alcance, si bien el riesgo de parte de la
volatilidad de las materias primas (lo que se
denominan riesgos especulativos o del
negocio) lo asumió el cliente. Estas fueron el
acero
estructural,
acero
de
refuerzo,
cemento, mano de obra y diesel y de hecho
implicaron un aumento del precio inicial del
contrato.
Podemos encontrar casos de total actualidad,
como el megaproyecto que incluye el diseño
y construcción del tercer juego de esclusas
del
Canal
de
Panamá,
donde
lo
anteriormente mencionado se pone de
manifiesto.
En el segundo caso, la mayor parte del riesgo
lo asume el cliente, y de hecho en algún
momento el cliente se planteó esta opción
para acelerar el inicio del proyecto y no
Vamos a analizar a modo de caso práctico, la
situación del proyecto desde el punto de vista
28
www.proiectus.es
Número 2, Abril 2014
esperar a una exhaustiva definición del
alcance, que precisó de un largo proceso (14
meses) durante la fase de oferta.
En una de las reclamaciones planteadas por
el contratista, toman como punto de partida
el informe geológico y geotécnico del terreno
suministrado por el Cliente, entendiendo que
las desviaciones con respecto al mismo
deben ser asumidas por el Cliente. Será
preciso leer con exactitud las cláusulas
correspondientes del contrato para poder
delimitar que parte de riesgo del suelo
asumió cada uno de los firmantes. Según se
puede leer en prensa, existe una clausula
según la cual el Cliente se compromete a
pagar sobrecostes en caso de encontrarse
condiciones
físicas
o
topográficas
imprevisibles durante del desarrollo de las
obras (2).
RIESGO DEL SUELO
En los proyectos de construcción, el cliente
habitualmente
suministra
un
informe
geotécnico y geológico preliminar del terreno
en el que se van a realizar los trabajos.
Quedará por determinar si las reclamaciones
corresponden a riesgos imprevisibles como
los denominados “cisnes negros” (en inglés
black shawn), pudiendo ser esto dirimido por
el tribunal de arbitraje que establece el
contrato para resolución de disputas.
RIESGO PROVENIENTE DE UN SUPUESTO
Fuente: Wikimedia Commons
Autor: Stan Shebs
Otra de las reclamaciones del contratista se
refiere a la naturaleza del basalto.
El contratista asumió en fase de oferta, en
base según sus reclamaciones a los datos del
cliente, que el basalto procedente de las
excavaciones de las esclusas de Pacífico sería
machacado y procesado para obtener el árido
de todo el hormigón de la obra.
Posteriormente,
el
contratista
debe
complementar, si lo estima conveniente, la
información
con
informes
adicionales
asumiendo el riesgo del suelo, es decir, si por
ejemplo los informes iniciales recomiendan
un tipo de cimentación superficial y
finalmente se precisa una cimentación
profunda el contratista debería haber
mitigado el riesgo del suelo realizando
campañas de ensayos adicionales que le
permitieran estimar los costes con menor
incertidumbre o en su defecto aceptar
activamente
el
riesgo
y
establecer
contingencias.
Sin embargo, posteriormente al evaluar el
supuesto y ver que era falso (al poner la
planta de machaqueo en funcionamiento, se
evidenció que al someter el basalto a la
fracturación se generaba una inesperada y
excesiva cantidad de material fino de
naturaleza plástica) y que los objetivos de
29
www.proiectus.es
Número 2, Abril 2014
plazo y coste se verían afectados, se
constituyó en un riesgo que obligó para
mitigar el incumplimiento de plazos, a
obtener
más
basalto
del
estimado
inicialmente
(durante
el
proceso
de
machaqueo y lavado el basalto sufría unas
pérdidas de más del 30% del material
fuente), modificar las plantas de machaqueo
consideradas en la oferta para asegurar la
producción así como llevar al vertedero el
exceso generado en machaqueo de finos
inútiles.
Si no se consideró como un supuesto y no se
tuvo en cuenta su incertidumbre, que debe
analizarse a lo largo del proyecto, no se
estableció un plan de respuesta ni reservas
de contingencia para poner en marcha una
vez conocida la verdadera naturaleza del
balasto.
Es muy interesante observar como la teoría
que estudiamos se puede y deber poner en
práctica en los proyectos (tanto pequeños
como megaproyectos) para garantizar su
éxito. Está en nuestras manos promover su
uso dentro de nuestras organizaciones.
REFERENCIAS
(1) Entrevista al administrador del Canal de
Panamá
(2) El contrato permite a SACYR incurrir en
sobrecostos
30
www.proiectus.es
Número 2, Abril 2014
ANTONIO PEDRO DORTA ALONSO
Ingeniero informático certificado Project Management Professional (PMP)®,
Máster en Administración de Empresas (MBA) y otra formación de
posgrado.
Más de 7 años de experiencia como consultor en proyectos de innovación
tecnológica (ERP, CRM, EDI, E-Commerce).
LOS ROLES DE BELBIN Y LA DIRECCIÓN DE PROYECTOS
Todo director de proyectos se ha enfrentado
alguna vez a la difícil situación de distribuir
adecuadamente
las
tareas
entre
los
miembros de su equipo de trabajo, a
gestionar las particularidades de cada
persona y, en definitiva, a tratar de sacarle el
máximo partido a todo el potencial del que
dispone.
ante la misma circunstancia. Debido a que un
rol es un conjunto de características
personales, posee una serie de fortalezas y
una serie de debilidades (algunas de ellas
son permitidas y otras no deberían
tolerarse).
Por ejemplo, una personal con el rol de
“cohesionador” posee las fortalezas de ser
muy cooperativo y poseer una buena escucha
hacia los demás, pero también conlleva una
debilidad permitida: a veces se muestra
indeciso ante situaciones difíciles que pueden
ofender a diferentes personas. Una debilidad
no tolerable de un cohesionador es que dicha
indecisión puede convertirse en pasividad si
se trata del líder del equipo y se le requiere
resolver un conflicto entre dos miembros del
mismo.
Abarcado dentro de las denominadas
habilidades suaves (soft skills) de la dirección
de proyectos, la gestión de personas es uno
de los retos más habituales a los que se debe
enfrentar todo directivo. Un ámbito que
resulta fácil de comprender pero muy difícil
de dominar.
Existen numerosas estrategias, metodologías
y técnicas para gestionar adecuadamente un
equipo de trabajo. En este artículo
cubriremos una de ellas, la Teoría de roles de
Belbin, por su enorme aplicabilidad a la
gestión de proyectos.
Es importante destacar que la teoría de
Belbin no trata de decirnos que algunos roles
sean mejores que otros, sino que una
adecuada combinación de los mismos es la
que produce equipos de alto rendimiento,
con resultados sobresalientes. Esto se debe a
que la presencia de determinados roles
pueden generar sinergias muy convenientes,
mientras que las debilidades de algunos de
¿QUÉ SON LOS ROLES DE BELBIN?
La Teoría de Belbin define 9 roles de equipo.
Un rol es un conjunto de comportamientos,
un patrón bien definido, distintivo y que
suele reaccionar de una forma determinada
31
www.proiectus.es
Número 2, Abril 2014
los roles pueden producir fricción y conflicto
cuando tienen lugar simultáneamente. En
definitiva, se trata de una cuestión de
equilibrio.
 Permite incrementar la eficacia de los
equipos de trabajo, a través de un mejor
conocimiento personal tanto propio como
del resto de compañeros
 Favorece la relación con los interesados,
considerando
las
expectativas
y
necesidades
de los mismos bajo el
paradigma de los roles de Belbin.
 Favorece la gestión del talento en las
organizaciones,
considerando
las
características y habilidades particulares
de cada persona.
¿CÓMO SURGIÓ LA TEORÍA RELACIONADA
CON LOS ROLES DE BELBÍN?
El investigador Raymond Meredith Belbin
publicó
en
1981
un
libro
titulado
“Management Teams: Why They Succeed or
Fail” (Gestión de Equipos: Porque tienen
éxito o fracasan). En dicha obra, el autor
presenta sus conclusiones tras varios años de
análisis de cómo las personas interactúan en
equipos de trabajo.
Fuente: Wikimedia Commons
Autor: Allan Edwards
¿QUÉ PUEDEN APORTARME LOS ROLES DE
BELBIN?
Fundamentalmente, la aplicación de los roles
de Belbin a la dirección de equipos de trabajo
puede proporcionar las siguientes ventajas:
Lo que resulta especialmente interesante de
dicho estudio es que en lugar de analizar el
comportamiento o la actitud de cada persona
como un ente aislado, Belbin se centró en
estudiar cómo interactuamos con otras
personas cuando poseemos un objetivo
común. Podríamos afirmar que no se trata de
un análisis de personalidad, sino un estudio
conductual de cómo trabajamos con los
demás.
 Ayuda a establecer relaciones laborales
productivas, aprovechando las fortalezas y
gestionando las debilidades que posee
cada rol.
 Favorece los procesos de selección de
personal o de miembros de equipo de
trabajo, adecuando los mismos según el
potencial
implícito
en
cada
rol
y
considerando las tareas a realizar en el
proyecto.
32
www.proiectus.es
Número 2, Abril 2014
¿CUÁLES SON LOS ROLES DE BELBÍN?
El rol del Cohesionador es, en muchos
aspectos, antagonista al del Impulsor. Se
trata de una persona cooperadora, sociable y
diplomática, constantemente preocupada del
bienestar de cada miembro y de que todas
las personas se encuentren cómodas.
Escucha e impide que se agraven los
conflictos, y descarga tensión en el ambiente.
A continuación, describimos los 9 roles de
Belbin, indicando cómo contribuye al equipo,
qué características personales lo definen y
qué debilidades habría que gestionar en cada
caso.
La debilidad del Cohesionador es su
tendencia a evitar los conflictos. Puede llegar
a convertirse en una debilidad no permitida,
si dicha tendencia se convierte en indecisión
en situaciones difíciles y no se afronta
situaciones desagradables.
El rol del Coordinador es capaz de identificar
el talento y sacar partido de las habilidades
de cada miembro del equipo, aclarando las
metas y delega las tareas. Posee un carácter
maduro, seguro de sí mismo. Dentro de las
debilidades permitidas para este rol, destaca
que suele ser percibido como manipulador.
Las debilidades que no deben ser permitidas
son descargarse de trabajo personal o asumir
el mérito de todo el equipo.
El rol del Cerebro es característico de
personas creativas e imaginativas. Posee un
carácter independiente, listo y original, lo
que le impulsa a innovar e inventar.
Contribuye al equipo generando ideas y
resolviendo problemas difíciles.
Por otro lado, el Cerebro suele estar absorto
en sus pensamientos, ignorando todo lo que
le rodea. Su carácter independiente le
impulsa a trabajar apartado del resto del
equipo. Entre las debilidades no permitidas
de este rol, se halla el que suele trabajar de
forma poco ortodoxa y que tienden a
sobrevalorar sus propias ideas sobre las del
resto del equipo. Si el equipo posee muchos
cerebros, apenas se relacionarán entre sí y
no existirá coordinación.
El Impulsor es una persona retadora,
dinámica y extrovertida. Trabaja bien bajo
presión y posee iniciativa y coraje para
superar los obstáculos. Contribuye al equipo
retando a los demás, empujándolos hacia la
acción y hacia el éxito.
La parte negativa de este rol es que suele
centrarse excesivamente en ganar, lo que
puede generar fricción con otros miembros
del equipo. Por su carácter tiende a tener
poca comprensión ante los demás, y ser
propenso a la provocación. Dentro de sus
debilidades no permitidas, puede originar con
facilidad discusiones y polémicas e incluso
abordar los conflictos con agresividad. Dos
impulsores en un mismo equipo pueden
entrar en conflicto si opinan de forma
diferente.
El Investigador de Recursos es una persona
extrovertida, entusiasta, comunicativa y
negociadora. Está constantemente buscando
nuevas
oportunidades
y
desarrollando
contactos. Es capaz de obtener nueva
información con facilidad.
33
www.proiectus.es
Número 2, Abril 2014
Este rol suele ser excesivamente optimista y
pierde rápidamente el interés, por lo que
requiere apoyo constante para mantener su
entusiasmo. Una debilidad que no debe
permitirse es que puede defraudar la
confianza de los demás cuando no cumple lo
pactado o descuida el seguimiento de los
acuerdos.
Su carácter meticuloso les convierte en
líderes muy rigurosos o en miembros del
equipo con problemas para delegar tareas,
llegando a tener fricciones con miembros del
equipo que asuman su tarea de forma
relajada. Su principal debilidad no permitida
es que su perfeccionismo puede derivar en
una obsesión hacia los detalles y un exceso
desproporcionado de rigor.
El Implementador transforma las ideas en
acciones, realiza el trabajo necesario para
cumplir los objetivos y tiende a centrarse
más en los objetivos del equipo que en sí
mismos. Se trata de una persona práctica,
confiable y displicinada. Con un carácter
conservador y ortodoxo, aborda todo de una
forma sistemática.
El
Especialista
aporta
cualidades
y
conocimientos
específicos
al
equipo.
Asumiendo el rol de experto técnico en
determinadas
disciplinas,
facilita
la
realización de ciertas tareas y asesora en la
toma de decisiones. Generalmente, se trata
de una persona entregada a su ámbito de
conocimiento,
con
un
alto
nivel
de
compromiso en su aprendizaje.
Entre
las
debilidades
que
posee
el
Implementador, destaca que a veces se
muestra inflexible antes nuevos cambios y
situaciones. Ello se debe a que hacer las
cosas de un modo distinto frena su eficacia,
lo que le motiva a mostrar resistencia al
cambio. Una debilidad a no permitir es que
su resistencia puede incluso obstaculizar la
innovación.
Los Especialistas tienden a centrarse en una
única cosa cada vez y sólo contribuyen
cuando se trata de un tema que dominan,
explayándose en tecnicismos. Su debilidad no
permitida es su nulo interés en el trabajo de
los demás, ignorando todo factor externo a
su ámbito de competencia.
El rol del Finalizador tiene cierta semejanza
con el del Implementador, pero su esencia es
muy distinta. Se trata de una persona
esmerada, concienzuda y perfeccionista,
obsesionada por llegar a los plazos
establecidos. La ansiedad es su verdadero
motor para motivarse, preocupándose hasta
alcanzar un resultado satisfactorio y cumplir
con la fecha prevista.
El Monitor Evaluador es una persona seria,
prudente y con mucho autocontrol, gracias a
que enfoca la realidad de una forma muy
lógica y analítica. Contribuye al equipo
evaluando todas las opciones y estableciendo
diagnósticos precisos. Por ello, resulta muy
útil en el análisis de problemas y para
evaluar ideas y sugerencias. Posee un talento
innato para sopesar las ventajas y las
desventajas de cada alternativa, emitiendo
juicios bien fundamentados.
El Finalizador busca los errores y perfecciona
los resultados, terminando las tareas
inacabadas y las omisiones. Por otro lado,
entre sus debilidades destaca el que tiende a
preocuparse excesivamente en los detalles.
Por el contrario, el Monitor Evaluador tiende
a ser lento en la toma de decisiones, ya que
quiere conocer el detalle de cada alternativa
34
www.proiectus.es
Número 2, Abril 2014
posible. Eso le impide tener iniciativa y no
resulta inspirador al resto del equipo. Entre
sus debilidades no permitidas, puede ser
excesivamente crítico e incluso destructivo
debido a su pesimismo, favoreciendo la no
acción ante el riesgo.
A
continuación
se
muestran
algunas
propuestas prácticas de cómo aprovechar las
características personales de cada rol en
determinadas circunstancias:
¿QUÉ APLICABILIDAD TIENEN LOS ROLES DE
BELBIN EN LOS PROYECTOS?
Como puede deducirse fácilmente, resulta
ideal para la asignación de tareas y para
mantener la gestión de la integración del
proyecto.
Coordinador
Evidentemente, un director de proyectos no
siempre puede conformar el equipo de
trabajo en base únicamente a sus deseos. La
gran mayoría de las veces, se encuentra con
un equipo de personas ya asignadas, cuyo
trabajo requiere ser coordinado.
Resulta ideal una persona con este rol para
conseguir reuniones productivas.
En equipos ágiles puede resultar también un
rol crucial si los miembros del equipo aún no
conforman un equipo auto-gestionado.
Sin embargo, un conocimiento adecuado en
el ámbito de recursos humanos, como los
roles de Belbin, le permitirán obtener el
mayor
rendimiento
posible,
prevenir
conflictos entre sus miembros y delegar
eficientemente.
Impulsor
Resulta ideal para hacer prosperar al equipo
bajo presión, inyectando vitalidad al grupo.
Su energía favorece que el equipo mantenga
un adecuado rendimiento, y al no poseer
miedo al conflicto lo hace idóneo para tomar
decisiones poco populares.
También resulta conveniente su entusiasmo
al comienzo de todo proyecto, ya que su
carácter enérgico facilita alinear a las
personas hacia el éxito y comenzar a ganar
velocidad.
Cohesionador
Favorece el buen ambiente de trabajo, lo que
resulta adecuado en cualquier momento de
ejecución del proyecto. Normalmente se
aprecia este rol cuando existe su ausencia,
ya que el equipo sufre crisis internas.
Fuente: Wikimedia Commons
Autor: Antonio Silverio
35
www.proiectus.es
Número 2, Abril 2014
También puede resultar muy conveniente en
reuniones donde se requiere una figura que
busque resolver conflictos mediante la
colaboración o la reconciliación.
Resulta extremadamente necesario en tareas
que requieren un alto grado de concentración
y exactitud.
Especialista
Cerebro
Es conveniente al inicio de un proyecto, para
poder idear estrategias de ejecución o para el
diseño de alternativas. También resulta
práctico en situaciones complejas en las que
se necesita soluciones creativas.
Favorece la realización de tareas muy
específicas o que demandan un alto nivel de
expertise. Su participación suele ser muy
valiosa para resolver problemas en el ámbito
que domina y para gestionar riesgos
relacionados con dicho ámbito.
Investigador de Recursos
Monitor-Evaluador
Es
excelente
estableciendo
relaciones
personales, creando redes de contactos y
buscando oportunidades de colaboración.
Estas habilidades pueden resultar de gran
interés en la gestión de los interesados y en
la gestión de las adquisiciones del proyecto.
En definitiva, puede ser una figura ideal para
la relación del equipo de trabajo con el
exterior.
Este rol resulta muy conveniente para
monitorizar el progreso del proyecto, evaluar
los riesgos y el control de la calidad.
Su carácter concienzudo lo convierte en una
pieza clave en cualquier comité de control de
gestión de cambios.
¿CÓMO SABES CUÁLES SON LOS ROLES
BELBIN DE UNA PERSONA?
Implementador
Es importante tener en cuenta que muy
pocas personas poseen las características de
un único rol del equipo. En realidad, lo
habitual es que cada persona destaque en
dos o tres roles, considerados primarios (lo
que genera, por cierto, una enorme cantidad
de
posibilidades
diferentes
de
comportamientos por combinación).
Este rol resulta crítico para conseguir que las
cosas se hagan. Es quien transforma el plan
de proyecto en realidad a través de construir
los entregables requeridos. Sin la presencia
de un implementador, es probable que el
trabajo
duro
nunca
se
realice
adecuadamente.
En el sitio web oficial de Belbin es posible
realizar diferentes cuestionarios de autopercepción (cómo nos vemos a nosotros
mismos) y cuestionarios con valoraciones de
nuestros compañeros de trabajo (aporta
mayor objetividad a los resultados). También
resulta interesante por la posibilidad de
consultar multitud de recursos adicionales.
Finalizador
Un rol fundamental para poder cumplir con el
calendario del proyecto, ya que transmiten
urgencia
para
alcanzar
los
plazos
establecidos.
36
www.proiectus.es
Número 2, Abril 2014
A continuación mostramos en una tabla
resumen la repercusión de cada una de estas
ventajas en los procesos y áreas de la
gestión
de
un
proyecto.
Para
ello,
consideraremos la clasificación propuesta por
el Project Management Institute en su
versión 5 de su obra PMBOK:
CONCLUSIONES
El éxito o fracaso de los equipos de trabajo
depende de su capacidad para detectar,
gestionar y coordinar las contribuciones de
cada miembro del equipo.
A través de una adecuada gestión del equipo
de trabajo, un director de proyectos puede
obtener el mayor rendimiento posible del
esfuerzo aplicado, prevenir posibles conflictos
y delegar eficientemente las tareas. En ese
sentido, Belbin y sus 9 patrones de conducta
pueden aportar un enfoque práctico de cómo
llevar a cabo este reto de una forma eficaz.
37
www.proiectus.es
Número 2, Abril 2014
ANTONIO MARTEL RODRÍGUEZ
Antonio Martel. Gestor de proyectos software especializado en soluciones Java y
de Business Intelligence. Scrum Master certificado con un amplio portfolio de
proyectos internacionales y para la administración pública local y regional.
JEFE DE PROYECTO, ¿Y AHORA QUÉ?
INTRODUCCIÓN
pero… ¿cómo vamos a ser capaces de poner
en vereda todo esto?
Nos acaban de nombrar jefe de proyecto. Lo
han hecho porque hemos tenido una buena
trayectoria como técnicos en nuestro campo
y nos han querido premiar con esta
responsabilidad. En realidad no sabemos
gran cosa de lo que tenemos que hacer a
partir de ahora, sólo sabemos que el jefe de
proyecto es „el que manda‟ y el que siempre
nos exigía responsabilidades. Lo buscamos
en la Wikipedia y encontramos que nuestra
misión es la de cumplir con los objetivos del
proyecto gestionando el coste, el tiempo, el
alcance, ¡casi nada!
Podemos tomar una actitud de supervisión
llevando una contabilidad exhaustiva y
precisa de gastos y horas empleadas,
asignando y desasignando recursos y
limitándonos a exigir al equipo de trabajo
que cumpla con los plazos estimados.
Lamentablemente, seguir a pies juntillas un
cronograma hecho antes de saber casi nada
del proyecto, no va a hacer más fácil que se
puedan cumplir esos plazos. Contar que ya
hemos registrado dos mil horas en la
aplicación de gestión de incidencias tampoco
nos va a decir si estamos construyendo el
producto que el cliente necesita o si vamos
por buen camino.
Hasta ahora, del coste de un proyecto no
sabíamos prácticamente nada, de esas cosas
se encargaba nuestro jefe, y siempre nos
explicaba que íbamos mal en asuntos de
dinero. Sobre el tiempo para realizar el
proyecto
sólo
sabíamos
que
siempre
incumplíamos los plazos y que para cada
entrega solíamos tener que trabajar varios
fines de semana. En cuanto al alcance, era
habitual que terminásemos haciendo una
cosa muy diferente a la prevista al principio y
que nuevos requisitos entrasen y saliesen
continuamente de la lista de tareas. Todo
esto es ahora es nuestra responsabilidad,
Cuanto más tiempo paso gestionando
proyectos más pienso que la labor del jefe de
proyecto no está solo en pedir explicaciones
y exigir responsabilidades sino en ayudar a
cumplir esos encargos. Facilitar el trabajo a
los demás y buscar la forma más fácil de
hacer el trabajo no es sencillo pero por algo
nos han dado esta responsabilidad.
Nuestro trabajo sería más fácil si siempre
contásemos
con
un
equipo
muy
38
www.proiectus.es
Número 2, Abril 2014
experimentado para el que no hay tarea que
se le resista. No necesitaríamos dedicar
semanas enteras a formación ni tendríamos
que preocuparnos por facilitar el trabajo.
Ellos nos facilitan el nuestro. Sólo tendríamos
que sentarnos a esperar a que terminen el
proyecto pero ¿de dónde vamos a sacar
equipos así?
trabajadores.
también.
Sí,
los
jefes
de
proyecto
Para
evitar
esto
creo
que
seguir
metodologías ágiles como Scrum me ha
ayudado bastante: Cada dos semanas
debemos hacer una entrega de lo que
estamos haciendo. Una entrega revisada y
comprobada. No podemos dejar todo para el
final del proyecto y luego ver que no
funciona. Sería como diseñar y construir un
coche de una sola pieza sin haber probado
primero que el motor funciona, que el
sistema eléctrico es capaz de arrancar el
coche o no saber si el sistema de frenado
puede parar el coche de forma eficiente en la
distancia requerida.
Lamentablemente el talento y la experiencia
no crece en los árboles. Podrías empezar a
pagar más y más a tu equipo de trabajo para
atraer a los mejores pero esto mismo lo van
a
comenzar
a
hacer
también
tus
competidores
para
retener
a
sus
profesionales y, no nos engañemos, tu
empresa no es Google. Esto sólo se lo
pueden permitir empresas con pingües
beneficios como ésa y por mucho que paguen
siempre habrá muy buenos profesionales
trabajando para otras compañías.
Otra práctica que creo que también ayuda
mucho a mejorar la productividad es el
hábito de mantener reuniones diarias con los
miembros del equipo de trabajo. Esto nos
ayuda a que todos seamos conscientes de lo
que tenemos que hacer cada día, de los
problemas que están surgiendo pero, sobre
todo, nos hace ver lo cerca que está la
siguiente entrega.
Tu equipo de trabajo y tú, que formas parte
de él, con todos los inconvenientes que
tengáis tendrán que hacer el trabajo lo mejor
que puedan. Esa es tu principal tarea ahora:
sacar el mejor partido a tu equipo. Estoy
seguro de que podrán hacer grandes cosas
con un poco de esfuerzo. Ya se sabe, a largo
plazo no triunfan los más brillantes sino los
talentos medios que vencen habitualmente la
pereza.
DAR TRANQUILIDAD AL EQUIPO DE TRABAJO
Esto ya lo avisaba Frederick Brooks en su
libro
“The
mythical
Man-month”:
Es
necesario reservar el tiempo suficiente para
hacer las tareas. Si damos menos tiempo del
necesario para acabar una tarea, no solo la
calidad se puede resentir sino que podríamos
tardar aún más del que habríamos necesitado
si
hubiésemos
planificado
el
tiempo
suficiente.
Siempre podremos hacer algo para sacar el
mejor partido del gran equipo con el que
contamos:
AYUDAR A SER MÁS PRODUCTIVOS
La procrastinación o la pereza para acometer
las tareas más difíciles y el pequeño caos
para organizar nuestras tareas diarias son
dificultades
que
tenemos
todos
los
Si por presiones externas, comprometemos
para tres meses una tarea que en
condiciones normales tardaríamos seis,
39
www.proiectus.es
Número 2, Abril 2014
podemos acabar haciéndola en nueve. Al
cumplirse los tres meses previstos y ver que
la tarea aún no está acabada, la presión y el
estrés aumentarán y esto hará sufrir la
calidad del producto. También tendríamos la
tentación de añadir más personas al equipo
para acabar antes el trabajo, pero esto no es
gratis. Varios miembros deberán parar
durante semanas o meses para formar a los
nuevos integrantes, tiempo durante el cual ni
los nuevos ni los antiguos miembros del
equipo estarán avanzando sus tareas. Otra
tentación sería la de darles menos tiempo de
formación a los nuevos pero ¿llegarán a ser
totalmente productivos antes de que acabe el
trabajo?
• Acortar las interrupciones al mínimo
posible siendo conciso en la exposición y
llevando todo lo necesario para resolver la
cuestión ya preparado al momento de la
reunión.
MANTENER EL BUEN HUMOR
Esta es la parte más difícil de cumplir. Todos
tenemos nuestras presiones y nuestros
problemas pero intentando bajar los niveles
de estrés a lo justo, dando tranquilidad al
equipo y recordando que dirigir es facilitar y
no controlar intentaremos conseguir que el
trabajo no sea siempre tan cansado, sino
quizás divertido.
REFERENCIAS
Otra forma de aportar tranquilidad a los
equipos de trabajo es no interrumpiéndolos.
Esta es una de las cosas que más me ha
costado aprender. Las prisas del trabajo
diario nos hacen ver que cada cosa que llega
a la bandeja de correo es aún más
importante que la anterior y andamos todo el
día pidiendo a unos y a otros que paren lo
que están haciendo para apagar el último
incendio.
(1) The mythical
Brooks
man-month,
Frederick
(2) Contagiar la no interrupción en el equipo
(3) Las ocho actitudes del jefe excelente
Con interrupciones constantes no hay un
poco de sosiego para acabar tareas que
requieren concentración. Para evitar estas
interrupciones procuro:
• Concentrarlas todas en un único momento
del día. Preferiblemente a última hora del
día.
• Pedir con antelación suficiente que me
reserven esa última hora de la jornada de
forma que puedan organizar el resto de sus
tareas en el tiempo restante.
40
www.proiectus.es
Número 2, Abril 2014
AGUSTÍN TAPIA QUESADA
Licenciado en Informática y Experto universitario en Ingeniería del Software
con más de 10 de experiencia en dirección de proyectos y servicios TIC, tanto
en el sector privado como en el público. Actualmente Responsable de Área de
Desarrollo
de
Open
Canarias
dirigiendo
los
proyectos
y
servicios
de
Administración Pública, Turismo y Sanidad.
LA VELOCIDAD, LA BOTELLA, LAS PELOTAS, LA ARENA… E ¿ITIL?
En un mundo laboral donde es necesario dar
respuesta casi inmediata a todo lo que nos
llega, es posible que esta labor del “día a día”
nos consuma tanto tiempo que no seamos
capaz de sacar el trabajo según lo habíamos
planificado.
Pensemos en un periodo de tiempo concreto,
nuestra agenda semanal, como una botella;
el trabajo u objetivos que pretendemos sacar
como pelotas; y finalmente, el día a día,
como arena.
Al empezar la semana
Empieza la semana, la idea es ir rellenando
la botella con las pelotas y con la arena
según vayamos terminando trabajo según
avance la semana.
A mediados de semana pasa que, aunque
hayamos metido algunas pelotas en la
botella, la arena entrará tanto en la botella
tanto que llegará un momento que ya no
cabrán más pelotas... el día a día nos ha
comido.
A mediados de semana
¿Otro enfoque? Metamos primero las pelotas
en la botella, reservemos de modo inflexible
tiempo, reservemos en nuestra agenda,
antes de empezar la semana. La arena,
según surja, irá rellenando los huecos...
¿resultado al acabar la semana? Objetivos
realizados, día a día contenido.
Al terminar la semana
41
www.proiectus.es
Número 2, Abril 2014
Vale, esta metáfora es muy conocida,
aplicada además a otros sectores de la vida,
como las cosas importantes, la familia, los
amigos, etc. vamos que no estoy hablando
de nada nuevo, ni inventando nada.
Hablemos ahora de Desarrollo de Software,
la metáfora me sirve para ilustrar algunas
situaciones que se dan en muchos de estos
proyectos. En los últimos años casi todos los
proyectos se abordan en un ciclo de vida
iterativo (e incremental). Aunque en todas
las metodologías “pesadas” siempre se ha
contemplado este ciclo de vida, parece que
es ahora, y gracias a la casi implantación casi
unánime de las metodologías ágiles en los
proyectos de software, cuando ya se ha
institucionalizado el ciclo de vida iteraciones.
Ya casi no se concibe un proyecto que no
esté basado en iteraciones.
Escenario iterativo con SCRUM
Hasta aquí un poco todo son ventajas en lo
relativo a un enfoque iterativo-incremental.
La cantidad de trabajo productivo que un
equipo es capaz de sacar adelante en una
Iteración es lo que se le denomina Velocidad.
De algún modo, la velocidad se puede medir
por el número de pelotas que somos capaces
de sacar adelante en una iteración, de este
modo nos centraremos primero en las
pelotas e iremos despachando la arena para
poder terminar la iteración con la botella
llena de pelotas y parte de la arena que haya
podido surgir. ¿Cuál es la arena en proyecto
de Desarrollo de Software? La atención
telefónica al cliente, las dudas, las reuniones,
los
informes,
las
presentaciones...todo
aquello que surge en un proyecto de
desarrollo de software que hace el equipo
pero que no está relacionado directamente
con producir software.
El objetivo de las iteraciones es buscar que el
personal que recibe el software lo vea
funcionando lo antes posible (software
funcionando
sobre
documentación
extensiva), que cada periodo vaya viendo
como su software va incrementando en
funcionalidad.
Un producto y sus incrementos. Esto nos
permite, al equipo de trabajo, percibir lo
antes posible el feedback del cliente y nos
permite hacer los ajustes para que el
software esté alineado con lo que se espera.
Al mismo tiempo, nos permite identificar
problemas tecnológicos en las primeras fases
del proyecto, para poner un software en
producción debo resolver un montón de
aspectos tecnológicos, todos ellos deben
quedar resueltos en las primeras entregas.
Cuanto antes aparezcan más tiempos
tendremos para resolverlos.
La teoría dice la velocidad de un equipo de
trabajo va mejorando a lo largo de la vida de
un proyecto, cada vez el equipo se conoce
mejor, conoce mejor el problema, la
tecnología, el cliente, etc. Esa es la teoría, y
aparentemente tiene sentido.
42
www.proiectus.es
Número 2, Abril 2014
¿La práctica? En muchos proyectos pasa
justo al contrario, la velocidad empieza a
empeorar
progresivamente,
la
presión
empieza a aumentar y los errores a aparecer.
El clima con nuestro cliente se deteriora,
nuestro equipo se estresa, etc. de repente
todo parece haberse torcido. ¿Qué ha
pasado?
dedicación de antes, se le llena de arena la
botella antes de poder meter parte de las
pelotas.
Encima nuestro cliente no entiende cómo
antes los incrementos del producto eran muy
importantes, y ahora cada iteración mejora
algunos aspectos ya desarrollados pero
incorpora pocas funcionalidades. “Me dijeron
que la velocidad iría mejorando…”. “Tu
equipo se está relajando, están perdiendo la
intensidad…”.
Volvamos a la definición de velocidad,
cantidad de trabajo productivo que un equipo
es capaz de sacar adelante en una iteración.
En un esquema iterativo-incremental, hemos
puesto en producción un software en el
primer tercio de vida del proyecto. Este
software, en las primeras iteraciones, lo
usaban algunos usuarios de referencia, en las
últimas se ha ido implantando en la
organización, ahora ya lo usa toda la
organización.
Ahora, al equipo de trabajo lo llaman todos
los usuarios para preguntar dudas por el
software, para comunicar incidencias, a los
desarrolladores los llaman los de sistemas
para
participar
en
reuniones
de
arquitectura.... un usuario, cansado de que
no lo atiendan, además se ha plantado en el
despacho y se ha pegado media mañana con
parte del equipo para entender una
funcionalidad.
Por
otro
lado,
sobre
funcionalidades ya entregadas surgen una
serie de ajustes que nuestro cliente entiende
necesarias.
Escenario desarrollo sin cumplir objetivos
¿Qué ha pasado? ¿no me sirve el esquema
iterativo-incremental del que todo el mundo
habla? ¿resulta que el enfoque interativo
incremental es malo?
Ha pasado que los granos de fina arena del
principio se han convertido en cantos
rodados, casi tan grandes como las propias
pelotas. Es decir, ahora tiene tanta
importancia para el proyecto dar soporte a
tus usuarios como seguir desarrollando el
producto.
En definitiva, el equipo de trabajo al principio
del proyecto dedicaba casi todo su tiempo a
desarrollar, a producir, a meter pelotas en la
botella, ahora, sin embargo, le surgen un
montón de tareas menores, que sin ser de
impacto de modo aislado sí evitan que el
equipo esté desarrollando con la misma
Ha pasado que ahora tu proyecto tiene dos
objetivos producir un software y ofrecer un
servicio. Un servicio de soporte para los
43
www.proiectus.es
Número 2, Abril 2014
usuarios de tu aplicación. Este servicio
precisamente tiene como objetivo dar ayuda
a los usuarios, resolver dudas, canalizar
peticiones
de
mejora,
nuevas
funcionalidades, etc. y también ayudar a
resolver incidencias de infraestructura.
¿Has oído hablar de ITIL? ITIL es casi un
estándar de facto en la gestión de servicios
TI, el alcance de ITIL va mucho más que un
servicio de soporte de una aplicación, pero
como marco de referencia para empezar a
organizarlo nos puede ayudar mucho.
Si tu equipo de trabajo acaba haciendo todo
esto en un proyecto de software asume
entonces que tienes dos objetivos, producir
software y ofrecer un servicio de soporte.
Aunque hay que reconocer que ITIL asustar,
sobre todo a los defensores de los enfoques
ágiles, yo creo que sí que nos puede ayudar
en muchas cosas, pero principalmente:
En esta situación puedes optar por dos
caminos: uno que se separe hacia un
departamento especializado de atención a
usuarios el servicio de soporte; dos, que el
propio equipo que desarrolla deba prestar
este servicio.
• A determinar qué sí que tenemos que
hacer o que no; a determinar realmente
cuales son las responsabilidades del equipo
en las tareas de soporte, qué debemos hacer
y para quién y qué no. Un Catálogo de
Servicios, aunque no sea de modo explícito,
determinará realmente cuales son las
responsabilidades del Equipo, a quién
debemos prestar esos servicios y bajo qué
condiciones (Niveles de Servicio), tiempos de
respuesta, horarios, tiempos de resolución,
etc.
Si estamos en el caso 1, perfecto, nos
quitamos arena, volveremos a dar la
velocidad a nuestro proyecto que habíamos
perdido.
Si estamos en el caso 2, la arena
efectivamente es piedra, es pelota. Hay que
establecer iteración por iteración un tiempo
bloqueado para garantizar este soporte. Este
caso es el que nos toca, ¿cómo vamos a
montar un servicio de soporte si el proyecto
no ha terminado? Desde luego que es difícil
conseguirlo.
• A saber diferenciar una Error de una
Necesidad, una Incidencia de una Petición de
Servicio. No es lo mismo que nos estén
transmitiendo un error de nuestro software
que impide a un usuario a realizar una
función; que una necesidad de mejora, una
consulta, etc. Obviamente, la incidencia va
primero!
Cada iteración, por tanto, tendrá reservada
una parte del tiempo del equipo para soporte
y otra para desarrollo. ¿Cuánta parte? Si
llega una petición ¿la atiendo sobre la
marcha? ¿tengo que responder a todos los
usuarios? ¿todo el mundo nos puede pedir
cambios?
Muchas
preguntas
y
pocas
respuestas.
• A saber gestionar, a quién escalar (dentro
o fuera de nuestro equipo), a quien pedir
autorización, etc. Un Proceso de Gestión de
Incidencias y de Peticiones de Servicio nos
ayudará a gestionar todo esto. A tener
estadísticas del volumen de actividad de
estos procesos y el tiempo que nos consume.
44
www.proiectus.es
Número 2, Abril 2014
• A abordar o no una petición de cambio.
Una aplicación la pueden usar distintos tipos
de usuario, cada uno con sus necesidades.
He vivido en más de una ocasión cómo se
aborda un cambio en una iteración, para
volver a deshacerlo en iteraciones siguientes,
para volver a aplicarlo más adelante, ¿cuál
era el problema? Que no había un Proceso de
Gestión de Peticiones de Cambio bien
establecido y casi que simplemente cuando
un usuario lo pedía se abordaba... Por cierto,
y un Cambio de una funcionalidad ya hecha,
entregada y cobrada...¿entra dentro del
alcance de nuestro proyecto?
ITIL nos debe ayudar a transformar la arena
en pelotas, a transformar trabajo no
planificado sin control, en paquetes de
trabajo controlado que podamos gestionar.
No tenía como objetivo explicar ITIL sino de
ilustrar que, adoptado con mesura, ITIL nos
puede
ser
muy
útil
para
controlar
determinados proyectos donde podamos
estar teniendo conflictos de prioridades,
donde, en definitiva, la arena nos esté
llenando todas las botellas sin poder abordar
las pelotas como nos gustaría.
ITIL también nos puede ayudar a gestionar
nuestro ciclo de versiones, a preparar
nuestro
sistema
para
dimensionarlo
correctamente para el volumen de actividad
esperado, etc. etc. La adopción de ITIL en un
proyecto
puede
abordarse
de
modo
incremental poco a poco introduciendo
aquellos procesos que nos vayan haciendo
falta... y parar donde creamos conveniente,
una pequeña parte o acabar adoptando el
marco completo en todas sus Fases.
Escenario desarrollo con SCRUM e ITIL
45
www.proiectus.es
Número 2, Abril 2014
IVÁN SAMUEL TEJERA SANTANA
Ingeniero Superior de Telecomunicaciones por la Universidad de Las Palmas de
Gran Canaria, Master Executive in Project Management por la Universidad de
Valencia
e ingeniero
certificado PMP®, PSM®,
ITIL® y
SCJP®.
Iván
ha
desarrollado su carrera profesional en multinacionales relacionadas con el sector
de las Tecnologías de la Información, siendo actualmente gerente de su propia
empresa de Consultoría y Formación en Dirección de Proyectos.
COACHING A EQUIPOS ÁGILES
INTRODUCCIÓN
la interacción entre los miembros del equipo
con objeto de mejorar la calidad de los
productos que se desarrollan.
¿Qué le ocurre a un Project Manager
acostumbrado a dar órdenes y asignar tareas
cuando se integra en un equipo ágil?
FACILITAR LAS REUNIONES DIARIAS
Pues le pueden ocurrir dos cosas, o que se
resista a perder su autoridad obstaculizando
la aplicación de metodologías ágiles, o que
no le quede más remedio que adaptarse a la
nueva situación.
El objetivo de esta reunión es facilitar la
transferencia
de
información
y
la
colaboración entre los miembros del equipo
para aumentar su productividad.
En estas reuniones cada miembro del equipo
responde a las siguientes preguntas:
El carácter autoorganizado de un equipo ágil
relega a un segundo plano la figura del
Director de Proyectos, acostumbrado hasta
ese momento a actuar como intermediario
frente al cliente y a ejercer su autoridad
mediante la asignación de tareas a los
miembros del equipo.
 ¿Qué he hecho desde la última reunión?
 ¿Qué voy a hacer antes de la siguiente?
 ¿Qué impedimentos están bloqueando o
ralentizando mi trabajo?
Ante este nuevo escenario, es lícito que un
Jefe de Proyecto se plantee en un momento
dado qué es lo que puede aportar de valor al
equipo. La respuesta es simple: ayudar a que
dicho equipo sea cada vez mejor creando las
condiciones adecuadas para fomentar la
innovación y la generación de ideas.
Nuestra labor cómo Agile Coach es asegurar
que la duración de la reunión diaria no
supera los 15 minutos, que cada miembro del
equipo responda a las preguntas anteriores y
que no se establezcan debates sobre cómo se
ha de resolver un problema.
Salvo en las fases iniciales, dónde nuestra
función es enseñar a los miembros del equipo
a llevar a cabo estas reuniones, por lo
El Director de Proyectos deja de actuar como
tal, y asume el rol de Agile Coach, mejorando
46
www.proiectus.es
Número 2, Abril 2014
general, nos situaremos en un segundo plano
interviniendo sólo en aquellos momentos que
así lo requieran, como por ejemplo, en caso
de que se ignore o interrumpa a un
compañero mientras habla.

¿Cuáles son las historias de usuario y sus
condiciones de satisfacción?

¿Qué es un punto de historia para el
equipo?
Como resultado de estas reuniones, los
miembros del equipo coordinan los esfuerzos
al tiempo que adquieren un compromiso con
el resto de compañeros.

¿En cuántos puntos de historia se estima
cada historia de usuario?

¿Qué tareas hay que realizar
resolver las historias de usuario?

¿Qué entendemos por Hecho cuando nos
referimos a la resolución de una historia
de usuario?

¿Cuál es el compromiso final del equipo
para este sprint?
FACILITAR
LAS
REUNIONES
PLANIFICACIÓN DEL SPRINT
DE
Para facilitar las reuniones de planificación
del sprint, un Agile Coach debe velar por que
el Dueño del Producto (Product Owner) haya
preparado correctamente la Pila de Producto
(Product Backlog), ¿esto qué quiere decir?
Pues que las Historias de Usuario (Story
User) que conforman la Pila de Producto han
de haber sido convenientemente detalladas y
priorizadas. No hay nada más frustrante que
llegar a una reunión de planificación de un
sprint y encontrarnos a un dueño de
producto incapaz de dar respuestas a las
preguntas del equipo de desarrollo.
Una vez más, el Agile Coach se encargará de
ir gestionando los tiempos para evitar que las
reuniones se eternicen.
Será nuestra responsabilidad ayudar al
dueño del producto a definir historias de
usuario que aporten valor real a su negocio.
Igualmente, nos ocuparemos de ayudar al
equipo de desarrollo a definir las tareas que
han de ser acometidas para resolver una
historia de usuario determinada sugiriendo el
uso mapas mentales, la definición de tareas
silenciosas, etc.
Además, hemos de facilitar un guión que
sirva para conducir la reunión de planificación
del sprint y saber cuándo la misma ha
alcanzado sus objetivos:

¿Cuál es el objetivo del sprint?

¿Quiénes son los miembros del equipo de
desarrollo?

¿Cuál es la capacidad total del equipo
para este sprint?

¿Cuáles son las historias de usuario de la
pila de producto que aportan mayor valor
al dueño del producto?
para
FACILITAR LAS REUNIONES DE REVISIÓN
DEL SPRINT
Durante estas reuniones, el equipo muestra
al dueño de producto las funcionalidades
desarrolladas durante el sprint sin que para
ello sea necesario preparar presentaciones
impactantes al estilo Steve Jobs.
47
www.proiectus.es
Número 2, Abril 2014
El equipo adquirió un compromiso al inicio
del sprint, ahora es el momento de mostrar
el trabajo realizado, obtener la aceptación del
dueño del producto e informar de los
“grandes” impedimentos que ni el Agile
Coach ni el Dueño de Producto pudieron
resolver durante el sprint.
FACILITAR
LAS
RETROSPECTIVA
¿Cómo es la interacción
miembros del equipo?

¿Cómo es la interacción entre los
miembros del equipo y el dueño del
producto?

entre
En estas reuniones el equipo debe responder
a las siguientes preguntas:
los
¿Se presta atención a la persona que
habla?

¿Alguno de los participantes en la reunión
es ignorado?

Cuando un miembro del equipo quiere
tomar posesión de la palabra, ¿lo
consigue?

¿Qué malinterpretaciones de conceptos
ágiles se observan en las conversaciones?
DE
Y llegamos al momento de hacer balance y
de evaluar cómo se hicieron las cosas. Aquí
el papel del Agile Coach es determinante
para ayudar al equipo a identificar los
problemas experimentados y consensuar
mejoras aplicables en posteriores sprints.
Durante la reunión de revisión del sprint, lo
mejor que podemos hacer es sentarnos al
final de la sala, permanecer en silencio,
observar e intentar dar respuesta a
preguntas tales como:

REUNIONES

¿Qué se ha hecho bien?

¿Qué se debe mejorar?

¿Qué se debe mejorar en el siguiente
sprint?

¿Qué
problemas
adecuadamente?
impiden
avanzar
CONCLUSIÓN
Si alguna vez tenéis la oportunidad de
entrenar a un equipo ágil, recordad que las
personas trabajan mejor cuando tienen la
oportunidad de autoorganizar su trabajo.
Nuestra función como Agile Coach es
proporcionarles los medios adecuados para
obtener de ellos el máximo rendimiento.
REFERENCIAS
Finalizada la reunión, compartiremos los
comportamientos observados con el resto de
miembros del equipo al objeto de poder
mejorar su desempeño.
(1)
48
Coaching Agile Teams. A companion for
ScrumMasters, Agile Coaches, and
Project Manager in Transition.
www.proiectus.es
Número 2, Abril 2014
MANUEL VARA GONZÁLEZ
Manuel Vara González es responsable de proyectos en Nartex Software, con más
de 15 de experiencia profesional. Licenciado en Administración de Empresas por
la Universidad Autónoma de Madrid, Master en Dirección Financiera y Control de
Gestión por la Escuela de Organización Industrial, es Stanford Certified Project
Manager (SCPM) por la Universidad de Stanford (USA) y certificado Project
Management Professional (PMP) por el Project Management Institute.
LA IMPORTANCIA DEL PLAN DE PRIORIZACIÓN EN LA
GESTIÓN DE LA CARTERA DE PROYECTOS
gestionados como un grupo con objeto de
alcanzar los objetivos estratégicos”
INTRODUCCIÓN
En los últimos años estamos asistiendo a
importantes cambios culturales en las
organizaciones, uno de ellos es la adopción
de la gestión por proyectos y programas.
Esta tendencia que reconoce la importancia
de los programas y proyectos como activos
estratégicos en las organizaciones está
aumentando y seguirá aumentando en el
futuro. Cada vez menos organizaciones
trabajan en proyectos individuales, aislados,
y la mayor parte, en cambio, han adoptado
un enfoque basado en la gestión de
programas y proyectos, identificándola como
una competencia crítica para el éxito
estratégico de la organización.
Como vemos, es en este punto donde
empieza a cobrar una gran relevancia la
necesidad de elegir correctamente los
programas y proyectos ya que será donde
vaya una gran parte de nuestras inversiones
siendo
más
interesante
para
nuestra
organización dedicar nuestros recursos en
programas y proyectos alineados con
nuestras estrategias.
EL PLAN DE PRIORIZACIÓN DEL PORTAFOLIO
Una de las técnicas con las que contamos
para apoyarnos a la hora de elegir nuestros
proyectos es el análisis de priorización. El
estándar de PMI para la gestión de cartera de
proyectos define el análisis de priorización
como "una técnica para comparar y clasificar
los componentes del portafolio, con base en
sus resultados de evaluación y otras
consideraciones de gestión, para asegurar la
alineación con la estrategia y los objetivos de
la organización. "
Es por tanto muy importante saber traducir
nuestras estrategias en acciones e iniciativas
y para ello disponemos de una herramienta
muy valiosa; la gestión de la cartera de
proyectos, también conocida como portafolio.
La propia guía de gestión de proyectos
PMBOK lo define de la siguiente forma: “Un
portafolio consiste en proyectos, programas,
subconjuntos de portafolios y operaciones
49
www.proiectus.es
Número 2, Abril 2014
También indica que el Plan Estratégico de la
cartera debe contener un modelo de
priorización que guíe las decisiones acerca de
los componentes de la cartera y cómo se
deberían monitorizar en todo momento para
añadir nuevos, modificar o rescindir los
actuales, así como gestionar las prioridades y
el equilibrio de los componentes de la cartera
de proyectos de la organización de forma
dinámica.
completa
• Las decisiones deben estar basadas en
hechos, obtenidos con el apoyo de un
procedimiento aplicado consistentemente.
• Tendrán que tomarse decisiones difíciles.
En algunos casos, la falta de recursos
conducirá a cortar algunos de los
componentes de la cartera de proyectos.
Con el fin de asegurar la prioridad adecuada,
se debería definir un plan que especifique los
dominios, los criterios de priorización, los
requisitos de las propuestas para cada
proyecto candidato o programa, los valores
ponderados y las escalas para los anclajes de
puntuación.
La
organización
establece
directa
o
indirectamente
la
prioridad
de
cada
componente de la cartera de proyectos a
través de definición de la estrategia. El
gestor de la cartera de proyectos utilizará
esta priorización en todo el manejo de la
cartera de planificar adecuadamente la
cartera, evaluar el impacto de los cambios
estratégicos, y tomar medidas correctivas.
A continuación vamos a describir en detalle
cada uno de estos pasos:
Antes de diseñar un modelo de priorización
para la gestión de la cartera tenemos que
tener en cuenta algunas consideraciones
importantes:
1. Establecer dominios
Un dominio es la agrupación de los proyectos
a los que se aplica un conjunto estándar de
criterios para la priorización (Geoghan y
Snow, 2001). Los dominios se pueden definir
de muchas maneras, algunos ejemplos son:
• Deben ser definidos diferentes tipos de
proyectos para poder agruparlos de forma
coherente.
Empresarial
• Las decisiones de priorización deben estar
conscientemente
alineadas
con
las
estrategias de negocio
 Mercados objetivo
 Tipos de productos / servicios
• La información que facilite el proyecto o
programa candidato deberá ser veraz y
 Conocimientos técnicos
50
www.proiectus.es
Número 2, Abril 2014
 Industria
 Una definición clara de los parámetros de
dominio es esencial
 Los objetivos de inversión
 Podemos
utilizar
características
de
proyecto para definir los parámetros de
dominio:
Unidad de Negocio
 Área Funcional
 Tipo de Proyecto
 Tipo de Cliente
 Principal fuente de recursos
 Categoría de gastos
 Contribución Negocios
 Los clientes internos / externos
 Requiere de inversiones
 Ubicación geográfica
 Tamaño / nivel de esfuerzo
Enfoque del producto
 Duración del esfuerzo
 La base de clientes
 Fase del ciclo de vida del proyecto
 Segmento de mercado
 Grado de definición
 Competencia
3. Identificar
organización
2. Definir los parámetros de dominio para
cada proyecto
las
estrategias
de
la
Si la organización ya ha realizado el análisis
de alineación estratégica para su cartera de
programas y proyectos, será más fácil
identificar las estrategias implicadas en la
gestión, si no, tendríamos que hacerlo ahora.
Las
estrategias
actuales
podrían
ser
detectadas en los informes anuales, en la
visión y misión de la empresa, en la historia
corporativa o en la cultura empresarial.
Los parámetros de dominio son el conjunto
de características únicas que se usan para
definir qué proyectos pertenecen a un
dominio
específico.
Para
asegurar
la
exactitud de un dominio que tenemos que
estar seguros de lo siguiente:
 Todos los trabajos de proyecto encajan
dentro de un dominio específico
 Cada dominio puede enfatizar ciertas
estrategias
de
negocio
de
manera
diferente
4. Definir los criterios de priorización
Las estrategias de la organización deben
guiar la definición criterios de priorización, y
estos
deben
ser
suficientemente
significativos.
 Los criterios de priorización de proyectos y
escalas de puntuación son específico de
cada dominio
51
www.proiectus.es
Número 2, Abril 2014
Este es un paso importante, ya que los
criterios de priorización impulsan el proceso
de gestión de cartera, proporcionando
información importante para la autorización
de las asignaciones de recursos y el orden de
prioridades de los proyectos.
Algunas características
crear estos criterios son:
I.
importantes
de ellos, por lo que debemos definir una serie
de contenidos mínimos para aquellos
programas o proyectos preseleccionados,
elaborando una propuesta ajustada a dichos
contenidos y los requisitos de cumplimiento
en términos de las estrategias identificadas
previamente.
para
Podemos concretar cómo el proyecto o
programa se ajusta o apoya el plan
estratégico de la compañía. Para obtener
esta información podemos definir un plan de
alto nivel del componente del portafolio.
Pocos en número
II. No solapados entre si
III. Claramente comprensibles
El plan de alto nivel debe contener hitos
clave, las posibles alternativas de calendarios
de ejecución, las estimaciones de recursos
preliminares, los supuestos y las restricciones
principales y las evaluaciones de riesgo de
alto nivel.
IV. Claramente medibles
V. Apropiados para cada dominio
Los
criterios
de
priorización
de
los
componentes de la cartera pueden tener un
carácter tangible o intangible, en la siguiente
tabla podemos ver algunos ejemplos:
En la definición de la propuesta de proyecto o
programa,
podemos
considerar
los
principales objetivos y resultados esperados,
tales como mercado de destino, penetración
de mercado, rentabilidad, satisfacción del
cliente y el cumplimiento normativo.
6. Establecer los valores ponderados.
El uso de técnicas de ponderación permitirá
que los componentes del portafolio se
clasifiquen de acuerdo a los criterios de
priorización.
Algunas
consideraciones
importantes:
 No todas las estrategias han sido creadas
de igual forma.
5. Definir los requisitos de las propuestas.
 La detección de funcionalidades duplicadas
entre componentes de la cartera de
Para seleccionar los componentes del
portafolio, necesitaremos saber más acerca
52
www.proiectus.es
proyecto
es
duplicidades.
Número 2, Abril 2014
crítica
para
eliminar
• Retorno de la inversión
 El orden de importancia de los criterios se
expresa utilizando un determinado peso
para cada criterio.
 Los criterios comunes a más de un
dominio, aunque estén dentro de una
misma cartera pueden tener diferentes
pesos.
5 = Introducción al mercado objetivo
5 = ROI Positivo

1 = difícil de adquirir

3 = fácil adquisición

5 = Sin nueva tecnología
REFERENCIAS
 Penetración en el mercado


El análisis de priorización es una de las
técnicas críticas para el proceso de selección
de los componentes finales de un portafolio.
El PMI destaca la importancia de usar un
modelo de priorización alineado con la
estrategia de la organización, para ello es
fundamental contar un plan de priorización
bien definido que dirija la ejecución del
modelo de priorización de acuerdo con las
estrategias a seguir.
Debemos evaluar los componentes del
portafolio mediante una escala definida
previamente donde cada valor tenga una
explicación de su significado. Por ejemplo,
podemos crear una escala de tres valores
para cada uno de los criterios de priorización
y seleccionar uno cuando lo apliquemos a
cada
uno
de
los
componentes
preseleccionados:
3 = El crecimiento en los mercados
existentes
3 = Punto de Equilibrio
CONCLUSIONES
7. Definir las escalas de puntuación y su
significado


Una vez completados estos pasos tendremos
definido nuestro plan y listo para aplicarlo en
la evaluación de los componentes de nuestro
portafolio.
Para cada uno de los criterios de priorización
podemos establecer un peso en función de
una determinada lista de valores, por
ejemplo, elegir un valor de la lista compuesta
por 0,5 - 1 - 1,5.
1 = Sin nuevos mercados
1 = ROI negativo
• Utiliza la tecnología existente
 Los criterios de ponderación deben ser
fáciles
de
aplicar;
el
propósito
fundamental es proporcionar finalmente un
ranking proyectos.


53
(2)
PMBOK 5th. Edition.
(3)
The Standard for Portfolio Management
3rd. Edition.
(4)
Tom Geoghan & Bruce Snow (2001).
Mastering the Project Portfolio. Stanford
Advanced Project Management.
www.proiectus.es
Número 2, Abril 2014
ALEJANDRO FORCADES PONS
Alejandro Forcades, Consejero Delegado de SM2, empresa líder en Baleares en
Tecnologías de la Información, Diplomado en Ciencias Empresariales por la UIB,
PDG por el IESE (Universidad de Navarra) y Certified for e-business – solution
advisor - por IBM. Ha trabajado durante 8 años en la multinacional de
consultoría y servicios informáticos Atos, fue subdirector de la empresa de
seguros sanitarios Novomedic (Grupo Sanitas) y trabajó como Consultor
Estratégico en el área de nuevos proyectos del Grupo Roxa.
EN ESTE NÚMERO ENTREVISTAMOS A…
ALEJANDRO
FORCADES
PONS,
DIRECTOR
La gestión de proyectos está protagonizando
un importante auge en nuestro país. En una
época de crisis como la actual, llama la
atención que España destaque en número de
Project
Managers
y
proliferen
las
asociaciones de gestión de proyectos. Las
cifras hablan por sí solas: El número de
certificados
españoles
PMP®
(Project
Management Professionals) supera los 4600,
por delante de Francia (3700) e Italia (4300).
Si bien aún estamos lejos de Reino Unido
(6500) y Alemania (10.000). Según datos del
PMI® (Project Management Institute), el
número de afiliados en 2012 creció un 39%
en España, mientras que el crecimiento
medio a nivel mundial fue del 7%. Sólo en el
capítulo de Madrid de PMI, el número de
socios se ha triplicado en tres años, hasta
llegar a los 1400 en la actualidad. Quizá las
razones
detrás
de
este
importante
crecimiento puedan encontrarse en la
necesidad de mejorar el currículum que
tienen actualmente nuestros profesionales, al
ser las acreditaciones de PMI altamente
reconocidas en todo el mundo, pero hay que
tener en cuenta que estos exámenes tienen
GENERAL
SM2
BALLEARES
S.A.
una alta tasa de suspensos (2-3 de cada 5) y
que los cursos para preparar el examen son
caros (el precio medio por alumno supera los
mil euros).
España también es noticia en el sector de la
gestión de proyectos por otra razón: Un
proyecto subvencionado con fondos públicos
del Plan Avanza 2 del año 2009, dio sus
frutos y hoy día es un negocio sostenible
basado en una herramienta de software libre.
El software que se desarrolló durante los
años
2009-2010
por
un
consorcio
encabezado por la empresa SM2 Baleares, se
bautizó con el nombre de OpenPPM (PPM
significa Project Portfolio Management), está
publicado para su descarga gratuita por
Internet
en
la
dirección
openppm.sourceforge.net, y es la pieza
central de una línea de servicios denominada
TALAIA™ (atalaya, en catalán), que presta
servicios a varios clientes españoles, entre
los que se encuentran: Iberostar, Riu Hotels
& Resorts, Govern de les Illes Balears,
Consell de Mallorca, Barceló Viajes e IBSalut.
54
www.proiectus.es
Número 2, Abril 2014
TALAIA se anuncia con frases como “la
Y sobre esta base argumentaron la solicitud
de la ayuda Avanza2. ¿Acudieron a la ayuda
individualmente como SM2?
herramienta pensada por y para Project
Managers”, o “consistente con los estándares
de PMI e ISO”, o bien “la única herramienta
opensource
para
gestionar
proyectos,
programas y portfolios”. Para profundizar un
Inicialmente se constituyó un consorcio de
cinco empresas. Más tarde, cuando se
produjo la adjudicación, quedamos solo dos.
Hay que decir que el motivo para solicitar la
ayuda no se reducía exclusivamente a la
herramienta. El objetivo del proyecto era
doble: además de desarrollar un producto sin
coste de licencia y de software abierto para
gestionar proyectos, programas y carteras
sobre los estándares de PMI, también se
pretendía constituir el capítulo Balear de PMI,
ya que aquí en Baleares había, y sigue
habiendo, un gran interés de muchos
profesionales en gestión de proyectos por
hacer comunidad. El objetivo inicial era ser el
cuarto capítulo español, después de Madrid,
Barcelona y Valencia. Finalmente no quedó el
capítulo, sino la asociación denominada
“Project Managers de les Illes Balears”, que
en la actualidad cuenta con más de 50 socios
y sigue creciendo.
poco más en TALAIA entrevistamos a
D.Alejandro Forcades Pons, Director General
de SM2 Baleares:
Hablemos en primer lugar de los orígenes.
¿Cómo surgió la idea de TALAIA?
En el año 2009 detectamos la necesidad de
que las empresas gestionaran proyectos con
herramientas corporativas, pero sin tener
que
pagar
precios
de
licencia
y
mantenimiento
muy
elevados.
Una
herramienta de gestión de proyectos
corporativa no tiene una funcionalidad
equivalente a un ERP, pero los precios de
mercado eran equivalentes. Eso resultaba
prohibitivo para las organizaciones de la
Administración Pública y también para
muchas PyMEs. Pero la necesidad de
gestionar por proyectos seguía estando ahí, y
más en tiempos de crisis, porque ya no se
podía perder dinero terminando los proyectos
tarde y sin calidad, por ejemplo, o porque es
más importante decidir bien si un proyecto lo
hacemos o no, lo retrasamos, lo cancelamos,
etc. Entonces, las organizaciones que no se
podían permitir el lujo de adquirir una
herramienta PPM de mercado, buscaban por
Internet
y
seleccionaban
herramientas
opensource tipo DotNet u Openproj, que ya
estaban disponibles por aquel entonces. El
problema con estas herramientas era que
eran soluciones parciales y no ofrecían todo
lo que necesita un Project Manager.
¿Cuál es el valor diferencial de TALAIA?
Yo diría que TALAIA aporta tres puntos
diferenciales: 1) es la primera herramienta
de código abierto que permite gestionar
proyectos individuales y programas de
proyectos, conforme a estándares; 2) sirve
para todos los roles relacionados con la
gestión de proyectos y 3) es un enfoque de
servicio que se adapta a la madurez del
cliente,
sin
imponerle
que
cambie
radicalmente su forma de gestionar.
55
www.proiectus.es
Número 2, Abril 2014
Por favor, desarrolle un poco cada uno de los
puntos.
¿Qué
significa
“conforme
a
estándares”?
quien ha vendido el proyecto o la inversión
querrá monitorizar sus objetivos anuales, el
responsable de recursos querrá anticiparse a
las fluctuaciones de capacidad, la PMO querrá
monitorizar todos los proyectos en su ámbito,
homogeneizar
los
métodos,
conceder
permisos de acceso a usuarios, etc.
Conforme a estándares significa ni más ni
menos que no hay que inventar la rueda.
Todo lo que necesita un Project Manager ya
está inventado. PMI lleva casi 50 años
estructurando el conocimiento necesario para
gestionar proyectos en su famosa guía
PMBOK® (Project Management Body of
Knowlege) estándar ANSI que ya va por su
quinta edición y que es totalmente
consistente con el nuevo estándar ISO
21500. Todo Project Manager ya sabe lo que
debe hacer para gestionar alcance, tiempos,
costes, calidad, recursos, comunicaciones,
riesgos, contrataciones, interesados, etc.
Sabe, por ejemplo, que el sobrecoste de un
proyecto se puede calcular según el estándar
Earned Value Management (estándar ANSI
748), pero en la herramienta de gestión de
proyectos que le impone su empresa, y por la
cual se está pagando mucho dinero, esto se
calcula de otra manera, ¿por qué?
Y por último, ¿el punto relativo a “adaptarse
a la madurez de los clientes”?
Este punto es muy interesante. Fíjese. El año
pasado tuve una conversación con un
potencial cliente de una gran empresa.
Tenían un plan para institucionalizar la
gestión de proyectos en toda la organización.
Un volumen y complejidad impresionantes,
estábamos hablando de varios cientos de
proyectos ejecutándose a la vez. Habían
evaluado varias herramientas y finalmente
habían seleccionado una herramienta de
mercado. Nosotros llegamos tarde con
TALAIA. Pues bien, en 2012, ya le habían
pedido al proveedor trabajar con la versión
beta de 2014, porque sabían que las
adaptaciones que tendrían que hacer en sus
procesos para usar la herramienta llevarían 2
años, como mínimo. Este enfoque a mí me
parece bien cuando se trata de adquirir un
ERP. Todos sabemos que cuando una
empresa compra un ERP, debe cambiar sus
procesos para adaptarse a la herramienta.
Este
enfoque
tiene
grandes
ventajas
relacionados con el ritmo del cambio y el
compliance. Sin embargo, este enfoque a mí
no me parece acertado cuando se trata de
gestionar proyectos. Los proyectos no fallan
o aciertan por las herramientas, sino por la
capacidad de las personas que los gestionan,
principalmente. Un Project Manager necesita
gestionar el proyecto, no la herramienta. Si
le hacemos seguir unos flujos muy
¿Sirve para todos los roles relacionados con
la gestión de proyectos”?
Los proyectos son esfuerzos organizacionales
colaborativos. Una herramienta PPM está
incompleta si la usa solamente el Project
Manager pero carece de interés para el
director de la organización o departamento,
el director de la cartera, del programa, el
patrocinador, el responsable de recursos, los
interesados, la PMO, etc. Todos estos roles
tienen un interés diferente sobre la misma
información del proyecto, y su forma de
gestionar es distinta. Por ejemplo: un
miembro del equipo usará la herramienta
para declarar sus horas y gastos incurridos,
56
www.proiectus.es
Número 2, Abril 2014
complejos, los cumplirá, por supuesto, pero
perderá poco tiempo porque tendrá otras
cosas que atender más urgentes. Miraremos
el proyecto en la herramienta y lo veremos
“todo verde” pero ¿tendremos información
fiable?
Si no venden licencias, ¿dónde está su
negocio?
TALAIA basa su modelo de negocio
exclusivamente en la venta de servicios
asociados
a
la
implantación
de
la
herramienta. Por lo tanto el cliente solo paga
por lo que necesita y le aporta valor. Nuestro
enfoque permite definir con el cliente los
servicios necesarios y dimensionar el
proyecto de implantación con un enfoque
lean startup ajustando los plazos a la
capacidad de inversión de cada cliente. Eso
nos
permite
realizar
implantaciones
incrementales
al
alcance
de
muchas
empresas.
Pero, ¿Cómo se le da la vuelta al
enfoque?¿Con TALAIA ya no hace falta que el
cliente cambie sus procesos?
Por supuesto que hace falta, pero no
empezamos por ahí. Cuando un cliente nos
pide ayuda a nosotros, generalmente es
porque tiene un problema. Unos necesitan
una visión global de toda la cartera, otros
tienen el problema puntual de tener que
justificar muchos proyectos a la vez para el
siguiente año, otros no dan abasto con la
demanda
no
planificada,
o
necesitan
controlar las horas incurridas de los recursos
en proyectos, quieren homogeneizar el ciclo
de vida, sufren continuas crisis y deben
empezar a gestionar los riesgos, etc.
Nosotros iniciamos típicamente el servicio
con un “quick-win” que resuelve ese
problema con la ayuda de TALAIA, y en
menos de 2 meses ya tenemos usuarios
accediendo, gestionando y colaborando en
sus proyectos. En esta fase
inicial,
generalmente no hay grandes cambios en los
procesos, sino que adaptamos TALAIA para
que se siga trabajando igual, pero de manera
eficiente y efectiva. Esta fase inicial suele
concluir con una hoja de ruta para las fases
siguientes. Nosotros vemos TALAIA como un
servicio continuo orientado a la generación
de valor, no a vender licencias.
Por su lista de clientes, parece que el servicio
TALAIA está muy localizado en Baleares.
¿Cómo ven el mercado en el resto de
España? ¿Están pensando en el negocio
internacional?
En una fase inicial es lógico centrarse en tus
clientes, la mayoría grandes compañías
internacionales y globalizadas, pero con sus
centros de operaciones en Baleares. A los
pocos meses y gracias a la potencia de
Internet (SourceForge) y a las peticiones de
todo el mundo recibidas a través de nuestra
página Web, decidimos desarrollar una red
de distribución global. En España contamos
ya con varios distribuidores especialistas en
PPM, y a nivel internacional tenemos ya
cerrados acuerdos en Alemania, Chile,
Uruguay y México. Y negociando en Australia,
Colombia, Perú y Brasil.
57
www.proiectus.es
Número 2, Abril 2014
MIKE GRIFFITHS
Mike Griffiths is a world-renowned project manager, trainer, consultant and writer,
holding multiple project management and Agile-related certifications. He is also a
regular columnist and Agile contributor at Gantthead.com, the world's leading
online community for IT project managers.
IN THIS ISSUE WE INTERVIEW…
MIKE GRIFFITHS, PMI-ACP® STEERING COMMITEE
Mike was on the original PMI-ACP® Steering
Committee, which defined the agile-related
knowledge, skills, tools and techniques to be
tested by the PMI-ACP® exam. He also
helped to create the new PMBOK® v5 Guide,
as well as the Software Extension to the
PMBOK Guide.
level of agile training, agile experience and
agile knowledge and skills. Most companies
today don‟t use a single methodology, but
instead leverage elements of agile, lean and
kanban where they best fit. An advantage of
being later to market with the PMI-ACP was
that it could choose to include the
widespread and most practical elements from
a variety of methodologies.
As a member of the PMI-ACP Steering
Committee, what benefits does the PMI-ACP
certification
offer
compared
to
other
certifications promoted by organizations like
the Scrum Alliance, Scrum.org or the
International Scrum Institute? What is the
intended purpose of the certification?
In Canary Island, most of the software
development contracts that are signed off,
have as a client the Public Administration.
Usually, in this type of public tenders, the
scope as well as the cost of the project are
pre-fixed in advance, which in turn makes
agile management difficult. What would you
recommend/do in order to achieve an agile
management of the project?
The PMI-ACP® is not focussed on a single
methodology. It combines elements from
multiple agile approaches along with Lean
and Kanban. The credential is well structured
and requires education, practical experience
and evaluation. Unlike Scrum certifications it
meets the ISO/IEC 17024 standards that
hiring managers look for in a rigorous,
defendable credential.
Contracting for agile projects used to be a
problem. I remember my first DSDM project
was for the British Government who had
similar rigid views about contracts and we
had to build new agile contacts from scratch.
However there are now many examples and
no need to reinvent the wheel. Agile methods
provide very practical tools for meeting a
fixed timeline, fixed scope or fixed budget.
The intended purpose is to create a credible,
robust credential that participants and hiring
managers can trust to demonstrate a base
58
www.proiectus.es
Número 2, Abril 2014
The advent of fixed price work packages and
more granular SOWs make the process
easier too.
scope using Feature Gathering workshops to
generate a candidate feature lists. Once we
have agreement that we have likely captured
80% of the core features, it is typically time
to create our backlog and start drafting a
roadmap knowing full well we need some
slack and contingency for the remaining 20%
of features that will emerge.
This workbook provides an excellent primer
on agile contracts for people wanting to learn
more.
What do you think should be done if we are
looking to manage a project following agile
methodologies and the client requests the
Project Plan prior to the beginning of the
project?
There is always a temptation to iterate
through feature gathering workshops until
people think they have generated 100% of
the likely features, people think that is the
right thing to do, but all that really happens
is that we get suggestions for speculative
features that go unused or represent gold
plating. The true additional features will
emerge as demos and evaluation of early
solution iterations reveal omissions.
I think a client asking for a project plan is a
perfectly natural request before starting work
on a project. Agile projects are still planned
but with detail appropriate to the quality of
the input data. It would be misleading to
present a seemingly concrete plan if it was
based on an incomplete view of true
requirements
and
technical
risks
or
uncertainty.
It takes discipline and courage to find that
point of the diminishing credibility of features
and switch to backlog building and
exploration. It is worth it though, since this
leads to the quicker discovery of the true
business requirements as opposed to the
initially anticipated ones.
So my response to a request for a plan is to
engage that person in release planning with
story maps and then the development of
iteration plans mindful of the quality of the
input data. Stakeholders are typically
receptive after being educated on the
uncertainties of early plans and the
processes for getting some rate of progress
feedback and then updating plans.
I use workshops rather than interviews to
gather candidate features since there is less
likelihood to gold plate requirements in the
presence of your business peers, and outputs
with unknown consumers can be quickly
killed off to simplify designs.
Given that at the beginning of a project you
usually don't have a detailed Product
Backlog, what process should be followed in
order to obtain a Product Roadmap?
I like to use visioning exercises like “Design
the product box” during kick-off sessions to
start gaining stakeholder consensus on
project scope. Then further elaborate on this
59
www.proiectus.es
Número 2, Abril 2014
Is it possible to manage a project in an agile
manner if in the Sprint Planning Meetings the
whole development team is not present
(team members are missing)?
What techniques can teams
minimize the technical debt
throughout the project?
apply to
generated
Technical debt eventually robs us of delivery
capability and so needs to be kept to a
practical minimum. Some basic techniques
for ensuring a clean design and reducing
technical debt include:
Yes, it is possible, but it is not optimal. We
want the whole team present not only to
provide necessary input, without which we
might miss something and make mistakes,
but also to build a better sense of ownership
and commitment to these plans and
estimates. Involving people in problem
solving, planning and estimating is the best
way to increase their commitment to meeting
deadlines.
 Employ a Simple Design – factor in
anticipated changes, but remain adaptable
for unanticipated changes.
 Frequent Integration – test that product
features fit together often
 Ruthless Testing – test first development,
automated tests, etc. Find issues early on
the “Cost of change curve”
 Regular Refactoring – little and often,
approved by PM and business. Refactoring
should be like “daily hygiene, not spring
cleaning” in other words done frequently
not left and batched up.
What would you tell a client that wants to
modify user stories in the middle of a Sprint?
I would tell the client “OK, let‟s ask the
team”. Scrum has a protectionist view of
changing stories during a sprint. It
discourages this practice and instead
recommends adding changes to the backlog
or even terminating the sprint. Other agile
methods are less controlling; in DSDM for
instance we would take the change to the
team and ask them about the impact. Maybe
it is something that is easily accommodated
in which case why would we not do it?
Alternatively, maybe it is more fundamental
and a pause and rethink at the end of the
iteration would make sense.
What does the Situational Leadership Model
consist of?
Situational
leadership
simply
means
adjusting your leadership approach based on
the circumstances at the time. Everyone does
it to a certain extent, but there are some
guidelines we teach that help prompt new
leaders of some common things to look out
for.
My view is quite pragmatic, if the client and
team are onsite then let‟s discuss it. If the
modification is easy then undertake it. If
however the change is more significant or the
cost of undoing / redoing work right now is
high, then we should explain this to the client
and let them decide what they want to do.
As an example, most people have heard of
the team stages of Forming, Norming,
Storming and Performing. These come
originally from Bruce Tuckman and are
followed by the disengagement phase of
Adjourning or what I like to call Mourning
60
www.proiectus.es
Número 2, Abril 2014
since people often miss being on a high
performing team.
Using this model we can see that Tuckman‟s
Forming phase maps to Blanchard/Hersey‟s
Directing phase. So, early on the role of an
agile team leader is to directly help with
project activities and paint a clear tactical
picture explaining what needs to be done.
Also it helps to ask lots of “Help me see it”
and “Where is the problem?” type questions
to assist team members identify and
articulate the issues.
As teams pass into the Storming phase we
generally witness plenty of disagreement,
open conflict, harsh dialogue. The Coaching
role is important here to help team members
resolve
conflicts
without
damaging
relationships, but generally some conflict is
good so don‟t molly coddle them too much.
Let the disputes occur, but act as referee or
safety valve to ensure things do not go too
far.
Here we see that teams start in the lower
right Forming quadrant as they learn about
each other. Then they move through
Storming (challenging each other) and
Norming (learning how to work with each
other), before finally arriving at the
Performing phase (working as one). As
leaders we can help the team through this
process by adjusting our focus based on the
matching overlay model from Ken Blanchard
and Paul Hersey.
At the Norming phase it means that the team
has found ways to create rules to help
govern itself. This is not an opportunity for
the lead to go on cruise control, but instead
play a more Supporting role. The team will
still need help with conflict resolution, as well
as reminders to enforce the rules (norms)
they have just created. This is a good time to
challenge teams with high level goals such as
“Team tracks velocity”, “Everyone owns
testing”, and tackling issues raised at
retrospectives.
The final Performing stage is not a given,
many (if not most) project teams are never
allowed to reach this phase because
organizations make too many changes to
them which send them through the Storming
and Norming phases again. Perfoming teams
are autonomous, empowered, self-managing,
61
www.proiectus.es
Número 2, Abril 2014
self-policing and require little more than a
direction to be pointed in and regular
recognition / thanks to be high-performing.
Blanchard/Hersey‟s
Deligative
leadership
style in this phase speaks to bringing work
and challenges to the team for them to solve.
What software tools would you recommend
our readers to manage projects using agile
methodologies (Scrum, Kanban)?
That‟s a little like asking what car should I
buy? It really depends on your circumstances
and needs. Small, collocated teams can get
by just fine with cards on a wall or Excel
based tools. Larger, geographically dispersed
teams can greatly benefit from the online
collaboration and tracking facilities of
dedicated tools.
Of course this is a simplification and people
and teams are complex and messy. Really
the best we can do is be aware of these
models and look for elements of them arising
and then act accordingly. Some general
pointers are better than no map at all, but
don‟t expect teams to proceed in an orderly
fashion and follow stereotypical stages.
The agile tools market has exploded with
offerings and add-ons. Like word processors,
most offerings contain features you do not
need or only infrequently use. Tool
evaluations that aim to count or rank
systems based on capabilities often fail to
see the costs of complications, unnecessary
features and learning effort. Decide what you
really need, switch on a bare minimum set of
functionality and let needs dictate enabling
new features. Software engineers often make
horrible tool choices because they are
attracted to “new shiny objects” which, while
fun to play with, need updating and if people
don‟t understand them or find them offputting
or
intimidating
are
counter
productive.
You helped create the Dynamic Systems
Development Method (DSDM). As it was one
of the first Agile methodologies, it is probably
unknown to many of our readers. Could you
please explain what it consists of?
DSDM is wider and deeper than most
methodologies. By that I mean it covers
more of the product lifecycle with tools for
assessing upfront feasibility and coverage for
roles like sponsor and ambassador user,
rather than just a product owner role. It is an
enterprise friendly wrapper for agile practices
and uses terminology more in keeping with
most organizations. So there are no
“planning games” or “extreme” anything that
might
strike
some
stakeholders
as
unprofessional terms.
We have all seen Microsoft Project Plans that
are so complicated that no one wants to edit
them in case they break something. The
same thing can happen with agile tools, we
want
simplicity
and
inclusion,
not
specialization and exclusion. The benefits
come from shared insight.
After the Feasibility Study portion of the
project, it works much like other agile
approaches, working from a prioritized list of
features in short timeboxed iterations of
development
followed
by
demos
and
adaptation.
62
www.proiectus.es
Número 2, Abril 2014
A Project requires a complex architecture to
be defined which will be used to determine
the rest of the project work, how can we lay
out partial and recurring deliverables?
The definition of architecture is usually
undertaken during the iteration 0 period of
the project. This is when tool set-up, proof of
concepts and connectivity tests are done. It
builds a skeleton of structure that features
can be developed on later. Unlike subsequent
iterations, iteration 0 may not take the
standard one week or two weeks; instead it
takes as long as necessary to set up the core
tools and prove that key elements of the
solution will work.
63
www.proiectus.es
Número 2, Abril 2014
ENTIDADES COLABORADORAS
64
www.proiectus.es
Número 2, Abril 2014
Esta publicación está disponible bajo Licencia Creative Commons Atribución-NoComercial-CompartirIgual 3.0 Unported (CC BY-SA
3.0). Usted es libre de compartir, copiar, distribuir, y comunicar públicamente la obra y hacer obras derivadas; bajo las condiciones de
reconocer los créditos de la obra de la manera especificada por el autor o el licenciante (pero no de una manera que sugiera que tiene
su apoyo o que apoyan el uso que hace de su obra), y si altera o transforma esta obra, o genera una obra derivada, sólo puede
distribuir la obra generada bajo una licencia idéntica a ésta.
Texto de reconocimiento de los créditos de la obra
Se ha de indicar la fuente de la información (www.proiectus.es) y el nombre y apellidos del autor del artículo referenciado.
ISSN 2340-9363
Lugar de Edición: Las Palmas de Gran Canaria
Empresa Editora: IVAN TEJERA PROIECTUS S.L.U.
URL: http://www.proiectus.es
E-mail: [email protected]
65