Revista Proiectus nº 3

www.proiectus.es Número 3, Octubre 2014
DIRECCIÓN DE PROYECTOS
DE CONSULTORÍA TECNOLÓGICA
Entrevista a Javier Zaya Martín, DIRECTOR DE PROYECTOS IT
GESTIONANDO LA DISTANCIA PARA EL ÉXITO DE LOS PROYECTOS
EL PROYECTO CMMI, UN PROYECTO DE MEJORA ORGANIZACIONAL
DEUDA TÉCNICA: LOS COCODRILOS SALEN DE LA ALCANTARILLA
METODOLOGIA PARA LA GESTIÓN DE LECCIONES APRENDIDAS
ESTRATEGIA PARA ENFRENTARSE AL EXAMEN PMP
ISSN 2340-9363

DIRECCIÓN DE LA REVISTA
Iván Samuel Tejera Santana
ivan.tejera@proiectus.es
EQUIPO EDITORIAL
ITPROIECTUS
www.proiectus.es
ASESORAMIENTO LEGAL
Javier Rodríguez Batllori Laffitte
MAQUETACIÓN Y EDICIÓN
Rogelio Suárez Tejera
COLABORADORES
Fernando Manero Martínez
Carlos Javier Pérez Escobar
Antonio Pedro Dorta Alonso
Jose Selaya Gómez
Mike Griffiths
María Pilar Tarriño Suárez
Mario Coquillat de Travesedo
Jose Barato Arroyo
Antonio Martel Rodríguez
Vicente R. Merchán Rodríguez
Javier Zaya Martín

3
Director revista PROIECTUS
Iván S. Tejera Santana
CARTA DEL DIRECTOR
Bienvenid@s a este tercer número de la revista PROIECTUS,
publicación MADE IN CANARIAS desarrollada por y para profesiona-les
vinculados a la Dirección de Proyectos.
Confeccionar una publicación gratuita como esta supone un gran es-fuerzo
para todos los que participamos de forma voluntaria en su ela-boración.
Por este motivo, nuestra mayor motivación para continuar
impulsándola está en la satisfacción de nuestros lectores.
El verdadero valor de la revista radica en ser capaces de aunar en un
mismo lugar el conocimiento y la experiencia de otros directores de
proyectos disgregados en distintas partes del mundo.
En este número hemos querido introducir nuevos enfoques de gestión de proyectos y mejora de procesos
en las organizaciones, lo que ha permitido dar la posibilidad de participar a un mayor número de profesionales.
Si en el anterior número pudimos entrevistar a 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), en este número hemos querido acercarnos a la gestión de proyectos en la Administración
Pública, entrevistando a Javier Zaya Martín, Senior IT Project Manager con amplia experiencia en este sector,
y a quién desde aquí agradecemos su tiempo y colaboración.
Tod@s los que formamos el equipo PROIECTUS esperamos que este número os resulte igual de inte-resante
que el anterior, a fin de cuentas, si la revista existe es gracias a vosotros.
La única fuente de conocimiento es la experiencia (Albert Einstein).

www.proiectus.es Número 3, Noviembre 2014
4
ÍNDICE
Gestión de proyectos internacionales
Fernando Manero Martínez
Cómo dirigir proyectos CMMI
Carlos Javier Pérez Escobar, CMMI Instructor
Dirigiendo proyectos para implantar ERP
Antonio Pedro Dorta Alonso, PMP®
ITIL y la dirección de proyectos
Jose Selaya Gómez, ITIL®, PMI-ACP®, PRINCE2®
Agile Errors
Mike Griffiths, PMP®, PMI-ACP®
Deuda Técnica
María Pilar Tarriño Suárez
Metodologia de lecciones aprendidas basada en
metodología de gestiÓn de riesgos
Mario Coquillat de Travesedo, PMP®, PMI-RMP®
Una estrategia para enfrentarse al examen PMP
Jose Barato Arroyo, PMP®, PMI-ACP®
El rol del director de proyectos en el cliente
Antonio Martel Rodríguez, PSM® I
Gestión de calidad en proyectos de consultoría
Vicente Merchán Rodríguez, ITIL®
Entrevista: D. Javier Zaya Martín
Javier Zaya Martín, PMP®, Senior IT Project Manager
5
13
20
29
33
38
44
53
57
61
65

Fernando Manero MARTÍNEZ
Ingeniero de Telecomunicación por la ULPGC, Master en Digital Business por ICEMD-ESIC
(Madrid) y fundador de Alkeno, donde dirige, diseña e implementa soluciones de digi-talización
con enfoque analítico en todos los ámbitos de la empresa desde la transfor-mación
digital interna (estrategia, procesos, proyectos, personas y herramientas) hasta
el comercio electrónico y el marketing online, siempre con el objetivo de maximizar de
forma demostrable el retorno de las inversiones realizadas por sus clientes.
Gestionando la distancia para el éxito de los
proyectos
5
proyectos
Siempre he defendido que la gestión de
proyectos tiene tanto de ciencia como
de arte. Es ciencia porque existen metodo-logías
y mejores prácticas ampliamente re-conocidas
y en constante evolución (dentro
de las cuales la Guía del PMBOK® es refe-rente).
Es arte por las habilidades necesa-rias
para llegar a ser buen jefe de proyecto:
un líder capaz de inspirar y gestionar con
eficacia las situaciones y las personas.
Ser jefe de proyecto requiere fortaleza para
afrontar decisiones difíciles y humildad para
asumir los errores y aprender de ellos, se
trata de un proceso de mejora continua
en el que salir de la zona de confort y asu-mir
nuevos retos es indispensable para se-guir
progresando.
Ese fue el motivo por el cual acepté el reto
de liderar un proyecto internacional. Un
trabajo que terminó resultando mucho más
duro y absorbente de lo previsto, del que
me llevo multitud de lecciones que me gus-taría
compartir con los lectores de Proiec-tus.
Meet the project
La educación digital es un área que me
apasiona, siento una profunda curiosidad
por los modelos educativos del futuro. Es un
tema sobre el que he escrito varios artículos
y entrevistas, cubriendo desde plataformas
educativas digitales hasta los novedosos
MOOC (massive open online courses).
Cuando el cliente entró en contacto conmi-go
ya conocía su producto: una plataforma
digital multi-plataforma líder en el mercado
educativo nacional. Al parecer, una gran
empresa estadounidense les había con-tratado
para desarrollar una adaptación
a medida de su plataforma. Un proyecto
aparentemente sencillo, de pocos meses,
en el cual la plataforma se desplegaría en
el cliente tras un lavado de cara a nivel de

6
interfaz gráfica e imagen corporativa, así
como determinados cambios en el flujo de
trabajo.
Sin embargo, la situación estaba lejos de
estar controlada: dos meses tras el kic-koff,
a dos meses de la finalización, apenas
había avances. El alcance se había dispara-do,
no tenían capacidad para seguir aten-diendo
a su negocio en España y además
gestionar el proyecto. Y el cliente en EEUU
empezaba a impacientarse. Les hacía falta
un jefe de proyecto.
Básicos de gestión de proyectos
De todos los aprendizajes del proyecto,
muchos son comunes a cualquier desarro-llo
de software y nada tienen que ver con
que sea internacional. Nunca está de más
recordarlos.
No escatimar tiempo en el análisis
inicial y en la definición de los
requerimientos
Hay mucha sabiduría en el dicho “cada hora
que se dedica a planificar ahorra diez horas
en la ejecución”. Un requerimiento aparen-temente
sencillo puede causar estragos en
el proyecto, especialmente si tiene impacto
en código o modelos de datos que llevan
años escritos.
En nuestro caso unos cuantos detalles apa-rentemente
nimios escaparon al análisis pre-vio
y causaron toda clase de problemas. Al-gunos
se asumieron, otros se renegociaron
como cambios de alcance y otros tuvieron
que ser desestimados por inviables.
Otra vertiente de este error es asumir depen-dencias
con terceros sin auditar previamen-te
el estado de dichos elementos e incluir
salvaguardas por si acaso no cumplen las
expectativas. La plataforma deseada tenía
una dependencia con un servicio web de
otra empresa del grupo del cliente final, uno
que en teoría era estable y estaba finalizado.
En la práctica, la empresa responsable ha-bía
cesado de ofrecer soporte porque lleva-ban
meses trabajando en una nueva versión
de la API. Más retrasos, más cambios, más
frustración para el equipo.
Optimizar la cadena de mando sin
dejar de controlar el alcance
Los stakeholders en cada proyecto son los
que son, pero unos protocolos claros pue-den
obrar milagros. ¿Qué se escala, cuán-do
y a quién? Sin herir sensibilidades,
pero con firmeza, si alguien no es nece-sario
en un comité de seguimiento que
no acuda.
Sin embargo, esta agilidad es un arma
de doble filo, es necesario mantener in-volucrado
al project owner y al sponsor,

7
proyectos
que dediquen tiempo al proyecto o, si
no es posible, que deleguen en alguien
adecuado. De lo contrario se corre un
riesgo de que no haya respuesta rápi-da
cuando haya que tomar decisiones,
que se aluda a las prisas y las agendas
apretadas, y que al final los cambios
dejen de analizarse con lupa o de vali-darse
en firme.
Nunca infravalorar el trabajo del jefe
de proyectos
Un proyecto necesita un líder y respon-sable,
un interlocutor cualificado para el
cliente que cuente con la visión global del
proyecto y que entienda del negocio. En
demasiadas ocasiones se pretende dele-gar
dichas labores en el equipo de trabajo,
lo cual no solo no funciona (lo cual implica
retrasos, sobrecostes, etc.), sino que so-mete
al equipo a un esfuerzo para el que
no están formados ni tienen experiencia,
derivando en frustración y malestar.
Conocer al cliente y sus
circunstancias
Las empresas grandes suelen ser más for-males
que las pequeñas, y en España has-ta
los más serios parecemos caóticos a
los ojos de los anglosajones. Sé precavido
cuando entres en proyectos con empresas
de fuera o más grandes que tú, que no te
ahoguen sus procesos, prevé un crecimien-to
exponencial de las necesidades de ges-tión.
Además, resulta vital dejar claro de inicio cuál
es tu capacidad para satisfacer sus necesi-dades,
que sean conscientes de hasta qué
punto puedes o no cumplir con sus procesos
en materia de entornos, despliegues, infor-mes,
auditorías, control de accesos, seguri-dad,
etc. Esto fue especialmente frustrante en
el proyecto, porque una respuesta que uno
nunca quiere dar (y que el cliente final difícil-mente
va a entender) es “le entendemos, y
ojalá tuviésemos los recursos para hacer las
cosas así de bien, pero somos una pyme
nos arruinaríamos de seguir sus procesos de
despliegue y auditorías”.
Vigilar con cuidado el rendimiento
Optimizar las prestaciones de una aplicación
no es fácil. Menos aun cuando desarrollo
es híbrido (nativo y web), multi-dispositivo y
está dirigido a un despliegue internacional.
Sal de los entornos controlados y lanza una
beta en equipos y entornos reales cuanto
antes para tomar datos, aprender y poder
corregir a tiempo (cuanto antes aparezcan
las sorpresas, mejor).
Otro factor relevante para el rendimiento,
con un gran impacto en el proyecto, fue la
interfaz gráfica. Lo que en principio iba a
ser un mero cambio de plantillas CSS re-

