Mostrando entradas con la etiqueta Dirección de proyectos. Mostrar todas las entradas
Mostrando entradas con la etiqueta Dirección de proyectos. Mostrar todas las entradas

viernes, 31 de julio de 2026

Actualización de publicaciones del Project Management Institute (III): "PMBOK Guide 8th edition"

Y con este post cierro la pequeña serie de artículos, tres incluyendo éste, dedicados a las últimas publicaciones del PMI ('Project Management Institute').

Tras haber comentado el estándar para gestión de proyectos y el estándar específico de inteligencia artificial, llega el momento del 'documento estrella' del PMI, es decir, el PMBOK ('Project Management Book Of Knowledge') o, como el PMI puntualiza la guía al PMBOK. 


El contenido del PMBOK

En esta octava edición, el PMBOK (documento de unas 270 páginas), se estructura en cinco capítulos y cinco apéndices. Los capítulos son:

  • 1. Introduction: Un breve introducción explicando la estructura del documento, la relación con el estándar y los principales cambios respecto a la edición anterior

  • 2. Project Management Performance Domain El capítulo más largo y que aporta mayor estructura y conceptos, describe los denominados 'performance domains' (algo así como dominios de desempeño) que, aunque quieren evitar el nombre, son una especie de procesos de alto nivel. Los dominios son:

    • Gobernanza ('Governance')
    • Alcance ('scope')
    • Planificación ('schedule')
    • Finanzas
    • Interesados ('stakeholders')
    • Recursos ('resources')
    • Riesgos

    Por cada uno de estos dominios, y salvo en el caso de la gobernanza en que añade alguna sección adicional, las estructura del discurso es siempre la misma:

    • Conceptos principales que, en esencia, aporta definiciones más o menos explicadas, de los conceptos utilizados

    • Procesos que componen el dominio indicando, aparte de la estructura general de procesos, un cierto detalle de cada proceso en que, aparte de una explicación se esquematiza sus entradas y salidas, y las herramientas y técnicas habitualmente utilizadas. Tantos las entradas y salidas como las herramientas y técnicas sólo se encuentra enunciadas porque la explicación se proporciona en otros capítulos

    • Consideraciones sobre personalización

    • Interacción con otros dominios

    • 'Checklist' de comprobación de resultados ('outcomes').

  • 3. Tailoring Un capítulo no muy largo sobre la personalización / adaptación del marco general a casos concretos donde se argumenta el por qué de esa adaptación, se identifica qué elementos de adaptan y se describe un poco ese proceso de adaptación / personalización.

  • 4. Inputs and outputs Describe todas y cada una de las entradas o salidas que han aparecido en los procesos de los dominios vistos en el capítulo dos. Se trata del orden de cien entradas y o salidas, descritas siguiendo un orden meramente alfabético y aportándose en la mayoría de los casos poco mas que una definición aunque en ciertos casos se detiene bastante más.

  • 5. Tools and techniques De forma muy similar a lo hecho con entradas y salidas, se censan por orden alfabético, todas las herramientas y técnicas que han aparecido en los procesos de los dominios. En este caso hablamos de una ciento setenta herramientas o técnicas. La descripción de cada una, de nuevo, es irregular, siendo en algunos caso meras definiciones pero, para otras, se aporta bastante detalle.

Tras esto, tenemos cinco apéndices:
  • El primero con el listado de personas que han participado

  • El segundo, de un cierto interés se ocupa de las PMO ('Project Management Office')

  • El tercero habla de inteligencia artificial pero sin grandes aportaciones y supongo que preparando el terreno para lo que sería el estándar que hemos comentado en otro post.

  • Un cuarto apéndice, muy bien desarrollado e interesante sobre 'procurement' que, quizá, debería haberse encajado de alguna forma en el cuerpo principal del PMBOK

  • Finalmente una descripción de cómo ha ido evolucionando el PMBOK a lo largo del tiempo.

Mi valoración


Creo que la mayor diferencia de esta edición (la octava) frente a la séptima edición (que, sinceramente, creo que era muy floja) son los dos capítulos dedicados tanto a entradas y salidas como, sobre todo, el de técnicas y herramientas.

Estos dos nuevos capítulos que, en el fondo, son un complemento a la descripción de los procesos del capítulo segundo dedicado a los dominios de desempeño, aportan valor, información y rigor y recuperan parte de lo que se perdió con esa creo que desgraciada séptima edición del PMBOK.

Aunque  no he hecho una comparación rigurosa, creo que, aún, la primera edición del PMBOK que yo conocí (la que estaba vigente cuando me certifiqué como PMP), la quinta y probablemente la sexta eran más sólidas y estructuradas, pero aún así, esta octava edición reconcilia un tanto con el PMBOK y recupera parte de lo perdido en la séptima edición.

No obstante, sigo sin entender, o tal vez compartir, la diferenciación entre el estándar y el PMBOK que creo que no tiene sentido tal y como está planteada actualmente.

 Igualmente, y de cara a futuras ediciones, creo que sería bueno seguir profundizando en la parte de entradas y salidas y las técnicas y herramientas, alargando más las descripciones y entrando más en materia porque gran parte del conocimiento real y práctico de la disciplina de dirección de proyectos recae en ellas.


Conclusiones


Hemos revisado el contenido del PMKOK (guía del PMBOK realmente) en su octava edición y, aunque creo que tiene margen de mejora, recupera una parte importante del rigor y profundidad perdidos en la séptima edición.


Artículos de este blog relacionados


viernes, 24 de julio de 2026

Actualización de publicaciones del Project Management Institute (II): "The standard for artificial intelligence"

En este breve recorrido por tres documentos recientes y relevantes emitidos por el PMI ('Project Management Institute'), le llega el momento a un documento, un estándar, dedicado al campo de la inteligencia artificial

El nombre del documento es 'The Standard for Artificial Intelligence in Portfolio, Program, and Project Management' y es de muy reciente publicación, en concreto de Junio de 2026, así que, en el momento de redactar este post, no tiene ni dos meses de vida.

Se trata de un estándar que me generó mucho interés porque une una de mis áreas de investigación de mayor interés, la inteligencia artificial, con un área de 'expertise' en gestión como es la dirección de proyectos y porque me parecía importante ver qué tenía que decir la mayor autoridad en dirección de proyectos sobre el caso concreto de la inteligencia artificial

¿Qué me he encontrado?


El contenido del "Standard for Artificial Intelligence in Portfolio, Program, and Project Management"


Nos encontramos ante un documento de mediana extensión, cercana a las 300 páginas.

Antes de ver un poco el contenido, alguna tema relevante a tener en cuenta.

Aunque personalmente tiendo a hablar de forma un poco genérica de dirección de proyectos, en este documento, y siguiendo el modelo del PMI, se distingue entre proyectos, programas y porfolios y, en varios puntos del estándar, la distinción es nítida.

El estándar distingue, y me parece un acierto, entre la IA como producto, como resultado de proyectos, programas y porfolios y la IA como una herramienta utilizable en la propia dirección de proyectos, programas y porfolios. 

