REVISTA PROIECTUS Nº 3 by PROIECTUS

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

CARTA DEL DIRECTOR Bienvenid@s a este tercer número de la revista PROIECTUS, publicación MADE IN CANARIAS desarrollada por y para profesionales vinculados a la Dirección de Proyectos. Confeccionar una publicación gratuita como esta supone un gran esfuerzo para todos los que participamos de forma voluntaria en su elaboració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.

Director revista PROIECTUS Iván S. Tejera Santana

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

ÍNDICE

www.proiectus.es

5 13

Número 3, Noviembre 2014

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

61 65

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

Gestionando la distancia para el éxito de los proyectos

www.proiectus.es

Número 3, Noviembre 2014

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 digitalización con enfoque analítico en todos los ámbitos de la empresa desde la transformació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 Siempre he defendido que la gestión de proyectos tiene tanto de ciencia como de arte. Es ciencia porque existen metodologías y mejores prácticas ampliamente reconocidas y en constante evolución (dentro de las cuales la Guía del PMBOK® es referente). Es arte por las habilidades necesarias para llegar a ser buen jefe de proyecto: un líder capaz de inspirar y gestionar con eficacia las situaciones y las personas.

me llevo multitud de lecciones que me gustaría compartir con los lectores de Proiectus.

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

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 asumir nuevos retos es indispensable para seguir progresando.

Cuando el cliente entró en contacto conmigo 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 contratado 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

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 5

www.proiectus.es

Número 3, Noviembre 2014

interfaz gráfica e imagen corporativa, así como determinados cambios en el flujo de trabajo.

rentemente nimios escaparon al análisis previo y causaron toda clase de problemas. Algunos se asumieron, otros se renegociaron como cambios de alcance y otros tuvieron que ser desestimados por inviables.

Sin embargo, la situación estaba lejos de estar controlada: dos meses tras el kickoff, a dos meses de la finalización, apenas había avances. El alcance se había disparado, no tenían capacidad para seguir atendiendo 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.

Otra vertiente de este error es asumir dependencias con terceros sin auditar previamente 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 había cesado de ofrecer soporte porque llevaban meses trabajando en una nueva versión de la API. Más retrasos, más cambios, más frustración para el equipo.

Básicos de gestión de proyectos De todos los aprendizajes del proyecto, muchos son comunes a cualquier desarrollo de software y nada tienen que ver con que sea internacional. Nunca está de más recordarlos.

Optimizar la cadena de mando sin dejar de controlar el alcance

No escatimar tiempo en el análisis inicial y en la definición de los requerimientos

Los stakeholders en cada proyecto son los que son, pero unos protocolos claros pueden obrar milagros. ¿Qué se escala, cuándo y a quién? Sin herir sensibilidades, pero con firmeza, si alguien no es necesario en un comité de seguimiento que no acuda.

Hay mucha sabiduría en el dicho “cada hora que se dedica a planificar ahorra diez horas en la ejecución”. Un requerimiento aparentemente sencillo puede causar estragos en el proyecto, especialmente si tiene impacto en código o modelos de datos que llevan años escritos.

Sin embargo, esta agilidad es un arma de doble filo, es necesario mantener involucrado al project owner y al sponsor,

En nuestro caso unos cuantos detalles apa6

Gestionando la distancia para el éxito de los proyectos

www.proiectus.es

Número 3, Noviembre 2014

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ápida 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 validarse en firme.

to exponencial de las necesidades de gestión. Además, resulta vital dejar claro de inicio cuál es tu capacidad para satisfacer sus necesidades, que sean conscientes de hasta qué punto puedes o no cumplir con sus procesos en materia de entornos, despliegues, informes, auditorías, control de accesos, seguridad, etc. Esto fue especialmente frustrante en el proyecto, porque una respuesta que uno nunca quiere dar (y que el cliente final difícilmente 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”.

Nunca infravalorar el trabajo del jefe de proyectos Un proyecto necesita un líder y responsable, 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 delegar dichas labores en el equipo de trabajo, lo cual no solo no funciona (lo cual implica retrasos, sobrecostes, etc.), sino que somete al equipo a un esfuerzo para el que no están formados ni tienen experiencia, derivando en frustración y malestar.

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

Conocer al cliente y sus circunstancias Las empresas grandes suelen ser más formales que las pequeñas, y en España hasta 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-

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 re7

www.proiectus.es

Número 3, Noviembre 2014

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 problemas de rendimiento no se hicieron patentes de inicio en los equipos de desarrollo y prueba (ordenadores portátiles y tablets modernos), sino cuando el equipo de la India 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.

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 proyecto: • E n Estados Unidos (UTC-4) el cliente final. • E n España (UTC+2) el desarrollador (mi cliente). • E n Inglaterra (UTC+1) el equipo de soporte funcional.

El factor distancia

• E n la India (UTC+5½) el equipo de pruebas.

Llegamos al punto álgido: ¿qué proble-

Fuente: WikimediaCommons Autor: TimeZonesBoy

Gestionando la distancia para el éxito de los proyectos

www.proiectus.es

Número 3, Noviembre 2014

Se trata de doce mil kilómetros de distancia, más de nueve horas de diferencia horaria, una fuente de quebraderos de cabeza en la que la primera obviedad es resolver como celebrar las reuniones.

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

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 escrupulosamente gestionado: el orden del día se emitía con 24 horas de antelación, y el acta se publicaba 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 alcanzaba la media hora planificada).

• Los respectivos calendarios laborables. 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 mentalízate a la cantidad de nomenclaturas y excepciones existentes, incluso dentro de un mismo país. • Los cambios de hora, que cada país hace a su manera. Por ejemplo, el cambio a horario de invierno es el último domingo de octubre en España, el primer domingo de noviembre en EEUU y nunca en la India (allí no se realiza cambio a horario de verano). A nosotros nos arruinó varias conferencias en la semana del cambio de hora, tenlo en cuenta.

La diferencia horaria daba poco lugar a la flexibilidad: las reuniones técnicas empezaban 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 apurando su hora de salida (19:30).

Gritando a los que están más lejos

Esto es manejable si todos los participantes utilizan sistemas de calendario compatibles como Outlook o Google Calendar… Si no (lo más frecuente) estás obligado a tener en cuenta (y aclarar a todos los im-

La distancia debilita los corazones, y se lo pone complicado al jefe de proyectos. No quiero decir que la distancia sea causa directa de problemas, pero va a introducir sí o 9

www.proiectus.es

Número 3, Noviembre 2014

sí una serie de factores problemáticos que conviene considerar (y si se puede, compensar):

Explorer 6 es el navegador oficial del cliente final (algo con lo que no contábamos nosotros, y al parecer tampoco desde EEUU). Un mazazo para todos.

• El idioma es un problema. Si con frecuencia es complicado entenderse en el idioma materno de uno, hacerlo de forma eficaz y eficiente con ingleses, norteamericanos e indios requiere el doble de paciencia y esfuerzo. Las barreras culturales 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.

• Los formatos de fechas y horas causarán bugs. Es ley de vida, parece algo superado pero hasta Apple tiene errores en el calendario de iOS. Búscalos 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 espacios).

• Las comunicaciones son una barrera. Email, videoconferencia, teléfono, VoIP, chat… nada sustituye una reunión presencial. A veces son verdaderamente necesarias, pero no son posibles.

La dedicación y la productividad Uno de los aprendizajes clave que me llevo es la capacidad de dimensionar el esfuerzo 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.

• Internet es rápida, pero el mundo enorme. Tus usuarios en Colombia, China y la India no van a estar satisfechos con el nivel de servicio que presta tu servidor en Alemania, por potente que sea. Abraza la nube, diversifica tus servidores y acércalos a los usuarios.

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 proyecto y entrar en pánico. O un día en que

• El factor China. El sistema operativo más utilizado en el gigante oriental es Windows XP. Es más, allí Internet 10

Gestionando la distancia para el éxito de los proyectos

www.proiectus.es

Número 3, Noviembre 2014

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

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.

En otras palabras, un proyecto internacional que abarca medio planeta requiere atención 12 horas al día. ¿A tiempo completo? No necesariamente (depende 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 multitarea impacta en la productividad y en la capacidad para afrontar otros proyectos. Pero es imprescindible si no se desea penalizar el proyecto completo, un retraso de media hora en la gestión un asunto puede retrasar varios días su solución.

Por supuesto, todo esto se complica si te incorporas a un proyecto ya comenzado en el que los requerimientos funcionales 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 procesos!), etc. ¿Y el factor internacional? Exigirá del don de la ubicuidad: estar en todo, a todas horas, para mantener los engranajes 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 investigación, no dar por hecho que en otros países las personas y las tecnologías son como en casa.

Conclusiones La distancia es una de los mayores obstáculos que se pueden interponer entre un gestor y su proyecto. La distancia impacta de lleno en su principal activo: el flujo de información y su capacidad de interpretarla libremente. Miles de kilómetros

Para cerrar, compartiré una cifra representativa: el esfuerzo final del proyecto 11

www.proiectus.es

Número 3, Noviembre 2014

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

El proyecto CMMI, un proyecto de mejora organizacional

www.proiectus.es

Número 3, Noviembre 2014

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.

El proyecto CMMI, un proyecto de mejora organizacional Generalmente un proyecto es entendido 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, infraestructura 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 gestionarse de igual forma. Aquí se presentan consideraciones generales para gestionar los recursos humanos y las primeras actividades para arrancar un proyecto de mejora en la organización.

de se incorporan las prácticas definidas en el modelo CMMI. Dependiendo del alcance y necesidades de la organización se requerirán determinadas consideraciones 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 refleja 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.

Típicamente se habla del proyecto CMMI para identificar el proyecto de cambio en la organización a nivel de procesos don13

www.proiectus.es

Número 3, Noviembre 2014

¿Qué es CMMI?

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 material informativo en las áreas de proceso. En general el documento se puede revisar en función de metas, prácticas y subprácticas con el resto del material informativo.

CMMI1 es el acrónimo de Capability Maturity Model Integration y se refiere a los modelos que contienen las mejores prácticas que ayudan a las organizaciones a mejorar sus procesos. Han sido desarrollados por equipos de trabajo formados por especialistas de la industria, el gobierno y el Software Engineering Institute (SEI) que transfirió los derechos al CMMI Institute para su operación y comercialización.

Existen tres constelaciones o modelos que se complementan con elementos comunes a nivel de áreas de proceso. Según el modelo que se utilice se puede obtener el documento con las guías que ayudan en:

Contiene elementos esenciales de un proceso efectivo y propone una forma de adopción para la organización que permite incrementar la calidad y productividad, al tiempo que controla el presupuesto y los compromisos establecidos. Cada una debe interpretar, adoptar y aplicar aquellas prácticas que le apoyan en el logro de sus objetivos y cumplimiento de sus necesidades de manera eficiente.

• 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 capacidad de acuerdo con la representación continua. El otro enfoque considera un conjunto preestablecido de áreas de proceso

El enfoque del modelo permite evolucionar desde un proceso en crisis a un proceso controlado, estandarizado, medido y optimizado que sienta las bases de la mejora continua y permite a la organización adoptar nuevas prácticas sobre un proceso estable que está institucionalizado o entendido y asimilado. 14

El proyecto CMMI, un proyecto de mejora organizacional

www.proiectus.es

Número 3, Noviembre 2014

que constituyen un nivel de madurez y que es la forma de evaluar la representación escalonada o por etapas.

Es importante definir objetivos, planear indicadores 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 objetivos hay que establecer acciones como parte del plan de mejora, el cual es integrado en las actividades de la organización.

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 estado 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 barreras. Al final, se requiere que los cambios formen parte de la forma de operación en la Organización de manera permanente. Un proceso mejor debe traducirse en más ganancia y una mejor operación.

El proyecto de mejora debe ejecutarse con la misma persistencia que la operació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 procesos, confianza del cliente por los altos niveles de capacidad, ventajas competitivas para el negocio y empleados comprometidos con la mejora continua.

Los procesos son valiosos cuando describen 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 mejora comunicadas, entendidas, acordadas y respaldadas que permitan el desarrollo, publicación y mantenimiento continuo.

Ruta hacia la mejora Siempre que iniciamos un proyecto, actividad o cualquier cosa que estemos intentando comenzar, la primera pregunta que nos asalta es ¿por dónde empiezo? Definitivamente para iniciar un proyecto de 15

www.proiectus.es

Número 3, Noviembre 2014

mejora, necesitamos saber cómo están las prácticas de la organización y a dónde queremos llegar, para establecer acciones y saber cómo lo vamos a solucionar.

a los elementos mencionados como todo proyecto requiere evaluar un presupuesto, establecer un cronograma, identificar riesgos, establecer e implementar mecanismos de comunicación, gestionar los recursos y controlar la ejecución del proyecto.

Es imprescindible tener una necesidad real de cambio, identificar que algo no está funcionando o no puede continuar como está para lograr un motivador concreto y objetivo. Lo recomendable es iniciar 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 realmente es necesario para la organización.

En el modelo CMMI el área de proceso de OPF i establece las prácticas requeridas para ejecutar un proyecto de mejora, es conveniente 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.

También es importante saber a dónde queremos llegar, cuales son las metas, motivadores y el nivel de compromiso de la dirección de la organización con este esfuerzo. Es una inversión de recursos en todo sentido 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 beneficios se están logrando. Adicionalmente i

La parte más “fácil” de todo el proyecto es entender cómo solucionarlo y aplicar el modelo como parte de la solución, el problema 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 necesidad del cambio, determinar que se requiere

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

El proyecto CMMI, un proyecto de mejora organizacional

www.proiectus.es

Número 3, Noviembre 2014

cambiar y los objetivos a alcanzar, garantizar el compromiso para lograr los cambios, involucrar al personal en las actividades del

proyecto y evaluar la forma en que se alcanzan 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 probado 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 presupone 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

www.proiectus.es

Número 3, Noviembre 2014

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- 2- 3- 4- 5- 6- 7-

Iniciar la fase Identificar las necesidades del negocio y los motivadores para la mejora Elaborar la propuesta de mejora de procesos Apoyo en formación y desarrollo Obtener la aprobación de la propuesta inicial de mejora y de los recursos para el proyecto Establecer la infraestructura para el proyecto de mejora 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 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 resultados 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 responsable de proyecto puede gestionarlo pero requiere que la Dirección esté al frente defendiendo y abogando 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

El proyecto CMMI, un proyecto de mejora organizacional

www.proiectus.es

Número 3, Noviembre 2014

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-fordevelopment-version-1-3/

Mullaly, Mark:”Managing Process Improvement”,

projectManagement.com, March 2013. http://www.projectmanagement.com/ articles/277644/Managing-ProcessImprovement

McFeeley, Robert. “IDEAL: A User’s Guide for

Software Process Improvement” (CMU/SEI-96HB-001) Pittsburgh, PA. Software Engineering Institute, Carnegie Mellon University, February 1996.

http://resources.sei.cmu.edu/asset_files/ Handbook/1996_002_001_16433.pdf

www.proiectus.es

Número 3, Noviembre 2014

ANTONIO PEDRO DORTA ALONSO Ingeniero informático certificado Project Management Professional (PMP)®, Máster en Administración de Empresas (MBA) y otra formación de posgrado. Más de 7 años de experiencia como consultor en proyectos de innovación tecnológica (ERP, CRM, EDI, E-Commerce).

Dirigiendo proyectos para implantar un ERP ¿Cómo implantar adecuadamente un sistema de gestión en una empresa? ¿Cómo asegurarse 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 empresa 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 preguntas que frecuentemente se realizan gerentes y directores de IT de muchas organizaciones.

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 podría extrapolarse a cualquier otro tipo de herramienta de gestión), y analizaremos en qué medida la dirección de proyectos 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 sistema 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 hablamos 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!

Ya se trate de implantar un sistema ERP 2 o sustituir el existente, o hablemos de implantar 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 empresa, no siempre exenta de polémica, tensión y conflictos. 20

Dirigiendo proyectos para implantar un ERP

www.proiectus.es

Número 3, Noviembre 2014

Nos encontramos, por tanto, ante un cambio organizativo. Un engranaje que ha ido puliéndose a lo largo de los años, instaurado 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 inteligentes) que se ve sometido a numerosos cambios en forma e incluso en trasfondo.

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 necesidades no previstas o aparecen nuevas acciones a realizar a medida que los consultores de negocio conocen con mayor profundidad cómo trabajan los usuarios. En este contexto de descubrimiento por avance, un adecuado control de cambios puede suponer la diferencia entre el éxito y el fracaso de la implantación.

En tal sentido, la gestión de la integració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 personas tengan la capacidad de ver todo el mapa en su conjunto, entendiendo que una modificación en un determinado aspecto (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 contabilización de dichas ventas).

Dos equipos de trabajo, ¿un objetivo común? Cada empresa podría considerarse un sistema 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 forma de trabajar, de gestionar los datos que la componen y de actuar frente a las necesidades del mercado.

Muchos miembros del equipo de proyecto, consultores de negocio y técnicos, tienden a centrarse en su ámbito de especialidad, ignorando el resto de ámbitos. Sin embargo, el director del proyecto debe mantener en todo momento esa visión holística para alinear necesidades con acciones y para mantener coherente el plan del proyecto con los resultados requeridos.

En este sentido, el conocimiento del equipo de implantación procedente de proyectos anteriores es importante, pero en raras ocasiones resulta suficiente. Las estimaciones por analogía para valorar cuánto esfuerzo requiere una tarea serán aproximadas, puesto que no se conoce a priori todo el detalle de los procesos de negocio, ni se conoce bien a los usuarios que los 21

www.proiectus.es

Número 3, Noviembre 2014

La mayor parte del conocimiento es tácito

ejecutan. Por ello, suponer que dos empresas 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 estilo que nos identifica como seres humanos únicos marca pautas en cómo hacemos las cosas. En este caso, la diversidad juega en nuestra contra.

Por si fuera poco, además, es importante tener en consideración que gran parte de todo el conocimiento necesario en el proyecto pertenece a la categoría de conocimiento tácito, difícil de establecer en procedimientos y, por extensión, complejo de documentar y sistematizar. De la misma manera que un consultor especializado con muchos años de experiencia posee un bagaje que le permite 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 construye las decisiones de ambos profesionales se ha conformado con numerosas iteraciones de los procesos y de mucha reflexión no verbalizada. Hay responsables de compra que realizan aprovisionamiento 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 contable simplemente analizando la comunicación no verbal del director financiero cuando se sienta con él.

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 implantación con éxito, pero que no se conocen entre sí, poseen un perfil y experiencia diferentes y, bajando a nivel de detalle, tienen objetivos a corto plazo distintos (unos estarán preocupados por una implantación rápida y sin incidencias, y los otros estarán preocupados en que el cambio tenga un mínimo impacto en su forma de trabajo actual). 22

Dirigiendo proyectos para implantar un ERP

www.proiectus.es

Número 3, Noviembre 2014

gestión en una empresa es, eminentemente, 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 conocimiento detallado de los procesos de negocio por parte de los consultores hace que el proyecto parta de un mayor o menor grado de incertidumbre, que deberá ser atajada a medida que se avanza en el calendario.

El juicio de expertos es una técnica valiosa en la implantació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á fundamental para algunos procesos, como la estimación de la duración de las actividades, la validación de alcance o la identificación de los riesgos del proyecto. No es infrecuente que el director de un proyecto de implantación de un ERP esté constantemente aplicando esta técnica para recabar criterios y para realizar una adecuada toma de decisiones.

Como norma general, en la fase previa a la de ejecución del proyecto, el equipo de trabajo que realiza la implantación suele realizar un análisis más o menos extenso de las posibles necesidades y requerimientos de los procesos de negocio, con el fin de evaluar la viabilidad del proyecto (y de establecer las condiciones económicas iniciales, si quien realiza los servicios de implantación es una empresa externa). Pero este conocimiento de partida rara vez cubre toda la casuística posible del día a día de la organización que implanta la nueva herramienta de gestión.

El problema del alcance en los ERP

Para tratar de solventar este problema, es frecuente dividir el proyecto en fases, siendo habitual que la primera de ellas se

Como se ha mencionado anteriormente, la implantación de una nueva herramienta de 23

www.proiectus.es

Número 3, Noviembre 2014

centre en el análisis de procesos de negocio y de requerimientos. De esta forma, se estructuran diferentes sesiones de trabajo entre consultores y usuarios, con el objetivo de adquirir un mejor entendimiento de lo que conllevará el proyecto a nivel de detalle.

fecha prevista de finalización del proyecto.

Posteriormente, tras una validación inicial del alcance, se re-planifica el trabajo restante 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 tanto 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 demostración y prueba.

Esto supone un problema importante desde el punto de vista de dirección de proyectos. 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á compuesto. 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.

Desafortunadamente, en el momento de presentar un prototipo es frecuente que aparezcan nuevos requerimientos (obviados 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 entendimiento) o se descubra nuevas necesidades 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

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

Dirigiendo proyectos para implantar un ERP

www.proiectus.es

Número 3, Noviembre 2014

ción (malas interpretaciones, suposiciones, falta de información) establecen el prefacio de la crónica de un fracaso anunciado.

Por ello, es muy frecuente realizar planificación gradual, refinando a nivel de detalle únicamente las acciones a corto plazo, 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.

El calendario es un aspecto crítico A diferencia de muchos otros proyectos, la implantación de un sistema ERP suele tener una mayor sensibilidad al calendario que otro tipo de herramientas informáticas, debido 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 comienzo de año para el cambio de sistema informático como un requisito indispensable para abordar el proyecto.

Algunas técnicas, como el análisis Montecarlo o el método de la cadena crítica, 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

Debido a las altas dosis de incertidumbre inicial, a que el conocimiento tácito de las personas establece muchas veces el criterio para actuar y a que el alcance demanda altas dosis de flexibilidad, resulta especialmente difícil la gestión del calendario de este tipo de proyectos.

Es frecuente oír en muchos ámbitos, especialmente en la publicidad y acciones de marketing de las empresas de servicios, que ‘las personas son lo más importante’. A pesar de que pueda ser un tópico en muchos casos, en los proyectos de implantación de sistemas ERP es un paradigma clave para alcanzar el éxito.

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 largo del tiempo hasta ocupar la totalidad del tiempo disponible) o la Teoría de las Limitaciones de Goldratt 7.

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 25

www.proiectus.es

Número 3, Noviembre 2014

La interacción con el equipo de trabajo y con los usuarios es clave para el éxito Imagen con licencia Creative Commons Autor: Woodley Wonderworks

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 relevancia muy superior al aspecto técnico informático. Y es que, ante todo, somos personas colaborando mutuamente para alcanzar nuestros objetivos.

coordinación que implanta el mejor ERP del mercado. Por otro lado, la correcta gestión de stakeholders o interesados también es crítica de cara a conseguir la mayor cooperación posible de todas las personas implicadas, ante lo que influye enormemente la gestión de las comunicaciones en el proyecto. Los problemas derivados de malas interpretaciones, 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 facilitar que todas las personas tengan el conocimiento necesario para tener una visión adecuada del éxito. Y es que gran parte de la jornada de un director de proyectos, especialmente en la implantación de un ERP,

En muchas ocasiones, un buen equipo de consultores, debidamente cohesionado a través de un adecuado liderazgo situacional y de técnicas de teambuilding, correctamente equilibrado en sus conocimientos técnicos y compensado convenientemente aplicando la teoría de Roles de Belbin 8, puede proporcionar mejores resultados implantando un ERP limitado que un equipo sin talento ni 26

Dirigiendo proyectos para implantar un ERP

www.proiectus.es

Número 3, Noviembre 2014

la emplea en comunicarse y asegurarse de que todas las piezas estén alineadas.

sados y comunicaciones pueden ser las áreas de conocimiento más relevantes en este tipo de proyectos.

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 organización, en la que la cultura corporativa, la presencia (o ausencia) de talento y la gestión del cambio son aspectos tan importantes como la funcionalidad del software a implantar.

Por supuesto, PMBOK no es la única alternativa viable para conseguir resultados similares. 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 necesidades de cada caso en particular. ¿Pero cuándo no?

REFERENCIAS 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 durante todo el desarrollo y saber dar respuesta a los inconvenientes que aparezcan a lo largo del camino. Dicho de otra forma, para implantar con éxito un ERP se requiere una gestión eficaz de proyectos.

Michael Eugene Porter (1947, -): profesor de Har-

vard Business School y experto reconocido a nivel mundial en estrategia corporativa. Es autor de numerosos libros y artículos sobre estrategia y competitividad. 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

En este sentido, la aplicación de buenas prácticas en dirección de proyectos, tales como las recogidas en el PMBOK, pueden 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-

SCM – Supply Chain Management: sistema orga-

nizativo para administrar el flujo de materiales desde 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.

www.proiectus.es

Número 3, Noviembre 2014

CRM – Customer Relationship Management: en-

foque de marketing para establecer todas las acciones 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 organizacionales. 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.

ITIL ® y la Gestión de Proyectos

www.proiectus.es

Número 3, Noviembre 2014

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 diferentes á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 continente Europeo, empresa acreditada por Peoplecert.

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.

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 marco de gestión de proyectos adecuado al uso de esta buena práctica. Dentro del ámbito Táctico-Operativo, tomemos por ejemplo 2 procesos dentro del Diseño del Servicio, así como Transición del Servicio., Serían respectivamente:

Ni la versión 3 ni la actualización 2011 quisieron ir más allá del hecho de hacer referencia a la gestión de proyectos como algo necesario pero externo/ajeno al alcance.

• Diseño del Servicio à Coordinación del Diseño • Transición del Servicio à Soporte y planificación de la transición.

Es acabar una formación y muchos asistentes preguntan, “”tenemos la teoría clara, pero esto cómo se implementa, adopta”” ¿?, tendremos que coordinar diferentes departamentos, fases etc, necesitaremos gestionar por proyectos ¿?

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 alcance la responsabilidad de gestionar to29

www.proiectus.es

Número 3, Noviembre 2014

dos los procesos involucrados dentro del Diseño del Servicio, tanto a nivel de seguridad, 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.

se encargaría de tomar el relevo a Diseño del Servicio, el cual facilitaría como resultado de su proyecto el paquete de diseño del servicio. Durante la fase de transición, este proceso es el encargado de gestionar los recursos y capacidades para poder