8
sultó en un diseño ambicioso, con múltiples
capas solapadas y pesadas animaciones
en HTML5 (todo ello desarrollado por una
agencia externa, sin nuestro input). Los pro-blemas
de rendimiento no se hicieron pa-tentes
de inicio en los equipos de desarrollo
y prueba (ordenadores portátiles y tablets
modernos), sino cuando el equipo de la In-dia
empezó a probar con tablets de bajas
prestaciones. Ya era demasiado tarde y
costoso realizar un rediseño, tuvimos que
eliminar las animaciones en las plataformas
más afectadas.
El factor distancia
Llegamos al punto álgido: ¿qué proble-mas,
situaciones y curiosidades concretas
puede uno esperar al realizar un proyecto
internacional?
En primer lugar, es necesario hacer una
composición espacio-temporal del proyec-to:
• En Estados Unidos (UTC-4) el cliente
final.
• En España (UTC+2) el desarrollador
(mi cliente).
• En Inglaterra (UTC+1) el equipo de so-porte
funcional.
• En la India (UTC+5½) el equipo de
pruebas.
Fuente: WikimediaCommons
Autor: TimeZonesBoy

9
proyectos
Se trata de doce mil kilómetros de dis-tancia,
más de nueve horas de diferen-cia
horaria, una fuente de quebraderos de
cabeza en la que la primera obviedad es
resolver como celebrar las reuniones.
Coordinando en la distancia
El proyecto se gestionaba en dos comités
de seguimiento semanales, uno funcional
los lunes y otro tecnológico los miércoles.
Correspondía al jefe de proyecto del cliente
en EEUU liderar las reuniones y coordinar al
resto de países, todo ello escrupulosamen-te
gestionado: el orden del día se emitía con
24 horas de antelación, y el acta se publi-caba
en las 12 horas siguientes. La hora de
inicio era estricta, el margen de cortesía de
5 minutos y la duración en la mayoría de los
casos inferior a lo previsto (rara vez alcanza-ba
la media hora planificada).
La diferencia horaria daba poco lugar a la
flexibilidad: las reuniones técnicas empe-zaban
por defecto a las 16:00 en España,
de forma que en EEUU ya fuese horario
laboral (10:00) y en la India estuviesen apu-rando
su hora de salida (19:30).
Esto es manejable si todos los participan-tes
utilizan sistemas de calendario compa-tibles
como Outlook o Google Calendar…
Si no (lo más frecuente) estás obligado a
tener en cuenta (y aclarar a todos los im-plicados,
constantemente) los siguientes
detalles:
• Los formatos de fecha y hora en el
mundo, y especialmente en EEUU (por
ejemplo, tener claro que las 12 a.m. del
12/31/2014 es la hora de las uvas de fin
de año).
• Los respectivos calendarios labora-bles.
Para los norteamericanos el July
4th es sagrado, y si no les avisas van
a esperar que respondas emails el Día
de la Constitución.
• El calvario de los husos horarios, ten
siempre un convertidor a mano y men-talízate
a la cantidad de nomenclaturas
y excepciones existentes, incluso den-tro
de un mismo país.
• Los cambios de hora, que cada país
hace a su manera. Por ejemplo, el cam-bio
a horario de invierno es el último do-mingo
de octubre en España, el primer
domingo de noviembre en EEUU y nun-ca
en la India (allí no se realiza cambio a
horario de verano). A nosotros nos arrui-nó
varias conferencias en la semana del
cambio de hora, tenlo en cuenta.
Gritando a los que están más lejos
La distancia debilita los corazones, y se lo
pone complicado al jefe de proyectos. No
quiero decir que la distancia sea causa di-recta
de problemas, pero va a introducir sí o

10
sí una serie de factores problemáticos que
conviene considerar (y si se puede, com-pensar):
• El idioma es un problema. Si con fre-cuencia
es complicado entenderse en el
idioma materno de uno, hacerlo de forma
eficaz y eficiente con ingleses, nortea-mericanos
e indios requiere el doble de
paciencia y esfuerzo. Las barreras cul-turales
están ahí y habrá que gestionar
sus daños colaterales: ofensas, enfados,
frustraciones y pequeñas crisis frutos de
malos entendidos. Con profesionalidad
y paciencia todo se soluciona.
• Las comunicaciones son una ba-rrera.
Email, videoconferencia, te-léfono,
VoIP, chat… nada sustituye
una reunión presencial. A veces son
verdaderamente necesarias, pero no
son posibles.
• Internet es rápida, pero el mundo
enorme. Tus usuarios en Colombia,
China y la India no van a estar satis-fechos
con el nivel de servicio que
presta tu servidor en Alemania, por
potente que sea. Abraza la nube, di-versifica
tus servidores y acércalos a
los usuarios.
• El factor China. El sistema operati-vo
más utilizado en el gigante oriental
es Windows XP. Es más, allí Internet
Explorer 6 es el navegador oficial del
cliente final (algo con lo que no con-tábamos
nosotros, y al parecer tam-poco
desde EEUU). Un mazazo para
todos.
• Los formatos de fechas y horas
causarán bugs. Es ley de vida, pare-ce
algo superado pero hasta Apple tiene
errores en el calendario de iOS. Bús-calos
sin tregua, aparecerán y son muy
complicados de cazar. ¿Un ejemplo? Un
servicio web cuya autenticación fallaba a
veces porque las librerías en un sistema
y en otro interpretaban un mismo formato
de hora de forma diferente (1:18 no es
01:18, ojo con el rellenado de ceros y es-pacios).
La dedicación y la productividad
Uno de los aprendizajes clave que me llevo
es la capacidad de dimensionar el esfuer-zo
necesario para gestionar con diligencia
un proyecto de estas características. En mi
caso ser el nodo entre tres continentes
me transformaba en cuello de botella
de las comunicaciones entre Madrid, el
Reino Unido, Estados Unidos y la India.
Imaginad un día malo como gestor de
proyectos. Uno de esos en los que nadie
sabe muy bien por qué un stakeholder
de peso decide mirar hacia el proyec-to
y entrar en pánico. O un día en que

11
proyectos
surge fallo grave de sincronización entre
la plataforma y el backend en medio de
un piloto clave. Son las 15:00 en EEUU,
las 21:00 en España. ¿Respondes o no?
Claro que sí.
En otras palabras, un proyecto interna-cional
que abarca medio planeta requie-re
atención 12 horas al día. ¿A tiempo
completo? No necesariamente (depen-de
de la magnitud del proyecto y de la
fase en la que se encuentre, claro). En
mi caso, difícilmente fui capaz de dedicar
menos de tres horas al día, una por la
mañana, otra después de comer y otra
bien entrada la tarde. Ni que decir tiene
que este tipo de dedicación penaliza a
cualquiera cuyo trabajo no sea gestionar
proyectos a tiempo completo, la multita-rea
impacta en la productividad y en la
capacidad para afrontar otros proyectos.
Pero es imprescindible si no se desea
penalizar el proyecto completo, un retra-so
de media hora en la gestión un asunto
puede retrasar varios días su solución.
Conclusiones
La distancia es una de los mayores
obstáculos que se pueden interponer
entre un gestor y su proyecto. La distan-cia
impacta de lleno en su principal activo:
el flujo de información y su capacidad de
interpretarla libremente. Miles de kilómetros
y varias horas por delante (o por detrás) en
el calendario, el gestor pierde el feeling del
proyecto y las personas que lo forman, se
nubla su visión general, pierde capacidad
de identificar y anticiparse a los riesgos.
Por supuesto, todo esto se complica si
te incorporas a un proyecto ya comen-zado
en el que los requerimientos fun-cionales
y técnicos no están escritos en
piedra. No debería pasar, pero pasa,
es mejor estar preparado: intentar ser
aún más estrictos con las metodologías,
imponer la cordura con un control de
cambios que involucre al project owner
y al sponsor, vigilar las expectativas del
cliente (¡tanto de alcance como de pro-cesos!),
etc.
¿Y el factor internacional? Exigirá del
don de la ubicuidad: estar en todo, a
todas horas, para mantener los engra-najes
girando y desbloquear asuntos
ASAP. Suplir las barreras del idioma y la
comunicación con más interacción, más
esfuerzo y mejor predisposición si cabe.
Imprescindible también será la investi-gación,
no dar por hecho que en otros
países las personas y las tecnologías
son como en casa.
Para cerrar, compartiré una cifra repre-sentativa:
el esfuerzo final del proyecto

12
superó un 74% las horas previstas
inicialmente, extendiéndose tanto en
esfuerzo diario como en duración. Afor-tunadamente
tanto el cliente como yo
estábamos satisfechos con la colabora-ción
y pudimos renegociar al alza, pero
no dejó de ser toda una lección de pla-nificación
para ambos.
Nadie dijo que estrenarse en gestión de
proyectos internacionales fuese fácil.

Carlos Javier Pérez Escobar
Instructor certificado por el CMMI Institute para los cursos de Intro CMMI Development,
Services and Acquisition Supplement, con Maestría en Ciencias de la Computación por el
IIMAS de la UNAM y graduado de Ingeniero en Sistemas Automatizados de Dirección en
el ISPJAE en La Habana, Cuba.
13
El proyecto CMMI, un proyecto de mejora
organizacional
organizacional
Generalmente un proyecto es entendi-do
como el conjunto de actividades que
realizan los individuos para alcanzar un
objetivo conforme a un plan, delimitado
en un tiempo para generar determinados
resultados con los recursos, infraestruc-tura
y el presupuesto establecido. Los
proyectos de mejora de procesos, en
los que se puede considerar la adopción
de las prácticas de CMMI consideran
los mismos componentes y debe gestio-narse
de igual forma. Aquí se presentan
consideraciones generales para gestio-nar
los recursos humanos y las primeras
actividades para arrancar un proyecto
de mejora en la organización.
Típicamente se habla del proyecto CMMI
para identificar el proyecto de cambio en
la organización a nivel de procesos don-de
se incorporan las prácticas definidas
en el modelo CMMI. Dependiendo del al-cance
y necesidades de la organización
se requerirán determinadas considera-ciones
que pueden afectar el contexto
del proyecto.
Los proyectos de mejora de procesos
suelen ser más complejos, a diferencia
de otros proyectos, porque no crean u
ofrecen “algo” sino que transforman la
forma en que se hacen u ofrecen los
productos o servicios. Mayormente se
relacionan con entidades abstractas y
eso dificulta los resultados como se re-fleja
en Ilustración 1. Dificultades en
la gestión de proyectos de mejora . El
enfoque del proyecto es mejorar y eso,
por su naturaleza, es extremadamente
complicado.

14
¿Qué es CMMI?
CMMI1 es el acrónimo de Capability
Maturity Model Integration y se refiere
a los modelos que contienen las mejo-res
prácticas que ayudan a las organi-zaciones
a mejorar sus procesos. Han
sido desarrollados por equipos de tra-bajo
formados por especialistas de la
industria, el gobierno y el Software En-gineering
Institute (SEI) que transfirió
los derechos al CMMI Institute para su
operación y comercialización.
Contiene elementos esenciales de un
proceso efectivo y propone una forma
de adopción para la organización que
permite incrementar la calidad y produc-tividad,
al tiempo que controla el presu-puesto
y los compromisos establecidos.
Cada una debe interpretar, adoptar y
aplicar aquellas prácticas que le apoyan
en el logro de sus objetivos y cumpli-miento
de sus necesidades de manera
eficiente.
El enfoque del modelo permite evolucio-nar
desde un proceso en crisis a un pro-ceso
controlado, estandarizado, medido
y optimizado que sienta las bases de la
mejora continua y permite a la organiza-ción
adoptar nuevas prácticas sobre un
proceso estable que está institucionali-zado
o entendido y asimilado.
El elemento central en que se organizan las
prácticas en el modelo lo constituyen las
áreas de proceso. Está estructurado para
facilitar su uso en componentes que definen
la forma y modo de aplicarlo, considerando
los que son obligatorios, sugeridos o el ma-terial
informativo en las áreas de proceso.
En general el documento se puede revisar
en función de metas, prácticas y subprácti-cas
con el resto del material informativo.
Existen tres constelaciones o modelos que
se complementan con elementos comunes
a nivel de áreas de proceso. Según el mo-delo
que se utilice se puede obtener el do-cumento
con las guías que ayudan en:
• Desarrollo y mantenimiento de productos
y servicios (CMMI DEV),
• Adquisición de productos y servicios
(CMMI ACQ) y
• Establecimiento, entrega y gestión de los
servicios (CMMI SVC).
El modelo considera dos enfoques o rutas
para adoptar las mejoras y medir el nivel
en que han evolucionado que se conocen
como representaciones. En una forma se
consideran áreas de proceso de manera
individual y se califican en niveles de ca-pacidad
de acuerdo con la representación
continua. El otro enfoque considera un con-junto
preestablecido de áreas de proceso

