Seguimiento y Control de Un Proyecto de TI

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
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
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
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
y lo Real
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
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
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
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
Bibliografa
43

Seguimiento y Control de Un Proyecto de TI

Cargado por

Copyright:

Formatos disponibles

Seguimiento y Control de Un Proyecto de TI

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Seguimiento y Control de Un Proyecto de TI

Cargado por

Copyright:

Formatos disponibles

Seguimiento y

Ing. Juan Carlos Nez Ugalde

Determinar si el proyecto esta

Si el proyecto esta fuera de

Definicin del Control

Porqu hace falta el

Porqu hace falta el

Como realizar el seguimiento

Reuniones para valorar estado del proyecto.

Correccin de errores y/o

Mejoramiento pagina web

Fin del Desarrollo

Establecer las condiciones o medidas que deben

Establecer sistemas de monitorizacin e informes.

Determinar los niveles de cumplimiento, o alcance

Iniciar acciones correctivas

Elogiar, remunerar, y disciplinar al personal.

Documentar los mtodos de control.

Formal, Oral, regular

Formal, Oral, Ad-hoc

Formal, Escrito, regular

Formal, Escrito, Ad-hoc

Informal, Oral, Ad-hoc

los estndares de productividad, y

Puede ser correcto el trabajo desde el punto de

Estudiar la desviacin del estndar y

Sobre un grfico de Gantt con lo planificado trazamos

Estimar el % de las tareas no finalizada para pasar la

Hay muchos autores que no estn por la labor de

DeMarco propone un sistema binario. Se ha

Cuando aparecen problemas con respecto al

A nivel OPERATIVO: Los pequeos ajustes, el director del

Anuncio y publicidad general del problema en el equipo.

Eliminar al personal innecesario.

La reestructuracin debe ser cuidadosa:

Planificar reuniones para que los implicados alineen los

Dejar constancia de lo realizado e intentados para no

Poner al personal del

Hay que marcar un plazo razonable para que

Una vez finalizada la crisis habr que devolver los

Examinar que es lo que fue mal.

Replanificar el proyecto tras

Estas dos visiones no son independientes.

(se suele planificar con ambos en mente)

Todos los proyectos tienen problemas.

Hay que reservar tiempo para que todos los

Cuando llevbamos 10 das de retraso en las

Davis, A.M., 201 Principles of software development.

También podría gustarte