Es por ello que se requiere la definición y ejecución de un proyecto que identifique las partes involucradas, analice los riesgos, autorice fases etc. etc... Durante mi época trabajando como gestor 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 desplegar, facilitando una transición minimizando en lo posible el impacto al entorno productivo.

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 productos finalmente montados, evaluar desviaciones y sus pertinentes justificaciones cara a la gestión financiera y del tiempo disponible, en definitiva, gestionar el proyecto, apoyándonos en los procesos de ITIL® para ejecutar las actividades, teniendo en mente que es un marco descriptivo.

Referente al otro proceso mencionado (“Soporte y planificación de la transición”), 30

ITIL ® y la Gestión de Proyectos

www.proiectus.es

Número 3, Noviembre 2014

Sirvan de ejemplo estos dos procesos a modo de ejemplo para poder evidenciar 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 mantengamos control sobre recursos y desviaciones a la hora de planificar nuevos productos.

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.

Por otro lado, desde un punto de vista estratégico, podemos prestar atención a la combinación de ambos marcos durante el proceso de toma de decisiones que afectan a la toma de decisiones sobre qué se queda en la empresa, que modificamos y qué retiramos, es decir, la gestión de cartera de servicios.

Bajo mi experiencia en el campo de consultoría, es sumamente importante que esté bien definido y esponsorizado cuál es el alcance que (queremos/ podemos/necesitamos) en nuestro entorno y utilizar un marco de gestión de proyecto que sea común en los equipos y la organización en general.

Este proceso de ITIL ®, se engloba dentro 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é elementos tendremos en cuenta para poder hacer cambios a la cartera.

Por mi parte recomiendo encarecidamente 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 ®.

En Prince2 ® esa parte de análisis de negocio sobre la viabilidad potencial de un nuevo proyecto, se realizaría en la parte de “Pre-arranque de proyecto” (Starting up a Project) y nos encontraríamos

No obstante es interesante la posibilidad de añadir elementos del marco de conocimiento PMBOK u otros que puedan aportarnos valor al identificar algún área que Prince2 no cubra, o bien crear 31

www.proiectus.es

Número 3, Noviembre 2014

nuestra propia metodología en la corporación si ésta demuestra efectividad para acometer los proyectos.

Agile Horrors

www.proiectus.es

Número 3, Noviembre 2014

MIKE GRIFFITHS Renowned project manager, trainer, consultant and writer, holding multiple project management and Agile related certifications. He is also a regular columnist and Agile contributor at www.leadinganswers.com and Ganthead.com Gantthead.com, the world’s leading online community for IT project managers.

Agile Horrors Agile practices are in a balanced network. Ruthless testing balances the need for comprehensive documentation; 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 environment. Don’t try and glom disparate process pieces together, it becomes a monster nobody loves or defends.

Frankenstein Process This is the methodology designed by committee that tries to combine iterative, empowered development with linear scheduling and command-and-control task assignment. Perhaps created in an attempt to satisfy the desires of competing groups, but this half goose, half salmon abomination neither flies nor swims.

Zombie Projects Some projects should just die but won’t seem to. Doomed from the outset with 33

www.proiectus.es

Número 3, Noviembre 2014

unrealistic deadlines, overly ambitious scope, or ill equipped skills and support; everybody knows it will not end well, but nobody seems willing or able to kill it.

about the issues, usually others have reached the same conclusion and are looking for support to fix things.

These death marches to eventual failure or cancelation are damaging to the people working on them who see the futility and mismatch of progress to targets. 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 shuffling forward like an army of undead looking for brains.

These people just suck the life out of things and never give back. Scrum Masters who look for process compliance but do not own or remove impediments; or project managers who push for velocity improvements, but don’t want to hear about quality improvements or refactoring plans.

Vampire Scrum Masters and Project Managers

Agile teams generally work very hard to deliver as many high quality features as they can. When they report problems 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 ignoring 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.

Unfortunately, there are no brains here and the higher-ups rarely have some cunning plan that turns struggling forward progress into an elegant solution. 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 attention to yourself if you are surrounded by zombies. Instead try to find an opportunity to exit quietly, see if there is a reset or restart initiative planned. Offer to be part of the solution, instead of bitching

Scrum Masters and project managers need to learn enough about their teams and their technical domain to distinguish genuine reports of problems and requests for investment from everyday complaints and unnecessary requests 34

Agile Horrors

www.proiectus.es

Número 3, Noviembre 2014

for resume boosting technology upgrades.

are understood, refined and prioritized, along with providing prototype feedback and resolving design decisions. Like missing or getting a poor developer or QA person, a project with a “hardly there” product owner will suffer tremendously.

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 extra mile to overcome an obstacle is removed. The delivery of results will decline and then the whole process sucks.

So, look out for signs of less than real product ownership. Warning signs of a non-committed or weak business involvement include: C - Contrary – decisions flip-flop with no clear explanation

So, show some interest, ask people to explain why issues and requests are important. If all the solutions are not possible 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.

A - Absent – you cannot find them or get their time when needed S - Switching – the person changes, no dedicated product owner is assigned

Product Owner Ghosts

P - Passive – without prompting we would not hear from them for long periods

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 attendance at a demo; product owner ghosts are unreliable.

E - Elusive – they will not provide clear feedback on the suitability of a prototype R - Reclusive – they withdraw from priority discussions and decisions

The product owner / business representative role is integral to agile processes. They are needed to ensure requirements

Instead try to staff projects with product 35

www.proiectus.es

Número 3, Noviembre 2014

owners who exhibit more solid, proactive business representations.

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

C – Collaborative – willing to discuss and evaluate alternative solutions O – Owners – owning the backlog of work, taking reasonability for its grooming N – Nearby – available when required to ask questions and get clarifications C – Committed – having the same person 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 questions T – Traceable – contactable when needed 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 Boehm’s CRACK mnemonic that does not emphasize the Nearby, Experienced 36

Agile Horrors

www.proiectus.es

NĂşmero 3, Noviembre 2014

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 problems are year round threats. More than just something that goes bump in the night, these problems are ever present in our lights-on projects. Look out for them and use your garlic and silver bullet awareness to keep them from impacting your projects.

www.proiectus.es

Número 3, Noviembre 2014

Pilar Tarriño Licenciada en Informática por la Universidad de Las Palmas de Gran Canaria. Tras varios 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. Enganchada a las metodologías ‘ágiles’ y a los ‘MOOCs’ y procurando no descolgarme del vertiginoso avance de la tecnología.

DEUDA TÉCNICA: Los cocodrilos salen de la alcantarilla Una antigua leyenda urbana en el Nueva York de los años 30 habla de pequeños cocodrilos que fueron traídos como souvenir y luego lanzados por los desagües. Allí crecieron y con el paso del tiempo se convirtieron en grandes y sigilosas sombras de ojos brillantes que acechaban a los empleados de mantenimiento. Es así como pequeñas decisiones aparentemente poco importantes se convierten en grandes problemas.

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 Cunningham 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 development so long as it is paid back promptly 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 brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

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 decisiones 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 podemos evitar cargar con ella, pero sí que debemos controlar su peso para que po-

— Ward Cunningham, 1992

DEUDA TÉCNICA: Los cocodrilos salen de la alcantarilla

www.proiectus.es

Número 3, Noviembre 2014

FASE 1: DETECTAR.

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 aumentando continuamente? Obviamente se llega a un punto de quiebra ante la imposibilidad de afrontarla.

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, estadísticas, … pero … ¿y si empezamos por preguntar? Creo que es lo más fácil y práctico. 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 preguntamos. En esta primera fase no se pretende un examen detallado y exhaustivo, solamente captar el sentir de los que trabajan día a día y codo con codo.

La diferencia entre la deuda económica y la técnica, es que en el primer caso normalmente es sencillo responder a las siguientes preguntas: • ¿Cuánto debo y con qué interés? • ¿Cuánto debo pagar mensualmente?

Obviamente lo primero es establecer una relación de confianza, no se buscan culpables ni culpas. Se buscan los problemas para proponer soluciones.

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

Las respuestas pueden ser: a. “Eh … ¿Deuda técnica? … ¡No tenemos ninguna deuda!”

Sin entrar en demasiada teoría, propongo una aproximación a este problema en tres fases clásicas: DETECTAR, CONTROLAR, REDUCIR.

b. “Bueno … tenemos un par de herramientas no fundamentales algo obsoletas.” c. “Buf … hay algunas partes fundamentales que necesitan una evolución” 39

www.proiectus.es

Número 3, Noviembre 2014

d. “Agh .. todo el proyecto depende de tecnologías no sólo obsoletas, antediluvianas!”

1- Muy baja 2- Baja 3- Media 4- Alta 5- Muy Alta

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 consciente 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 seguimos los máximos estándares de calidad? ¿estamos excelentemente formados?.

El objetivo final de esta primera fase es disponer de un mapa global de los puntos problemáticos de nuestro proyecto, ordenarlos por su gravedad para así empezar a controlar el problema.

FASE 2: CONTROLAR Llegados a este punto es importante determinar la/las causas por las que hemos llegado 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.

Recomiendo dividir nuestro proyecto en sus partes o secciones fundamentales, pero haciendo un desglose a alto nivel. No conviene inicialmente analizar elemento a elemento 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.

Martin Fowler utiliza el siguiente cuadrante para la clasificación de la deuda:

Dividido el proyecto en su partes principales, podemos estimar su nivel de deuda utilizando la técnica de planning poker. Todo el equipo debe estar involucrado en esta estimación. No me voy a extender sobre esta técnica dado que está profusamente documentada, pero el objetivo es que tras varias iteraciones lleguemos a un valor en el rango de:

Si ordenamos este cuadrante de menos mala a muy mala, tendremos que: 40

DEUDA TÉCNICA: Los cocodrilos salen de la alcantarilla

www.proiectus.es

Número 3, Noviembre 2014

En el caso de deuda inadvertida, pueden ser:

• 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 documentada y se planificará su corrección en un futuro cercano.

• Falta de comunicación. • Dispersión del conocimiento del proyecto. • Falta de estándares de calidad o de seguimiento de los mismos.

• Prudente e Inadvertido: El equipo no fue consciente de que la decisión tomada aumentaba la deuda técnica del proyecto, pero se detecta el problema y se planificará su corrección en un futuro cercano.

• Deficiencias en la formación y en los conocimientos necesarios para el proyecto. • Equipos inestables con alta tasa de movilidad. • Falta de liderazgo y control del proyecto.

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

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 actual, de forma que con el paso del tiempo la deuda disminuya de forma efectiva.

• Imprudente e Inadvertida: El peor escenario, el equipo aumenta continuamente la deuda técnica sin ni siquiera darse cuenta.

El plan de control de la deuda técnica debería atacar los siguientes aspectos:

Algunas posibles razones para incurrir en una deuda deliberada suelen ser:

• Liderazgo del proyecto

• Presiones para la entrega en plazos acordados.

• Calidad • Equipo de trabajo

• Relajación de la calidad con el objetivo de aumentar la velocidad o disminuir los costes.

• Conocimiento y Formación Un artículo de Henrik Kniberg describe muy gráficamente el objetivo de esta fase (http://

• Trabajo a corto plazo, sin evaluar las implicaciones futuras.

blog.crisp.se/2013/10/11/henrikkniberg/good-

• Falta de liderazgo y control del proyecto.

and-bad-technical-debt). Debemos procurar 41

www.proiectus.es

Número 3, Noviembre 2014

mantenernos en la línea verde, y estar muy atentos a no cruzar la línea roja.

3. Seleccionar de una lista de peticiones que está ordenada por importancia (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 objetivos y vuelta a empezar. Además de la lista de tareas o Product Backlog, 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 realización.

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 mantenerla bajo control. Llega el momento de ‘pagar’ la deuda y para ello el mejor enfoque desde mi modesto 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 describen las técnicas ágiles de gestión de proyectos. En resumen:

En cada ciclo, se debería reservar un porcentaje de la velocidad de trabajo para incluir tareas de esta segunda lista. De esta forma nos aseguramos un ‘pago’ continuo y estable de la deuda a lo largo de los diferentes ciclos de entrega. Esta cuota no debe ser negociable con el cliente por varias razones:

1. Establecer un ciclo de trabajo (sprint), con una fecha de inicio y una de fin.

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

2. Determinar la velocidad de trabajo, es decir, cuántas tareas podemos abordar en cada ciclo. 42

DEUDA TÉCNICA: Los cocodrilos salen de la alcantarilla

www.proiectus.es

Número 3, Noviembre 2014

la mayoría de los casos nos ha metido en el problema.

“Calidad significa hacer lo correcto

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

–Henry Ford

cuando nadie está mirando” —

REFERENCIAS: http://blog.crisp.se/2013/10/11/ henrikkniberg/good-and-bad-technical-debt http://martinfowler.com/bliki/TechnicalDebt. html

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:

http://www.ontechnicaldebt.com http://www.javiergarzas.com/2012/11/deudatecnica-2.html http://www.infoq.com/articles/managingtechnical-debt http://technicaldebt.com/got-technical-debt

CONCLUSIONES: ¨Nunca hay tiempo para hacer las cosas bien, pero si para hacerlas dos veces¨ –Anónimo

www.proiectus.es

Número 3, Noviembre 2014

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 proyectos” y participa actualmente en el TC-258 - project, programme and portfolio management.

metodología para la gestión de lecciones aprendidas basada en la metodología de gestión de riesgos Uno de los mayores retos en la actualidad de las organizaciones que trabajan por proyectos es la gestión del conocimiento, siendo las lecciones aprendidas generadas durante su ejecución, uno de sus principales activos.

los proyectos, define una metodología para una gestión eficiente y en tiempo real de las lecciones aprendidas tanto a nivel de proyecto como de programa o portafolio, basándose en las buenas prácticas del proceso de gestión de riesgos desarrollado por PMI y recogidas en el Practice Standard for Project Risk Management – First Edition.

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“, incluyendo un nuevo proceso denominado “Recopilar las lecciones aprendidas”, es necesario establecer metodologías, técnicas y herramientas que permitan implantar con éxito este proceso clave dentro de las organizaciones para mejorar el resultado de sus proyectos.

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 organizació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 fundamentalmente por una cultura de miedo a que se hagan visibles los errores (especial-

Este artículo, fruto de mi experiencia en los últimos años en este campo, donde empecé realizando el análisis post mortem de 44

Creando una metodología para la gestión de lecciones aprendidas basada en la metodología de gestión de riesgos

www.proiectus.es

Número 3, Noviembre 2014

mente en estos tiempos actuales de crisis).

tanto cualquier gasto de recursos en tareas que no se consideren necesarias se tratará de minimizar.

Recomendación: Esto se debe paliar 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.

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 posible en el acta de constitución del proyecto). Asimismo se deben considerar los siguientes Factores Ambientales de la Empresa en la que se implanta el proceso de lecciones aprendidas:

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.

