archivo

Archivos diarios: enero 3, 2013

Llegado a un punto el esfuerzo necesario para mejorar el control que se tiene de un proyecto crece exponencialmente. Esto es así porque hay todo un universo de detalles dentro y fuera del proyecto que inciden en él.

El deseo de control lleva a la microgestión y ésta a su vez a una pérdida importante de la capacidad de autogestión del equipo, ya que todos los pasos se miden milimétricamente.

Otra consecuencia es que se tienden a centralizar muchas tareas, para ser ejecutadas directamente o, al menos, supervisadas por quien controla. Al ser la capacidad de trabajo mayor que la que puede asumir esa persona, su deseo de control se termina convirtiendo en un problema ya que se convierte en un cuello de botella y, además, su tasa de fallos se incrementa.

Las consecuencias de lo anterior son las siguientes:

– Falta de flexibilidad a la hora de adaptarse al cambio provocado por la pérdida de autonomía (llevado a un extremo, sus colaboradores dejarán de tomar decisiones incluso en aspectos de poca importancia, ante el temor de la reacción que pueda tener el controlador o por el escaso interés que muestra por opiniones de terceros), los cuellos de botella y por las normas estrictas de control que se han establecido.

– El equipo de proyecto al reducirse su margen de toma de decisiones, pierde implicación en el proyecto.

– Coste adicional en tareas, hitos o entregables relacionados con el control del proyecto y que no aportan un valor real al mismo.

La mayoría de nosotros ha caído en mayor o menor medida en este antipatrón, empujado generalmente por la presión externa y por el deseo de sacar adelante el proyecto. Es cierto que hay proyectos y equipos que requieren una gran implicación pero eso no debe confundirse con un control que sea nocivo para el proyecto.

Saber cuál es el punto exacto de control que requiere un proyecto no es fácil, porque en cada uno es diferente y es más que posible que a lo largo del proceso de desarrollo, cambie, incluso más de una vez. Una vez más, la experiencia te permitirá equivocarte menos (si es que has aprendido de los errores anteriores).

En el transcurso de un proyecto de desarrollo de software se van generando resistencias que pueden ser de distinta naturaleza: técnicas (deuda técnica, desviaciones funcionales, derivadas de la tecnología y/o arquitectura a utilizar…), relacionadas con el contexto (requisitos cambiantes, falta de estabilidad en el equipo de desarrollo o el área usuaria…), relacionadas con las personas (conflictos entre individuos, entre personas, con la organización, baja motivación, baja productividad…), relacionadas con la gestión (saturación de trabajo por parte de componentes del equipo, mala selección de prioridades, mala gestión del equipo, del proyecto, de las expectativas…), etc…

A todo lo anterior habría que sumar resistencias que pueden existir desde la etapa de estimación del proyecto cuando los errores en los costes (sobre todo) y en los plazos pueden poner de entrada muy cuesta arriba los objetivos marcados en cuanto a alcance y calidad (que ya de por sí es complicado debido a la dificultad de encuadrar el cumplimiento de la agenda y la ganancia de valor del producto).

A mayor resistencia más dificultad, a mayor resistencia más dificultad para eliminar resistencia, a más resistencia menos atención podremos dedicar a las tareas de desarrollo.

Nos encontramos con generadores de resistencias cuando en el proyecto participan personas que, sin estar en el día a día del mismo, tienen poder de influencia o decisión, de manera que en lugar de intentar mostrar su apoyo para reducir resistencias, dejan a un lado la situación en la que se encuentran los trabajos y tratan de imponer criterios que no hacen más que abrir nuevos frentes o desviar esfuerzo y atención en tareas que no son necesarias o prioritarias en este momento.

Los generadores de resistencias son recurrentes, lo seguirán haciendo en este proyecto y en cualquier otro proyecto en los que tengan influencia.

¿Cómo podemos contrarrestarlo? Como va a ser muy complicado esquivarlos mi recomendación es hacer justamente lo contrario, hacerlos más partícipes en el proyecto, dándoles más información e intentando que vean tanto los aspectos positivos como los negativos desde más cerca. De esta forma el proyecto será más suyo, se atenuará el deseo de estar poniendo su impronta cada vez que tienen ocasión, son más conscientes de los problemas y se sentirán más respetados.