Revista Proiectus nº 3

ww

w.p

roie

ctus

.es

Núm

ero

3, O

ctub

re 2

014 DIRECCIÓN DE PROYECTOS

ENTREvISTa a JavIER ZaYa MaRTíN, DIRECTOR DE PROYECTOS IT GESTIONaNDO La DISTaNCIa PaRa EL ÉXITO DE LOS PROYECTOSEL PROYECTO CMMI, UN PROYECTO DE MEJORa ORGaNIZaCIONaL

DEUDa TÉCNICa: LOS COCODRILOS SaLEN DE La aLCaNTaRILLaMETODOLOGIa PaRa La GESTIÓN DE LECCIONES aPRENDIDaS

ESTRaTEGIa PaRa ENFRENTaRSE aL EXaMEN PMPISSN 2340-9363

DE CONSULTORía TECNOLÓGICa

www.proiectus.es

DIRECCIÓN DE LA REVISTAIván Samuel Tejera Santana

[email protected]

EQUIPO EDITORIAL

ITPROIECTUSwww.proiectus.es

ASESORAMIENTO LEGALJavier Rodríguez Batllori Laffitte

MAQUETACIÓN Y EDICIÓNRogelio Suárez Tejera

COLABORADORESFernando Manero MartínezCarlos Javier Pérez EscobarAntonio Pedro Dorta Alonso

Jose Selaya GómezMike Griffiths

María Pilar Tarriño SuárezMario Coquillat de Travesedo

Jose Barato ArroyoAntonio Martel Rodríguez

Vicente R. Merchán RodríguezJavier Zaya Martín

mailto:[email protected]

www.proiectus.es

3

Director revista PROIECTUSIván S. Tejera Santana

CARTA DEL DIRECTOR

Bienvenid@s a este tercer número de la revista PROIECTUS, publicación MADE IN CANARIAS desarrollada por y para profesiona-les vinculados a la Dirección de Proyectos.

Confeccionar una publicación gratuita como esta supone un gran es-fuerzo para todos los que participamos de forma voluntaria en su ela-boración. Por este motivo, nuestra mayor motivación para continuar impulsándola está en la satisfacción de nuestros lectores.

El verdadero valor de la revista radica en ser capaces de aunar en un mismo lugar el conocimiento y la experiencia de otros directores de proyectos disgregados en distintas partes del mundo.

En este número hemos querido introducir nuevos enfoques de gestión de proyectos y mejora de procesos en las organizaciones, lo que ha permitido dar la posibilidad de participar a un mayor número de profesionales.

Si en el anterior número pudimos entrevistar a Mike Griffiths, miembro del Comité de Dirección encargado de definir las habilidades, herramientas y técnicas que conforman los contenidos del examen PMI-ACP® (Agile Certified Practitioner), en este número hemos querido acercarnos a la gestión de proyectos en la Administración Pública, entrevistando a Javier Zaya Martín, Senior IT Project Manager con amplia experiencia en este sector, y a quién desde aquí agradecemos su tiempo y colaboración.

Tod@s los que formamos el equipo PROIECTUS esperamos que este número os resulte igual de inte-resante que el anterior, a fin de cuentas, si la revista existe es gracias a vosotros.

La única fuente de conocimiento es la experiencia (Albert Einstein).

http://www.proiectus.es


http://twitter.com/proiectus

http://es.linkedin.com/in/ivantejera

4

Número 3, Noviembre 2014www.proiectus.es

ÍNDICE

Gestión de proyectos internacionalesFernando Manero Martínez

cómo diriGir proyectos cmmiCarlos Javier Pérez Escobar, CMMI Instructor

diriGiendo proyectos para implantar erpAntonio Pedro Dorta Alonso, PMP®

itil y la dirección de proyectosJose Selaya Gómez, ITIL®, PMI-ACP®, PRINCE2®

aGile errorsMike Griffiths, PMP®, PMI-ACP®

deuda técnicaMaría Pilar Tarriño Suárez

metodoloGia de lecciones aprendidas basada en metodoloGía de Gestión de riesGosMario Coquillat de Travesedo, PMP®, PMI-RMP®

una estrateGia para enfrentarse al examen pmpJose Barato Arroyo, PMP®, PMI-ACP®

el rol del director de proyectos en el clienteAntonio Martel Rodríguez, PSM® I

Gestión de calidad en proyectos de consultoríaVicente Merchán Rodríguez, ITIL®

entrevista: d. Javier Zaya martínJavier Zaya Martín, PMP®, Senior IT Project Manager

5

13

20

29

33

38

44

53

57

61

65

www.proiectus.es

http://es.linkedin.com/in/fernandomanero

http://mx.linkedin.com/in/cjperez7

http://es.linkedin.com/in/tonidorta

http://es.linkedin.com/in/p3mconsultant

FreeDigitalPhotos.net

http://es.linkedin.com/pub/pilar-tarri%C3%B1o/61/859/497

http://es.linkedin.com/in/mariocoquillat

http://es.linkedin.com/in/josebarato/es

http://es.linkedin.com/in/antoniomartel

http://ec.linkedin.com/in/vicentemerchan

http://es.linkedin.com/pub/javier-zaya/1/588/566

5


ÍNDICEGESTIONANDO 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 metodo-logías y mejores prácticas ampliamente re-conocidas y en constante evolución (dentro de las cuales la Guía del PMBOK® es refe-rente). Es arte por las habilidades necesa-rias para llegar a ser buen jefe de proyecto: un líder capaz de inspirar y gestionar con eficacia las situaciones y las personas.

Ser jefe de proyecto requiere fortaleza para afrontar decisiones difíciles y humildad para asumir los errores y aprender de ellos, se trata de un proceso de mejora continua en el que salir de la zona de confort y asu-mir nuevos retos es indispensable para se-guir progresando.

Ese fue el motivo por el cual acepté el reto de liderar un proyecto internacional. Un trabajo que terminó resultando mucho más duro y absorbente de lo previsto, del que

me llevo multitud de lecciones que me gus-taría compartir con los lectores de PrOIEC-TUS.

MEET ThE PROjECT

La educación digital es un área que me apasiona, siento una profunda curiosidad por los modelos educativos del futuro. Es un tema sobre el que he escrito varios artículos y entrevistas, cubriendo desde plataformas educativas digitales hasta los novedosos MOOC (massive open online courses).

Cuando el cliente entró en contacto conmi-go ya conocía su producto: una plataforma digital multi-plataforma líder en el mercado educativo nacional. Al parecer, una gran empresa estadounidense les había con-tratado para desarrollar una adaptación a medida de su plataforma. Un proyecto aparentemente sencillo, de pocos meses, en el cual la plataforma se desplegaría en el cliente tras un lavado de cara a nivel de

GESTIONANDO LA DISTANCIA PARA EL éxITO DE LOS PROYECTOS

Fernando Manero MarTÍneZIngeniero de Telecomunicación por la ULPGC, Master en Digital Business por ICEMD-ESIC (Madrid) y fundador de Alkeno, donde dirige, diseña e implementa soluciones de digi-talización con enfoque analítico en todos los ámbitos de la empresa desde la transfor-mación digital interna (estrategia, procesos, proyectos, personas y herramientas) hasta el comercio electrónico y el marketing online, siempre con el objetivo de maximizar de forma demostrable el retorno de las inversiones realizadas por sus clientes.

www.proiectus.es

6


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

Sin embargo, la situación estaba lejos de estar controlada: dos meses tras el kic-koff, a dos meses de la finalización, apenas había avances. El alcance se había dispara-do, no tenían capacidad para seguir aten-diendo a su negocio en España y además gestionar el proyecto. Y el cliente en EEUU empezaba a impacientarse. Les hacía falta un jefe de proyecto.

BáSICOS DE GESTIÓN DE PROYECTOS

De todos los aprendizajes del proyecto, muchos son comunes a cualquier desarro-llo de software y nada tienen que ver con que sea internacional. Nunca está de más recordarlos.

No escatimar tiempo en el análisis inicial y en la definición de los requerimientosHay mucha sabiduría en el dicho “cada hora que se dedica a planificar ahorra diez horas en la ejecución”. Un requerimiento aparen-temente sencillo puede causar estragos en el proyecto, especialmente si tiene impacto en código o modelos de datos que llevan años escritos.

En nuestro caso unos cuantos detalles apa-

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

Otra vertiente de este error es asumir depen-dencias con terceros sin auditar previamen-te el estado de dichos elementos e incluir salvaguardas por si acaso no cumplen las expectativas. La plataforma deseada tenía una dependencia con un servicio web de otra empresa del grupo del cliente final, uno que en teoría era estable y estaba finalizado. En la práctica, la empresa responsable ha-bía cesado de ofrecer soporte porque lleva-ban meses trabajando en una nueva versión de la API. Más retrasos, más cambios, más frustración para el equipo.

Optimizar la cadena de mando sin dejar de controlar el alcanceLos stakeholders en cada proyecto son los que son, pero unos protocolos claros pue-den obrar milagros. ¿Qué se escala, cuán-do y a quién? Sin herir sensibilidades, pero con firmeza, si alguien no es nece-sario en un comité de seguimiento que no acuda.

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

www.proiectus.es

7



que dediquen tiempo al proyecto o, si no es posible, que deleguen en alguien adecuado. De lo contrario se corre un riesgo de que no haya respuesta rápi-da cuando haya que tomar decisiones, que se aluda a las prisas y las agendas apretadas, y que al final los cambios dejen de analizarse con lupa o de vali-darse en firme.

Nunca infravalorar el trabajo del jefe de proyectosUn proyecto necesita un líder y respon-sable, un interlocutor cualificado para el cliente que cuente con la visión global del proyecto y que entienda del negocio. En demasiadas ocasiones se pretende dele-gar dichas labores en el equipo de trabajo, lo cual no solo no funciona (lo cual implica retrasos, sobrecostes, etc.), sino que so-mete al equipo a un esfuerzo para el que no están formados ni tienen experiencia, derivando en frustración y malestar.

Conocer al cliente y sus circunstanciasLas empresas grandes suelen ser más for-males que las pequeñas, y en España has-ta los más serios parecemos caóticos a los ojos de los anglosajones. Sé precavido cuando entres en proyectos con empresas de fuera o más grandes que tú, que no te ahoguen sus procesos, prevé un crecimien-

to exponencial de las necesidades de ges-tión.

Además, resulta vital dejar claro de inicio cuál es tu capacidad para satisfacer sus necesi-dades, que sean conscientes de hasta qué punto puedes o no cumplir con sus procesos en materia de entornos, despliegues, infor-mes, auditorías, control de accesos, seguri-dad, etc. Esto fue especialmente frustrante en el proyecto, porque una respuesta que uno nunca quiere dar (y que el cliente final difícil-mente va a entender) es “le entendemos, y ojalá tuviésemos los recursos para hacer las cosas así de bien, pero somos una pyme nos arruinaríamos de seguir sus procesos de despliegue y auditorías”.

Vigilar con cuidado el rendimientoOptimizar las prestaciones de una aplicación no es fácil. Menos aun cuando desarrollo es híbrido (nativo y web), multi-dispositivo y está dirigido a un despliegue internacional. Sal de los entornos controlados y lanza una beta en equipos y entornos reales cuanto antes para tomar datos, aprender y poder corregir a tiempo (cuanto antes aparezcan las sorpresas, mejor).

Otro factor relevante para el rendimiento, con un gran impacto en el proyecto, fue la interfaz gráfica. Lo que en principio iba a ser un mero cambio de plantillas CSS re-

www.proiectus.es

8


sultó en un diseño ambicioso, con múltiples capas solapadas y pesadas animaciones en HTML5 (todo ello desarrollado por una agencia externa, sin nuestro input). Los pro-blemas de rendimiento no se hicieron pa-tentes de inicio en los equipos de desarrollo y prueba (ordenadores portátiles y tablets modernos), sino cuando el equipo de la In-dia empezó a probar con tablets de bajas prestaciones. Ya era demasiado tarde y costoso realizar un rediseño, tuvimos que eliminar las animaciones en las plataformas más afectadas.

EL fACTOR DISTANCIA

Llegamos al punto álgido: ¿qué proble-

mas, situaciones y curiosidades concretas puede uno esperar al realizar un proyecto internacional?

En primer lugar, es necesario hacer una composición espacio-temporal del proyec-to:

• EnEstados Unidos (UTC-4)elclientefinal.

• En España (UTC+2) el desarrollador(micliente).

• EnInglaterra (UTC+1)elequipodeso-portefuncional.

• En la India (UTC+5½) el equipo depruebas.

Fuente: WikimediaCommonsAutor: TimeZonesBoy

www.proiectus.es

http://commons.wikimedia.org/wiki/Main_Page

9



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

Coordinando en la distanciaEl proyecto se gestionaba en dos comités de seguimiento semanales, uno funcional los lunes y otro tecnológico los miércoles. Correspondía al jefe de proyecto del cliente en EEUU liderar las reuniones y coordinar al resto de países, todo ello escrupulosamen-te gestionado: el orden del día se emitía con 24 horas de antelación, y el acta se publi-caba en las 12 horas siguientes. La hora de inicio era estricta, el margen de cortesía de 5 minutos y la duración en la mayoría de los casos inferior a lo previsto (rara vez alcanza-ba la media hora planificada).

La diferencia horaria daba poco lugar a la flexibilidad: las reuniones técnicas empe-zaban por defecto a las 16:00 en España, de forma que en EEUU ya fuese horario laboral (10:00) y en la India estuviesen apu-rando su hora de salida (19:30).

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

plicados, constantemente) los siguientes detalles:

• Los formatos de fecha y horaenelmundo, y especialmente en EEUU (por

ejemplo,tenerclaroquelas12a.m.del

12/31/2014eslahoradelasuvasdefin

deaño).

• Los respectivoscalendarios labora-bles.ParalosnorteamericanoselJuly

4thessagrado,ysino lesavisasvan

aesperarquerespondasemailselDía

delaConstitución.

• Elcalvariodeloshusos horarios,tensiempreunconvertidoramanoymen-

talízatealacantidaddenomenclaturas

yexcepcionesexistentes,inclusoden-

trodeunmismopaís.

• Loscambios de hora,quecadapaíshaceasumanera.Porejemplo,elcam-

bioahorariodeinviernoeselúltimodo-