1. Estructura de la organización. Dependiendo si la organización es funcional, matricial u orientada a proyectos los actores que intervendrán y la clasificación de las lecciones aprendidas podrían ser diferentes.

Recomendación: Se debe diseñar un proceso que asigne recursos y defina técnicas y herramientas tanto para asegurar la captación como para asegurar la difusión y reutilización de las lecciones aprendidas.

Si la estructura es funcional la clasificación de las lecciones aprendidas se podrá 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.

3. Falta de una métrica que nos permita medir el valor tangible que nos está retornando este proceso. Hay que tener en consideración que los proyectos están focalizados en la ejecución y por

Por el contrario, si la estructura es orientada a proyectos, la gestión del conoci45

www.proiectus.es

Número 3, Noviembre 2014

miento es más complicada al poder actuar 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 componen.

Expertos en la Materia (del término inglés Subject Matter Expert -SME) que actuaran como un nexo de unión entre los proyectos. 2. Sistemas de información para la dirección de proyectos. Si en la organización ya existen aplicaciones suele existir la tendencia a “encajar” el proce-

En dicho caso se deben crear “silos de conocimiento virtuales” liderados por 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 Niveles cualitativos de importancia basado en el impacto (análisis cualitativo) 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 Departamento o entidad liderando el proceso (se recomienda la PMO) de riesgos

Creando una metodología para la gestión de lecciones aprendidas basada en la metodología de gestión de riesgos

www.proiectus.es

Número 3, Noviembre 2014

Nueva metodología de lecciones aprendidas basada en la gestión de riesgos

so en las mismas lo cual puede restringir las funcionalidades y perjudicar la nueva metodología.

En el cuadro adjunto se puede ver la comparación entre la metodología de gestión de riesgos según PMI y la nueva metodología de lecciones aprendidas.

Se recomienda priorizar el proceso sobre la herramienta por lo que en una primera fase de implantación se pueden utilizar plantillas con un software de uso común como Microsoft Excel ® y posteriormente cuando esté madura y sea aceptada por la organización, se debe estudiar la opción de desarrollar una aplicación corporativa a medida.

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:

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, rentabilizando el coste de su desarrollo.

Proceso de identificación (IDE): consiste en la utilización de mecanismos para captar lecciones aprendidas y así evitar su pérdida.

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, definiendo el procedimiento que lo regule y asegurando 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 éxito del proceso (Post-Project Reviews to Gain Effective Lessons Learned, Project Management Institute 2007).

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 deben evaluar con el objeto de establecer su prioridad y analizar la viabilidad de las acciones definidas para cada lección aprendida. 47

www.proiectus.es

Número 3, Noviembre 2014

Proceso de almacenamiento (ALM): las lecciones aprendidas se almacenarán en una base de datos que permita su búsqueda rápida e intuitiva

ceso) explicando de una manera informal cuál es la situación y, en el caso de tenerla, 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 coordinador

Proceso de difusión (DIF): se define un plan de comunicación para asegurar que las acciones definidas para cada lección aprendida se difundan tanto al proyecto donde se identifican como al resto de proyectos.

• Identificación proactiva. Los coordinadores utilizarán para ello información del proyecto (informes de avance, registros de incidentes, registros de riesgos, etc..) pero la fuente principal será la realización de entrevistas al equipo de proyecto en las visitas periódicas.

Proceso de seguimiento (SEG): se establece un sistema que asegura la implementación de las acciones definidas para cada lección aprendida.

Proceso de identificación

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 proyectos se encuentran deslocalizados en diferentes ubicaciones y países) para establecer una comunicación fluida con el proyecto y entre los proyectos, siendo el coordinador el “medio de difusión” que la garantice.

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 habilitando una opción para ello si se dispone de una aplicación específica para el pro-

Como salida de este proceso se debe definir una ficha (ver ejemplo adjunto) para cada lección aprendida en la que se rellenaran al menos los siguientes campos: 1- Título 48

Creando una metodología para la gestión de lecciones aprendidas basada en la metodología de gestión de riesgos

www.proiectus.es

Número 3, Noviembre 2014

Para establecer el Impacto (I) se debe definir 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.

2- Descripción 3- Código (definido en el sistema de gestión de la configuración) 4- Proyecto 5- Tipo de proyecto 6- País 7- Acción a implementar (versión preliminar) 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.

Bajo (1)

Medio (2)

Alto (3)

No afecta o afecta en menos de 1 semana 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 definiremos tres niveles y tres colores que nos facilitarán la identificación visual.

Proceso de evaluación Una vez identificada la lección aprendida se debe establecer su prioridad al igual que sucede con los riesgos de un proyecto.

Nivel 1: Importancia alta Nivel 2: Importancia media

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 aprendida en los objetivos del proyecto (por ejemplo al coste o a su plazo de ejecución).

Nivel 3: Importancia baja Pero es aquí donde nuestra metodología incluye un concepto adicional, que aportará valor al proceso pues permitirá la utilizació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.

La otra variable utilizada para el análisis cualitativo de riesgos, la probabilidad, no aplica en principio en este caso al ser siempre 1 por tratarse de hechos. Otro enfoque es considerar la probabilidad (P) de recurrencia de la lección aprendida optando por la fórmula P x I. 49

www.proiectus.es

Número 3, Noviembre 2014

Ahora bien, en aquellas lecciones aprendidas que una vez realizado el análisis cualitativo se han establecido como prioritarias, se debe realizar un análisis de viabilidad de la acción a implementar (análisis cuantitativo).

1- Impacto (I) 2- Coste asociado al impacto (CI) 3- Coste asociado a la acción a implementar (CA) 4- Análisis de viabilidad (CI-CA)

Proceso de almacenamiento

Como hemos dicho anteriormente, necesitamos que se aprecie el valor del proceso y esto implica que una vez definida la acción a implementar, debemos analizar si es viable, es decir, que el coste de su implementación es menor que el coste del impacto vinculado a la lección aprendida. Esto es:

Las lecciones aprendidas identificadas tanto en el proyecto origen como las transferidas 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.

CI: Coste asociado al impacto (en el caso de que el impacto sea en plazo se cuantificará por ejemplo el coste de la penalización contractual por retraso en el proyecto)

Hasta este momento hemos generado una base de datos y aquí es donde muere este proceso en muchas organizaciones.

Procesos de difusión y seguimiento

¿Cómo vamos a difundir las lecciones aprendidas y asegurar la implantación de las acciones en los proyectos?

CA: Coste asociado a la acción a implementar La acción será CI – CA > 0

viable

siempre

Un primer paso, como hemos hablado, es disponer 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.

que

Al finalizar este proceso obtendremos un registro de lecciones aprendidas donde adicionalmente a los campos obtenidos en el proceso de identificación se rellenarán los siguientes campos:

A cada acción a implementar cuyo análisis de viabilidad sea positivo, se le asignará dentro del equipo de proyecto un respon50

Creando una metodología para la gestión de lecciones aprendidas basada en la metodología de gestión de riesgos

www.proiectus.es

Número 3, Noviembre 2014

Esta planificación del proceso se debe incluir en el plan para la dirección del proyecto o si se considera preciso en un plan de gestión de las lecciones aprendidas.

sable de su implementación (responsable 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 implementación.

Asimismo, es conveniente generar informes del proceso, a ser posible, por una cuestión de eficiencia, a través de la herramienta. Esta información será diferente en función del rol y de la visión del proceso. Así tendremos entre otros:

Y a partir de aquí se deben establecer diferentes niveles de seguimiento. Para el seguimiento periódico del estado de la implementación de las acciones, asignación de nuevos responsables, identificación de nuevas lecciones aprendidas será el coordinador quien establezca el calendario con el proyecto acorde a sus necesidades.

• Informes a nivel de proyecto para poder hacer seguimiento de las lecciones aprendidas con dos niveles de información (incluyendo los análisis de viabilidad al director de proyecto y sin incluirlo para el equipo de proyecto al ser información sensible).

Con el objetivo de poner en común lecciones aprendidas de las diferentes categorías, realizar análisis de viabilidad y tratar temas relativos al procedimiento que regula el proceso, se recomiendan reuniones periódicas de los coordinadores con el departamento que lo regula (en general según dijimos debe ser la PMO)

• Informes a nivel de categoría para uso del coordinador para hacer seguimiento de todas sus lecciones aprendidas, incluyendo para una misma lección aprendida, su estado en todos los proyectos donde se está implementando la acción (proyecto origen y proyectos destino).

Por último la PMO (o quien se asigne) se reunirá con la gerencia para tratar aquellas lecciones aprendidas nivel 1 (y quizás nivel 2) cuyo análisis de viabilidad es positivo pero que la dirección de proyecto (normalmente por razones de plazo o por falta de credibilidad en el análisis de viabilidad) se resiste a implantar.

Retorno del proceso de lecciones aprendidas En base a mi experiencia en la PMO implantando nuevos procesos en la organización, para garantizar su éxito y sostenibilidad en el 51

www.proiectus.es

Número 3, Noviembre 2014

tiempo, es una buena práctica ser capaces de demostrar el retorno que la inversión devuelve a la organización y en consecuencia que es un proceso que aporta valor.

siendo ROILA el retorno de la inversión del proceso Se recomienda, para conseguir el compromiso del proyecto con el proceso de lecciones aprendidas, establecer un objetivo vinculado a esta métrica (por ejemplo obtener un ROILA = 2% del presupuesto del proyecto).

En este caso, hemos definido para ello una métrica que no precisa de cálculos adicionales y que aporta esa valoración tangible que precisamos. Si consideramos el valor CI – CA obtendremos:

Esta métrica se puede combinar con otras que midan la eficiencia del proceso, como el porcentaje de lecciones aprendidas transferidas a un proyecto por el coordinador que se han implementado.

• En el caso de una lección aprendida positiva un beneficio real al proyecto (el coste del impacto menos el coste de implementar la acción) • En el caso de una lección aprendida negativa se habrá evitado una perdida al proyecto (el coste del impacto menos el coste de implementar la acción) En ambos casos, habremos aportado valor al proyecto por lo que el sumatorio de (CICA) para aquellas acciones ya implementadas, nos dará un valor monetario aproximado de lo que aporta el proceso (si se quiere realizar un cálculo más exacto se deberá descontar el coste de los coordinadores, viajes, etc..) mediante la fórmula: ROILA = (CI1 - CA1) +……..+ (CIn - CAn) 52

Una estrategia para enfrentarse al exÁmen PMP

www.proiectus.es

Número 3, Noviembre 2014

JOSE BARATO ARROYO Jose Barato es el Director de PMPeople, empresa especializada en formación, consultoría y gestión de proyectos. Desde 2009, participa en el proyecto opensource TALAIA OpenPPM, consistente en la creación, difusión y servicio sobre un producto de software libre para gestionar proyectos, programas y portfolios consistente con los estándares de PMI.

Una estrategia para enfrentarse al exÁmen PMP El grado de confianza necesario para presentarse al examen del PMI® con tranquilidad se alcanza practicando tests. Practicar es beneficioso para seguir aprendiendo (el buen aprendizaje viene cuando entendemos por qué las respuestas buenas son las correctas y por qué las otras son incorrectas) y también para llegar a la marca de un minuto por pregunta (en el examen hay que responder 200 preguntas en 4 horas). No hay atajos aquí: para aprobar el examen PMP ® , una vez están claros todos los conceptos, hay que habituarse a practicar muchas preguntas, cuantas más mejor. Es cuestión de práctica. Hay que practicar, practicar y volver a practicar. ¡Practicar hasta la extenuación! Hay muchos juegos de preguntas disponibles, de exámenes completos o de menos

preguntas, por áreas de conocimiento o mezclando las áreas, gratuitos o de pago, interactivos o en libros, etc. Antes del examen, hay que planificar un esfuerzo constante para hacer tests, más intenso a medida que se aproxima la fecha del examen. Es aconsejable reservarse un mínimo 2 horas al día las 2 últimas semanas para practicar tests. Solo después de sentir un primer grado de confianza respondiendo preguntas, es momento de programar la fecha del examen. Cuando soliciten el examen, pidan la ayuda en español para leer rápidamente el enunciado y distinguir la información relevante (que típicamente consiste en saber en qué proceso de los 47 hay que situarse). La gran dificultad a la que se enfrenta el candidato a la certificación del PMI ® es sin duda el tiempo limitado. Para el examen PMP ® tiene 4 horas para responder 200 preguntas, y siempre falta tiempo. La mayoría de 53

www.proiectus.es

Número 3, Noviembre 2014

los candidatos que suspenden el examen PMP ® se quejan de que les ha faltado tiempo en el examen. Cuando queda una hora, por ejemplo, se dan cuenta de que les quedan más de 60 preguntas por responder y entran en pánico. Para conseguir el tiempo medio de un minuto por pregunta es necesario haber hecho los deberes: aprender bien los fundamentos, practicar muchos tests, descansar bien el día anterior, etc. Todo esto, sin embargo, no garantiza el aprobado.

ofrece un tutorial. Aunque ya seguramente lo sepa, se le recuerda cómo responder las preguntas, cómo marcarlas para revisar, ir al resumen, etc. Muchos candidatos prefieren usar las teclas, mejor que el ratón. Es decir: pulsan la tecla [P] para ir a la pregunta previa, la tecla [N] para ir a la pregunta siguiente, la tecla [M] para marcar para revisar, la tecla [A] para elegir la respuesta a), etc. Dicen que así ganan velocidad. La pantalla de las preguntas es más o menos como se representa en la imagen (si piden la ayuda de la traducción al español, la pantalla aparece dividida en dos mitades, arriba en español y abajo en inglés: su respuesta quedará marcada en la sección en inglés, que es el idioma oficial del examen): Es probable que usted no necesite los 15 minutos para ver el tutorial. En el tiempo que le sobre, la recomendación es que realice lo que se conoce como “volcado de le memoria” (brain-dump). Anote en un papel cierta información útil que sabe de memo-

