Control de Proyectos Informticos Jos Onofre Montesa Andrs
- Slides: 43
Control de Proyectos Informáticos José Onofre Montesa Andrés Universidad Politécnica de Valencia Escuela Superior de Informática Aplicada 2003 -2004 GPI-P 3 B. 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: Diseño Programas Tarea: Codificación Program. Recursos: … Duración: 4 semanas Duración: 7 semanas Tarea: Especifica Necesidades Tarea: Pruebas Recursos: … Duración: 2 semanas Tarea: Realización Esquema Tarea: Diseño B. D. Recursos: … Duración: 2 semanas Duración: 1 semanas TAREAS Especificar Necesidades Diseño Programas Diseño Base de Datos Realización Esquema Codificación Programas Pruebas 0 GPI-P 3 B. Control de Proyectos Informáticos. 2 4 6 8 10 12 14 16 SEMANAS 1
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-P 3 B. Control de Proyectos Informáticos. 2
Objetivos del seguimiento – Determinar si el proyecto esta bajo control – Si el proyecto esta fuera de control GPI-P 3 B. Control de Proyectos Informáticos. 3
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-P 3 B. Control de Proyectos Informáticos. 4
Si el proyecto esta fuera de control, • Tan pronto se observen desviaciones hay que: – Replanificar – Renegociar el plan del proyecto con los clientes GPI-P 3 B. Control de Proyectos Informáticos. 5
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-P 3 B. Control de Proyectos Informáticos. 6
Definición del Control “Proceso de hacer que las cosas ocurran de forma ordenada o de acuerdo a lo planificado” Reifer GPI-P 3 B. Control de Proyectos Informáticos. 7
¿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-P 3 B. Control de Proyectos Informáticos. 8
¿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-P 3 B. Control de Proyectos Informáticos. 9
Flujo de trabajo en el Seguimiento y Control Inicio del Desarrollo Obtener Información del Avance del Proyecto Planificación Estándares Productividad Replanificar o Corregir Comparar lo Esperado con los datos REALES ¿Satisfactorio? NO SI ¿Fin del Proyecto? SI NO Fin del Desarrollo GPI-P 3 B. Control de Proyectos Informáticos. 10
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-P 3 B. Control de Proyectos Informáticos. 11
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-P 3 B. Control de Proyectos Informáticos. 12
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-P 3 B. Control de Proyectos Informáticos. 13
Formas de obtener información del proyecto GPI-P 3 B. Control de Proyectos Informáticos. 14
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-P 3 B. Control de Proyectos Informáticos. 15
Comparar lo ESPERADO y lo REAL GPI-P 3 B. Control de Proyectos Informáticos. 16
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-P 3 B. Control de Proyectos Informáticos. 17
ar or di n ? ra rf ec to N Ex t GPI-P 3 B. Control de Proyectos Informáticos. ¿P e BI E Hoy M AL io Comparar lo planificado y lo Real 18
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. • De. Marco 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-P 3 B. Control de Proyectos Informáticos. 19
¿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-P 3 B. Control de Proyectos Informáticos. 20
¿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-P 3 B. Control de Proyectos Informáticos. 21
¿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-P 3 B. Control de Proyectos Informáticos. 22
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-P 3 B. Control de Proyectos Informáticos. 23
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-P 3 B. Control de Proyectos Informáticos. 24
Crisis en Proyectos Informáticos. • Detección del desfase • Gestión de la crisis • Recuperación tras la crisis GPI-P 3 B. Control de Proyectos Informáticos. 25
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-P 3 B. Control de Proyectos Informáticos. 26
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-P 3 B. Control de Proyectos Informáticos. 27
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-P 3 B. Control de Proyectos Informáticos. 28
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-P 3 B. Control de Proyectos Informáticos. 29
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-P 3 B. Control de Proyectos Informáticos. 30
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-P 3 B. Control de Proyectos Informáticos. 31
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-P 3 B. Control de Proyectos Informáticos. 32
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-P 3 B. Control de Proyectos Informáticos. 33
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-P 3 B. Control de Proyectos Informáticos. 34
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-P 3 B. Control de Proyectos Informáticos. 35
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-P 3 B. Control de Proyectos Informáticos. 36
Replanificar el proyecto tras la crisis (coste pendiente y total). • Como ha afectado la crisis al presupuesto del proyecto. GPI-P 3 B. Control de Proyectos Informáticos. 37
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-P 3 B. Control de Proyectos Informáticos. 38
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-P 3 B. Control de Proyectos Informáticos. 39
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-P 3 B. Control de Proyectos Informáticos. 40
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-P 3 B. Control de Proyectos Informáticos. 41
Bibliografía – Davis, A. M. , 201 Principles of software development. Mc. Graw-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-P 3 B. Control de Proyectos Informáticos. 42
- Tiempo en montesa
- Eric onofre
- Andrs bello
- Wendy onofre
- Andrs mint
- Aprendizaje basado en proyectos ventajas y desventajas
- Proyectos de produccion artesanal
- Metodo de proyectos
- Matriz del marco logico ejemplos
- Formulacion de proyectos
- Proyectos para escuelas de jornada extendida
- Estudio tecnico evaluacion de proyectos
- Ejemplos de perfil de proyectos
- Gestiona proyectos de emprendimiento
- Aprendizaje basado por proyectos
- Disposicion 30/05 proyectos de catedra
- Títulos de proyectos de servicio comunitario ejemplos
- Metas a corto plazo proyecto de nacion ejemplos
- Quien soy yo proyecto de vida
- Aprendizaje basado en proyectos ejemplos
- Banco de programas y proyectos
- Qué proyectos y talleres podemos crear asc
- Tipos de proyectos integradores
- Di lo que haces haz lo que dices y demuéstralo
- Factores externos en un proyecto
- Evaluacion de proyectos
- Cmo proyectos
- Proyectos de solidaridad en la escuela
- Porque fracasan los proyectos
- Ser hispano
- Instituto tolomei
- Proyectos practicos
- Proyectos interdisciplinarios
- Planeación de proyectos de ingeniería web
- Objetivos de proyectos sociales
- Vae valor actual de
- Proyectos interdisciplinarios
- Planificacion de proyectos
- Proyectos visuales
- Conclusiones para un proyecto ejemplos
- Proyectos productivos en los crfa
- Factibilidad de un proyecto
- Modelo de un proyecto de vida
- Evaluación financiera de proyectos