Muchas veces en los proyectos nos olvidamos de un punto crítico, cumplir o superar las expectativas de los clientes.
Podemos acabar un proyecto en tiempo, coste y con el alcance definido pero tener al cliente descontento, debido a que el resultado del proyecto no era el esperado, aquí un ejemplo clásico:
¿Cómo podemos evitar esta situación?
Pues haciendo uso de una série de buenas prácticas que nos van a permitir definir correctamente, y gestionar a lo largo de todo el proyecto las expectativas de los diferentes interesados
¡Vamos a ello!
Definir unas expectativas realistas
Parece un punto lógico, pero no siempre es así, muchas veces se «promete» o se «vende» algo que luego no podemos entregar o no con con todas las funcionalidades que el cliente esperaba.
Por ello es importante dedicar tiempo al inicio del proyecto para definir correctamente lo que se pretende obtener, el resultado del proyecto y concretar con el cliente sus expectativas iniciales.
Involucración en Fase de ánalisis del PM
Es importante que el PM del proyecto, esté cuanto antes involucrado, incluso en fases de análisis o pre-venta, para que pueda aportar su conocimiento y visión.
Muchas veces se venden proyectos «imposibles», es decir que se firman y cuando llegas tú un lunes por la mañana y te «cae» el proyecto, ya a primeras ves que no tiene ni pies ni cabeza o que se ha prometido finalizarlo en fechas imposibles si tienes en cuenta los recursos actuales de los que se disponen.
Para evitar este tipo de situaciones, siempre habría que intentar que el PM pueda estar previamente informado y dar su opinión.
Documentar Requisitos
Definir con todo el detalle posible, el alcance del proyecto, documentando los requisitos. Hay que hablar con todas las partes interesadas, que impacten o que reciban impacto del proyecto.
Esto supone escuchar (sin excepción) a todos los impactados para el proyecto en concreto, desde la dirección, directores de área, usuario final, hasta el departamento de limpieza si se diera el caso (cuantas veces han caído servicios informáticos, por un «golpe de mocho» en el cableado de los racks de los servidores, por no haber comunicado adecuadamente o escuchado los «problemas» de algunos interesados, como puede ser el equipo de limpieza).
Es una tarea no siempre fácil, y en muchos proyectos se cae en el error de delegar estas «entrevistas» con los interesados a perfiles con poca experiencia, que no tienen la capacidad o los conocimientos adecuados para realizar una correcta y detallada toma de requisitos.
Comunicar Expectativas
Esto es importante a lo largo de TODO el proyecto, al inicio cuando se documentan y durante el transcurso del proyecto, si hay cambios o modificiaciones, debemos ir gestionando y comunicando estas expectativas.
Es muy importante la comunicación en todo momento y con todas las partes, para que sepan lo que va sucediendo en todo momento y si hay cambios importantes de los que tengan que estar informados, evitando así sorpresas no esperadas.
Presentar entregables intermedios
A la vez que comunicamos, a medida que avanzamos el trabajo, es interesante ir proporcionando «demos» o «muestras» al cliente para confirmar que el trabajo generado es el esperado.
Es un fallo clásico, el esperar al final de proyecto para hacer la demo final o entrega, y encontrarse con que lo que se entrega no era lo que el cliente se esperaba (con todo el problema que esto puede suponer).
Espero que estos 5 consejos/buenas prácticas te ayuden a enfocar correctamente la gestión de expectativas en tus proyectos.
Como siempre, tus comentarios y/o apreciaciones serán más que bienvenidos 🙂
Por favor, ayuda a difundir estos contenidos:
💬 Comparte tu opinión y deja tu comentario
👌 Pulsa «Like / Recomendar»
⏭️ Difunde y comparte entre tus contactos
4 respuestas
Gracias Alejandro por los consejos para gestionar las expectativas en los proyectos.
El ejemplo ilustrativo de los árboles vale mas que mil palabras.
Este asunto es interesante y complejo, porque se presentan casos que hacen difícil identificar claramente la expectativa. Por ejemplo:
1) Existen clientes que no saben lo que quieren
2) Existen proveedores que no tienen el conocimiento ni experiencia para ayudar a los señalados en el punto 1.
3) Existen clientes que al parecer lo saben todo. Siempre quieren tener la razón.
4) Existen emociones y sentimientos que afectan el desempeño del cerebro.
5) Existe el pensamiento antagónico, el pensamiento paralelo y quien sabe no falte mucho para que hablen de pensamiento cuántico. Y un dato interesante es que las mujeres usan el pensamiento paralelo de forma natural a diferencia del hombre.
6) Existen valores positivos y negativos que tienen las personas.
Y podríamos seguir enumerando la lista y tal vez nunca acabemos.
Pero mejor vamos a lo que el PMI dice y que considero debe ampliar:
1.1.3 Código de Ética y Conducta Profesional
El PMI publica el Código de Ética y Conducta Profesional [5] para infundir confianza en la profesión de dirección de proyectos y para ayudar a un individuo a tomar decisiones inteligentes, especialmente frente a situaciones difíciles donde puede que al individuo se le pida comprometer su integridad o sus valores. Los valores que la comunidad global de la dirección de proyectos definió como más importantes son la responsabilidad, el respeto, la imparcialidad y la honestidad. El Código de Ética y Conducta Profesional se sustenta en estos cuatro valores.
El Código de Ética y Conducta Profesional incluye tanto estándares deseables como estándares obligatorios. Los estándares deseables describen la conducta que los profesionales que son miembros, poseedores de certificación o voluntarios del PMI se esfuerzan por mantener. Si bien el cumplimiento de los estándares deseables no es fácil de medir, la conducta acorde a ellos constituye una expectativa para quienes se consideran profesionales—no es opcional.
Los estándares obligatorios establecen requisitos firmes y, en algunos casos, limitan o prohíben el comportamiento de los profesionales. Los profesionales que también son miembros, poseedores de certificación o voluntarios del PMI y que no se comportan de acuerdo con estos estándares serán objeto de procedimientos disciplinarios ante el Comité
de Revisión Ética del PMI.
“tomar decisiones inteligentes” y “valores”
Considero que “tomar decisiones inteligentes” debería cambiarse por “tomar decisiones sabias”.
Inteligencia no es lo mismo que sabiduría. Uno puede ser muy inteligente y hasta ser premiado por algo que hizo en su especialidad. Pero en otro campo de la vida tener problemas. En este sentido la sabiduría no depende de la inteligencia. De ahí que por eso dicen que: “mas sabe el diablo por viejo que por diablo”.
Inteligencia es por ejemplo: estudiar el PMBOK y lograr una certificación del PMI. Así se demuestra tener todos los conocimientos de la Dirección de Proyectos. La sabiduría es saber que conocimiento del PMBOK se debe aplicar en este momento, en cada proyecto en particular. No es hacer “copy page”.
Digo “copy page” porque algunos usamos la información de la base de datos de lecciones aprendidas, copiándolas y pegándolas en nuevos proyectos como si se tratarán de escenarios iguales al que origino la lección aprendida en ese proyecto pasado.
Y respecto de la otra palabra resaltada (valores), solo decir que la finalidad de la sabiduría es ayudar a los valores.
Por eso estoy de acuerdo con lo que recomiendas, en especial en la parte: Involucración en Fase de análisis del PM
Pero recomiendo que para proyectos estratégicos y de costos elevados, el PM tenga los años de experiencia para que enfrente el reto con sabiduría. Yo elogió y felicito a los PM cuando los califican de preguntones o incluso los califican como pesimistas. Y esto sucede mas cuando abordan la gestión de riesgos. Y esto se hace más duro en lugares donde no existe la cultura de evaluar riesgos.
Saludos,
Gracias José por tu extensa y detallada aportación. Saludos!
Me gustaria aportar mi experiencia en particular aportando mi visión de la gestión de requisitos.
Creo que es una parte vital para el exito de un proyecto, no una mera colección de entrevistas.
Hay que centrarse en que el objetivo de la gestión de requisitos es obtener un catalogo de especificaciones como frases cortas (sujeto-verbo-predicado) que el sistema a construir debe cumplir, y bajando de nivel se deben establecer correspondencias individuales de trazabilidad entre los requisitos y las funciones / casos de uso del sistema, que junto con los casos de prueba de cada funcion al combinar ambos niveles de trazabilidad, nos dirá que requisitos valida cada caso de prueba y que requisitos no disponen de suficientes casos de prueba. Ambas trazabilidades se expresan mejor como dos matrices de 0 y 1 (no cumple / cumple) : requisitos x funciones y funciones x casos de prueba, y si HACEMOS el producto de las dos matrices obtenemos la matriz requisitos x casos de prueba, que resulta muy util para saber el nivel de prueba ok del sistema en conjunto.
Otro factor critico es la capacidad, experiencia y conocimiento de negocio de los analistas que hacen la obtención de requisitos para 1.empatizar con el stakeholder que los proporciona, y 2.saber hacer la pregunta «mas allà» aparentemente que descubre aquel caso «que no pasa casi nunca» pero que si no lo contemplamos, p.e. en el modelo logico de datos, nos destrozará todo el desarrollo y provocará costosas regresiones.
Alguien pensará que es problema del cliente no haber suministrado aquel detalle, pero no, es mucho mejor para todos tener ese detalle y que el desarrollo se lleve a cabo sin sorpresas ni discusiones.
Al final, en una metodologia orientada a la REUTILIZACION DE COMPONENTES, transversal a diversas tecnologias y canales de acceso (algo tipico en grandes organizaciones como los bancos), un requisito se ha de tratar como UN COMPONENTE, de igual modo que consideramos un componente un DATA ELEMENT TYPE reusable en toda la organización, o un DATA ELEMENT particular de una entidad de datos.
Si lo hacemos asi, con la ayuda de un METAMODELO de componentes y un repositorio, no tendremos grandes problemas para hacer ANALISIS DE IMPACTO de proyectos de mejora o de las incomodas regresiones de desarrollo.
Gracias Alex por compartir tu experiencia y por la detallada explicación/aportación al artículo. Saludos!