Para lograr un buen desempeño durante el examen por ordenador, yo aconsejo seguir una estrategia. Cuando se siente delante del ordenador, tendrá unos 15 minutos para aprender a usar la interfaz, para lo cual se 54

Una estrategia para enfrentarse al exÁMen PMP

www.proiectus.es

Número 3, Noviembre 2014

ria. Mientras esté realizando el examen no querrá detenerse a recordar las fórmulas, los porcentajes de 1-2-3 sigmas, el mapa de los 47 procesos, los 7 modelos de contratos, los 5 niveles de la pirámide de Maslow, los 5 niveles de formación de equipos de Tuckman, los 5 métodos de resolución de conflictos, etc., etc.

guida llega una pregunta muy difícil, y nos hace perder 5 minutos porque nos empeñamos en seguir el examen de forma secuencial. Esto es un error muy común. Mi consejo es que den una primera pasada quitándose las preguntas fáciles, cuando vuelvan a las preguntas difíciles, comprobarán que ya no les parecen tan difíciles, simplemente porque ya se han “aclimatado”. Se dice que un tercio de las preguntas son fáciles. Bien, empiece por ellas. Encuéntrelas y respóndalas. Si ha aprendido bien los fundamentos, en este grupo de preguntas fáciles seguras se incluyen casi todas las de ROI, EVM y CPM. El objetivo en esta primera pasada es terminar en 50 minutos con 50 preguntas seguras contestadas. El resto de las preguntas que no sabe con certeza puede haberlas respondido o no, pero es importante que las deje “marcadas para revisar”. Si ha respondido 50 preguntas con seguridad, tendrá 150 preguntas marcadas para revisar. Si consume los 50 minutos con menos preguntas contestadas, no se preocupe: no siga buscando preguntas fáciles, marque el resto para revisar y siga con el siguiente paso. Si consigue contestar 50 preguntas antes de 50 minutos, tampoco siga: marque el resto para revisar y siga con el siguiente paso.

Una vez ponga en marcha el cronómetro con la cuenta atrás de 4 horas, le aconsejo que siga una estrategia, eso le mantendrá enfocado y mejorará su desempeño. La mejor estrategia siempre será la suya, que debe haber practicado previamente. Quizá estos puntos le ayuden a diseñar su propia estrategia:

1. Primera iteración contestando solo las respuestas seguras y marcando el resto para revisar. Ocurre que al principio del examen entramos fríos y nerviosos, empezamos a responder preguntas fáciles y nos animamos, pero ense55

www.proiectus.es

Número 3, Noviembre 2014

2. En las siguientes iteraciones, olvídese de las preguntas que ha contestado sin dudar. Haga que la interfaz le muestre solamente las marcadas para revisar. Asegúrese de que contesta todas las preguntas. Vaya desmarcando aquellas que no quiera volver a repasar. Objetivo: 25 preguntas marcadas pendientes antes de los últimos 40 minutos. Por ejemplo, si le quedan 100 minutos, debería tener (100-10)*5/6=75 preguntas pendientes marcadas para revisar. El objetivo de hacer disminuir el número de preguntas marcadas pendientes puede ayudarle a mantenerse enfocado y darle confianza durante el examen. Antes del examen, cuando haga su brain-dump, podría pintar esta gráfica y luego ir marcando sobre la misma su desempeño real. Cada cierto tiempo, cuando llegue a un punto de control (¿cada media hora? ¿cada hora?) puede representar el punto indicando cuántas quedan pendientes en ese momento, a modo de burndown chart.

3. Después, dedique 30 minutos a resolver las preguntas marcadas pendientes, contestándolas definitivamente (quite todas las marcas). 4. Por último, dedique los 10 minutos finales a repasar todo el examen. Es importante que se asegure de que contesta todas las preguntas, ya que los fallos no restan. Si le gusta esta estrategia en varias pasadas, quizá también le interese poder monitorizar en cualquier momento cuántas preguntas debería tener pendientes de revisión para terminar a tiempo. Para controlar hay que medir. Si representamos el número de preguntas marcadas pendientes siguiendo la estrategia indicada arriba, nos quedaría una gráfica como esta:

¿Quizá esta pueda ser una buena forma de evitar agobios al final?

El rol del Director del Proyecto en el Cliente

www.proiectus.es

Número 3, Noviembre 2014

Antonio Martel Titulado en Informática y Sistemas por la Universidad Las Palmas de Gran Canaria y PSM®. Responsable de la dirección de proyectos software de las áreas de gestión medio ambiental y de inteligencia de negocio en DESIC, compañía de desarrollo software canaria. Autor del libro Gestión práctica de proyectos con Scrum y contribuidor principal del blog www.antoniomartel.com, dedicado a mejorar la productividad de los departamentos de desarrollo software mediante la aplicación de metodologías ágiles.

El rol del Director del Proyecto en el Cliente Hay muchas formas de denominar a la persona que cumple las funciones de Director del Proyecto en la organización que nos contrata. Aquel que tiene la visión del producto que necesita su compañía y que la representa ante el equipo de trabajo. Si pertenece a la organización externa que nos ha encargado el trabajo, el nombre que mejor se le ajusta es el de Dueño del Producto, como hace Scrum, porque es eso literalmente, el ‘Dueño’ de lo que se ha contratado. Si en cambio es una persona de nuestra propia organización la que va a representar al ‘negocio’ en el proyecto suele denominársele Product Manager o incluso Business Analyst según la empresa que le haya dado el cargo. Personalmente, quizás por el tipo de proyecto que habitualmente gestiono, me siento más cómodo llamándolo simplemente Director del Proyecto en el Cliente.

una función muy importante para el éxito de un proyecto. Es el encargado de decidir qué funcionalidades tendrá el producto que se está construyendo, cuáles son importantes y cuáles son prescindibles. Es posible que sea un usuario final del producto por lo que tendrá muy claro qué se necesita para obtener una herramienta útil en su trabajo diario, pero no debe ser útil solo para si mismo o su departamento, sino que deberá tener en cuenta los requisitos de toda su empresa. Cuando comenzamos un nuevo proyecto, el Director del Proyecto en el cliente y todos los usuarios interesados en el producto final tienen un montón de ideas y grandes expectativas para el nuevo sistema. Lamentablemente, ningún proyecto, por grande que sea, puede contemplar todas y cada una de las sugerencias de sus usuarios. Algunas ideas serían irrelevantes para la mayoría, otras funcionalidades

Lo llamemos como lo llamemos, cumple 57

www.proiectus.es

Número 3, Noviembre 2014

serán demasiado costosas de implementar o llevaría tanto tiempo desarrollarlas que retrasarían la puesta en marcha del producto. Es aquí donde el Director del Proyecto en el Cliente, que conoce bien el mercado y tiene una clara visión del producto, tendrá que priorizar las características más importantes y descartar aquellas que aportan menos valor al resultado final.

dosamente todos estos requisitos en un cuaderno. Al segundo mes de comenzado el proyecto Elena se da cuenta que el Equipo de Trabajo en la empresa desarrolladora está entregando de 4 a 6 nuevas funcionalidades a la semana y que esta parece su capacidad máxima de trabajo. Está contenta con el trabajo que están haciendo pero tiene un problema: en su libreta anota una media de 10 nuevos requisitos a la semana. La lista está creciendo y pronto necesitará un nuevo cuaderno.

Para explicar hasta dónde llegan sus responsabilidades imaginemos que nuestra empresa decide contratar el desarrollo de un nuevo sistema de reserva de billetes de avión. En esta empresa han nombrado a Elena como Dueña del Producto o Directora del Proyecto y tendrá que trasladar a la empresa contratada todos los requisitos y necesidades que el nuevo sistema deberá cubrir.

Primero solicitó al Equipo de Trabajo que hiciera un esfuerzo para entregar estas diez funcionalidades cada semana. Lamentablemente, no muchas más funcionalidades eran entregadas y, lo que es peor, se comenzaba a percibir que la calidad de las mismas había bajado. En ocasiones incluso había que parar todo para corregir defectos en entregas previas. Si seguían así, la desmoralización y el estrés iban a dominar el proyecto.

Elena tiene una visión muy clara de lo que quiere y está muy ilusionada con el proyecto. También los están los responsables de IT, marketing y ventas que han elaborado una exhaustiva lista de funcionalidades a incluir en el nuevo producto. Incluso en conversaciones informales, los que serán nuevos usuarios del sistema, le trasladan a diario peticiones de nuevas funcionalidades. Elena no quiere que se le escape nada importante y anota cuida-

Elena iba a decidir a partir de ahora qué se hacía y qué no. Todas las funcionalidades no iban a poder se desarrolladas, por lo menos no ahora. Algunas tendrían que esperar a una futura versión. Desde luego, la funcionalidad similar al Clippy de Windows 58

El rol del Director del Proyecto en el Cliente

www.proiectus.es

Número 3, Noviembre 2014

para asistir en la compra de los billete de avión era un claro ‘No’.

dades de aproximadamente el mismo valor para la empresa pero tardaríamos 5 días en desarrollar una de ellas cuando la segunda podría estar desarrollada en una horas, también estaba claro en cuál se trabajaría primero. Elena sabía que el coste y el valor de cada funcionalidad no eran números absolutos sino solo una aproximación. No sabemos cuánto pesa una manzana pero sí sabemos que es aproximadamente 5 veces más grande que una fresa y que la fresa gusta más (para los que van a pagar por ella al menos) por lo que la fresa se construiría primero. Es un modo fácil de decidir qué aporta más valor y más rápido a nuestro proyecto.

Fuente: Flickr Autor: Bill sinser

Pero ¿cuáles desarrollar primero? ¿qué criterio seguir? Elena se dio cuenta de que no había relación directa entre el coste de las funcionalidades y su valor para el producto final. Algunas funcionalidades eran fáciles de construir pero otras, en cambio, llevaban mucho tiempo de desarrollo pero no por ello eran las que más valor aportaban. Si preguntaba directamente al Equipo de Trabajo en cuantos días podría estar hecha cada una de las funcionalidades sabría su coste aproximado y si preguntaba a los usuarios por una valoración del 1 al 5 para cada funcionalidad sabría calcular el valor para su empresa.

La comunicación es una parte importante de las responsabilidades de Elena. Deberá estar en contacto directo con el Equipo de Trabajo pero también con las personas de su empresa que tienen algo que decir sobre el producto que se va a construir. Debe ser hábil para saber decir ‘no’ cuando sea necesario, Debe ser práctica también para tomar esta decisión de forma rápida y directa y, además, conocer muy bien su negocio para asegurarse de que se construye lo que realmente aportará valor a su empresa. Todo un papel para Elena ¿no creen?

Si había dos funcionalidades que tienen el mismo coste aproximado pero una tiene valor 1 y la segunda valor 3 estaba claro que se construiría la segunda funcionalidad. Si en cambio, había dos funcionali59

www.proiectus.es

Número 3, Noviembre 2014

Referencias: Este artículo está basado en el vídeo-presentación de

Henrik Kniberg, Agile Product Ownership in a Nutshell, y en el blog post de Mountain Goat, Product Owner.

