Control de Proyectos Informáticos José Onofre Montesa Andrés Universidad Politécnica de Valencia Escuela Superior de Informática Aplicada 2003-2004

GPI-P3B. Control de Proyectos Informáticos. El punto de partida... Disponemos de la programación del proyecto. Disponemos de la aplicación de recursos en cada instante. Disponemos de un flujo de caja aceptado y uno coste global Tarea: Especifica Necesidades Recursos: … Duración: 2 semanas Tarea: Diseño Programas Duración: 4 semanas Tarea: Diseño B.D. Tarea: Realización Esquema Duración: 1 semanas Tarea: Codificación Program. Duración: 7 semanas Tarea: Pruebas TAREAS Especificar Necesidades Diseño Programas Diseño Base de Datos Realización Esquema Codificación Programas Pruebas 0 2 4 6 8 10 12 14 16 SEMANAS GPI-P3B. Control de Proyectos Informáticos.

Definición de Seguimiento y Control. Hacer un seguimiento de lo planificado, tomando las medidas oportunas cuando: se produzcan retrasos, costes por encima de lo planificado, o se contravenga algunas condiciones acordadas que fueron base en la decisión de realizar éste proyecto GPI-P3B. Control de Proyectos Informáticos.

Objetivos del seguimiento Determinar si el proyecto esta bajo control Si el proyecto esta fuera de control GPI-P3B. Control de Proyectos Informáticos.

Determinar que el proyecto esta bajo control, Se están alcanzando los hitos del proyecto: A tiempo Con los recursos estimados Con un nivel de calidad Continua siendo aceptable económicamente GPI-P3B. Control de Proyectos Informáticos.

Si el proyecto esta fuera de control, Tan pronto se observen desviaciones hay que: Replanificar Renegociar el plan del proyecto con los clientes GPI-P3B. Control de Proyectos Informáticos.

Definición del Control “Toda actividad de gestión aseguradora de que el trabajo real va de acuerdo al plan: Compara lo realizado con las metas y planes, Revela cuando y donde existen desviaciones, y Pone en marcha acciones correctoras, ayudando a la realización de los planes” (Thayer 1988) GPI-P3B. Control de Proyectos Informáticos.

Definición del Control “Proceso de hacer que las cosas ocurran de forma ordenada o de acuerdo a lo planificado” Reifer GPI-P3B. Control de Proyectos Informáticos.

¿Porqué hace falta el seguimiento y control? Porque al realizar la planificación, hacemos estimaciones de: Tamaño de la aplicación. Tareas necesarias. Recursos para cada tarea. Productividad esperada. Además suele cambiar el objetivo a alcanzar. GPI-P3B. Control de Proyectos Informáticos.

¿Porqué hace falta el seguimiento y control? Es normal que no coincida exactamente lo planificado con la realidad. Los proyectos informáticos no son repeticiones de un conjunto de tareas realizadas previamente. GPI-P3B. Control de Proyectos Informáticos.

Flujo de trabajo en el Seguimiento y Control Inicio del Desarrollo Obtener Información del Avance del Proyecto ¿Fin del Proyecto? NO Replanificar o Corregir Comparar lo Esperado con los datos REALES Planificación Estándares Productividad ¿Satisfactorio? NO SI SI Fin del Desarrollo GPI-P3B. Control de Proyectos Informáticos.

Actividades de control Desarrollar estándares de productividad. Establecer las condiciones o medidas que deben darse cuando las tareas se realizan de forma correcta. Establecer sistemas de monitorización e informes. Determinar que datos son necesarios, quien y cuando los debe recibir. GPI-P3B. Control de Proyectos Informáticos.

Actividades de control Medir los resultados Determinar los niveles de cumplimiento, o alcance de desviaciones, sobre metas y estándares. Iniciar acciones correctivas Reforzar estándares, ajustar metas, o replanificar. GPI-P3B. Control de Proyectos Informáticos.

Actividades de control Recompensar y disciplinar. Elogiar, remunerar, y disciplinar al personal. Documentar los métodos de control. Documentar los estándares, métodos de informar y control, puntos de decisión, planes de primas y recompensas etc... GPI-P3B. Control de Proyectos Informáticos.

Formas de obtener información del proyecto GPI-P3B. Control de Proyectos Informáticos.

