GESTIÓN DE RIESGOS CON IA PMI INFINITY

INTRODUCCIÓN:

Actualmente es imposible no encontrar referencias a las IA (Inteligencias Artificiales) en cualquier medio de comunicación. Y, aprovechando la salida a finales del años pasado de la IA Infinity de PMI, me parece interesante comprobar cuales son sus capacidades en materia de gestión de riesgos en los proyectos en primera instancia, antes de comprobar sus capacidades de ayuda a la gestión de proyectos de forma global.

El PMI proporciona una herramienta basada en AI Co-Pilot y GPT 4 denominada PMI Infinity.

Esta herramienta ofrece respuestas y recomendaciones confiables y precisas para solucionar problemas que se puedan presentar a lo largo de la ejecución de los proyectos, gracias a que cuenta con una interfaz conversacional, que selecciona información relevante de la amplia biblioteca del PMI y aprovecha la arquitectura abierta de AI GPT 4.

Se debe tener en cuenta que esta aplicación se ha construido sobre un servicio OpenAI privado y dedicado, por lo tanto, sólo el PMI, lo mantiene, entrena y utiliza. Ninguna información con la que se ha entrenado, ni ninguna entrada o salida de las interacciones del usuario, se agrega a ningún servicio público de IA.

Para acceder a PMI Infinity, es necesario iniciar sesión utilizando tu nombre de usuario y contraseña del PMI. A partir del 12/Feb/24 solo pueden acceder los miembros del PMI , pues hasta esa fecha el acceso era libre).
Una vez que se ingresa a https://infinity.pmi.org/login, se encuentra la interfaz conversacional y se podrá iniciar la búsqueda.

Project management

 

CONSIDERACIONES:

Antes de utilizar PMI Infinity hay que tener en cuenta las siguientes consideraciones:

  • PMI Infinity es una herramienta complementaria para los Project Managers, si bien puede brindar información valiosa y recursos útiles, no reemplazan la experiencia y el juicio del Director de Proyecto. Por lo tanto, es él quien debe guiar y refinar el proceso de búsqueda, así como saber interpretar, aplicar y utilizar la información que encuentra para facilitar su gestión.
  • La calidad y precisión de las respuestas que se obtienen, depende de cómo se formulen los “prompts”, es decir “las instrucciones de búsqueda” que están representadas por las situaciones y/o escenarios que se plantean a la herramienta.
  • Para encontrar las respuestas esperadas se debe utilizar técnicas denominadas “prompt engineering”, las cuales buscan asegurar aspectos como:
    •Reducir las malas interpretaciones
    •Proporcionar contexto, limitaciones específicas y resultados deseados
    •Presentar ideas coherentes, siguiendo un flujo estructurado de información

 

Una IA puede disminuir el tiempo dedicado a la creación, pero incrementa el tiempo dedicado a la supervisión

 

Se recomienda empezar con conversaciones simples y no estructuradas:

 

¿CÓMO PMI PUEDE FACILITAR LA GESTIÓN DE RIESGOS?

Para facilitar la gestión de riesgos de los proyectos que están a cargo de la OGTP, PMI Infinity puede ser una herramienta valiosa y que se puede aplicar en las siguientes etapas que conforman el proceso de riesgos:

 

Para lograr que la herramienta ofrezca una ayuda adecuada, se deben formular “Prompts” precisos, claros y según el contexto de cada proyecto, por lo tanto se recomienda tener en cuenta los siguientes tips:

A continuación, se presentan algunos “PROMPTS” GENERALES de ejemplo que pueden servir de apoyo:

  1. Por favor, enumera las principales causas de riesgos en un proyecto de… (Ejemplo: desarrollo de software, infraestructura, automatización, mantenimiento, entre otros)
  2. ¿Podrías darme una lista de riesgos potenciales que se pueden presentar en proyectos de… (Ejemplo: desarrollo de software, automatización, suministros, entre otros)
  3. ¿Puedes mencionar cuáles son las categorías de riesgo que se deben considerar en un proyecto de… (Ejemplo: desarrollo de software, automatización, suministros, entre otros)
  4. Dame los 10 mejores consejos referentes a la gestión de riesgos.
  5. ¿Me puedes explicar cómo un bajo nivel de… (Ejemplo: comunicación, planificación, coordinación, entre otros) puede impactar en la ejecución de un proyecto de… (Ejemplo: desarrollo de software, suministros, mantenimiento, entre otros)
  6. ¿Cuáles son los riesgos de no completar un proyecto de… (Ejemplo: desarrollo de software, mantenimiento, suministros, entre otros) dentro del tiempo y presupuesto asignado?

A continuación, se presentan algunos “PROMPS” ESPECÍFICOS de ejemplo, que pueden servir de apoyo:

  1. Actualmente estoy asignado a un proyecto como Gerente de Proyecto. El proyecto está en su fase de… (Ejemplo: “inicio”). El objetivo de este proyecto es… (Ejemplo: “realizar mejoras sobre la herramienta que se utiliza para realizar al proceso de autenticación biométrica a los clientes”), buscando… (Ejemplo: “mejorar los indicadores de atención de clientes y número de créditos aprobados”). Para asegurar una ejecución y gestión adecuada del proyecto, necesito realizar una identificación de riesgos potenciales que pueden impactar el proyecto.
  2. Por favor identifica los riesgos potenciales y para cada uno de ellos debes incluir los siguientes detalles en una tabla: nombre del riesgo, con un título breve que resume la esencia del riesgo; descripción del riesgo, con una explicación detallada del mismo, indicando probabilidad e impacto por orden de importancia y cómo puede impactar en los objetivos del proyecto.
  3. Hola, soy Project Manager y me gustaría que me plantearas preguntas que me permitan realizar una identificación oportuna de los riesgos que pueden impactar a mi proyecto. Mi proyecto tiene el objetivo de… (Ejemplo: “realizar mejoras en la aplicación que se utiliza en la empresa para la gestión de incidentes reportados por los empleados a través de la intranet”.
  4. ¿Qué tipo de respuesta al riesgo: aceptar, escalar, mitigar, evitar o transferir, se debería de escoger para un riesgo de… (Ejemplo: “retraso en el cronograma debido a ampliación del alcance”)?
  5. ¿Cómo mitigar un riesgo de…(Ejemplo: “cambios de alcance”) en un proyecto de… (Ejemplo: “desarrollo de software”).
  6. ¿Cómo crear un plan de contingencia para un riesgo de… (Ejemplo: “retrasos de cronograma”) en un proyecto de… (Ejemplo: “diseño de una aplicación web”).

ANEXO, VIDEO:

FUENTES CONSULTADAS:

•https://www.pmi.org/membership/infinity
•(2024) Project Management Institute: Talking to the machine
•(2024) Project Management Institute: An Overview of PMI Infinity
•(2023) Project Management Institute: Shaping the future of Project Management with AI

 

CERTIFICACIÓN AGILE HYBRID PROJECT PRO

Consciente de la importancia que está teniendo últimamente en materia de proyectos el movimiento de mezclar elementos de las metodologías predictivas o waterfall, agile, Six Sigma y otras, el PMI ha lanzado una nueva certificación orientada a cubrir esta necesidad formativa.

La micro-credencial ágil / híbrida se alinea con la Guía para el cuerpo de conocimiento de la gestión de proyectos, la Guía del PMBOK, (que ya está en su versión 7) y que es el estándar global preeminente para la gestión de proyectos y que proporciona las prácticas fundamentales de la profesión.

Según el PMI “Los poseedores de la certificación Agile Hybrid Project Pro Micro-Credential han demostrado su amplio conocimiento de conceptos, tareas y técnicas de gestión de proyectos ágiles / híbridos que son aplicables en prácticamente cualquier industria. Los poseedores pueden hablar y comprender el lenguaje global de la gestión de proyectos ágiles / híbridos. Los poseedores han demostrado el conocimiento y las habilidades necesarias para gestionar los planes, el alcance, las partes interesadas, los riesgos, los presupuestos, el cumplimiento, los recursos, la resolución de problemas y la entrega de valor del proyecto.”

La certificación  Project Pro Micro-Credential se está introduciendo para ayudar a los gerentes de proyectos tradicionales, titulares de la certificación PMP existentes, gerentes de proyectos con conocimientos ágiles / híbridos y / o experiencia, para alinearse con los últimos estándares de la industria.

Y es que, como ya vimos en la entrada correspondiente a la certificación Google de Project Management, es ya un hecho que, en lugar de seguir una sola metodología para la gestión de un proyecto, lo más adecuado es estudiar tanto las características del proyecto como las peculiaridades de la empresa y decidir qué es lo más adecuado para lograr el éxito.

Se trata de un movimiento imparable que se ha convertido en tendencia. Mal que le pese a los apóstoles del agilismo o del waterfall puros, muchos responsables de proyectos se han dado cuenta, a través de la experiencia, de que el éxito de un proyecto depende mucho de la cultura de la empresa y que el uso de prácticas o artefactos de las diferentes metodologías puede ayudar enormemente a llevar a buen fin un proyecto.

Ya nadie duda que las daylies que provienen del agilismo ayudan mucho a mejorar la comunicación del equipo y fomentan la transparencia.  Y lo mismo ocurre con las “Retrospectivas“, que proporcionan un feedback excelente acerca de lo que ha sucedido en una fase, iteración o proyecto. Por otra parte, el Business Case de la metodología Prince2 se ha demostrado que proporciona claridad en la definición de los objetivos del proyecto y la búsqueda de rentabilidad o de valor añadido. Es un hecho que muchos proyectos hacen un kickoff para iniciar sus proyectos y completan un Project Charter para definir lo que el proyecto debe cumplir.

A continuación, muestro un resumen de algunos de los enfoques de gestión de proyectos que pueden componer el enfoque híbrido:

  • Predictiva o Waterfall es una metodología tradicional en la que las tareas y fases se completan de manera lineal y secuencial, y cada etapa del proyecto debe completarse antes de que comience la siguiente. El Project Manager es responsable de priorizar y asignar tareas a los miembros del equipo. En el enfoque predictivo, los criterios utilizados para medir la calidad están claramente definidos al inicio del proyecto. Es ideal para proyectos en los que los requisitos están claros desde el principio (lo que no suele ser muy normal).
  • Agile implica fases cortas de trabajo colaborativo e iterativo con pruebas frecuentes y mejoras implementadas regularmente. Algunas fases y tareas ocurren al mismo tiempo que otras. En los proyectos ágiles, los equipos comparten la responsabilidad de gestionar su propio trabajo. Scrum y Kanban son ejemplos de marcos ágiles, que son enfoques de desarrollo específicos basados ​​en la filosofía Agile.
  • Scrum es un marco ágil que se enfoca en desarrollar, entregar y mantener proyectos y productos complejos a través de la colaboración, la responsabilidad y un proceso iterativo. El trabajo lo completan equipos pequeños y multifuncionales dirigidos por un Scrum Master y un Product Owner  y se divide en Sprints cortos con una lista seleccionada de entregables.
  • Kanban es tanto un enfoque ágil como una herramienta que proporciona retroalimentación visual sobre el estado del trabajo en progreso mediante el uso de tablas o gráficos Kanban. Con Kanban, los gerentes de proyecto usan notas adhesivas o tarjetas de notas en un tablero Kanban físico o digital para representar las tareas del equipo con categorías como “Por hacer”, “En progreso” y “Listo”.
  • Prince2 es una metodología de gestión de proyectos que se plantea sean realizados entre otras actividades considerando 7 temas: la Calidad, el Cambio, la estructura de roles del proyecto (Organización), los planes (Cuánto, Cómo, Cuando), el Riesgo y el Progreso del proyecto, justificado por un Business Case (o necesidad del negocio) que es la que evidencia la realización de ese proyecto.
  • Lean utiliza la herramienta de calidad 5S (clasificar, ordenar, limpiar, estandarizar, disciplina) para eliminar ocho áreas de desperdicio, ahorrar dinero, mejorar la calidad y agilizar los procesos. Los principios de Lean establecen que puede hacer más con menos al abordar las disfunciones que generan desperdicio. Lean implementa un sistema de programación Kanban para administrar la producción.
  • Six Sigma implica reducir las variaciones asegurando que los procesos de calidad se sigan en todo momento. El método Six Sigma sigue un enfoque de mejora de procesos llamado DMAIC, que significa definir, medir, analizar, mejorar y controlar.
  • Lean Six Sigma es una combinación de enfoques Lean y Six Sigma. A menudo se utiliza en proyectos que tienen como objetivo ahorrar dinero, mejorar la calidad y avanzar rápidamente en los procesos. Lean Six Sigma también es ideal para resolver problemas complejos o de alto riesgo. La herramienta de calidad 5S, el proceso DMAIC y el uso de tableros Kanban son todos componentes de este enfoque.

El examen de certificación se basa en la aplicación de los siguientes principios y conceptos: 

  • Manejar conflictos y liderar un equipo
  • Apoyar el desempeño del equipo, empoderar a los miembros del equipo y a las partes interesadas
  • Abordar y eliminar impedimentos, obstáculos y bloqueos para el equipo
  • Colaborar con las partes interesadas e involucrar a las partes interesadas
  • Desarrollar un entendimiento compartido, involucrar y apoyar a equipos virtuales
  • Ejecute el proyecto con la urgencia necesaria para ofrecer valor empresarial
  • Gestionar comunicaciones, evaluar y gestionar riesgos
  • Planificar y administrar el presupuesto, el cronograma, la calidad de los productos / entregables, el alcance, los cambios y los problemas del proyecto
  • Planificar y gestionar el cumplimiento del proyecto
  • Evaluar y entregar los beneficios y el valor del proyecto

Los dominios en  los que se basa el examen son los siguientes:

  1. People,
  2. Process
  3. Business Environement.

La siguiente tabla identifica la proporción de preguntas de cada dominio que aparecerán en el examen:

Por último comentar que el examen de certificación se puede realizar “on line” en modo “unproctored” y consta de 60 preguntas, que se deben completar en 75 minutos. Superar el examen proporciona 13 PDUs válidos para el mantenimiento de los poseedores de la certificación PMP.

Más información:

GOOGLE PROJECT MANAGEMENT CERTIFICATE

Certificate of completion¿A QUIÉN SE DIRIGE?

Explorando en Internet acerca de novedades en materia de gestión de Proyectos, recientemente descubrí que la mismísima GOOGLE está proponiendo un certificado profesional en materia de Project Management, y como todo lo que hace el gigante tecnológico es interesante, creo que es digno de echarle un buen vistazo.

¿Cuál es el origen de este Google Project Management Certificate?. Los certificados de carrera de Google son parte de Grow with Google, una iniciativa que se basa en los 20 años de historia de Google en la creación de productos, plataformas y servicios que ayudan a las personas y las empresas a crecer. El objetivo de los certificados profesionales de Google es proporcionar formación específica para cubrir las futuras demandas de profesionales que exigirá el mercado laboral. Afirman que se han decidido a lanzar esta certificación porque los gerentes de proyecto tienen una gran demanda. De hecho, comentan que un estudio del Project Management Institute descubrió que, para el año 2027, los empleadores necesitarán 87,7 millones de personas para ocupar puestos relacionados con la gestión de proyectos. A medida que el lugar de trabajo continúa creciendo y evolucionando, los gerentes de proyecto sirven como una pieza fundamental de la capacidad de una organización para adaptarse y permanecer ágil.

“Los gerentes de proyectos son solucionadores de problemas por naturaleza. Además de establecer el plan y guiar a los compañeros de equipo a través del proyecto, tienen la tarea de gestionar los cambios y los riesgos. ¡Cada día es dinámico y diferente para un gerente de proyecto porque está en el centro del proyecto, construyendo relaciones, priorizando tareas y entregando resultados! Usando varias herramientas y plantillas, así como un conjunto de habilidades únicas, el gerente de proyecto pone orden en el caos.” Google

La certificación no exige experiencia previa en la materia, se imparte 100 % en línea, se dicta exclusivamente en inglés y está pensada para poder ser compaginada con otras dedicaciones y ser completada en seis meses, a un ritmo de estudio sugerido de entre 5 y 10 horas por semana. Exige unas 140 horas de trabajo. Pero se puede completar antes.  Eso sí, si se completa antes de ese período mucho mejor, pues se paga por cada mes que se esté cursando, a razón de 32 €/mes.

El formato es tipo MOOC (Massive Open Online Course) y se realiza utilizando la conocida plataforma de formación on line Coursera. 

Los cursos están compuestos de diferentes tipos de ejercicios. Unos son de tipo test, en los cuales es necesario obtener un 80% mínimo para aprobarlo. También existen ejercicios interactivos situacionales. Y se deben completar diferentes plantillas (artefactos) como elaborar un Project Charter o cumplimentar un Impact Report que deben ser calificados por los compañeros de curso.  Y también existen preguntas abiertas que se lanzan al foro del curso para su análisis y discusión.

Además de enfocarse en adquirir conocimientos de Project Management, existe una parte del curso orientada a poder obtener empleo como Project Manager, presentando situaciones en las cuales se entra en un proceso de selección para ese puesto en una empresa. Google también apoya durante todo el proceso de preparación del trabajo con una herramienta de creación de currículum, entrevistas simuladas y soporte de redes profesionales para ayudarlo a conseguir un trabajo después de completar el programa.

En general, las habilidades que adquirirán con estos cursos incluirán:

  • Crear planes de gestión de riesgos
  • Comprender las técnicas de mejora de procesos
  • Gestionar escaladas, dinámicas de equipo y partes interesadas
  • Creación de presupuestos y navegación por adquisiciones
  • Utilizar software, herramientas y plantillas de gestión de proyectos
  • Practicar la gestión ágil de proyectos, con énfasis en Scrum

CURSOS QUE LO COMPONEN:

En concreto, este certificado se divide en seis cursos, que se pueden cursar de forma independiente:

Curso 1. Foundations of Project Management.

Los objetivos de este curso son:

Google Project Management

  • Definir la gestión de proyectos y describir qué constituye un proyecto.
  • Explorar las funciones y responsabilidades de la gestión de proyectos en una variedad de industrias.
  • Detallar las habilidades básicas que ayudan a un gerente de proyecto a tener éxito.
  • Describir el ciclo de vida de un proyecto y explicar el significado de cada fase.
  • Comparar diferentes metodologías y enfoques de gestión de programas y determinar cuál es más eficaz para un proyecto determinado.
  • Definir la estructura y cultura organizacional y explicar cómo impacta la gestión de proyectos.
  • Definir la gestión del cambio y describir el rol del director del proyecto en el proceso.

Curso 2. Project Initiation. Starting a Successful Project:

  • Comprender la importancia de la fase de inicio del proyecto del ciclo de vida del proyecto.
  • Describir los componentes clave de la fase de inicio del proyecto.
  • Determinar los beneficios y costos de un proyecto.
  • Definir y crear objetivos y entregables del proyecto medibles.
  • Definir el alcance del proyecto y diferenciar entre las tareas que están dentro y fuera del alcance.
  • Comprender cómo gestionar el deslizamiento del alcance para evitar afectar los objetivos del proyecto.
  • Definir y medir los criterios de éxito de un proyecto.
  • Completar un análisis de las partes interesadas y explicar su importancia.
  • Utilizar gráficos RACI para definir y comunicar las responsabilidades de los miembros del equipo del proyecto.
  • Comprender los componentes clave de los estatutos del proyecto y desarrollar un estatuto del proyecto para el inicio del proyecto.
  • Evaluar varias herramientas de gestión de proyectos para satisfacer las necesidades del proyecto.

Curso 3. Project Planning. Putting It All Together:

  • Describir los componentes de la fase de planificación del proyecto y su importancia.
  • Explicar por qué los hitos son importantes y cómo establecerlos.
  • Realizar estimaciones de tiempo precisas y describir técnicas para adquirirlas de los miembros del equipo.
  • Identificar herramientas y mejores prácticas para construir un plan de proyecto y un plan de gestión de riesgos.
  • Describir cómo estimar, rastrear y mantener un presupuesto.
  • Explicar el proceso de adquisiciones e identificar la documentación clave de adquisiciones.
  • Redactar un plan de comunicación y explicar cómo gestionarlo.
  • Explicar por qué los hitos son importantes y cómo establecerlos.
  • Explicar por qué es necesario un plan de proyecto y qué componentes contiene.
  • Realizar estimaciones de tiempo precisas y describir técnicas para adquirirlas de los miembros del equipo

Curso 4: Project Execution. Running the Project:

  • Identificar qué aspectos de un proyecto rastrear y comparar diferentes métodos de rastreo.
  • Discutir cómo gestionar y comunicar de forma eficaz los cambios, las dependencias y los riesgos.
  • Explicar los conceptos clave de gestión de la calidad de estándares de calidad, planificación de la calidad, garantía de calidad y control de calidad. –
  • Describir cómo crear una mejora continua y mejora de procesos y cómo medir la satisfacción del cliente.
  • Explicar el propósito de una retrospectiva y describir cómo realizar una.
  • Demuestre cómo priorizar y analizar datos y cómo comunicar la historia basada en datos de un proyecto.
  • Identificar herramientas que proporcionen una comunicación eficaz del equipo del proyecto y explorar las mejores prácticas para comunicar las actualizaciones del estado del proyecto.
  • Describir los pasos del proceso de cierre para las partes interesadas, el equipo del proyecto y los gerentes de proyecto.

Curso 5. Agile Project Management:

  • Explicar el enfoque y la filosofía de gestión de proyectos ágiles, incluidos los valores y principios.
  • Explicar los pilares de Scrum y cómo apoyan los valores de Scrum.
  • Identificar y comparar los roles esenciales en un equipo Scrum y qué los hace efectivos.
  • Construya y administre un Product Backlog y realice un Refinamiento del Backlog.
  • Describir los cinco eventos Scrum importantes y cómo configurar cada evento para un equipo Scrum.
  • Implementar las estrategias de entrega impulsadas por el valor de Agile y definir una hoja de ruta de valor.
  • Explicar cómo entrenar a un equipo ágil y ayudarlo a superar los desafíos.

Curso 6. Capstone. Applying Project Management in the Real World:

  • Completar una carta del proyecto, completando la información clave, incluido un resumen del proyecto, objetivos SMART, alcance, beneficios y costos.
  • Examinar la documentación del proyecto y realizar una investigación para identificar las tareas de un proyecto y organizar esas tareas e hitos del proyecto en un plan de proyecto.
  • Determinar los estándares de calidad y evalúe contra esos estándares para asegurarse de que el proyecto está logrando el nivel de calidad requerido.
  • Desarrollar informes efectivos para las partes interesadas aplicando estrategias de narración para describir los datos.

CONCLUSIONES

Sobre su nivel de dificultad, no es muy alta, pues es un curso de entrada en el mundo del Project Management y en ningún caso se acerca a dificultad de la certificación Prince2 Practitioner ni al certificado PMP, que requieren una preparación mucho más exigente y un examen rigurosamente vigilado por Pearson Vue (en el caso del PMP) y por Axelos (en el caso de Prince2). Pero es una excelente forma de acceder al Project Management, pues ofrece las técnicas para poder empezar a gestionar proyectos.

Lo más interesante de esta iniciativa es estudiar el enfoque de Google en materia de metodologías utilizadas en la gestion de proyectos. Y destacan que los Project o Product Managers en Google no utilizan una sola metodología en sus proyectos. Al contrario, tienen la prerrogativa de utilizar todas las metodologías que consideren oportunas según el tipo de proyecto, su entorno y sus circunstancias, lo que viene a ser una especie de enfoque híbridoAsí pues, pueden utilizar waterfall, Agile o Lean Six Sigma en cada una de las partes del proyecto, si consideran que este enfoque será el más adecuado para obtener los objetivos previamente definidos y previstos del proyecto.

Como conclusión, se trata de una muy interesante iniciativa que puede ser de ayuda a varios grupos de profesionales.

Para quien es este curso:

  • Por un lado, puede ayudar a los profesionales del Project Management que deseen actualizar o refrescar sus conocimientos. La visión de Google de la gestión de los proyectos es muy interesante. Su enfoque es muy práctico y toma lo mejor de cada una de las metodologías más conocidas. Y con los “artefactos” o plantillas hacen igual, usan el Project Charter, el análisis de stakeholders o el Project Plan de las metodologías “Waterfall” junto con los “burndown charts”, la pila de producto o los informes de retrospectivas de las metodologías ágiles. O los “Diagrama de Ishikawa” propios de Lean Six Sigma.
  • Por otra parte, puede ser una gran ayuda para los profesionales sin conocimientos en este campo (que es el verdadero público objetivo de este curso) y que deseen iniciarse en esta disciplina. Completar este curso puede contribuir para poder obtener la ya mencionada certificación CAPM del PMI. Y una vez adquirida la CAPM sería el momento adecuado para lanzarse a obtener el certificado PMP, que es sin ninguna duda la certificación más completa en materia de gestión de proyectos.  Disponer de la certificación PMP no significa ser mejor Project Manager, pero sí que se conocen todas las técnicas para hacer que un proyecto sea un éxito.
  • Y también puede ser un excelente recurso para los profesionales de otros sectores que, de un día para otro y en virtud del conocido y famoso artículo 33 , deben hacerse cargo de la gestión de un proyecto en una empresa, sin contar con conocimientos y/o experiencia, los llamados project managers “por accidente“.

Una nota final a tener en cuenta: dado que los MOOC tienen una tasa de finalización promedio de entre el 4% y el 10%, es importante prepararse para el éxito desde el principio y meditar cómo se tiene pensado estudiar para este certificado. Tener un plan de estudio, especialmente si el auto estudio no es lo tuyo, te ayudará a superar este curso y a retener todo lo que hayas aprendido. ¡Mucho Animo!

 

INICIACIÓN A KANBAN (II) – ENTENDER EL SISTEMA

INTRODUCCIÓN

Tras el primer post donde os enseñé los conceptos básicos y la filosofía de Kanban, en este vamos a introducir algunos conceptos ya aplicados al trabajo diario y a entender como funciona un sistema Kanban. Vamos a focalizarnos en ver como trabajar con los famosos tableros Kanban, ver que significa cada elemento del tablero y una pequeña introducción a las métricas, donde veremos dos métricas muy sencillas y dos tipo de gráficas muy simples que nos permitirán hacernos una idea de las posibilidades que vamos a poder obtener.

Representación del “trabajo en curso” (WIP)

  • En primer lugar, cuando hablamos de “Kanbans”, estamos hablando de “huecos” que hay en un determinado espacio. Si trasladamos esto a un panel, donde tenemos identificadas las columnas como los diferentes estados en los que pasa una tarea, podemos decir que en nuestro sistema, en cada estado, tenemos una cantidad limitada de trabajo que podemos hacer, definido por los kanbans que tengo en cada estado. Es muy común confundir los tickets con “kanbans”, pero realmente los tickets son tareas y los kanbans son los huecos que hay para hacer estas tareas. Un hueco vacío en el panel esta emitiendo una señal “pull” para que se traiga una tarea desde el estado anterior.

  • Esta forma de mostrar la capacidad de trabajo por cada estado en forma de huecos resulta engorrosa, por lo que la forma de representar la capacidad de cada estado e incluyendo un número con la capacidad encima de cada columna. Esta capacidad es un concepto fundamental de Kanban y es el “Work In Progress” (WIP) y define los número de tickets que pueden estar a la vez en un determinado estado. En el próximo post veremos un poco más en detalle este concepto y porque debemos de tener este valor lo más bajo posible para que el trabajo fluya lo más rápido posible. Si indicamos un símbolo de infinito o un “-“, significa que no hay WIP en esas columnas.

 

Sistemas push vs sistemas pull

  • Kanban es un sistema basado en “pull”. Esto quiere decir que busca la máxima eficiencia y optimización, adaptando en tiempo real la producción a la demanda.  Mediante este sistema, sólo producimos los que sabemos que vamos a realizar. En un sistema de fabricación, no tendría un stock o tendría un stock mínimo y solo fabricaría aquellos pedidos que ya tengo confirmados (Just-In-Time). En este caso, solo voy cogiendo tickets cuando tengo huecos, de forma que el trabajo fluya más rápido.
  • Un sistema “push” consistiría en coger muchos tickets e ir pasándolos de estado a estado, de forma que pueda asegurarme que tengo tickets suficientes en el siguiente estado (tengo stock suficiente para abastecer a la siguiente fase). Esta forma de trabajar nos rompería completamente la filosofía Kanban, ya que no tendría un WIP limitado y el tiempo de finalización de cada tarea se ralentizaría.

 

Compromiso diferido y políticas

  • El compromiso sobre cuando vamos a hacer algo se retrasa (lo diferimos) hasta el punto de compromiso. En ese momento, ya podemos comprometernos a un determinado tiempo si sabemos como se comporta nuestro sistema Kanban.
  • Hasta que llegamos a ese punto de compromiso, las diferentes ideas que se tienen son opciones para realizar tareas, que deben de ser priorizadas (en Kanban se llama Upstream y en siguientes post hablaremos más en detalle de ello). Una vez se ha priorizado la idea, se pasa a un estado en el que empezamos a contar y del que no podemos tirar hacía atrás. Una vez pasamos al estado de compromiso, la tarea tiene que finalizarse o cancelarse (habría que evitar siempre la cancelación ya que suponemos que ha pasado todo los filtros necesarios para asegurarnos que hay que realizar dicha tarea)
  • Uno de los principios de Kanban es hacer las políticas explícitas. Podemos ayudarnos de esto en los paneles indicando las políticas que tenemos que aplicar en cada uno de los estados. Por ejemplo, las entregas listas, por política, siempre se grabará en un determinado registro, se almacenará en una determinada base de datos, etc. Otro ejemplo podría ser que para las pruebas de usuario solo tendremos 15 días, etc., pero si podemos indicarlas en el panel, será transparente para todo el mundo.

Trabajo por lotes

  • Kanban también permite el trabajo por lotes (push). Estos se suele utilizar cuando realizamos tareas de priorización periódicas donde indicamos las tareas que están listas para desarrollarse. Por ejemplo, cada dos semanas se traspasa una carga de trabajo a la columna de listo con las tareas que ya están aprobadas para realizar. Es importante señalar que cuanto más largo en el tiempo sea esta carga de tareas, menos flexibilidad tendrá el sistema (ver el punto de replanificaciones y entregas frecuentes)

 

Descartes

  • Es importante tener en cuenta que debemos descartar ideas. Las ideas son opciones que tenemos para elegir y tenemos que seleccionar la que más valor aporta a la compañía. Si descartamos muchas y hacemos pocas, quiere decir que nuestra capacidad no es la adecuada ya que hay muchas necesidades pero poca capacidad. Un ratio muy bajo de descartes quieres decir que hacemos prácticamente todo lo que pedimos, sean ideas buenas o tal vez ideas que no aporten el beneficio esperado. Hay que tener en cuenta que el futuro es incierto, no sabemos si una idea va a acabar teniendo éxito o no. Un ratio equilibrado sería un 50% de descartes.

Replanificaciones y entregas frecuentes

  • Esta característica es una de las principales diferencias con respecto a Scrum. Mientras que en Scrum, tenemos un Sprint donde no se puede replanificar nada y no se entrega nada hasta el final del Sprint (normalmente 15 días), en Kanban tenemos más flexibilidad para gestionar las replanificaciones y las entregas. Lo ideal sería replanificar a demanda, es decir, en cuanto el sistema requiera una tarea, que en ese momento se pueda evaluar que tarea realizar y seleccionarla (planificación a demanda). Una mala idea es hacer una planificación a largo plazo (por ejemplo mensual) ya que en determinados sistemas, siempre surgen necesidades no planificadas que hacer que no se pueda cumplir dicha planificación. Kanban recomienda realizar reuniones de planificación semanales, para adecuar las tareas a las necesidades actuales.
  • El mismo criterio se aplica a las entregas. Si podemos realizar una entrega lo más rápido posible, antes se podrá aportar valor a la compañía. Una entrega a demanda es lo más ágil, aunque esto también tiene un coste, ya que no es lo mismo hacer 10 entregas en 10 días distintos que hacer una entrega un día de 10 tareas.
  • El concepto de agilidad consisten en entregar el trabajo correcto en el tiempo correcto, ni antes ni después.

Compromisos de entrega

  • Los compromisos de entrega se pueden retrasar hasta una fase posterior. Muchas veces, sobre todo si durante el proceso tenemos factores externos al sistema que no controlamos, no podremos tener un compromiso de entrega fiable. Por poner un ejemplo, en equipo de desarrollo de Software que una vez termine su desarrollo y sus pruebas, necesite otro equipo que realice pruebas de usuario. En este caso, Kanban permite crear compromisos de dos fases, con lo cual podremos medir el tiempo de nuestro sistema y su eficiencia por fases.

Métricas

En este punto vamos a ver dos tipos de métricas muy sencillas que podemos obtener de nuestro sistema, además de dos tipos de gráficas para medir, por ejemplo, las dos métricas que vamos a ver y poder estudiarlas.

Tiempo de espera del sistema y del cliente e Histogramas

  • Las primeras métricas que vamos a tener son los tiempos de espera del sistema y tiempo de espera del cliente. Mediante estas métricas, vamos a poder medir la velocidad de nuestro flujo de trabajo. Muy utilizadas para poder definir SLAs (acuerdos de niveles de servicio)
  • Tiempo de espera del sistema: Es el tiempo que transcurre desde que pasa el punto de compromiso hasta que pasa al primer estado con un WIP infinito. Con esto, podemos medir el tiempo que tarda una tarea desde que se empieza a trabajar en la tarea hasta que llegamos a un estado que no controlamos. Es importante avanzar que mediante el WIP de los estados vamos a poder controlar la velocidad del sistema y ajustarlo a nuestras necesidades, aunque lo veremos en el siguiente post.
  • Tiempo de espera del cliente: Es el tiempo desde el punto de compromiso hasta que ya lo tiene listo el cliente para utilizar. Con esta métrica, podemos indicar al cliente cuando tardará en tener disponible la petición.
  • Mediante un Histograma, vamos a poder visualizar de forma clara, por ejemplo, los días que tarda el cliente en tener la tarea disponible. En el siguiente ejemplo, podemos ver en primer lugar una tabla con todas las tareas realizadas y los días que hemos tardado en finalizarla. Si transformamos esta tabla desde el punto de vista de los días de espera, podemos ver la cantidad de tareas que se han realizado en unos determinados días. En este ejemplo, podemos ver que lo normal es que tardemos entre 3 y 4 días en realizar las tareas. Este estudio podemos ampliarlo añadiendo tipología de tareas para saber cuando tarda el sistema en realizar determinados tipos de tareas e ir dando aproximaciones de nuestra velocidad del flujo de trabajo.

Rendimiento y Run-Chart

  • En la métrica de rendimiento vamos a poder medir las tareas terminadas por unidad de tiempo, midiendo el ratio de tareas completadas.
  • Es una métrica muy útil para medir la productividad de un equipo. Por ejemplo, vamos a poder medir que un equipo hace, por ejemplo, 10 tareas a la semana o 30 tareas al mes y podremos ver como evoluciona el sistema.
  • Mediante un Run-Chart, podemos buscar tendencias o impactos en nuestro rendimiento. Por ejemplo, podemos incorporar nuevas acciones para mejorar nuestro sistema (mejora continua) y medir dicho impacto para saber si estamos mejorando por el contrario, estamos empeorando nuestro rendimiento.

Conclusiones

En este post hemos visto algunos conceptos claves de Kanban para poder diseñar los primeros paneles Kanban y un par de métricas muy sencillas de calcular para poder medir nuestro sistema. Recordar que no podemos mejorar lo que no medimos.

Próximo post

En el próximo post hablaremos de lo siguiente:

  • Diseño de los paneles: Algunas ideas para crear un buen panel Kanban
  • Diseño de tarjetas para ponerlas en el panel
  • La Ley de Little: Como mediante el WIP vamos a poder controlar nuestro flujo de trabajo
  • Métricas: Vamos a ver varias métricas más y entender un Diagrama Acumulativo de Flujo (CFD) para poder estudiar nuestro sistema.

 

 

INICIACIÓN A KANBAN (I) – CONCEPTOS PREVIOS

¿Qué significa Kanban?

Si nos vamos a la definición estricta, podemos decir que Kanban es un método para definir, gestionar y mejorar servicios que entregan trabajo del conocimiento, tales como servicios profesionales, trabajos o actividades en las que interviene la creatividad y el diseño, tanto de productos de software como físicos.

Un sistema Kanban consiste realmente en una cantidad de “tarjetas señales” o “Kanbans” en circulación. Algunos ejemplos de un sistema Kanban son:

  • En el palacio imperial de Tokio, para entrar te dan un ticket para poder entrar y cuando se acaban los tickets, ya no pueden entrar hasta que sale alguien y devuelve el ticket.
  • En la atracción de feria de los famosos “coches de choque” (¡Quien no ha subido alguna vez!), hay un número limitado de coches que pueden estar circulando a la vez.  Se podría decir que es un sistema Kanban.

Imaginaros un sistema donde no se controle la cantidad de “entes” en curso. Por ejemplo, Madrid en Navidad, entrar a ciertos pubs sin control de acceso, subir al metro en hora punta….. ¿Es un sistema un poco caótico? ¿Quién esta más cerca del grupo en un concierto? ¿Quién entra antes al metro?

Pues esto pasa cada día en nuestra vida diaria y en nuestro trabajo. Vamos asumiendo tareas y más tareas mientras que no nos damos cuenta inconscientemente que tenemos una capacidad límite. Mediante un sistema Kanban, se pretende controlar la cantidad de tareas que ponemos estar haciendo a la vez, para mejorar la calidad de vida, que no se acumulen las cosas sin hacer o a medias y poder estimar cuando vas a terminar las tareas. En definitiva, adaptamos la demanda a la capacidad de producir. Seguro que a nadie le ha pasado esto, ¿verdad?.

Principios directores

Kanban tiene 3 principios directores:

  • Sostenibilidad. A nivel individual, evita sobrecarga, mejora la calidad y produce orgullo profesional y satisfacción en el cliente
  • Orientación al servicio. A nivel de gestión intermedia, se entrega valor de forma rápida, predecible y realista. Hacia un nivel superior, podremos responder a cuestiones complejas con confianza. Hacia un nivel inferior, podremos tomar decisiones difíciles con confianza
  • Supervivencia. A nivel de gestión senior: Realizar promesas que puedes cumplir y liderar el negocio, a nivel de estrategia y posicionamiento.

 


El método Kanban

El método Kanban consiste en una serie de valores y principios que rigen el sistema. En concreto, existen los valores de Kanban, los principios de entrega de servicio, los principios del cambio y las prácticas generales.

Valores Kanban

Hay un valor fundamental que engloba a todos que consiste en respetar a todos los individuos que contribuyen colaborativamente en una organización. Además, hay una serie de valores también que son necesarios para poder aplicar este método:

  • Transparencia: La creencia de que compartir información abiertamente mejora el flujo de valor de negocio. Utilizar un lenguaje claro y directo es parte del valor.
  • Equilibrio: El entendimiento de que los diferentes aspectos, puntos de vista y capacidades deben ser equilibrados para conseguir efectividad. Algunos aspectos (como demanda y capacidad) causarán colapso si no se encuentran equilibrados por un periodo prolongado.
  • Colaboración: Trabajar juntos. El Método Kanban fue formulado para mejorar la manera en que las personas trabajan juntas, por ello, la colaboración esta en su corazón.
  • Foco en el cliente: Conociendo el objetivo para el sistema. Cada sistema Kanban fluye a un punto de valor realizable — cuando los clientes reciben un elemento solicitado o servicio. Los clientes en este contexto son externos al servicio, pero pueden ser internos o externos a la organización como un todo. Los clientes y el valor que estos reciben es el foco natural en Kanban.
  • Flujo: La realización de ese trabajo es el flujo de valor, tanto si es continuo como puntual. Ver el flujo es un punto de partida esencial en el uso de Kanban.
  • Liderazgo: La habilidad de inspirar a otros a la acción a través del ejemplo, de las palabras y la reflexión. Muchas organizaciones tienen diferentes grados de jerarquía estructural, pero en Kanban, el liderazgo es necesario a todos los niveles para alcanzar la entrega de valor y la mejora.
  • Entendimiento: Principalmente conocimiento de si mismo (tanto individual como de la organización) para ir hacia adelante. Kanban es un método de mejora, por lo que conocer el punto de inicio es la base de todo.
  • Acuerdo: El compromiso de avanzar juntos hacia los objetivos, respetando — y donde sea posible, acomodando — las diferencias de opinión o aproximaciones. Esto no es gestión por consenso sino un co-compromiso dinámico para mejorar.
  • Respeto: Valorando, entendiendo y mostrando consideración por las personas. De manera apropiada al pie de esta lista se encuentra la base sobre la cual reposan el resto de valores.

Principio de entrega de servicios

¿Qué es un servicio?

Un cliente tiene una necesidad y el servicio responde a esa necesidad con una serie de actividades. El cliente acepta el resultado.

La organización es una red de servicios interdependientes con políticas que terminan su comportamiento:

  • Entiende y pon foco en las necesidades y expectativas del cliente
  • Gestiona el trabajo, deja que los trabajadores se gestionen alrededor de dicho trabajo
  • Revisa regularmente la red y sus políticas para mejorar los resultados

 

Principio de gestión del cambio

  1. Empieza por lo que haces
    1. Entiende los procesos actuales
    2. Respecta los roles actuales, responsabilidades y puestos
  2. Acordar en buscar mejoras a través del cambio evolutivo
  3. Fomentar el liderazgo en todos los niveles de la organización

El método Kanban usa ….

… tableros Kanban para visualizar el trabajo invisible, los flujos y los riesgos del negocio junto con sistemas Kanban para limitar el trabajo en curso.

El método Kanban entrega ….

velocidad, entrega de servicios más predecibles y capacidades de adaptación que permite que puedas responder eficientemente a los cambios en las demandas de los clientes o de tu entorno de negocio.

Prácticas Generales

Visualizar:

  • Ver el trabajo y su flujo
  • Visualiza los riesgos
  • Construye un modelo visual que refleje tu trabajo

Limitar el WIP:

  • Para de empezar y empieza a terminar
  • De izquierda a derecha
  • Limita el trabajo a la capacidad

Gestionar el flujo de trabajo:

  • Flujo es el movimiento del trabajo
  • Gestiona el flujo de forma suave y predecible
  • Usa datos

Hacer explícitas las políticas:

  • Haced visibles las políticas a todos
  • Clases de servicio, límite WIP, criterio de siguiente tarea, dependencias, gestión de bloqueos …

Circuitos de retroalimentación:

  • Establecimiento de circuitos de retroalimentación mediante cadencias (reuniones periódicas)
  • Rapidez en la colaboración, aprendizaje y mejoras
  • Conducción por datos

Mejorar & evolucionar:

  • Usa el método científico
  • Cambio guiado por las hipótesis
  • Ejecuta experimentos seguros ante fallos

 

Conclusiones

  • “Kanbaniza” tus procesos existentes. No es necesario un cambio brusco. Empieza con los procesos que tienes y como funcionan ahora y verás como poco a poco vas cambiando cosas y detectando mejoras en tus procesos que hacen que sean más óptimos.
  • Provoca cambios para mejorar los procesos existentes. No tengas miedo a equivocarte. Todos nos equivocamos pero si no eres valiente e intentas provocar cambios, nunca podrás mejorar un proceso. Lo importante es saber rectificar a tiempo y aprender de dichos errores. Quien no se equivoca, no aprende.
  • Cada flujo engloba a una ventana de un proceso, dentro de su contexto. Kanbaniza primero una ventana de un proceso y esto hará que poco a poco vayas Kanbanizando todo el proceso de forma escalada. Pensemos que con Kanban optimizamos cada flujo. Más adelante, ya veremos como realizar Kanban Escalado para toda una organización.
  • Los clientes y empleados mejorarán su satisfacción. Menos sobrecarga de las personas, menos tareas que se eternizan y producen frustración, menos tiempo en terminar las tareas ( y antes están a disposición del cliente)

 

Próximos post:

  • Entender sistemas Kanban: ¡Empecemos a diseñar un sistema Kanban y a obtener algunas métricas sencillas !
  • Introducir Kanban en las organizaciones con el método STATIK
  • Cambio evolucionario: Protokanban
  • Kanban para la empresa: Orientación al servicio, Escalabilidad, Gestión de la demanda (Upstream) y Roles
  • Cadencias Kanban. ¿Los clientes están contentos? Circuitos de retroalimentación
  • Flujos de comunicación y técnicas de mejoras: Métricas avanzadas, interrupciones y dependencias, cuellos de botella y sobrecarga e ineficiencia

 

 

 

 

 

 

 

TÉCNICOS “BLACK BOX”

QUÉ ES:

A raíz de una conversación de oficina surgió un tema muy interesante que es el de los llamados técnicos “Black Box”. Un “Black Box”,  es “Una persona que produce ella misma o contribuye a producir un bien o servicio, según unas especificaciones, mediante un proceso que su supervisor entiende sólo en términos generales y que él mismo no domina” *. Para entendernos, es un técnico que desarrolla unas tareas técnicas que su responsable no entiende.  Es una figura muy común dentro del mundo de la informática o de la ingeniería.

Existen diferentes grados en esto, desde el Black Box puro, en el cual su responsable no conoce en absoluto las tareas técnicas que realiza el Black Box a su cargo, pasando por el “White Box” en el cual el trabajo se entiende perfectamente y se puede reproducir también fácilmente, hasta el “Grey Box”, donde su responsable conoce y entiende las tareas que desempeña el técnico, aunque le costaría realizarlas.

Hay que diferenciar la capa técnica y la capa de gestión dentro del trabajo en las empresas y especialmente dentro de los proyectos. El Project Manager debería enfocarse en la gestión del proyecto y los técnicos enfocarse en la parte técnica. Por otra parte, algunos técnicos Back Box no aprecian el valor añadido que proporciona la capa de gestión y solo valoran la capa técnica.

Estos son los problemas que puede generar la gestión de los técnicos Black Box*:

  • De control: no informan porque no lo consideran necesario y porque creen que su responsable tampoco lo entendería. No quieren sentirse controlados. Pero existen proyectos con grandes inversiones o de gran riesgo que requieren reportes de status frecuentes. Esta actitud provoca stress a sus responsables. Tener una necesidad de control relativamente baja es esencial. Un Project Manager, por ejemplo, que no sepa delegar, puede tener un gran problema con la coordinación de los Black Box.
  • De motivación: suelen ser personas auto motivadas y además se molestan si alguien quiere tratar de motivarles. El pensamiento Wishful thinking es contraproducente aquí.
  • De poder: pueden querer convertirse en indispensables en la empresa no compartiendo su conocimiento. La crisis económica y el miedo a ser despedido puede hacer que este punto se convierta en relevante. Además, el jefe depende del tecnioc Black Box para obtener sus objetivos personales, lo que agrava la situación.
  • Otros factores: aquí pueden intervenir otras circunstancias que pueden empeorar la situación, tales como el coste del proyecto, su duración, su complejidad, la escasez de técnicos Black Box en el mercado laboral, etc…

Problemas que puede generar:

  • Depende de la personalidad del supervisor, que puede ver la actitud del técnico Black Box como una amenaza a su autoridad o una oportunidad (no tener que preocuparse de esas tareas)
  • Algunos técnicos Black Box  pueden no respetar a su supervisor como por considerar que no está cualificado técnicamente.  Aquí existe un gran matiz cultural:
    • En los países mediterráneos y en  Latino América la obligación de los gestores de conocer los que saben sus colaboradores es muy fuerte. Se presupone que el supervisor conoce perfectamente el trabajo que realiza el BB. No hace falta decir que esto puede suponer una gran fuente de stress para el supervisor, pues necesita estar actualizandose continuamente para conocer el trabajo técnico, pudiendo dejar del lado la capa de gestión que es precisamente su labor principal.
    • Los países escandinavos y anglosajones no están de acuerdo con la aseveración de que el supervisor debe entender y saber hacer el trabajo de sus colaboradores. En este esquema, está claramente definido que el gestor gestiona y el técnico Black Box ejecuta el trabajo técnico.

Los comportamientos adecuados con los BB serían:

  • Escucharlos
  • Ayudarles
  • Protegerles de interferencias
  • Reducir su stress
  • Controlarles, pero sin ofenderles
  • Mostrarles respeto

EN RELACIÓN A LA GESTIÓN DE PROYECTOS:

Dentro del PMBOK V6 el proceso 9-5 es “Dirigir al Equipo”, que se puede definir como el “proceso que consiste en hacer seguimiento del desempeño de los miembros del equipo, proporcionar retroalimentación, resolver problemas y gestionar cambios en el equipo a fin de optimizar el desempeño del proyecto.”

Implica para el Project Manager del proyecto disponer de una combinación de habilidades, entre ellas la comunicación, gestión de conflictos, liderazgo y la negociación.

Y aquí entramos en un dilema eterno en materia de gestión de proyectos, el Project Manager (PM) ¿Debe conocer técnicamente lo que conocen los técnicos que trabajan en el proyecto? La respuesta oficial  sería que no es necesario (porque un gestor de proyectos debería de poder dirigir proyectos multidisciplinares y transversales en todos los sectores, con independencia de la materia sobre la que verse) pero acto seguido hay que reconocer que el conocimiento técnico del PM de la materia sobre la que trata el proyecto tiene interesantes ventajas (por ejemplo, las estimaciones de las tareas pueden ser más precisas, se podrán controlar mejor los riesgos) y solo un posible inconveniente (que el PM trabaje de técnico y no gestione el proyecto). Pero insistiendo en la idea de que es imposible saber de todo. Un buen jefe de proyectos debe quitarse la “gorra” de técnico y ponerse la de gestor.

Otro factor que agrava este problema es el Efecto “Halo” que es muy común en materia de proyectos. Se refiere de forma genérica a una “Desviación cognitiva por la que la percepción de una característica de una persona está influenciada por la percepción de otras características de esa persona.” Un ejemplo es pensar que una persona que fue un gran jugador de fútbol deba ser un gran entrenador. Específicamente, en materia de gestión de proyectos, se cae frecuentemente en que se elige al mejor técnico, al que más sabe en la materia para que pase a gestionar proyectos, lo que significa pasar de gestionar tareas a gestionar personas, lo que significa gestionar conflictos. Y claro está, resulta evidente que un excelente técnico no tiene por qué ser por sí mismo un buen gestor de proyectos.

El Project Manager debe disponer de habilidades interpersonales y de equipo, que incluyen, entre otras, la resolución de conflictos.

Las técnicas de resolución de conflictos son las siguientes:

  • Apartarse/Eludir: Retirarse de una situación de conflicto real o potencial
  • Suavizar/Reconciliar: Reforzar los puntos de acuerdo más que en las diferencias.
  • Consentir: Buscar soluciones que aporten un cierto grado de satisfacción a todas las partes.
  • Forzar: Imponer su propio punto de vista a costa de los demás; ofrece soluciones únicamente de tipo ganar-perder.
  • Colaborar: Incorporar múltiples puntos de vista y visiones a partir de perspectivas diversas; conduce al consenso y al compromiso.
  • Confrontar/Resolver Problemas: Tratar un conflicto como un problema que debe resolverse mediante el examen de alternativas; requiere una actitud de concesión mutua y un diálogo abierto.

Una mención aparte merece el tema de las Comunicaciones. Es curiosa una regla ya mencionada de que cuantas más capacidades técnicas tiene una persona, menos capacidades “blandas” posee, (liderazgo, el desarrollo del espíritu de equipo, la motivación, comunicación, influencia, la habilidad para resolver conflictos y la negociación). Esto podría ser problema cuando se trata de supervisar a los técnicos Black Box. Este es un punto que debe cuidar el Project Manager, pues el contacto con estos colaboradores podría resultar complejo y frustrante. Y es una obligación del Project Manager desarrollar al equipo del proyecto, y esto implica:

  • Mejorar la motivación, las habilidades y la capacidad de los miembros del equipo, a fin de aumentar su competencia para completar las actividades del proyecto.
  • Mejorar los sentimientos de confianza y cohesión entre los miembros del equipo con el fin de incrementar su productividad a través de un mejor trabajo en equipo.
  • Crear una dinámica de cooperación, trabajo en equipo y capacidad para compartir conocimiento y experiencia.

La necesidad de gestionar adecuadamente las personalidades de tipo Black Box está creciendo, a medida que el mundo laboral se especializa más y más. La globalización de las empresas amplifica este fenomeno. Y su gestión plantea un gran desafío dentro de los proyectos y más con el advenimiento y extensión de las metodologías ágiles. Este tema se relaciona con el cambio de papel de los Project Manager, que pasan de ostentar un liderazgo jerárquico a un liderazgo colaborativo o facilitador, siendo capaces de delegar o empoderar a su equipo.

Y en el mundo de la gestión ágil, se plantea un interesante dilema respecto a la figura del Scrum Master, pues sus funciones son apoyar y tutelar al equipo y ayudar a entender la teoría scrum y sus reglas, valores y prácticas. Esta figura choca frontalmente con la necesidad de autonomía que tienen los técnicos Black Box.

*Fuentes:

  • PMBOK 6 PMI
  • Instituto de Empresa. Informe NT CT13002
  • Manifiesto Ágil.