Gestión de la Calidad en los Proyectos de Consultoría

www.proiectus.es

Número 3, Noviembre 2014

Vicente R. Merchán Rodríguez Consultor y capacitador de TIC, certificado en ITIL Foundation , Member ID PMI: 2266702, Certificado Microsoft. Con experiencia de más de 15 años a nivel profesional, desarrollando e implementando proyectos de telecomunicaciones y sistemas de información, todos en el sector público. Actualmente docente del Departamento de Ciencias de la Computación, de la Universidad de las Fuerzas Armadas – ESPE de Ecuador.

Gestión de la Calidad en los Proyectos de Consultoría se ciñe a un alcance determinado de trabajo, muy concreto, limitándose a analizar y estudiar la información disponible acerca de los aspectos técnicos, económicos, financieros y riesgos que demanda el problema en cuestión. En nuestro caso al proyecto se le denominó: estudio, sin que esto lo aparte de la aplicación de las buenas prácticas de dirección de un proyecto per se, como son: la planificación, la ejecución, el control y seguimiento, y el cierre. Además, sin apartarse de las normas que regulan la contratación y ejercicio en el ámbito público1.

1. INTRODUCCIÓN Antes que nada un agradecimiento a la persona que dirige la revista y al equipo que conforman. Este artículo se motiva por los resultados obtenidos en el último proceso de consultoría entregado a satisfacción de nuestro cliente del sector público; específicamente, el Ministerio de Telecomunicaciones y de la Sociedad de la Información del estado ecuatoriano. Los proyectos de consultoría tienen su particularidad al igual que el resto de proyectos clásicos, de investigación o industrial; los cuales demandan un conjunto de actividades necesarias para alcanzar el objetivo propuesto y el rendimiento esperado.

Para claridad en el entendimiento de nuestros lectores; el estado ecuatoriano cuenta con una normativa denominada: Ley Orgánica del Sistema Nacional de Contratación Pública (LOSNCP), la cual, regula el sistema de contratación pública, de igual manera, debe ser observada por toda entidad contratante del sector estatal2.

En definitiva, el proyecto de consultoría o estudio es el principio de este artículo. El mismo

www.proiectus.es

Número 3, Noviembre 2014

En la Ley constan los principios y directrices que se deben tomar en cuenta para la contratación de Bienes y Servicios, incluido los de consultoría; cuyo procedimiento de adquisición se establece de acuerdo al monto a contratar.

Durante esta fase preliminar conocida como de preparación de la oferta, se comunica al potencial cliente lo que se va hacer, cómo se va ejecutar, en cuanto tiempo y a qué precio; con un adecuado nivel de detalle. Esto ya nos suena familiar con las prácticas enlistadas en el PMBOK, cuando se refiere al proceso de gestión de la calidad, en donde se debe asegurar las actividades necesarias para que un proyecto sea eficaz y efectivo3. Siendo así, la calidad en el proyecto de consultoría no fue un proceso aislado, por el cual, se debió esperar al final del desarrollo del proyecto para asegurarla, sino que fue un proceso que se llevó a cabo desde el mismo instante en que se ofertó, siendo aún más específico, desde que se firmó el contrato con el cliente contratante.

Fuente: FreeDigitalPhotos.net Autor: Stuart Miles

Para culminar, el enfoque de la calidad, además del descrito en PMBOK, también se toma en cuenta los estándares de ISO, así como las recomendaciones de Deming, Juran y Crosby.

Un aspecto importante que se debe involucrar desde el mismo momento que empieza la relación con el cliente es el aspecto de Calidad. El potencial cliente de un proyecto debe saber que tiene ante él, un equipo de trabajo capaz de cumplir eficientemente su responsabilidad, en precio y condiciones determinadas. Este primer acercamiento deja una buena o mala impresión ante el cliente, el mismo que se constituye en un factor clave de éxito, ya que de este depende el apoyo a recibir a lo largo del ciclo de vida del proyecto.

2.PLANIFICACIÓN DE LA CALIDAD El proceso de planificación de la calidad se llevó a cabo con la identificación de requisitos de calidad que luego serían aprobados por el cliente. Algo muy importante en este proceso fue la identificación y registro de riesgos, los cuales fueron analizados e interiorizados como 62

Gestión de la Calidad en los Proyectos de Consultoría

www.proiectus.es

Número 3, Noviembre 2014

potenciales impactos en el cumplimiento de los requisitos de calidad. Lográndose determinar que los estándares de información que se planeaba solicitar a los operadores de telecomunicaciones no eran suficientes para correr el modelo técnico-económico (Objeto del contrato), y por lo tanto, no garantizarían la calidad.

más, como el tiempo era corto, aplicábamos buenas prácticas sobre la marcha como detección de errores semánticos, tipográficos, estadísticos, entre otros, y se los corregía a tiempo.

4. CONTROL DE LA CALIDAD El equipo tenía mucha práctica en lo que hacía. Conocía muy bien su trabajo y el área de conocimiento materia del contrato, sin emFuente:FreeDigitalPhotos.net bargo, fue importante Autor: Stuart Miles inspeccionar de manera detallada cada uno de los productos y verificar su consistencia literaria acorde con los requerimientos establecidos. Este trabajo lo realizó pares en la materia. Cada producto tenía el control de calidad requerido, se manejaba una lista de lecciones aprendidas en cada revisión las mismas retroalimentaban los productos siguientes que en el orden de cinco fueron los que consolidaron el producto final.

El proyecto presentó complicaciones. Se debió manejar la incertidumbre con supuestos, con la finalidad de avanzar en la ejecución y que no sirva de excusa para irlo dilatando. El equipo de trabajo estaba cohesionado. El plan de trabajo se diseñó en función del tiempo y los productos a entregar. Se utilizaron técnicas de costo de la calidad a nivel interno, principalmente. Se establecieron reuniones de seguimiento semanal en modalidad in situ o virtual; con el cliente o con el equipo interno del proyecto, con la finalidad de ir evaluando la calidad de información que se relevaba y recuperaba de las fuentes. De igual manera se mantuvieron reuniones comparativas con otro proyecto externo parecido, en cuanto al área de conocimiento que se estudiaba.

3. ASEGURAMIENTO DE LA CALIDAD

Al final del camino el producto final denominado: Informe Ejecutivo, fue presentado a tiempo tras una validación con el grupo administrador del contrato y beneficiarios del servicio de consultoría que fueron parte de la institución contratante. Lo que nos demuestra que la Planificación de la Calidad funciona.

Si bien no incurrimos en auditorías de calidad como establece el PMBOK, nos encargamos en desarrollar actividades ágiles de revisión unipersonal a las políticas y normas acordes a las establecidas por la institución. Ade63

www.proiectus.es

Número 3, Noviembre 2014

Referencias 1

A. Domingo Ajenjo, Dirección y Gestión de Pro-

yectos, Mexico D.F.: Alfaomega Grupo editor, 2005. 2

Servicio de Compras Públicas del Ecuador, [En

línea]. Available: http://portal.compraspublicas.gob. ec/incop/cat_ normativas/losncp. [Último acceso: 10 Junio 2014]. 3

Project Management Institute, Guía de Funda-

mentos para la Dirección de Proyectos, Quinta ed., Newtown Square, Pennsylvania: Project Management Institute, Inc., 2013.

Entrevista a Javier Zaya Martín

www.proiectus.es

Número 3, Noviembre 2014

Javier Zaya Martín Director de Proyectos IT con 19+ años de experiencia. Titulado en Informática por la ULPGC, inicia su carrera profesional en Canarias trabajando para diferentes empresas de Las Palmas y Santa Cruz. Posteriormente, se traslada a Madrid para incorporarse a INDRA, empresa a la que estuvo vinculado durante 13 años. En 2003 regresa a Las Palmas para montar la delegación de INDRA en Canarias, responsabilizándose de los proyectos para Sector Público, y teniendo la oportunidad de colaborar prácticamente con todas las Administraciones Locales y Empresas de la zona. Por último, tras una breve aventura como Consultor independiente, en Julio de 2014 decide dar el salto a Auckland (NZ) donde reside actualmente.

Entrevista a Javier Zaya Martín En primer lugar, queremos agradecer a Javier su interés en participar en este número.

Por tanto, la satisfacción es mutua. 1. Después de más de 20 años gestionando proyectos TIC para la Administración Pública, ¿cuál consideras que es el principal reto al que se ha de enfrentar un director de proyectos para poder cumplir con los objetivos de un proyecto?

Muchas gracias a la revista por contar conmigo. En primer lugar Javier, agradecerte el que desde la Nueva Zelanda de Tolkien, hayas encontrado un hueco para colaborar con nosotros en este tercer número de la revista.

Cuando lleve esos 20 años, podré responderos. “Sólo” llevo 19 años de carrera profesional, y 16 gestionando proyectos.

Para una publicación nacida en Canarias, siempre es una satisfacción poder contar con profesionales canarios que han demostrado a lo largo de los años su capacidad para gestionar proyectos tanto a nivel nacional como a nivel internacional.

Desde mi experiencia, y respondiendo a la pregunta, diría que el principal reto es el de alinear los intereses de todos los implicados (stakeholders en su más amplio sentido). Sólo cuando todas las piezas se mueven al unísono, con un objetivo compartido, es posible superar las múltiples barreras que aparecerán durante

Era algo que tenía pendiente pero, precisamente por estar con la cabeza centrada en este “pequeño salto”, no había podido. 65

www.proiectus.es

Número 3, Noviembre 2014

la ejecución del proyecto. Y esta sintonía debe mantenerse durante todo el ciclo de vida del proyecto.

• Presupuesto inadecuado • Recursos inadecuados (aparte del presupuesto)

Fíjate que doy por hecho que aparecerán obstáculos, problemas, habrá crisis (internas, con el cliente, con los usuarios...). Sin embargo, y como os digo, siempre que todas las partes tengan claros los objetivos, las condiciones de partida, los condicionantes... esos obstáculos se podrán superar. Y ése es precisamente el reto del Director de Proyectos, garantizar las condiciones para que ese entendimiento exista, gestionando el cambio, facilitando la labor del equipo de proyecto (como dijo acertadamente Antonio Martel en el primer número, “un Director de Proyectos es un facilitador, un servidor”), gestionando expectativas (propias y del cliente), priorizando/negociando... Y os aseguro que no es tarea fácil.

• Requerimientos críticos mal especificados (o no identificados) • No tener acceso al Sponsor del Proyecto a la hora de aprobar decisiones estratégicas (o directamente no tener sponsor) • Miembros clave del equipo sin ciertas habilidades críticas • Miembros clave del equipo sin el nivel adecuado de autoridad • Tareas críticas del proyecto entregadas tarde • Pruebas inexistentes, incompletas o inadecuadas

Dándole la vuelta a la pregunta, “¿qué obstáculos impedirán que un Director de Proyectos cumpla con los objetivos del proyecto?” mi respuesta no podría ser más estándar:

Y todos ellos, en mi opinión, son consecuencia de una mala gestión (y consenso/alineación) de los intereses de todos los implicados por parte del Director de Proyecto.

• Cambios en el alcance del proyecto (Scope Creep)

Dicho esto, sin embargo, quiero romper una lanza en favor de todos los Directores de Proyecto que, como yo en infinidad de ocasiones, nos hemos encontrado con unas

• Poco tiempo para completar el proyecto (plazos no realistas) 66

Entrevista a Javier Zaya Martín

www.proiectus.es

Número 3, Noviembre 2014

condiciones de partida difíciles de asumir (por las razones que sea) y hemos intentado reconducir, con mayor o menor éxito. Me refiero a proyectos aceptados a sabiendas de que el presupuesto o el plazo son insuficientes, sin el equipo adecuado, sin el conocimiento previo adecuado, sin Project Charter, sin participación activa del cliente... Y aún así los hemos sacado adelante.

el primer número algunos problemas derivados de la aplicación estricta de la Ley de Contratos del Sector Público, de la sujeción a la Ley General Presupuestaria (según el momento de publicación), y de valorar positivamente bajadas “cuasi-absurdas” en el precio de licitación. Seguro que podría poneros infinidad de ejemplos de cómo se publicaron algunos pliegos que jamás deberían haber visto la luz.

2. A diario se publican licitaciones públicas que introducen como criterio de valoración de las propuestas el plan de proyecto y la metodología de trabajo propuesta. Sin embargo, no siempre los requisitos se recogen en los pliegos con el nivel de detalle necesario para poder elaborar un plan de proyecto realista. Bajo estas circunstancias, ¿consideras acertado introducir el plan de trabajo como criterio objetivo de valoración de propuestas? En base a tu experiencia, ¿se ha podido ceñir luego el trabajo a ese plan de proyecto recogido en la propuesta?

Ciñéndome a la pregunta, y aunque posiblemente os sorprenda mi respuesta, honestamente debo responder que sí, que considero acertado introducir “un plan de trabajo” como criterio objetivo de valoración. Ahora bien, como acertadamente habéis indicado, antes de poder elaborar ese “primer plan” las empresas deberían conocer con un nivel suficiente de detalle los requisitos del proyecto y cualesquiera otros condicionantes que pudieran afectar al diseño de ese plan. Y eso implicaría que la Consejería, Dirección General, Servicio, Centro Directivo... ha hecho sus deberes y sabe qué es lo que realmente necesita o quiere.

