¿Unir PMBOK® y PRINCE2®?

(Trobareu versió en català més avall) El pasado 22 de junio, en sede UOC pero en el contexto del capítulo de Barcelona del PMI (estrenábamos convenio de colaboración entre las dos entidades), Glòria Segura, una de las profesoras de nuestro equipo docente de Gestión de Proyectos, presentó una ponencia de título provocador: “Gana uniendo PMBOK® y PRINCE2®”. Hablar de PRINCE2, el método de gestión de proyectos del gobierno británico (Axelos) y considerado competidor directo del PMBOK del PMI, en un contexto del PMI, era una oportunidad para la polémica; pero también una oportunidad para darlo a conocer -es todavía poco usado en nuestro país-, y para, sobre todo, exponer las ventajas de utilizar los dos marcos de trabajo de forma colaborativa, aprovechando las fortalezas de ambos, y obtener así un método de gestión de proyectos aún mejor. Tanto si ya hemos adoptado (o queremos adoptar) PMBOK o PRINCE2, Glòria defendió que es posible buscar esta confluencia, añadiendo los puntos del uno que puedan complementar al otro en positivo. Por parte de PRINCE2 estos puntos serían: La gran relevancia que se le da a la justificación del proyecto, desde su inicio hasta después de su cierre, definiendo también mecanismos para ser capaces de tomar la difícil decisión de parar un proyecto cuando se prevé que no dará los beneficios que lo justifican. La robusta estructura organizativa de gestión de cada proyecto que tiene en cuenta los diferentes intereses (de negocio, de usuario y de proveedor) en la toma de decisiones, con roles y responsabilidades bien definidos y detallados. La gestión por excepción, que permite delegar con control, definiendo tolerancias y...

Realización de beneficios en Informática

Venimos predicando por aquí que, aunque entendemos la fascinación por la elegancia de un algoritmo o por la robustez de un artefacto, las TIC tienen sentido si resuelven problemas de la gente y de la empresa y… si la gente y la empresa son capaces de extraer los beneficios de la aplicación de la tecnología para resolver sus problemas. En eso consiste la adopción y uso efectivo de las TIC o, si nos ponemos metafísicos, la diferencia entre el mundo de los objetos y el mundo de los significados, el mundo de lo social. En el fondo, como decía Keen, éste es el sentido del estudio de los sistemas de información. Reedición de clásico de John Ward sobre Gestión de Benficios En el nivel macroeconómico, la realización de beneficios de la informática es una combinación de las inversiones en IT y en “capital organizativo”: el esfuerzo dedicado a cambiar la forma de tomar las decisiones y los procesos de trabajo, utilizar la información, desarrollar el talento o relacionarse con el entorno. Esto se llama la teoría de la complementariedad, desarrollada por Brynjolfsson y otros, y cuenta con evidencias cuantitativas que, por ejemplo, han llevado al Instituto de Estadística norteamericano a cambiar su manera de medir la productividad o contabilizar los activos intangibles de las empresas. En el nivel local, en cada organización, la efectividad de la informática parece depender también más de factores organizativos, sociales y culturales. “Típicamente, los beneficios se consiguen a través de cambios intensivos en las prácticas de negocio y la toma de decisiones”, decía Markus, uno de los pioneros del estudio de la gestión de...

De techie a manager

Muchos buenos ingenieros informáticos piensan en hacer el salto a cuadros intermedios o jefes de proyecto de TI. Frecuentemente reciben el apoyo y el ánimo de sus colegas, que proviene de una admiración genuina: si tú eres el mejor o uno de los mejores de entre nosotros, tú puedes ser el jefe o puedes ser jefe en otro sitio. Pero la transición y el encaje no son fáciles; y no es igual ser técnico y colega que jefe. Como dice Scott Cromar, autor de uno de los manuales sobre esta clase de transiciones, el caso del técnico convertido en gestor es una los ejemplos más genuinos del principio de Peter, según el cual, en una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia. Resulta muy frustrante para la empresa, para sus colegas y, sobre todo, para el interesado. Bulldozers: La mítica Caterpillar d6c Hace poco escribí un decálogo de las preguntas que debe hacerse el ejecutivo de cualquier cosa. Pues bien, un colega me ha animado a intentar aplicarlo a la informática o a los trabajos directivos en informática (…y me ha pedido sintetizarlo para que quepa en el post). Veamos. 1. ¿Qué trabajo hay que hacer?  Tan importante o más que el proyecto, la posición o la carrera, es imaginarse (y, si es posible, conocer  de primera mano) un martes cualquiera y pensar si es el martes que queremos para nosotros y, a cambio, qué dejaremos de hacer. De hecho, en el trabajo ejecutivo no “se hacen cosas”, sino que se hace que otros las hagan, ofreciéndoles guía, ayuda y realimentación.  El trabajo directivo, decía...

