Project Portfolio Management

La decisión de «dónde, cómo y cuándo» invertir es el mayor reto de la dirección estratégica de los sistemas de información, dicen los colegas Peppard y Ward en su manual ya clásico. El resultado de la planificación estratégica, hemos dicho algunas veces, es una cartera de iniciativas priorizadas de TI, que responden a lo que el negocio considera más importante. A esas decisiones y a su ejecución efectiva se le llama gestión del portafolio de proyectos, o Project Portfolio Management. Contenidos conceptuales del Portafolio de Proyectos de TI PPM (Project Portfolio Management) no es una teoría. Es el espacio práctico donde se encuentran la formación de la estrategia de TI, el gobierno corporativo (o sea, la distribución de las decisiones más importantes en materia de gestión de las TIC en una empresa) y la gestión del día a día (o sea, el trabajo del CIO y del área de informática, junto con el negocio, para crear y mantener productos y servicios). De hecho, la literatura científica y profesional lo ha abordado desde estos puntos de vista, frecuentemente por separado. Es el clavo perfecto si uno tiene su propio martillo. La estrategia de TI ha analizado especialmente los criterios de priorización para conseguir un mejor alineamiento entre los objetivos del negocio y los de TI, sea a través de factores críticos de éxito, gestión de beneficios o un conjunto balanceado de indicadores (el famoso balanced scorecard).El gobierno de TI (IT Governance) ha evolucionado como un conjunto de marcos de trabajo y catecismos omnicomprensivos (los más conocidos son COBIT y unas cuantas ISO, a los que no niego ambición y utilidad)....

La aplicación del Internet de las Cosas en el ámbito de la Industria: el mantenimiento predictivo

(Trobareu la versió en català més avall) Desde su aparición a finales de la década de los 50, la evolución tecnológica en el campo de la informática y las telecomunicaciones han evolucionado seguido dos grandes leyes[1]: la Ley de Moore (Gordon Moore, 1965) y la Ley de Bell (Gordon Bell, 1972). Por un lado, la Ley de Moore enuncia que el número de transistores en un circuito integrado se duplica cada dos años aproximadamente gracias a la evolución tecnológica de los procesos de fabricación de los semiconductores. Los primeros microprocesadores (Intel 4004) se fabricaron a principios de los años 70 con tecnología de 10 micrómetros, mientras que los microprocesadores actuales (ARM Cortex A-53) se fabrican con tecnología de 10 nanómetros (¡como referencia, el diámetro de un cabello es de entre 60 y 80 micrómetros!). Esto supone una reducción de tres órdenes de magnitud en cinco décadas, lo que ha propiciado el aumento de la capacidad de cómputo, la reducción del consumo energético o la optimización de los costes de producción de estos dispositivos. Por otra parte, la Ley de Bell enuncia que, gracias a la evolución tecnológica que propicia la Ley de Moore, cada década aparece una nueva clase de sistemas de computación (incluyendo el sistema operativo, la red de comunicaciones y la interfaz de usuario) que establece un nuevo paradigma de aplicación y una nueva industria. De esta forma, hemos visto como la década de los 90 supuso la explosión de la informática personal y la popularización de Internet, la década de 2000 supuso la explosión de la informática móvil y las comunicaciones celulares, y la década de 2010 está...

Modelos de agilidad en escala

Scrum es probablemente la aplicación más conocida de los principios de agilidad en la construcción de software y en otros ámbitos de conocimiento y de práctica. De hecho, scrum nació a finales de los 80 en el mundo del marketing y del desarrollo de producto. En TI, algunos de los fundadores de scrum fueron parte del grupo que publicó el Manifiesto Ágil. La idea es conocida: cada incremento o mejora de producto (product increment) se puede descomponer en ciclos de desarrollo menores (sprints) de los que se ocupa un equipo pequeño de participantes de diferentes procedencias, incluido el cliente, situados en el mismo espacio físico y dedicados de forma intensa y entusiasta. El despliegue es incremental e iterativo y el resultado siempre es imperfecto, pero se puede poner en producción rápidamente. Algun0s otros artefactos y roles de scrum, como el product owner, el backlog, las reuniones cortas diarias, el scrum master, las retrospectivas y los papelitos pegados en una pizarra forman parte ya del instrumental de la producción de sotware en cualquier parte. Presentación a alto nivel de los artefactos de SAfe Scrum funciona bien en esfuerzos donde el alcance es abierto y los requerimientos pueden cambiar frecuentemente. Va mejor con equipos y proyectos no muy grandes y que no requieran un gran número de interdependencias o integración con otros proyectos o con aplicaciones heredadas (legacy). Funciona mejor con perfiles relativamente homogéneos de desarrolladores acostumbrados a trabajar así. Es una organización muy plana, sin jerarquías ni grandes especialidades. Requiere  una cultura organizativa propicia y tiene una curva de aprendizaje, pero no es dramático. Puede ser bonito, excitante, divertido y los resultados, en general y bajo las condiciones anteriores, pagan. En las circunstancias que hemos descrito, scrum se...

Los productos de TI en la era digital (y II)

