Gestión de proyectos. errores clásicos

Relación de errores clásicos en la gestión de proyectos
 
Relación de errores clásicos para reconocerles como potenciales riesgos. Esta relación de errores se complementa con el ejemplo C mostrado más adelante.
a) Personas
A continuación aparecen algunos de los errores clásicos relacionados con las personas.
1. Motivación débil.
Estudio tras estudio se ha mostrado que la motivaciónprobablemente tiene mayor efecto sobre la productividad y la calidad que ningún otro factor. En el Ejemplo C, los directivos tomaron a lo largo de todo el proyecto medidas que minaban la moral, como dar ánimos a diario al principio para pedir horas extras en la mitad, y como irse de vacaciones mientras el equipo estaba trabajando incluso los días de fiesta, para dar recompensas al final del proyecto queresultaron ser de menos de un dólar por cada hora extra.
2. Personal mediocre.
Después de la motivación, la capacidad individual de los miembros del equipo, así como sus relaciones como equipo, probablemente tienen la mayor influencia en la productividad. Contratar apurando el fondo del barril supondrá una amenaza al esfuerzo del desarrollo rápido. En el ejemplo, la selección del personal se hizobuscando quién podría contratarse más rápido, en vez de quién realizaría la mayoría del trabajo durante la vida del proyecto. Esta técnica consigue un inicio rápido del proyecto, pero no determina un final rápido.
3. Empleados problemáticos incontrolados.
Un fallo al tratar con personal problemático también amenaza la velocidad de desarrollo. En el desarrollo de software por ejemplo, es unproblema habitual, y se ha comprendido bien, al menos desde que Gerald Weinberg publicóPsychology of Computer Programming en 1971. Un fallo al tomar una decisión cuando se trata con un empleado problemático es una de las quejas más comunes que tienen los miembros del equipo respecto de sus responsables. En el Ejemplo C, el equipo sabía que Chip era una manzana podrida, pero el jefe del equipo no hizonada. El resultado era predecible: rehacer el trabajo de Chip.
4. Hazañas.
Algunos desarrolladores de software ponen un gran énfasis en la realización de hazañas en los proyectos. Pero lo que hacen tiene más de malo que de bueno.
En el ejemplo C, los directivos de nivel medio dieron mayores aplausos a actitudes del tipo «ser capaz de» que a los progresos firmes y consistentes y a los informessignificativos de progreso. El resultado fue un modelo de planificación al límite en el que las amenazas de desajuste del plan no se detectaban, ni se conocían o ni se informaban a la cadena de directivos hasta el último minuto. Un pequeño equipo de desarrollo y sus jefes inmediatos toman como rehenes a una compañía entera por no admitir que tienen problemas para cumplir su plan. El énfasis en loscomportamientos heroicos fomenta correr un riesgo extremo, e impide la cooperación entre los múltiples elementos que contribuyen al proceso de desarrollo del proyecto.
Algunos directivos fomentan el comportamiento heroico cuando se concentran con demasiada firmeza en actitudes «ser capaz de». Elevando estas actitudes por encima de informes del estado exactos y a veces pesimistas, los directivosde estos proyectos coartan su capacidad de tomar medidas correctivas. Ni siquiera saben que tienen que emprender acciones correctoras hasta que el daño ya está hecho. Como dijo Tom DeMarco, las actitudes «ser capaz de» convierten pequeños contratiempos en auténticos desastres.
5. Añadir más personal a un proyecto retrasado.
Este es quizás el más clásico de los errores clásicos. Cuando un proyectose alarga, añadir más gente puede quitar más productividad a los miembros del equipo existente de la que añaden los nuevos miembros. En un proyecto informático, Fred Brooks compara esto de añadir gente a un proyecto retrasado con echar gasolina en un fuego.
6. Oficinas repletas y ruidosas.
Buena parte de los proyectistas consideran sus condiciones de trabajo como insatisfactorias. Alrededor...