Noticias

La siguiente imagen ya es un clásico y aun cuando en su concepción se asociaba a desarrollo de software, y un incorrecto entendimiento de las necesidades del usuario, dicha situación es transversal a proyectos de toda índole, y sucede con más frecuencia de la que quisiéramos.

 

Una encuesta a nivel mundial que hizo PMI el 2018 indica que la medición y porcentaje de proyectos que registraron corrupción de alcance fue de un 30% de la cartera de proyectos implementados entre las organizaciones encuestadas.   

Un pobre entendimiento/involucramiento en la comprensión del ámbito de negocio que enmarca la necesidad del proyecto puede llevar a múltiples problemas, tales como:

• Riesgos se convierten en incidentes.
• Retrasos en el proyecto.
• Cambios de alcance ya que se debe implementar lo no considerado.
• Aparecen interesados no identificados e impactados que provocan resistencia al proyecto.
• Funcionalidades que no fueron consideradas debido a deficiencias en la comprensión de los requisitos.
• Normativas no consideradas del país en el cual se desarrolla el proyecto.
• Alcance del proyecto mal definido.

Diversas son las razones que pueden llevar a que el jefe/equipo de proyecto desconozcan el negocio/flujo/proceso en el cual se implementará el proyecto, aun cuando puede ser esperable en determinadas situaciones, esto ocasiona muchas veces, sesgos en el equipo o “cajas negras” que en la medida que avanza el proyecto al no haber sido debidamente trabajadas, provocan los impactos descritos anteriormente.

 

¿Qué implica el end-to-end?

Habitualmente los entregables o el producto del proyecto conviven o forman parte una operación de negocio, y como tal esperan brindar los beneficios previamente fijados en los objetivos del proyecto.

La comprensión que necesitamos desarrollar requiere:

• Visión de principio a fin, considera el viaje del cliente (Customer Journey) identificando todas las relaciones y dependencias que condicionan la implementación del proyecto, pudiendo implicar nuevos requisitos o bien consideraciones que los entregables del proyecto tendrán una vez implementados.
• La mirada global apunta a que el equipo del proyecto considere todos los aspectos necesarios que deban ser gestionados a tiempo para el éxito del proyecto.
  • Permisos legales, tributarios, normativos de la industria en el que se implementará el proyecto.
  • Riesgos adicionales que el flujo global puede estar condicionando el proyecto.
• No pensar en silos e involucrar a todas las áreas de negocio que se pueden ver impactados directa o indirectamente por el proyecto.
• Comprender los procesos de negocio involucrados en el proyecto, esto obliga al equipo a profundizar el entendimiento de los requisitos y necesidades del cliente final, entender los objetivos detrás de la misma, empatizar con los usuarios y clientes finales y visualizar la situación actual versus la situación final (proyecto implementado).

 

Claves para incentivar este enfoque

Es necesario considerar ciertas directrices para propiciar una mirada end-to-end cuando se implementan proyectos, y esta debe suceder desde las etapas iniciales del mismo con mayor énfasis, ya que el costo de posibles controles de cambio será inversamente proporcional en la medida en que se avanza en la ejecución del proyecto.

El objetivo principal es entregar valor al cliente final, comprendiendo las actividades y funciones relacionadas con la entrega del alcance comprometido para el objetivo sobre el cual se llevó a cabo el proyecto.

De igual manera, es más que enfocarse únicamente en los entregables, que por cierto son vitales, sino más bien, en el resultado global del proyecto y como éste cumple los beneficios a nuestros clientes.

Esta entrega implica cumplir con las expectativas que tienen un alto grado de subjetividad, habitualmente los equipos se enfocan únicamente en las necesidades o requisitos del cliente, descuidando las expectativas, las cuales apuntan a un ámbito emocional y donde el cliente visualiza los resultados muchas veces desde un enfoque idealista.

Dado lo anterior, suele ocurrir que al término del proyecto se produce una dicotomía entre lo obtenido como resultado del proyecto versus las expectativas del mismo.

Es importante además que, como equipo de proyecto o líder del proyecto, tengamos presente que los clientes valorar de manera diferente los resultados del proyecto. Algunos valorarán “cuanto pueden mejorar sus ventas”, otros la “facilidad de uso de una app” y como le simplifica un proceso complejo, “como pueden reducir los tiempos de procesamiento” en su operación diaria, etc.

La dificultad principal en identificar el end-to-end de un proyecto, es lograr un entendimiento común respecto del mismo, entre todos los interesados (incluidos el equipo de proyecto), y comprender además a cabalidad, el entorno funcional del mismo, sólo así, tendremos sinergia entre los requisitos, las expectativas y el valor esperado.

 

Algunas herramientas útiles para fomentar E2E

 

Las siguientes herramientas incentivan una mirada integral en la comprensión de la necesidad que origina el proyecto, además de la elaboración del flujo funcional que es la base para comprender el end-to-end.

Mapas mentales.

 

Descripción: dicen que más vale una imagen que mil palabras. Pues cuando capturas los requisitos de usuario, si los complementas con mapas mentales, puedes comprender: el flujo de negocio detrás de la necesidad, el alcance del trabajo a realizar y además verificar que el equipo comprendió lo que el cliente requiere. Esto es; tener un entendimiento común de la necesidad. Se puede realizar a mano alzada o en pizarra, para luego documentarlo en una aplicación.

Beneficios: comprensión visual para los interesados y para el equipo. Se puede implementar a mano alzada, esto da rapidez en borradores, para luego iterar en sesiones de equipo, hasta llegar a las versiones finales.

Procedimiento para llevarlo a cabo:

• Paso 1: Se define la idea central, el concepto principal. Ejemplo: “Un servicio técnico de teléfonos”.
• Paso 2: Añade las palabras clave que son conceptos secundarios y relacionados al concepto principal, que en este caso describen a la idea principal. Se realiza como lluvia de ideas. Ejemplo; reparación, venta dispositivos, recepción, recaudación, etc.
• Paso 3: Incluye las ideas complementarias que se desprenden de los conceptos secundarios y que son aperturas de los conceptos secundarios.
• Paso 4: Crea conexiones entre las ideas, las que se relacionen directamente.
• Paso 5: Agrega ilustraciones e imágenes que te ayuden y aporten al cliente.

Software para diseñarlos: miro.com (libre), creately.com. (Gratuito hasta cierta cantidad de diseños) y Microsoft Visio (con licencia).

 

User Journey Map.

Descripción: Inicialmente la técnica customer journey(viaje del cliente) surgió en el contexto de las interacciones que realiza un consumidor en un proceso de compra u obtención de algún servicio con un oferente(vendedor) sea organización o personas. No obstante, esta puede ser utilizada en diversos ámbitos y es especialmente adecuada para reflejar todas aquellas interacciones del cliente con su entorno, en el cual, por supuesto estará inmerso el proyecto, ahí está la clave, el poder realizar el levantamiento del “viaje” considerando el “to be” la situación futura del cliente o usuario y el proyecto una vez implementado.

Beneficios: es la herramienta ideal para detallar el end-to-end de los proyectos, ya que permite identificar claramente todas aquellas interacciones que el negocio o proceso(s) que involucran al proyecto y como se relaciona con su entorno. Más aun con los “pain point” o “dolores” que el cliente vive y que generan la necesidad del proyecto, ejemplo:

• Proyectos que no han cumplido con lo comprometido.
• Necesidades, Problemas, incidencias en la operación.
• Interrupciones en la entrega del servicio que impiden lograr los objetivos de negocio.

Formatos para plasmar un viaje del cliente hay múltiples, un ejemplo de plantilla puede ser el siguiente:

 

Donde:

1. El enfoque es sobre las interacciones del cliente final con el producto que generará el proyecto, a través de las distintas etapas del flujo de negocio que lo acompaña. Identifica las acciones que se suceden.
2. Corresponde a las etapas que participan en el flujo, la profundidad dependerá de la necesidad del equipo del proyecto según la comprensión de negocio buscada.
3. Son las actividades que se registran en la matriz.
4. Corresponde al feedback que se obtiene de las reuniones de trabajo con los clientes, es un “termómetro” de la experiencia y expectativas del cliente en cada etapa.

Cada una de las filas corresponde a ámbitos que se desean detallar según la profundidad requerida en el flujo de negocio.

Diagrama de Flujo de Datos (DFD).

Descripción: se emplean símbolos definidos, como rectángulos, círculos y flechas, además de etiquetas de texto breves, para mostrar las entradas y salidas de datos, los puntos de almacenamiento y las rutas entre cada destino. Los diagramas de flujo de datos pueden variar desde simples panoramas de procesos incluso trazados a mano, hasta DFD muy detallados y con múltiples niveles que profundizan progresivamente en cómo se manejan los datos.  

Beneficios: permite tener una visión global de la información que sale y entra, en un proceso de la organización, o entre áreas, o sistemas.

El siguiente esquema permite visualizar como la información se interactúa entre áreas en un flujo de proceso específico, teniendo una mirada global del proceso funcional, sus falencias y posibles mejoras. 

Datos útiles:

 Una aplicación online para este y otros diagramas:

• Miro que es una herramienta colaborativa y que soporta sesiones con múltiples usuarios, muy usadas para sesiones ágiles en la actualidad. www.miro.com.
• También Microsoft Visio es muy completa para éste tipo de diagramas, pero con pago por licencia de uso.

 

Job Shadowing u Observación.

Descripción: se enfoca en la observación, apoyado por entrevista con los interesados o usuarios que llevan a cabo las actividades del proceso/flujo de negocio que es parte del “core” que deseamos relevar. Ejemplo: Una fábrica de zapatos, significaría observar (no sólo conversar o entrevistar) todos aquellos roles que son parte del flujo de negocio requerido. En industrias TI o Tecnológicas por ejemplo es habitual que producto de la aplicación de esta técnica se obtengan métricas como:

• Cantidad de interacciones que llevan a cabo los usuarios en el sistema o aplicación que utilizan como parte del proceso a relevar.
• Falencias o puntos de falla del sistema o aplicación.
• Tiempos de proceso de ejecución de las funcionalidades del sistema o aplicación.
• Por supuesto, todo lo relativo a la experiencia del cliente.

Beneficios: observar que va más allá del relato, la operación diaria de la organización (in-situ), permite conocer, documentar y ver los puntos críticos del flujo y lo que se puede mejorar. No hay mejor feedback que de primera fuente, vivenciar y evidenciar las actividades que serán el foco de intervención de nuestro proyecto, nos permite además de documentar el flujo actual, conocer los “dolores” del usuario (cliente) y sus expectativas.

Procedimiento:

1. Acordar las sesiones de observación con el cliente/usuarios.
2. Documentar los puntos principales de la operación observada.
3. Ideal apoyar con Diagramas de Contexto.
4. Trabajar internamente lo documentado.
5. En sesión con los protagonistas del proceso, validar los mapas y asegurar que lo representado refleje la realidad.

Independiente del enfoque utilizado, hay características que los requisitos o la necesidad del cliente deben cumplir para asegurar que el alcance del trabajo esté bien relevado y por consiguiente se traduzca en una mejor entrega de valor.

Es importante que el equipo del proyecto se centre en la entrega de los aspectos requeridos para el producto o entregable, pero sin olvidar la relevancia de satisfacer y saber gestionar las expectativas de los interesados.

Y tú, ¿cómo aseguras tus proyectos de principio a fin?

 

Carlos Álvarez G. 

Revisor y colaborador de la Guía PMBOK® 7.0. Consultor en Gestión de Proyectos.

Santiago, mayo 2023.