El proyecto no ha muerto. Ágil lo ha cambiado todo. La combinación de Ágil y Lean permite potencialmente escalar la agilidad desde proyectos pequeños y auto-contenidos al nivel de la organización de los departamentos de informática y de toda la empresa. A introducir estas ideas dedicamos la primera parte de este post. Seguimos ahora.     7. Los departamentos de TI construyen y mantienen productos y servicios, que sirven a las necesidades de grupos de clientes internos o externos. Esos chismes son flujos de creación de valor para diferentes negocios o procesos empresariales. La creación de un nuevo producto o la sustitución por entero de uno existente tiende a ser un proyecto, pero eso pasa sólo algunas veces. Se podría decir que un proyecto es una parte de un flujo de producción o, a veces, un flujo de producción en sí mismo. El flujo de creación de valor representa la transformación de unas necesidades, convenientemente priorizadas, en unos productos para unos clientes. El flujo de producción tiene que asegurar: 1) el conocimiento y la comprensión profunda de las necesidades muy variadas de un cliente (qué hay que hacer), 2) su valoración y cualificación estratégica y económica (por qué hay que hacerlo y por qué haremos ésto en vez de otra cosa), 3) el diseño, construcción y aprobación del producto de acuerdo con las capacidades existentes (cómo y cuándo lo haremos), 4) la entrega y puesta en producción en todo o en partes y 5) el mantenimiento y protección de los activos creados. 8. Desde un punto de vista, este proceso se puede ver como una máquina, una fábrica, una cadena de...

Los productos de TI en la era digital (I)

Mis posts veraniegos sobre el ocaso de la gestión de proyectos, deliberadamente provocadores, se leyeron bastante y se copiaron en las redes. Lectores y colegas no mostraron desacuerdo, pero me pidieron aclaraciones y avenidas de solución: then, what? Como Hamlet, vivo en las preguntas y tengo más dudas que respuestas. Pero voy a intentar en este y otros posts compartir lo poco que sé o que sabemos, a partir de la experiencia y la literatura profesional y científica. Los proyectos siguen teniendo sentido. Son la mejor, probablemente la única, manera de hacer cosas diferentes de las que hacemos cada día, de poner en tensión la organización para construir cosas nuevas, únicas y transformadoras, que tengan sentido estratégico y económico, rompiendo los silos organizativos. Necesitamos organizaciones orientadas, apasionadas por los proyectos. Necesitamos también modelos, herramientas y profesionales expertos en proyectos. Podemos pasar de cofradías, burocracias y certificaciones, pero no podemos prescindir de gente con la mano rota de reunir personas y capacidades diferentes y hacer que trabajen juntas para construir puentes, fábricas de coches o productos de software. Ni podemos prescindir de lo que hemos aprendido en casi un siglo de práctica profesional. Ágil lo cambió casi todo. Ágil, que pronto cumplirá treinta años, ni es ni se pensó como un modelo integrador y sistemático para construir programas y mucho menos para gestionar proyectos, sino como un repositorio de ideas, principios y prácticas inventados por los propios desarrolladores para hacer su trabajo (¡desarrollar software!) más efectivo, valioso y divertido. Los valores y principios de ágil han impregnado (para bien) la gestión de proyectos, en la informática y en la empresa....

¿Hacer estrategia o hacer planes de TI?

Venimos repasando de vez en cuando el estado de la planificación estratégica de TI, lo que en algún momento se llamó SISP (Strategic Information Systems Planning). Sigo haciendo, investigando y enseñando sobre esto. Hace no mucho decíamos aquí: puedes no tener un plan estratégico de sistemas de información, pero no puedes dejar de tener una estrategia de sistemas y tecnologías de la información. Si no, alguien (tus jefes, tus proveedores o tus usuarios) la tendrá para ti. [gview file=»http://informatica.blogs.uoc.edu/wp-content/uploads/2018/10/IT-STRATEGY-IN-THE-MAKING-BLOG.pdf»]   Pero es verdad que este espacio, en la teoría y en la práctica, ha cambiado mucho desde la aparición de los primeros planes de sistemas en los 1970. Yo suelo explicar el estado de la cuestión con la tabla que veis hoy, basada en la introducción del número monográfico que publicó el Journal of Strategic Information Systems en 2014. El concepto de alineamiento estratégico se ha visto no sé si superado o reforzado por la avalancha de la transformación digital, o sea, la fusión de la estrategia de sistemas y la estrategia de negocio. Ya no se espera que el CIO escuche con atención al negocio y seguidamente diseñe, construya y opere los sistemas, sino que ambas partes trabajen juntas y lideren la transformación. Ya no se pueden pensar estrategias empresariales sin atención a las oportunidades y las capacidades de la tecnología. Por tanto, la capacidad tecnológica ya no es más un atributo del departamento de TI sino una competencia que necesita desarrollar toda la empresa. Los SISP se basaban en entornos empresariales y tecnológicos relativamente estables: alguien podía pensar su estrategia de sistemas en detalle y luego vigilar férreamente su ejecución. Ahora todo es más dinámico, incierto e imprevisible y...