La confianza en la gestión de programas y proyectos (y II)

En la primera parte de esta entrada, explorábamos la dificultad de gestionar el cambio y asegurar la implantación y el uso de la informática en proyectos y programas complejos, mientras pedíamos a los espónsores, los líderes y gestores de proyectos reconocer la naturaleza política de esta clase de esfuerzos, emplear tiempo e inteligencia en el análisis y la intervención, establecer relaciones de confianza y utilizar metodologías ágiles. El Padrino: Keep your friends close, but enemies closer. Alrededor de los años 2000, diferentes autores, como Kumar y colegas, Markus, Ward, Esteves y Pastor, han estudiado esta situación en la implantación de ERPs. En esta clase de proyectos, parece posible establecer una aproximación racional y de arriba abajo en organizaciones jerarquizadas que persiguen objetivos operacionales de mejora del rendimiento bien conocidos. También es posible negociar y llegar a acuerdos si las partes tienen poderes equivalentes y se conocen bien los intereses de cada lado. Cuando todo ésto no ocurre (y muchas veces en las que ocurre), las relaciones personales y la creación de confianza son una mejor estrategia para manejar la incertidumbre, la negociación y el conflicto; aunque es probable, dicen las evidencias, que el alcance y los beneficios deban reducirse: será posible obtener acuerdos sobre menos cosas y de menos impacto. Más recientemente se han realizado análisis de programas de transformación de IT más complejos. Gregory y otros han acuñado el concepto de ambidexterity, como la combinación de acciones entre el corto y el largo plazo, el enfoque directivo y el colaborativo y la gestión de beneficios locales (sobre cada proyecto) y globales (sobre el programa en conjunto). En los momentos de planificación y diseño,...

La confianza en la gestión de programas y proyectos (I)

Hemos intentado decir cosas aquí de la gestión del cambio, que sean un poco diferentes de los manuales y la formación de usuario que proponen el saber popular y las consultoras. El objetivo de la gestión del cambio es la adopción por la organización de los beneficios de la tecnología y eso tiene que ver, en buena medida, con el poder, las relaciones y los intereses. La gestión del cambio es más importante en programas y proyectos complejos. Hemos intentado mostrar que no es un contenido opinático, tertuliano o del sentido común, sino que se trata también de una prescripción técnica (aunque no sea de la clase de técnica de un algoritmo): o sea que el cambio se puede analizar y se pueden medir y diseñar y ejecutar intervenciones que tengan sentido y sean evaluables. GRAFICA: Cédula real borbónica. Imagen de la exposición de la Hispanic Society en el Museo del Prado tomada por el autor. Los estándares de gestión de proyectos y programas, como el PMI, han ido concediendo mayor importancia al manejo de los interesados (stakeholders), pero en la práctica continúa siendo mayormente una cuestión de cartografiar los riesgos y comunicar y distribuir información. La gestión de programas se basa en la realización efectiva de beneficios (benefits management) para la empresa y desde esta perspectiva se puede hilar más fino. Dicen Daniel y Ward: “Mientras que el análisis y la gestión de interesados se puede considerar una parte de la evaluación de riesgos, su valor real reside en anticipar y determinar las acciones necesarias para atender los temas de los interesados tan pronto como sea posible en el proyecto.”...

Empresas ágiles

Las empresas de todos los sectores están importando últimamente modelos de gestión basados en la organización de la informática en la empresa y, en particular, en las organizaciones cuyo producto es la informática: negocios de internet, fabricantes de software, gestores de plataformas de contenidos o de infraestructura. No sé si es una buena idea, si se tiene en cuenta que los informáticos no son especialmente “organizados”, jeje. Como decía Cusumano, una cosa es hacer software y otra cosa es gestionar una empresa de software. De hecho, primero fue al revés: la informática copió la estructura estandarizada y predecible de los procesos industriales, el famoso PDCA, mediante sistemas de gobierno como COBIT, ITIL o CMMi. Era una forma de intentar superar, con moderado éxito, las organizaciones funcionales clásicas basadas en silos de expertise: los de desarrollo, los de infraestructura, los de operaciones, los de atención al usuario…;  los de SAP, los de Siebel, los de Java, etc. Jim Highsmith John Kotter Muchas organizaciones empezaron a trabajar por proyectos o, al menos, la forma proyecto servía para gestionar iniciativas de compañía más transversales y complejas. Aunque en realidad la gestión de proyectos venía de las empresas industriales: un proyecto es la creación de una planta de producción, un barco o un puente. Los modelos de gobierno de gestión de proyectos, como PMBoK, se usan en las ingenierías y en los departamentos de informática. Como dijimos aquí una vez, la gestión de proyectos no es construir buen software o hacer un puente que no se caiga (que también) sino que es una profesión en sí misma, con reglas, procedimientos, criterios de admisión,...