TEMA 10 Seguimiento y Control de Proyectos Informáticos. Jose Onofre Montesa Andrés Universidad...

TEMA 10 Seguimiento y Control

de Proyectos Informáticos.

Jose Onofre Montesa Andrés

Universidad Politécnica de Valencia

Escuela Universitaria de Informática

2001

TEMA 10 Seguimiento y Control de Proyectos Informáticos.

2

El punto de partida...

Disponemos de la programación del proyecto.

Disponemos de la aplicación de recursos en cada instante.

Disponemos de un flujo de caja aceptado y uno coste global

Tarea: Especifica Necesidades

Recursos: …

Duración: 2 semanas

Tarea: Diseño Programas

Recursos: …


Tarea: Diseño B.D.

Recursos: …


Tarea: Realización Esquema

Recursos: …


Tarea: Codificación Program.

Recursos: …


Tarea: Pruebas

Recursos: …


6

543

21

1 2 3 4 5 6 7 8 9 1 0

TAREAS

Especificar Necesidades

Diseño Programas

Diseño Base de Datos

Realización Esquema

Codificación Programas

Pruebas

0 2 4 6 8 10 12 14 16SEMANAS


3

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, ose contravenga algunas condiciones

acordadas que fueron base en la decisión de realizar éste proyecto


4

Objetivos del seguimiento

Determinar si el proyecto esta bajo control

Si el proyecto esta fuera de control


5

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


6

Si el proyecto esta fuera de control, Tan pronto se

observen desviaciones hay que Replanificar Renegociar el plan

del proyecto con los clientes


7

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)


8

Definición del Control

“Proceso de hacer que las cosas ocurran

de forma ordenada o de acuerdo a lo planificado”

Reifer


9

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


10

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


11

Planificación

Estándares Productividad

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

Flujo de trabajo en el Seguimiento y Control


12

Descripción de las actividades de controlDesarrollar 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.


13

Descripción de las actividades de controlMedir los resultados

Determinar los niveles de cumplimiento, o alcance de desviaciones, sobre metas y estándares.

Iniciar acciones correctivasReforzar estándares, ajustar metas, o

replanificar.


14

Descripción de las actividades de controlRecompensar 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...


15

Formas de obtener información del proyectoTipo 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 BarRadio macuto

Información sobreproblemas futuros


16

Comparar lo ESPERADO y lo REALLo 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:


17

Cumple loPlanificado

Cumple elEstándar

Acción

SI SI Todo va bien

SI NO Estudiar la desviación del estándar yajustarlo si es necesario, disciplinar

NO SI Replanificar y estudiar la situaciónpara crear medidas correctivas

NO NO Estudiar con cuidado. Aplicar las dosmedidas anteriores.

Comparar lo ESPERADO y lo REAL


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.


19M

ALBIE

N¿P

erfe

cto?

Extra

ordi

narioHoy

Comparar lo planificado y lo Real


20

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


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.

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.


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


24


La replanificación debe de realizarse para que el calendario se ajuste a la realidadLos 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.


25


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.


26

Crisis en Proyectos Informáticos.Detección del desfaseGestión de la crisisRecuperación tras la crisis


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.


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


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.


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.


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, yquién puede tomar decisiones y sobre que.


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.


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


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.


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.


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.


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.


38

Gasto acumulado

0

5

10

15

20

25

0 1 2 3 4 5 6 7 8 9

RevisiónRealPlanificado

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

presupuesto del proyecto.


39

Tipos de seguimiento

ProcesoHitos (Momentos clave del proyecto)Tareas: Comienzo, Fin, Recursos.

ProductosEntregablesCalidad (Conformidad del cliente)

Estas dos visiones no son independientes.

– (se suele planificar con ambos en mente)


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.


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.


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


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. Jose Onofre Montesa Andrés Universidad...

Documents

Transcript of TEMA 10 Seguimiento y Control de Proyectos Informáticos. Jose Onofre Montesa Andrés Universidad...