mingodeoctubreenEspaña,elprimer

domingodenoviembreenEEUUynun-

caenlaIndia(allínoserealizacambioa

horariodeverano).Anosotrosnosarrui-

nóvariasconferenciasenlasemanadel

cambiodehora,tenloencuenta.

Gritando a los que están más lejosLa distancia debilita los corazones, y se lo pone complicado al jefe de proyectos. No quiero decir que la distancia sea causa di-recta de problemas, pero va a introducir sí o

www.proiectus.es

10


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

• El idioma es un problema.Siconfre-cuenciaescomplicadoentenderseenel

idiomamaternodeuno,hacerlodeforma

eficaz y eficiente con ingleses, nortea-

mericanoseindiosrequiereeldoblede

paciencia y esfuerzo. Las barreras cul-

turalesestánahí y habráquegestionar

susdañoscolaterales:ofensas,enfados,

frustracionesypequeñascrisisfrutosde

malosentendidos.Conprofesionalidad

ypacienciatodosesoluciona.

• Las comunicaciones son una ba-rrera. Email, videoconferencia, te-

léfono, VoIP, chat… nada sustituye

unareuniónpresencial.Avecesson

verdaderamentenecesarias,perono

sonposibles.

• Internet es rápida, pero el mundo enorme.TususuariosenColombia,

ChinaylaIndianovanaestarsatis-

fechos con el nivel de servicio que

presta tu servidor en Alemania, por

potentequesea.Abrazalanube,di-

versificatusservidoresyacércalosa

losusuarios.

• El factor China.Elsistemaoperati-

vomásutilizadoenelgiganteoriental

esWindowsXP.Esmás,allí Internet

Explorer6eselnavegadoroficialdel

clientefinal(algoconloquenocon-

tábamosnosotros,yalparecertam-

pocodesdeEEUU).Unmazazopara

todos.

• Los formatos de fechas y horas causarán bugs.Es leydevida,pare-cealgosuperadoperohastaAppletiene

errores en el calendario de iOS. Bús-

calossintregua,apareceránysonmuy

complicadosdecazar.¿Unejemplo?Un

serviciowebcuyaautenticaciónfallabaa

vecesporquelaslibreríasenunsistema

yenotrointerpretabanunmismoformato

de hora de forma diferente (1:18 no es

01:18,ojoconelrellenadodecerosyes-

pacios).

La dedicación y la productividadUno de los aprendizajes clave que me llevo es la capacidad de dimensionar el esfuer-zo necesario para gestionar con diligencia un proyecto de estas características. En mi caso ser el nodo entre tres continentes me transformaba en cuello de botella de las comunicaciones entre Madrid, el reino Unido, Estados Unidos y la India.

Imaginad un día malo como gestor de proyectos. Uno de esos en los que nadie sabe muy bien por qué un stakeholder de peso decide mirar hacia el proyec-to y entrar en pánico. O un día en que

www.proiectus.es

11



surge fallo grave de sincronización entre la plataforma y el backend en medio de un piloto clave. Son las 15:00 en EEUU, las 21:00 en España. ¿respondes o no? Claro que sí.

En otras palabras, un proyecto interna-cional que abarca medio planeta requie-re atención 12 horas al día. ¿A tiempo completo? No necesariamente (depen-de de la magnitud del proyecto y de la fase en la que se encuentre, claro). En mi caso, difícilmente fui capaz de dedicar menos de tres horas al día, una por la mañana, otra después de comer y otra bien entrada la tarde. Ni que decir tiene que este tipo de dedicación penaliza a cualquiera cuyo trabajo no sea gestionar proyectos a tiempo completo, la multita-rea impacta en la productividad y en la capacidad para afrontar otros proyectos. Pero es imprescindible si no se desea penalizar el proyecto completo, un retra-so de media hora en la gestión un asunto puede retrasar varios días su solución.

CONCLUSIONES

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

y varias horas por delante (o por detrás) en el calendario, el gestor pierde el feeling del proyecto y las personas que lo forman, se nubla su visión general, pierde capacidad de identificar y anticiparse a los riesgos.

Por supuesto, todo esto se complica si te incorporas a un proyecto ya comen-zado en el que los requerimientos fun-cionales y técnicos no están escritos en piedra. No debería pasar, pero pasa, es mejor estar preparado: intentar ser aún más estrictos con las metodologías, imponer la cordura con un control de cambios que involucre al project owner y al sponsor, vigilar las expectativas del cliente (¡tanto de alcance como de pro-cesos!), etc.

¿Y el factor internacional? Exigirá del don de la ubicuidad: estar en todo, a todas horas, para mantener los engra-najes girando y desbloquear asuntos ASAP. Suplir las barreras del idioma y la comunicación con más interacción, más esfuerzo y mejor predisposición si cabe. Imprescindible también será la investi-gación, no dar por hecho que en otros países las personas y las tecnologías son como en casa.

Para cerrar, compartiré una cifra repre-sentativa: el esfuerzo final del proyecto

www.proiectus.es

12


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

Nadie dijo que estrenarse en gestión de proyectos internacionales fuese fácil.

www.proiectus.es

13


EL PROYECTO CMMI, UN PROYECTO DE MEjORA ORGANIzACIONAL

EL PROYECTO CMMI, UN PROYECTO DE MEjORA ORGANIzACIONALGeneralmente un proyecto es entendi-do como el conjunto de actividades que realizan los individuos para alcanzar un objetivo conforme a un plan, delimitado en un tiempo para generar determinados resultados con los recursos, infraestruc-tura y el presupuesto establecido. Los proyectos de mejora de procesos, en los que se puede considerar la adopción de las prácticas de CMMI consideran los mismos componentes y debe gestio-narse de igual forma. Aquí se presentan consideraciones generales para gestio-nar los recursos humanos y las primeras actividades para arrancar un proyecto de mejora en la organización.

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

de se incorporan las prácticas definidas en el modelo CMMI. Dependiendo del al-cance y necesidades de la organización se requerirán determinadas considera-ciones que pueden afectar el contexto del proyecto.

Los proyectos de mejora de procesos suelen ser más complejos, a diferencia de otros proyectos, porque no crean u ofrecen “algo” sino que transforman la forma en que se hacen u ofrecen los productos o servicios. Mayormente se relacionan con entidades abstractas y eso dificulta los resultados como se re-fleja en Ilustración 1. Dificultades en la gestión de proyectos de mejora . El enfoque del proyecto es mejorar y eso, por su naturaleza, es extremadamente complicado.

Carlos Javier PéreZ esCobarInstructor 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.

www.proiectus.es

14


¿Qué es CMMI?

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

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

El enfoque del modelo permite evolucio-nar desde un proceso en crisis a un pro-ceso controlado, estandarizado, medido y optimizado que sienta las bases de la mejora continua y permite a la organiza-ción adoptar nuevas prácticas sobre un proceso estable que está institucionali-zado o entendido y asimilado.

El elemento central en que se organizan las prácticas en el modelo lo constituyen las áreas de proceso. Está estructurado para facilitar su uso en componentes que definen la forma y modo de aplicarlo, considerando los que son obligatorios, sugeridos o el ma-terial informativo en las áreas de proceso. En general el documento se puede revisar en función de metas, prácticas y subprácti-cas con el resto del material informativo.

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

• Desarrolloymantenimientodeproductos

yservicios(CMMIDEV),

• Adquisición de productos y servicios

(CMMIACQ)y

• Establecimiento,entregaygestióndelos

servicios(CMMISVC).

El modelo considera dos enfoques o rutas para adoptar las mejoras y medir el nivel en que han evolucionado que se conocen como representaciones. En una forma se consideran áreas de proceso de manera individual y se califican en niveles de ca-pacidad de acuerdo con la representación continua. El otro enfoque considera un con-junto preestablecido de áreas de proceso

www.proiectus.es

15



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

LOS RECURSOS hUMANOS EN EL PROYECTO DE MEjORA

Un proyecto de mejora requiere que la gente cambie su comportamiento, es un cambio organizacional. Para salir del esta-do actual es importante que la gente esté receptiva, que acepte que es necesario y que no haga resistencia al cambio. Para avanzar en la mejora, se deben proponer soluciones para salir de los problemas existentes y fortalecer los factores que promueven el cambio y suprimen las ba-rreras. Al final, se requiere que los cambios formen parte de la forma de operación en la Organización de manera perma-nente. Un proceso mejor debe traducirse en más ganancia y una mejor operación. Los procesos son valiosos cuando descri-ben la forma en que opera la Organización y además, son aceptadas por el personal. Por ello es fundamental que: sean útiles para diferentes tipos de proyectos dentro de la Organización, presentados en un lenguaje sencillo y gráfico siempre que sea posible, y basados en propuestas de me-jora comunicadas, entendidas, acordadas y respaldadas que permitan el desarrollo, publicación y mantenimiento continuo.

Es importante definir objetivos, planear in-dicadores para monitorearlos e integrarlo en el plan de mejora. Cada mejora debe contribuir a perfeccionar los objetivos del negocio y motivar al personal a modificar su comportamiento. Para alcanzar esos ob-jetivos hay que establecer acciones como parte del plan de mejora, el cual es integra-do en las actividades de la organización. El proyecto de mejora debe ejecutarse con la misma persistencia que la opera-ción diaria. Para seguir el proyecto de mejora, aún en situaciones difíciles en la Organización, es importante demostrar a la gente que la mejora es esencial para la visión, objetivos de negocio y satisfacción del cliente. El personal necesita motivación para el cambio y evitar así, consecuencias indeseadas. Como beneficios se obtienen incremento de la eficiencia, mejor calidad del producto a través de mejores proce-sos, confianza del cliente por los altos ni-veles de capacidad, ventajas competitivas para el negocio y empleados comprometi-dos con la mejora continua.

RUTA hACIA LA MEjORA

Siempre que iniciamos un proyecto, ac-tividad o cualquier cosa que estemos in-tentando comenzar, la primera pregunta que nos asalta es ¿por dónde empiezo? Definitivamente para iniciar un proyecto de

www.proiectus.es

16


mejora, necesitamos saber cómo están las prácticas de la organización y a dónde queremos llegar, para establecer accio-nes y saber cómo lo vamos a solucionar. Es imprescindible tener una necesidad real de cambio, identificar que algo no está funcionando o no puede continuar como está para lograr un motivador con-creto y objetivo. Lo recomendable es ini-ciar con una revisión, auditoría o evaluación de lo que se tiene y lo que falta por hacer. El modelo CMMI puede funcionar como un checklist de buenas prácticas pero no podemos perder de vista lo que real-mente es necesario para la organización. También es importante saber a dónde que-remos llegar, cuales son las metas, motiva-dores y el nivel de compromiso de la direc-ción de la organización con este esfuerzo. Es una inversión de recursos en todo sen-tido que no podemos abandonar a mitad de camino por falta de visión. Es elemental tomar indicadores de la situación actual en relación a los objetivos de mejora y poder demostrar con los resultados que los be-neficios se están logrando. Adicionalmente

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

En el modelo CMMI el área de proceso de OPF i establece las prácticas requeridas para ejecutar un proyecto de mejora, es con-veniente revisarlas para identificar lo que se debe hacer y apoyarse con el ciclo IDEALii

como hoja de ruta para implementarlas. En la Ilustración 2. Actividades para el inicio del proyecto de mejora se muestran los pasos a seguir para garantizar un arranque efectivo del proyecto.

La parte más “fácil” de todo el proyecto es entender cómo solucionarlo y aplicar el mo-delo como parte de la solución, el proble-ma real es lograr hacerlo. Dejamos como referencia algunas recomendaciones que pueden ser de gran beneficio para lograr el resultado en la Ilustración 3. Consejos para el éxito del proyecto de mejora. En resumen se requiere identificar la necesi-dad del cambio, determinar que se requiere

i Organizational Process Focus es el area de proceso del CMMI que se relaciona con las prácticas del proyec-

to de mejora en la Organización.

ii Initiation – Diagnosis – Executing – Acting - Learning son las etapas del ciclo de mejora definido por el SEI

www.proiectus.es

17



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

proyecto y evaluar la forma en que se alcan-zan los beneficios.

Mullaly2 identifica cinco problemas que son la base de la complejidad y particularidad en la gestión

de proyectos de mejora de procesos

1. Personas. Muchasveceslosquequierenloscambiosenlosprocesosnonecesariamenteson

losqueloejecutan.Sonmuyraraslasocasionesenquelosqueestánoperativamenterealizando

lasactividadesidentificanlanecesidaddecambio,mayormenteloscambiossonimpuestossobre

ellossinestarconvencidosdelanecesidad.

2. Cambio. Unproyectodemejoraimplicalagestióndelcambioycambiarelcomportamientode

laspersonasenparticularesunaactividadmuycompleja.

3. Errores. Losresultadosseobtienenpor“pruebayerror”.Laadopcióndeloscambiosespro-

badoyconbaseenlosresultadosmodificadoparaseguirprobandohastaobtenerunasolución

“óptima”

4. Mediciones. La obtención demedidas e indicadores de resultados es vital para conocer si

realmenteseobtienenmejoresresultados.Debidoaquelosprocesosnoestáncompletamente

entendidosyaplicadoslarecoleccióndeinformaciónpuedesercostosaydifícilenciertaforma.

5. Compromiso. Losprocesosafectan laoperaciónyprecisamente lapresiónpolítica,quepre-

suponeparalosgerentesysupervisoresaceptarquelesdiganloquedebenhaceryquepuede

ponerenjuegosupodereinfluencia,escomplejaparaelequipodemejora.

Ilustración 1. Dificultades en la gestión de proyectos de mejora

www.proiectus.es

18


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

2- Identificarlasnecesidadesdelnegocioylosmotivadoresparalamejora

3- Elaborarlapropuestademejoradeprocesos

4- Apoyoenformaciónydesarrollo

5- Obtenerlaaprobacióndelapropuestainicialdemejoraydelosrecursosparaelproyecto

6- Establecerlainfraestructuraparaelproyectodemejora

7- Evaluarelclimaparaelproyectodemejora

8- Definirlosobjetivosgeneralesdemejora

9- Establecerlosprincipiosqueguíanelproyectodemejora

10-Lanzarelproyecto

Ilustración 2. Actividades para el inicio del proyecto de mejora

