Seguimiento y

Control de un
Proyecto de TI

Ing. Juan Carlos Nez Ugalde

Definicin 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 decisin de
realizar
ste
proyecto
no
se
cumplan.

Objetivos del
seguimiento

Determinar si el proyecto esta

bajo control.
Un ejemplo de ello que los hitos
no se cumplan.

Determinar que el
proyecto esta bajo
Se control.
estn alcanzando los
hitos del proyecto:

A tiempo
Con
los
recursos
estimados
Con un nivel de calidad
Continua siendo aceptable
econmicamente
4

Si el proyecto esta fuera de

control,
Tan pronto se observen
desviaciones hay que:

Replanificar
Renegociar el plan
del proyecto con los
clientes

Definicin 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 planificacin,
hacemos estimaciones de:
Tamao de la aplicacin.
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.

Porqu hace falta el

seguimiento y control?
Es
normal
que
no
coincida
exactamente lo planificado con la
realidad.
Los proyectos informticos no son
repeticiones de un conjunto de tareas
realizadas previamente.

Como realizar el seguimiento

Calendarizacin realizado:

de

la

Reuniones para valorar estado del proyecto.

Evaluacin de resultados de cada una de las

actividades
expresadas
en
Hitos
(entregables).
Comparar fechas: tentativa-real inicio tarea
usando tabla de tareas.

Ejemplo de Tabla de
Ac Actividades
Descripcin
Tie
Esta
tiv
mp precedid
id
ad

Entregable

a de

Anlisis de requerimientos
con el o los usuarios de la
pgina WEB

_______

Listado de
requerimientos

Diseo en papel

Diseos en papel

Desarrollo de prototipo
para dar a conocer
avances al cliente

A,B

Diseos para
propuesta al usuario

Mostrar al cliente el
prototipo

Prototipo

Correccin de errores y/o

peticiones del cliente

Correcciones que se
van a realizar a la
pagina WEB

Mejoramiento pagina web

(foros, datos, visitas,
publicidad)

Mejoras en la pgina
WEB

10

Flujo de trabajo en el
Seguimiento y Control
Inicio del Desarrollo
Obtener Informacin del
Avance del Proyecto
Planificacin

Replanificar o
Corregir

Comparar lo Esperado
con los datos REALES
Satisfactorio?

NO

SI
Fin del
Proyecto?
SI

NO

Fin del Desarrollo

11

Descripcin de las
actividades de control
Desarrollar estndares de productividad.

Establecer las condiciones o medidas que deben

darse cuando las tareas se realizan de forma
correcta.

Establecer sistemas de monitorizacin e informes.

Determinar que datos son necesarios, quien y
cuando los debe recibir.

12

Descripcin de las
actividades de control
Medir los resultados

Determinar los niveles de cumplimiento, o alcance

de desviaciones, sobre metas y estndares.

Iniciar acciones correctivas

Reforzar estndares, ajustar metas, o replanificar.

13

Descripcin de las
actividades de control
Recompensar y disciplinar.

Elogiar, remunerar, y disciplinar al personal.

Documentar los mtodos de control.

Documentar los estndares, mtodos de informar y
control, puntos de decisin, planes de primas y
recompensas etc...

14

Formas de obtener
informacin del proyecto
Tipo de Informe

Ejemplo

Comentarios

Formal, Oral, regular

Reunin Semanal

Notas de la reunin

Formal, Oral, Ad-hoc

Final de Etapa

Formal, Escrito, regular

Informe Semanal

Formal, Escrito, Ad-hoc

Informe de Excepcin

Informal, Oral, Ad-hoc

Discusin en el Bar
Radio macuto

TEMA 10
Seguimiento y Control de Proyectos

Informacin sobre
problemas futuros

15

Comparar lo ESPERADO
y lo REAL
Lo esperado se basa en:

los estndares de productividad, y

en los compromisos de la planificacin.

Puede ser correcto el trabajo desde el punto de

vista de estndares y no serlo desde el punto de
vista de la planificacin.
Podemos encontrarnos en una de las siguientes
situaciones:

16

Comparar lo ESPERADO y
lo REAL
Cumple lo Cumple el Accin
Planificado Estndar
Todo va bien
SI
SI

SI

NO

NO

SI

NO

NO

TEMA 10
Seguimiento y Control de Proyectos

Estudiar la desviacin del estndar y

ajustarlo si es necesario, disciplinar
Replanificar y estudiar la situacin
para crear medidas correctivas
Estudiar con cuidado. Aplicar las dos
medidas anteriores.
17

Comparar lo planificado
y lo Real: lo planificado

Sobre un grfico de Gantt con lo planificado trazamos

una lnea quebrada que:
comienza y termina en la vertical del da actual.
Los vrtices de sta lnea se sitan en la interseccin de las
tareas no terminadas o las que ya deberan haber
comenzado pero que aun no lo han hecho.

Estimar el % de las tareas no finalizada para pasar la

lnea por ese punto.

18

di

na

19

ra
or

to
?
Ex
t

P
e

rf
ec

BI
EN

AL
M

Hoy

rio

Comparar lo planificado
y lo Real

Comparar lo planificado
y lo Real

Hay muchos autores que no estn por la labor de

