Seguimiento y Control de

Proyectos Informáticos.
El punto de partida...
 Disponemos de la
programación del
Tarea: Diseño Tarea: Codificación
Programas Program.
Recursos: … Recursos: …
Duración: 4 semanas Duración: 7 semanas

proyecto.
Tarea: Especifica
Necesidades Tarea: Pruebas
Recursos: … Recursos: …
Duración: 2 semanas Duración: 2 semanas

 Disponemos de la
Tarea: Realización
Tarea: Diseño B.D.
Esquema
Recursos: …
Recursos: …
Duración: 2 semanas
Duración: 1 semanas

aplicación de recursos TAREAS

Especificar Necesidades

en cada instante.
Diseño Programas

Diseño Base de Datos

Realización Esquema

 Disponemos de un
Codificación Programas

Pruebas

flujo de caja
0 2 4 6 8 10 12 14 16
SEMANAS

aceptado y uno coste

5
4

global
3
2
1
1 2 3 4 5 6 7 8 9 1 0

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
2
Objetivos del seguimiento
Determinar si el proyecto esta bajo
control
Si el proyecto esta fuera de control

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
4
Si el proyecto esta fuera de
control,
 Tan pronto se
observen
desviaciones hay
que
Replanificar
Renegociar el plan
del proyecto con los
clientes

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 para correctoras,
 ayudando a la realización de los
planes”
» (Thayer 1988)
6
Definición del Control
“Proceso de hacer
que las cosas
ocurran de
forma ordenada
o de acuerdo a
lo planificado”
Reifer

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.

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.

TEMA 10 9
Seguimiento y Control de
Flujo de trabajo en el
Seguimiento y Control
Inicio del Desarrollo

Obtener Información del

Avance del Proyecto

Planificación Comparar lo Esperado Replanificar o

con los datos REALES Corregir
Estándares
Productividad NO
¿Satisfactorio?

SI
¿Fin del NO
Proyecto?
SI
Fin del Desarrollo
10
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
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
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
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 Información sobre

Radio macuto problemas futuros

14
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
Comparar lo ESPERADO y lo
REAL

Cumple lo Cumple el Acción

Planificado Estándar
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.

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.
17
Comparar lo planificado y lo
Real

Hoy

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

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

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.

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.
24
Crisis en Proyectos
Informáticos.
 Detección del desfase
 Gestión de la crisis
 Recuperación tras la crisis

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.

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

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

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

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

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

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.

36
Replanificar el proyecto tras la
crisis (coste pendiente y total).
 Como ha afectado la crisis al
presupuesto del proyecto.

Gasto acumulado
25
20
15 Revisión
10 Real
Planificado
5
0
0 1 2 3 4 5 6 7 8 9

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

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.

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

41
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

42
La Calidad.

La Calidad:
Qué es, Cómo se consigue, Quién la define.
Etapas de la Gestión de la Calidad
Calidad en las empresas de servicios
Evolución de la Calidad.
Evaluación final del Proyecto:
Concepto, Finalidad , Características
Evaluación de la Calidad del Proyecto
Informático
Evaluación de Grupo de Desarrollo
43