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

Control de Proyectos

Informáticos José Onofre Montesa AndrésUniversidad Politécnica de

ValenciaEscuela Superior de Informática Aplicada

2003-2004

GPI-P3B. Control de Proyectos Informáticos. 2

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

Recursos: …


Tarea: Diseño B.D.

Recursos: …


Tarea: Realización Esquema

Recursos: …


Tarea: Codificación Program.

Recursos: …


Tarea: Pruebas

Recursos: …


6

543

21

1 2 3 4 5 6 7 8 9 1 0

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 16SEMANAS


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


Objetivos del seguimiento

– Determinar si el proyecto esta bajo control

– Si el proyecto esta fuera de control


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


Si el proyecto esta fuera de control,

• Tan pronto se observen desviaciones hay que:– Replanificar– Renegociar el plan

del proyecto con los clientes


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)


Definición del Control

“Proceso de hacer que las cosas ocurran

de forma ordenada o de acuerdo a lo planificado”

Reifer


¿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.


¿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.


Inicio del Desarrollo

Obtener Información del Avance del Proyecto

Comparar lo Esperado con los datos REALES

Fin del Desarrollo

Replanificar o Corregir

¿Satisfactorio? NO

SI

SI

¿Fin del Proyecto?

NO

Planificación

Estándares Productividad

Flujo de trabajo en el Seguimiento y Control


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.



• 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.



• 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...


Formas de obtener información del proyecto

Tipo de I nforme

Ejemplo Comentarios

Formal, Oral, regular

Reunión Semanal Notas de la reunión

Formal, Oral, Ad-hoc

Final de Etapa

Formal, Escrito, regular

I nf orme Semanal

Formal, Escrito, Ad-hoc

I nf orme de Excepción

I nf ormal, Oral, Ad-hoc

Discusión en el bar Radio macuto

I nf ormación sobre problemas f uturos


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:


Cumple lo Planificado

Cumple el Estándar

Acción

SI SI Todo va bien

SI NO Estudiar la desviación del estándar y ajustarlo si es necesario, disciplinar

NO SI Replanificar y estudiar la situación para crear medidas correctivas

NO NO Estudiar con cuidado. Aplicar las dos medidas anteriores.

Comparar lo ESPERADO y lo REAL


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. 19M

AL

BIEN

¿Per

fect

o

? Extr

aord

inar

i

o

Hoy

Comparar lo planificado y lo Real


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.


¿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.

OPERATIVO

TACTICO

ESTRATEGICO



• 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.



• “Los proyectos informáticos no retrasan su entrega en meses de golpe, su retraso se produce de día en día.”



• 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.



• 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.


Crisis en Proyectos Informáticos.

• Detección del desfase

• Gestión de la crisis• Recuperación tras

la crisis


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.


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).


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.


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.


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.


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.


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...


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.


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.


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.


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.


Gasto acumulado

05

1015

2025

0 1 2 3 4 5 6 7 8 9

Revisión

Real

Planificado

Replanificar el proyecto tras la crisis (coste pendiente y total).• Como ha afectado la crisis al

presupuesto del proyecto.


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)


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.


Estudio postmorten.

• Hay que reservar tiempo para que todos los miembros del equipo puedan reflexionar sobre:– las desviaciones,– los problemas, y– las soluciones tomadas.


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.”


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

Documents

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