Comparar lo ESPERADO y lo REAL Lo esperado se basa en: los compromisos de la planificación y en los estándares de productividad. Puede ser correcto el trabajo desde el punto de vista de estándares y no serlo desde el punto de vista de la planificación. Podemos encontrarnos en una de las siguientes situaciones: GPI-P3B. Control de Proyectos Informáticos.

Comparar lo ESPERADO y lo REAL GPI-P3B. Control de Proyectos Informáticos.

Comparar lo planificado y lo Real: lo planificado Sobre un gráfico de Gantt con lo planificado trazamos una línea quebrada que: comienza y termina en la vertical del día actual. Los vértices de ésta línea se sitúan en la intersección de las tareas no terminadas o las que ya deberían haber comenzado pero que aun no lo han hecho. Estimar el % de las tareas no finalizada para pasar la línea por ese punto. GPI-P3B. Control de Proyectos Informáticos.

Comparar lo planificado y lo Real Hoy MAL BIEN Extraordinario ¿Perfecto? GPI-P3B. Control de Proyectos Informáticos.

Comparar lo planificado y lo Real Hay muchos autores que no están por la labor de que se estime un % de la tarea realizada. Lleva al síndrome del 90% eterno. DeMarco propone un sistema binario. Se ha realizado o no la tarea. En este caso es muy importante que las tareas no tengan una duración excesiva. GPI-P3B. Control de Proyectos Informáticos.

¿Es satisfactoria la situación REAL? Cuando aparecen problemas con respecto al proyecto, la decisión de qué hacer debe ser tomada al nivel jerárquico apropiado. ESTRATEGICO TACTICO OPERATIVO GPI-P3B. Control de Proyectos Informáticos.

¿Es satisfactoria la situación REAL? A nivel OPERATIVO: Los pequeños ajustes, el director del proyecto los deja a los técnicos. A nivel TACTICO: Ajustes del plan de mayor nivel (retraso de una semana, etc.) son tratados por el director del proyecto. A nivel ESTRATEGICO: Grandes retrasos, así como otras incidencias. p.e.: se han fusionado dos empresas y podremos utilizar un sistema similar de la otra. En estos casos las decisiones son más drásticas. GPI-P3B. Control de Proyectos Informáticos.

¿Es satisfactoria la situación REAL? “Los proyectos informáticos no retrasan su entrega en meses de golpe, su retraso se produce de día en día.” GPI-P3B. Control de Proyectos Informáticos.

Replanificar o Corregir La replanificación debe de realizarse para que el calendario se ajuste a la realidad Los desarrolladores se sentirán menos frustrados si ven que los objetivos son alcanzables. Los clientes tendrán más claro que es lo que pueden esperar. GPI-P3B. Control de Proyectos Informáticos.

Replanificar o Corregir Corrección de las desviaciones. En lugar de modificar el plan, lo que haremos es forzar al equipo de desarrollo para que la situación real se aproxime a la planificada. Llamamos crisis de un proyecto al periodo que va desde el que se ha producido una situación seria de desajuste hasta que ésta es reencauzada. GPI-P3B. Control de Proyectos Informáticos.

Crisis en Proyectos Informáticos. Detección del desfase Gestión de la crisis Recuperación tras la crisis GPI-P3B. Control de Proyectos Informáticos.

GPI-P3B. Control de Proyectos Informáticos. Gestión de la crisis Anuncio y publicidad general del problema en el equipo. Reasignación de responsabilidades y autoridad. Actualización de la información de situación. Relajación de las restricciones sobre los recursos. Poner al personal del proyecto a trabajar a tope. Establecer la fecha de finalización de la crisis. GPI-P3B. Control de Proyectos Informáticos.

Recuperación tras la crisis Eliminar al personal innecesario. Realizar un estudio postmorten de la crisis. Replanificar el proyecto tras la crisis (coste pendiente y total). GPI-P3B. Control de Proyectos Informáticos.

Anuncio y publicidad general del problema en el equipo. Cuando se declara la crisis vamos retrasados y hemos intentado corregir el problema. Si la gente se entera de manera informal, pensara que el problema esta controlado. Si no piden ayuda será que no es necesario. Se puede ofender alguien, así que mejor callar. GPI-P3B. Control de Proyectos Informáticos.

Anuncio y publicidad general del problema en el equipo. Lo primero que hay que hacer es comunicar a todos los que están implicados en el proyecto el problema para que ayuden sin reservas y que interioricen la situación. GPI-P3B. Control de Proyectos Informáticos.