Dicho esto, el contenido del documento se estructura en siete capítulos, a saber:


  • 'Introduction:' Una introducción al contenido e intenciones del estándar junto con algún recordatorio de conceptos sobre dirección de proyectos y sobre inteligencia artificial.

  • 'Principles of AI in Project, Program and Porfolio Management:' De la misma forma que el estándar para dirección de proyectos, programas y porfolios establece seis principios, aquí se establecen ocho principios que, aunque se parecen, no son los mismos que los generales. Sin entrar en detalles, sólo señalar cuáles son los principios para el caso de proyectos en materia de inteligencia artificial:

    • Valor estratégico: es decir, foco en la creación de valor.
    • Riesgo: que enfatiza la necesidad de supervisión humana.
    • Gobernanza y cumplimiento normativo: orientado por un lado al alineamiento estratégico y, por otro, al respeto a la legislación y a los principios éticos.
    • Personas y cultura: desglosando entre liderazgo y el equipo de proyecto.
    • Ética y responsabilidad profesional: con foco fundamentalmente en la supervisión humana y en la responsabilidad en el sentido de rendición de cuentas.
    • Involucración de partes interesadas ('stakeholder engagement'): alineando los proyectos con las expectativas de esas partes interesadas.
    • Optimización e innovación: anima a la adopción de nuevas tecnologías y metodologías para conseguir mayor eficiencia, adaptación y calidad.
    • Calidad del dato: como mecanismo para conseguir resultados de calidad, a su vez.

  • 'Performance Domains of AI in Project, Program and Porfolio Management:' Establece cinco dominios ('performance domains') que se asemejan, pero no coinciden, con los dominios identificados en el PMBOK, del que hablaremos en otro post. Los dominios para el caso de la IA serían, según este estándar, los siguientes:

    • Gestionar las expectativas de las partes interesadas sobre la IA
    • Definir el alcance de la IA
    • Definir una arquitectura IA con calidad y responsabilidad
    • Ejecutar objetivos estratégicos
    • Gestionar riesgos e incertidumbres

  • 'Life Cycle management and tailoring activities:' Revisa muy brevemente los ciclos de vida predictivos, adaptativos e híbrido y su traslado a proyectos de IA y luego trata tanto las actividades de personalización ('tailoring') como de ciclo de vida y optimización distinguiendo en ambos casos entre proyectos, programas y porfolios.

  • 'AI in the context of Project, Program and Porfolio Management:' hace el cambio de perspectiva a la aplicación de la IA no como producto sino en la propia actividad de dirección de proyectos, programas y porfolios aportando alguna idea sobre cómo usarla

  • 'Framework for the use of AI in Project, Program and Porfolio Management:' Aporta un marco con unos pasos y consideraciones a tener en cuenta en la dirección de proyectos, programas y porfolios, centrándose en cuatro áreas: establecimiento de un caso de negocio, uso de la IA en proyectos, programas y porfolios, flujo de información y ajuste cultural y organizativo.

  • 'Ethical and Legal considerations for AI use in Projects, Programs and Porfolios:' realiza alguna propuesta en los ámbitos ético y legal, como la existencia de un comité ético


En dos anexos finales identifica, por un lado, algunos esquema de evaluación de la madurez en IA y, por otro, leyes y regulaciones a tener en cuenta. 


Mi valoración


Siendo sincero, debo reconocer que este estándar me ha decepcionado y que soy bastante crítico con él.

Antes de la crítica, decir que me parece bueno que exista este estándar, o al menos una guía en este campo, por parte del PMI, y que me parece acertada la distinción entre la IA como producto de proyectos y el uso de la IA para la propia dirección de proyectos, programas y porfolios.

Pero mi visión positiva casi se acaba aquí y en seguida comienza mi crítica.

En primer lugar, y como ya expresé a propósito del "Standard for project management", esto no me parece un estándar, por más que se encuentre respaldado por ANSI. No es prescriptivo, no es asertivo, no es demasiado accionable y no es claramente certificable. En mi opinión, es más una guía o un marco de trabajo, pero no un estándar, que ANSI y el PMI me perdonen.

Por otro lado, y casi como extensión de lo anterior, lo veo muy ligero, de muy alto nivel, muy de intenciones o ideas, pero de poco detalle y 'accionabilidad'.

Creo que no es demasiado acertado al tratar de forma genérica los proyectos de inteligencia artificial sin distinciones nítidas de tipologías. En mi opinión tiene poco que ver, a nivel de ciclo de vida y gestión, un proyecto de machine learning tradicional como la creación de un modelo predictivo personalizado para una empresa, con el desarrollo de un agente, por ejemplo. 

Me sorprende, y me parece incoherente, que los principios y dominios que se identifican en este supuesto estándar sobre IA, sean diferentes, en lugar de ser una particularización, de los genéricos de dirección de proyectos identificados en el estándar de dirección de proyectos, o los dominios identificados en el PMBOK. Eso es tanto como decir que los principios y dominios genéricos no son tan genéricos, sino que diferentes tipologías de proyectos pueden necesitar principios y dominios diferentes y cuestionar los genéricos.  Como mucho, podría entender que se añada alguno principio o dominio nuevo, pero no que se redefinan todos. No tiene sentido.

También me parece incoherente que si en el caso de la documentación general del PMI, los principios se encuentran en el estándar de proyectos y los dominios y la personalización ('tailoring') en el PMBOK, aquí, en el caso de la IA, todo quepa en el estándar.

En fin, que me ha resultado bastante decepcionante.


Conclusiones


Entre los documentos más recientes lanzados por el PMI se encuentra el estándar para proyectos, programas y porfolios de inteligencia artificial.

Una, en mi opinión, buena iniciativa pero con un resultado, también en mi opinión, criticable y bastante decepcionante.


Artículos de este blog relacionados


viernes, 17 de julio de 2026

Actualización de publicaciones del Project Management Institute (I): "The standard for project management"

Con este post inicio una serie corta de tres artículos (que probablemente se intercalen con posts de temáticas completamente diferentes) en que comentaré y valoraré brevemente algunas de las últimas publicaciones del PMI ('Project Management Institute'), la probablemente autoridad más reconocida a nivel mundial en materia de dirección de proyectos

En ellos, uno en cada post, comentaré brevemente tres documentos, a saber:


  • The standard for project management (ANSI/PMI 99-001-2025)
  • A guide to the Project Management Book Of Knowledge. PMBOK Guide. 8th edition.
  • The Standard for Artificial Intelligence in Portfolio, Program, and Project Management


Antes de los breves comentarios, una pequeña explicación acerca de mis motivaciones.


Motivaciones: la importancia de los proyectos y el PMP


Hasta que en 2018 inicié mi andadura profesional por cuenta propia bajo mi marca 'Reingeniería digital', una parte muy importante de mi carrera ha estado dedicada de una forma u otra a proyectos.

He formado parte de equipos de proyecto, he actuado como jefe de proyecto y director de proyecto de iniciativas de todo tipo, algunas sencillas pero otras muy ambiciosas y de alto presupuesto, y he dirigido equipos que, a su vez, dirigían proyectos.

Y cada vez más fui apreciando la disciplina de la dirección de proyectos y, aún más, la figura del jefe de proyecto. Esta importancia se me hizo especialmente patente cuando los proyectos a que nos dedicábamos estaban dirigidos a clientes pertenecientes a las grandes cuentas de Telefónica Empresas, donde se encontraban la mayor parte de empresas del IBEX y muchas otras empresas y administraciones de gran tamaño y presupuesto. Llegué al profundo convencimiento de lo importante que era la figura del jefe de proyecto para alcanzar el éxito y no me refiero sólo a la figura en sí como un rol abstracto, que también, sino a la cualificación y voluntad de las personas concretas que ejercían ese rol. La relación con el cliente y el éxito de los proyectos, dependían en buena medida de esa figura y de la persona que la ejerciese. 

En 2012, cuando ya realmente no ejercía como director de proyecto sino como gerente, decidí, a pesar de ello, obtener la certificación PMP ('Project Management Professional'), lo cual sucedió en Junio de 2012, hace ahora catorce años, a lo largo de los cuales, y como establece el PMI, he ido renovando esa certificación que aún tengo en vigor y que pienso volver a renovar el año que viene.

Cuando obtuve la certificación, el PMBOK vigente se encontraba en su quinta edición. Desde entonces he adquirido y estudiado las siguientes ediciones, la sexta, la séptima... y ahora le toca a la octava, publicada en Enero de 2025.

Además, me interesó mucho conocer, dado mi interés y dedicación a la inteligencia artificial, que PMI junto con ANSI, habían lanzado también un estándar para proyectos de inteligencia artificial.

La idea, pues, ha sido realizar una nueva actualización y, en este caso, además, compartir con los lectores de este blog un poco del contenido objetivo de los documentos, y otro poco de mi valoración personal. 

Explicado esto, vamos con el primero de los documentos, el 'Standard for project management'


El contenido del "Standard for Project management"


Este estándar ha sido definido mediante una colaboración entre el PMI ('Project Management Institute') y ANSI ('American National Standards Institute'), colaboración que se inició, si la memoria no me falla, con la anterior versión del PMBOK (la séptima).

Aunque se trata de un documento separado, se publica en el mismo volumen que el PMBOK, del cual hablaré en otro post de esta serie.

Según reza en el propio documento, este estándar


provides a basis for understanding project management and how it facilitates intended outcomes.


y, un poco más abajo, dice


The standard describes how project management creates value and benefits in organizations as well as how organizational and project leaders can harness the power of project management for success.

 

Como se pude deducir un poco de estas declaraciones de intenciones, y como insistiré en mi comentario personal, se trata de un documento más descriptivo que normativo.

El documento de poco más de setenta páginas  y se estructura en cuatro secciones:


  • 'Introduction': Establece el propósito del estándar, proporciona un vocabulario de términos y conceptos y ataca algunos aspectos generales de los proyectos como sus características, conceptos de gobernanza, relación con las operaciones de la compañía y las relaciones entre los conceptos de proyecto, programa, porfolio y operaciones.

  • 'System for value delivery': Extendiendo lo ya iniciado en la séptima edición, adopta una visión muy de alto nivel y negocio para hablarnos de cómo los proyectos aportan valor y se sitúan como parte de un sistema de valor. Propone un modelo para conceptualizar ese sistema de valor y a partir de ahí comenta elementos de contexto interno y externo a proyectos, programas y porfolios, establece la relación con el 'product management' e identifica una serie de funciones y roles presentes en los proyectos.

  • 'Project management principles': Identifica y explica seis principios de la dirección de proyectos, a saber:
    • Adoptar una visión holística
    • Enfocarse en el valor
    • Introducir la calidad en los procesos y los entregables
    • Ejercer un liderazgo responsable
    • Integrar la sostenibilidad en todas las áreas de proyecto
    • Construir una cultura de empoderamiento

  • 'Project Life Cycles': Habla de las fases de los proyectos y luego identifica los tres grandes enfoques para la dirección de proyectos (predictivo, adaptativo e híbrido) y proporciona criterios para seleccionar un enfoque u otro. También habla de la cadencia de las entregas, mencionando el despliegue continuo propio de DevOps (aunque sin mencionar a DevOps). Finaliza identificando y describiendo las que denomina cinco áreas de foco, a saber:
    • Inicio
    • Planificación
    • Ejecución
    • Monitorización y control
    • Cierre


Una valoración: ¿Esto es un estándar?


Este estándar es un documento correcto y bien redactado (aunque en el típico estilo profesional austero) y que proporciona un vocabulario y una especie de marco de referencia común, eso sí, un poco abstracto y de bastante alto nivel.

Me parece bueno, a nivel de una disciplina, establecer ese marco de referencia y ese vocabulario comunes y no me parece mal, tampoco, comenzar por un alto nivel para luego ir bajando.

Sin embargo, insisto, es muy alto nivel y en algunas partes un poco abstracto. Le falta mucho bajar a tierra, en mi opinión. si pretende orientar realmente la acción de las organizaciones y de los profesionales.

Y aunque esto sea enmendarle la plana nada más y nada menos que a ANSI, me resisto a ver este documento como un verdadero estándar, porque no detalla nada, no da pautas asertivas, no obliga a nada y no es muy verificable si se está aplicando o no.

La verdad es que esto no es lo que yo entiendo por un estándar.

Hace muchos años, en mis primeros tiempos en Telefónica, me miré muchas normas y estándares del ámbito de las telecomunicaciones, que definían, por ejemplo, protocolos y, desde luego, no tiene nada que ver con esto. Aquello era detalladísimo, normativo, verificable y, todo hay que decirlo, muy farragoso,

No he tenido mucha ocasión de leer directamente estándares o normas del ámbito industrial pero, hasta donde sé, son de nuevo, muy detalladas, muy concretas y completamente verificables en su cumplimiento.

Este documento, pues, lo veo como divulgativo, conceptual e introductorio pero, por mucho que lo firme ANSI, me resisto a verlo como un verdadero estándar.


Conclusiones


Inicio con este artículo, una breve serie de tres posts dedicados a documentos más o menos recientes emitidos por el PMI ('Project Management Institute')

En este primer post, comento brevemente el 'The Standard For Project Management', un documento conceptual y de alto nivel, que establece vocabulario y conceptos, pero que no entra en detalles y que me cuesta mucho verlo como un verdadero estándar.

jueves, 21 de noviembre de 2024

Patrones subyacentes metodológicos y analíticos. El uso consciente de las herramientas y modelos

Después de bastante tiempo publicando artículos que, con alguna excepción en forma de reseña de libros, tenían que ver con la inteligencia artificial y/o la robótica, hoy voy a cambiar momentánea y brevemente de tercio para hablar de análisis, metodología y rigor.

Habitualmente veo, incluso en entornos académicos, usos o entendimientos incorrectos de herramientas, metodologías o enfoques de trabajo de naturalezas diversas pero que, de una forma u otra, caen dentro del ámbito de la gestión empresarial.

Me refiero a conceptos o herramientas como un simple DAFO, o un modelo de negocio o enfoques como 'agile' o 'design thning'.

Términos que tienen en común haber hecho fortuna en el mundo empresarial, enseñarse con frecuencia en el ámbito universitario o de posgrado, y estar muy presentes en medios más o menos especializados (en este caso a lo mejor habría que enfatizar lo del 'más o menos'). Y, como ya he comentado en algún otro post y a propósito de algún tema diferente, esa popularidad tiene una doble cara o es un arma de doble filo. Por un lado es bueno, ayuda a que se propague y se aplique, y por otro lado es malo, porque favorece el uso frívolo y descuidado del término, la herramienta o la metodología.

A mi, que valoro el conocimiento y el rigor y que me he preocupado de autoformarme en todos esas herramientas y enfoques que menciono, debo confesar que me enerva un tanto ese constante empleo frívolo, superficial e incluso ignorante de esos  nombres, herramientas y métodos.

Pero ayer vino a mi mente una reflexión algo más positiva, que me pareció interesante y que motiva este post.

El caso es que tuve ocasión de leer un uso, para mí algo 'cogido por los pelos' del término design thinking. Y pensando el porqué de ese uso, se me ocurrió una explicación diferente, y algo más positiva que la pura ignorancia y superficialidad.


Metodologías y patrones


Esa reflexión me lleva a distinguir, en cada enfoque metodológico o herramienta de trabajo, dos niveles.



Por un lado está lo que es la herramienta o metodología propiamente dicha, la que alumbraron sus creadores, generalmente conocidos gurús de la gestión, la que está bien analizada, documentada, explicada y a la que debemos referirnos para un discurso y una práctica rigurosos. A este nivel, y aunque el término quizá resulte algo aburrido y 'viejuno', lo voy a denominar metodología, ya que no se me ocurre un término más atractivo y moderno.

Pero por debajo de la metodología rigurosa, hay una serie de fundamentos, principios básicos o patrones de comportamiento, más difusos quizá, más laxos e indefinidos quizá, pero también más generales y que permiten su aplicación en entornos diferentes de aquellos para los que fue pensada la metodología inicialmente. Éstos serían los patrones subyacentes.

Lo que creo que sucede es que, en muchos casos, las personas no bien formadas, no bien advertidas, pero que 'han oído campanas', se quedan con dos cosas: por un lado, el nombre 'oficial' de la metodología, que en realidad se refiere al nivel superior y, por otro, a los patrones o principios básicos, que son el nivel inferior pero más general.

Y luego aplican los principios básicos, pero dándoles el nombre de la metodología.

Y así, se habla de un DAFO (cuando realmente no es un verdadero DAFO pero sí usa sus principios, sus patrones) o de un design thinking que, realmente, no es un 'design thinking pero que emplea sus principios y patrones.

Por si dicho así suena muy abstracto, lo concreto en cuatro herramientas o enfoques metodológicos muy populares y con frecuencia mal usados.


Análisis estratégico: el DAFO


Metodología


El DAFO es una muy bien conocida herramienta de análisis estratégico. El DAFO, como metodología (nivel superior), se aplica a una empresa u organización y adopta dos visiones: una externa (Amenazas y Oportunidades) en que se mira al mercado y al contexto, y otra interna (Fortalezas y Debilidades) en que se analiza la situación y competencias de la propia organización. Tanto para el análisis interno, como para el externo, se mira tanto lo bueno (Oportunidades y Fortalezas) como lo malo (Amenazas y Debilidades).

Hecho este análisis estratégico, la empresa puede identificar sus opciones estratégicas y elegir, con cierto conocimiento de causa, la mejor

Así concebida es, como digo, una herramienta de análisis estratégico y aplicada a una empresa o una organización

Sin embargo, la veo con frecuencia aplicada a un proyecto concreto, incluso de no mucho alcance, dentro de una organización. Estrictamente hablando, eso es incorrecto


Patrones subyacentes


Los patrones subyacentes al DAFO son esa doble mirada interna y externa, por un lado, y la otra doble mirada: positivo-negativo.

Y así considerado, en realidad, podríamos aplicarlo a otros muchos ámbitos. Por ejemplo, se habla en ciertos entornos, de un DAFO personal, y creo que ahí, si sabemos bien lo que estamos haciendo, podría llegar a tener bastante sentido. Me encaja menos aplicarlo a lo que he dicho más arriba, proyectos, pero, de nuevo, sabiendo lo que se hace, podría llegar a ser admisible.

Probablemente el DAFO sea una de las herramientas más sencillas y flexibles, con unas patrones más claros y que la habilitan con más facilidad que otras a aplicarla fuera de su verdadero entorno que recuerdo, de nuevo, que es el análisis estratégico.


Modelo de negocio: el Business Model Canvas


Metodología


El Business Model Canvas es una herramienta omnipresente en la literatura actual de gestión empresarial y, especialmente, de innovación y emprendimiento. Se trata de una herramienta para describir un modelo de negocio y, con base en esa descripción, poder adoptar posibles decisiones sobre el mismo. Ese es su objeto, aunque parece también muy ligado al emprendimiento y la innovación, precisamente porque, y tal y como definen reputados autores, una startup lo que está buscando es un modelo de negocio rentable y sostenible y, por tanto, necesita describir y analizar ese modelo de negocio y trabajar sobre él.

Pero he visto usar también el Busines Model Canvas para un proyecto, un simple proyecto, ni siquiera especialmente transformador, en una empresa establecida con un modelo de negocio establecido... y que el proyecto no va a modificar. Y eso no es muy correcto.


Patrones subyacentes


El Busines Model Canvas tiene unos patrones menos claros y externalizables que el DAFO, pero podríamos identificar la necesidad de una triple mirada: por un lado hacia el mercado (clientes, proposición de valor, canales y relaciones), por otro hacia la parte operativa (actividades, recursos y socios) y finalmente hacia la económica (flujos de ingresos y estructura de costes).

Y, quizá, podríamos decir que los propios cuadrantes que hay dentro de cada una de esas miradas, nos confecciona una especie de checklist de cosas a tener claras en una organización.

El Business Model Canvas es una herramienta muy popular y muy útil, pero que creo que no se extiende fácilmente fuera de su entorno natural que es el modelo de negocio de una empresa, o de una unidad de negocio dentro de ella o incluso de una línea de productos dentro de ella.

Si lo aplicas a un proyecto, creo que solo podría tener sentido en proyectos más o menos ambiciosos y transformadores y no tanto por el proyecto propiamente ducho sino para saber cómo el modelo de negocio condiciona al proyecto o cómo, caso de ser realmente transformador, el proyecto impacta en el modelo de negocio.


Dirección de proyectos: Agile


Metodología


Quizá uno de los términos más usados, y con frecuencia de manera incorrecta o con una valoración incorrecta, es el de 'agile'. Aunque a los fanáticos del agilismo les repele que se le denomine 'metodología' y prefieren hablar de 'framework', creo que aquí opto denominarla metodología, siguiendo los dos niveles explicados más arriba y, en concreto, del ámbito de la dirección de proyectos. Una metodología surgida en el mundo del desarrollo software, aunque luego ha hecho fortuna yendo más allá y aplicándose a otros muchos tipos de proyectos e impregnando metodologías de innovación y emprendimiento como 'lean startup'.

Aunque como metodología, en efecto, agile es 'laxa', los enfoques agile como scrum definen sus roles, sus herramientas, sus ceremonias...

La verdad es que creo que en el caso de 'agile', su mal uso se debe casi siempre a superficialidad y a ignorancia de todos esos detalles, pero de todas formas, creo que exhibe patrones muy claros,  muy útiles y muy exportables más allá de su ámbito natural.


Patrones subyacentes


El patrón más claro, y en el fondo definitorio, es el de el crecimiento iterativo y adaptativo, crecimiento y adaptación tanto en la definición del propio alcance del proyecto como en el desarrollo y entregables del mismo. Y un crecimiento y adaptación que, un poco, se mueven por una especie de ensayo y error, especialmente cuando trasciende el mundo del software y se centran en innovación.

Esa visión adaptativa e iterativa es la que lo convierte en tan útil para salir del mundo de los proyectos de software e ir hacia otro tipo de proyectos. Y, ese movimiento de ensayo y error, lo prepara bien para la innovación, como hemos dicho.


Productos y soluciones: desing thinking


Metodología


Quizá como metodología, el design thinking sea en sí misma la más difusa, a veces más una filosofía que una metodología y la que, de forma natural, tiende más a sus principios y patrones que a un enfoque cerrado.

De todas formas, y aunque muchos de los propios gurús del design thinking parecen derivar y ampliar sus fronteras, su ámbito principal es del diseño de productos y servicios, o soluciones en general, con una visión amplia, que conecta con el cliente y usuario finales, y que también propotipa y prueba, avanzando de forma iterativa.


Patrones subyacentes


Dentro de los patrones del design thinking se encuentran también la iteración y la adaptación, pero quizá refuerza más que agile, elementos como la creatividad, la empatía con y observación del usuario / cliente así como el prototipado

La cercanía al usuario final, la empatía y el prototipado son útiles en muchos problemas complejos o sin roadmap de resolución claro, y eso lleva a posibilidades de uso fuera del ámbito de los productos, servicios y soluciones.


Sobre el conocimiento y el rigor


Hecho el razonamiento anterior y ejemplificado en los casos que con más frecuencia me encuentro, tiendo a adoptar una visión un poco más optimista de cómo son usadas estas herramientas y metodologías.

No digo que no exista desconocimiento y superficialidad, que existen y bastante, y no digo que no exista un cierto 'postureo', que también existe y probablemente bastante, pero al menos me queda la expectativa de que, aunque seguramente bajo un nombre incorrecto, al menos se estén aplicando unos principios y patrones que sí pueden ser correctos y útiles. 

Dicho lo cual, a pesar de todo, reclamo, aunque sé que en vano, la profundización en el conocimiento real de las herramientas y tecnologías y que se usen por su nombre cuando realmente se está aplicando esa herramienta o metodología.

Y defiendo y abogo también, cuando tenga sentido, se apliquen sólo algunos de sus patrones y principios pero, cuando eso suceda, sea mediante una identificación y selección consciente de esos patrones y sin aplicarles un nombre que no les corresponde.

Esa es mi propuesta y ese es mi deseo. La propuesta aquí está. El deseo, creo que ni el genio de la lámpara me lo va a conceder :).


Conclusiones


Por debajo de las herramientas y metodologías más populares de análisis y gestión empresariales, subyacen unos principios y patrones básicos. 

La confluencia, por el lado negativo, de una cierta ignorancia y superficialidad en muchos adoptantes, y en el lado positivo, de unos patrones y principios básicos de utilidad mucho más general, hace que con frecuencia se apliquen  fuera del ámbito que les es propio y con un nombre que sería incorrecto.