15
organizacional
que constituyen un nivel de madurez y que
es la forma de evaluar la representación es-calonada
o por etapas.
Los recursos humanos en el
proyecto de mejora
Un proyecto de mejora requiere que la
gente cambie su comportamiento, es un
cambio organizacional. Para salir del esta-do
actual es importante que la gente esté
receptiva, que acepte que es necesario y
que no haga resistencia al cambio. Para
avanzar en la mejora, se deben proponer
soluciones para salir de los problemas
existentes y fortalecer los factores que
promueven el cambio y suprimen las ba-rreras.
Al final, se requiere que los cambios
formen parte de la forma de operación
en la Organización de manera perma-nente.
Un proceso mejor debe traducirse
en más ganancia y una mejor operación.
Los procesos son valiosos cuando descri-ben
la forma en que opera la Organización
y además, son aceptadas por el personal.
Por ello es fundamental que: sean útiles
para diferentes tipos de proyectos dentro
de la Organización, presentados en un
lenguaje sencillo y gráfico siempre que sea
posible, y basados en propuestas de me-jora
comunicadas, entendidas, acordadas
y respaldadas que permitan el desarrollo,
publicación y mantenimiento continuo.
Es importante definir objetivos, planear in-dicadores
para monitorearlos e integrarlo
en el plan de mejora. Cada mejora debe
contribuir a perfeccionar los objetivos del
negocio y motivar al personal a modificar su
comportamiento. Para alcanzar esos ob-jetivos
hay que establecer acciones como
parte del plan de mejora, el cual es integra-do
en las actividades de la organización.
El proyecto de mejora debe ejecutarse
con la misma persistencia que la opera-ción
diaria. Para seguir el proyecto de
mejora, aún en situaciones difíciles en la
Organización, es importante demostrar a
la gente que la mejora es esencial para la
visión, objetivos de negocio y satisfacción
del cliente. El personal necesita motivación
para el cambio y evitar así, consecuencias
indeseadas. Como beneficios se obtienen
incremento de la eficiencia, mejor calidad
del producto a través de mejores proce-sos,
confianza del cliente por los altos ni-veles
de capacidad, ventajas competitivas
para el negocio y empleados comprometi-dos
con la mejora continua.
Ruta hacia la mejora
Siempre que iniciamos un proyecto, ac-tividad
o cualquier cosa que estemos in-tentando
comenzar, la primera pregunta
que nos asalta es ¿por dónde empiezo?
Definitivamente para iniciar un proyecto de

16
mejora, necesitamos saber cómo están
las prácticas de la organización y a dónde
queremos llegar, para establecer accio-nes
y saber cómo lo vamos a solucionar.
Es imprescindible tener una necesidad
real de cambio, identificar que algo no
está funcionando o no puede continuar
como está para lograr un motivador con-creto
y objetivo. Lo recomendable es ini-ciar
con una revisión, auditoría o evaluación
de lo que se tiene y lo que falta por hacer.
El modelo CMMI puede funcionar como
un checklist de buenas prácticas pero
no podemos perder de vista lo que real-mente
es necesario para la organización.
También es importante saber a dónde que-remos
llegar, cuales son las metas, motiva-dores
y el nivel de compromiso de la direc-ción
de la organización con este esfuerzo.
Es una inversión de recursos en todo sen-tido
que no podemos abandonar a mitad
de camino por falta de visión. Es elemental
tomar indicadores de la situación actual en
relación a los objetivos de mejora y poder
demostrar con los resultados que los be-neficios
se están logrando. Adicionalmente
a los elementos mencionados como todo
proyecto requiere evaluar un presupuesto,
establecer un cronograma, identificar ries-gos,
establecer e implementar mecanismos
de comunicación, gestionar los recursos y
controlar la ejecución del proyecto.
En el modelo CMMI el área de proceso
de OPF i establece las prácticas requeridas
para ejecutar un proyecto de mejora, es con-veniente
revisarlas para identificar lo que se
debe hacer y apoyarse con el ciclo IDEALii
como hoja de ruta para implementarlas. En
la Ilustración 2. Actividades para el inicio
del proyecto de mejora se muestran los
pasos a seguir para garantizar un arranque
efectivo del proyecto.
La parte más “fácil” de todo el proyecto es
entender cómo solucionarlo y aplicar el mo-delo
como parte de la solución, el proble-ma
real es lograr hacerlo. Dejamos como
referencia algunas recomendaciones que
pueden ser de gran beneficio para lograr
el resultado en la Ilustración 3. Consejos
para el éxito del proyecto de mejora. En
resumen se requiere identificar la necesi-dad
del cambio, determinar que se requiere
i Organizational Process Focus es el area de proceso del CMMI que se relaciona con las prácticas del proyec-to
de mejora en la Organización.
ii Initiation – Diagnosis – Executing – Acting - Learning son las etapas del ciclo de mejora definido por el SEI

17
organizacional
cambiar y los objetivos a alcanzar, garanti-zar
el compromiso para lograr los cambios,
involucrar al personal en las actividades del
proyecto y evaluar la forma en que se alcan-zan
los beneficios.
Mullaly2 identifica cinco problemas que son la base de la complejidad y particularidad en la gestión
de proyectos de mejora de procesos
1. Personas. Muchas veces los que quieren los cambios en los procesos no necesariamente son
los que lo ejecutan. Son muy raras las ocasiones en que los que están operativamente realizando
las actividades identifican la necesidad de cambio, mayormente los cambios son impuestos sobre
ellos sin estar convencidos de la necesidad.
2. Cambio. Un proyecto de mejora implica la gestión del cambio y cambiar el comportamiento de
las personas en particular es una actividad muy compleja.
3. Errores. Los resultados se obtienen por “prueba y error”. La adopción de los cambios es pro-bado
y con base en los resultados modificado para seguir probando hasta obtener una solución
“óptima”
4. Mediciones. La obtención de medidas e indicadores de resultados es vital para conocer si
realmente se obtienen mejores resultados. Debido a que los procesos no están completamente
entendidos y aplicados la recolección de información puede ser costosa y difícil en cierta forma.
5. Compromiso. Los procesos afectan la operación y precisamente la presión política, que pre-supone
para los gerentes y supervisores aceptar que les digan lo que deben hacer y que puede
poner en juego su poder e influencia, es compleja para el equipo de mejora.
Ilustración 1. Dificultades en la gestión de proyectos de mejora

En la fase de Inicio del modelo IDEAL3 el propósito general es encontrar una razón suficiente para
justificar el proyecto de mejora en beneficio de la organización antes de comprometer los recursos.
Las actividades que se ejecutan son:
1- Iniciar la fase
2- Identificar las necesidades del negocio y los motivadores para la mejora
3- Elaborar la propuesta de mejora de procesos
4- Apoyo en formación y desarrollo
5- Obtener la aprobación de la propuesta inicial de mejora y de los recursos para el proyecto
6- Establecer la infraestructura para el proyecto de mejora
7- Evaluar el clima para el proyecto de mejora
8- Definir los objetivos generales de mejora
9- Establecer los principios que guían el proyecto de mejora
10- Lanzar el proyecto
Ilustración 2. Actividades para el inicio del proyecto de mejora
• Establecer las expectativas en relación con lo que se espera del proyecto, por qué es necesario
y qué es lo que debe cambiar o mejorar. Estos elementos se consideran como parte del plan estraté-gico
de mejora y tiene la función principal de comunicar a los interesados las bases del proyecto y la
18
forma en que deben conducir sus actividades.
• Determinar y definir claramente la situación actual de la operación, lo cual será tomado como
base para determinar los cambios y establecer las medidas e indicadores que demostrarán los resul-tados
obtenidos.
• Definir claramente los objetivos a mejorar. Cuáles son las metas que se quieren alcanzar, cuá-les
son los elementos que se deben atender para lograr esas metas y cuáles son los resultados que
se esperan alcanzar. Cualquier cambio de objetivo implica cambios en el alcance del esfuerzo y debe
ser debidamente evaluado.
• Garantizar el apoyo y patrocinio efectivo de la Dirección es crítico para el proyecto, el respon-sable
de proyecto puede gestionarlo pero requiere que la Dirección esté al frente defendiendo y abo-gando
por la mejora. La deserción, resistencia, cuestionamientos y quejas deben ser políticamente
conducidos y atendidos por la Dirección. Para ello se requiere conocimiento, compromiso, liderazgo,
confianza y acción bajo el propio ejemplo para defender el proyecto y la necesidad de cambiar la
forma anterior de operar.
• Asegurar que el proyecto considera y permite a todos los interesados entender la necesidad del
cambio y actuar para cambiar el comportamiento. El proyecto es para mejorar y eso debe ser
el centro de toda la gestión.
• Evaluar periódicamente los resultados e identificar situaciones que no están contribuyendo a
obtener los objetivos esperados. La identificación oportuna de focos rojos que no están mejorando
el resultado deben permitir de inmediato corregir el comportamiento antes de que la afectación sea
mayor.
Ilustración 3. Consejos para el éxito del proyecto de mejora

19
organizacional
Referencias:
1 CMMI DEV version 1.3, “Improving processes for
developing better products and services.” (CMU/
SEI-210-TR-033). Software Engineering Institute,
Carnegie Mellon University. November 2010.
http://cmmiinstitute.com/resource/cmmi-for-development-
version-1-3/
2 Mullaly, Mark:”Managing Process Improvement”,
projectManagement.com, March 2013.
http://www.projectmanagement.com/
articles/277644/Managing-Process-
Improvement
3 McFeeley, Robert. “IDEAL: A User’s Guide for
Software Process Improvement” (CMU/SEI-96-
HB-001) Pittsburgh, PA. Software Engineering Insti-tute,
Carnegie Mellon University, February 1996.
http://resources.sei.cmu.edu/asset_files/
Handbook/1996_002_001_16433.pdf

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).
Dirigiendo proyectos para implantar un ERP
20
¿Cómo implantar adecuadamente un sistema
de gestión en una empresa? ¿Cómo asegu-rarse
de que se cumple adecuadamente las
fechas previstas, se atiende todo lo necesario
y se evitan problemas? ¿Conseguiremos que
el cambio en el sistema informático de la em-presa
sirva para darle impulso y generar una
ventaja competitiva sostenible en el tiempo
(al más puro estilo de la definición de Michael
Porter 1), o bien pasará a convertirse en un
lastre que la hace más burocrática y menos
eficiente? Estas son algunas de las pregun-tas
que frecuentemente se realizan gerentes
y directores de IT de muchas organizaciones.
Ya se trate de implantar un sistema ERP 2 o
sustituir el existente, o hablemos de implan-tar
una solución específica de un área (SCM 3
o WMS 4 en el ámbito logístico, CRM 5 en el
área comercial y de marketing,…), se trata de
una decisión estratégica en cualquier empre-sa,
no siempre exenta de polémica, tensión y
conflictos.
En el presente artículo presentaremos
las principales dificultades a las que se
puede enfrentar una organización que
se plantea cambiar de ERP (si bien po-dría
extrapolarse a cualquier otro tipo de
herramienta de gestión), y analizaremos
en qué medida la dirección de proyec-tos
puede ayudarnos a llevar este reto a
buen término.
Un cambio de ERP es un cambio de
sistema
Uno de los aspectos más importantes a
considerar en la implantación de un siste-ma
ERP o similar es que se trata, ante todo,
de un cambio profundo en la organización.
En realidad no es meramente un cambio
informático, sino que frecuentemente ha-blamos
de una transformación profunda
en la forma de operar de todo un sistema.
¡Hay implantaciones de ERP que resultan
más traumáticas que trasladar la sede de
un lugar físico a otro!