• Establecer las expectativas enrelaciónconloqueseesperadelproyecto,porquéesnecesarioyquéesloquedebecambiaromejorar.Estoselementosseconsiderancomopartedelplanestraté-gicodemejoraytienelafunciónprincipaldecomunicaralosinteresados lasbasesdelproyectoylaformaenquedebenconducirsusactividades.

• Determinar y definir claramente la situación actualdelaoperación,locualserátomadocomobaseparadeterminarloscambiosyestablecerlasmedidaseindicadoresquedemostraránlosresul-tadosobtenidos.

• Definir claramente los objetivos a mejorar.Cuálessonlasmetasquesequierenalcanzar,cuá-lessonloselementosquesedebenatenderparalograresasmetasycuálessonlosresultadosqueseesperanalcanzar.Cualquiercambiodeobjetivoimplicacambiosenelalcancedelesfuerzoydebeserdebidamenteevaluado.

• Garantizar el apoyo y patrocinioefectivodelaDirecciónescríticoparaelproyecto,elrespon-sabledeproyectopuedegestionarloperorequierequelaDirecciónestéalfrentedefendiendoyabo-gandoporlamejora.Ladeserción,resistencia,cuestionamientosyquejasdebenserpolíticamenteconducidosyatendidosporlaDirección.Paraelloserequiereconocimiento,compromiso,liderazgo,confianzayacciónbajoelpropioejemploparadefenderelproyectoy lanecesidaddecambiar laformaanteriordeoperar.

• Asegurarqueelproyectoconsideraypermiteatodoslosinteresadosentender la necesidad del cambio y actuar para cambiar el comportamiento. Elproyectoesparamejoraryesodebeserelcentrodetodalagestión.

• Evaluar periódicamente los resultadoseidentificarsituacionesquenoestáncontribuyendoaobtenerlosobjetivosesperados.Laidentificaciónoportunadefocosrojosquenoestánmejorandoelresultadodebenpermitirdeinmediatocorregirelcomportamientoantesdequelaafectaciónseamayor.

Ilustración 3. Consejos para el éxito del proyecto de mejora

www.proiectus.es

19



REfERENCIAS:1 CMMI DEV version 1.3, “Improving processes for

developing better products and services.” (CMU/

SEI-210-TR-033). Software Engineering Institute,

Carnegie Mellon University. November 2010.

http://cmmiinstitute.com/resource/cmmi-for-development-version-1-3/

2 Mullaly, Mark:”Managing Process Improvement”,

projectManagement.com, March 2013.

http://www.projectmanagement.com/articles/277644/Managing-Process-Improvement

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

Software Process Improvement” (CMU/SEI-96-

HB-001) Pittsburgh, PA. Software Engineering Insti-

tute, Carnegie Mellon University, February 1996.

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

www.proiectus.es









20


¿Cómo implantar adecuadamente un sistema de gestión en una empresa? ¿Cómo asegu-rarse de que se cumple adecuadamente las fechas previstas, se atiende todo lo necesario y se evitan problemas? ¿Conseguiremos que el cambio en el sistema informático de la em-presa sirva para darle impulso y generar una ventaja competitiva sostenible en el tiempo (al más puro estilo de la definición de Michael Porter 1), o bien pasará a convertirse en un lastre que la hace más burocrática y menos eficiente? Estas son algunas de las pregun-tas que frecuentemente se realizan gerentes y directores de IT de muchas organizaciones.

Ya se trate de implantar un sistema ErP 2 o sustituir el existente, o hablemos de implan-tar una solución específica de un área (SCM 3

o WMS 4 en el ámbito logístico, CrM 5 en el área comercial y de marketing,…), se trata de una decisión estratégica en cualquier empre-sa, no siempre exenta de polémica, tensión y conflictos.

En el presente artículo presentaremos las principales dificultades a las que se puede enfrentar una organización que se plantea cambiar de ErP (si bien po-dría extrapolarse a cualquier otro tipo de herramienta de gestión), y analizaremos en qué medida la dirección de proyec-tos puede ayudarnos a llevar este reto a buen término.

UN CAMBIO DE ERP ES UN CAMBIO DE SISTEMA

Uno de los aspectos más importantes a considerar en la implantación de un siste-ma ErP o similar es que se trata, ante todo, de un cambio profundo en la organización. En realidad no es meramente un cambio informático, sino que frecuentemente ha-blamos de una transformación profunda en la forma de operar de todo un sistema. ¡Hay implantaciones de ErP que resultan más traumáticas que trasladar la sede de un lugar físico a otro!

DIRIGIENDO PROYECTOS PARA IMPLANTAR UN ERP

anTonio Pedro dorTa alonsoIngeniero 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).

www.proiectus.es

21


Nos encontramos, por tanto, ante un cambio organizativo. Un engranaje que ha ido puliéndose a lo largo de los años, ins-taurado a través de procedimientos (más o menos lógicos), de tareas (más o menos eficientes) y de hábitos (más o menos inte-ligentes) que se ve sometido a numerosos cambios en forma e incluso en trasfondo.

En tal sentido, la gestión de la integra-ción, tal y como la concibe el PMBOK puede resultar crítica para asegurar el éxito del proyecto. resulta frecuente que, ante un cambio tan complejo, pocas per-sonas tengan la capacidad de ver todo el mapa en su conjunto, entendiendo que una modificación en un determinado as-pecto (un proceso de ventas) puede tener su repercusión en otro (el cálculo de las comisiones tras su impacto en la cuenta de resultados, observable tras la contabi-lización de dichas ventas).

Muchos miembros del equipo de proyec-to, consultores de negocio y técnicos, tienden a centrarse en su ámbito de es-pecialidad, ignorando el resto de ámbi-tos. Sin embargo, el director del proyec-to debe mantener en todo momento esa visión holística para alinear necesidades con acciones y para mantener coheren-te el plan del proyecto con los resultados requeridos.

resulta frecuente en este tipo de proyectos que se vaya refinando los requerimientos de la organización que recibe la implantación del sistema ErP, surgen nuevas necesida-des no previstas o aparecen nuevas accio-nes a realizar a medida que los consultores de negocio conocen con mayor profundi-dad cómo trabajan los usuarios. En este contexto de descubrimiento por avance, un adecuado control de cambios puede su-poner la diferencia entre el éxito y el fracaso de la implantación.

Dos eQuIpos De trabajo, ¿un objetIvo CoMún?

Cada empresa podría considerarse un sis-tema complejo, semejante a un ente vivo, que evoluciona. Y de la misma manera que no hay dos personas iguales, tampoco hay dos empresas que sean idénticas en su for-ma de trabajar, de gestionar los datos que la componen y de actuar frente a las nece-sidades del mercado.

En este sentido, el conocimiento del equi-po de implantación procedente de proyec-tos anteriores es importante, pero en raras ocasiones resulta suficiente. Las estima-ciones por analogía para valorar cuánto esfuerzo requiere una tarea serán aproxi-madas, puesto que no se conoce a priori todo el detalle de los procesos de negocio, ni se conoce bien a los usuarios que los


www.proiectus.es

22


ejecutan. Por ello, suponer que dos empre-sas trabajarán con el sistema informático de igual manera puede ser una hipótesis errónea, ya que el talento existente en cada organización, la cultura corporativa y el es-tilo que nos identifica como seres humanos únicos marca pautas en cómo hacemos las cosas. En este caso, la diversidad juega en nuestra contra.

En el otro lado de la mesa, tenemos a los usuarios que actualmente conocen con excepcional lujo de detalle cómo opera su empresa, pero desconocen cómo funciona la nueva herramienta de gestión, y cómo se adaptará a su negocio (este último punto es lógico, ya que de lo contrario no haría falta la presencia de un equipo de consultores en la implantación).

En definitiva, dos equipos de trabajo que en el mejor de los casos estarán bien liderados por sus correspondientes responsables y estarán alineados en conseguir una implan-tación con éxito, pero que no se conocen entre sí, poseen un perfil y experiencia di-ferentes y, bajando a nivel de detalle, tie-nen objetivos a corto plazo distintos (unos estarán preocupados por una implantación rápida y sin incidencias, y los otros esta-rán preocupados en que el cambio tenga un mínimo impacto en su forma de trabajo actual).

LA MAYOR PARTE DEL CONOCIMIENTO ES TáCITO

Por si fuera poco, además, es importan-te tener en consideración que gran par-te de todo el conocimiento necesario en el proyecto pertenece a la categoría de conocimiento tácito, difícil de estable-cer en procedimientos y, por extensión, complejo de documentar y sistematizar. De la misma manera que un consultor especializado con muchos años de ex-periencia posee un bagaje que le permi-te actuar en numerosas circunstancias, un responsable de compras con talento y que lleve varios años en su empresa tendrá un extenso conocimiento que le permite realizar pedidos óptimos. Y la mayor parte del conocimiento que cons-truye las decisiones de ambos profesio-nales se ha conformado con numerosas iteraciones de los procesos y de mucha reflexión no verbalizada. Hay responsa-bles de compra que realizan aprovisio-namiento considerando lo que ven en las noticias (el caso de aluminio en el ámbito industrial) o viendo la fluctuación meteorológica (el caso de la producción de cerveza), de la misma forma que un consultor experto sabe las dificultades que tendrá en la consolidación conta-ble simplemente analizando la comuni-cación no verbal del director financiero cuando se sienta con él.

www.proiectus.es

23



El juicio de expertos es una técnica valiosa en la implanta-ción de ErPs

Imágen con licencia Creative CommonsAutor: Kevin Dooley

Desde un punto de vista de dirección de proyectos, es importante considerar este conocimiento no formalizado a través de la técnica juicio de expertos. resultará fun-damental para algunos procesos, como la estimación de la duración de las activida-des, la validación de alcance o la identifi-cación de los riesgos del proyecto. No es infrecuente que el director de un proyecto de implantación de un ErP esté constante-mente aplicando esta técnica para recabar criterios y para realizar una adecuada toma de decisiones.

EL PROBLEMA DEL ALCANCE EN LOS ERP

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

gestión en una empresa es, eminentemen-te, un proyecto de cambio organizativo, y que se aborda a través de un itinerario de descubrimiento por avance.

La ausencia de conocimiento detallado de lo que puede hacer la nueva herramienta por parte de los usuarios, y la falta de co-nocimiento detallado de los procesos de negocio por parte de los consultores hace que el proyecto parta de un mayor o me-nor grado de incertidumbre, que deberá ser atajada a medida que se avanza en el ca-lendario.

Como norma general, en la fase previa a la de ejecución del proyecto, el equipo de tra-bajo que realiza la implantación suele reali-zar un análisis más o menos extenso de las posibles necesidades y requerimientos de los procesos de negocio, con el fin de eva-luar la viabilidad del proyecto (y de estable-cer las condiciones económicas iniciales, si quien realiza los servicios de implantación es una empresa externa). Pero este cono-cimiento de partida rara vez cubre toda la casuística posible del día a día de la orga-nización que implanta la nueva herramienta de gestión.

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

www.proiectus.es

https://www.flickr.com/photos/pagedooley/7007372665

24


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

Posteriormente, tras una validación inicial del alcance, se re-planifica el trabajo res-tante necesario en el proyecto y se prosigue con la siguiente fase, en la que se procede a implementar todas aquellas necesidades de negocio establecidas. Para facilitar tan-to la verificación como la validación, suele establecerse un calendario de prototipos, conjuntos de funcionalidades más o menos completas y refinadas para su demostra-ción y prueba.

Desafortunadamente, en el momento de presentar un prototipo es frecuente que aparezcan nuevos requerimientos (obvia-dos en la fase de análisis por despiste o por cualquier otro motivo), se modifique los requerimientos ya existentes (porque hubo dificultades de comunicación o de enten-dimiento) o se descubra nuevas necesida-des no previstas. Esto podría suponer una ampliación en el alcance, cuyo coste puede o no asumir la empresa cliente (en función de las negociaciones comerciales iniciales o posteriores) pero que normalmente no se desea que impacte en el calendario ni en la

fecha prevista de finalización del proyecto.

Esto supone un problema importante des-de el punto de vista de dirección de pro-yectos. Sólo se conocerá con exactitud lo que se va a realizar una vez que el proyecto ha finalizado, pero para cumplir tiempos y costes se requiere un avance planificado y estructurado de un trabajo que aún no se sabe con detalle de qué estará compues-to. Dicho de otra manera, los paquetes de trabajo y la Estructura de Desglose de Trabajo se construyen a medida que el proyecto avanza, pero suele requerirse un Diagrama de Gantt desde el minuto 0 y que posea un margen de desvío lo más bajo posible. Todo un reto para cualquier experto en planificación.

Gran parte del problema en un proyecto de este tipo, como se puede deducir, radica en el Alcance del proyecto, especialmente en el proceso de Validación del Alcance. De hecho, en muchas organizaciones esta situación se agrava si además los usuarios finales no tienen contacto con el equipo de consultores, por la presencia de inter-locutores que actúan de intermediarios, y la labor de análisis de requerimientos no se realizó de forma realista. En este sentido, la ausencia de una adecuada Gestión del Cambio (por ejemplo, siguiendo el modelo de Kotter 6) y los problemas de comunica-

www.proiectus.es

25



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

EL CALENDARIO ES UN ASPECTO CRÍTICO

A diferencia de muchos otros proyectos, la implantación de un sistema ErP suele te-ner una mayor sensibilidad al calendario que otro tipo de herramientas informáticas, de-bido al impacto en la gestión financiera de la organización. De hecho resulta frecuente que el departamento de Administración de una empresa sea quien establezca el co-mienzo de año para el cambio de sistema informático como un requisito indispensable para abordar el proyecto.

Debido a las altas dosis de incertidumbre inicial, a que el conocimiento tácito de las personas establece muchas veces el crite-rio para actuar y a que el alcance deman-da altas dosis de flexibilidad, resulta espe-cialmente difícil la gestión del calendario de este tipo de proyectos.

Adicionalmente, hay elementos presentes en todo tipo de proyectos que favorecen retrasos y desvíos temporales, como la Ley de Parkinson (toda tarea se dilata a lo lar-go del tiempo hasta ocupar la totalidad del tiempo disponible) o la Teoría de las Limita-ciones de Goldratt 7.

