Control de

Proyectos
Informáticos
José Onofre Montesa Andrés
Universidad Politécnica de
Valencia
Escuela Superior de
Informática Aplicada
2003-2004
 El punto de partida...
• Disponemos de la Tarea: Diseño Tarea: Codificación

programación del
Programas Program.
Recursos: … Recursos: …
Duración: 4 semanas Duración: 7 semanas

Tarea: Especifica

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

Tarea: Realización
Tarea: Diseño B.D.
Esquema

• Disponemos de la
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 flujo
Codificación Programas

Pruebas

0 2 4 6 8 10 12 14 16

de caja aceptado y uno

SEMANAS

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

GPI-P3B. Control de Proyectos Informáticos. 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

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

 Objetivos del seguimiento
– Determinar si el proyecto esta bajo control
– Si el proyecto esta fuera de control

GPI-P3B. Control de Proyectos Informáticos. 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

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

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

GPI-P3B. Control de Proyectos Informáticos. 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 correctoras,
• ayudando a la realización de los planes”
» (Thayer 1988)

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

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

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.

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

 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
GPI-P3B. Control de Proyectos Informáticos. 10
 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.

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

 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.

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

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

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

 Formas de obtener
información del proyecto
Tipo de Ejemplo Comentarios
Informe
Formal, Oral, Reunión Semanal Notas de la reunión
regular
Formal, Oral, Final de Etapa
Ad-hoc
Formal, Escrito, Informe Semanal
regular
Formal, Escrito, Informe de
Ad-hoc Excepción
Informal, Oral, Discusión en el bar Información sobre
Ad-hoc Radio macuto problemas futuros
GPI-P3B. Control de Proyectos Informáticos. 14
 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:

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.

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

Comparar lo planificado y lo
Real

Hoy

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.”

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.

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

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

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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).

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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...

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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
5 Planificado
0

0 1 2 3 4 5 6 7 8 9

GPI-P3B. Control de Proyectos Informáticos. 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)

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.

GPI-P3B. Control de Proyectos Informáticos. 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.”

GPI-P3B. Control de Proyectos Informáticos. 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

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