21
Nos encontramos, por tanto, ante un
cambio organizativo. Un engranaje que ha
ido puliéndose a lo largo de los años, ins-taurado
a través de procedimientos (más
o menos lógicos), de tareas (más o menos
eficientes) y de hábitos (más o menos inte-ligentes)
que se ve sometido a numerosos
cambios en forma e incluso en trasfondo.
En tal sentido, la gestión de la integra-ción,
tal y como la concibe el PMBOK
puede resultar crítica para asegurar el
éxito del proyecto. Resulta frecuente que,
ante un cambio tan complejo, pocas per-sonas
tengan la capacidad de ver todo el
mapa en su conjunto, entendiendo que
una modificación en un determinado as-pecto
(un proceso de ventas) puede tener
su repercusión en otro (el cálculo de las
comisiones tras su impacto en la cuenta
de resultados, observable tras la contabi-lización
de dichas ventas).
Muchos miembros del equipo de proyec-to,
consultores de negocio y técnicos,
tienden a centrarse en su ámbito de es-pecialidad,
ignorando el resto de ámbi-tos.
Sin embargo, el director del proyec-to
debe mantener en todo momento esa
visión holística para alinear necesidades
con acciones y para mantener coheren-te
el plan del proyecto con los resultados
requeridos.
Resulta frecuente en este tipo de proyectos
que se vaya refinando los requerimientos de
la organización que recibe la implantación
del sistema ERP, surgen nuevas necesida-des
no previstas o aparecen nuevas accio-nes
a realizar a medida que los consultores
de negocio conocen con mayor profundi-dad
cómo trabajan los usuarios. En este
contexto de descubrimiento por avance, un
adecuado control de cambios puede su-poner
la diferencia entre el éxito y el fracaso
de la implantación.
Dos equipos de trabajo, ¿un
objetivo común?
Cada empresa podría considerarse un sis-tema
complejo, semejante a un ente vivo,
que evoluciona. Y de la misma manera que
no hay dos personas iguales, tampoco hay
dos empresas que sean idénticas en su for-ma
de trabajar, de gestionar los datos que
la componen y de actuar frente a las nece-sidades
del mercado.
En este sentido, el conocimiento del equi-po
de implantación procedente de proyec-tos
anteriores es importante, pero en raras
ocasiones resulta suficiente. Las estima-ciones
por analogía para valorar cuánto
esfuerzo requiere una tarea serán aproxi-madas,
puesto que no se conoce a priori
todo el detalle de los procesos de negocio,
ni se conoce bien a los usuarios que los

22
ejecutan. Por ello, suponer que dos empre-sas
trabajarán con el sistema informático
de igual manera puede ser una hipótesis
errónea, ya que el talento existente en cada
organización, la cultura corporativa y el es-tilo
que nos identifica como seres humanos
únicos marca pautas en cómo hacemos las
cosas. En este caso, la diversidad juega en
nuestra contra.
En el otro lado de la mesa, tenemos a los
usuarios que actualmente conocen con
excepcional lujo de detalle cómo opera su
empresa, pero desconocen cómo funciona
la nueva herramienta de gestión, y cómo se
adaptará a su negocio (este último punto es
lógico, ya que de lo contrario no haría falta
la presencia de un equipo de consultores
en la implantación).
En definitiva, dos equipos de trabajo que en
el mejor de los casos estarán bien liderados
por sus correspondientes responsables y
estarán alineados en conseguir una implan-tación
con éxito, pero que no se conocen
entre sí, poseen un perfil y experiencia di-ferentes
y, bajando a nivel de detalle, tie-nen
objetivos a corto plazo distintos (unos
estarán preocupados por una implantación
rápida y sin incidencias, y los otros esta-rán
preocupados en que el cambio tenga
un mínimo impacto en su forma de trabajo
actual).
La mayor parte del
conocimiento es tácito
Por si fuera poco, además, es importan-te
tener en consideración que gran par-te
de todo el conocimiento necesario en
el proyecto pertenece a la categoría de
conocimiento tácito, difícil de estable-cer
en procedimientos y, por extensión,
complejo de documentar y sistematizar.
De la misma manera que un consultor
especializado con muchos años de ex-periencia
posee un bagaje que le permi-te
actuar en numerosas circunstancias,
un responsable de compras con talento
y que lleve varios años en su empresa
tendrá un extenso conocimiento que le
permite realizar pedidos óptimos. Y la
mayor parte del conocimiento que cons-truye
las decisiones de ambos profesio-nales
se ha conformado con numerosas
iteraciones de los procesos y de mucha
reflexión no verbalizada. Hay responsa-bles
de compra que realizan aprovisio-namiento
considerando lo que ven en
las noticias (el caso de aluminio en el
ámbito industrial) o viendo la fluctuación
meteorológica (el caso de la producción
de cerveza), de la misma forma que un
consultor experto sabe las dificultades
que tendrá en la consolidación conta-ble
simplemente analizando la comuni-cación
no verbal del director financiero
cuando se sienta con él.

23
El juicio de expertos es una técnica valiosa en la implanta-ción
de ERPs
Imágen con licencia Creative Commons
Autor: Kevin Dooley
Desde un punto de vista de dirección de
proyectos, es importante considerar este
conocimiento no formalizado a través de la
técnica juicio de expertos. Resultará fun-damental
para algunos procesos, como la
estimación de la duración de las activida-des,
la validación de alcance o la identifi-cación
de los riesgos del proyecto. No es
infrecuente que el director de un proyecto
de implantación de un ERP esté constante-mente
aplicando esta técnica para recabar
criterios y para realizar una adecuada toma
de decisiones.
El problema del alcance en los
ERP
Como se ha mencionado anteriormente, la
implantación de una nueva herramienta de
gestión en una empresa es, eminentemen-te,
un proyecto de cambio organizativo, y
que se aborda a través de un itinerario de
descubrimiento por avance.
La ausencia de conocimiento detallado de
lo que puede hacer la nueva herramienta
por parte de los usuarios, y la falta de co-nocimiento
detallado de los procesos de
negocio por parte de los consultores hace
que el proyecto parta de un mayor o me-nor
grado de incertidumbre, que deberá ser
atajada a medida que se avanza en el ca-lendario.
Como norma general, en la fase previa a la
de ejecución del proyecto, el equipo de tra-bajo
que realiza la implantación suele reali-zar
un análisis más o menos extenso de las
posibles necesidades y requerimientos de
los procesos de negocio, con el fin de eva-luar
la viabilidad del proyecto (y de estable-cer
las condiciones económicas iniciales, si
quien realiza los servicios de implantación
es una empresa externa). Pero este cono-cimiento
de partida rara vez cubre toda la
casuística posible del día a día de la orga-nización
que implanta la nueva herramienta
de gestión.
Para tratar de solventar este problema, es
frecuente dividir el proyecto en fases,
siendo habitual que la primera de ellas se

24
centre en el análisis de procesos de nego-cio
y de requerimientos. De esta forma, se
estructuran diferentes sesiones de trabajo
entre consultores y usuarios, con el objeti-vo
de adquirir un mejor entendimiento de lo
que conllevará el proyecto a nivel de detalle.
Posteriormente, tras una validación inicial
del alcance, se re-planifica el trabajo res-tante
necesario en el proyecto y se prosigue
con la siguiente fase, en la que se procede
a implementar todas aquellas necesidades
de negocio establecidas. Para facilitar tan-to
la verificación como la validación, suele
establecerse un calendario de prototipos,
conjuntos de funcionalidades más o menos
completas y refinadas para su demostra-ción
y prueba.
Desafortunadamente, en el momento de
presentar un prototipo es frecuente que
aparezcan nuevos requerimientos (obvia-dos
en la fase de análisis por despiste o
por cualquier otro motivo), se modifique los
requerimientos ya existentes (porque hubo
dificultades de comunicación o de enten-dimiento)
o se descubra nuevas necesida-des
no previstas. Esto podría suponer una
ampliación en el alcance, cuyo coste puede
o no asumir la empresa cliente (en función
de las negociaciones comerciales iniciales
o posteriores) pero que normalmente no se
desea que impacte en el calendario ni en la
fecha prevista de finalización del proyecto.
Esto supone un problema importante des-de
el punto de vista de dirección de pro-yectos.
Sólo se conocerá con exactitud lo
que se va a realizar una vez que el proyecto
ha finalizado, pero para cumplir tiempos y
costes se requiere un avance planificado y
estructurado de un trabajo que aún no se
sabe con detalle de qué estará compues-to.
Dicho de otra manera, los paquetes
de trabajo y la Estructura de Desglose
de Trabajo se construyen a medida que
el proyecto avanza, pero suele requerirse
un Diagrama de Gantt desde el minuto 0
y que posea un margen de desvío lo más
bajo posible. Todo un reto para cualquier
experto en planificación.
Gran parte del problema en un proyecto de
este tipo, como se puede deducir, radica
en el Alcance del proyecto, especialmente
en el proceso de Validación del Alcance.
De hecho, en muchas organizaciones esta
situación se agrava si además los usuarios
finales no tienen contacto con el equipo
de consultores, por la presencia de inter-locutores
que actúan de intermediarios, y
la labor de análisis de requerimientos no se
realizó de forma realista. En este sentido,
la ausencia de una adecuada Gestión del
Cambio (por ejemplo, siguiendo el modelo
de Kotter 6) y los problemas de comunica-

25
ción (malas interpretaciones, suposiciones,
falta de información) establecen el prefacio
de la crónica de un fracaso anunciado.
El calendario es un aspecto
crítico
A diferencia de muchos otros proyectos, la
implantación de un sistema ERP suele te-ner
una mayor sensibilidad al calendario que
otro tipo de herramientas informáticas, de-bido
al impacto en la gestión financiera de
la organización. De hecho resulta frecuente
que el departamento de Administración de
una empresa sea quien establezca el co-mienzo
de año para el cambio de sistema
informático como un requisito indispensable
para abordar el proyecto.
Debido a las altas dosis de incertidumbre
inicial, a que el conocimiento tácito de las
personas establece muchas veces el crite-rio
para actuar y a que el alcance deman-da
altas dosis de flexibilidad, resulta espe-cialmente
difícil la gestión del calendario de
este tipo de proyectos.
Adicionalmente, hay elementos presentes
en todo tipo de proyectos que favorecen
retrasos y desvíos temporales, como la Ley
de Parkinson (toda tarea se dilata a lo lar-go
del tiempo hasta ocupar la totalidad del
tiempo disponible) o la Teoría de las Limita-ciones
de Goldratt 7.
Por ello, es muy frecuente realizar planifi-cación
gradual, refinando a nivel de de-talle
únicamente las acciones a corto pla-zo,
y estableciéndose planificación hacia
atrás, partiendo de la fecha de arranque
(puesta en marcha del nuevo sistema) y
definiéndose las fechas previas necesarias
hasta llegar a la fecha actual.
Algunas técnicas, como el análisis Mon-tecarlo
o el método de la cadena críti-ca,
pueden ser excepcionalmente útiles
para mejorar la gestión del calendario de un
proyecto considerando los posibles riesgos
existentes y estableciendo buffers para
hacer frente a las posibles dificultades que
seguro surgirán.
Las personas son la pieza clave
Es frecuente oír en muchos ámbitos, es-pecialmente
en la publicidad y acciones
de marketing de las empresas de servi-cios,
que ‘las personas son lo más im-portante’.
A pesar de que pueda ser un
tópico en muchos casos, en los proyec-tos
de implantación de sistemas ERP es
un paradigma clave para alcanzar el éxi-to.
Si partimos de la premisa de que ante
todo nos encontramos en un proyecto
de cambio organizativo, donde impera
el conocimiento tácito no estructurado