Por ello, es muy frecuente realizar planifi-cación gradual, refinando a nivel de de-talle únicamente las acciones a corto pla-zo, y estableciéndose planificación hacia atrás, partiendo de la fecha de arranque (puesta en marcha del nuevo sistema) y definiéndose las fechas previas necesarias hasta llegar a la fecha actual.

Algunas técnicas, como el análisis Mon-tecarlo o el método de la cadena críti-ca, pueden ser excepcionalmente útiles para mejorar la gestión del calendario de un proyecto considerando los posibles riesgos existentes y estableciendo buffers para hacer frente a las posibles dificultades que seguro surgirán.

LAS PERSONAS SON LA PIEzA CLAVE

Es frecuente oír en muchos ámbitos, es-pecialmente en la publicidad y acciones de marketing de las empresas de servi-cios, que ‘las personas son lo más im-portante’. A pesar de que pueda ser un tópico en muchos casos, en los proyec-tos de implantación de sistemas ErP es un paradigma clave para alcanzar el éxi-to.

Si partimos de la premisa de que ante todo nos encontramos en un proyecto de cambio organizativo, donde impera el conocimiento tácito no estructurado

www.proiectus.es

26


y donde las mayores fricciones surgen de la validación del alcance, es lógico considerar que las personas juegan una pieza clave en el proyecto, con una rele-vancia muy superior al aspecto técnico informático. Y es que, ante todo, somos personas colaborando mutuamente para alcanzar nuestros objetivos.

En muchas ocasiones, un buen equipo de consultores, debidamente cohesiona-do a través de un adecuado liderazgo situacional y de técnicas de teambuil-ding, correctamente equilibrado en sus conocimientos técnicos y compensado convenientemente aplicando la teoría de Roles de Belbin 8, puede proporcio-nar mejores resultados implantando un ErP limitado que un equipo sin talento ni

coordinación que implanta el mejor ErP del mercado.

Por otro lado, la correcta gestión de stake-holders o interesados también es crítica de cara a conseguir la mayor cooperación po-sible de todas las personas implicadas, ante lo que influye enormemente la gestión de las comunicaciones en el proyecto. Los problemas derivados de malas interpre-taciones, confusiones y malos entendidos pueden ser fácilmente gestionados a través de una comunicación eficaz promovida por el director del proyecto, así como puede fa-cilitar que todas las personas tengan el co-nocimiento necesario para tener una visión adecuada del éxito. Y es que gran parte de la jornada de un director de proyectos, es-pecialmente en la implantación de un ErP,

La interacción con el equipo de trabajo y con los usuarios es clave para el éxitoImagen con licencia Creative Commons

Autor: Woodley Wonderworks

www.proiectus.es

https://www.flickr.com/photos/wwworks/9111274504

27



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

CONCLUSIONES

La implantación de un sistema ErP es una tarea ardua y compleja, debido a que más allá de un cambio informático, se trata de una profunda transformación de una orga-nización, en la que la cultura corporativa, la presencia (o ausencia) de talento y la ges-tión del cambio son aspectos tan impor-tantes como la funcionalidad del software a implantar.

Para abordar una implantación de estas características con éxito es necesario una adecuada planificación y coordinación de las tareas, un adecuado seguimiento de las mismas, mantener una visión global duran-te todo el desarrollo y saber dar respuesta a los inconvenientes que aparezcan a lo lar-go del camino. Dicho de otra forma, para implantar con éxito un ERP se requiere una gestión eficaz de proyectos.

En este sentido, la aplicación de buenas prácticas en dirección de proyectos, tales como las recogidas en el PMBOK, pue-den generar resultados muy positivos. Una correcta gestión de la integración, una gestión de riesgos eficaz y una adecuada gestión de recursos humanos, intere-

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

Por supuesto, PMBOK no es la única alter-nativa viable para conseguir resultados si-milares. Y de hecho, la aplicación sin más de esas buenas prácticas no garantiza el éxito de por sí sin una correcta ejecución y sin adaptarlo adecuadamente a las nece-sidades de cada caso en particular. ¿Pero cuándo no?

REfERENCIAS

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

vard Business School y experto reconocido a nivel

mundial en estrategia corporativa. Es autor de nu-

merosos libros y artículos sobre estrategia y com-

petitividad.

2 ERP – Enterprise Resource Planning: sistema de

gestión que trata de aglutinar todos los procesos o

los procesos críticos de una empresa.

3 SCM – Supply Chain Management: sistema orga-

nizativo para administrar el flujo de materiales des-

de el aprovisionamiento hasta la entrega al cliente.

En ocasiones se respalda con una herramienta

informática, denominada también SCM.

4 WMS – Warehouse Management System: sof-

tware especializado en la gestión operativa de un

almacén.

www.proiectus.es

28


5 CRM – Customer Relationship Management: en-

foque de marketing para establecer todas las accio-

nes de una empresa centradas en el cliente y en su

experiencia como tal. En ocasiones se respalda con

una herramienta informática para el seguimiento de

dichas acciones, denominada también CRM.

6 John Kotter (1947, -): profesor de Harvard Busi-

ness School y experto reconocido a nivel mundial

en liderazgo empresarial y cambios organizacio-

nales. Estableció un modelo de cambio basado en

ocho pasos secuenciales en su libro “Liderando el

Cambio” (1995).

7 Eliyahu Moshe Goldratt (1947, 2011): doctor en

Física y creador de la Teoría de las Limitaciones.

En su obra “La Meta” estableció un paradigma en

gestión de procesos basado en la reingeniería de

procesos para reducir cuellos de botella a nivel

organizativo.

8 Teoría de comportamiento de personas traba-

jando en equipos. Léase Revista IT PROIECTUS

Número 2.

www.proiectus.es

29


ITIL ® Y LA GESTIÓN DE PROYECTOS