Sin embargo, si reforzásemos el conocimiento y consciencia tanto de metodologías como de patrones, podríamos aplicar con mucho provecho los segundos, sin adjudicarles el nombre las primeras. 


miércoles, 15 de mayo de 2024

Indicadores de un buen roadmap de transformación digital

A pesar de los años que llevamos ya hablando, y se supone que implementando, la transformación digital, es cierto que probablemente sigue siendo una idea rodeada de cierta confusión, y probablemente, cierta inseguridad en empresas y directivos en cuanto a cómo llevarla a cabo.

Lo cierto es que no creo que existan verdaderas recetas, ninguna metodología detallada de cómo definirla y ejecutarla. 

De hecho, no creo que ninguna eventual metodología detallada, que no existe, para llevar a cabo una transformación digital, fuese creíble porque, al menos eso defiendo yo, la concreción de una transformación digital depende mucho de la situación de cada empresa, de su punto de partida en cuanto a madurez y realidad digital, su estrategia, sus circunstancias, su cultura, y muy especialmente la de sus directivos e incluso su situación financiera. Y, en ese sentido, se resiste a recetas simplistas o a cerrarse en una 'to-do list' detallada y de validez general.


Mi modelo de transformación digital


En mi primer libro 'La carrera digital', hice mi propuesta de transformación digital, que se estructura en torno a tres ejes:


  • Tecnología: A despecho de otras visiones que desprecian el papel de la tecnología en la transformación digital, yo defiendo decididamente la necesidad de conocimiento de la tecnología digital, incluso o empezando por los directivos, identificando sus posibilidades y las oportunidades y amenazas de naturaleza estratégica que representa para una organización

  • Método: Una gestión ordenada y rigurosa del programa de transformación que, a su vez, planteo en dos dimensiones principales:

    • Encaje estratégico: Un encaje que parte de la reflexión estratégica, dando sentido a la transformación digital como una actividad plenamente empresarial y que no se hace 'a tontas y a locas' porque esté de moda sino con una clara lógica de negocio. Y una reflexión estratégica que no se quede en grandes palabras sino que tenga en cuenta también elementos más del día a día como la realidad de tecnologías, procesos y cultura de partida y las limitaciones y necesidades presupuestarias.

    • Dirección de proyectos: un enfoque, quizá no 'glamouroso' pero sí realista y riguroso, que trata la transformación digital como un programa, en el sentido que el Project Management Institute da al término programa y sus iniciativas concretas como proyectos, de nuevo en el sentido del PMI.

  • Personas y cultura teniendo en cuenta todos los aspectos de liderazgo y gestión del cambio que, en el fondo, deben acompañar a toda transformación, sea ésta digital o no.


Han pasado ya cinco años desde que publiqué 'La carrera digital', he leído, antes y después de su publicación, a muchos autores en materia de transformación digital y la propia tecnología ha evolucionado mucho y, sin embargo, me sigue pareciendo que mi planteamiento sigue siendo válido y plenamente vigente y no lo cambiaría en nada importante.


El roadmap de transformación digital


En cualquier caso, parece que una transformación digital marca una forma de 'roadmap', un camino de cambio y, claro, transformación, y un camino que, cada vez somos más conscientes, no tiene un final definido, sólo etapas de una transformación para la que no se vislumbra un final.

Y en ese camino queremos saber que lo hemos trazado correctamente y que lo estamos ejecutando correctamente.


Los cinco marcadores de McKinsey Digital


En el último libro que he leído en materia de transformación digital, 'Rewired: The McKinsey Guide to Outcompeting in the Age of Digital and AI', de Eric Lamarre, Kate Smaje y Rodney Zemmel de McKinsey Digital, un libro interesante y bastante diferente de otros, los autores se plantean en un momento dado, cómo asegurarnos de que ese 'roadmap' está bien trazado.

Y proponen lo que definen como 'marcadores' de que estamos ante un buen 'roadmap' de transformación digital. En concreto, los marcadores que proponen son los siguientes:


  • Los dominios y las soluciones digitales subyacentes se secuencian de tal forma que producen valor tanto en el corto como el medio plazo.

  • Las transformaciones en los diferentes dominios están ligadas a mejoras en KPIs operativos, lo cual, a su vez, liga con mejoras operativas.

  • Todo el plan tiene un cuenta, de manera explícita la construcción de las capacidades digitales por las que los autores apuestan (talento, modelo operativo, tecnología y datos) y de las que ya hablamos en 'Una propuesta de capacidades nucleares para empresas digitales'. Además se incluyen las inversiones y tiempo necesario para conseguir la madurez.

  • El plan financiero es claro y agresivo pero realista. Además apuestan por unos indicadores financieros del programa claros y de seguimiento periódico, por ejemplo, mensual.

  • Se incorpora la gestión del cambio tanto para toda la transformación digital en su conjunto como para soluciones concretas.


Aunque quizá, más que indicadores propiamente dichos, estos cinco puntos sean características a exigir, en general me parecen sensatas.

Creo que es interesante la relevancia que le dan al plan financiero porque, en efecto, eso aporta realismo y rigor: sin inversión clara y planificada es imposible llevar a cabo un programa de transformación y, además, el seguimiento financiero obliga al rigor en todos los sentidos.

El enlace con KPIs operativos obliga también a tener los pies en la tierra y al alineamiento con la realidad de la compañía y sólo advertiría de que una atadura demasiado estrecha a la realidad operativa de partida, puede 'cortar un poco las alas' y limitar iniciativas más innovadoras, mas radicales y transformadoras.

También es interesante que al hablar del valor, que es evidente, destaquen que ese valor se produzca ya en el corto plazo, lo cual parece referirnos a la famosa búsqueda de 'quick wins'. En cualquier caso, es bueno, apostar por resultados no sólo a largo plazo, quizá más estratégicos, sino también a corto. Aporta realismo, engrasa el programa y contribuye a la gestión del cambio.


Alguna consideración


Comparo mi propuesta con la de estos autores y, aunque en su formulación literal es bastante diferente, creo que en el fondo encajan bastante bien.

El encaje estratégico que yo propongo creo que enlazaría razonablemente bien con la apuesta por aportaciones a los KPIs y la construcción de capacidades digitales, así como el tener en cuenta la realidad presupuestaria.

La gestión como programas y proyectos, aunque es una propuesta diferenciada de mi parte, creo que se alinea muy bien con el rigor financiero y con la aportación de valor en diferentes momentos del tiempo.

Finalmente, casi encaja como un 'guante' mi visión de personas con la gestión del cambio.


Conclusión


Paree que, en efecto, la transformación digital se ha de estructurar como un plan, que en mi caso de convierte en programas y proyectos y en la propuesta de McKinsey en un 'roadmap', algo más vago, un plan con anclaje estratégico y con clara aportación de valor, un plan que se siga de manera rigurosa, tanto en el plano financiero como en el general de dirección de proyectos, y un plan que tenga en cuanta a las personas y la consiguiente gestión del cambio.


martes, 20 de diciembre de 2022

Una decepcionante versión 7 del PMBOK de PMI

El Project Management Institute es la autoridad de facto en materia de dirección de proyectos y la entidad emisora del prestigioso certificado PMP ('Project Management Professional') que me honro en poseer. Y el conocido popularmente como PMBOK, aunque su titulo real es 'Guide to the Project Management Body Of Knowledge', es decir, una guía al cuerpo de conocimiento en dirección de proyectos, es sin duda, su publicación fundamental. Este volumen es, en el momento de editar esta reseña, la última edición de ese documento, la séptima, en concreto.

Una edición que cambia de manera bastante radical el contenido y orientación de las ediciones anteriores, al menos las que yo he conocido desde que me certifiqué (cosa que hice con base en la edición 4).

Lo cambia en el sentido de hacer un enfoque mucho menos de metodología y más de principios e ideas generales. Lo cambia en el sentido de hacerlo más breve y creo que superficial y lo cambia en el sentido de que, además, del PMBOK propiamente dicho, incluye lo que se ha convertido en un estándar ANSI.

El volumen, pues, es en realidad la unión de dos documentos, cosa que me resultó un poco confuso cuando lo leí.

Se comienza por el estándar en el documento 'THE STANDARD FOR PROJECT MANAGEMENT' que consta de tres capítulos, a saber:
  • '1. INTRODUCTION': Un muy breve capítulo introductorio en que señala el objetivo del estándar, define algunos términos básicos y anuncia la audiencia esperada del documento.

  • '2. A SYSTEM FOR VALUE DELIVERY': Situa a los proyectos dentro de una especie de ecosistema de entrega de valor. Comienza, precisamente, mostrando ese sistema de entrega de valor que incluye los proyectos como tales pero agrupados en programas y porfoliosdando entrada también a las operaciones. Habla brevemente de los sistemas de gobierno y salta a continuación a identificar y explicar ocho funciones asociadas a los proyectos. En la siguiente sección identifica brevemente una serie de elementos de contexto tanto internos (en la propia empresa) como externos, que afectan a los proyectos. Y, finalmente, y de nuevo brevemente, pone los proyectos en relación con el ciclo de producto.

  • '3. PROJECT MANAGEMENT PRINCIPLES': Identifica y desarrolla, en dos o tres páginas cada uno, los principios que guian la dirección de proyectos y que son los siguientes:
    • Sé un administrador diligente, respetuoso y cuidadoso
    • Crea un entorno colaborativo del equipo del proyecto
    • Involúcrate eficazmente con los interesados
    • Reconoce, evalua y responde a las interacciones del sistema
    • Demuestra comportamientos de liderazgo
    • Adapta en función del contexto
    • Incorpora la calidad en los procesos y los entregables
    • Navega en la complejidad
    • Optimiza las respuestas a los riesgos
    • Abraza la adaptabilidad y la resiliencia
    • Permite el cambio para lograr el estado futuro previsto
Tras esto, se aborda ya el PMBOK, en el documento'A GUIDE TO THE PROJECT MANAGEMENT BOOK OF KNOWLEDGE' que consta de cuatro capítulos:
  • '1. INTRODUCTION': Capítulo introductorio breve donde indica la estructura del documento y también la relación de este PMBOK con el estándar que acabamos de ver, fundamentalmente relacionando los principios definidos en el estándar con los dominios de desempeño que se desarrollan en el PMBOK. Y señala finalmente, algunos cambios respecto a la edición anterior.

  • '2. PROJECT PERFORMANCE DOMAINS': 'Un capítulo nuclear donde identifica y desarrolla los ocho dominios del desempeño de proyectos, a saber:
    • Interesados ('stakeholders')
    • Equipo
    • Enfoque de desarrollo y ciclo de vida
    • Planificación
    • Trabajo del proyecto
    • Entrega
    • Medida
    • Incertidumbre

  • '3. TAILORING': ' Un capítulo que explica cómo adaptar elementos de proyecto como el enfoque de desarrollo, el ciclo de vida o los dominios de desempeño a las circunstancias particulares de cada proyecto.

  • '4. MODELS, METHODS AND ARTIFACTS': ' Un capítulo que censa y explica, aunque sin profundidad, un amplio catálogo de técnicas usadas habitualmente en proyectos y que agrupa en tres bloques:
    • Modelos: estrategias de pensamiento. Menciona varios de ellos y en una tabla/matriz final relaciona estos modelos con su uso en los diferentes dominios de desempeño.
    • Métodos: medio para conseguir unos resultados y que identifica agrupándolos en cuatro bloques: métodos para toma de datos y análisis, métodos para estimación, métodos para reuniones y eventos y otros. Como en el caso anterior cierra con una tabla / matriz que relaciona los métodos con su uso en dominios de desempeño.
    • Artefactos: plantillas, documentos, etc que identifica agrupados en nueve bloques: estrategia, registros, planes, organigramas, líneas base, información y datos visuales, informes, acuerdos y contratos y otros. Al final, y como en los dos casos anteriores, se ofrece una tabla/matriz con el uso de esos artefactos en los diferentes dominios de desempeño.
Aparte de las dos obras mencionadas, el volumen incluye 5 anexos. El primero es un simple, aunque extenso, listado de las personas que han contribuido aportando contenido o como revisores. Los tres siguientes hacen foco sobre tres temas concretos como son los espónsors, la PMO ('Project Management Office') y la gestión de productos. El último habla de la investigación realizada para la elaboración del estándar.

Aparte de la existencia de dos documentos, algunos otros elementos diferenciales de esta versión son el foco en los principios que se detallan en el estándar y el cambio de la orientación a procesos y áreas de conocimiento de las ediciones anteriores, a los dominios de desempeño de ésta. Además, y quizá es lo único que me quedo que realmente me haya aportado valor, y aunque ya se había anticipado bastante en las versiones anteriores, es con el discurso de las orientaciones de proyecto y ciclo de vida, que puede ser un buen marco conceptual para encajar waterfall/predictivo, agile y opciones intermedias.

Y al referirme a los enfoques de proyectos he dicho que es con lo único que me quedo porque, para ser sincero, esta edición del PMBOK, así como el propio estándar, me han decepcionado mucho. Valoro enormemente el rol de jefe de proyecto y director de proyecto, roles que ejercí con frecuencia hace unos pocos años, y estoy muy contento y orgullo de ostentar la certifición PMP. Y no puedo evitar percibir que esta edición del PMBOK incluye, no sólo un giro que no considero afortunado, sino, sobre todo, una suerte de 'descafeinado' de la información y de la propia disciplina, convirtiendo tanto al estándar como al PMBOK en documentos un tanto filosóficos o de puras intenciones e ideas generalistas y bastante superficiales. En lo relativo al estándar, no sé cómo un documento así se puede considerar un estándar cuando es tan especulativo, cuando no establece ni normas, ni procedimientos, ni procesos, ni plantillas, ni verificaciones. Nada de nada. No sé que pretende estandarizar realmente.

Unos documentos, en fin, que creo que nada o poco aportan ni a un profesional de la dirección de proyectos ni a nadie que se quiera formar en la materia y que se acerque a este documento como quien se aproxima a una autoridad.

Espero que la octava edición retorne a una senda más parecida a la mantenida hasta la edición 6.

Una verdadera pena.

Ficha técnica:

viernes, 29 de octubre de 2021

Cómo ejecutar proyectos de Inteligencia Artificial con Jaume Miralles

'Proyectos de inteligencia artificial' ofrece una visión de la inteligencia artificial muy real y casi, casi, de uso común, porque refleja en el fondo el día a día en las empresas que implementan soluciones de inteligencia artificial, pero al tiempo una visión original porque, paradójicamente, está visión tan pegada a tierra, está muy poco presente en la abundante literatura especializada, y no tan especializada, que aborda el amplio campo de la inteligencia artificial. En concreto, este libro no se centra en la tecnología, fundamentos, casos de uso o implicaciones de la inteligencia artificial sino en la implementación real de capacidades y soluciones de inteligencia artificial en la empresa, es decir, en cómo llevar a cabo realmente iniciativas y proyectos de inteligencia artificial

El libro se estructura en diez capítulos, como sigue:
  • '1. Proyectos de Inteligencia Artificial': Comienza analizando el estado, barreras y retos para la adopción de la inteligencia artificial en la empresa. Luego aclara brevemente lo que es un proyecto de inteligencia artificial, destacando la importancia de operacionalizar los modelos de machine learning / deep learning. Y, finalmente, hace una distinción entre lo que son capacidades de Inteligencia Artificial y lo que son aplicaciones, explicando brevemente cada una de ellas así como los sistemas cognitivos.

  • '2. Estructura primaria de un proyecto IA': Hace primero una clasificación de los proyectos de inteligencia artificial en una matriz bidimensional, donde en una dimensión se muestra si hablamos de una capacidad o una aplicación y en la otra si el proyecto trata de hacer un desarrollo o un despliegue /operacionalización de un modelo. Luego comenta las principales actividades o fases en un proyecto de capacidades de IA. A continuación dedica un amplioespacio a hablar de los datos, abordando temas como el tipo, consistencia, etiquetado, sesgos etc. Y finaliza considerando los tipos de despliegue posibles (capacidad como módulo de una aplicación, capacidad como servicio web, capacidad batch y capacidad para datos en streaming).

  • '3. Enfoque metodológico': Primero explica algunos marcos metodológicos generales, como Design Thinking y Agile y alguno específico del campo de la Inteligencia Artificial como CRISP-DM. Y luego mira algo más hacia la operación, hablando de DevOps (de nuevo, un enfoque genérico) y cómo se traslada al campo del Machine Learning convirtiéndose en MLOps.

  • '4. Mejores prácticas': Desgrana una serie de buenas prácticas que incluyen la anticipación, la reutilización, la automatización mediante AutoML, las pruebas de regresión, el reentrenamiento de modelos, etc

  • '5. Recursos materiales': Un corto capítulo que, en realidad, sirve a modo de introducción a los capítulos siguientes que se centran en recursos.

  • '6. Infraestructura': Capítulo dedicado a la infraestructura hardware y software. Comienza identificando los atributos clave en la utilización de infraestructuras (localización, virtualización y mdelo de gestión). Luego afronta el almacenamiento y la computación y acaba revisando la oferta existente en materia de procesadores y sistemas.

  • '7. Frameworks y lenguajes de programación para IA': Habla primero de los lenguajes de programación ofreciendo algunas gráficas comparativas en cuanto a su mayor o menor utilización. Luego pasa revista a librerías usadas en machine learning revisando librerías para Python y R. A continuación visiita brevemente Spark y finaliza con una breve revisión de frameworks de deep learning.

  • '8. Herramientas': Realiza un amplio recorrido por diversas herramientas, empezando por las de modelado de datos, incluyendo el acceso a datasets públicos y siguiendo por herramientas para el despliegue y ejecución de modelos. Se explican las ideas principales y se mencionan herramientas concretas de mercado.

  • '9. Mercado de plataformas de IA en cloud (AIaaS)': Siguiendo con la orientación al mercado, en este capítulo se repasan las plataformas y servicios en la nube empezando primero por sus características generales y siguiendo por un breve recorrido por plataformas como Amazon Web Services ML Stack, Microsoft Azure AI Platform, Google Cloud AI Platform e IBM Watson Data & AI Platform

  • '10. Recursos humanos': Finaliza el libro con una mirada hacias las personas y recursos humanos. Se revisan ampliamente los perfiles específicos para proyectos de Inteligencia Artificial, se identifican algunas fuentes posibles de talento y se finaliza con una visión organizativa de la IA en la empresa.
'Proyectos de inteligencia artificial' es un libro realista, muy correcto, ilustrativo, útil y muy oportuno, porque contribuye a llenar llena un importante vacío de conocimiento en la literatura sobre inteligencia artificial: el de su implementación real.

Jaume Miralles Solé

(Fuente: Ligera elaboración propia de la biografía en su sitio oficial)

Jaume Miralles Solé
Jaume Miralles es un consultor TIC que, en 2016, descubrió su pasión por la Inteligencia Artificial, cuando pasó a trabajar para la unidad de IBM Watson y dejó atrás unos cuantos años de proyectos de implantación de soluciones TIC.

Desde entonces su día a día consiste en entender, apoyar y transmitir a colegas, colaboradores y clientes las ventajas competitivas que proporciona la IA en cualquier ámbito e industria. Adicionalmente, también colabora en diversos programas formativos de postgrado relacionados con la IA, lo que, unido a su actividad habitual, le obliga a estar muy al día en las mejores prácticas, las novedades y las tendencias tecnológicas del ámbito de IA empresarial.

En la actualidad es Líder de la práctica de Customer Data Platforms (España) en IBM iX.

Jaume Miralles es Ingeniero Electrónico por la Universidad Ramón Llul y es autor del libro 'Proyectos de Inteligencia Artificial'.

Puedes saber más del autor, visitando su página oficial, consultando su perfil en LinkedIn o siguiéndole en Twitter donde se identifica como @jaumemiralles.

Ficha técnica:

EDITORIAL: Autoeditado
AÑO: 2021o 
ISBN: 978-1661199456
PAGINAS: 239

Artículos de este blog relacionados

viernes, 2 de abril de 2021

¿Por qué fracasa una transformación digital? Dos riesgos que habitualmente no se mencionan

Mucho se ha escrito y hablado sobre transformación digital en los últimos años, y mucho se escribirá y hablará sobre transformación digital en los inmediatamente venideros.

Muchas explicaciones, no siempre afortunadas, sobre en qué consiste la transformación digital. 

Muchas ideas y recetas, no todas completas ni acertadas, sobre cómo llevarla a cabo.

Y también, si, alguna argumentación, tampoco necesariamente bien enfocada, sobre los riesgos existentes y sobre qué puede hacer que nuestra transformación digital descarrile y no llegue a buen puerto. 

Hablé largo y tendido sobre transformación digital en mi primer libro 'La carrera digital' y en él hui de proporcionar recetas simples y genéricas, porque como les suelo insistir a mis alumnos cuando les hablo de transformación digital, no creo en la existencia de LA transformación digital, en abstracto, sino en TU transformación digital, la propia de tu compañía. Una transformación digital que depende del sector en que operes, de tu estrategia, de la situación de partida y madurez en materia de sistemas y tecnologías en tu empresa, de la presencia o no de cultura digital y habilidades digitales básicas, de tu aversión al riesgo, de tu disponibilidad presupuestaria...

No, no creo, en las recetas simplistas y generales, aunque, evidentemente, existen patrones comunes y buenas y malas prácticas.

En mi visión de la transformación digital, juega un papel importante una disciplina a la que no se suele relacionar, incomprensiblemente, con la transformación: la dirección de proyectos. Y una parte relevante de la dirección es la gestión de riesgos. En gran medida, la gestión del riesgo de un programa de transformación digital se debería, en mi opinión, gestionar siguiendo las buenas prácticas de gestión de riesgos en proyectos y programas.

En resumen, no creo en las recetas simplistas y generales para la transformación digital y los riesgos que la aquejan se debe gestionar mediante las técnicas al respecto de la dirección de proyectos.

A pesar de todo lo anterior, en este post quisiera mencionar dos riesgos genéricos que comprometen el éxito de una transformación digital (y, en gran medida, cualquier transformación ambiciosa). Y lo hago porque, como parte de mis actividades docentes, he tenido la ocasión recientemente de observar algún planteamiento sobre riesgos en transformación digital, y me pareció que había cosas importantes que añadir o, al menos, resaltar.

Voy a comentar, en concreto, dos elementos de riesgo:

  • El salto de la estrategia a la operativa
  • La ejecución y la resiliencia


El salto de la estrategia a la operativa


Se suele decir, y se dice bien, que la transformación digital deriva de la estrategia, que debe estar alineada con la estrategia. Y es cierto. Muy cierto. Absolutamente cierto. 

La transformación digital debe apoyar de forma coherente una estrategia existente o, incluso, debe definir, al menos parcialmente, esa estrategia. En cualquier caso, debe haber un completo alineamiento entre nuestra estrategia empresarial y la transformación digital que acometemos.

Sin embargo, existen discursos, que me inquietan e incomodan por lo blandos y ambiguos, en que de tanto centrarse en la estrategia, de tantas grandes palabras y visiones como los pueblan, se olvidan de que la estrategia hay que implementarla. La transformación digital hay que hacerla, construirla, ejecutarla

En el modelo que propongo en 'La Carrera Digital' indico que, teniendo clara la estrategia, se deben identificar unas iniciativas. De esas iniciativas se seleccionan las más oportunas. Y las iniciativas se convierten en proyectos (es decir, actividades con alcance, entregables, plazos, responsables, costes...). Ese salto de las estrategias, que forzosamente son visiones de alto nivel, a proyectos que son empeños muy concretos y operativos, es fundamental para que la transformación digital no se quede en un discurso o un powerpoint.

Y se trata de un salto que algunas visiones en mi opinión demasiado 'blandas' de la transformación digital no favorecen. La transformación digital no son unas 'slides' o el discurso de un CEO. La transformación digital es acción. Es ejecución. Es sangre, sudor y lágrimas.


La ejecución y la resiliencia 


Sangre, sudor y lágrimas. Una forma artística aunque severa de decirlo. Pero es así. La ejecución es compleja. Y es dura. La implantación de tecnología es compleja, y es dura. Y la transformación digital, aunque les pese reconocerlo a aquellos que se empeñen en negar su base tecnológica, es esencialmente, implantación de tecnología.

Una implantación de tecnología que, como hemos dicho, deriva de la estrategia...pero implantación de tecnología, al fin y al cabo.

Una implantación de tecnología acompañada de acciones de gestión del cambio y, eventualmente, de la promoción de un cambio cultural... pero implantación de tecnología.

Y cualquier que haya tenido la experiencia de participar en proyectos de implantación de tecnología sabe que suelen ser complejos y duros. Sabe que aparecen imprevistos, cosas que, inexplicablemente, no funcionan como pensábamos. Que surgen errores y fallos que parecen indescifrables. Que pese a nuestros mejores intentos de estimación de plazos, los tiempos tienden inexorablemente a alargarse. Que hay agentes que se oponen de forma activa o pasiva al avance del proyecto y que ponen 'palos en las ruedas. Y que la presión de la dirección suele ser alta.

Si, la implantación de tecnología es bonita, pero dura. Y la transformación digital, pese a quien pese, es esencialmente implantación de tecnología. Y, por tanto, es bonita, pero dura.

Y por eso es tan importante la resiliencia. Una resiliencia que nos haga a un tiempo resistentes y flexibles, pero en cualquier caso capaces de mantener la visión, la tensión y la motivación, cuando las cosas se ponen difíciles, lo cual suele ocurrir con frecuencia.

Cuando se habla de la importancia de las personas, se suele poner más énfasis en los aspectos culturales y de gestión del cambio. Y, en efecto, son muy importantes.

Pero en mi visión, lo que más me importa de cara a una transformación digital (en realidad de cara a cualquier transformación o iniciativa ambiciosa) es el liderazgo, la capacidad de llevar a la práctica una visión. Y esa capacidad de llevarla a la práctica implica no sólo visión. Implica, aún más, capacidad operativa y resiliencia, mucha resiliencia.


En resumen


Estos dos riesgos se podrían resumir en uno solo: la falta de capacidad operativa

Sugiero que no nos dejemos arrastrar por discursos simplistas, que nos hablen de estrategia sin concretar o que, al poner el foco en lo cultural, se desentiendan de lo tecnológico y operativo.

Insisto: la estrategia es esencial como punto de partida y las personas son cruciales, como impulsoras y sujetos afectados. Pero una transformación digital es, en esencia, implantación de tecnología. E implantar implica voluntad, resistencia y capacidad operativa.

Y si no la tienes, créeme, puedes llamarle como quieras a tu programa de cambio, pero no será una transformación digital. 

Y no implantarás nada relevante.

Y no triunfarás.


miércoles, 15 de enero de 2020

No, Agile no significa ir más rápido


Con frecuencia, los nombres que se escogen para las tecnologías, y en ocasiones también para las disciplinas de gestión, son engañosos. A veces, ya sea por ignorancia o, creo más bien, con intenciones de naturaleza comercial, se eligen nombres que llaman a engaño y que hacen creer lo que no es.

Y eso ocurre con Agile, una, ¿cómo la llamaríamos? filosofía o disciplina de gestión de proyectos que se encuentra absolutamente de moda, aunque sus orígenes se remonten a muchos años atrás. Se trata de una filosofía que, simplificando un poco, se aplica en proyectos con requisitos poco claros o que se mueven en un entorno de incertidumbre (típicamente, proyectos de innovación o emprendimiento, y muchos proyectos de desarrollo software) y que se basa en construir el resultado mediante iteraciones cortas que producen resultados tangibles, por ejemplo, una nueva versión de software utilizable.

Pero  ¿qué sugiere el nombre de Agile? Pues, claro, agilidad, es decir, rapidez

Y así, de nuevo puede que en algunos casos por ignorancia y en otros intencionadamente, se ha asimilado agilidad o agilismo a rapidez y muchos gestores han implantado agile (o "cosas" que pretenden serlo) sólo en búsqueda de esa tierra prometida de la rapidez.


Agile significa adaptación


Pues va a ser que no: agile no significa ir más rápido. Agile, lo que significa, es ser adaptativo

Y esa capacidad de adaptación, eso sí, nos puede hacer avanzar más rápído en algunos casos.

¿Qué quiere decir esto? 

Pues que, dado que nos movemos en entornos de incertidumbre y de requisitos poco claros y cambiantes, renunciamos a definir clara y completamente el alcance al inicio del proyecto y renunciamos también a hacer una planificación de tareas, tiempos y recursos para toda la vida del proyecto. En lugar de eso, vamos avanzando en ciclos cortos (lo que Scrum denomina sprints), generando incrementalmente versiones del entregable final (un software, un producto, un modelo de negocio...). Y con base en lo que vemos y el entorno, deducimos cuáles son los nuevos requisitos y hacemos un nuevo incremento corto adaptado a esa realidad.


¿Es Agile más rápido?


¿Y eso es más rápido?

Pues no exactamente, o no necesariamente. Sólo en los contextos adecuados. 

De heco, y aunque no lo voy a detallar en este post (invito al lector a razonarlo), en un proyecto con requisitos claros y entorno estable (lo que desde hace un tiempo el Project Management Institute denomina proyectos predictivos) creo es más eficiente e incluso más rápida la gestión de proyectos tradicional.

Lo que ocurre, eso sí, es que cada vez son menos frecuentes esos proyectos predictivos. Y en entornos de incertidumbre y requisitos poco claros, Agile si que tiene las armas para ir más rápido. ¿Por qué? Pues porque las inevitables equivocaciones que se producen en un entorno de incertidumbre, se corrigen de forma muy costosa y lenta en un proyecto gestionado de forma tradicional, mientras que tienen un impacto menor, mucho menor, en Agile dado que como mucho nos equivocamos en un pequeño incremento. Así que esos errores inevitables se corrigen rápido y el proyecto en su conjunto, termina antes.

Además, Agile produce una "ilusión de rapidez" por aquello de que produce resultados tangibles en iteraciones cortas. Y por eso, el cliente, o la dirección o el mercado, ven resultados pronto y los observan crecer a buena velocidad. Estrictamente hablando, eso no es ir exactamente más rápido, el final se puede alcanzar en el mismo plazo, sino hacer visible los resultados antes. Pero esa estrategia de producir resultados en pequeños incrementos, aparte de ser pieza muy importante del mecanismo de adaptación, genera esa sensación, no realmente cierta pero sí útil y atractiva, de rapidez y agilidad.


Conclusión


Este es mi convencimiento y algo que suelo destacar en las ocasiones en que explico Agile a mis alumnos o clientes.

Y me alegra ver que, aunque no sé si lo explicarían de la misma forma que yo, unas autoridades en el mundo de Agile, como son los autores del libro  'La empresa ágil' : Alonso ÁlvarezSara AguileraSusana Jurado y Míquel Rodríguez, van en una línea, al menos parecida, cuando indican:

tendemos a usar "ágil" como sinónimo de "rápido", pero en realidad también tiene una connotación de "flexible" y "adaptable".


Así que, recordemos, debemos usar Agile en entornos de incertidumbre y requisitos poco claros por muchas razones, incluido que nos pueden permitir terminar antes por gestionar mejor los cambios de alcance y requisitos. Pero no, Agile no significa realmente ir más rápido, Agile, lo que significa es ser adaptativo. La rapidez, en todo caso, se nos dará por añadidura.