u01.4.3seguimiento y Control

Control de Proyectos Informticos Jos Onofre Montesa AndrsUniversidad Politcnica de ValenciaEscuela Superior de Informtica Aplicada2003-2004

GPI-P3B. Control de Proyectos Informticos.

El punto de partida...Disponemos de la programacin del proyecto.Disponemos de la aplicacin de recursos en cada instante.Disponemos de un flujo de caja aceptado y uno coste global


6

5

4

3

2

1

1

2

3

4

5

6

7

8

9

1

0

Definicin 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 decisin de realizar ste proyecto


Objetivos del seguimientoDeterminar si el proyecto esta bajo controlSi el proyecto esta fuera de control


Determinar que el proyecto esta bajo control,Se estn alcanzando los hitos del proyecto:A tiempoCon los recursos estimadosCon un nivel de calidadContinua siendo aceptable econmicamente


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


Definicin del ControlToda actividad de gestin 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 realizacin de los planes(Thayer 1988)


Definicin del ControlProceso de hacer que las cosas ocurran de forma ordenada o de acuerdo a lo planificadoReifer


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.Adems suele cambiar el objetivo a 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.


Flujo de trabajo en el Seguimiento y ControlSI


Actividades de controlDesarrollar 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.


Actividades de controlMedir los resultadosDeterminar los niveles de cumplimiento, o alcance de desviaciones, sobre metas y estndares.Iniciar acciones correctivasReforzar estndares, ajustar metas, o replanificar.


Actividades de controlRecompensar 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...


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

Informacin sobre problemas futuros

Comparar lo ESPERADO y lo REALLo esperado se basa en:los compromisos de la planificacin yen los estndares de productividad. 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:


Comparar lo ESPERADO y lo REAL


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


Comparar lo planificado y lo RealMALBIENPerfecto?ExtraordinarioHoy


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


Es satisfactoria la situacin REAL?Cuando aparecen problemas con respecto al proyecto, la decisin de qu hacer debe ser tomada al nivel jerrquico apropiado.OPERATIVOTACTICOESTRATEGICO


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.


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


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


Replanificar o CorregirCorreccin 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.


Crisis en Proyectos Informticos.Deteccin del desfaseGestin de la crisisRecuperacin tras la crisis


Gestin de la crisisAnuncio 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.


Recuperacin tras la crisisEliminar al personal innecesario.Realizar un estudio postmorten de la crisis.Replanificar el proyecto tras la crisis (coste pendiente y total).


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.


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


Reasignacin de responsabilidades y autoridad.Deber reasignarse recursos,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, yquin puede tomar decisiones y sobre que.


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.


Relajacin de las restricciones sobre los recursos.Es posible que hubieran recursos limitados para el 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...


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


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.


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.


Realizar un estudio postmorten de la crisis.Examinar que es lo que fue mal.Identificar problemas sistemticos que podran evitarse.Documentar lo aprendido.


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


Tipos de seguimientoProcesoHitos (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)


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.


Estudio postmorten.Hay que reservar tiempo para que todos los miembros del equipo puedan reflexionar sobre:las desviaciones,los problemas, ylas soluciones tomadas.


Estudio postmorten: ejemplos.Cuando llevbamos 10 das de retraso en las pruebas deberamos haberselo comunicado al clienteEmpezamos el diseo demasiado pronto, antes de tener claras las especificacionesSe desmotivo al personal al decir que no habran subidas, justo en aquel momento.


BibliografaDavis, A.M., 201 Principles of software development. McGraw-Hill 1995Fairley, 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


u01.4.3seguimiento y Control

Documents

Transcript of u01.4.3seguimiento y Control