José selaYaConsultor independiente especializado en Gestión del cambio y evangelizador de marcos de buenas prácticas. Ostenta en la actualidad de 17 acreditaciones oficiales en diferen-tes ámbitos (Prince2 Practitioner, ITIL Expert, MSP, P30, M.o.R, Scrum Manager, ISO20K, ISO27K,etc ... Es colaborador internacional de Axelos como asesor en traducciones de marcos de buenas prácticas y exámenes en lengua castellana. Actualmente colabora con Globallynx.com en la organización de formaciones acreditadas ITIL® a lo largo del conti-nente Europeo, empresa acreditada por Peoplecert.

En una de mis primeras aproximaciones a ITIL® allá por el año 2005, me llamó sumamente la atención el “cortocircuí-to” que existía en los temarios oficiales a la hora de explicar la estrecha relación entre este marco de buenas prácticas y la necesidad de abordar los proyectos tanto a la hora de introducir, cambiar o retirar servicios/productos de la cartera corporativa.

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

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

No es mi pretensión adentrarme en las “tinieblas teóricas” de ITIL hasta un nivel cansino, sino mas bien plasmar una serie de conceptos que den píe a la reflexión sobre la conveniencia de enlazar un mar-co de gestión de proyectos adecuado al uso de esta buena práctica.

Dentro del ámbito Táctico-Operativo, to-memos por ejemplo 2 procesos dentro del Diseño del Servicio, así como Transi-ción del Servicio., Serían respectivamen-te:

• Diseño del Servicio à Coordina-ción del Diseño

• Transición del Servicio à Soporte y planificación de la transición.

Coordinación del Diseño fue añadido como proceso nuevo en la actualización (que no versión) 2011. Es un elemento muy significativo ya que engloba en su al-cance la responsabilidad de gestionar to-

www.proiectus.es

http://Globallynx.com

http://www.peoplecert.org

30


dos los procesos involucrados dentro del Diseño del Servicio, tanto a nivel de segu-ridad, capacidad, disponibilidad etc. etc. siendo por tanto un reto en cuanto aunar tanto la gestión técnica como la gerencial más enfocada al negocio.

Es por ello que se requiere la definición y ejecución de un proyecto que identifique las partes invo-lucradas, anali-ce los riesgos, autorice fases etc. etc...

Durante mi época trabajando como ges-tor de proyectos en Sun Microsystems, se aunaron elementos propios de los procesos de Diseño de ITIL dentro de la ejecución un proyecto Bajo principios basados en Prince2, de tal forma que se pudieran entregar productos que había que diseñar, construir, probar y desple-gar, facilitando una transición minimi-zando en lo posible el impacto al entor-no productivo.

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

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

construir y probar la viabilidad del producto que se va a desplegar en la fase operativa.

En Sun utilizábamos puntos de revisión significativos (“Peajes”/Toolgates), para poder comparar los diseños con los pro-ductos finalmente montados, evaluar desviaciones y sus pertinentes justifica-ciones cara a la gestión financiera y del tiempo disponible, en definitiva, gestionar el proyecto, apoyándonos en los proce-sos de ITIL® para ejecutar las actividades, teniendo en mente que es un marco des-criptivo.

www.proiectus.es

31



Sirvan de ejemplo estos dos procesos a modo de ejemplo para poder eviden-ciar lo transcendental que resulta poder coordinar las actividades propias de los procesos ITIL ® dentro de un marco de gestión de Proyectos como Prince2 ® por ejemplo de tal forma que manten-gamos control sobre recursos y des-viaciones a la hora de planificar nuevos productos.

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

Este proceso de ITIL ®, se engloba den-tro de la parte de Estrategia del Servicio y nos describe las actividades y status en los que los servicios pueden pasar a lo largo de su ciclo de vida y qué ele-mentos tendremos en cuenta para po-der hacer cambios a la cartera.

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

en la situación temprana en la que aún no está definido siquiera el equipo del proyecto que gestionará el mismo. En ITIL ® una vez se autoriza el paso de un servicio en “Pipeline” a “Chartered”, es entonces cuando se ha obtenido un análisis positivo de esa viabilidad y por tanto se puede armar el equipo y por consiguiente el proyecto que gestionará ese producto en concreto.

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

Por mi parte recomiendo encarecida-mente utilizar Prince2 ® ya que tiene un carácter eminentemente pragmático al ser (Prescriptivo), se dispone de forma abierta de plantillas para trabajar desde día 1 y es perfectamente asimilable con ITIL ®.

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

www.proiectus.es

32


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

www.proiectus.es

33


AGILE hORRORS

MiKe GriFFiTHsRenowned project manager, trainer, consultant and writer, holding multiple project ma-nagement and Agile related certifications. He is also a regular columnist and Agile con-tributor at www.leadinganswers.com and Ganthead.com Gantthead.com, the world’s leading online community for IT project managers.

fR ANkENSTEIN PROCESS

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

Agile practices are in a balanced ne-twork. ruthless testing balances the need for comprehensive documenta-tion; colocation, demos and daily stand ups reduce the need for detailed status reporting. Changes made to this web of practices can easily create risks, gaps and duplications if they are not carefully considered.

Think candy apples not pumpkin pie; hybrid methods work best when there is a core of agile for the team to own and execute, surrounded by a wrapper of more traditional process to buffer and integrate into a less agile aware en-vironment. Don’t try and glom disparate process pieces together, it becomes a monster nobody loves or defends.

zOMBIE PROjECTS

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

AGILE hORRORS

www.proiectus.es

http://www.leadinganswers.com

http://Gantthead.com

34


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

These death marches to eventual failu-re or cancelation are damaging to the people working on them who see the futility and mismatch of progress to tar-gets. However, like the emperor’s new clothes there is a shared acceptance that this is unlikely to work, but nobody seems to speak out. Perhaps thinking that the “higher ups” must know what they are doing and would intervene if there are problems; they continue shu-ffling forward like an army of undead looking for brains.

Unfortunately, there are no brains here and the higher-ups rarely have some cunning plan that turns struggling forward progress into an elegant solu-tion. More often if it looks, smells, and behaves like an undead zombie, it is one. Just like in the movies, it is best not to start shouting and bring atten-tion to yourself if you are surrounded by zombies. Instead try to find an opportu-nity to exit quietly, see if there is a reset or restart initiative planned. Offer to be part of the solution, instead of bitching

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

VAMPIRE SCRUM MASTERS AND PROjECT MANAGERS

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

Agile teams generally work very hard to deliver as many high quality featu-res as they can. When they report pro-blems or ask permission to undertake maintenance work it is so they can be better equipped to deliver high quality features long into the future. Like igno-ring a Check-Engine light in your car or missing regular maintenance, you might save some money in the short term but it is a false economy longer term.

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

www.proiectus.es

35


AGILE hORRORS

for resume boosting technology upgra-des.

Teams who routinely get their requests ignored by leads that just want results without investment will correctly draw the conclusion that they are not valued. When this occurs, the motivation to try hard, delight customers and go the ex-tra mile to overcome an obstacle is re-moved. The delivery of results will decli-ne and then the whole process sucks.

So, show some interest, ask people to explain why issues and requests are im-portant. If all the solutions are not pos-sible ask them to prioritize. Try as hard as you can to fulfill these requests and usually the teams will reciprocate with improved effort and results.

PRODUCT OwNER GhOSTS

These are business representatives that are kind of there, but not really, they tend to vanish or dissolve when pressed on anything. Whether it is a tough decision on a product feature, or their attendan-ce at a demo; product owner ghosts are unreliable.

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

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

So, look out for signs of less than real product ownership. Warning signs of a non-committed or weak business invol-vement include:

C -Contrary–decisionsflip-flopwithno

clearexplanation

A -Absent–youcannot find themor

gettheirtimewhenneeded

S -Switching–thepersonchanges,nodedicatedproductownerisassigned

P - Passive – without prompting we

wouldnothear fromthemfor longpe-

riods

E -Elusive–theywillnotprovideclearfeedbackonthesuitabilityofaprototy-

pe

R -Reclusive–theywithdrawfromprio-

ritydiscussionsanddecisions

Instead try to staff projects with product

www.proiectus.es

36


owners who exhibit more solid, proactive business representations.

C – Collaborative – willing to discuss

andevaluatealternativesolutions

O –Owners – owning the backlog of

work, taking reasonability for its groo-

ming

N –Nearby–availablewhenrequiredto

askquestionsandgetclarifications

C –Committed–havingthesameper-

sonorpeoplethroughouttheproject

R –Representative – representing thegroupwearebuildingfor,notpersonal

goals

E –Expert–knowledgeableaboutthedomainathandtoanswerteamques-

tions

T –Traceable–contactablewhennee-dedorwithaproxyavailableifaway

E –Experienced–experienced in thefieldtowarnofoutliersandexceptions

(I prefer these attributes over Barry Boe-hm’s CrACK mnemonic that does not emphasize the Nearby, Experienced

and Expert qualities that can really save teams time.)

Getting the best users is always difficult since the best people are busy doing real work. Try to explain the costs and risks of building the wrong or a sub-optimal solu-tion. Offer to back fill admin work from the project for the best people even just to free up some of their time each week for input and feedback.

www.proiectus.es

37


AGILE hORRORS

SUMMARY

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

www.proiectus.es

38


Pilar Tarriño Licenciada en Informática por la Universidad de Las Palmas de Gran Canaria. Tras va-rios años de trabajo en empresas privadas, de ellos 5 programando para Sistemas de Información Geográficos, doy el salto hace 6 años a la administración pública canaria. Primero como analista en la Consejería de Ordenación Territorial y Medio Ambiente, y actualmente en la Consejería de Educación, Universidades y Sostenibilidad. Engancha-da a las metodologías ‘ágiles’ y a los ‘MOOCs’ y procurando no descolgarme del verti-ginoso avance de la tecnología.

DEUDA TéCNICA: LOS COCODRILOS SALEN DE LA ALCANTARILLA

Una antigua leyenda urbana en el Nueva York de los años 30 habla de pequeños cocodrilos que fueron traídos como sou-venir y luego lanzados por los desagües. Allí crecieron y con el paso del tiempo se convirtieron en grandes y sigilosas som-bras de ojos brillantes que acechaban a los empleados de mantenimiento. Es así como pequeñas decisiones aparentemente poco importantes se convierten en grandes pro-blemas.

En este modesto artículo pretendo hablar de una problema común a todo proyecto, la deuda técnica. Todo proyecto, sea del tipo que sea, arrastra una deuda técnica, desde el minuto uno se toman decisio-nes que van a ir introduciendo en nuestra mochila pequeñas o grandes piedras con las que tendremos que acarrear hasta el final del mismo. La cuestión es que no po-demos evitar cargar con ella, pero sí que debemos controlar su peso para que po-

damos seguir alcanzando los objetivos del proyecto y no nos retrase, o en el peor de los casos, nos paralice.

El término de Deuda Técnica es acuñado por Ward Cunningham en 1992. Aunque la definición propuesta por Ward Cunnin-gham se refiere al desarrollo del software, no es en absoluto el único campo en la que se puede aplicar.

“Shipping first time code is like going into debt. A little debt speeds develop-ment so long as it is paid back prompt-ly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brou-ght to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

— Ward Cunningham, 1992

www.proiectus.es

http://en.wikipedia.org/wiki/Ward_Cunningham

39



En esta definición se realiza una similitud con una deuda económica. Si para llevar a cabo un proyecto un banco te concede un préstamo, sabes que estás adquiriendo una deuda que debes pagar en un tiempo determinado y además con unos intereses. ¿Qué ocurriría con un proyecto en el que la deuda no disminuye, o peor aún, va au-mentando continuamente? Obviamente se llega a un punto de quiebra ante la imposi-bilidad de afrontarla.

La diferencia entre la deuda económica y la técnica, es que en el primer caso normal-mente es sencillo responder a las siguientes preguntas:

• ¿Cuántodeboyconquéinterés?

• ¿Cuántodebopagarmensualmente?

• ¿Quéocurresimeretrasoenelpago?

• ¿Cuándosaldarémideuda?

Para la deuda técnica la cosa no es tan clara, porque no es sencillo responder a ninguna de esas preguntas. Si no sabes cuánta deuda tienes, mucho menos podrás reducirla ni controlarla.

Sin entrar en demasiada teoría, propongo una aproximación a este problema en tres fases clásicas: DETECTAr, CONTrOLAr, rEDUCIr.

fASE 1: DETECTAR.

Para detectar nuestra deuda se pueden hacer un montón de mediciones: tasa de errores, tiempos de respuesta, análisis de calidad, matrices de dependencias, esta-dísticas, … pero … ¿y si empezamos por preguntar? Creo que es lo más fácil y prác-tico. El equipo del proyecto sabe si hay deuda y sabe dónde está.

Así que nos sentamos en una mesa con el equipo del proyecto y simplemente le pre-guntamos. En esta primera fase no se pre-tende un examen detallado y exhaustivo, solamente captar el sentir de los que traba-jan día a día y codo con codo.

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

Las respuestas pueden ser:

a. “Eh…¿Deudatécnica?…¡Notenemos

ningunadeuda!”

b. “Bueno…tenemosunpardeherramien-

tasnofundamentalesalgoobsoletas.”

c. “Buf…hayalgunaspartesfundamenta-

lesquenecesitanunaevolución”

www.proiectus.es

40


d. “Agh.. todoelproyectodependedetec-nologíasnosóloobsoletas,antediluvianas!”

Si la respuesta es A ... vuelve a preguntar. Todo proyecto siempre-siempre-siempre tiene algo de deuda. Si el equipo responde que no la hay significa que no es consciente de la misma y, cuando no eres conscien-te de algo no puedes evitarlo. Por lo tanto, hay que preguntarse ¿trabajamos siempre con la última tecnología del mercado? ¿no cometemos nunca errores y siempre segui-mos los máximos estándares de calidad? ¿estamos excelentemente formados?.

recomiendo dividir nuestro proyecto en sus partes o secciones fundamentales, pero ha-ciendo un desglose a alto nivel. No convie-ne inicialmente analizar elemento a elemen-to sino el tener una visión global. Cuando detectemos la zona más problemática ya entraremos en una segunda fase al detalle específico.

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

1- Muybaja

2- Baja

3- Media

4- Alta

5- MuyAlta

El objetivo final de esta primera fase es dis-poner de un mapa global de los puntos pro-blemáticos de nuestro proyecto, ordenarlos por su gravedad para así empezar a contro-lar el problema.

fASE 2: CONTROLAR

Llegados a este punto es importante deter-minar la/las causas por las que hemos lle-gado al actual nivel de deuda. Detectar las causas es fundamental para iniciar el control del problema, no sirve de mucho tener un equipo reparando agujeros mientras por otro lado los seguimos generando.

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

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

www.proiectus.es

41



• Prudente y Deliberado: El equipo esconscientedequeladecisióntomadava

a incurrirenaumentar ladeuda técnica

delproyecto,pero ladecisiónesdocu-

mentada y se planificará su corrección

enunfuturocercano.

• Prudente e Inadvertido:Elequiponofue consciente de que la decisión to-

mada aumentaba la deuda técnica del

proyecto,perosedetectaelproblemay

seplanificarásucorrecciónenunfuturo

cercano.

• Imprudente y Deliberado:Elequipoesconscientedequeladecisióntomadava

a incurrirenaumentar ladeuda técnica

delproyecto,peroyasecorregirá‘algún

día’.

• Imprudente e Inadvertida: Elpeores-cenario,elequipoaumentacontinuamen-

te la deuda técnica sin ni siquiera darse

cuenta.

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

• Presiones para la entrega en plazos

acordados.

• Relajaciónde la calidad con el objetivo

deaumentarlavelocidadodisminuirlos

costes.

• Trabajoacortoplazo,sinevaluarlasim-

plicacionesfuturas.

• Faltadeliderazgoycontroldelproyecto.

En el caso de deuda inadvertida, pueden ser:

• Faltadecomunicación.

• Dispersióndelconocimientodelproyecto.

• Faltadeestándaresdecalidadodese-

guimientodelosmismos.

• Deficienciasenlaformaciónyenlosco-

nocimientosnecesariosparaelproyecto.

• Equiposinestablesconaltatasademo-

vilidad.

• Faltadeliderazgoycontroldelproyecto.

Es importante detectar las razones por la que el proyecto incurre en deuda técnica y establecer un plan para minimizar dichas causas. Este plan debe desarrollarse en paralelo con la reducción de la deuda ac-tual, de forma que con el paso del tiempo la deuda disminuya de forma efectiva.

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

• Liderazgodelproyecto

• Calidad

• Equipodetrabajo

• ConocimientoyFormación

Un artículo de Henrik Kniberg describe muy gráficamente el objetivo de esta fase (http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt). Debemos procurar

www.proiectus.es

http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt


42


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

fASE 3: REDUCIR

En este punto toca atajar la deuda que ya tenemos, de forma que la mantengamos dentro de unos niveles aceptables. Como ya comenté , la deuda cero es imposible de alcanzar así que lo importante es mantener-la bajo control.

Llega el momento de ‘pagar’ la deuda y para ello el mejor enfoque desde mi modes-to punto de vista es usar un enfoque ágil. En anteriores artículos de esta revista y en multitud de libros y páginas web se descri-ben las técnicas ágiles de gestión de pro-yectos. En resumen:

1. Establecer un ciclo de trabajo (sprint),

conunafechadeinicioyunadefin.

2. Determinar la velocidad de trabajo, es

decir,cuántastareaspodemosabordar

encadaciclo.

3. Seleccionar de una lista de peticio-

nes que está ordenada por importan-

cia(ProductBacklog)lastareasquese

abordarán en el ciclo de trabajo y se

ajustan a la velocidad definida (sprint

Backlog).

4. Completadoelciclo,revisióndelosob-

jetivosyvueltaaempezar.

Además de la lista de tareas o Product Bac-klog, debemos también establecer una lista de tareas enfocadas a la reducción de la deuda, es lo que se denominaría ‘Technical Debt Backlog’. Básicamente es un conjunto de tareas ordenadas por su importancia y valoradas en función de su coste de reali-zación.

En cada ciclo, se debería reservar un por-centaje de la velocidad de trabajo para in-cluir tareas de esta segunda lista. De esta forma nos aseguramos un ‘pago’ continuo y estable de la deuda a lo largo de los dife-rentes ciclos de entrega.

Esta cuota no debe ser negociable con el cliente por varias razones:

Si permites que el cliente decida cuántos recursos se destinan a la deuda, es muy probable que ese porcentaje tienda a cero. Al fin y al cabo, es el propio cliente el que en

www.proiectus.es

43



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

Es importante hacer visible el coste de la deuda y el coste de hacer las cosas mal. De esta forma todos los implicados en el proyecto visualizan más fácilmente las ra-zones de la ralentización del proyecto. Y no sólo eso, a medida que se controle la deuda también se observa el aumento de la velocidad.

Por lo tanto, suponiendo que en el ciclo de trabajo nuestra velocidad es de 15 puntos y hemos determinado una reserva de un 20% para pagar la deuda, entonces podemos abordar 12 puntos para peticiones y 3 para pagar la deuda:

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

–Anónimo

“Calidad significa hacer lo correcto

cuando nadie está mirando”

–Henry Ford —

REfERENCIAS:


http://martinfowler.com/bliki/TechnicalDebt.html

http://www.ontechnicaldebt.com

http://www.javiergarzas.com/2012/11/deuda-tecnica-2.html

http://www.infoq.com/articles/managing-technical-debt

http://technicaldebt.com/got-technical-debt

www.proiectus.es





http://www.ontechnicaldebt.com



http://www.infoq.com/articles/managing-technical-debt

http://technicaldebt.com/got-technical-debt

44


Mario CoquillaT de TravesedoProfesional experimentado en gestión de proyectos, certificado PMP® y PMi-rMP®. Miembro del Comité CTN 157/ SC1 Project Management de Aenor que participó como Comité Espejo en la nueva ISO 21500 “Directrices para la dirección y gestión de pro-yectos” y participa actualmente en el TC-258 - project, programme and portfolio ma-nagement.

Uno de los mayores retos en la actualidad de las organizaciones que trabajan por proyectos es la gestión del conocimien-to, siendo las lecciones aprendidas ge-neradas durante su ejecución, uno de sus principales activos.

Si bien el proceso de lecciones aprendidas es un concepto al alza, como muestra la nueva norma ISO 21500 “Directrices para la dirección y gestión de proyectos“, inclu-yendo un nuevo proceso denominado “re-copilar las lecciones aprendidas”, es nece-sario establecer metodologías, técnicas y herramientas que permitan implantar con éxito este proceso clave dentro de las orga-nizaciones para mejorar el resultado de sus proyectos.

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

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

PUNTOS DéBILES DEL PROCESO Y fACTORES AMBIENTALES DE LA EMPRESA QUE LO AfECTAN

Cuando comienzas a implantar un proceso de lecciones aprendidas dentro de una or-ganización los principales riesgos a los que te enfrentas y las posibles estrategias para acometerlos son:

1.Falta de implicación delosmiembros

del equipo de proyecto fundamental-

menteporunaculturademiedoaque

sehaganvisiblesloserrores(especial-

METODOLOGÍA PARA LA GESTIÓN DE LECCIONES APRENDIDAS BASADA EN LA METODOLOGÍA DE GESTIÓN DE RIESGOS

www.proiectus.es

45


CREANDO UNA METODOLOGÍA PARA LA GESTIÓN DE LECCIONES APRENDIDAS BASADA EN LA METODOLOGÍA

DE GESTIÓN DE RIESGOS

mente en estos tiempos actuales de

crisis).

Recomendación: Esto se debe pa-

liar implantado una cultura de lecciones

aprendidas top-down desde la gerencia

siendo fundamental a nivel de proyecto

el apoyo del Director de Proyecto. Otro

aspecto a inculcar es que las lecciones

aprendidas (al igual que los riesgos) no

siempre son negativas sino que también

pueden ser positivas. Hay que reforzar

también esta visión positiva del proceso.

2.Falta de difusión y reutilización de las lecciones aprendidas. Existe unriesgoelevadodegenerarunabasede

conocimiento que no se utilice con lo

cual no sehabrácumplidoel finúltimo

paraelquesediseñóelproceso.

Recomendación: Se debe diseñar un

proceso que asigne recursos y defina

técnicas y herramientas tanto para ase-

gurar la captación como para asegurar

la difusión y reutilización de las lecciones

aprendidas.

3.Falta de una métricaquenospermi-

tamedirelvalor tangiblequenosestá

retornando este proceso.Hay que te-

nerenconsideraciónquelosproyectos

estánfocalizadosenlaejecuciónypor

tantocualquiergastoderecursosenta-

reasquenoseconsiderennecesarias

setratarádeminimizar.

Recomendación: Se debe establecer

una métrica para medir la eficiencia del

proceso de lecciones aprendidas en un

proyecto así como establecer objetivos

vinculados al mismo al inicio (a ser po-

sible en el acta de constitución del pro-

yecto).

Asimismo se deben considerar los siguien-tes Factores Ambientales de la Empresa en la que se implanta el proceso de leccio-nes aprendidas:

1.Estructura de la organización.De-pendiendosilaorganizaciónesfuncio-

nal,matricialuorientadaaproyectoslos

actoresque intervendrány laclasifica-

ción de las lecciones aprendidas po-

dríanserdiferentes.

Silaestructuraesfuncionallaclasifica-

cióndelasleccionesaprendidassepo-

drárealizarenbasealosdepartamentos

existentes al funcionar como “silos de

conocimiento” que fomentan lamejora

delosprocesosylideraránelproceso.

Porelcontrario,silaestructuraesorien-

tadaaproyectos,lagestióndelconoci-

www.proiectus.es

46


mientoesmáscomplicadaalpoderac-

tuarcadaproyectocomounaestructura

independientey temporal ysólopasará

elconocimientodeunproyectoaotroa

travésde laspersonasque loscompo-

nen.

Endichocasosedebencrear“silosde

conocimiento virtuales” liderados por

ExpertosenlaMateria(deltérminoinglés

Subject Matter Expert -SME)queactua-

rancomounnexodeuniónentrelospro-

yectos.

2.Sistemas de información para la di-rección de proyectos.Si en la orga-nización ya existen aplicaciones suele

existirlatendenciaa“encajar”elproce-

Metodología gestión de riesgos Nueva metodología lecciones aprendidasRiesgos negativos (amenazas) y riesgos

positivos (oportunidades)Lecciones aprendidas positivas y negativas

Impacto y Probabilidad Impacto (I)

Plan de gestión de riesgos Plan de gestión de las lecciones aprendidas

Categorías de riesgos Categorías de lecciones aprendidas

Identificar riesgos (técnicas) Identificar lecciones aprendidas (técnicas)

Probabilidad - Matriz de probabilidad e impacto (análisis cualitativo)

Niveles cualitativos de importancia basado en el impacto

Análisis cuantitativo Análisis de la viabilidad de la acción (CI-CA)

Respuesta al Riesgo Acción a implementar

Monitorear y controlar los riesgos Seguimiento de las lecciones aprendidas

Gestor del riesgo Coordinador de la categoria

Responsable del riesgo Responsable de la acción

Gobernabilidad del proceso de gestión de riesgos

Departamento o entidad liderando el proceso (se recomienda la PMO)

www.proiectus.es

47




soenlasmismaslocualpuederestringir

lasfuncionalidadesyperjudicarlanueva

metodología.

Se recomienda priorizar el proceso

sobre la herramienta por lo que en

una primera fase de implantación se

pueden utilizar plantillas con un sof-

twaredeusocomúncomoMicrosoft

Excel®yposteriormentecuandoesté

madurayseaaceptadaporlaorgani-

zación,sedebeestudiarlaopciónde

desarrollarunaaplicacióncorporativa

amedida.

En base a mi experiencia pasé por

ambasfasesylasegundasupusoun

cambiocualitativoen laaceptacióne

implantación del proceso, rentabili-

zandoelcostedesudesarrollo.

En cualquiera de los casos debe existir un departamento o entidad (se recomienda que sea por su posición estratégica la PMO) que lidere de manera global el proceso, definien-do el procedimiento que lo regule y asegu-rando su cumplimiento por todas las partes. Estas dos condiciones, junto con la madurez en gestión de proyectos de la organización, son los factores clave que contribuyen al éxi-to del proceso (Post-Project reviews to Gain Effective Lessons Learned, Project Manage-ment Institute 2007).

NUEVA METODOLOGÍA DE LECCIONES APRENDIDAS BASADA EN LA GESTIÓN DE RIESGOS

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

A continuación detallaremos esta nueva metodología.

CICLO DE VIDA DE UNA LECCIÓN APRENDIDA

Toda lección aprendida de un proyecto debe seguir el siguiente ciclo de vida:

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

Proceso de clasificación (CLA): se deben clasificar en categorías siguiendo un criterio (áreas de conocimiento, procesos, etc..) que permita su diferenciación y mayor facilidad de acceso a la información.

Proceso de evaluación (EVA): se de-ben evaluar con el objeto de establecer su prioridad y analizar la viabilidad de las acciones definidas para cada lección aprendida.

www.proiectus.es

48


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

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

Proceso de seguimiento (SEG): se esta-blece un sistema que asegura la implemen-tación de las acciones definidas para cada lección aprendida.

PROCESO DE IDENTIfICACIÓN

Una vez asignada la persona que liderará el proceso para cada una de las categorías (le llamaremos coordinador) se debe iniciar la captura de lecciones aprendidas.

Para ello se deben establecer dos tipos de mecanismos:

• Identificación reactiva. Cualquier

miembrodeunequipodeproyectoque

detecte una posible mejora o un error

encualquieraspectodeunproyectose

pondráencontactoconelcoordinador

pertinente (porejemplovíae-mailhabili-

tandounaopciónparaellosisedispone

deunaaplicaciónespecíficaparaelpro-

ceso)explicandodeunamanerainformal

cuáleslasituacióny,enelcasodete-

nerla,supropuestadesolución.

Esimportanteenlafaseinicialnosolicitar

alosusuariosrellenarplantillasyasumir

esa responsabilidadporpartedelcoor-

dinador

• Identificación proactiva. Los coordi-nadores utilizarán para ello información

delproyecto(informesdeavance,regis-

trosde incidentes, registrosde riesgos,

etc..)perolafuenteprincipalserálarea-

lizacióndeentrevistasalequipodepro-

yectoenlasvisitasperiódicas.

Sibien laperiodicidadde las visitasse

debeajustarenfuncióndelproyectoes

muyimportanterealizarpresencialmente

estas visitas (especialmente si los pro-

yectosseencuentrandeslocalizadosen

diferentesubicacionesypaíses)paraes-

tablecerunacomunicaciónfluidaconel

proyectoyentrelosproyectos,siendoel

coordinadorel“mediodedifusión”quela

garantice.

Como salida de este proceso se debe defi-nir una ficha (ver ejemplo adjunto) para cada lección aprendida en la que se rellenaran al menos los siguientes campos:

1- Título

www.proiectus.es

49




2- Descripción

3- Código(definidoenelsistemadeges-

tióndelaconfiguración)

4- Proyecto

5- Tipodeproyecto

6- País

7- Accióna implementar (versiónprelimi-

nar)

8- Palabrasclave

9- Categoría/salasquepertenece

PROCESO DE CLASIfICACIÓNLa lección aprendida se clasificará en base a las categorías definidas en cada caso al igual que se realiza con los riesgos.

PROCESO DE EVALUACIÓN

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

Para ello y como analogía de la metodología de riesgos tendremos la variable Impacto (I), que es la consecuencia o impacto de la lección apren-dida en los objetivos del proyecto (por ejemplo al coste o a su plazo de ejecución).

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

Para establecer el Impacto (I) se debe defi-nir un criterio para cada uno de los objetivos del proyecto, por ejemplo tres niveles (bajo – medio –alto) asignándoles valores del 1 al 3 (ver ejemplo adjunto). El valor final será por ejemplo el mayor de los obtenidos para cada uno de los objetivos del proyecto.

Bajo (1) Medio (2) Alto (3)

No afecta o afecta en menos de 1 se-mana al plazo total

del proyecto.

Afecta en más de 1 semana y menos de 4 semanas al plazo total del proyecto.

Afecta en más de 4 semanas al plazo total del proyecto.

Al igual que en la matriz de riesgos defini-remos tres niveles y tres colores que nos facilitarán la identificación visual.

Nivel1:Importanciaalta

Nivel2:Importanciamedia

Nivel3:Importanciabaja

Pero es aquí donde nuestra metodología incluye un concepto adicional, que apor-tará valor al proceso pues permitirá la uti-lización de esta lección aprendida a nivel de toda la organización: la transferencia de una lección aprendida de un proyecto a otro mediante el rol del coordinador y la evaluación de la prioridad en el proyecto destino.

www.proiectus.es

50


Ahora bien, en aquellas lecciones apren-didas que una vez realizado el análisis cualitativo se han establecido como priori-tarias, se debe realizar un análisis de via-bilidad de la acción a implementar (análi-sis cuantitativo).

Como hemos dicho anteriormente, nece-sitamos que se aprecie el valor del pro-ceso y esto implica que una vez definida la acción a implementar, debemos anali-zar si es viable, es decir, que el coste de su implementación es menor que el coste del impacto vinculado a la lección apren-dida. Esto es:

CI: Coste asociado al impacto (en el caso de que el impacto sea en plazo se cuan-tificará por ejemplo el coste de la penali-zación contractual por retraso en el pro-yecto)

CA: Coste asociado a la acción a imple-mentar

La acción será viable siempre que CI – CA > 0

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

1- Impacto(I)

2- Costeasociadoalimpacto(CI)

3- Coste asociado a la acción a imple-

mentar(CA)

4- Análisisdeviabilidad(CI-CA)

PROCESO DE ALMACENAMIENTOLas lecciones aprendidas identificadas tan-to en el proyecto origen como las transferi-das a los proyectos destino se almacenarán en la aplicación o plantillas que utilicemos para poder gestionarlas y para utilizarla como información histórica a futuro.

PROCESOS DE DIfUSIÓN Y SEGUIMIENTO

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

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

Un primer paso, como hemos hablado, es dis-poner de un coordinador para cada una de las categorías, pero esto no será suficiente. Aquí nuevamente nos asomamos a la metodología de riesgos para recoger buenas prácticas.

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

www.proiectus.es

51




sable de su implementación (responsa-ble de la acción), así como se controlará tanto la fecha en la que se ha difundido al proyecto como la fecha estimada de su im-plementación.

Y a partir de aquí se deben establecer dife-rentes niveles de seguimiento.

Para el seguimiento periódico del estado de la implementación de las acciones, asigna-ción de nuevos responsables, identificación de nuevas lecciones aprendidas será el coordinador quien establezca el calendario con el proyecto acorde a sus necesidades.

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

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

Esta planificación del proceso se debe in-cluir en el plan para la dirección del proyec-to o si se considera preciso en un plan de gestión de las lecciones aprendidas.

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

• Informes a nivel de proyecto parapoder hacer seguimientode las leccio-

nesaprendidascondosnivelesdeinfor-

mación(incluyendolosanálisisdeviabili-

dadaldirectordeproyectoysinincluirlo

parael equipodeproyecto al ser infor-

maciónsensible).

• Informes a nivel de categoría parauso del coordinador para hacer segui-

mientodetodassus leccionesaprendi-

das,incluyendoparaunamismalección

aprendida,suestadoen todos lospro-

yectosdondeseestáimplementandola

acción(proyectoorigenyproyectosdes-

tino).

RETORNO DEL PROCESO DE LECCIONES APRENDIDASEn base a mi experiencia en la PMO implan-tando nuevos procesos en la organización, para garantizar su éxito y sostenibilidad en el

www.proiectus.es

52


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

En este caso, hemos definido para ello una métrica que no precisa de cálculos adicio-nales y que aporta esa valoración tangible que precisamos.

Si consideramos el valor CI – CA obtendre-mos:

• En el caso de una lección aprendida positiva un beneficio real al proyecto (el coste del impacto menos el coste de im-plementar 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 (CI-CA) para aquellas acciones ya implementa-das, nos dará un valor monetario aproxima-do 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)

siendo rOILA el retorno de la inversión del proceso

Se recomienda, para conseguir el compro-miso del proyecto con el proceso de lec-ciones aprendidas, establecer un objetivo vinculado a esta métrica (por ejemplo ob-tener un rOILA = 2% del presupuesto del proyecto).

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 coordina-dor que se han implementado.

www.proiectus.es

53


UNA ESTRATEGIA PARA ENfRENTARSE AL ExáMEN PMP

Jose baraTo arroYoJose 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 Open-PPM, consistente en la creación, difusión y servicio sobre un producto de software libre para gestionar proyectos, programas y portfolios consistente con los estándares de PMI.


El grado de confian-za necesario para presentarse al exa-men del PMI® con tranquilidad se al-canza practicando tests. Practicar es beneficioso para se-guir aprendiendo (el buen aprendizaje viene cuando entendemos por qué las respuestas buenas son las co-rrectas y por qué las otras son incorrectas) y también para llegar a la marca de un minu-to por pregunta (en el examen hay que res-ponder 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 pre-guntas, 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 disponi-bles, de exámenes completos o de menos

preguntas, por áreas de conocimiento o mezclando las áreas, gratuitos o de pago, in-teractivos 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 acon-sejable 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 mo-mento de programar la fecha del examen. Cuando soliciten el examen, pidan la ayuda en español para leer rápidamente el enun-ciado 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 can-didato a la certificación del PMI ® es sin duda el tiempo limitado. Para el examen PMP ® tiene 4 horas para responder 200 pregun-tas, y siempre falta tiempo. La mayoría de

www.proiectus.es

54


los candidatos que suspenden el examen PMP ® se quejan de que les ha faltado tiem-po en el examen. Cuando queda una hora, por ejemplo, se dan cuenta de que les quedan más de 60 preguntas por res-ponder y entran en pánico. Para conseguir el tiempo medio de un minuto por pregunta es necesario haber hecho los debe-res: apren-der bien los fundamen-tos, practi-car muchos tests, des-cansar bien el día an-terior, etc. Todo esto, sin embargo, no garantiza el aprobado.

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

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 pre-via, la tecla [N] para ir a la pregunta siguien-te, la tecla [M] para marcar para revisar, la te-cla [A] para elegir la respuesta a), etc. Dicen que así ganan velocidad. La pantalla de las preguntas es más o menos como se repre-senta en la imagen (si piden la ayuda de la traducción al español, la pantalla aparece di-

vidida en dos mitades, arri-ba en espa-ñol y abajo en inglés: su respues-ta 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 rea-lice lo que se conoce como “volcado de le memoria” (brain-dump). Anote en un papel cierta información útil que sabe de memo-

www.proiectus.es

55


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 ni-veles de formación de equipos de Tuckman, los 5 métodos de resolución de conflictos, etc., etc.

Una vez ponga en marcha el cronómetro con la cuenta atrás de 4 horas, le aconsejo que siga una estrategia, eso le manten-drá 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

respuestassegurasymarcandoelres-

topara revisar.Ocurrequealprincipio

delexamenentramosfríosynerviosos,

empezamos a responder preguntas

fáciles y nos animamos, pero ense-

guida llega una preguntamuy difícil, y

noshaceperder5minutosporquenos

empeñamos en seguir el examen de

formasecuencial.Estoesunerrormuy

común.Miconsejoesquedenunapri-

merapasadaquitándoselaspreguntas

fáciles,cuandovuelvanalaspreguntas

difíciles,comprobaránqueyanolespa-

recentandifíciles,simplementeporque

ya se han “aclimatado”. Se dice que

un terciode laspreguntasson fáciles.

Bien,empieceporellas.Encuéntrelasy

respóndalas.Si ha aprendidobien los

fundamentos, en este grupo de pre-

guntasfácilessegurasseincluyencasi

todaslasdeROI,EVMyCPM.Elobje-

tivoenestaprimerapasadaesterminar

en 50 minutos con 50 preguntas se-

gurascontestadas.Elrestodelaspre-

guntasquenosabeconcertezapuede

haberlasrespondidoono,peroesim-

portante que las deje “marcadas para

revisar”. Si ha respondido 50 pregun-

tasconseguridad,tendrá150pregun-

tasmarcadaspararevisar.Siconsume

los 50minutos conmenos preguntas

contestadas,nosepreocupe:nosiga

buscandopreguntasfáciles,marqueel

restopararevisarysigaconelsiguiente

paso.Siconsiguecontestar50pregun-

tasantesde50minutos,tampocosiga:

marqueelrestopararevisarysigacon

elsiguientepaso.


www.proiectus.es

56


2.En las siguientes iteraciones, olvídese

delaspreguntasquehacontestadosin

dudar. Haga que la interfaz le muestre

solamente las marcadas para revisar.

Asegúrese de que contesta todas las

preguntas. Vaya desmarcando aquellas

quenoquieravolverarepasar.Objetivo:

25preguntasmarcadaspendientesan-

tesdelosúltimos40minutos.

3.Después,dedique30minutosa resol-

verlaspreguntasmarcadaspendientes,

contestándolasdefinitivamente (quite to-

daslasmarcas).

4.Porúltimo,dediquelos10 minutosfinales

arepasartodoelexamen.Esimportan-

tequeseaseguredeque contesta to-

das laspreguntas, yaque 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 pre-guntas marcadas pendientes siguiendo la estrategia indicada arriba, nos quedaría una gráfica como esta:

Por ejemplo, si le quedan 100 minutos, de-bería tener (100-10)*5/6=75 preguntas pen-dientes marcadas para revisar. El objetivo de hacer disminuir el número de pregun-tas marcadas pendientes puede ayudarle a mantenerse enfocado y darle confianza du-rante 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, cuan-do llegue a un punto de control (¿cada me-dia hora? ¿cada hora?) puede representar el punto indicando cuántas quedan pendien-tes en ese momento, a modo de burndown chart.

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

www.proiectus.es

57


EL ROL DEL DIRECTOR DEL PROYECTO EN EL CLIENTE

anTonio MarTelTitulado 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 ca-naria. 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 departa-mentos de desarrollo software mediante la aplicación de metodologías ágiles.

Hay muchas formas de denominar a la persona que cumple las funciones de Di-rector 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 per-sona de nuestra propia organización la que va a representar al ‘negocio’ en el proyecto suele denominársele Product Manager o incluso Business Analyst se-gún la empresa que le haya dado el car-go. Personalmente, quizás por el tipo de proyecto que habitualmente gestiono, me siento más cómodo llamándolo simple-mente Director del Proyecto en el Cliente.

Lo llamemos como lo llamemos, cumple

una función muy importante para el éxito de un proyecto. Es el encargado de deci-dir qué funcionalidades tendrá el produc-to 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 departamen-to, sino que deberá tener en cuenta los requisitos de toda su empresa.

Cuando comenzamos un nuevo proyec-to, el Director del Proyecto en el cliente y todos los usuarios interesados en el pro-ducto final tienen un montón de ideas y grandes expectativas para el nuevo siste-ma. Lamentablemente, ningún proyecto, por grande que sea, puede contemplar to-das y cada una de las sugerencias de sus usuarios. Algunas ideas serían irrelevan-tes para la mayoría, otras funcionalidades


www.proiectus.es

www.antoniomartel.com

58


serán demasiado costosas de implemen-tar 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 pro-ducto, tendrá que priorizar las caracterís-ticas más importantes y descartar aque-llas que aportan menos valor al resultado final.

Para explicar hasta dónde llegan sus res-ponsabilidades 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 Direc-tora del Proyecto y tendrá que trasladar a la empresa contratada todos los requisitos y necesidades que el nuevo sistema debe-rá cubrir.

Elena tiene una visión muy clara de lo que quiere y está muy ilusionada con el proyecto. También los están los respon-sables de IT, marketing y ventas que han elaborado una exhaustiva lista de funcio-nalidades 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-

dosamente todos estos requisitos en un cuaderno.

Al segundo mes de comenzado el proyecto Elena se da cuenta que el Equipo de Tra-bajo en la empresa desarrolladora está en-tregando de 4 a 6 nuevas funcionalidades a la semana y que esta parece su capaci-dad 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 nue-vo cuaderno.

Primero solicitó al Equipo de Trabajo que hiciera un esfuerzo para entregar estas diez funcionalidades cada semana. Lamenta-blemente, no muchas más funcionalidades eran entregadas y, lo que es peor, se co-menzaba 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 des-moralización y el estrés iban a dominar el proyecto.

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 es-perar a una futura versión. Desde luego, la funcionalidad similar al Clippy de Windows

www.proiectus.es

59



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

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 pro-ducto 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 aporta-ban. Si preguntaba directamente al Equipo de Trabajo en cuantos días podría estar hecha cada una de las funcionalidades sa-brí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.

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 funciona-lidad. Si en cambio, había dos funcionali-

dades de aproximadamente el mismo valor para la empresa pero tardaríamos 5 días en desarrollar una de ellas cuando la segun-da 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í sabe-mos que es aproximadamente 5 veces más grande que una fresa y que la fresa gus-ta 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.

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 so-bre 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 cons-truye lo que realmente aportará valor a su empresa. Todo un papel para Elena ¿no creen?

Fuente: FlickrAutor: Bill sinser

www.proiectus.es

http://flickr.com

60


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

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

www.proiectus.es

https://www.youtube.com/watch%3Fv%3D502ILHjX9EE

https://www.youtube.com/watch%3Fv%3D502ILHjX9EE

61


GESTIÓN DE LA CALIDAD EN LOS PROYECTOS DE CONSULTORÍA

viCenTe r. MerCHán rodrÍGueZConsultor 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, desarro-llando 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.


1. INTRODUCCIÓN

Antes que nada un agradecimiento a la per-sona que dirige la revista y al equipo que con-forman.

Este artículo se motiva por los resultados ob-tenidos 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 par-ticularidad al igual que el resto de proyectos clásicos, de investigación o industrial; los cua-les demandan un conjunto de actividades ne-cesarias para alcanzar el objetivo propuesto y el rendimiento esperado.

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

se ciñe a un alcance determinado de trabajo, muy concreto, limitándose a analizar y estudiar la información disponible acerca de los aspec-tos técnicos, económicos, financieros y ries-gos 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 re-gulan la contratación y ejercicio en el ámbito público1.

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 con-tratación pública, de igual manera, debe ser observada por toda entidad contratante del sector estatal2.

www.proiectus.es

62


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

Un aspecto importante que se debe involu-crar desde el mismo momento que empie-za 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 de-terminadas. Este primer acercamiento deja una buena o mala impresión ante el clien-te, 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.

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 ase-gurar las actividades necesarias para que un proyecto sea eficaz y efectivo3.

Siendo así, la calidad en el proyecto de con-sultorí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 es-pecífico, desde que se firmó el contrato con el cliente contratante.

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

2.PLANIfICACIÓN DE LA CALIDAD

El proceso de planificación de la calidad se lle-vó 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

Fuente: FreeDigitalPhotos.netAutor: Stuart Miles

www.proiectus.es

http://FreeDigitalPhotos.net

63



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

El proyecto presentó complicaciones. Se de-bió 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 tiem-po 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

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

más, como el tiempo era corto, aplicábamos buenas prácticas sobre la marcha como de-tecció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 ha-cía. Conocía muy bien su trabajo y el área de conocimiento materia del contrato, sin em-bargo, fue importante

inspeccionar de manera detallada cada uno de

los productos y verificar su consistencia lite-raria acorde con los requerimientos estableci-dos. Este trabajo lo realizó pares en la mate-ria. Cada producto tenía el control de calidad requerido, se manejaba una lista de lecciones aprendidas en cada revisión las mismas retro-alimentaban los productos siguientes que en el orden de cinco fueron los que consolidaron el producto final.

Al final del camino el producto final denomina-do: Informe Ejecutivo, fue presentado a tiem-po tras una validación con el grupo adminis-trador del contrato y beneficiarios del servicio de consultoría que fueron parte de la institu-ción contratante. Lo que nos demuestra que la Planificación de la Calidad funciona.

Fuente:FreeDigitalPhotos.netAutor: Stuart Miles

www.proiectus.es

http://FreeDigitalPhotos.net

64


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

ment Institute, Inc., 2013.

www.proiectus.es

65


ENTREVISTA A jAVIER zAYA MARTÍN

En primer lugar, queremos agradecer a Ja-vier su interés en participar en este número.

Muchas gracias a la revista por contar con-

migo.

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

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

Era algo que tenía pendiente pero, preci-

samente por estar con la cabeza centrada

en este “pequeño salto”, no había podido.

Por tanto, la satisfacción es mutua.

1. Después de más de 20 años gestio-nando proyectos TIC para la Adminis-tración Pública, ¿cuál consideras que es el principal reto al que se ha de enfren-tar un director de proyectos para poder cumplir con los objetivos de un proyec-to?

Cuando lleve esos 20 años, podré respon-

deros. “Sólo” llevo 19 años de carrera profe-

sional, y 16 gestionando proyectos.

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 ob-jetivo compartido, es posible superar las múltiples barreras que aparecerán durante


Javier ZaYa MarTÍnDirector 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 de-legació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.

www.proiectus.es

66


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

Fíjate que doy por hecho que aparecerán

obstáculos, problemas, habrá crisis (inter-

nas, con el cliente, con los usuarios...). Sin

embargo, y como os digo, siempre que to-

das las partes tengan claros los objetivos,

las condiciones de partida, los condicionan-

tes... esos obstáculos se podrán superar. Y

ése es precisamente el reto del Director de Proyectos, garantizar las condicio-nes 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 ex-pectativas (propias y del cliente), priori-zando/negociando... Y os aseguro que no

es tarea fácil.

Dándole la vuelta a la pregunta, “¿qué obstá-

culos impedirán que un Director de Proyec-

tos cumpla con los objetivos del proyecto?”

mi respuesta no podría ser más estándar:

• Cambios en el alcance del proyecto (Sco-

pe Creep)

• Poco tiempo para completar el proyecto

(plazos no realistas)

• Presupuesto inadecuado

• Recursos inadecuados (aparte del presu-

puesto)

• Requerimientos críticos mal especifica-

dos (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 ha-

bilidades críticas

• Miembros clave del equipo sin el nivel

adecuado de autoridad

• Tareas críticas del proyecto entregadas

tarde

• Pruebas inexistentes, incompletas o in-

adecuadas

Y todos ellos, en mi opinión, son consecuen-

cia de una mala gestión (y consenso/alinea-

ción) de los intereses de todos los implica-

dos por parte del Director de Proyecto.

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

www.proiectus.es

67


condiciones de partida difíciles de asumir

(por las razones que sea) y hemos intentado

reconducir, con mayor o menor éxito. Me re-

fiero a proyectos aceptados a sabiendas de

que el presupuesto o el plazo son insuficien-

tes, sin el equipo adecuado, sin el conoci-

miento previo adecuado, sin Project Charter,

sin participación activa del cliente... Y aún así

los hemos sacado adelante.

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 pro-puesta?

La forma en que están redactados los plie-

gos de muchas licitaciones públicas, y los

problemas que posteriormente supondrían

para el proyecto de respetarse con escru-

pulosidad, darían para un monográfico en

la revista. Miguel Quintanilla ya apuntó en

el primer número algunos problemas deri-

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

vamente bajadas “cuasi-absurdas” en el pre-

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

Ciñéndome a la pregunta, y aunque posi-

blemente os sorprenda mi respuesta, ho-

nestamente debo responder que sí, que

considero acertado introducir “un plan de trabajo” como criterio objetivo de va-loración. Ahora bien, como acertadamen-

te habéis indicado, antes de poder elaborar

ese “primer plan” las empresas deberían co-

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

sejería, Dirección General, Servicio, Centro

Directivo... ha hecho sus deberes y sabe qué

es lo que realmente necesita o quiere.

En cualquier caso, fijaos que hablo de “UN plan de trabajo” o un “primer plan”, no de “EL plan de trabajo”. ¿Por qué? Preci-

samente por lo que apuntáis. En fase de plie-

go/oferta no se conocen con exactitud los

requisitos del proyecto. El alcance no está


www.proiectus.es

68


claramente delimitado. Es más, posiblemen-

te el cliente (Sector Público) ni siquiera sepa

por qué necesita ese nuevo producto o ser-

vicio. En el momento de publicar los pliegos,

sólo sabe que dispone de cierto presupues-

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

que los mismos que le dijeron que ese pre-

supuesto era suficiente se han encargado

de detallar y especificar al máximo, estiman-

do costes, márgenes y plazos de ejecución

razonables).

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

rimientos, evaluación de alternativas,

estimación de esfuerzos, dimensiona-

miento del posible equipo de proyecto,

estimación de costes medios, estima-

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

• Esos pliegos se publican o se hacen lle-

gar de alguna manera a las empresas

que, en igualdad de condiciones, cuen-

tan con un tiempo razonable para reali-

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

tido?) para responder a cuantas pre-

guntas le formulen. De esta forma, es

posible que aparezcan nuevos requeri-

mientos o se aclaren aspectos dudosos

de los pliegos.

• Teóricamente, y de forma bastante ra-

zonable, si la estimación inicial (inter-

na) 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 licitado-

ras, bajo los mismos supuestos, habrán

llegado a números bastante similares, o

no. ¿Por qué las discrepancias? Diferen-

tes costes de estructura que repercuten

en diferentes costes por perfil, disponi-

bilidad local de recursos, conocimiento

suficiente de la tecnología/cliente, expe-

riencias previas similares... y diferente nivel de madurez en la ejecución de proyectos (cuanto más acostumbrados

estemos a ejecutar proyectos, mejor lo

www.proiectus.es

69


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

sidero claves:

| Contemplar explícitamente la vo-latilidad, incertidumbre, com-plejidad y ambigüedad inheren-tes a todo proyecto en esta fase inicial, definiendo unas horquillas o

márgenes de «movilidad» razonable

dentro de nuestras condiciones de

contorno.

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

CoW).

| Y, en base a la metodología exigida

en pliego u ofertada, plantear la ne-

cesidad de contar con «algo» tangible

(una especificación formal de requisi-

tos – ERS de Métrica, o un Product

Backlog de Scrum...) ANTES de po-der plantear siquiera una estima-ción realista del cronograma del proyecto.

• Finalmente, en base a las ofertas pre-

sentadas, y asumiendo un proceso de

adjudicación objetivo, limpio y honesto,

al adjudicatario será aquella empresa

que maximice los criterios de adjudica-

ción.

Por todo esto, y como debemos creer en

la corrección de los procedimientos, es

por lo que considero razonable, necesa-

rio y hasta “sano” para la profesión, que

se introduzca el plan de trabajo como

criterio objetivo de valoración de pro-

puestas.

Con respecto a la segunda parte de la pre-

gunta, y dado que la situación de partida an-

terior es inusual (por no decir, irreal), nunca me he encontrado con un proyecto en el que el plan de trabajo final fuera siquie-ra 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.


www.proiectus.es

70


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

Sin duda. Considero completamente factible

aplicar metodologías ágiles. Sólo es necesa-

rio cierta labor de “evangelización” y forma-

ció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 en-

foques contractuales, hitos de facturación

(idealmente, uno por release)...

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

tente entre requerimientos, coste y calenda-

rio, pasando de la habitual en metodologías

predictivas (Waterfall), en la que los requeri-

mientos condicionan el coste y el plazo en

base a un plan preestablecido, a otra “inver-

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

Modelo Predictivo (Waterfall):

[Coste, Calendario] = f (Requerimientos)

Donde f () es el Plan de Proyecto para esos requeri-mientos que nos vienen dados

Modelo Adaptativo (Agile):

Funcionalidades = f (Coste, Calendario)

Donde f () es la “visión” que podemos tener del siste-ma, 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, deriva-

rí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 ries-

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

nes...

Contras, los derivados de una deficiente asi-

milación del nuevo paradigma, como, por

ejemplo, pretender mantener y respetar un

www.proiectus.es

71


plan de proyecto rígido “en paralelo” a una

ejecución ágil y adaptativa, plantear unos hi-

tos de facturación acordes con un modelo

en cascada (análisis, diseño, construcción,

puesta en marcha)...

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

demos la aplicación “juiciosa y con criterio”

de unas u otras (o ambas a la vez). Personal-

mente, abogo por la aplicación simultánea

de ambas metodologías, aprovechando “lo

mejor de cada casa” y enriqueciendo nues-

tra labor como PM/facilitador. Como leí hace

tiempo, “Así como en el más Ágil de los pro-

yectos Á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”.

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 encorse-tada en prácticas tradicionales y adere-zadas con RPTs (relaciones de puestos de trabajo) obsoletas?

Buena pregunta. Sin embargo, me temo

que no hay respuesta sencilla, clara y direc-

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

tores Generales, Jefes de Servicio, Interven-

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

El “argumento de venta”, en cualquier caso,

creo que es potente: el cliente (alguien den-

tro de la organización con capacidad de

decisión, habitualmente el Director Funcio-

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

mando forma su producto. Participará en

la planificación de las iteraciones, sabien-

do qué tendrá al finalizar cada una de ellas.

Sus técnicos, si así se decide, también po-

drían formar parte del equipo de proyecto,

facilitando la posterior transferencia de co-

nocimiento.


www.proiectus.es

72


Donde más problema veo, como ya apunté,

es en el área de Contratación e Intervención.

Mientras los hitos facturables se sigan plan-

teando en términos de “Fases y Entregables

de Proyecto”, según su entender (básica-

mente las fases habituales de Métrica 3: Es-

pecificación Funcional del Sistema, Análisis

del Sistema, Diseño, Construcción, Prue-

bas...), y esas fases se estimen (en tiempo

y presupuesto) en base al peso porcentual

que, históricamente, hayan tenido en los pro-

yectos de desarrollo de software que ellos

hayan ejecutado (x% Análisis, y% Diseño y

Construcción...) las metodologías Ágiles ten-

drán difícil encaje. Quiero decir, podremos

abordar la ejecución del proyecto en térmi-

nos ágiles, con implicación de los usuarios,

el Product Owner, etc. De nada nos servirá

a la hora de intentar emitir la primera factu-

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

tema, 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 docu-

mento, y cuál es la planificación, etc. Y ten-

dremos que hacer “encaje de bolillos” con

ellos planteándoles “equivalencias” absur-

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

siderarlo incumplimiento...”.

Si a todo eso le unimos el hecho de que,

con las metodologías ágiles, no estamos li-

mitados a un sólo tipo de contrato (precio

fijo cerrado, plazo fijo), la necesidad de ges-

tionar 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 con-tratació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 con-tratos? ¿el cliente o el proveedor? ¿pro-pondrías algún otro tipo de contrato?

No quiero generalizar. El modelo en sí mis-

mo no es malo, y se ha empleado con éxi-

to en miles de contratos. La Administración

tiene, entre otras funciones, que administrar

el dinero público con criterios de austeri-

dad, 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 contabili-

www.proiectus.es

73


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

ta, además, que antes de aceptar la factu-

ra 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/repriorizacio-

nes acordadas, etc.

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

cuado? 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 clien-

te es juez y parte. Él decide cuándo conside-

ra cumplido un hito, cuando paga, cuando

hace la vista gorda y cuando no.

Como ya nos contó Mike Griffiths en el nú-

mero anterior, en UK fue necesario replan-

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

supuesto fijo). Según lo que más interese al

cliente en cada contrato concreto, así debe-

ría gestionarse la contratación del proyecto.

Por otra parte, los aspectos legales y es-

tructurales de los contratos «ágiles» debe-

rían ser los mismos que para contratos de

servicios de desarrollo «tradicionales». La

diferencia clave está en el enfoque y enten-

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

bilidades legales, garantías...). El éxito de

