Agujeros negros en los presupuestos de proyectos TI
Los 10 errores mas frecuentes
Posiblemente si los directores de proyecto supieran cuáles son los lugares de uso excesivo de dinero más importantes, las estadísticas mejorarían. Teniendo esto en cuenta, hemos hablado con directores de proyecto experimentados y otros expertos para conocer dónde están los “agujeros negros” de la gestión de proyectos y cómo evitarlos.
1. PROBLEMAS DE ALCANCE. Estos pueden comenzar pronto, en la etapa de definición de los requerimientos. “La gente dice, ´Estamos gastando el tiempo y el dinero de todas formas, así que vamos a hacer esto y aquello". De esa forma se amplía el alcance o extensión del proyecto mucho más allá de lo que puede conseguirse o se necesita realmente.
Incluso los proyectos bien planificados aumentan en hasta un 2% por sí solos cada mes a lo largo de la duración de un proyecto. Uno de los motivos es el “embellecimiento técnico,” según explica un consultor TIC. “Es cuando los programadores bien intencionados añaden características y funcionalidades que no han sido especificadas pero que resultan atractivas o novedosas, y esto reduce la productividad e introduce dificultades en los tests.”
Solución: Mantener la productividad básica definiendo los requerimientos como “obligatorios”, “convenientes” e “interesantes”. Para mantener bajo control a los desarrolladores de aplicaciones se aconseja especificar rigurosamente los requerimientos obligatorios y hacer un seguimiento de los mismos durante el proceso de desarrollo. Esto es más difícil para los directores de proyecto que proceden del área comercial de la empresa y no comprenden las complejidades técnicas. Para estos directores es conveniente obtener la ayuda de una persona capacitada y creible del área TI. También se sugiere reducir las expectativas del usuario ofreciendo algo de corto alcance que sea posible ampliar más adelante.
2. CREAR UN INTERFACE GUI DEMASIADO SOFISTICADO AL COMIENZO DEL PROYECTO. La mayoría de los interfaces gráficos de usuario cambian extraordinariamente entre la etapa de definición de requerimientos y la entrega final del proyecto, y, sin embargo los desarrolladores sienten siempre la tentación de perfeccionar el interface GUI en forma electrónica en las primeras etapas del proyecto.
Solución: Comenzar con interfaces GUI low-tech. En este punto se debería representar el interface de usuario con un prototipo de papel, utilizando rotuladores de colores y pegatinas de papel amarillas, o mediante un programa software de dibujo, como Photoshop. Si se comienza con una representación electrónica del GUI, los costes se incrementarían extraordinariamente.
3. FALTA DE CAPACIDADES DE NEGOCIACIÓN. Pocos directores de proyecto reciben educación formal sobre cómo negociar los mejores precios para software o contratar personal.
Solución: Desarrollar conocimientos y capacidades básicas. Las capacidades de negociación son también capacidades de comunicación. Por ejemplo, después de que se ha presentado una oferta no hay que decir ni una palabra. En lugar de eso, es mejor contar números o recitar (en silencio) los nombres de personas a las que uno conoce. La mayoría de la gente no puede hacer frente a ésto. En este mismo contexto sería positivo que los directores de proyectos TIC pasen también una semana en el departamento de aprovisionamiento para ver cómo se realizan las negociaciones. Por ejemplo, comprar software en el último minuto puede resultar entre tres y cinco veces más caro que adquirirlo por adelantado.
4. NO COMPRENDER EL LADO FINANCIERO DEL PROYECTO, QUE ES DIFERENTE DE LA CONTABILIDAD DEL PROYECTO. La gente sencillamente no comprende lo que significa el dinero, como por ejemplo, que si se dota de más dinero a un proyecto, otro proyecto no podrá realizarse.
Solución: Un curso abreviado de terminología y conceptos financieros. En particular en el caso de proyectos complejos que duran más de seis meses, se aconseja a los directores de proyecto informarse a sí mismos y a sus equipos sobre conceptos como la “tasa interna de rendimiento” y el “valor neto actual”. No se intenta convertir a la gente en expertos, pero deben tener suficiente conocimiento para comprender tanto el problema como la solución.
5. IMPLEMENTAR PROYECTOS GRANDES Y ESPECTACULARES. Las investigaciones muestran que la productividad por persona disminuye al aumentar el tamaño del proyecto. Esfuerzo de comunicación adicional, requerimientos más formales, un diseño más detallado y el aumento del número de reuniones, son factores que aumentan el gasto. En los proyectos pequeños el tiempo empleado en implementar un proyecto es un 60% del total, frente a entre un 8% y un 10% en los proyectos muy grandes. El resto del tiempo se emplea en coordinar, comunicar y realizar tests adicionales.
Solución: Fraccionar los proyectos en partes más pequeñas y más manejables. Diversos estudios han mostrado que existe una correlación entre altos porcentajes de fracaso y proyectos grandes, y además los proyectos pequeños son más económicos.
6. EXCESO DE TESTS. Todo el mundo ha oido hablar de “parálisis por análisis”. A lo que habría que añadir el fenómeno conocido como “parálisis por exceso de tests”. Posiblemente porque se ha tenido una mala experiencia en el pasado con fallos que aparecen en el último momento, se mantiene uno realizando tests y más tests. O los desarrolladores podrían estar jugando con diversos tipos de letra para impresionar a los usuarios. El resultado: plazos rebasados y pérdida de recursos.
Solución: Hay que aceptarlo: va a haber fallos. En algún punto, habrá que decir basta. Hay que decirle al usuario que habrá fallos y que el equipo los resolverá. Es mejor buscar una perfección de 80% que del 100%.
7. TAREAS DUPLICADAS O SUPERPUESTAS. En particular en las compañías grandes y dispersas, sin departamento TI central, podría ignorarse que fuera posible obtener ideas o quizá incluso un sistema de otro grupo que ya se ha enfrentado al mismo reto que se enfrenta uno.
Solución: Una biblioteca de proyectos en la que sea posible buscar.
8. ESTIMACIÓN DEFICIENTE. Si no se comprenden bien al principio los costes y los plazos del proyecto, cuando surjan los problemas será quizás demasiado tarde para reasignar recursos TI de manera efectiva,. El peor escenario posible es cuando un director comprende a mitad de camino que el proyecto está retrasado, y asigna más desarrolladores o responsables de tests al trabajo. Estos colaboradores de última hora no comprenden el problema ni cómo funciona la aplicación, así que no pueden adquirir velocidad rápidamente. Se trata de una pérdida totalmente inútil de dinero.
Solución: Eliminar las pérdidas y, la próxima vez, utilizar una herramienta de estimación. Lo mejor que puede hacerse cuando se comprende que no se han estimado bien los recursos es calcular los requerimientos mínimos para terminar el proyecto actual y comenzar inmediatamente a planificar otro proyecto en el que pueda utilizarse el dinero de manera más efectiva. También sería posiitivo realizar una estimación de las herramientas como medio de predecir los costes y los plazos.
9. FALTA DE DATOS DE COSTE-DESARROLLO Y DE TIEMPOS. Con demasiada frecuencia, los miembros del equipo desconocen t
1. PROBLEMAS DE ALCANCE. Estos pueden comenzar pronto, en la etapa de definición de los requerimientos. “La gente dice, ´Estamos gastando el tiempo y el dinero de todas formas, así que vamos a hacer esto y aquello". De esa forma se amplía el alcance o extensión del proyecto mucho más allá de lo que puede conseguirse o se necesita realmente.
Incluso los proyectos bien planificados aumentan en hasta un 2% por sí solos cada mes a lo largo de la duración de un proyecto. Uno de los motivos es el “embellecimiento técnico,” según explica un consultor TIC. “Es cuando los programadores bien intencionados añaden características y funcionalidades que no han sido especificadas pero que resultan atractivas o novedosas, y esto reduce la productividad e introduce dificultades en los tests.”
Solución: Mantener la productividad básica definiendo los requerimientos como “obligatorios”, “convenientes” e “interesantes”. Para mantener bajo control a los desarrolladores de aplicaciones se aconseja especificar rigurosamente los requerimientos obligatorios y hacer un seguimiento de los mismos durante el proceso de desarrollo. Esto es más difícil para los directores de proyecto que proceden del área comercial de la empresa y no comprenden las complejidades técnicas. Para estos directores es conveniente obtener la ayuda de una persona capacitada y creible del área TI. También se sugiere reducir las expectativas del usuario ofreciendo algo de corto alcance que sea posible ampliar más adelante.
2. CREAR UN INTERFACE GUI DEMASIADO SOFISTICADO AL COMIENZO DEL PROYECTO. La mayoría de los interfaces gráficos de usuario cambian extraordinariamente entre la etapa de definición de requerimientos y la entrega final del proyecto, y, sin embargo los desarrolladores sienten siempre la tentación de perfeccionar el interface GUI en forma electrónica en las primeras etapas del proyecto.
Solución: Comenzar con interfaces GUI low-tech. En este punto se debería representar el interface de usuario con un prototipo de papel, utilizando rotuladores de colores y pegatinas de papel amarillas, o mediante un programa software de dibujo, como Photoshop. Si se comienza con una representación electrónica del GUI, los costes se incrementarían extraordinariamente.
3. FALTA DE CAPACIDADES DE NEGOCIACIÓN. Pocos directores de proyecto reciben educación formal sobre cómo negociar los mejores precios para software o contratar personal.
Solución: Desarrollar conocimientos y capacidades básicas. Las capacidades de negociación son también capacidades de comunicación. Por ejemplo, después de que se ha presentado una oferta no hay que decir ni una palabra. En lugar de eso, es mejor contar números o recitar (en silencio) los nombres de personas a las que uno conoce. La mayoría de la gente no puede hacer frente a ésto. En este mismo contexto sería positivo que los directores de proyectos TIC pasen también una semana en el departamento de aprovisionamiento para ver cómo se realizan las negociaciones. Por ejemplo, comprar software en el último minuto puede resultar entre tres y cinco veces más caro que adquirirlo por adelantado.
4. NO COMPRENDER EL LADO FINANCIERO DEL PROYECTO, QUE ES DIFERENTE DE LA CONTABILIDAD DEL PROYECTO. La gente sencillamente no comprende lo que significa el dinero, como por ejemplo, que si se dota de más dinero a un proyecto, otro proyecto no podrá realizarse.
Solución: Un curso abreviado de terminología y conceptos financieros. En particular en el caso de proyectos complejos que duran más de seis meses, se aconseja a los directores de proyecto informarse a sí mismos y a sus equipos sobre conceptos como la “tasa interna de rendimiento” y el “valor neto actual”. No se intenta convertir a la gente en expertos, pero deben tener suficiente conocimiento para comprender tanto el problema como la solución.
5. IMPLEMENTAR PROYECTOS GRANDES Y ESPECTACULARES. Las investigaciones muestran que la productividad por persona disminuye al aumentar el tamaño del proyecto. Esfuerzo de comunicación adicional, requerimientos más formales, un diseño más detallado y el aumento del número de reuniones, son factores que aumentan el gasto. En los proyectos pequeños el tiempo empleado en implementar un proyecto es un 60% del total, frente a entre un 8% y un 10% en los proyectos muy grandes. El resto del tiempo se emplea en coordinar, comunicar y realizar tests adicionales.
Solución: Fraccionar los proyectos en partes más pequeñas y más manejables. Diversos estudios han mostrado que existe una correlación entre altos porcentajes de fracaso y proyectos grandes, y además los proyectos pequeños son más económicos.
6. EXCESO DE TESTS. Todo el mundo ha oido hablar de “parálisis por análisis”. A lo que habría que añadir el fenómeno conocido como “parálisis por exceso de tests”. Posiblemente porque se ha tenido una mala experiencia en el pasado con fallos que aparecen en el último momento, se mantiene uno realizando tests y más tests. O los desarrolladores podrían estar jugando con diversos tipos de letra para impresionar a los usuarios. El resultado: plazos rebasados y pérdida de recursos.
Solución: Hay que aceptarlo: va a haber fallos. En algún punto, habrá que decir basta. Hay que decirle al usuario que habrá fallos y que el equipo los resolverá. Es mejor buscar una perfección de 80% que del 100%.
7. TAREAS DUPLICADAS O SUPERPUESTAS. En particular en las compañías grandes y dispersas, sin departamento TI central, podría ignorarse que fuera posible obtener ideas o quizá incluso un sistema de otro grupo que ya se ha enfrentado al mismo reto que se enfrenta uno.
Solución: Una biblioteca de proyectos en la que sea posible buscar.
8. ESTIMACIÓN DEFICIENTE. Si no se comprenden bien al principio los costes y los plazos del proyecto, cuando surjan los problemas será quizás demasiado tarde para reasignar recursos TI de manera efectiva,. El peor escenario posible es cuando un director comprende a mitad de camino que el proyecto está retrasado, y asigna más desarrolladores o responsables de tests al trabajo. Estos colaboradores de última hora no comprenden el problema ni cómo funciona la aplicación, así que no pueden adquirir velocidad rápidamente. Se trata de una pérdida totalmente inútil de dinero.
Solución: Eliminar las pérdidas y, la próxima vez, utilizar una herramienta de estimación. Lo mejor que puede hacerse cuando se comprende que no se han estimado bien los recursos es calcular los requerimientos mínimos para terminar el proyecto actual y comenzar inmediatamente a planificar otro proyecto en el que pueda utilizarse el dinero de manera más efectiva. También sería posiitivo realizar una estimación de las herramientas como medio de predecir los costes y los plazos.
9. FALTA DE DATOS DE COSTE-DESARROLLO Y DE TIEMPOS. Con demasiada frecuencia, los miembros del equipo desconocen t