La forma en que están redactados los pliegos de muchas licitaciones públicas, y los problemas que posteriormente supondrían para el proyecto de respetarse con escrupulosidad, darían para un monográfico en la revista. Miguel Quintanilla ya apuntó en

En cualquier caso, fijaos que hablo de “UN plan de trabajo” o un “primer plan”, no de “EL plan de trabajo”. ¿Por qué? Precisamente por lo que apuntáis. En fase de pliego/oferta no se conocen con exactitud los requisitos del proyecto. El alcance no está 67

www.proiectus.es

Número 3, Noviembre 2014

claramente delimitado. Es más, posiblemente el cliente (Sector Público) ni siquiera sepa por qué necesita ese nuevo producto o servicio. En el momento de publicar los pliegos, sólo sabe que dispone de cierto presupuesto máximo (las Reservas de Crédito que nos explicaba Miguel), que alguien (personal de la casa o alguna empresa externa, o quizás, simplemente preguntando a otro organismo «similar» cuánto le costó ejecutar «lo mismo») le ha dicho que es suficiente para acometer su proyecto. Un proyecto, no olvidemos, que «más o menos» tiene claro (con suerte porque los mismos que le dijeron que ese presupuesto era suficiente se han encargado de detallar y especificar al máximo, estimando costes, márgenes y plazos de ejecución razonables).

• Esos pliegos se publican o se hacen llegar de alguna manera a las empresas que, en igualdad de condiciones, cuentan con un tiempo razonable para realizar sus propios análisis y estimaciones. Dado que el objetivo (teórico) deseable es lograr un máximo de entendimiento por parte de los posibles licitadores, el cliente público debería habilitar un canal de comunicación (¿abierto y compartido?) para responder a cuantas preguntas le formulen. De esta forma, es posible que aparezcan nuevos requerimientos o se aclaren aspectos dudosos de los pliegos. • Teóricamente, y de forma bastante razonable, si la estimación inicial (interna) realizada por el cliente antes de la publicación de los pliegos se hizo con el criterio y la profesionalidad que se le supone, las posibles empresas licitadoras, bajo los mismos supuestos, habrán llegado a números bastante similares, o no. ¿Por qué las discrepancias? Diferentes costes de estructura que repercuten en diferentes costes por perfil, disponibilidad local de recursos, conocimiento suficiente de la tecnología/cliente, experiencias previas similares... y diferente nivel de madurez en la ejecución de proyectos (cuanto más acostumbrados estemos a ejecutar proyectos, mejor lo

Así las cosas, y haciendo un ejercicio de abstracción y fe importantes, tenemos que: • El cliente, previa publicación de los pliegos, ha hecho un trabajo interno importante de identificación de requerimientos, evaluación de alternativas, estimación de esfuerzos, dimensionamiento del posible equipo de proyecto, estimación de costes medios, estimación de márgenes razonables (margen comercial y/o industrial), presupuesto máximo de licitación... Y todo ello lo ha plasmado en unos pliegos. 68

Entrevista a Javier Zaya Martín

www.proiectus.es

Número 3, Noviembre 2014

haremos, y menos nos costará). Y es precisamente ese «nivel de madurez en la ejecución de los proyectos» lo que el cliente quiere ver reflejado en la oferta. ¿Y cómo? En forma de Plan de Proyecto y Metodología (si somos estrictos, el Plan de Proyecto es «algo más» que un cronograma/diagrama de Gantt). Ese primer plan reflejado en fase de oferta debe contemplar, entre otros, determinados aspectos que considero claves:

cesidad de contar con «algo» tangible (una especificación formal de requisitos – ERS de Métrica, o un Product Backlog de Scrum...) ANTES de poder plantear siquiera una estimación realista del cronograma del proyecto. • Finalmente, en base a las ofertas presentadas, y asumiendo un proceso de adjudicación objetivo, limpio y honesto, al adjudicatario será aquella empresa que maximice los criterios de adjudicación.

|| Contemplar explícitamente la volatilidad, incertidumbre, complejidad y ambigüedad inherentes a todo proyecto en esta fase inicial, definiendo unas horquillas o márgenes de «movilidad» razonable dentro de nuestras condiciones de contorno.

Por todo esto, y como debemos creer en la corrección de los procedimientos, es por lo que considero razonable, necesario y hasta “sano” para la profesión, que se introduzca el plan de trabajo como criterio objetivo de valoración de propuestas.

|| Exigir la participación activa del cliente en la revisión, identificación, priorización y posible eliminación de requisitos en diversos momentos del proyecto (podemos aprovechar para «educar» al cliente, enseñándole a aplicar alguna metodología tipo MoSCoW).

Con respecto a la segunda parte de la pregunta, y dado que la situación de partida anterior es inusual (por no decir, irreal), nunca me he encontrado con un proyecto en el que el plan de trabajo final fuera siquiera cercano al reflejado en la propuesta. Y, casi siempre, en perjuicio de la empresa que, no lo olvidemos, está obligada a acatar en su totalidad las condiciones reflejadas y exigidas en pliego.

|| Y, en base a la metodología exigida en pliego u ofertada, plantear la ne69

www.proiectus.es

Número 3, Noviembre 2014

3. Durante mucho tiempo los contratos con la Administración Pública se han gestionado haciendo uso de metodologías predictivas, sin embargo, a lo largo de los últimos años hemos asistido a la consolidación de las metodologías adaptativas como alternativa a las predictivas, ¿consideras factible aplicar metodologías ágiles tipo Scrum a la gestión de proyectos en la Administración Pública? ¿cuáles son los pros y los contras que podrían derivarse de su aplicación?

base a un plan preestablecido, a otra “invertida” donde, en función del presupuesto y el tiempo, y mediante un proceso adaptativo (guiado por el valor ganado), se genera un paquete de funcionalidades.

Sin duda. Considero completamente factible aplicar metodologías ágiles. Sólo es necesario cierta labor de “evangelización” y formación al personal de la Administración. A los técnicos y participantes en los equipos de proyecto para aprovechar plenamente esa mayor implicación (los “on-site customers” según Kent Beck), y especialmente, a los técnicos de Contratación e Intervención en relación a los nuevos planteamientos y enfoques contractuales, hitos de facturación (idealmente, uno por release)...

Funcionalidades = f (Coste, Calendario)

Modelo Predictivo (Waterfall): [Coste, Calendario] = f (Requerimientos) Donde f () es el Plan de Proyecto para esos requerimientos que nos vienen dados Modelo Adaptativo (Agile):

Donde f () es la “visión” que podemos tener del sistema, y que maximiza el valor ganado para ese Coste y Calendario dados.

Pros, muchos. Mayor agilidad en la ejecución de los proyectos que, con el tiempo, derivaría en una organización más ágil. Un mayor ratio de proyectos finalizados con éxito. Una optimización en la gestión del presupuesto y el calendario. Mejor gestión de los riesgos. Una implicación mayor de los usuarios, lo que simplificaría la gestión del cambio, al reducir las resistencias, mejor capacidad de respuesta ante los cambios/nuevas peticiones...

Básicamente, el éxito de la implantación de las metodologías ágiles en la Administración pasa por “darle la vuelta” a la relación existente entre requerimientos, coste y calendario, pasando de la habitual en metodologías predictivas (Waterfall), en la que los requerimientos condicionan el coste y el plazo en

Contras, los derivados de una deficiente asimilación del nuevo paradigma, como, por ejemplo, pretender mantener y respetar un 70

Entrevista a Javier Zaya Martín

www.proiectus.es

Número 3, Noviembre 2014

plan de proyecto rígido “en paralelo” a una ejecución ágil y adaptativa, plantear unos hitos de facturación acordes con un modelo en cascada (análisis, diseño, construcción, puesta en marcha)...

ta. Como siempre, todo depende del grado de madurez de la propia Organización, del punto de partida. Básicamente, habría que evangelizar (y es en casos como éstos donde el término viene que ni pintado) a todos los niveles, desde los puestos directivos (Directores Generales, Jefes de Servicio, Intervención...) hasta los responsables funcionales y grupos de usuarios. Lógicamente, cada uno según su grado de participación estimada/ deseada en el proyecto.

En todo caso, sin embargo, considero que fomentar la dicotomía Metodologías Ágiles vs. Metodologías Predictivas (o Scrum vs. Waterfall), como excluyentes e incompatible, no nos beneficia en absoluto a los que defendemos la aplicación “juiciosa y con criterio” de unas u otras (o ambas a la vez). Personalmente, abogo por la aplicación simultánea de ambas metodologías, aprovechando “lo mejor de cada casa” y enriqueciendo nuestra labor como PM/facilitador. Como leí hace tiempo, “Así como en el más Ágil de los proyectos Ágiles subyacen los principios de la gestión tradicional de proyectos, del mismo modo el más predictivo y tradicional de los Waterfall podría ser Ágil”.

El “argumento de venta”, en cualquier caso, creo que es potente: el cliente (alguien dentro de la organización con capacidad de decisión, habitualmente el Director Funcional del Proyecto) pasa a desempeñar un papel fundamental, activo, en el proceso de ejecución de su proyecto. Se convierte, o al menos ése es el objetivo, literalmente en el Product Owner (no sólo en el papel, como parte contratante). Y sus “historias” serán la forma en que nos indicará qué quiere o qué espera del producto final. Trabajará codo con codo con el equipo de proyecto, y verá, cada poco tiempo (15-30 días) cómo va tomando forma su producto. Participará en la planificación de las iteraciones, sabiendo qué tendrá al finalizar cada una de ellas. Sus técnicos, si así se decide, también podrían formar parte del equipo de proyecto, facilitando la posterior transferencia de conocimiento.

4. Desde el punto de vista de la gestión del cambio y de las personas, ¿cómo se debería abordar el cambio metodológico dentro de una Administración encorsetada en prácticas tradicionales y aderezadas con RPTs (relaciones de puestos de trabajo) obsoletas? Buena pregunta. Sin embargo, me temo que no hay respuesta sencilla, clara y direc71

www.proiectus.es

Número 3, Noviembre 2014

Donde más problema veo, como ya apunté, es en el área de Contratación e Intervención. Mientras los hitos facturables se sigan planteando en términos de “Fases y Entregables de Proyecto”, según su entender (básicamente las fases habituales de Métrica 3: Especificación Funcional del Sistema, Análisis del Sistema, Diseño, Construcción, Pruebas...), y esas fases se estimen (en tiempo y presupuesto) en base al peso porcentual que, históricamente, hayan tenido en los proyectos de desarrollo de software que ellos hayan ejecutado (x% Análisis, y% Diseño y Construcción...) las metodologías Ágiles tendrán difícil encaje. Quiero decir, podremos abordar la ejecución del proyecto en términos ágiles, con implicación de los usuarios, el Product Owner, etc. De nada nos servirá a la hora de intentar emitir la primera factura tras la primera iteración. Contratación se regirá por lo que dice el pliego (algo tipo “el primer pago se realizará a la finalización de la fase de Especificación Funcional del Sistema, y previa presentación del Documento Formal de Especificación de Requisitos del Sistema, junto con el Cronograma detallado del resto del proyecto hasta su finalización”) y nos preguntará que dónde está ese documento, y cuál es la planificación, etc. Y tendremos que hacer “encaje de bolillos” con ellos planteándoles “equivalencias” absurdas tipo “como cada iteración equivale a un x% del proyecto total, y dado que en cada

una de ellas abordamos análisis, diseño, construcción, pruebas, formación, puesta en marcha... qué te parece si tras la primera nos pagas el primer hito, tras la segunda nos pagas parte del segundo hito, pero sin considerarlo incumplimiento...”. Si a todo eso le unimos el hecho de que, con las metodologías ágiles, no estamos limitados a un sólo tipo de contrato (precio fijo cerrado, plazo fijo), la necesidad de gestionar el Cambio en el área de Contratación e Intervención (y, posiblemente, en la propia Ley de Contratos del Sector Público) se hace indispensable. 5. ¿Consideras que el modelo de contratación actual de la Administración – precio fijo cerrado- es el más adecuado para gestionar proyectos con eficacia? En base a tu experiencia, ¿quién sale más beneficiado con este tipo de contratos? ¿el cliente o el proveedor? ¿propondrías algún otro tipo de contrato? No quiero generalizar. El modelo en sí mismo no es malo, y se ha empleado con éxito en miles de contratos. La Administración tiene, entre otras funciones, que administrar el dinero público con criterios de austeridad, control, eficacia... (lo sé, hoy en día no se lo cree nadie). Y la forma simple es poner un tope a ese gasto/inversión (la contabili72

Entrevista a Javier Zaya Martín

www.proiectus.es

Número 3, Noviembre 2014

dad pública es rígida, tienen que realizar las correspondientes Reservas de Crédito por el importe máximo de licitación en tiempo de pliego/oferta, la Aceptación del Gasto por el precio de licitación, la Disposición de Efectivo y la Ordenación de Pago en cada hito facturable...). Hay que tener en cuenta, además, que antes de aceptar la factura del proveedor, el Director Funcional y/o Técnico tienen que presentar una memoria descriptiva de los trabajos realizados. Si no están debidamente capacitados para ello, lo más fácil es tirar de checklist (el PPT), y decir «de los entregables asociados a este hito, ¿están todos?¿falta alguno?» y emitir su «memoria» en base a eso, sin valorar el esfuerzo, el posible adelanto de tareas, las decisiones/replanificaciones/repriorizaciones acordadas, etc.