Reasignación de responsabilidades y autoridad. Deberá reasignarse recursos, algunas tareas se paralizarán, las personas y recursos que tenían asignados pasen a responsabilizarse de las nuevas tareas, creadas para solucionar el problema. La reestructuración debe ser cuidadosa: aclarando las nuevas responsabilidades, y quién puede tomar decisiones y sobre que. GPI-P3B. Control de Proyectos Informáticos.

Actualización de la información de situación. Planificar reuniones para que los implicados alineen los trabajos hacia la solución. En estos casos es cuando es mas importante la comunicación. Dejar constancia de lo realizado e intentados para no cometer varias veces el mismo error. El trabajo en grupo suele dar soluciones más creativas. GPI-P3B. Control de Proyectos Informáticos.

Relajación de las restricciones sobre los recursos. Es posible que hubieran recursos limitados para el proyecto. Habrá que hacer excepciones: Permitir la utilización de equipos más rápidos de otros proyectos. Aumentar el soporte administrativo para que los desarrolladores se concentren más en lo suyo. Hacer catering... GPI-P3B. Control de Proyectos Informáticos.

Poner al personal del proyecto a trabajar a tope. Hacer que la gente trabaje tantas horas como sea posible en el proyecto (h. extras) Ponerles teléfonos móviles 24 horas al día por si a alguien le hace falta comunicarse con algún compañero. Suprimir reuniones de departamento o empresa, aplazar cursillos, etc. GPI-P3B. Control de Proyectos Informáticos.

Establecer la fecha de finalización de la crisis. Hay que marcar un plazo razonable para que finalice la crisis, 30 días máximo. Si se sobrepasa este limite debería replantearse la viabilidad del proyecto. La gente no puede vivir con un nivel de estrés excesivo, puede ser contraproducente. GPI-P3B. Control de Proyectos Informáticos.

Eliminar al personal innecesario. Una vez finalizada la crisis habrá que devolver los recursos tomados de otros proyectos. El proyecto tiene una planificación que deberá seguir. Los desarrolladores dejaran de tener prioridad en la utilización de los administrativos. GPI-P3B. Control de Proyectos Informáticos.

Realizar un estudio postmorten de la crisis. Examinar que es lo que fue mal. Identificar problemas sistemáticos que podrían evitarse. Documentar lo aprendido. GPI-P3B. Control de Proyectos Informáticos.

Replanificar el proyecto tras la crisis (coste pendiente y total). Como ha afectado la crisis al presupuesto del proyecto. GPI-P3B. Control de Proyectos Informáticos.

GPI-P3B. Control de Proyectos Informáticos. Tipos de seguimiento Proceso Hitos (Momentos clave del proyecto) Tareas: Comienzo, Fin, Recursos. Productos Entregables Calidad (Conformidad del cliente) Estas dos visiones no son independientes. (se suele planificar con ambos en mente) GPI-P3B. Control de Proyectos Informáticos.

Estudio postmorten de los proyectos. Todos los proyectos tienen problemas. La idea es documentar, analizar y aprender de las cosas que han ido mal. Documenta aquellas cosas que podrás hacer de forma diferente en el futuro. GPI-P3B. Control de Proyectos Informáticos.

GPI-P3B. Control de Proyectos Informáticos. Estudio postmorten. Hay que reservar tiempo para que todos los miembros del equipo puedan reflexionar sobre: las desviaciones, los problemas, y las soluciones tomadas. GPI-P3B. Control de Proyectos Informáticos.

Estudio postmorten: ejemplos. “Cuando llevábamos 10 días de retraso en las pruebas deberíamos haberselo comunicado al cliente” “Empezamos el diseño demasiado pronto, antes de tener claras las especificaciones” “Se desmotivo al personal al decir que no habrían subidas, justo en aquel momento.” GPI-P3B. Control de Proyectos Informáticos.

GPI-P3B. Control de Proyectos Informáticos. Bibliografía Davis, A.M., 201 Principles of software development. McGraw-Hill 1995 Fairley, R., Risk Management for software projects, IEEE Software Mayo 1994. Cotterell, M y Hughes, B. Software Project Management. International Thomson, 1995. Thayer, R.H., Tutorial: Software Engineering Project Mangement. IEEE Computer Press. 1988 GPI-P3B. Control de Proyectos Informáticos.