que se estime un % de la tarea realizada.
Lleva al sndrome 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 duracin excesiva.

20

Es satisfactoria la
situacin REAL?

Cuando aparecen problemas con respecto al

proyecto, la decisin de qu hacer debe ser
tomada al nivel jerrquico apropiado.

ESTRATEGICO
TACTICO
OPERATIVO
21

Es satisfactoria la
situacin
REAL?

A nivel OPERATIVO: Los pequeos ajustes, el director del

proyecto los deja a los tcnicos.
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 ms drsticas.

22

Es satisfactoria la
situacin REAL?
Los proyectos
informticos no
retrasan su
entrega en meses
de golpe, su
retraso se
produce de da en
da.

TEMA 10
Seguimiento y Control de Proyectos

23

Replanificar o Corregir
La replanificacin debe de realizarse para que el
calendario se ajuste a la realidad
Los desarrolladores se sentirn menos frustrados si
ven que los objetivos son alcanzables.
Los clientes tendrn ms claro que es lo que pueden
esperar.

24

Replanificar o Corregir
Correccin de las desviaciones.
En lugar de modificar el plan, lo que haremos es
forzar al equipo de desarrollo para que la situacin
real se aproxime a la planificada.
Llamamos crisis de un proyecto al periodo que va
desde el que se ha producido una situacin seria de
desajuste hasta que sta es reencauzada.

25

Crisis en Proyectos
Informticos.
Deteccin del desfase
Gestin de la crisis
Recuperacin tras la crisis

26

Gestin de la crisis

Anuncio y publicidad general del problema en el equipo.

Reasignacin de responsabilidades y autoridad.
Actualizacin de la informacin de situacin.
Relajacin de las restricciones sobre los recursos.
Poner al personal del proyecto a trabajar a tope.
Establecer la fecha de finalizacin de la crisis.

27

Recuperacin tras la
crisis

Eliminar al personal innecesario.

Realizar un estudio postmorten de la crisis.
Replanificar el proyecto tras la crisis (coste
pendiente y total).

28

Anuncio y publicidad
general del problema en
Cuando se declara la crisis vamos retrasados y hemos
el equipo.
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.

29

Anuncio y publicidad
general del problema en
Lo primero que hay
elqueequipo.
hacer es
comunicar a todos
los que estn
implicados en el
proyecto el
problema para que
ayuden sin reservas
y que interioricen la
situacin.

TEMA 10
Seguimiento y Control de Proyectos

30

Reasignacin de
responsabilidades y
Deber reasignarse recursos,
autoridad.
algunas tareas se paralizarn,
las personas y recursos que tenan asignados pasen a
responsabilizarse de las nuevas tareas, creadas para
solucionar el problema.

La reestructuracin debe ser cuidadosa:

aclarando las nuevas responsabilidades, y
quin puede tomar decisiones y sobre que.

31

Actualizacin de la
informacin
de
situacin.

Planificar reuniones para que los implicados alineen los

trabajos hacia la solucin.
En estos casos es cuando es mas importante la
comunicacin.

Dejar constancia de lo realizado e intentados para no

cometer varias veces el mismo error.
El trabajo en grupo suele dar soluciones ms creativas.

32

Relajacin de las
restricciones sobre los
Es posible que hubieran recursos limitados para el
recursos.
proyecto.
Habr que hacer excepciones:
Permitir la utilizacin de equipos ms rpidos de
otros proyectos.
Aumentar el soporte administrativo para que los
desarrolladores se concentren ms en lo suyo.
Hacer catering...

33

Poner al personal del

proyecto a trabajar a
Hacer que la gente trabaje tantas horas como sea
posible en el proyecto (h. extras)
tope.
Ponerles telfonos mviles 24 horas al da por si a
alguien le hace falta comunicarse con algn
compaero.
Suprimir reuniones de departamento o empresa,
aplazar cursillos, etc.

34

Establecer la fecha de
finalizacin de la crisis.

Hay que marcar un plazo razonable para que

finalice la crisis, 30 das mximo.
Si se sobrepasa este limite debera replantearse la
viabilidad del proyecto.
La gente no puede vivir con un nivel de estrs
excesivo, puede ser contraproducente.

35

Eliminar al personal
innecesario.

Una vez finalizada la crisis habr que devolver los

recursos tomados de otros proyectos.
El proyecto tiene una planificacin que deber
seguir.
Los desarrolladores dejaran de tener prioridad en
la utilizacin de los administrativos.

36

Realizar un estudio
postmorten de la crisis.

Examinar que es lo que fue mal.

Identificar problemas sistemticos que podran
evitarse.
Documentar lo aprendido.

37

Replanificar el proyecto tras

la crisis (coste pendiente y
Como ha afectado la crisis al presupuesto del
total).
proyecto.

38

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)

39

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 podrs hacer de
forma diferente en el futuro.

40

 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

Estudio postmorten.

41

Cuando llevbamos 10 das de retraso en las

pruebas deberamos haberselo comunicado al
cliente
Empezamos el diseo demasiado pronto, antes de
tener claras las especificaciones
Se desmotivo al personal al decir que no habran
subidas, justo en aquel momento.

TEMA 10
Seguimiento y Control de

Estudio postmorten:
ejemplos.

42

 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

Bibliografa

43