La interacción con el equipo de trabajo y con los usuarios es clave para el éxito
26
y donde las mayores fricciones surgen
de la validación del alcance, es lógico
considerar que las personas juegan una
pieza clave en el proyecto, con una rele-vancia
muy superior al aspecto técnico
informático. Y es que, ante todo, somos
personas colaborando mutuamente para
alcanzar nuestros objetivos.
En muchas ocasiones, un buen equipo
de consultores, debidamente cohesiona-do
a través de un adecuado liderazgo
situacional y de técnicas de teambuil-ding,
correctamente equilibrado en sus
conocimientos técnicos y compensado
convenientemente aplicando la teoría
de Roles de Belbin 8, puede proporcio-nar
mejores resultados implantando un
ERP limitado que un equipo sin talento ni
coordinación que implanta el mejor ERP
del mercado.
Por otro lado, la correcta gestión de stake-holders
o interesados también es crítica de
cara a conseguir la mayor cooperación po-sible
de todas las personas implicadas, ante
lo que influye enormemente la gestión de
las comunicaciones en el proyecto. Los
problemas derivados de malas interpre-taciones,
confusiones y malos entendidos
pueden ser fácilmente gestionados a través
de una comunicación eficaz promovida por
el director del proyecto, así como puede fa-cilitar
que todas las personas tengan el co-nocimiento
necesario para tener una visión
adecuada del éxito. Y es que gran parte de
la jornada de un director de proyectos, es-pecialmente
en la implantación de un ERP,
Imagen con licencia Creative Commons
Autor: Woodley Wonderworks

27
la emplea en comunicarse y asegurarse de
que todas las piezas estén alineadas.
Conclusiones
La implantación de un sistema ERP es una
tarea ardua y compleja, debido a que más
allá de un cambio informático, se trata de
una profunda transformación de una orga-nización,
en la que la cultura corporativa, la
presencia (o ausencia) de talento y la ges-tión
del cambio son aspectos tan impor-tantes
como la funcionalidad del software
a implantar.
Para abordar una implantación de estas
características con éxito es necesario una
adecuada planificación y coordinación de
las tareas, un adecuado seguimiento de las
mismas, mantener una visión global duran-te
todo el desarrollo y saber dar respuesta
a los inconvenientes que aparezcan a lo lar-go
del camino. Dicho de otra forma, para
implantar con éxito un ERP se requiere
una gestión eficaz de proyectos.
En este sentido, la aplicación de buenas
prácticas en dirección de proyectos, tales
como las recogidas en el PMBOK, pue-den
generar resultados muy positivos. Una
correcta gestión de la integración, una
gestión de riesgos eficaz y una adecuada
gestión de recursos humanos, intere-sados
y comunicaciones pueden ser las
áreas de conocimiento más relevantes en
este tipo de proyectos.
Por supuesto, PMBOK no es la única alter-nativa
viable para conseguir resultados si-milares.
Y de hecho, la aplicación sin más
de esas buenas prácticas no garantiza el
éxito de por sí sin una correcta ejecución y
sin adaptarlo adecuadamente a las nece-sidades
de cada caso en particular. ¿Pero
cuándo no?
REFERENCIAS
1 Michael Eugene Porter (1947, -): profesor de Har-vard
Business School y experto reconocido a nivel
mundial en estrategia corporativa. Es autor de nu-merosos
libros y artículos sobre estrategia y com-petitividad.
2 ERP – Enterprise Resource Planning: sistema de
gestión que trata de aglutinar todos los procesos o
los procesos críticos de una empresa.
3 SCM – Supply Chain Management: sistema orga-nizativo
para administrar el flujo de materiales des-de
el aprovisionamiento hasta la entrega al cliente.
En ocasiones se respalda con una herramienta
informática, denominada también SCM.
4 WMS – Warehouse Management System: sof-tware
especializado en la gestión operativa de un
almacén.

28
5 CRM – Customer Relationship Management: en-foque
de marketing para establecer todas las accio-nes
de una empresa centradas en el cliente y en su
experiencia como tal. En ocasiones se respalda con
una herramienta informática para el seguimiento de
dichas acciones, denominada también CRM.
6 John Kotter (1947, -): profesor de Harvard Busi-ness
School y experto reconocido a nivel mundial
en liderazgo empresarial y cambios organizacio-nales.
Estableció un modelo de cambio basado en
ocho pasos secuenciales en su libro “Liderando el
Cambio” (1995).
7 Eliyahu Moshe Goldratt (1947, 2011): doctor en
Física y creador de la Teoría de las Limitaciones.
En su obra “La Meta” estableció un paradigma en
gestión de procesos basado en la reingeniería de
procesos para reducir cuellos de botella a nivel
organizativo.
8 Teoría de comportamiento de personas traba-jando
en equipos. Léase Revista IT PROIECTUS
Número 2.