un proyecto no es consecuencia de lo bue-

no o malo que es el contrato, sino de las

relaciones de éxito establecidas entre las

partes, basadas en la colaboración, trans-

parencia y confianza. Los contratos reflejan

lo que la gente espera, sus posibles mie-

dos y las actuaciones y contingencias para

evitarlos. Por todo esto, un contrato «ágil»


www.proiectus.es

74


debería contener mecanismos que sopor-

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

6. ¿Qué consejos podrías darnos para gestionar los conflictos que surgen con los clientes cuando éstos no está sa-tisfechos con el producto resultado del proyecto? ¿y para gestionar los con-flictos que puedan surgir en el seno de nuestro propio equipo?

La “receta” es la misma en ambos casos:

Comunicación, Comunicación, Comunica-

ción.

Debemos ser conscientes de que el proyec-

to 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é an-

tes: transparencia, confianza y colaboración.

Y debemos intentar alinear los intereses de

todas las partes, gestionando adecuada-

mente sus expectativas, sabiendo que no

siempre será posible.

Si hemos tenido éxito implicando a las par-

tes en la toma de decisión, incluyendo al

propio cliente, y gestionado bien sus ex-

pectativas (comunicando adecuadamen-

te el avance, la situación y los riesgos del

proyecto) minimizaremos cualquier posible