Como ya nos contó Mike Griffiths en el número anterior, en UK fue necesario replantear nuevos modelos de contrato desde cero. Desconozco qué medidas similares al respecto se están tomando en España. En todo caso, las metodologías Ágiles nos permiten contemplar diferentes escenarios (plazo de ejecución fijo, alcance fijo o presupuesto fijo). Según lo que más interese al cliente en cada contrato concreto, así debería gestionarse la contratación del proyecto. Por otra parte, los aspectos legales y estructurales de los contratos «ágiles» deberían ser los mismos que para contratos de servicios de desarrollo «tradicionales». La diferencia clave está en el enfoque y entendimiento de los procesos operacionales y el delivery de los proyectos, y cómo casarlos con los aspectos contractuales. Un enfoque ágil permite el delivery incremental y rápido de los entregables del proyecto, así como la toma de decisiones colaborativa entre las partes (eliminando o aligerando responsabilidades legales, garantías...). El éxito de un proyecto no es consecuencia de lo bueno o malo que es el contrato, sino de las relaciones de éxito establecidas entre las partes, basadas en la colaboración, transparencia y confianza. Los contratos reflejan lo que la gente espera, sus posibles miedos y las actuaciones y contingencias para evitarlos. Por todo esto, un contrato «ágil»

En el contexto actual de contratos de servicio de desarrollo e implantación de soluciones software para las Administraciones públicas ¿es adecuado? Puede ser. ¿Es EL MÁS adecuado? Diría que no. Y, mayoritariamente, el perjudicado es la empresa proveedora, no el cliente. En muchos proyectos la experiencia nos dice que vamos directamente a sufrir, a sudar sangre, si queremos cumplir con los hitos de facturación tal cual están. Y el cliente es juez y parte. Él decide cuándo considera cumplido un hito, cuando paga, cuando hace la vista gorda y cuando no. 73

www.proiectus.es

Número 3, Noviembre 2014

debería contener mecanismos que soporten y fomenten el establecimiento de esas relaciones de colaboración, transparencia y confianza, primando la colaboración entre las partes sobre la negociación contractual.

propio cliente, y gestionado bien sus expectativas (comunicando adecuadamente el avance, la situación y los riesgos del proyecto) minimizaremos cualquier posible insatisfacción con respecto al producto resultado del proyecto. Al cliente no le quedará otra opción que responsabilizarse de las decisiones tomadas, en las que habrá participado de manera activa (por eso decía antes que las metodologías ágiles, al exigir una mayor implicación del cliente, ayudan a gestionar las expectativa y mejorar la gestión del cambio).

6. ¿Qué consejos podrías darnos para gestionar los conflictos que surgen con los clientes cuando éstos no está satisfechos con el producto resultado del proyecto? ¿y para gestionar los conflictos que puedan surgir en el seno de nuestro propio equipo? La “receta” es la misma en ambos casos: Comunicación, Comunicación, Comunicación.

Y, con respecto a los conflictos internos, debemos estar siempre atentos, “leyendo” el ambiente. Como Directores de Proyecto, somos facilitadores, somos coaches/ mentores, debemos saber cómo gestionar personas, conociendo sus fortalezas, sus intereses, sus aspiraciones... Debemos comunicar. Debemos ser justos. Y debemos crear las condiciones para que cualquier conflicto se resuelva antes de que impacte en la ejecución del proyecto. En muchos casos, los conflictos surgen por gestionar los proyectos “con el mando a distancia”, sin implicarnos en y con el equipo. Y es nuestra responsabilidad.

Debemos ser conscientes de que el proyecto nos va a ocupar los próximos n meses de nuestra vida, que vamos a tener que crear (o reforzar) relaciones con múltiples personas, con objetivos e intereses dispares (y a veces en conflicto). Debemos intentar basar esas relaciones en la terna que ya mencioné antes: transparencia, confianza y colaboración. Y debemos intentar alinear los intereses de todas las partes, gestionando adecuadamente sus expectativas, sabiendo que no siempre será posible.

No es fácil gestionar un equipo de personas y hacerlo funcionar de forma coordinada. Requiere cierta habilidad y pararte a

Si hemos tenido éxito implicando a las partes en la toma de decisión, incluyendo al 74

Entrevista a Javier Zaya Martín

www.proiectus.es

Número 3, Noviembre 2014

conocerlos. Soy un defensor convencido del Efecto Pigmalión, que viene a decir algo así como “cuanto mayores son las expectativas que pones sobre la gente, mejor se desempeñan”. Y por eso, en la medida de lo posible, intento aplicar un liderazgo “de apoyo” (supportive leadership):

• Motivándolos para que permanezcan centrados en el momento y proyecto presente, no preocupándose por acontecimientos negativos del pasado. 7. Por orden de prioridad, ¿qué áreas de conocimiento del PMBOK® (Project Management Body of Knowledge) encierran mayor dificultad a la hora de dirigir proyectos para la Administración Pública?

• Reconociendo que todos los miembros de mi equipo (y yo mismo) tenemos la capacidad o el potencial para incrementar nuestro rendimiento.

Lo tengo claro: • Gestión del Alcance: que complica/afecta la Gestión del Coste y Calendario del Proyecto.

• Estableciendo objetivos de alto rendimiento. • Reforzando positivamente el trabajo bien hecho.

• Gestión de los Stakeholders: tendemos a olvidar al usuario final, o al Ciudadano. Por otra parte, muchas veces el Sponsor/Product Owner no está o no aparece cuando se le necesita.

• Proporcionando feedback frecuentemente, transmitiendo el convencimiento acerca de nuestra habilidad/capacidad para completar las tareas asignadas.

• Gestión de Riesgos: es crucial hacer una correcta identificación y estimación del impacto/coste de los riesgos del proyecto.

• Dando a los miembros del equipo la oportunidad de participar en tareas o proyectos que supongan un desafío cada vez mayor.

8. Fuiste uno de los primeros PMP® (Project Management Professional) certificados en España, ¿qué te ha aportado la certificación a lo largo de tu carrera profesional?

• Proporcionando a los miembros del equipo los inputs, la información y los recursos necesarios para lograr sus objetivos. 75

www.proiectus.es

Número 3, Noviembre 2014

Quitando lo que me ha supuesto en términos de “crecimiento profesional personal” (la conciencia de mi propia valía, refrendada por una certificación internacional de reconocido prestigio), en España, honestamente, muy poco. Es cierto que desde principios del 2005 hasta ahora la situación ha mejorado muchísimo, y ya se nos reconoce cierto “saber”, cierta experiencia. Incluso se nos considera SME (Subject Matter Experts) en ciertos ámbitos. Pero ya digo, más allá del reconocimiento por parte de otros compañeros de profesión, que conocen y comparten la trastienda de la Dirección de Proyectos, poco o nada. Siguen siendo muy pocos los clientes que exigen que los Directores de Proyecto estén certificados. Tampoco supuso ningún incremento salarial (como reflejan muchas de las estadísticas del PMI) ni mejora de mi empleabilidad. Sé que durante un tiempo (fui de la “primera promoción” de PMP’s de INDRA, “los primeros 25”), mi CV se incluyó en diversas licitaciones internacionales en las que participó mi empresa, precisamente por ser un criterio a valorar, pero no pasó de ahí. Si finalmente resultó adjudicataria de alguno de aquellos proyectos, yo no lo dirigí.

empleo extranjeros prácticamente desde el año 2000. Tan pronto lo actualicé con mi flamante PMP hubo un incremento considerable en las ofertas que me llegaban, sobre todo de USA y UK. Y algunas eran económicamente muy atractivas. Por lo que sigo manteniendo la certificación. Voy a por la tercera renovación 2015-2018 (ya tengo los PDU’s necesarios) y tan ilusionado como el primer día. 9. Cambiando de tercio, no queremos desaprovechar la oportunidad para preguntarte sobre cómo se valora la profesión del director de proyectos en Nueva Zelanda, ¿debemos hacer las maletas y seguir tus pasos? Mi experiencia en NZ es aún muy limitada, aunque, por lo que he podido ver, se nos reconoce y valora muy positivamente (de hecho, estamos en demanda). Copio algunos párrafos del documento titulado “The Future of Project Management Qualifications in New Zealand” (adjunto): “NZQA (NZ Qualification Authority) invited the Project Management Institute of New Zealand (PMINZ) and the New Zealand Industry Training Organisation (the NZ ITO), as national bodies representing project management in New Zealand, to make a submis-

Fuera de España, por contra, sí que percibí claramente un cambio. Como muchos otros, he tenido mi CV publicado en portales de 76

Entrevista a Javier Zaya Martín

www.proiectus.es

Número 3, Noviembre 2014

sion to NZQA about the need for specialist project management qualifications on the NZQF (NZ Qualification Framework)

• Findings indicate that 70 percent of New Zealand companies have experienced at least one project failure in the past 12 months.

[...] about the strategic importance of project management for New Zealand now and in the future; the current project management capability of New Zealand organisations across the board; availability and accessibility of project management education and training; and the place of New Zealand project management qualifications alongside industry credentials such as the PMP, CAPM and PRINCE2.

• Results show that projects undertaken by New Zealand companies often perform poorly in at least one of the following areas – lack of timely delivery, cost (project runs over budget), or inability to achieve the stated deliverables. • Over 50 percent of respondents stated that they do not consistently achieve stated project deliverables.

[...]We believe that building capability in project management is strategically highly important, if not critical, to New Zealand’s continued growth and prosperity; and that there is a specific role for qualifications in complementing industry credentials.”

• Nearly 60 percent of New Zealand companies fail to consistently align their projects with corporate strategy. • In the past 12 months, 98 percent of those surveyed completed [fewer] than five projects; however, the amount of money spent is significant with 44 percent of companies spending more than $15 million on their projects over this period.

Las razones, según un informe de KPMG realizado en 2012, se resumen en: • 60 percent of New Zealand companies are failing to measure the return on their investments in projects.

• 68 percent of companies do not always have an effective Sponsor to provide clear direction for the project or to escalate problems when necessary.

• More than a quarter of organisations surveyed do not undertake any form of strategic review to track the benefits realised by the business.

“…I absolutely agree that project manage77

www.proiectus.es

Número 3, Noviembre 2014

ment qualifications are strategically important on a national basis, and the results this year show that a lack of maturity in terms of managing projects is having a significant impact on delivering agreed outcomes. This is especially noticeable in the Public Sector where projects are se-scoped to meet timeframes and budgets and in the Financial Sector, where projects incur significant cost overruns.”

nal”, de forma que sin contactos o experiencia local (incluidas actividades de voluntariado), es muy complicado acceder a esos puestos. Por otra parte, está la barrera del idioma que dificulta aún más el tema según qué puestos y el grado de interacción con stakeholders a alto nivel requerido. Muchas ofertas exigen certificación en dirección de proyectos (PMI o PRINCE2), además de años de experiencia dirigiendo proyectos de envergadura (de varios millones de $), así que la certificación me ha permitido optar con confianza a esos puestos, quedando en algunos casos seleccionado para la shortlist final (aunque sin éxito, de momento).

Así que, por lo pronto, y hasta que yo ponga remedio ;) hay campo de sobra para que os liéis la manta a la cabeza y os vengáis para NZ. 10. ¿De qué manera te ha ayudado estar certificado PMP® (Project Management Professional) a la hora de buscar trabajo en Nueva Zelanda? ¿ya te has unido al capítulo PMI® (Project Management Institute) de Nueva Zelanda?

11. Muchas gracias Javier por tu tiempo. Te deseamos mucha suerte en tu nuevo proyecto profesional. Que sepáis que tenéis un seguidor de vuestra revista aquí en las antípodas. Cualquier cosa que necesitéis, mía o del Capítulo de NZ, no dudéis en pedírmela. Un abrazo.

Sí, ya me he unido al Capítulo de NZ (http:// www.pmi.org.nz), concretamente a la subbranch de Auckland. Con respecto a la búsqueda de trabajo, sigo en ello. Está siendo más complicado de lo que en un momento pensé, pero no por falta de puestos, como ya os he comentado, sino por cómo opera el mercado laboral local. En muchos aspectos todavía es algo “tradicio78

www.proiectus.es

Número 3, Noviembre 2014

ENTIDADES COLABORADORAS

Esta publicación está disponible bajo Licencia Creative Commons Atribución-NoComercial-CompartirIgual 3.0 Unported (CC BY-SA 3.0). Usted es libre de compartir, copiar, distribuir, y comunicar públicamente la obra y hacer obras derivadas; bajo las condiciones de reconocer los créditos de la obra de la manera especificada por el autor o el licenciante (pero no de una manera que sugiera que tiene su apoyo o que apoyan el uso que hace de su obra), y si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Texto de reconocimiento de los créditos de la obra Se ha de indicar la fuente de la información (www.proiectus.es) y el nombre y apellidos del autor del artículo referenciado. ISSN 2340-9363 Lugar de Edición: Las Palmas de Gran Canaria Empresa Editora: IVAN TEJERA PROIECTUS S.L.U. URL:

http://www.proiectus.es revista@proiectus.es

E-mail: