Gestión de expectativas (I de II)

Llevo mucho tiempo pensando en escribir acerca de este tema que, dentro de todos los aspectos que la gestión de un proyecto debe cubrir, sea quizá en el que menos empeño se pone y en el que más se debería poner.

introducción

Aunque la gestión de expectativas es aplicable a cualquier tipo proyecto, se hace más difícil cuanto mayor sea el desconocimiento acerca de la tecnología a emplear para acometerlo o de las posibilidades de la misma. Todos podemos llegar a conocer el posible alcance del proyecto de construcción de una vivienda, incluso cuando se trata de complejos proyectos de ingeniería, éstos son siempre supervisados por personal cualificado nombrado al efecto. Pero en los proyectos tecnológicos muchas veces su supervisión es realizada por perfiles que muchas veces tienen una visión limitada de la profundidad que pueden alcanzar los mismos. Y es que, en tecnología, todos somos “expertos” y no necesitamos a nadie que supervise lo que nosotros podemos hacer (primer error)

preventa

En la preventa del proyecto, nadie se para a pensar en formar al cliente o en sugerirle asesoramiento especializado (cualquier sospecha de que quizá no vaya a poder gestionar el proyecto personalmente o que gestionarlo “desde la barrera” vaya a suponerle un coste adicional ¡podría dar al traste con la operación!) Es cuando quien hace la preventa y más si no es quien luego va a gestionar el proyecto o la postventa se plantea el dilema  de seguir adelante por lograr la venta o adviertir al cliente acerca de los seguros problemas que acarreará el desconocimiento de la tecnología. También es el cliente a veces, el que cuando se pone de manifiesto cualquier tipo de desconocimiento, no duda en reconocerlo y en ponerse en las manos de quien se lo va a desarrollar pues son los que “saben de esto” (segundo error)

definición

La toma de requisitos es otro de los orígenes de los problemas en la gestión de expectativas. Una deficiente especificación e identificación de los requisitos y necesidades reales del proyecto y, por qué no, del presupuesto disponible, suelen ser factores determinantes para que las expectativas generadas sean erróneas o difíciles de mantener en el futuro. Dejar que el proyecto avance inexorablemente hacia un muy posible punto de bloqueo y/o ir sorteando los problemas e imprevistos de forma improvisada no siempre funcionará y muchas veces nos obligará a deshacer y repensar algún planteamiento o implementación, robándole tiempo al proyecto (en realidad, a nuestro tiempo libre al final del mismo por “no llegar”) (tercer error)

re-mate

En la recta final del proyecto poco se puede hacer por arreglar los errores anteriores, lo que sí es fácil es caer en los que re-matarán el proyecto (sí, re-matarán y no rematarán). La fecha de entrega se acerca y el proyecto no tiene visos de terminar bien.  El cliente comienza a impacientarse por ver algún resultado o lo que ha visto no ha cumplido con lo que esperaba. La tensión aumenta y llega el momento de las descalificaciones, decepciones, etc. Se tratan de justificar las deficiencias en el resultado argumentando que se ajustó a las necesidades y requerimientos recogidos, que éstos, además, se modificaron durante el desarrollo (cuarto error). Sólo quedan ganas para poner los últimos parches y terminar un proyecto que no ha traído más que problemas. (quinto error)

fue bonito mientras duró

Llegados a este punto es difícil recuperar la confianza con el cliente y, de requerir un mantenimiento o de haberse comprometido a dar un soporte adicional durante los primeros meses de funcionamiento, todos los errores anteriores pasarán factura (¡y de qué manera!) La predisposición del cliente siempre será la desconfianza en toda tarea o ajuste y tenderá a remitir como incidencias deficiencias en el desarrollo y no fallos reales. Si se hace caso al cliente en ese sentido por un sentimiento de remordimiento profesional completamos el último de los errores (sexto error)

Quien haya sufrido (en uno u otro lado) los errores anteriores entenderá el porqué de la música que acompaña este post.

Message in a bottle, de The Police

1 comment so far ↓

#1 Gestión de expectativas (II de II) — selfbite on 05.24.11 at 19:33

[...] la primera parte de este post señalaba los errores más comunes en el desarrollo de un proyecto tecnológico [...]

Leave a Comment

Security Code: