seguimiento y control de proyectos

1. Seguimiento y Control
de un Proyecto de TI
Ing. Juan Carlos Núñez Ugalde

2. Definición de Seguimiento y
Control.
• Es importante el seguimiento de lo
planificado en un proyecto, tomando las
medidas oportunas cuando:
• Se produzcan retrasos.
• Los costos van por encima de lo
planificado.
• Que algunas condiciones acordadas que
fueron base en la decisión de realizar
éste proyecto no se cumplan.
1

3. Objetivos del seguimiento
• Determinar si el proyecto esta bajo
control.
• Un ejemplo de ello que los hitos no se
cumplan.
2

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

5. Si el proyecto esta fuera de control,
• Tan pronto se observen desviaciones hay
que:
• Replanificar
• Renegociar el plan
del proyecto con los
clientes
4

6. Definición del Control
“Proceso de hacer
que las cosas
ocurran de forma
ordenada o de
acuerdo a lo
planificado”
Reifer
5

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.
• Tiempo en que se va a realizar.
• Sin perder de vista el objetivo que se quiere
alcanzar. 6

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

9. Como realizar el seguimiento de la
Calendarización realizado:
 Reuniones para valorar estado del
proyecto.
 Evaluación de resultados de cada una de
las actividades expresadas en Hitos
(entregables).
 Comparar fechas: tentativa-real inicio tarea
usando tabla de tareas.

10. Ejemplo de Tabla de Actividades
Act
ivid
ad
Descripción Tie
mpo
Esta
precedida
de
Entregable
A Análisis de requerimientos con el
o los usuarios de la página WEB
1 _______ Listado de requerimientos
B Diseño en papel 1 A Diseños en papel
C Desarrollo de prototipo para dar
a conocer avances al cliente
5 A,B Diseños para propuesta al
usuario
D Mostrar al cliente el prototipo 2 C Prototipo
E Corrección de errores y/o
peticiones del cliente
1 D Correcciones que se van a
realizar a la pagina WEB
F Mejoramiento pagina web (foros,
datos, visitas, publicidad)
2 E Mejoras en la página WEB
G Reunión final con el cliente para
la aceptación
1 F
H Elaboración de manual de
operación
2 G Manual de Calidad
I Entrega pagina web 1 F, G Carta de aceptación del
proyecto
9

11. Flujo de trabajo en el Seguimiento y
Control
10
Planificación
Inicio del Desarrollo
Obtener Información del
Avance del Proyecto
Comparar lo Esperado
con los datos REALES
¿Satisfactorio?
Fin del Desarrollo
¿Fin del
Proyecto?
Replanificar o
Corregir
NO
SI
SI
NO

12. Descripción de las 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.
11

13. Descripción de las 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.
12

14. Descripción de las 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...
13

15. Formas de obtener información
del proyecto
Tipo de Informe Ejemplo Comentarios
Formal, Oral, regular Reunión Semanal Notas de la reunión
Formal, Oral, Ad-hoc Final de Etapa
Formal, Escrito, regular Informe Semanal
Formal, Escrito, Ad-hoc Informe de Excepción
Informal, Oral, Ad-hoc Discusión en el Bar
Radio macuto
Información sobre
problemas futuros
TEMA 10
Seguimiento y Control de Proyectos 14

16. Comparar lo ESPERADO y lo
REAL
• Lo esperado se basa en:
• los estándares de productividad, y
• en los compromisos de la planificación.
• 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:
15

17. Comparar lo ESPERADO y lo
REAL
TEMA 10
Seguimiento y Control de Proyectos 16
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.

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

19. Comparar lo planificado y lo
Real
18
Hoy

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

21. ¿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.
20
OPERATIVO
TACTICO
ESTRATEGICO

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

23. ¿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.”
TEMA 10
Seguimiento y Control de Proyectos 22

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

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

26. Crisis en Proyectos
Informáticos.
• Detección del desfase
• Gestión de la crisis
• Recuperación tras la crisis
25

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

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

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

30. 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.
TEMA 10
Seguimiento y Control de Proyectos 29

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

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

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

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

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

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

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

38. Replanificar el proyecto tras la crisis
(coste pendiente y total).
• Como ha afectado la crisis al presupuesto del proyecto.
37
Gasto acumulado
0
5
10
15
20
25
0 1 2 3 4 5 6 7 8 9
Revisión
Real
Planificado

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

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

41. Estudio postmorten.
• Hay que reservar tiempo para que todos los miembros del
equipo puedan reflexionar sobre:
• las desviaciones,
• los problemas, y
• las soluciones tomadas.
TEMA
10
Seguimiento
y
Control
de
Proyectos
Informáticos.
40

42. 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.”
TEMA
10
Seguimiento
y
Control
de
Proyectos
Informáticos.
41

43. 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
TEMA
10
Seguimiento
y
Control
de
Proyectos
Informáticos.
42