insatisfacción con respecto al producto re-

sultado del proyecto. Al cliente no le queda-

rá otra opción que responsabilizarse de las

decisiones tomadas, en las que habrá par-

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

tión del cambio).

Y, con respecto a los conflictos internos,

debemos estar siempre atentos, “leyendo”

el ambiente. Como Directores de Proyec-

to, somos facilitadores, somos coaches/

mentores, debemos saber cómo gestionar

personas, conociendo sus fortalezas, sus in-

tereses, sus aspiraciones... Debemos comu-

nicar. Debemos ser justos. Y debemos crear

las condiciones para que cualquier conflicto

se resuelva antes de que impacte en la eje-

cució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 responsa-

bilidad.

No es fácil gestionar un equipo de perso-

nas y hacerlo funcionar de forma coordi-

nada. Requiere cierta habilidad y pararte a

www.proiectus.es

75


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

peñan”. Y por eso, en la medida de lo posi-

ble, intento aplicar un liderazgo “de apoyo”

(supportive leadership):

• Reconociendo que todos los miem-

brosdemiequipo(yyomismo)tene-

moslacapacidadoelpotencialpara

incrementarnuestrorendimiento.

• Estableciendo objetivos de alto rendi-

miento.

• Reforzando positivamente el trabajo

bienhecho.

• Proporcionando feedback frecuentemen-

te, transmitiendo el convencimiento acer-

ca de nuestra habilidad/capacidad para

completar las tareas asignadas.

• Dando a los miembros del equipo la

oportunidad de participar en tareas o

proyectos que supongan un desafío cada

vez mayor.

• Proporcionando a los miembros del

equipolosinputs,lainformaciónylos

recursos necesarios para lograr sus

objetivos.

• Motivándolos para que permanezcan

centrados en el momento y proyecto pre-

sente, no preocupándose por aconteci-

mientos negativos del pasado.

7. Por orden de prioridad, ¿qué áreas de conocimiento del PMBOK® (Project Ma-nagement Body of Knowledge) encierran mayor dificultad a la hora de dirigir pro-yectos para la Administración Pública?

Lo tengo claro:

• Gestión del Alcance: que complica/afec-

ta la Gestión del Coste y Calendario del

Proyecto.

• Gestión de los Stakeholders: tendemos

a olvidar al usuario final, o al Ciudadano.

Por otra parte, muchas veces el Spon-

sor/Product Owner no está o no aparece

cuando se le necesita.

• Gestión de Riesgos: es crucial hacer

una correcta identificación y estimación

del impacto/coste de los riesgos del pro-

yecto.

8. Fuiste uno de los primeros PMP® (Pro-ject Management Professional) certifica-dos en España, ¿qué te ha aportado la certificación a lo largo de tu carrera pro-fesional?


www.proiectus.es

76


Quitando lo que me ha supuesto en térmi-

nos de “crecimiento profesional personal”

(la conciencia de mi propia valía, refrenda-

da por una certificación internacional de

reconocido prestigio), en España, hones-

tamente, muy poco. Es cierto que desde

principios del 2005 hasta ahora la situa-

ción ha mejorado muchísimo, y ya se nos

reconoce cierto “saber”, cierta experien-

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

té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 inclu-

yó en diversas licitaciones internacionales

en las que participó mi empresa, precisa-

mente por ser un criterio a valorar, pero no

pasó de ahí. Si finalmente resultó adjudica-

taria de alguno de aquellos proyectos, yo

no lo dirigí.

Fuera de España, por contra, sí que percibí

claramente un cambio. Como muchos otros,

he tenido mi CV publicado en portales de

empleo extranjeros prácticamente desde el

año 2000. Tan pronto lo actualicé con mi

flamante PMP hubo un incremento conside-

rable en las ofertas que me llegaban, sobre

todo de USA y UK. Y algunas eran económi-

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

nado como el primer día.

9. Cambiando de tercio, no queremos desaprovechar la oportunidad para pre-guntarte sobre cómo se valora la profe-sió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 he-

cho, 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 In-

dustry Training Organisation (the NZ ITO), as

national bodies representing project mana-

gement in New Zealand, to make a submis-

www.proiectus.es

77


sion to NZQA about the need for specialist

project management qualifications on the

NZQF (NZ Qualification Framework)

[...] 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 accessibili-

ty of project management education and tra-

ining; and the place of New Zealand project

management qualifications alongside indus-

try credentials such as the PMP, CAPM and

PRINCE2.

[...]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.”

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.

• More than a quarter of organisations sur-

veyed do not undertake any form of stra-

tegic review to track the benefits realised

by the business.

• Findings indicate that 70 percent of New

Zealand companies have experienced

at least one project failure in the past 12

months.

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

ted project deliverables.

• Nearly 60 percent of New Zealand com-

panies fail to consistently align their pro-

jects with corporate strategy.

• In the past 12 months, 98 percent of tho-

se surveyed completed [fewer] than five

projects; however, the amount of money

spent is significant with 44 percent of

companies spending more than $15 mi-

llion on their projects over this period.

• 68 percent of companies do not always

have an effective Sponsor to provide

clear direction for the project or to esca-

late problems when necessary.

“…I absolutely agree that project manage-


www.proiectus.es

78


ment qualifications are strategically impor-

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

meframes and budgets and in the Financial

Sector, where projects incur significant cost

overruns.”

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 Ins-titute) de Nueva Zelanda?

Sí, ya me he unido al Capítulo de NZ (http://www.pmi.org.nz), concretamente a la sub-

branch 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 “tradicio-

nal”, de forma que sin contactos o experien-

cia local (incluidas actividades de volunta-

riado), 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 direc-

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

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

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

www.proiectus.es

http://www.pmi.org.nz

http://www.pmi.org.nz

79


ENTIDADES COLABORADORAS

www.proiectus.es

http://www.desic-sl.com/

http://www.inerza.com/

http://www.inventiaplus.com/

http://www.isidrohdez.com/

http://www.opencanarias.com

http://www.proiectus.es/

http://www.spegc.org/

http://www.eii.ulpgc.es/

http://www.laspalmasgc.es/

80

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 obraSe 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.esE-mail: [email protected]


mailto:revista%40proiectus.es?subject=

Revista Proiectus nº 3

Engineering

Transcript of Revista Proiectus nº 3