JOSÉ SELAYA
Consultor independiente especializado en Gestión del cambio y evangelizador de marcos
de buenas prácticas. Ostenta en la actualidad de 17 acreditaciones oficiales en diferen-tes
ámbitos (Prince2 Practitioner, ITIL Expert, MSP, P30, M.o.R, Scrum Manager, ISO20K,
ISO27K,etc ... Es colaborador internacional de Axelos como asesor en traducciones de
marcos de buenas prácticas y exámenes en lengua castellana. Actualmente colabora con
Globallynx.com en la organización de formaciones acreditadas ITIL® a lo largo del conti-nente
Europeo, empresa acreditada por Peoplecert.
29
ITIL ® y la Gestión de Proyectos
En una de mis primeras aproximaciones
a ITIL® allá por el año 2005, me llamó
sumamente la atención el “cortocircuí-to”
que existía en los temarios oficiales
a la hora de explicar la estrecha relación
entre este marco de buenas prácticas y
la necesidad de abordar los proyectos
tanto a la hora de introducir, cambiar o
retirar servicios/productos de la cartera
corporativa.
Ni la versión 3 ni la actualización 2011
quisieron ir más allá del hecho de ha-cer
referencia a la gestión de proyectos
como algo necesario pero externo/ajeno
al alcance.
Es acabar una formación y muchos asis-tentes
preguntan, “”tenemos la teoría
clara, pero esto cómo se implementa,
adopta”” ¿?, tendremos que coordinar
diferentes departamentos, fases etc, ne-cesitaremos
gestionar por proyectos ¿?
No es mi pretensión adentrarme en las
“tinieblas teóricas” de ITIL hasta un nivel
cansino, sino mas bien plasmar una serie
de conceptos que den píe a la reflexión
sobre la conveniencia de enlazar un mar-co
de gestión de proyectos adecuado al
uso de esta buena práctica.
Dentro del ámbito Táctico-Operativo, to-memos
por ejemplo 2 procesos dentro
del Diseño del Servicio, así como Transi-ción
del Servicio., Serían respectivamen-te:
• Diseño del Servicio à Coordina-ción
del Diseño
• Transición del Servicio à Soporte
y planificación de la transición.
Coordinación del Diseño fue añadido
como proceso nuevo en la actualización
(que no versión) 2011. Es un elemento
muy significativo ya que engloba en su al-cance
la responsabilidad de gestionar to-

30
dos los procesos involucrados dentro del
Diseño del Servicio, tanto a nivel de segu-ridad,
capacidad, disponibilidad etc. etc.
siendo por tanto un reto en cuanto aunar
tanto la gestión técnica como la gerencial
más enfocada al negocio.
Es por ello que
se requiere la
definición y
ejecución de
un proyecto
que identifique
las partes invo-lucradas,
anali-ce
los riesgos,
autorice fases
etc. etc...
Durante mi época trabajando como ges-tor
de proyectos en Sun Microsystems,
se aunaron elementos propios de los
procesos de Diseño de ITIL dentro de
la ejecución un proyecto Bajo principios
basados en Prince2, de tal forma que se
pudieran entregar productos que había
que diseñar, construir, probar y desple-gar,
facilitando una transición minimi-zando
en lo posible el impacto al entor-no
productivo.
Referente al otro proceso mencionado
(“Soporte y planificación de la transición”),
se encargaría de tomar el relevo a Diseño
del Servicio, el cual facilitaría como resul-tado
de su proyecto el paquete de diseño
del servicio. Durante la fase de transición,
este proceso es el encargado de gestio-nar
los recursos y capacidades para poder
construir y probar la viabilidad del producto
que se va a desplegar en la fase operativa.
En Sun utilizábamos puntos de revisión
significativos (“Peajes”/Toolgates), para
poder comparar los diseños con los pro-ductos
finalmente montados, evaluar
desviaciones y sus pertinentes justifica-ciones
cara a la gestión financiera y del
tiempo disponible, en definitiva, gestionar
el proyecto, apoyándonos en los proce-sos
de ITIL® para ejecutar las actividades,
teniendo en mente que es un marco des-criptivo.

31
Sirvan de ejemplo estos dos procesos
a modo de ejemplo para poder eviden-ciar
lo transcendental que resulta poder
coordinar las actividades propias de los
procesos ITIL ® dentro de un marco de
gestión de Proyectos como Prince2 ®
por ejemplo de tal forma que manten-gamos
control sobre recursos y des-viaciones
a la hora de planificar nuevos
productos.
Por otro lado, desde un punto de vista
estratégico, podemos prestar atención
a la combinación de ambos marcos du-rante
el proceso de toma de decisiones
que afectan a la toma de decisiones so-bre
qué se queda en la empresa, que
modificamos y qué retiramos, es decir,
la gestión de cartera de servicios.
Este proceso de ITIL ®, se engloba den-tro
de la parte de Estrategia del Servicio
y nos describe las actividades y status
en los que los servicios pueden pasar
a lo largo de su ciclo de vida y qué ele-mentos
tendremos en cuenta para po-der
hacer cambios a la cartera.
En Prince2 ® esa parte de análisis de ne-gocio
sobre la viabilidad potencial de un
nuevo proyecto, se realizaría en la par-te
de “Pre-arranque de proyecto” (Star-ting
up a Project) y nos encontraríamos
en la situación temprana en la que aún
no está definido siquiera el equipo del
proyecto que gestionará el mismo. En
ITIL ® una vez se autoriza el paso de un
servicio en “Pipeline” a “Chartered”, es
entonces cuando se ha obtenido un
análisis positivo de esa viabilidad y por
tanto se puede armar el equipo y por
consiguiente el proyecto que gestionará
ese producto en concreto.
Bajo mi experiencia en el campo de
consultoría, es sumamente importante
que esté bien definido y esponsoriza-do
cuál es el alcance que (queremos/
podemos/necesitamos) en nuestro en-torno
y utilizar un marco de gestión de
proyecto que sea común en los equipos
y la organización en general.
Por mi parte recomiendo encarecida-mente
utilizar Prince2 ® ya que tiene un
carácter eminentemente pragmático al
ser (Prescriptivo), se dispone de forma
abierta de plantillas para trabajar desde
día 1 y es perfectamente asimilable con
ITIL ®.
No obstante es interesante la posibili-dad
de añadir elementos del marco de
conocimiento PMBOK u otros que pue-dan
aportarnos valor al identificar algún
área que Prince2 no cubra, o bien crear

32
nuestra propia metodología en la cor-poración
si ésta demuestra efectividad
para acometer los proyectos.

33
Agile Horrors
MIKE GRIFFITHS
Renowned project manager, trainer, consultant and writer, holding multiple project ma-nagement
and Agile related certifications. He is also a regular columnist and Agile con-tributor
at www.leadinganswers.com and Ganthead.com Gantthead.com, the world’s
leading online community for IT project managers.
Frankenstein Process
This is the methodology designed by
committee that tries to combine iterati-ve,
empowered development with linear
scheduling and command-and-control
task assignment. Perhaps created in an
attempt to satisfy the desires of com-peting
groups, but this half goose, half
salmon abomination neither flies nor
swims.
Agile practices are in a balanced ne-twork.
Ruthless testing balances the
need for comprehensive documenta-tion;
colocation, demos and daily stand
ups reduce the need for detailed status
reporting. Changes made to this web of
practices can easily create risks, gaps
and duplications if they are not carefully
considered.
Think candy apples not pumpkin pie;
hybrid methods work best when there
is a core of agile for the team to own
and execute, surrounded by a wrapper
of more traditional process to buffer
and integrate into a less agile aware en-vironment.
Don’t try and glom disparate
process pieces together, it becomes a
monster nobody loves or defends.
Zombie Projects
Some projects should just die but won’t
seem to. Doomed from the outset with
Agile Horrors

34
unrealistic deadlines, overly ambitious
scope, or ill equipped skills and su-pport;
everybody knows it will not end
well, but nobody seems willing or able
to kill it.
These death marches to eventual failu-re
or cancelation are damaging to the
people working on them who see the
futility and mismatch of progress to tar-gets.
However, like the emperor’s new
clothes there is a shared acceptance
that this is unlikely to work, but nobody
seems to speak out. Perhaps thinking
that the “higher ups” must know what
they are doing and would intervene if
there are problems; they continue shu-ffling
forward like an army of undead
looking for brains.
Unfortunately, there are no brains here
and the higher-ups rarely have some
cunning plan that turns struggling
forward progress into an elegant solu-tion.
More often if it looks, smells, and
behaves like an undead zombie, it is
one. Just like in the movies, it is best
not to start shouting and bring atten-tion
to yourself if you are surrounded by
zombies. Instead try to find an opportu-nity
to exit quietly, see if there is a reset
or restart initiative planned. Offer to be
part of the solution, instead of bitching
about the issues, usually others have
reached the same conclusion and are
looking for support to fix things.
Vampire Scrum Masters
and Project Managers
These people just suck the life out of
things and never give back. Scrum Mas-ters
who look for process compliance
but do not own or remove impediments;
or project managers who push for ve-locity
improvements, but don’t want to
hear about quality improvements or re-factoring
plans.
Agile teams generally work very hard
to deliver as many high quality featu-res
as they can. When they report pro-blems
or ask permission to undertake
maintenance work it is so they can be
better equipped to deliver high quality
features long into the future. Like igno-ring
a Check-Engine light in your car or
missing regular maintenance, you might
save some money in the short term but
it is a false economy longer term.
Scrum Masters and project managers
need to learn enough about their teams
and their technical domain to distin-guish
genuine reports of problems and
requests for investment from everyday
complaints and unnecessary requests

35
Agile Horrors
for resume boosting technology upgra-des.
Teams who routinely get their requests
ignored by leads that just want results
without investment will correctly draw
the conclusion that they are not valued.
When this occurs, the motivation to try
hard, delight customers and go the ex-tra
mile to overcome an obstacle is re-moved.
The delivery of results will decli-ne
and then the whole process sucks.
So, show some interest, ask people to
explain why issues and requests are im-portant.
If all the solutions are not pos-sible
ask them to prioritize. Try as hard
as you can to fulfill these requests and
usually the teams will reciprocate with
improved effort and results.
Product Owner Ghosts
These are business representatives that
are kind of there, but not really, they tend
to vanish or dissolve when pressed on
anything. Whether it is a tough decision
on a product feature, or their attendan-ce
at a demo; product owner ghosts are
unreliable.
The product owner / business represen-tative
role is integral to agile processes.
They are needed to ensure requirements
are understood, refined and prioritized,
along with providing prototype feedback
and resolving design decisions. Like mis-sing
or getting a poor developer or QA
person, a project with a “hardly there”
product owner will suffer tremendously.
So, look out for signs of less than real
product ownership. Warning signs of a
non-committed or weak business invol-vement
include:
C - Contrary – decisions flip-flop with no
clear explanation
A - Absent – you cannot find them or
get their time when needed
S - Switching – the person changes, no
dedicated product owner is assigned
P - Passive – without prompting we
would not hear from them for long pe-riods
E - Elusive – they will not provide clear
feedback on the suitability of a prototy-pe
R - Reclusive – they withdraw from prio-rity
discussions and decisions
Instead try to staff projects with product

36
owners who exhibit more solid, proactive
business representations.
C – Collaborative – willing to discuss
and evaluate alternative solutions
O – Owners – owning the backlog of
work, taking reasonability for its groo-ming
N – Nearby – available when required to
ask questions and get clarifications
C – Committed – having the same per-son
or people throughout the project
R – Representative – representing the
group we are building for, not personal
goals
E – Expert – knowledgeable about the
domain at hand to answer team ques-tions
T – Traceable – contactable when nee-ded
or with a proxy available if away
E – Experienced – experienced in the
field to warn of outliers and exceptions
(I prefer these attributes over Barry Boe-hm’s
CRACK mnemonic that does not
emphasize the Nearby, Experienced
and Expert qualities that can really save
teams time.)
Getting the best users is always difficult
since the best people are busy doing real
work. Try to explain the costs and risks of
building the wrong or a sub-optimal solu-tion.
Offer to back fill admin work from the
project for the best people even just to free
up some of their time each week for input
and feedback.

37
Agile Horrors
Summary
Hopefully this light hearted view of some
agile anti-patterns in the guise of Halloween
ghouls reminds us of things to be on the
lookout for. Unlike Halloween these pro-blems
are year round threats. More than
just something that goes bump in the night,
these problems are ever present in our li-ghts-
on projects. Look out for them and
use your garlic and silver bullet awareness
to keep them from impacting your projects.

Pilar Tarriño
Licenciada en Informática por la Universidad de Las Palmas de Gran Canaria. Tras va-rios
años de trabajo en empresas privadas, de ellos 5 programando para Sistemas de
Información Geográficos, doy el salto hace 6 años a la administración pública canaria.
Primero como analista en la Consejería de Ordenación Territorial y Medio Ambiente, y
actualmente en la Consejería de Educación, Universidades y Sostenibilidad. Engancha-da
a las metodologías ‘ágiles’ y a los ‘MOOCs’ y procurando no descolgarme del verti-ginoso
avance de la tecnología.
DEUDA TÉCNICA: Los cocodrilos salen de la alcantarilla
38
Una antigua leyenda urbana en el Nueva
York de los años 30 habla de pequeños
cocodrilos que fueron traídos como sou-venir
y luego lanzados por los desagües.
Allí crecieron y con el paso del tiempo se
convirtieron en grandes y sigilosas som-bras
de ojos brillantes que acechaban a los
empleados de mantenimiento. Es así como
pequeñas decisiones aparentemente poco
importantes se convierten en grandes pro-blemas.
En este modesto artículo pretendo hablar
de una problema común a todo proyecto,
la deuda técnica. Todo proyecto, sea del
tipo que sea, arrastra una deuda técnica,
desde el minuto uno se toman decisio-nes
que van a ir introduciendo en nuestra
mochila pequeñas o grandes piedras con
las que tendremos que acarrear hasta el
final del mismo. La cuestión es que no po-demos
evitar cargar con ella, pero sí que
debemos controlar su peso para que po-damos
seguir alcanzando los objetivos del
proyecto y no nos retrase, o en el peor de
los casos, nos paralice.
El término de Deuda Técnica es acuñado
por Ward Cunningham en 1992. Aunque
la definición propuesta por Ward Cunnin-gham
se refiere al desarrollo del software,
no es en absoluto el único campo en la
que se puede aplicar.
“Shipping first time code is like going
into debt. A little debt speeds develop-ment
so long as it is paid back prompt-ly
with a rewrite... The danger occurs
when the debt is not repaid. Every
minute spent on not-quite-right code
counts as interest on that debt. Entire
engineering organizations can be brou-ght
to a stand-still under the debt load
of an unconsolidated implementation,
object-oriented or otherwise.”
— Ward Cunningham, 1992

39
DEUDA TÉCNICA: Los cocodrilos salen de la
alcantarilla
En esta definición se realiza una similitud
con una deuda económica. Si para llevar
a cabo un proyecto un banco te concede
un préstamo, sabes que estás adquiriendo
una deuda que debes pagar en un tiempo
determinado y además con unos intereses.
¿Qué ocurriría con un proyecto en el que
la deuda no disminuye, o peor aún, va au-mentando
continuamente? Obviamente se
llega a un punto de quiebra ante la imposi-bilidad
de afrontarla.
La diferencia entre la deuda económica y la
técnica, es que en el primer caso normal-mente
es sencillo responder a las siguientes
preguntas:
• ¿Cuánto debo y con qué interés?
• ¿Cuánto debo pagar mensualmente?
• ¿Qué ocurre si me retraso en el pago?
• ¿Cuándo saldaré mi deuda?
Para la deuda técnica la cosa no es tan
clara, porque no es sencillo responder a
ninguna de esas preguntas. Si no sabes
cuánta deuda tienes, mucho menos podrás
reducirla ni controlarla.
Sin entrar en demasiada teoría, propongo
una aproximación a este problema en tres
fases clásicas: DETECTAR, CONTROLAR,
REDUCIR.
FASE 1: DETECTAR.
Para detectar nuestra deuda se pueden
hacer un montón de mediciones: tasa de
errores, tiempos de respuesta, análisis de
calidad, matrices de dependencias, esta-dísticas,
… pero … ¿y si empezamos por
preguntar? Creo que es lo más fácil y prác-tico.
El equipo del proyecto sabe si hay
deuda y sabe dónde está.
Así que nos sentamos en una mesa con el
equipo del proyecto y simplemente le pre-guntamos.
En esta primera fase no se pre-tende
un examen detallado y exhaustivo,
solamente captar el sentir de los que traba-jan
día a día y codo con codo.
Obviamente lo primero es establecer una
relación de confianza, no se buscan cul-pables
ni culpas. Se buscan los problemas
para proponer soluciones.
Las respuestas pueden ser:
a. “Eh … ¿Deuda técnica? … ¡No tenemos
ninguna deuda!”
b. “Bueno … tenemos un par de herramien-tas
no fundamentales algo obsoletas.”
c. “Buf … hay algunas partes fundamenta-les
que necesitan una evolución”

40
d. “Agh .. todo el proyecto depende de tec-nologías
no sólo obsoletas, antediluvianas!”
Si la respuesta es A ... vuelve a preguntar.
Todo proyecto siempre-siempre-siempre
tiene algo de deuda. Si el equipo responde
que no la hay significa que no es consciente
de la misma y, cuando no eres conscien-te
de algo no puedes evitarlo. Por lo tanto,
hay que preguntarse ¿trabajamos siempre
con la última tecnología del mercado? ¿no
cometemos nunca errores y siempre segui-mos
los máximos estándares de calidad?
¿estamos excelentemente formados?.
Recomiendo dividir nuestro proyecto en sus
partes o secciones fundamentales, pero ha-ciendo
un desglose a alto nivel. No convie-ne
inicialmente analizar elemento a elemen-to
sino el tener una visión global. Cuando
detectemos la zona más problemática ya
entraremos en una segunda fase al detalle
específico.
Dividido el proyecto en su partes principa-les,
podemos estimar su nivel de deuda uti-lizando
la técnica de planning poker. Todo el
equipo debe estar involucrado en esta es-timación.
No me voy a extender sobre esta
técnica dado que está profusamente docu-mentada,
pero el objetivo es que tras varias
iteraciones lleguemos a un valor en el rango
de:
1- Muy baja
2- Baja
3- Media
4- Alta
5- Muy Alta
El objetivo final de esta primera fase es dis-poner
de un mapa global de los puntos pro-blemáticos
de nuestro proyecto, ordenarlos
por su gravedad para así empezar a contro-lar
el problema.
FASE 2: CONTROLAR
Llegados a este punto es importante deter-minar
la/las causas por las que hemos lle-gado
al actual nivel de deuda. Detectar las
causas es fundamental para iniciar el control
del problema, no sirve de mucho tener un
equipo reparando agujeros mientras por otro
lado los seguimos generando.
Martin Fowler utiliza el siguiente cuadrante
para la clasificación de la deuda:
Si ordenamos este cuadrante de menos
mala a muy mala, tendremos que:

41
alcantarilla
• Prudente y Deliberado: El equipo es
consciente de que la decisión tomada va
a incurrir en aumentar la deuda técnica
del proyecto, pero la decisión es docu-mentada
y se planificará su corrección
en un futuro cercano.
• Prudente e Inadvertido: El equipo no
fue consciente de que la decisión to-mada
aumentaba la deuda técnica del
proyecto, pero se detecta el problema y
se planificará su corrección en un futuro
cercano.
• Imprudente y Deliberado: El equipo es
consciente de que la decisión tomada va
a incurrir en aumentar la deuda técnica
del proyecto, pero ya se corregirá ‘algún
día’.
• Imprudente e Inadvertida: El peor es-cenario,
el equipo aumenta continuamen-te
la deuda técnica sin ni siquiera darse
cuenta.
Algunas posibles razones para incurrir en
una deuda deliberada suelen ser:
• Presiones para la entrega en plazos
acordados.
• Relajación de la calidad con el objetivo
de aumentar la velocidad o disminuir los
costes.
• Trabajo a corto plazo, sin evaluar las im-plicaciones
futuras.
• Falta de liderazgo y control del proyecto.
En el caso de deuda inadvertida, pueden
ser:
• Falta de comunicación.
• Dispersión del conocimiento del proyecto.
• Falta de estándares de calidad o de se-guimiento
de los mismos.
• Deficiencias en la formación y en los co-nocimientos
necesarios para el proyecto.
• Equipos inestables con alta tasa de mo-vilidad.
• Falta de liderazgo y control del proyecto.
Es importante detectar las razones por la
que el proyecto incurre en deuda técnica y
establecer un plan para minimizar dichas
causas. Este plan debe desarrollarse en
paralelo con la reducción de la deuda ac-tual,
de forma que con el paso del tiempo la
deuda disminuya de forma efectiva.
El plan de control de la deuda técnica de-bería
atacar los siguientes aspectos:
• Liderazgo del proyecto
• Calidad
• Equipo de trabajo
• Conocimiento y Formación
Un artículo de Henrik Kniberg describe muy
gráficamente el objetivo de esta fase (http://
blog.crisp.se/2013/10/11/henrikkniberg/good-and-
bad-technical-debt). Debemos procurar

42
mantenernos en la línea verde, y estar muy
atentos a no cruzar la línea roja.
FASE 3: REDUCIR
En este punto toca atajar la deuda que ya
tenemos, de forma que la mantengamos
dentro de unos niveles aceptables. Como
ya comenté , la deuda cero es imposible de
alcanzar así que lo importante es mantener-la
bajo control.
Llega el momento de ‘pagar’ la deuda y
para ello el mejor enfoque desde mi modes-to
punto de vista es usar un enfoque ágil.
En anteriores artículos de esta revista y en
multitud de libros y páginas web se descri-ben
las técnicas ágiles de gestión de pro-yectos.
En resumen:
1. Establecer un ciclo de trabajo (sprint),
con una fecha de inicio y una de fin.
2. Determinar la velocidad de trabajo, es
decir, cuántas tareas podemos abordar
en cada ciclo.
3. Seleccionar de una lista de peticio-nes
que está ordenada por importan-cia
(Product Backlog) las tareas que se
abordarán en el ciclo de trabajo y se
ajustan a la velocidad definida (sprint
Backlog).
4. Completado el ciclo, revisión de los ob-jetivos
y vuelta a empezar.
Además de la lista de tareas o Product Bac-klog,
debemos también establecer una lista
de tareas enfocadas a la reducción de la
deuda, es lo que se denominaría ‘Technical
Debt Backlog’. Básicamente es un conjunto
de tareas ordenadas por su importancia y
valoradas en función de su coste de reali-zación.
En cada ciclo, se debería reservar un por-centaje
de la velocidad de trabajo para in-cluir
tareas de esta segunda lista. De esta
forma nos aseguramos un ‘pago’ continuo
y estable de la deuda a lo largo de los dife-rentes
ciclos de entrega.
Esta cuota no debe ser negociable con el
cliente por varias razones:
Si permites que el cliente decida cuántos
recursos se destinan a la deuda, es muy
probable que ese porcentaje tienda a cero.
Al fin y al cabo, es el propio cliente el que en

43
alcantarilla
la mayoría de los casos nos ha metido en el
problema.
Es importante hacer visible el coste de la
deuda y el coste de hacer las cosas mal.
De esta forma todos los implicados en el
proyecto visualizan más fácilmente las ra-zones
de la ralentización del proyecto. Y
no sólo eso, a medida que se controle la
deuda también se observa el aumento de
la velocidad.
Por lo tanto, suponiendo que en el ciclo de
trabajo nuestra velocidad es de 15 puntos y
hemos determinado una reserva de un 20%
para pagar la deuda, entonces podemos
abordar 12 puntos para peticiones y 3 para
pagar la deuda:
CONCLUSIONES:
¨Nunca hay tiempo para hacer las
cosas bien, pero si para hacerlas dos
veces¨
–Anónimo
“Calidad significa hacer lo correcto
cuando nadie está mirando”
–Henry Ford —
REFERENCIAS:
http://blog.crisp.se/2013/10/11/
henrikkniberg/good-and-bad-technical-debt
http://martinfowler.com/bliki/TechnicalDebt.
html
http://www.ontechnicaldebt.com
http://www.javiergarzas.com/2012/11/deuda-tecnica-
2.html
http://www.infoq.com/articles/managing-technical-
debt
http://technicaldebt.com/got-technical-debt

Mario Coquillat DE TRAVESEDO
Profesional experimentado en gestión de proyectos, certificado PMP® y PMI-RMP®.
Miembro del Comité CTN 157/ SC1 Project Management de Aenor que participó como
Comité Espejo en la nueva ISO 21500 “Directrices para la dirección y gestión de pro-yectos”
y participa actualmente en el TC-258 - project, programme and portfolio ma-nagement.
para la gestión de lecciones aprendidas
basada en la metodología de gestión de riesgos
44
Uno de los mayores retos en la actualidad
de las organizaciones que trabajan por
proyectos es la gestión del conocimien-to,
siendo las lecciones aprendidas ge-neradas
durante su ejecución, uno de sus
principales activos.
Si bien el proceso de lecciones aprendidas
es un concepto al alza, como muestra la
nueva norma ISO 21500 “Directrices para
la dirección y gestión de proyectos“, inclu-yendo
un nuevo proceso denominado “Re-copilar
las lecciones aprendidas”, es nece-sario
establecer metodologías, técnicas y
herramientas que permitan implantar con
éxito este proceso clave dentro de las orga-nizaciones
para mejorar el resultado de sus
proyectos.
Este artículo, fruto de mi experiencia en los
últimos años en este campo, donde empe-cé
realizando el análisis post mortem de
los proyectos, define una metodología para
una gestión eficiente y en tiempo real de las
lecciones aprendidas tanto a nivel de pro-yecto
como de programa o portafolio, ba-sándose
en las buenas prácticas del proce-so
de gestión de riesgos desarrollado por
PMI y recogidas en el Practice Standard
for Project Risk Management – First Edition.
Puntos débiles del proceso
y Factores Ambientales de la
Empresa que lo afectan
Cuando comienzas a implantar un proceso
de lecciones aprendidas dentro de una or-ganización
los principales riesgos a los que
te enfrentas y las posibles estrategias para
acometerlos son:
1. Falta de implicación de los miembros
del equipo de proyecto fundamental-mente
por una cultura de miedo a que
se hagan visibles los errores (especial-metodología

Creando una metodología para la gestión de
lecciones aprendidas basada en la metodología
45
de gestión de riesgos
mente en estos tiempos actuales de
crisis).
Recomendación: Esto se debe pa-liar
implantado una cultura de lecciones
aprendidas top-down desde la gerencia
siendo fundamental a nivel de proyecto
el apoyo del Director de Proyecto. Otro
aspecto a inculcar es que las lecciones
aprendidas (al igual que los riesgos) no
siempre son negativas sino que también
pueden ser positivas. Hay que reforzar
también esta visión positiva del proceso.
2. Falta de difusión y reutilización de
las lecciones aprendidas. Existe un
riesgo elevado de generar una base de
conocimiento que no se utilice con lo
cual no se habrá cumplido el fin último
para el que se diseñó el proceso.
Recomendación: Se debe diseñar un
proceso que asigne recursos y defina
técnicas y herramientas tanto para ase-gurar
la captación como para asegurar
la difusión y reutilización de las lecciones
aprendidas.
3. Falta de una métrica que nos permi-ta
medir el valor tangible que nos está
retornando este proceso. Hay que te-ner
en consideración que los proyectos
están focalizados en la ejecución y por
tanto cualquier gasto de recursos en ta-reas
que no se consideren necesarias
se tratará de minimizar.
Recomendación: Se debe establecer
una métrica para medir la eficiencia del
proceso de lecciones aprendidas en un
proyecto así como establecer objetivos
vinculados al mismo al inicio (a ser po-sible
en el acta de constitución del pro-yecto).
Asimismo se deben considerar los siguien-tes
Factores Ambientales de la Empresa
en la que se implanta el proceso de leccio-nes
aprendidas:
1. Estructura de la organización. De-pendiendo
si la organización es funcio-nal,
matricial u orientada a proyectos los
actores que intervendrán y la clasifica-ción
de las lecciones aprendidas po-drían
ser diferentes.
Si la estructura es funcional la clasifica-ción
de las lecciones aprendidas se po-drá
realizar en base a los departamentos
existentes al funcionar como “silos de
conocimiento” que fomentan la mejora
de los procesos y liderarán el proceso.
Por el contrario, si la estructura es orien-tada
a proyectos, la gestión del conoci-

46
miento es más complicada al poder ac-tuar
cada proyecto como una estructura
independiente y temporal y sólo pasará
el conocimiento de un proyecto a otro a
través de las personas que los compo-nen.
En dicho caso se deben crear “silos de
conocimiento virtuales” liderados por
Expertos en la Materia (del término inglés
Subject Matter Expert -SME) que actua-ran
como un nexo de unión entre los pro-yectos.
2. Sistemas de información para la di-rección
de proyectos. Si en la orga-nización
ya existen aplicaciones suele
existir la tendencia a “encajar” el proce-
Metodología gestión de riesgos Nueva metodología lecciones aprendidas
Riesgos negativos (amenazas) y riesgos
positivos (oportunidades)
Lecciones aprendidas positivas y negativas
Impacto y Probabilidad Impacto (I)
Plan de gestión de riesgos Plan de gestión de las lecciones aprendidas
Categorías de riesgos Categorías de lecciones aprendidas
Identificar riesgos (técnicas) Identificar lecciones aprendidas (técnicas)
Probabilidad - Matriz de probabilidad e
impacto (análisis cualitativo)
Niveles cualitativos de importancia basado en el
impacto
Análisis cuantitativo Análisis de la viabilidad de la acción (CI-CA)
Respuesta al Riesgo Acción a implementar
Monitorear y controlar los riesgos Seguimiento de las lecciones aprendidas
Gestor del riesgo Coordinador de la categoria
Responsable del riesgo Responsable de la acción
Gobernabilidad del proceso de gestión
de riesgos
Departamento o entidad liderando el proceso (se
recomienda la PMO)

47
so en las mismas lo cual puede restringir
las funcionalidades y perjudicar la nueva
metodología.
Se recomienda priorizar el proceso
sobre la herramienta por lo que en
una primera fase de implantación se
pueden utilizar plantillas con un sof-tware
de uso común como Microsoft
Excel ® y posteriormente cuando esté
madura y sea aceptada por la organi-zación,
se debe estudiar la opción de
desarrollar una aplicación corporativa
a medida.
En base a mi experiencia pasé por
ambas fases y la segunda supuso un
cambio cualitativo en la aceptación e
implantación del proceso, rentabili-zando
el coste de su desarrollo.
En cualquiera de los casos debe existir un
departamento o entidad (se recomienda que
sea por su posición estratégica la PMO) que
lidere de manera global el proceso, definien-do
el procedimiento que lo regule y asegu-rando
su cumplimiento por todas las partes.
Estas dos condiciones, junto con la madurez
en gestión de proyectos de la organización,
son los factores clave que contribuyen al éxi-to
del proceso (Post-Project Reviews to Gain
Effective Lessons Learned, Project Manage-ment
Institute 2007).
Nueva metodología de lecciones
aprendidas basada en la gestión
de riesgos
En el cuadro adjunto se puede ver la com-paración
entre la metodología de gestión de
riesgos según PMI y la nueva metodología
de lecciones aprendidas.
A continuación detallaremos esta nueva
metodología.
Ciclo de vida de una lección
aprendida
Toda lección aprendida de un proyecto
debe seguir el siguiente ciclo de vida:
Proceso de identificación (IDE): consiste
en la utilización de mecanismos para captar
lecciones aprendidas y así evitar su pérdida.
Proceso de clasificación (CLA): se deben
clasificar en categorías siguiendo un criterio
(áreas de conocimiento, procesos, etc..) que
permita su diferenciación y mayor facilidad
de acceso a la información.
Proceso de evaluación (EVA): se de-ben
evaluar con el objeto de establecer
su prioridad y analizar la viabilidad de
las acciones definidas para cada lección
aprendida.

48
Proceso de almacenamiento (ALM): las
lecciones aprendidas se almacenarán en
una base de datos que permita su búsqueda
rápida e intuitiva
Proceso de difusión (DIF): se define un
plan de comunicación para asegurar que las
acciones definidas para cada lección apren-dida
se difundan tanto al proyecto donde se
identifican como al resto de proyectos.
Proceso de seguimiento (SEG): se esta-blece
un sistema que asegura la implemen-tación
de las acciones definidas para cada
lección aprendida.
Proceso de identi ficación
Una vez asignada la persona que liderará el
proceso para cada una de las categorías (le
llamaremos coordinador) se debe iniciar la
captura de lecciones aprendidas.
Para ello se deben establecer dos tipos de
mecanismos:
• Identificación reactiva. Cualquier
miembro de un equipo de proyecto que
detecte una posible mejora o un error
en cualquier aspecto de un proyecto se
pondrá en contacto con el coordinador
pertinente (por ejemplo vía e-mail habili-tando
una opción para ello si se dispone
de una aplicación específica para el pro-ceso)
explicando de una manera informal
cuál es la situación y, en el caso de te-nerla,
su propuesta de solución.
Es importante en la fase inicial no solicitar
a los usuarios rellenar plantillas y asumir
esa responsabilidad por parte del coor-dinador
• Identificación proactiva. Los coordi-nadores
utilizarán para ello información
del proyecto (informes de avance, regis-tros
de incidentes, registros de riesgos,
etc..) pero la fuente principal será la rea-lización
de entrevistas al equipo de pro-yecto
en las visitas periódicas.
Si bien la periodicidad de las visitas se
debe ajustar en función del proyecto es
muy importante realizar presencialmente
estas visitas (especialmente si los pro-yectos
se encuentran deslocalizados en
diferentes ubicaciones y países) para es-tablecer
una comunicación fluida con el
proyecto y entre los proyectos, siendo el
coordinador el “medio de difusión” que la
garantice.
Como salida de este proceso se debe defi-nir
una ficha (ver ejemplo adjunto) para cada
lección aprendida en la que se rellenaran al
menos los siguientes campos:
1- Título

49
2- Descripción
3- Código (definido en el sistema de ges-tión
de la configuración)
4- Proyecto
5- Tipo de proyecto
6- País
7- Acción a implementar (versión prelimi-nar)
8- Palabras clave
9- Categoría/s a las que pertenece
proceso de clasificación
La lección aprendida se clasificará en base a
las categorías definidas en cada caso al igual
que se realiza con los riesgos.
Proceso de evaluación
Una vez identificada la lección aprendida se
debe establecer su prioridad al igual que su-cede
con los riesgos de un proyecto.
Para ello y como analogía de la metodología de
riesgos tendremos la variable Impacto (I), que es
la consecuencia o impacto de la lección apren-dida
en los objetivos del proyecto (por ejemplo
al coste o a su plazo de ejecución).
La otra variable utilizada para el análisis cuali-tativo
de riesgos, la probabilidad, no aplica en
principio en este caso al ser siempre 1 por tra-tarse
de hechos. Otro enfoque es considerar
la probabilidad (P) de recurrencia de la lección
aprendida optando por la fórmula P x I.
Para establecer el Impacto (I) se debe defi-nir
un criterio para cada uno de los objetivos
del proyecto, por ejemplo tres niveles (bajo
– medio –alto) asignándoles valores del 1
al 3 (ver ejemplo adjunto). El valor final será
por ejemplo el mayor de los obtenidos para
cada uno de los objetivos del proyecto.
Bajo (1) Medio (2) Alto (3)
No afecta o afecta
en menos de 1 se-mana
al plazo total
del proyecto.
Afecta en más de 1
semana y menos de
4 semanas al plazo
total del proyecto.
Afecta en más de
4 semanas al plazo
total del proyecto.
Al igual que en la matriz de riesgos defini-remos
tres niveles y tres colores que nos
facilitarán la identificación visual.
Nivel 1: Importancia alta
Nivel 2: Importancia media
Nivel 3: Importancia baja
Pero es aquí donde nuestra metodología
incluye un concepto adicional, que apor-tará
valor al proceso pues permitirá la uti-lización
de esta lección aprendida a nivel
de toda la organización: la transferencia
de una lección aprendida de un proyecto
a otro mediante el rol del coordinador y la
evaluación de la prioridad en el proyecto
destino.

50
Ahora bien, en aquellas lecciones apren-didas
que una vez realizado el análisis
cualitativo se han establecido como priori-tarias,
se debe realizar un análisis de via-bilidad
de la acción a implementar (análi-sis
cuantitativo).
Como hemos dicho anteriormente, nece-sitamos
que se aprecie el valor del pro-ceso
y esto implica que una vez definida
la acción a implementar, debemos anali-zar
si es viable, es decir, que el coste de
su implementación es menor que el coste
del impacto vinculado a la lección apren-dida.
Esto es:
CI: Coste asociado al impacto (en el caso
de que el impacto sea en plazo se cuan-tificará
por ejemplo el coste de la penali-zación
contractual por retraso en el pro-yecto)
CA: Coste asociado a la acción a imple-mentar
La acción será viable siempre que
CI – CA > 0
Al finalizar este proceso obtendremos un
registro de lecciones aprendidas donde
adicionalmente a los campos obtenidos
en el proceso de identificación se rellena-rán
los siguientes campos:
1- Impacto (I)
2- Coste asociado al impacto (CI)
3- Coste asociado a la acción a imple-mentar
(CA)
4- Análisis de viabilidad (CI-CA)
Proceso de almacenamiento
Las lecciones aprendidas identificadas tan-to
en el proyecto origen como las transferi-das
a los proyectos destino se almacenarán
en la aplicación o plantillas que utilicemos
para poder gestionarlas y para utilizarla
como información histórica a futuro.
Procesos de difusión y
seguimiento
Hasta este momento hemos generado una
base de datos y aquí es donde muere este
proceso en muchas organizaciones.
¿Cómo vamos a difundir las lecciones
aprendidas y asegurar la implantación de
las acciones en los proyectos?
Un primer paso, como hemos hablado, es dis-poner
de un coordinador para cada una de las
categorías, pero esto no será suficiente. Aquí
nuevamente nos asomamos a la metodología
de riesgos para recoger buenas prácticas.
A cada acción a implementar cuyo análisis
de viabilidad sea positivo, se le asignará
dentro del equipo de proyecto un respon-

51
sable de su implementación (responsa-ble
de la acción), así como se controlará
tanto la fecha en la que se ha difundido al
proyecto como la fecha estimada de su im-plementación.
Y a partir de aquí se deben establecer dife-rentes
niveles de seguimiento.
Para el seguimiento periódico del estado de
la implementación de las acciones, asigna-ción
de nuevos responsables, identificación
de nuevas lecciones aprendidas será el
coordinador quien establezca el calendario
con el proyecto acorde a sus necesidades.
Con el objetivo de poner en común leccio-nes
aprendidas de las diferentes categorías,
realizar análisis de viabilidad y tratar temas
relativos al procedimiento que regula el pro-ceso,
se recomiendan reuniones periódicas
de los coordinadores con el departamen-to
que lo regula (en general según dijimos
debe ser la PMO)
Por último la PMO (o quien se asigne) se
reunirá con la gerencia para tratar aquellas
lecciones aprendidas nivel 1 (y quizás ni-vel
2) cuyo análisis de viabilidad es positivo
pero que la dirección de proyecto (normal-mente
por razones de plazo o por falta de
credibilidad en el análisis de viabilidad) se
resiste a implantar.
Esta planificación del proceso se debe in-cluir
en el plan para la dirección del proyec-to
o si se considera preciso en un plan de
gestión de las lecciones aprendidas.
Asimismo, es conveniente generar infor-mes
del proceso, a ser posible, por una
cuestión de eficiencia, a través de la herra-mienta.
Esta información será diferente en
función del rol y de la visión del proceso. Así
tendremos entre otros:
• Informes a nivel de proyecto para
poder hacer seguimiento de las leccio-nes
aprendidas con dos niveles de infor-mación
(incluyendo los análisis de viabili-dad
al director de proyecto y sin incluirlo
para el equipo de proyecto al ser infor-mación
sensible).
• Informes a nivel de categoría para
uso del coordinador para hacer segui-miento
de todas sus lecciones aprendi-das,
incluyendo para una misma lección
aprendida, su estado en todos los pro-yectos
donde se está implementando la
acción (proyecto origen y proyectos des-tino).
Retorno del proceso de
lecciones aprendidas
En base a mi experiencia en la PMO implan-tando
nuevos procesos en la organización,
para garantizar su éxito y sostenibilidad en el

Revista Proiectus nº 3

Recomendados

Recomendados

Más contenido relacionado

Similar a Revista Proiectus nº 3

Similar a Revista Proiectus nº 3 (20)

Más de Pablo Aguilera

Más de Pablo Aguilera (20)

Último

Último (20)

Revista Proiectus nº 3