TABLA DE CONTENIDO

INTRODUCCION.........................................................................................................................................3 CAPITULO 1...............................................................................................................................................5 CONCEPTOS DE LA GERENCIA DE PROYECTOS..................................................................................5 CONTROL ADMINISTRATIVO Y CONTROL TCNICO ........................................................................................................5 LA GERENCIA DEL PROYECTO COMO UN PROCESO DE RESOLUCIN DE PROBLEMAS..............................................................6 GERENCIA DE PROYECTOS BASADA EN EL EQUIPO DE TRABAJO.......................................................................................7 PARTICIPACIN ACTIVA DE LA ALTA GERENCIA...........................................................................................................7 SESIONES DE PLANIFICACIN RPIDA DE APLICACIONES (RAP)....................................................................................7 EL CONJUNTO DE INFORMACIN CRTICA PARA LA GERENCIA DEL PROYECTO....................................................................8 GERENCIA DEL PROYECTO EN TIEMPO REAL...............................................................................................................9 CAPITULO 2.............................................................................................................................................10 INICIO DE UN PROYECTO.......................................................................................................................10 PASO 1: INICIO DEL PROYECTO..............................................................................................................................11 BUSINESS CASE..................................................................................................................................................13 MODELANDO EL ALCANCE DEL PROYECTO.................................................................................................................14 FIGURA 2.3 ALCANCES DEL PROYECTO Y DEL SISTEMA AUTOMATIZADO.........................................................................15 SOBRE LOS ESTIMADOS INICIALES............................................................................................................................17 CAPITULO 3.............................................................................................................................................19 PLANIFICACION DE PROYECTOS..........................................................................................................19 PASO 2: PLANIFICACIN DETALLADA DEL PROYECTO.................................................................................................20 TAREA 1: REVISIN DEL BUSINESS CASE................................................................................................................20 TAREA 2: SELECCIN DE LA ESTRATEGIA DE DESARROLLO..........................................................................................20 FIGURA 3.2 ESTRATEGIAS DE DESARROLLO.....................................................................................23 Acerca del Desarrollo Rpido de Aplicaciones (RAD)...........................................................................24 TAREA 3: DESARROLLO DE LA EVALUACIN DE RIESGOS............................................................................................25 Complejidad del sistema.........................................................................................................................25 Ambiente de los Usuarios clave.............................................................................................................25 Ambiente del Grupo de Proyecto...........................................................................................................26 Acerca de las Mtricas de Software ......................................................................................................26 TAREA 4: SELECCIN DE LAS TAREAS.....................................................................................................................27 TAREA 5: ESTIMACIN DE LAS TAREAS....................................................................................................................30 ESTIMANDO EL ESFUERZO DE LA TAREA...................................................................................................................30 Estimando el esfuerzo y la duracin de las tareas.................................................................................31 TAREA 6: CRONOGRAMA DEL PROYECTO.................................................................................................................32 UNA REVISIN A LA PLANIFICACIN EN TIEMPO - REAL..............................................................................................34 CAPITULO 4.............................................................................................................................................36 SEGUIMIENTO Y REVISION DE LOS PROYECTOS..............................................................................36 PASO 3: SEGUIMIENTO DEL PROYECTO...................................................................................................................36 PASO 4: INFORME DEL PROYECTO.........................................................................................................................36 Reporte de situacin del proyecto..........................................................................................................37 FIGURA 4.1REPORTE SEMANAL DE SITUACIN..........................................................................................................37 FIGURA 4.2 REPORTE MENSUAL DE SITUACIN.........................................................................................................38 FIGURA 4.3 SOLICITUD DE CAMBIO........................................................................................................................39

Figura 4.6 Registro de Solicitudes de Decisin......................................................................................44 Reporte y registro de problemas............................................................................................................45 FIGURA 4.7 REPORTE DE PROBLEMAS...................................................................................................................45 Figura 4.8 Registro de Reporte de Problemas.......................................................................................47 CAPITULO 5.............................................................................................................................................48 ACUERDOS EN EL PROYECTO..............................................................................................................48 LIBRO DEL PROYECTO..........................................................................................................................................48 GRUPOS CLAVE..............................................................................................................................................49 ACUERDOS DEL PROYECTO.....................................................................................................................51 ACUERDOS SOBRE EL PERSONAL DEL PROYECTO.............................................................................52 ALGO MAS SOBRE LOS ACUERDOS........................................................................................................52 CAPITULO 6 ............................................................................................................................................58 ORGANIZACION PARA EL PROYECTO.................................................................................................58 COMITE DEL PROYECTO...........................................................................................................................62 Funciones y responsabilidades del Comit del Proyecto......................................................................63 Aprobacin de proyectos y etapas de proyectos...................................................................................63 Seguimiento y revisin de proyectos......................................................................................................64 Asistencia al proyecto.............................................................................................................................64 Resolucin de conflictos durante el proyecto.........................................................................................64 Estructura de las reuniones del Comit del Proyecto............................................................................65 ALGO MAS SOBRE EL COMITE DEL PROYECTO....................................................................................68 CAPITULO 7.............................................................................................................................................72 MODELO DE EVALUACION DE RIESGOS ..............................................................................................72 INTRODUCCIN....................................................................................................................................................72 EL CUESTIONARIO...............................................................................................................................................74 PESOS PARA LA EVALUACIN DEL RIESGO...............................................................................................................74 MS ACERCA DE LAS MTRICAS DE SOFTWARE........................................................................................................75 DIFERENTES MODELOS DE RIESGO.........................................................................................................................75 CAPITULO 8.............................................................................................................................................90 ADMINISTRANDO EL EQUIPO DEL PROYECTO...................................................................................90 RESPONSABILIDADES EN CADA ETAPA DEL CICLO DE VIDA.............................................................91 PUNTOS DE REVISIN EN CADA ETAPA DEL CICLO DE VIDA DEL PROYECTO.......................................................................95 Estudio de Factibilidad............................................................................................................................95 Definicin de los requerimientos.............................................................................................................95 Especificacin del sistema......................................................................................................................95 Diseo del sistema..................................................................................................................................95 Desarrollo del sistema............................................................................................................................96 Protocolo de pruebas..............................................................................................................................96 Implantacin............................................................................................................................................97 Mantenimiento.........................................................................................................................................98

INTRODUCCION En un ambiente de sistemas de informacin caracterizado en sus aspectos tcnicos y tecnolgicos por una alta integracin entre los datos, las funciones, el usuario y el ambiente de computacin, se hace necesario tambin definir un nuevo paradigma en cuanto a la gerencia de proyectos de sistemas de informacin se refiere. Se requiere de un nuevo enfoque para la formacin de equipos humanos, estructura organizacin y tcnicas de administracin de proyectos que satisfagan las presiones por una mayor productividad, un presupuesto controlado, un servicio orientado al Cliente-Usuario y un ambiente de negocios altamente competido que obliga a ser efectivos con eficiencia. Se debe contar en las empresas con profesionales de proyectos que reconozcan las exigencias del ambiente actual de negocios (cambiante y competitivo), que se identifiquen con la necesidad que tienen los miembros del equipo de trabajar en un proyecto bien gerenciado y que el resultado del trabajo debe ayudar a mejorar tanto a los procesos de la organizacin como la existencia de sus empleados. Se dice que slo podemos manejar aquellas cosas que podemos medir. Luego, si no podemos medir lo que creamos, surgirn factores subjetivos o indirectos que sern utilizados para determinar el xito o fracaso del esfuerzo realizado. De acuerdo a esto, para manejar las actividades efectivamente, se necesita crear un ambiente donde se pueda medir con precisin, y monitorear constantemente, el esfuerzo realizado contra un conjunto de estndares y valores predeterminados. Aunque no todas las fallas en un proyecto de sistemas pueden ser eliminadas si se cuenta con una gerencia de proyectos adecuada, de seguro que s ayudar. Qu es un proyecto de desarrollo de sistemas? Es un conjunto de actividades orientadas a lograr un objetivo definido, que consume recursos, que opera bajo restricciones de calidad y de costos, y que comienza y termina en puntos identificables en el tiempo, generando productos de sistemas cuantificables y de calidad. En el nterin, se obtienen otros productos que ayudarn a controlar el progreso del proyecto, pasando algunos de ellos a ser parte del sistema definitivo. Por qu fracasa un proyecto? Se puede definir que un proyecto ha fallado si no logra satisfacer los requerimientos mnimos del usuario, o es implantado tan tarde que ya no es efectivo, o excede inaceptablemente sus presupuestos de desarrollo o de operacin. Tambin existen razones puramente polticas que llevan al fracaso de un proyecto, pero esas son las ms impredecibles y menos previsibles. Entre las razones previsibles ms comunes estn: Ausencia de especificaciones claras y entendibles. Documentacin de baja calidad.

Una pobre comunicacin. Objetivos muy ambiciosos. Rendimiento bajo y de poca calidad. Desarrollos que nunca terminan. Sistemas que no son costo-efectivos. Proyectos que se exceden en mucho presupuestariamente.

Cmo puede ayudar una gerencia de proyectos? Con todas esas causas de fallas previamente descritas y posiblemente muchas otras no mencionadas, Qu se puede hacer para aumentar las posibilidades de xito de un proyecto? Salvo que existan razones polticas para que fracase el proyecto, se pueden hacer muchas cosas que ayudarn a mejorar las probabilidades de culminar el proyecto exitosamente. Conceptos como dividir para conquistar, mnimo producto mensurable, revisiones, presencia activa de QA, conjunto mnimo aceptable de pruebas, equipo de proyecto adecuadamente organizado, control de cambios, y acuerdo de niveles de servicio, estn directamente relacionados con el objetivo de culminar con xito un proyecto y luego operarlo en condiciones de seguridad. La idea de contar con un ambiente organizado y procedimentado es el objetivo de este manual, que se espera contribuya a mejorar el ambiente de trabajo en la organizacin.

CAPITULO 1 Conceptos de la Gerencia de Proyectos Para el Project Management Institute (PMI), la gerencia de proyectos es el arte de dirigir y coordinar recursos humanos y materiales a travs de la vida de un proyecto, utilizando tcnicas de administracin modernas, para lograr objetivos determinados en cuanto a alcance, costo, tiempo, calidad y satisfaccin de los participantes. Existe un grupo de conceptos crticos que definen el enfoque de Gerencia de Proyectos que se quiere desarrollar e implantar: Control Administrativo y Control Tcnico. La Gerencia de Proyectos como un proceso de solucin de problemas. La Gerencia de Proyectos orientada a Equipos de Trabajo. El involucramiento de la Alta Gerencia en los proyectos. Sesiones de Planificacin Rpida de Aplicaciones. El conjunto de informacin crtica para la gerencia del proyecto. Gerencia de Proyectos en tiempo real.

Control Administrativo y Control Tcnico La gerencia de proyectos se enfoca hacia los aspectos administrativos y del negocio de un proyecto. Su inters se dirige a aspectos tales como costos, beneficios, riesgos, personal, productos, fechas de entrega, contingencias, productividad y prioridades. Un proyecto de sistemas se puede definir usando dos grupos interrelacionados de informacin: la informacin administrativa o del negocio, y la informacin tcnica. ADMINISTRATIVA TECNICA

Proyectosdependientes Riesgos Beneficios Costos Cronogramas Prioridades Estimados Recursos Suposiciones

Especificaciones funcionales Modelo dedatos Diagramas dediseo Alcance Diseo de bases de datos/archivos Objetivos Especificaciones de mdulos Estrategia Documentacin Calidad Entrenamiento Programas y procedimientos Planes deprueba

Figura 1.1 Definicin del proyecto: Aspectos Administrativos y Tcnicos

Estos dos grupos tienen en comn los objetivos, alcance, calidad y estrategia del proyecto. Los aspectos tcnicos del proyecto deben ser resueltos por el personal tcnico y controlados por el sistema de control tcnico. Por ejemplo, problemas como defectos en el software, fallas de la red local, etc., son aspectos tcnicos que debe resolver el personal tcnico ms calificado. El problema que el Gerente del Proyecto debe resolver es el impacto de los aspectos tcnicos en el ambiente de administracin tales como fechas de entrega, productos, personal, etc. El Gerente del Proyecto debe facilitar el proceso de solucin tcnica, sin involucrarse en la solucin del problema, pero s en el qu y el por qu de la solucin. En resumen, el proceso de administracin del proyecto est interrelacionado con la naturaleza tcnica del proyecto, pero debe mantenerse tan independiente como sea posible de los detalles en cuanto a los aspectos tcnicos. La gerencia del proyecto como un proceso de resolucin de problemas. Es razonable afirmar que todos los proyectos estarn sujetos a cambios, interrupciones y presin. La experiencia demuestra que los proyectos, a medida que se desarrollan, sufren cambios en los objetivos y ampliacin del alcance, que dejan a los estimados iniciales del proyecto muy lejos de la realidad. Adicionalmente, los proyectos estn sujetos a rotacin del personal, problemas de calidad, cambios de prioridades y otros aspectos relacionados con una duracin ms prolongada de ellos. Como resultado de esto, la gerencia del proyecto debe estar pendiente del seguimiento, evaluacin y control de las variaciones con respecto a los conceptos iniciales del proyecto. Muchos proyectos dedican ms tiempo y esfuerzos a tareas reactivas para arreglar los inconvenientes que se presentan, que lo que estaran dispuestos a invertir en la planificacin productiva para prevenirlos. Se debe luchar por eliminar la idea arraigada en el personal tcnico, que la planificacin es una carga que los distrae del objetivo principal de disear, programar e implantar sistemas. Se debe enfatizar que las actividades de planificacin y administracin de proyectos no significan una carga para el proyecto, sino que son actividades normales que se desarrollan como parte del trabajo diario del grupo del proyecto. La identificacin de los problemas potenciales en un proyecto y su resolucin proactiva o su minimizacin, son la clave del enfoque de la gerencia de proyectos.

Gerencia de proyectos basada en el equipo de trabajo. El uso de tcnicas de trabajo en equipo y de mtodos formales orientados a la solucin de los problemas, es parte integral de una gerencia de proyectos efectiva. Es esencial que las actividades de la gerencia de proyectos sean comprendidas por la mayora de los miembros del equipo de trabajo, los representantes de usuarios y los diferentes grupos de soporte tcnico y administrativo. Entre las ventajas del trabajo en equipo se tienen: Los planes del proyecto, la informacin de soporte y la informacin de seguimiento del proyecto sern ms precisas. Los miembros del equipo estarn comprometidos ms profundamente con los planes en la medida que ellos sean parte integral de su desarrollo. La informacin del proyecto ser aceptada con ms facilidad en la medida en que la base de entrada de los datos sea compartida por la mayora de las personas involucradas. Participacin Activa de la Alta Gerencia Este es uno de los aspectos ms crticos del enfoque que se est exponiendo. Hay oportunidades en que se presentan situaciones que requieren de decisiones que estn fuera del control o delegacin de autoridad del Gerente del Proyecto. Por ejemplo, un proveedor no puede entregar un equipo esencial para el proyecto, o un gerente de alto nivel no est dispuesto a asignar a una persona clave de su unidad como parte del grupo del proyecto, o hay problemas con la reestructuracin de una unidad y sus cargos como consecuencia del nuevo enfoque del proyecto. En estos casos, el grupo de Alta Gerencia asociado al proyecto debe tomar acciones para resolver las situaciones y minimizar su impacto en el proyecto integral. La Alta Gerencia debe ser vista como la instancia para plantear los aspectos administrativos que requieren de soluciones de problemas de alto nivel. Ellos constituyen una red de soporte vital para el Gerente del Proyecto y deben aadir valor a los procesos de administracin de los proyectos. Finalmente, La Alta Gerencia debe desempear su rol en la resolucin de los problemas as como tambin continuar desempeando sus tareas tradicionales de aprobacin, seguimiento y revisin. Sesiones de Planificacin Rpida de Aplicaciones (RAP) Un elemento adicional a los procesos de planificacin basados en trabajo en equipo, es el uso de sesiones de planificacin altamente estructuradas. Al igual que los procesos de desarrollo de sistemas se han acortado debido a la utilizacin de Planificacin Conjunta de Requerimientos (JRP), Diseo Conjunto de Aplicaciones (JAD) y

Desarrollo Rpido de Aplicaciones (RAD), se har uso de las tcnicas asociadas a dichos procesos para el mejoramiento de la planificacin. Las sesiones RAP son convocadas por el Gerente del Proyecto y deben involucrar a todos los miembros del grupo del proyecto, expertos del negocio de las reas afectadas, representantes de proyectos interrelacionados y personal de los grupos de soporte tcnico (Operaciones, Redes, Administracin de base de datos, etc.). Tpicamente, las sesiones RAP duran de uno a tres das. Las sesiones RAP pueden ser apoyadas por el uso de sistemas automatizados para la estimacin y preparacin de cronogramas. El conjunto de informacin crtica para la Gerencia del Proyecto. Como se muestra en la Figura 1.1, se requiere de dos grupos de informacin para entender las caractersticas de un proyecto. La primera se refiere a los aspectos tcnicos tales como Diccionario de Datos, Modelos de datos, diagramas funcionales, especificaciones de programas, protocolos de prueba, material de entrenamiento, etc. Al mismo nivel de importancia est la informacin de los aspectos administrativos del proyecto. Esta informacin es la base para la toma de decisiones clave durante la vida del proyecto. Ella establece el enlace entre el Equipo del Proyecto, el Gerente del Proyecto, los Usuarios o Clientes y la Alta Gerencia. Es importante enfatizar que el contenido y la estructura de la informacin administrativa debe ser tan independiente como sea posible de la naturaleza tcnica especfica del proyecto. El contenido del informe administrativo del proyecto se ir detallando en los siguientes captulos; sin embargo, un esquema general del mismo es como sigue:

Objetivos Alcance reas, grupos y proyectos clave externos Fechas de eventos crticos Beneficios Costos Riesgos Calidad en los productos Estrategias de desarrollo Personal Cronogramas/tareas

La informacin para la gerencia del proyecto debe ser considerada como la base para un acuerdo/contrato del proyecto, y ser el vehculo principal para el seguimiento y control de cambios durante el desarrollo del proyecto.

Gerencia del Proyecto en tiempo real La gerencia de proyectos actual se mueve en un ambiente que se podra catalogar de turbulento, impredecible, con tecnologas que surgen continuamente y que obligan a cambios no previstos en el desarrollo de los proyectos. Por tanto, la gerencia debe adecuarse a este ambiente y operar en tiempo real utilizando tanto la microplanificacin como la macroplanificacin. La planificacin en tiempo real o microplanificacin implica la planificacin detallada de un proyecto por perodos limitados, en el entorno de 3 a 6 meses. El enfoque de microplanificacin, aunado a las sesiones RAP, conduce a la ejecucin de sesiones peridicas e intensivas de planificacin (con una frecuencia mnima quincenal) para el desarrollo detallado de actividades del siguiente perodo (lo que es diferente de la planificacin de la siguiente fase o subproyecto), a la actualizacin de la informacin de la gerencia del proyecto, a desarrollar la solucin a los problemas presentados y a informar al Comit del Proyecto sobre cualquier variacin potencial para su revisin y aprobacin a nivel gerencial. Se debe enfatizar que la frecuencia de los procesos de microplanificacin depende en gran medida de los niveles de riesgo del proyecto. Lo que es esencial es que la informacin y la planificacin del proyecto siempre reflejen la realidad de ste. Mientras ms turbulencia se presente en un proyecto, ms frecuentemente se deben realizar las microplanificaciones. En cada oportunidad que se presente un cambio en cualquiera de los componentes del conjunto de informacin del proyecto(por ejemplo, cambios en los niveles de riesgo o modificaciones en el objetivo), el Gerente del Proyecto, junto con el Equipo del Proyecto, deben hacer un alto en las actividades y desarrollar una sesin RAP para evaluar el impacto del cambio, determinar alternativas y opciones de solucin, desarrollar planes alternos y, si se requiere, buscar la aprobacin de la Alta Gerencia y del Usuario Cliente para poder continuar el proyecto.

CAPITULO 2 INICIO DE UN PROYECTO El modelo de administracin de proyectos que se va a desarrollar define 4 procesos administrativos y un proceso de tecnologa de informacin, como se muestra en la siguiente figura:
Roles Ejecutivos Business Case Aprobado SELECCION, APROBACION, REVISION Y SEGUIMIENTO DE LOS PROYECTOS Business Case

Reportes del Proyecto

PLANIFICACION DEL PROYECTO ESTUDIO DE FACTIBILIDAD (BUSINESS CASE) Planes del Proyecto

REVISION DEL PROYECTO

Detalles de Replanificacin del proyecto SEGUIMIENTO AL PROYECTO

Detalles de seguimiento del Proyecto

ROLES DEL GERENTE Y DEL GRUPO DE PROYECTO

Figura 2.1Modelo de Administracin del Proyecto

Los cuatro procesos administrativos son: Seleccin, aprobacin y revisin del proyecto. Planificacin del proyecto. Seguimiento del proyecto. Revisin del proyecto.

El proceso correspondiente al Ciclo de Desarrollo de Sistemas es: Desarrollo de los Trminos de Referencia o Business Case.

Este captulo se dedicar a explorar el modelo general de gerencia de proyectos, con nfasis en las relaciones entre la Alta Gerencia, el Gerente de Proyectos y su Grupo de Proyecto. As mismo, se ver como el Business Case se produce durante el Estudio de Factibilidad. Como regla general, el enfoque de gerencia de proyectos implica una estrategia de dos etapas para el inicio del proyecto. Como siempre al inicio de cualquier jornada, la primera de stas es la ms importante. Paso 1: Inicio del proyecto Este proceso implica una compleja interrelacin entre el nivel gerencial, los planificadores estratgicos, gerentes de proyecto y analistas de negocios y de sistemas. Para abordar este paso, es importante entender que, aunque los gerentes del negocio son las personas crticas para el proceso de seleccin, aprobacin y revisin de los proyectos, ellos dependen para su trabajo de un conjunto de informacin clave del proyecto. Esta informacin es preparada en principio por el Gerente del Proyecto y los analistas de negocios, a objeto de determinar y confirmar si el proyecto es viable, tanto desde el punto de vista de la gerencia/negocio, como tcnicamente. La forma en que esto normalmente ocurrira est basada en que durante el ejercicio de planificacin estratgica la alta gerencia ya habra identificado los proyectos clave, es decir, aquellos que reflejan su adecuacin a la misin y direccin corporativa. Este plan estratgico podra tambin incluir algunos proyectos adicionales o algunas iniciativas resultantes de eventos externos sucedidos luego de la finalizacin del ejercicio de planificacin estratgica (Figura 2.2). En la mayora de los proyectos, la alta gerencia aprueba la primera etapa de inicio del proyecto: la culminacin del Estudio de Factibilidad, que se refleja en el producto Trminos de Referencia o Business Case. Esto implica un estudio de alto nivel del proyecto, incluyendo el anlisis inicial del sistema y la produccin de dos conjuntos clave de informacin: La descripcin tcnica del proyecto y las propuestas de solucin. El Business Case o Trminos de Referencia del proyecto.

El desarrollo de la descripcin tcnica debe incluir modelos de datos iniciales de alto nivel, diagramas de flujo de datos, descripcin del problema y propuestas de alternativas de diseo. La calidad del material preparado es crtica para el Business Case, ya que es la base para las estimaciones y los requerimientos de calidad.

Clientes

Nuevos proyectos

Business Case Aprobado

SELECCION, APROBACION, REVISION Y SEGUIMIENTO DE LOS PROYECTOS Business Case Requerimiento Inicial

Planes estratgicos

Unidad de Planif. Estrat.

Clientes Reportes del Proyecto

INICIO DEL PROYECTO

PLANIFICACION DEL PROYECTO ESTUDIO DE FACTIBILIDAD (BUSINESS CASE)

REVISION DEL PROYECTO

Planes del Proyecto

Detalles de Replanificacin del proyecto

Detalles del seguimiento del Proyecto

Grupo del Proyecto

Progreso Acrual/proyectado

SEGUIMIENTO AL PROYECTO

Detalles del seguimiento del proyecto

Grupo del Proyecto

Figura 2.2 Modelo Detallado de gerencia del proyecto

Business Case El Business Case o Trminos de Referencia, es un producto del Estudio de Factibilidad, que es la primera fase del ciclo de desarrollo de sistemas. Se produce como resultado de las sesiones iniciales de planificacin del proyecto. El proceso tpico para desarrollar el Business Case es la produccin de un borrador inicial, al comienzo del Estudio de Factibilidad, el cual se va puliendo a medida que progresa el estudio. La versin final se produce con la finalizacin del Estudio de Factibilidad y se remite al Comit del Proyecto para su aprobacin y as ir a la segunda etapa de la fase de inicio del proyecto - el desarrollo total del proyecto. Para preparar el Business Case, el Gerente del Proyecto debe concentrarse en el qu y el por qu del sistema de informacin, y evitar involucrarse en el cmo. Las preguntas pertinentes son: qu se quiere hacer? (La especificacin) y por qu se quiere hacer? (El beneficio o retorno de la inversin). Como Gerente Usuario incorporado al negocio de sistemas, se est ms cerca de la cuestin del por qu que el personal de Tecnologa de Informacin. Cuando se est envuelto en una reunin de sistemas de informacin, la pregunta a hacerse como Gerente Usuario es: Estamos trabajando en las preguntas del qu y el por qu? Si no, en el mejor de los casos se est gastando el tiempo ahondando en reas donde el Gerente Usuario no puede contribuir. El Business Case provee los elementos bsicos para el seguimiento del proyecto, desde su inicio hasta su culminacin. Como ya se ha mencionado, es normal que un proyecto est sujeto a variaciones y cambios. El Business Case es la herramienta bsica para hacer el seguimiento y controlar los cambios en el proyecto. El Business Case debe contener la siguiente informacin:

Antecedentes y descripcin del proyecto: Una descripcin breve de los antecedentes y del proyecto. Es importante en este punto incluir una definicin muy clara de los objetivos del negocio. En la implantacin de sistemas complejos, la ausencia de una real necesidad produce dificultades casi insuperables, porque no se encuentra colaboracin entre los usuarios, casi siempre reacios a invertir tiempo y esfuerzos para facilitar el xito del proyecto. Alcance del proyecto: Una definicin clara de las reas de impacto del proyecto y de sus lmites. Objetivos del proyecto: Una descripcin precisa de los objetivos del proyecto desde los puntos de vista estratgico, de negocios y de sistema. El proyecto tiene necesariamente que basarse sobre objetivos del negocio claros y ponderables. Beneficios del proyecto: Los beneficios que la organizacin espera obtener al poner en operacin el proyecto. Costos del proyecto: Los costos de personal, tiempo, equipos, etc. involucrados en la ejecucin del proyecto. Estrategia de desarrollo: La secuencia y segmentos del proyecto en versiones y subproyectos.

Evaluacin de los riesgos del proyecto: Una evaluacin formal de los riesgos potenciales asociados con el proyecto. Cronograma de desarrollo: Los planes y cronogramas del proyecto. Leyes, normas y reglamentos relevantes al proyecto: Una descripcin y recopilacin de cualquier legislacin o poltica gubernamental o privada que est asociada con el proyecto. Grupos clave: Grupos clave y Unidades fuera del control directo del Gerente del Proyecto, y de los cuales depende en alguna forma el proyecto. Personal del proyecto: Una definicin clara de los perfiles requeridos para el personal necesario en el proyecto, as como una primera propuesta de organizacin para el proyecto. El soporte y la colaboracin de todos los niveles de la gerencia de la empresa son condiciones bsicas e imprescindibles para el desarrollo continuo del proyecto. La responsabilidad del proyecto tiene que ser manejada por un gerente con competencia y conocimiento profundo del negocio y, si es posible, acompaado por un miembro exitoso del equipo de Tecnologa de Informacin. Proyectos relacionados: Una descripcin de cualquier otro proyecto que dependa o est interrelacionado con el proyecto propuesto, as como la integracin del sistema bajo estudio con los sistemas existentes. Suposiciones, condiciones y restricciones: Se refiere a elementos tales como fechas de culminacin propuestas o impuestas, tecnologa seleccionada, etc. Calidad en el proyecto: Una definicin que incluya medidas de la calidad requeridas de los productos del proyecto. Descripcin tcnica del proyecto: Este es un anexo que debe cubrir al menos los siguientes tpicos: Necesidades o deficiencias potenciales de sistemas existentes. Una conceptualizacin que ofrezca una gua estratgica para eliminar deficiencias existentes o potenciales, sobre todo en cuanto a la fuente y uso de los datos crticos del sistema. Propuestas de alternativas de diseo. Diagrama de flujo de procesos de alto nivel. Diagrama de flujo de datos de alto nivel.

Para producir esta informacin se requiere del concurso del Gerente del Proyecto, quien es responsable por los estimados, estrategia de desarrollo, evaluacin de riesgos y clculo de costos, y de los Analistas de Sistemas y de Negocios, quienes modelan en detalle el alcance, objetivos, beneficios y proyectos dependientes, del proyecto en estudio. El desarrollo del Estudio de Factibilidad es un esfuerzo conjunto de los expertos en el negocio y de los tcnicos en sistemas. Es tambin importante involucrar a los Grupos clave y a grupos de especialistas (tales como Finanzas, Abastecimientos y Recursos Humanos), quienes ayudan a mejorar la calidad del estudio y a identificar a los usuarios futuros con el trabajo que se desarrollar. Modelando el alcance del proyecto Una de las reas que presentan un mayor reto en la planificacin del proyecto es la relacionada con su alcance.

Para muchas personas, alcance y objetivos son similares, cuando es ms til verlos como interrelacionados pero diferentes. El alcance de un proyecto define los lmites de responsabilidad del Gerente del Proyecto, mientras que el objetivo del proyecto define lo que el Gerente del Proyecto debe lograr dentro de esos lmites. Para el PMI, el alcance se define como el trabajo por realizar y los productos a obtener de un proyecto o componente del proyecto. El alcance se describe completamente definiendo todas las actividades a realizar, los recursos a consumir y el producto final resultante, incluyendo los estndares de calidad. En proyectos de sistemas de informacin, uno de los aspectos crticos est en establecer la diferencia, si existe, entre el alcance de los procesos automatizados y el alcance del proyecto (Fig. 2.3). Esto es especialmente crtico en grandes proyectos, donde los elementos del sistema que no estn computarizados pueden llegar a ser significativamente mayores que los computarizados.

Alcance del proyecto

Alcance del sistema computarizado

Fig . 2.3 A lcances del sistem com a putarizado y del proyecto

Figura 2.3 Alcances del proyecto y del sistema automatizado El alcance de los procesos automatizados puede ser definido grficamente utilizando tcnicas tales como diagrama de flujo de datos (DFD) y modelos de datos. Sin embargo, como ya se mencion, excepto para pequeos procesos automatizados, el alcance de la parte automatizada es un subconjunto del alcance del proyecto. Todos los sistemas de informacin impactan, en alguna forma, a la organizacin y a su personal. La implantacin exitosa de un nuevo sistema de informacin, o de las

mejoras a uno existente, requerir del rediseo o creacin de procedimientos, alteraciones de la planta fsica, definicin de nuevos roles en la organizacin y nuevos procesos de control gerencial y administrativo. Adicionalmente, los grandes proyectos pueden abarcar aspectos legales, gerencia financiera, un soporte administrativo mayor que incluya logstica de viajes y compras mayores, alquiler de espacios de trabajo, etc. Esos proyectos requieren de un nmero de actividades externas al sistema de informacin en s, que deben ser llevadas por expertos del negocio diferentes a los requeridos por el sistema. Es esencial que el alcance y los objetivos del proyecto reflejen explcitamente tanto los objetivos de la parte automatizada como de la parte manual del sistema de informacin. Es igualmente importante entender que los riesgos, tareas, estimados y requerimientos de calidad se desarrollan para el sistema integral. Involucrar a los representantes de los Niveles 3 y superior nos asegurar que estos asuntos son cubiertos adecuadamente en las sesiones RAP. En muchos proyectos, la parte no computarizada del sistema se encuentra en el camino crtico y se convierte en rea de alto riesgo. Una mecanismo muy til para establecer el alcance del proyecto es utilizar una modificacin de una tcnica desarrollada por Kepner y Tregoe (1981) para la definicin de problemas. Como se muestra en la figura 2.5, esta tcnica define lo que es del proyecto, lo que no es del proyecto y (al inicio del proyecto), lo que no se sabe si es. Por supuesto, cualquier rea desconocida necesita ser resuelta como materia de urgencia. Como se muestra en la figura 2.6, una vez que el Comit del Proyecto (y a veces hasta la Alta Gerencia) recibe el Business Case, debe decidir cundo proceder con el Paso 2 del proceso de planificacin del proyecto; la Planificacin Detallada del Proyecto y su subsecuente desarrollo. Es importante entender que la aprobacin de un proyecto es ms una decisin de negocios que una decisin tcnica.

Definicin del Alcance Proyecto: Automatizacin de la oficina Est en el alcance No est en el alcance Instalacin de estaciones Suplir las LANs de trabajo Diseo del entrenamiento Dar el entrenamiento

No se sabe Definicin de la interfaz del Usuario

Produccin de las guas Soporte al software del Usuario Figura 2.5 Modelo modificado de Kepner y Tregoe para definicin del Alcance Sobre los estimados iniciales Es problemtico justificar econmicamente los proyectos al inicio del estudio. Los anlisis de Costo/Beneficio y otras informaciones utilizadas para aprobar los proyectos son, en general, estimaciones gruesas que se van afinando a medida que el proyecto progresa. El Business Case debe ser constantemente actualizado y monitoreado para que siempre refleje la realidad actual del proyecto. Cualquier variacin importante de los elementos de control, tales como los costos y beneficios utilizados inicialmente para justificar el proyecto, deben ser remitida al Comit del Proyecto y/o al Ejecutivo del Proyecto.

R v io e d l C m d l Po e to e is n s e o it e r y c

Pe e t c nd l r s na i e B s e sC s u in s a e ET D D S U IO E F C IB ID D A T IL A (B S E SC S ) U IN S A E

P A IF A IO L N IC C N IN IA IC L

R V IO D LC M E E IS N E O IT (A r b c np r po a i a a po e e c ne r cdr o l E tu iod F c ilid d s d e a tib a )

P A IF A IO L N IC C N DT LA A EAL D A A IS D L S N L IS E O R Q IR IE T S E U IM N O P A IF A IO L N IC C N DT LA A EAL D D E OD L IS E S TM IS E A P A IF A IO L N IC C N DT LA A EAL D D S R OL D L EAR LO E SS E A I TM P A IF A IO L N IC C N DT LA A EAL D IN T L C ND L S A A IO E SS E A I TM B s e sC s u in s a e a r bd po a o R V IO E IS N P S -IM L N A IO OT PA T C N P A IF A IO L N IC C N DT LA A EAL D

R V IO D LC M E E IS N E O IT (A r b c np r po a i a a po e e a a isd r c d r l n lis e R q e i ie to oc n e u rm n s o e d s r o toa l e a r llo t l) R V IO D LC M E E IS N E O IT (A r b c np r po a i a a po e e c nla r cdr o s u n fs d ig ie te a e e d s roo e a r ll ) R V IO D LC M E E IS N E O IT (A r b c np r po a i a a po e e c nla r cdr o s u n fs d ig ie te a e e d s roo e a r ll )

B s e sC s u in s a e a r bd po a o

M I C R O P L A N I F I C A C I O N

R V IO D LC M E E IS N E O IT (A r b c np r po a i a a po e e c nla r cdr o s u n fs d ig ie te a e e d s roo e a r ll )

R V IO D LC M E E IS N E O IT (R v i d la e is n e c lm a i d l u in c n e po e t ya r b c n r y co po a i d mjoa in ia s e e r s ic le )

C N IN A D OT UNO C NL O A P A IF A IO L N IC C N D LD S R O L E EAR LO

Fig. 2.6 Inicio y desarrollo del proyecto

CAPITULO 3 PLANIFICACION DE PROYECTOS Al final del estudio de Factibilidad y previo al comienzo del ciclo de desarrollo, el Gerente del Proyecto y su Grupo de Trabajo deben dedicarse al segundo paso del proceso de planificacin: Una sesin de planificacin detallada del proyecto. La tcnica a utilizar para este trabajo es la de sesiones de Planificacin Rpida de Aplicaciones, RAP. La Figura 3.1 muestra los seis pasos del modelo, sistemticamente: que deben ser ejecutados

B s e sCs uins ae Ar b d po a o

Co o r m dlPo e t r n g a a e r y co y B s e sCs At aiz d uins ae cu l a o

P AI I AI N E P OE T L NFC CO D L R Y C O

R VSO EII N DL E B SN S UI E S CS AE

COORM R N GA A DL E P OE T R Y CO

Bs e s uin s Cs ae Rvs d eiao

Eti a o s md s d la e s Tr a ae s

S LCI N E E CO DL E A ET A E I S R T GA D E D S R OL EA R L O

E TMCO S I AI N D LS E A T RA AE S

Et a g sd sr te ia e d s r o od l ear ll e po e to r yc D S R OL R EA R L A L A E A U CO VL AI N D RE G E ISO D LS E A ET A E I S S R T GA

Tr a ae s

Rso ieg s Ea a o v lu d s

S LCI N E E CO D LS E A T RA AE S

Figura 3.1Planificacin Detallada del proyecto El plan resultante de la aplicacin del modelo es la base para el seguimiento y el reportaje del proyecto. La situacin actual del proceso, al nivel de tareas, es comparada con el progreso planificado y se solucionan las desviaciones mayores encontradas. En algunos casos, esto puede llevar a procesos de replanificacin. El Reporte de Progreso recopila informacin de todas las tareas del proyecto, para su revisin por el Comit del Proyecto y otros gerentes y usuarios que se vean afectados por el proyecto.

La planificacin es realizada al comienzo de cada proyecto y repetida regularmente durante la vida del proyecto va microplanificacin y sesiones RAP. Este el concepto de Gerencia de Proyectos en Tiempo Real que se aplica en la metodologa que se est definiendo. Dependiendo de la magnitud del proyecto, el Gerente del Proyecto o los Analistas de Negocios producen un plan inicial para el proyecto, mientras se completa el Business Case. La preparacin del cronograma y la planificacin detallada no se comienzan hasta el inicio de la etapa de Anlisis de Requerimientos de la primera fase del ciclo de desarrollo. Este enfoque de proyectos implica el desarrollo de una planificacin detallada y la produccin del cronograma respectivo al comienzo de cada fase y slo para esa fase. El plan general del proyecto ofrece informacin de todas las fases en una forma menos detallada y en muchos casos, se debe considerar esta informacin como una aproximacin a los tiempos y recursos requeridos por el proyecto. Slo hasta que se evalen las diferentes alternativas, el Gerente del Proyecto no puede precisar el Plan de Diseo de Sistemas y las fases subsecuentes. Paso 2: Planificacin Detallada del Proyecto Como se observa en la Figura 3.1, la planificacin detallada se realiza mediante 6 pasos interrelacionados e iterativos. Aunque estn dibujadas como procesos en serie, ellos son altamente iterativos y habr que realizarlos muchas veces antes de llegar a un plan aceptable. Por ejemplo, se pueden haber hecho muchas suposiciones sobre el personal que conformara el grupo de trabajo, mientras que al asignar el personal disponible a las tareas del proyecto, se observa que tienen habilidades y conocimientos diferentes (o en menor grado) a las previstas, requiriendo esto una revisin de los estimados iniciales. La planificacin del proyecto est basada en el desarrollo de sesiones con alta participacin del equipo, el Gerente del Proyecto, representantes de los Grupos clave y de otros proyectos relacionados, y de representantes de los grupos de soporte tcnico que interesan al proyecto. Tarea 1: Revisin del Business Case El primer proceso es la revisin del Business Case. Si el proyecto que est siendo planificado no tiene el Business Case, entonces se comenzar con la recopilacin de esta informacin (en particular, la evaluacin de los riesgos, objetivos, alcance y los modelos de sistemas de alto nivel). Para proyectos mayores, se debe realizar un Estudio de Factibilidad muy completo, involucrando para ello a Analistas de Negocios, Analistas de Sistemas y a los Clientes clave del proyecto. Tarea 2: Seleccin de la Estrategia de desarrollo.

Se debe distinguir entre la metodologa de desarrollo de sistemas y la estrategia de desarrollo. La estrategia maneja y define la manera en que el proceso total de desarrollo de sistemas se realizar, mientras que la metodologa se refiere a las tareas especficas que deben realizarse durante el ciclo de desarrollo de sistemas. La estrategia adecuada es altamente dependiente del riesgo y del tamao del proyecto. Se pueden definir cuatro estrategias bsicas de desarrollo:

Monoltica: Define al desarrollo del sistema como un todo, con cada fase como una actividad independiente y predecesora de las siguientes. Por ejemplo, el diseo no se comienza hasta que el anlisis est completado. Esta estrategia es recomendable para proyectos de bajo riesgo o cortos (menos de 6 meses) y para grupos de trabajo pequeos (menos de 5 personas). Versiones: Esto implica dividir el sistema en subsistemas semi-independientes y producir un subsistema completamente operacional (o un producto totalmente terminado) como Versin 1; luego se aade un segundo subsistema como Versin 2, etc. El usuario podr obtener componentes semi-operacionales del sistema por adelantado. Por ejemplo, la Versin 1 podra incluir todos los componentes de la entrada de datos que crean las bases de datos activas del sistema. Mientras la Versin 2, que se encarga de los componentes de salida est siendo desarrollada, los usuarios pueden accesar los datos mediante queries. En la Versin 3, todas las facilidades de base de datos podran ponerse a disposicin de los usuarios. Esto es llamado Versiones Secuenciales. Alternativamente, el grupo de proyecto puede dividirse en subgrupos, cada uno de los cuales produce un subsistema en paralelo o de forma concurrente. En este caso se llama Versiones Concurrentes. Desarrollo Acelerado: Esto involucra la produccin de prototipos tan rpido como sea posible. Esto puede ser logrado minimizando la adherencia a los estndares y/o utilizando lenguajes de alto nivel o generadores de aplicaciones. El primer prototipo operacional ser optimizado a travs de una serie de modificaciones. Claramente, sta es una estrategia de alto riesgo y requiere de profundas negociaciones y alto involucramiento de la gerencia y los usuarios del sistema.

Hbrido: Es una modificacin de la estrategia de Versiones Concurrentes. La estrategia hbrida consiste de una serie de versiones o subproyectos, con cada uno de ellos utilizando una estrategia diferente de desarrollo. Por ejemplo, un subproyecto de alto riesgo puede ser desarrollado utilizando la estrategia de desarrollo acelerado, mientras que uno de bajo riesgo se desarrollara utilizando la estrategia monoltica.

El siguiente cuadro ofrece lineamientos para la seleccin apropiada de la estrategia:

Duracin del Proyecto Menos de 3 meses

Riesgo Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto

Estrategia Monoltico Versiones Desarrollo Acelerado Monoltico o por Versiones Versiones Versiones o Acelerado Versiones Versiones Hbrido o Acelerado

3 - 6 meses

Ms de 6 meses

Generalmente, cuando se manejan grupos de proyecto mayores a 5-7 personas, se recomienda el uso de las estrategias de Versiones o Hbrida. La Figura 3.2 muestra las diferencias entre las diferentes estrategias y como se ver el cronograma del proyecto dependiendo de qu estrategia de desarrollo se adopte.
ESTRA TEG M OLITIC IA ON A

FASE A

FASE B

FASE C

FASE D

ESTRA TEG DE VERSION SECUENCIALES IA ES

Versin 1 FASE A FASE A FASE B FASE C FASE D FASE A Versin 2 FASE B FASE C FASE D

ESTRA TEG DE VERSION CO UR IA ES NC RENTES

Versin 1 FASE A FASE A FASE B FASE C FASE D

Versin 2 FASE A FASE B FASE C FASE D

ESTRA TEG DE VERSION AC IA ES ELERADAS

Versin 1 FASE A FASE B FASE C FASE D EVA LUACION FASE A Versin 2 FASE B FASE C FASE D

ESTRA TEGIA HIBRIDA

Versin 1 FASE A FASE A FASE B FASE C

M onoltica FASE D Concurrente Versin 2 2.1 2.2 FASE A FASE A FASE B FASE B FASE C FASE C FASE D FASE D

Figura 3.2 Estrategias de Desarrollo

Se debe tener presente que, para muchos proyectos, la estrategia puede variar para las diferentes etapas del desarrollo del proyecto. Por ejemplo, el proyecto puede tener una fase de Anlisis de Requerimientos de alto riesgo que requiere del uso de una estrategia acelerada (lo que pudiera incluir el desarrollo de pantallas de prototipo, etc.). Sin embargo, una vez que los requerimientos del cliente han sido determinados, el proyecto puede moverse a una estrategia de bajo riesgo para el diseo, el desarrollo y la implantacin, por lo que pudiera adoptar una estrategia ms conservadora, tal como Versiones Secuenciales o Monolticas. Si tuviese que elegirse una estrategia Hbrida o de Versiones, el sistema se podra empaquetar en versiones en tres puntos clave: Al final del Estudio del Business Case. Al final de Anlisis Detallado de Requerimientos. Al final del Diseo de Sistemas.

Se debe enfatizar que previo a la particin del sistema en subsistemas, el Gerente del Proyecto y su Grupo, deben desarrollar una representacin del sistema (DFD, Cartas Estructuradas, DFP) con suficiente detalle como para poder asegurar una mnima interdependencia de datos. Mientras ms temprano se quiera dividir el sistema, ms riesgos se tendr de que los subsistemas no se puedan separar limpiamente. Esto se hace para poder asegurar que cada versin pueda ser tratada como un subsistema virtualmente independiente. Para realizar esta particin se debe contar activamente con el Administrador de Datos o el Supervisor de Recursos de Informacin durante la etapa de planificacin del proyecto. Adicionalmente, al estar desarrollndose concurrentemente mltiples versiones, se hace imprescindible hacer el seguimiento de los cambios a las versiones bajo desarrollo. Ya que existen datos que enlazan a los subsistemas, es esencial que estos datos comunes sean administrados en conjunto para asegurar que cualquier modificacin o alteracin realizada por un subsistema a los datos comunes, sea del conocimiento de los otros. El uso formal de la disciplina de Control de Cambios es particularmente importante para esta estrategia. Similar preocupacin debe tenerse sobre las funciones de negocios comunes que deben ser compartidas entre los subsistemas. Acerca del Desarrollo Rpido de Aplicaciones (RAD) Las estrategias de Versiones y de Desarrollo Acelerado son totalmente apoyadas por los CASE, que ayudan en las actividades de almacenamiento y mantenimiento de los productos clave del proyecto tales como modelos de datos, diagramas de flujo de datos, diagramas de diseo estructurado, diseo de los archivos, especificaciones de programas, etc. El proceso de particin de los sistemas en pequeas versiones, que son luego desarrolladas utilizando estrategias secuenciales o concurrentes, ha sido denominado como Desarrollo Rpido de Aplicaciones. Algunas versiones de esta estrategia sugieren la particin del sistema en versiones que pueden ser desarrolladas e implantadas en un trmino de 90 a 120 das.

Tarea 3: Desarrollo de la Evaluacin de Riesgos. La Evaluacin de Riesgos normalmente se realiza durante el desarrollo del Business Case y es revisada y actualizada durante cada proceso de planificacin por el Grupo de Proyecto. La Evaluacin de Riesgos es una medida subjetiva de las probabilidades de xito del proyecto. Tiene un impacto directo en el estilo de gerencia a aplicar, la composicin del Grupo de Proyecto, el uso de la metodologa, las estrategias para el desarrollo del sistema, y sobre todo, sobre la decisin de la Organizacin de aprobar el proyecto. En otras palabras, a mayores riesgos en el proyecto, es ms grande la probabilidad de que los estimados, los cronogramas y la planificacin sean incorrectos y que el proyecto se salga de control. El riesgo de un proyecto puede ser establecido tomando en cuenta los siguientes criterios: Complejidad del sistema o sus productos. Ambiente de los Usuarios clave. Ambiente del Grupo de Proyecto. Complejidad del sistema Para evaluar la complejidad del sistema y los riesgos del proyecto de software, se tomar como una medida la tcnica de Puntos Funcin de la IBM y se considerar la complejidad de sus datos, es decir, cuntas entradas, salidas, consultas, archivos lgicos internos y archivos compartidos estn involucrados en el sistema. Otros aspectos que tambin afectan la complejidad o el riesgo son: Funciones y algoritmos. Controles complejos, decisiones por excepcin, y/o operaciones matemticas. Procedimientos actuales. Impacto significante en los puestos de trabajo. Requerimientos de comportamiento. Grandes volmenes de datos, tiempos de respuesta rpidos para minimizar el uso de la red, CPU, etc. Requerimientos especiales de tecnologa. Uso intensivo de Hardware y/o Software especialmente diseados para el sistema. Ambiente de los Usuarios clave La complejidad o riesgo de los Usuarios clave est relacionada con las siguientes reas:

 El nmero de sitios donde opera el usuario (secciones, departamentos, agencias, sucursales y otras instalaciones) y que estn afectados por el sistema. El nivel de conocimientos y la actitud de participacin de los usuarios durante los diferentes procesos del proyecto. La prioridad y el impacto del sistema dentro del rea del usuario. Las necesidades de reacondicionamiento fsico de las oficinas, el desarrollo de nuevos sitios, etc. Ambiente del Grupo de Proyecto La complejidad o el riesgo del ambiente del Grupo del Proyecto est relacionado con las siguientes reas: Cronogramas, en cuanto a su rigidez o flexibilidad. La experiencia y estabilidad del Grupo. El tiempo total estimado para el proyecto. El uso de contratistas y proveedores. El ambiente fsico para el Grupo de Proyecto.

Es obligatorio que el Gerente del Proyecto considere todos estos criterios de riesgos a travs de los diferentes procesos del proyecto, y especialmente durante la planificacin, utilizando el cuestionario formal contenido en el Captulo dedicado a desarrollar el Modelo de Evaluacin de Riesgos. Si el Gerente del Proyecto considera que la combinacin de algunos de esos factores contribuye significativamente con el nivel de riesgos del proyecto, debe considerar alguna de las siguientes acciones: Dar los pasos para limitar el alcance del proyecto y reducir su complejidad. Documentar las reas de complejidad en el plan del proyecto y buscar tiempo o recursos adicionales para minimizar el riesgo. Preparar un Memorndum Formal de Riesgos que detalle los factores de alto nivel de riesgos, identifique su posible impacto y recomiende las acciones y opciones disponibles para reducir el impacto o el factor de riesgo. Es importante que el manejo de los factores de riesgo sea tomado como un proceso proactivo. Por ejemplo, previo al inicio del ciclo de desarrollo, el Gerente del Proyecto debe realizar negociaciones con el Comit del Proyecto, los Grupos clave y el Ejecutivo Promotor del proyecto con el objeto de minimizar el factor de riesgos. Acerca de las Mtricas de Software La evaluacin de riesgos que se ha definido es subjetiva. El proceso de cuantificar los diferentes factores de riesgo se define como Mtrica de Software. Por ejemplo, la experiencia indica que existe una diferencia notable entre un programador inexperto y

otro con experiencia. Luego, al usar un modelo subjetivo, un proyecto con programadores sin experiencia implicara riesgos mayores que con los experimentados (manteniendo todas las dems variables iguales). Aunque se han realizado muchos intentos por cuantificar estas medidas de experiencia, los resultados obtenidos no permiten llegar a una conclusin nica: diferentes autores del rea han presentado trabajos donde la relacin de productividad vara desde una de 26:1, otra de 10:1 hasta una tan pequea como 2:1. Definitivamente esto es un problema. Se han estimado ms de 100 factores que influyen significativamente en la productividad y en el riesgo de un proyecto y muchos de ellos son, para todos los propsitos prcticos, inconmensurables (por ejemplo, cul es el impacto cuantificado de las polticas de una organizacin entre dos grupos de Clientes clave?). Como se observa, el rea de mtricas de software es bastante imperfecto. Sin embargo, el uso ms efectivo de las mtricas de software es utilizar las que estn disponibles para apoyar los criterios subjetivos de la evaluacin de riesgo y as, ajustar los estimados siempre que sea posible. Tarea 4: Seleccin de las tareas. Para el desarrollo de los sistemas, las fases del proyecto son divididas en tareas y stas a su vez se subdividen en sub-tareas (Figura 3.3). Aunque el proceso de identificacin de las tareas requeridas para un proyecto es conceptualmente simple, el detalle y la calidad del resultado son vitales ya que ello constituye la base para la estimacin de abajo hacia arriba y la obtencin final de un cronograma detallado del proyecto. Con el tiempo, las organizaciones van desarrollando cronogramas estndares para los diferentes tipos de proyectos, tales como desarrollos internos, seleccin de paquetes, etc. Dependiendo del riesgo y naturaleza del proyecto, se deben combinar, eliminar, o aadir tareas y subtareas de los estndares ya desarrollados. Por ejemplo, se puede requerir aadir tareas para una seleccin de hardware, y no necesitarse las tareas relacionadas con base de datos. Esta adaptacin la realiza el Gerente del Proyecto junto con especialistas de las reas de inters requeridas por el proyecto. En caso de no existir los estndares, o si el proyecto bajo estudio no se adapta a los existentes, el grupo de planificacin debe realizar sesiones especiales para obtener la lista detallada de las tareas que representarn posteriormente al proyecto. Idealmente, las actividades de una fase del proyecto (tareas, subtareas) no deben tener una duracin de ms de 10 das calendario. Esto no debe confundirse con la cantidad de trabajo que se realizar en ese perodo ya que, por ejemplo, una tarea podra requerir de 2 personas por 15 das, lo que nos dara 30 das de esfuerzo de trabajo. Cuando una tarea excede de los 10 das, se la debe separar en tareas ms pequeas. Se debe reconocer que esto no siempre es posible. El objetivo principal de separar en tareas es, como ya se ha dicho, separar las fases en partes que sean mensurables y manejables.

El proceso de separacin del proyecto en tareas es clave para la estimacin, ya que asegura que el equipo de trabajo entiende la magnitud del trabajo que debe ser hecho. Una de las causas ms comunes de concluir con unas estimaciones de baja calidad es el hecho de fallar al listar todas las tareas requeridas. En las sesiones RAP, el uso de expertos y la participacin integral del equipo de trabajo y los Usuarios clave usualmente conducen a lograr una lista exhaustiva y precisa de las tareas requeridas.

Examinar documentacin del paquete Contactar a usuarios del paquete Preparar los datos de prueba Evaluar el paquete Auditar al proveedor del paquete Visitar a usuarios del paquete Probar el paquete Verificar los acuerdos de servicio Verificar la informacin econmica-financiera

Figura 3.3 Divisin del trabajo para su control Macro-estimado (75) Proyecto A Fase 1, (15) Micro-estimado Fase 1 (15) Fase 2 Fases 2 + 3 (61)

Obtenido utilizando Punto funcin

Obtenido utilizando porcentajes

(38)

Fase 3

(23)

Tarea A (5) Tarea B (6) Tarea C (4) Obtenidos utilizando estimados basados en las tareas

(20 %) Micro-estimado

(50 %)

(30 %)

Figura 3.4 Macro y Micro-tcnicas de estimacin

Tarea 5: Estimacin de las tareas Existen actualmente varias tcnicas de estimacin, entre las cuales destaca la macrotcnica de Punto Funcin, con la cual se puede lograr un estimado para el esfuerzo de desarrollo total del proyecto y luego, con microtcnicas tales como bottomup o basadas en las tareas individuales, ir ensamblando los tiempos hasta lograr llegar a la fase completa. La microtcnica se requiere para poder desarrollar el cronograma del proyecto. Como se muestra en la figura 3.4, el enfoque tpico es el de un estimado inicial usando Punto Funcin y luego usar ste para correlacionarlo con un segundo estimado desarrollado bottom-up va una microtcnica tal como Wide-Band Delphi (Ver Captulo 9). Los estimados a nivel de tareas son agregados para lograr un estimado de la fase el cual, de existir una metodologa estndar, puede ser usado para derivar otro valor del esfuerzo total de desarrollo utilizando el porcentaje de cada fase como una gua. Estimando el esfuerzo de la tarea Para cada tarea/subtarea en cada fase del proyecto, El Gerente del Proyecto y su grupo de trabajo deben producir un estimado del esfuerzo que se requiere y de los das necesarios para realizarla. Con el tiempo, las organizaciones cuentan con metodologas maduras que incluyen el registrar y mantener informacin sobre nombres comunes de tareas y sus duraciones provenientes de todos los proyectos, lo que servir de gua para saber el tiempo y los recursos que consumen las tareas en proyectos similares. Con esto se obtiene la base de datos de mtricas de los proyectos. Mientras no se cuente con esta base de datos, se sugiere las siguientes guas: Mientras ms pequeas y especficas sean las tareas/subtareas de una actividad, ms fcil ser obtener sus estimados. Mientras mayor sea el riesgo de un proyecto, sern mayores las posibilidades de errores de estimacin. Los estimados realizados por un grupo, por ejemplo durante las sesiones de definicin de las tareas, deben ser obtenidos promediando los estimados de cada uno de los miembros para cada tarea/subtarea, utilizando tcnicas como la WideBand Delphi. Realice los estimados asumiendo que el trabajo lo realiza una sola persona, y calcule el esfuerzo de trabajo en das-hombre y no en duracin. El traslado de dashombre a das calendario y la distribucin de los recursos disponibles se har durante la construccin de los cronogramas.

Es esencial definir los estimados como un rango y no un nmero nico, especialmente durante las fases iniciales del desarrollo del proyecto. El uso de tcnicas de anlisis de sensibilidad ser de gran utilidad para lograr los mejores valores para el proyecto. Esta tcnica involucra la obtencin de estimados de tres categoras:

 Valor optimista/el mejor caso. Valor realista/ms probable. Valor pesimista/el peor caso. El valor optimista se logra suponiendo que todo marcha sobre ruedas. El realista refleja la situacin ms probable y en general la experiencia de trabajo de cada elemento del grupo, y la pesimista supone que lo que podra salir mal, suceder. Luego, basados en las estimaciones de riesgo, el Gerente del Proyecto debe seleccionar una de esas cifras como la base para desarrollar su cronograma. Para proyectos de bajo riesgo se utilizaran los estimados optimistas o realistas. A medida que el proyecto presenta ms riesgos, se debe ir pasando de los estimados realistas a los pesimistas. Sin embargo, el conjunto de los tres estimados debe incluirse en el archivo del proyecto. En muchos casos, el estimado realista es el ms adecuado para los cronogramas; sin embargo, ciertas tareas pueden tener un riesgo mayor que otras y pueden requerir de los estimados pesimistas. En otras palabras, realizando un estimado informal de riesgos de cada tarea, las de bajo riesgo deben planificarse utilizando los estimados optimistas, las de riesgo medio utilizarn el estimado realista, y las de alto riesgo se programan usando los estimados pesimistas. Una alternativa es utilizar las tres cifras para lograr un valor esperado nico, mediante la siguiente ecuacin: Valor esperado = [Optimista + (4 x Realista) + Pesimista] / 6 Estimando el esfuerzo y la duracin de las tareas Una de las causas que ms influyen en una mala estimacin tiene que ver con la diferencia entre el trabajo o esfuerzo directo (horas-hombre) y la duracin calendario requerida para realizar el trabajo. El proceso de estimacin implica comenzar por calcular el esfuerzo de trabajo para luego llegar a la duracin calendario requerida para realizar dicho trabajo. Por ejemplo, un proceso puede haber sido estimado en cuatro horas-hombre de esfuerzo pero requerir de dos das calendario para su ejecucin debido a las caractersticas del trabajo y a la disponibilidad de recursos existentes. El Gerente del Proyecto debe tener muy en cuenta esta diferencia entre el esfuerzo de trabajo (ET) y la duracin calendario (DC). Entre las razones tpicas que marcan la diferencia entre el esfuerzo y la duracin estn: Reparacin de defectos en tareas predecesoras completadas con anterioridad. Das no laborables. Asesoras a otros grupos de trabajo. Actividades administrativas extra proyecto. Entrenamiento extra proyecto. Reuniones extra proyecto.

Interrupciones, incluyendo el telfono. Preparacin de Informes extra proyecto. Tiempos de espera para iniciar reuniones u obtener resultados planificados. Switch time, esto es, el tiempo requerido para pasar de una a otra actividad.

No es raro encontrar que estos factores en conjunto representan de un 30% a un 50% de la capacidad de trabajo diaria de cada persona. As, es aceptable encontrar una DC de dos o tres das por cada da de ET, dependiendo de cada proyecto en particular y del ambiente administrativo de la organizacin en general. Adems, la cantidad de tiempo perdido vara con el nivel de la persona que realiza el trabajo. Por ejemplo, un 30% de prdida es tpico en el caso de Analistas y Programadores Junior, mientras que se consiguen cifras de prdida de un 50% o superior cuando se trata de Analistas Senior o Lderes de Proyecto que dedican ms tiempo a entrevistas, administracin, reuniones, asesora al personal Junior del equipo y a actividades extra proyecto. Tarea 6: Cronograma del proyecto Esta actividad es realizada durante las sesiones RAP e involucra la asignacin de recursos a cada tarea identificada para el proyecto, para as producir el cronograma formal del proyecto. Esta actividad puede ser complicada, debido a las alternativas que se presentan para realizar la secuencia de las tareas y la asignacin de recursos. Por ejemplo, las tareas pueden ser programadas linealmente o concurrentemente dependiendo de la disponibilidad de recursos y de la interrelacin entre las tareas. Cuando se requiere de recursos externos al grupo de proyecto, tales como personal del rea usuaria (o cliente) o de operaciones, el Gerente del Proyecto deber negociar con las reas de inters para obtener las personas requeridas en la oportunidad y por el tiempo que se necesite. Idealmente, los representantes de las reas de inters estarn presentes en las sesiones RAP y llegarn a acuerdos con el Gerente del Proyecto para asignar los recursos clave en las condiciones exigidas por el proyecto. La forma de realizar este proceso es: Dibujar en papel tipo rotafolio o en una pizarra blanca, una primera versin del diagrama de red mostrando aquellas tareas que tienen dependencias y las que se pueden realizar concurrentemente (ver Figura 3.5). Esta red est basada en una dependencia de los productos de una tarea que son requeridos para que se inicie la siguiente tarea. Para cada tarea en la red, y manteniendo su orden cronolgico de ejecucin, asignarle las personas requeridas. Se debe tener en cuenta en esta actividad que: Algunas tareas necesitan de habilidades especiales o de un entrenamiento especfico para la persona asignada. Las tareas que dependen de la finalizacin de una tarea previa, no pueden ser programadas para preceder o solapar dichas tareas.

 Las previsiones que se han hecho para eventos tales como entrenamiento durante el proyecto, permisos para actividades personales programadas (matrimonio, vacaciones, operaciones), sobretiempo, deben ser revisados cuando se asignan los recursos, en caso de las tareas donde trabajarn varias personas. De ser necesario, se extender la duracin probable de la tarea para tomar en cuenta estos eventos. Se deben tomar las previsiones de recursos necesarias para minimizar el sobretiempo en aquellas tareas que consistentemente lo requieran; se deben hacer previsiones para disponer de una cantidad razonable de seguro en la construccin de la red. Se deben hacer las previsiones para tomar en cuenta el tiempo requerido para las actividades de aseguramiento de la calidad en cada tarea (aproximadamente un 10 % de esfuerzo adicional). En algunas oportunidades, se hacen ciertas suposiciones durante las etapas iniciales de estimacin acerca de las habilidades y conocimientos de un recurso, tales como la de contar con un Analista Senior con mucha experiencia en el diseo de bases de datos. Si al momento de asignar el personal a las tareas no se cuenta con el recurso tal como se estim, es necesario revisar los tiempos y ver el impacto del cambio. Hay que tener precaucin cuando se asignan tareas concurrentes a la misma persona. Si es necesario hacerlo, es preferible extender el tiempo para tomar en cuenta el tiempo de switch entre tareas. Cuando los recursos para realizar una tarea son provistos de una fuente diferente al grupo del proyecto, la duracin probable de la misma es slo un estimado que necesitar ser revisado posteriormente, una vez que se conozcan las caractersticas de las personas asignadas. El Gerente del Proyecto slo debe asignarse tareas de naturaleza administrativa o que puedan ser realizadas sin detrimento de su actividad como gerente. Cuando se ha culminado la actividad de asignar recursos y tiempos (das calendario) a todas las tareas, se debe hacer una nueva revisin para asegurarse que estn reflejadas todas las interdependencias y que en el caso de tareas que comparten recursos, las personas asignadas realmente estn en capacidad de hacer el trabajo concurrentemente. A este nivel del trabajo, se deben introducir los datos de la red en un sistema de control de proyectos automatizado (por ejemplo el Microsoft Project) para depurar la red y calcular el camino crtico para el proyecto. Este camino crtico produce el tiempo mximo de duracin (das calendario) del proyecto y por ende, la trayectoria ms larga a travs de la red. Por ejemplo, en la Figura 3.5, la Tarea D depende de las Tareas B y C. Si la Tarea B toma 4 das y la Tarea C se estima en 3 das, lo ms temprano que la Tarea D puede comenzar es 4 das despus que termine la Tarea A. La Tarea C tiene 1 da de holgura y la Tarea B est en el camino crtico. De requerirse, el Gerente del Proyecto y su grupo de proyecto pueden reprogramar las tareas y los recursos para reducir o minimizar las actividades con holgura y el cronograma total. El software de planificacin de proyectos tambin produce una Carta Gantt (Figura 3.5). Esta carta muestra la duracin de las tareas vs. la lnea de tiempo e indica

aquellas que estn en el camino crtico y las que tienen holgura. Asimismo, muestra los recursos asignados por tareas, una lista de tareas por recurso, carga de trabajo de los recursos, y otras informaciones importantes para la planificacin y seguimiento del proyecto. Toda esta informacin ser usada como base para preparar el reporte de avance de los proyectos. Estos paquetes de software son un ejemplo clsico de lo que conocemos como si entra basura, sale basura. Si el proceso de planificacin es realizado con informacin irreal, los cronogramas resultantes son falsos y su uso puede resultar peligroso para el proyecto. Una revisin a la Planificacin en Tiempo - Real El enfoque de tiempo real para la planificacin implica la repeticin del proceso de planificacin a lo largo del proyecto. Adicionalmente, en caso de salirse de control el proyecto, se necesitar realizar nuevamente el ciclo de planificacin integral. Es muy importante planificar slo aquellas tareas/fases que razonablemente se pueden incluir en un cronograma. El disponer de un paquete de software de planificacin hace de la reprogramacin una tarea sencilla, por lo que no tiene mucho significado programar inicialmente con alta precisin, en cuanto a su duracin, aquellas tareas que, por ejemplo, dependen de que otras 20 tareas culminen en tiempo para ella arrancar. Adicionalmente, la duracin de las tareas est en das calendario, lo que hace menos probable que a mediano plazo, las fechas definidas se logren al 100 %. Sencillamente, realice la programacin detallada slo para un perodo de 3 a 6 meses o hasta el final de la fase actualmente en ejecucin. El resto de las tareas deben ser sumarizadas a nivel de fase y pasar al detalle en sesiones posteriores de planificacin.

TAREA A

TAREA B

TAREA D

TAREA F

TAREA G

Dependencia

TAREA C

TAREA E

TAREA A

TAREA F

TAREA B TAREA C

TAREA D

TAREA G

TAREA E

HOLG

Holgura

Figura 3.5 Carta Gantt / Cronograma

CAPITULO 4 SEGUIMIENTO Y REVISION DE LOS PROYECTOS Paso 3: Seguimiento del Proyecto El seguimiento del proyecto tiene un objetivo clave: Determinar si est bajo control, esto es, cumpliendo con los acuerdos logrados en cuanto a fechas, calidad, costo, etc., o fuera de control. En cuanto el proyecto est fuera de control, inmediatamente hay que replanificarlo, lo cual incluye renegociar el Business Case y las especificaciones tcnicas. El proceso de seguimiento se realiza combinando procedimientos formales de seguimiento con reuniones regulares del Equipo del Proyecto. El objetivo inicial del seguimiento del proyecto es la revisin de la situacin del Business Case para determinar cualquier variacin actual o potencial. En caso de detectarse alguna variacin, en particular sobre el alcance, objetivos o calidad, sta debe ser formalizada a travs del mecanismo de Control de Cambios. De no haber cambios mayores en el Business Case, un objetivo secundario es la comparacin, en un momento cualquiera, de la cantidad de tareas completadas vs. las que estaban planificadas para completarse. Por tanto, el seguimiento del proyecto depende del seguimiento de las tareas que lo componen. Mientras que el seguimiento de las tareas es responsabilidad de cada uno de los miembros del grupo del proyecto, el seguimiento del proyecto es realizado por el Gerente del Proyecto basado en los recursos puestos a su disposicin y a su efectividad para cumplir con el plan del proyecto aprobado. Para el propsito tanto del proyecto como de cada tarea individual, las tareas deben ser tomadas como terminadas o no terminadas; los trminos casi completa o culminada en un x %, no son aceptados como medida de avance de una tarea. Este enfoque simplifica el seguimiento del proyecto y elimina el sndrome del 90% completado tan comn en el medio. Esta tcnica se conoce como del 0/100 %. Aunque normalmente el seguimiento del proyecto se hace con una frecuencia quincenal, se debe hacer nfasis en que, tan pronto como los miembros del Equipo del Proyecto o algn Usuario de los Grupos Clave crean que no se va a cumplir con la fecha de entrega de una tarea, esto es, que est fuera de control, deben notificar al Gerente del Proyecto para que se tomen los correctivos necesarios. Esto es vital para las tareas que estn en el camino crtico; para las otras, se requiere actuar cuando el impacto de los cambios exceda la holgura de la tarea. El producto Microsoft Project ser utilizado para el seguimiento del proyecto. Se definirn varios reportes del portafolio que trae el paquete para ser presentados semanal o quincenalmente y mensualmente. Paso 4: Informe del Proyecto

La informacin esencial que debe ser enviada al Comit del Proyecto, a los Ejecutivos del rea de Sistemas y a las Gerencias Usuarias clave, comprende los siguientes tpicos: El estado del proyecto: Se mantiene o no de acuerdo con lo planificado? Si no: 1. Cul es la situacin fuera de control y las causas de la variacin? 2. Qu acciones ha tomado el Equipo del Proyecto para resolver los problemas presentados? 3. Existen escenarios alternativos disponibles? 4. Qu acciones puede tomar la Alta Gerencia? El Archivo del Proyecto actualizado. Un resumen de los costos totales del proyecto a la fecha. Reporte de situacin del proyecto. Es uno de los mecanismos que tiene el Gerente del Proyecto para comunicarse con todos los niveles de gerencia y con el Equipo del Proyecto. Indica el esfuerzo y el progreso actual vs. lo planificado. Presta mucha atencin a las fechas de los hitos clave del proyecto. Las Figuras 4.1 y 4.2 ilustran los Reportes de Situacin quincenales y mensuales del proyecto.
R P RES M N L EOT E AA
N mr d lC n : o b e e lie te N m r d l P y co o b e e ro e t : G r ned l P y co e e t e ro e t : S m n q ete m ae e a a u r in l: L g o (e tep r d ) o r s s e o o: Pg a in d e

C d od l Po e to ig e r y c : Fc a eh:

P n a op r n c m le d ( s p r d ): la ific d e o o o p ta o e te e o o

R a a op r n p n a o( sep r d ) e liz d e o o la ific d e t e o o

O jeiv s ( ig ie tep r d ): b t o s u n e o o

Po le a / a v rt n ia : r b ms d e e c s

Figura 4.1Reporte semanal de situacin

R P REMN U L EOT ESA

N mr d l C n : o be e lie te N m r d l Po e t : o be e r y co G r ned l Po e t : e e t e r y co M sr p r d : e e ota o L go ( sep r d ) o r s e t e o o: Pg a in d e

C d od l Po e to ig e r y c : Fc a eh:

P n ic d p r n c m lea o( sep r d ): la if a o e o o o p t d e t e o o

R a a op r n p n a o( sep r d ) e liz d eo o la ific d e t e o o

O jeiv s ( ig ie tep r d ): b t o s u n e o o

Po le a / a v r e c s r b ms d e t n ia :

Figura 4.2 Reporte mensual de situacin Control de Cambios en el proyecto. Como ya se ha mencionado, es inevitable que se presenten situaciones que obliguen a ejecutar cambios antes de que se haga la implantacin del sistema. Sin la existencia de un riguroso proceso de negociacin que evale el cambio y su impacto, es posible que el Business Case y su plan de proyecto asociado desemboquen en una situacin tal que haga necesaria una reprogramacin drstica de un grupo de tareas o del proyecto completo. En este contexto, los cambios pueden ser internos o externos:

Internos, cuando surgen durante el desarrollo del proyecto por interpretaciones erradas de los requerimientos, errores de principio, errores de estimacin, cambio de los miembros del Equipo del Proyecto, lgicas incorrectas, o aspectos tcnicos que no pudieron ser previstos durante la planificacin inicial del proyecto. Externos, cuando se originan por decisiones polticas de los Usuarios Clave, por descuido o falta de involucramiento en los procesos de definicin del proyecto, por nuevas ideas, por requerimientos de otros proyectos o, lo ms probable, por no

poderse realizar ciertas tareas dentro del contexto de las especificaciones originales del sistema. El control de cambios implica tres pasos: Solicitud del cambio, su evaluacin y la decisin.

Solicitud de cambio. Debe venir por escrito en el formato diseado para tal fin, independientemente de dnde se origine (ver Figura 4.3); de no cumplirse con esto, se perder el control del proyecto. El formato debe ser llenado en su totalidad y entregado al Gerente del Proyecto. El proceso de solicitud de cambio asegura la existencia de un foro para introducir modificaciones durante el curso del proyecto, y el manejo de estos cambios para asegurar que sean logrados los objetivos globales del proyecto. Cada solicitud es evaluada, revisada, programada o descartada por el Gerente del Proyecto y su Equipo del Proyecto. Las solicitudes de cambio que afecten o alteren el programa, alcance o costos del proyecto, deben ser aprobadas por el Comit del Proyecto o por niveles superiores de la organizacin.

R Q E IM N OD C M IO E U R IE T E A B S A P OE T L R Y CO
N mr d lC n : o be e lie te N m r d l Po e t : o be e r y co G r ned l Po e t : e e t e r y co N m r d l R q e im n : o be e e u r ie to M tiv d l C m io- Pe a a op r o o e a b r p r d o: N mr d l R q e im no e o e e u r ie t : C d od l Po e to ig e r y c : Fc a eh:

D s r c nd l C m io- Pe a a op r e c ip io e a b r p r d o:

C s d l C m io Pe a a o p r o to e a b - r p r d o:

Ine r la io e : t re c ns

A r b d (A R c a a o (R po a o ) e h z d ) P r e C n ais : o l o tr t ta N mr : o be F m: ir a Fc a eh: P re C n : o l lie te N mr : o be F m: ir a Fc a eh:

Figura 4.3 Solicitud de Cambio

Un Registro de Solicitud de Cambio, presentado en la Figura 4.4, se utiliza para llevar un seguimiento del estado de las solicitudes. Contiene un asiento de una lnea por cada Solicitud de Cambio. El mismo provee al Comit del Proyecto y al Gerente del Proyecto con una referencia rpida de la situacin de los cambios. Se utilizan tres cdigos para indicar la situacin del cambio: Aprobado indica que el cambio ha sido aprobado; Pendiente indica que el cambio est siendo evaluado; y Rechazado indica que el cambio no fue aceptado y que no se tomar ninguna accin adicional con respecto a esa solicitud. Evaluacin. El Gerente del Proyecto, junto con el Equipo del Proyecto y posiblemente otros expertos, evaluarn el cambio. Esto se realiza normalmente mediante una sesin de RAP. La evaluacin debe cubrir puntos tales como: Se justifica realmente el cambio? De ser as: Es esencial que sea realizado en este momento, o podra ser diferido hasta la fase de Revisin de Post-Implantacin, al final del proyecto? El cambio altera el Business Case del proyecto? Qu tareas (completadas, en progreso o por comenzar) se afectan? Cul es la duracin estimada y el esfuerzo requerido para implementar el cambio? Se requerir de una reprogramacin del proyecto y/o una extensin del tiempo de culminacin del proyecto? Se requerirn recursos adicionales para implantar el cambio? El cambio afecta a otros proyectos, subproyectos o sistemas? El cambio requiere de una alteracin de la estrategia de desarrollo del proyecto? El cambio altera la complejidad o el riesgo del proyecto? Qu riesgos se presentan, tanto si se implementa como si no se implementa el cambio?

Los resultados de la evaluacin y del anlisis de impacto deben ser anexados a la forma de solicitud de cambio.

Decisin. Asumiendo que el Gerente del Proyecto no tiene dudas sobre la implantacin del cambio en este momento y bajo el supuesto de que no se requiere de recursos adicionales, que no se altera la complejidad, que no cambia el Business Case, y/o la extensin del proyecto, el cambio puede ser aceptado. Sin embargo, si al menos uno de los supuestos no se da, se debe llevar la decisin al Comit del Proyecto para su consideracin.

Si existe alguna duda o si el cambio es muy grande, el Gerente del Proyecto debe convocar a una reunin del Comit del Proyecto. En esta reunin se deben discutir todos los aspectos relacionados con el cambio y se debe llegar a una recomendacin sobre proceder o no con el cambio. Esta recomendacin puede requerir de involucrar a los gerentes de las unidades de sistemas y/o usuarias para su confirmacin y finalmente al Comit de Alta Gerencia para su aprobacin final e implantacin.

La decisin de no proceder debe ser comunicada por escrito al solicitante. Adicionalmente, el cambio propuesto puede ser planificado como una mejora a ser implantada luego de la culminacin del proyecto. Tales decisiones se consideran como definitivas mientras dure el proyecto, para evitar prdidas de tiempo en la reevaluacin de solicitudes viejas. Siguiendo a la decisin de adoptar un cambio, el Gerente del Proyecto debe tomar las previsiones necesarias para ponerlo en funcionamiento. Esto incluir una nueva sesin RAP (planificacin en tiempo real). Se debe notar cuidadosamente que, siempre que el proyecto se mueva fuera de control, como resultado de un cambio externo o interno, el Gerente del Proyecto debe invocar un ciclo de planificacin del proyecto. En caso de cambios severos, ser necesario repetir la fase de Estudio de Factibilidad.

R G T OD R Q E IM N O E IS R E E U R IE T S D C M IO A P O E T E A B S L R Y CO
N mr d l C n : o be e lie te N m r d l Po e t : o be e r y co G r ned Po e t : e e t e r y co N mr d l eo e R q e im n e u r ie to Fc a eh Ev n o N m r d l R q e im no o be e e u r ie t Pg a in Fc a eh:
Et t s sau

d e

C d od l Po e to ig e r y c :

C so ot

Pe d n n ie te Apo a o r bd

Fc a eh

Re h z d c aa o

Figura 4.4 Registro de Requerimientos de Cambios al proyecto Acerca de los supuestos

Durante las sesiones RAP, se hacen varios supuestos acerca del proyecto. Por ejemplo, mientras se planifica el proyecto, el Gerente del Proyecto puede asumir que existen todas las facilidades de rea de trabajo y que el personal de secretara de apoyo estar dedicado a tiempo completo al grupo del proyecto. Esos supuestos estn parcialmente documentados en el modelo de Evaluacin de Riesgos. Otros estn documentados en los Acuerdos de Calidad y algunos son documentados en los Acuerdos con los Grupos clave. Cualquier cambio en los supuestos del proyecto debe ser tratado con el mecanismo de control de cambios establecido, en la misma forma que lo son los cambios de requerimientos, cronograma, y otros componentes clave del Business Case. Solicitud y Registro de Decisin La Solicitud de Decisin es un mecanismo para obtener y documentar decisiones o requerimientos de informacin durante el curso del proyecto. La figura 4.5 muestra el formulario de Solicitud de Decisin. Las Solicitudes de Decisin documentadas aseguran que los participantes del proyecto estn conscientes de cualquier decisin que debe ser tomada y que puede tener un impacto en el progreso y la productividad del Equipo del Proyecto. Un asunto es mantenido como problema del Equipo del Proyecto hasta que sea documentado o entregado a los Usuarios clave del sistema. Este mismo mecanismo ser utilizado para resolver los asuntos pendientes e internos del Equipo del Proyecto. El Registro de Solicitudes de Decisin, presentado en la figura 4.6, contiene un asiento de una lnea por cada Solicitud de Decisin. Ello provee al Gerente del Proyecto y al Comit del Proyecto con una referencia rpida a los asuntos que esperan por decisiones y la fecha que se espera las decisiones sean tomadas, con el fin de mantener la programacin actual del proyecto.

SOLICITUD DE DECISION
Nombre del Cliente: Nombre del Proyecto: Gerente del Proyecto: Cdigo del Proyecto: Descripcin de la Decisin Requerida: Nmero de Requerimiento: Nombre del Requerimiento: Fecha : Decisin Requerida por:

Recomendacin:

Impacto de la Recomendacin:

Decisin Lograda:

Fecha:

Por el Contratista: Nombre: Firma: Fecha:

Por el Cliente: Nomnre: Firma: Fecha:

Figura 4.5 Solicitud de Decisin

REGISTRO DE REQUERIMIENTOS DE DECISION

Nombre del Cliente: Nombre del Proyecto: Gerente del Proyecto: Nmero de Requerimiento Fecha Nombre del Requerimiento Pgina de Cdigo del Proyecto: Fecha: Fecha Requerida de la Decisin Fecha de Recepcin de la Decisin

Figura 4.6 Registro de Solicitudes de Decisin

Reporte y registro de problemas El Reporte de Problemas es el mecanismo para formalizar y hacer seguimiento a los problemas y fallas que se presentan durante el desarrollo de un proyecto. La Figura 4.7 muestra el formulario de Reporte de Problemas a ser utilizado por el Equipo de Aceptacin durante los procesos de prueba de aceptacin. El formulario cubre varios propsitos: Formaliza el proceso de registro de problemas. Acta para detener cambios innecesarios. Ayuda a detectar los errores oportunamente. Permite actuar objetivamente en el proceso de correccin de problemas.

El Reporte de Problemas debe ser usado tambin por el Equipo de Desarrollo para hacer seguimiento a los problemas que han encontrado y que afectan el progreso del proyecto. En este caso, los Reportes de Problema deben ser del conocimiento del Coordinador Administrativo y por supuesto del Gerente del Proyecto. Todos los Reportes de Problema que afectan el progreso del proyecto deben ser controlados mediante el uso del formulario de Registro de Reporte de Problemas (Figura 4.8).

Figura 4.7 Reporte de Problemas

REPORTE DE PROBLEMAS
Su Voz ... sin lmites
Nombre del Cliente: Nombre del Proyecto: Gerente del Proyecto: Descripcin del Problema Preparada por: Fecha: Nmero de Fallas: Cdigo:

Accin Tomada:

Preparada por:

Fecha:

Asignado a:

REGISTRO DE PROBLEMAS EL PROYECTO

Nombre del Cliente: Gerencia de Interconexin yCarrier Nombre del Proyecto: SINTEROP Gerente de Proyecto: Lisette Fuentes Nmero de la falla Fecha Envo Pgina de Cdigo del Proyecto: Fecha:
Estatus

Identificacin del problema/falla

Pendiente Resuelto

Fecha

Figura 4.8 Registro de Reporte de Problemas

CAPITULO 5 ACUERDOS EN EL PROYECTO Una vez que se culminan las sesiones iniciales de planificacin, que son la base para desarrollar la fase de Estudio de Factibilidad (o de definicin de los Trminos de Referencia) y la fase de definicin de Requerimientos del Sistema, el Gerente del Proyecto y su equipo de trabajo ya deben contar con una serie de documentos que describen los aspectos administrativos y del negocio del proyecto. Se debe tener una clara diferenciacin entre la administracin del proyecto y el desarrollo de los aspectos tcnicos que ste conlleva. Los documentos asociados con las tareas administrativas del proyecto deben ser ensamblados en un archivo independiente que ser el Archivo de la Administracin del Proyecto. Es importante mantener los documentos de este archivo separados de los documentos tcnicos asociados con el proyecto, tales como los requerimientos funcionales, diagramas, etc. Libro del Proyecto En el Libro del Proyecto se debe incluir el Business Case, tal como ya fue descrito: Antecedentes del proyecto. Alcance. Objetivos. Beneficios. Costos. Estrategia de desarrollo. Evaluacin de riesgos. Cronograma de desarrollo. Legislacin relevante. Grupos clave. Personal del proyecto. Proyectos relacionados. Suposiciones, condiciones y restricciones. Calidad en el proyecto y en sus productos. Descripcin tcnica del proyecto.

El Libro del Proyecto debe incluir adems otros papeles de trabajo tales como estndares, procedimientos administrativos, etc. Un ndice recomendado para dicho archivo se muestra en la Figura 5.1.

LIBRO DEL PROYECTO CONTENIDO

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.

Business Case Organigrama y lista de contactos Contratos, horario de trabajo Documentos de Aceptacin Cronograma del proyecto Reporte semanal Reporte mensual Minutas del Comit del Proyecto Requerimientos de cambios Requerimientos de decisin Reportes de problemas Requerimientos de servicios First Class Otras correspondencias Detalle de los estimados Detalle de los cronogramas Informacin sobre el personal del proyecto Reporte de gastos Contabilidad del proyecto

Figura 5.1 ndice del Libro del Proyecto GRUPOS clave Dentro de la complejidad de los proyectos actuales, es tpico encontrar gran cantidad de relaciones con elementos tales como grupos de soporte, Consultores, Grupos de Usuarios, etc. Esos grupos externos son definidos como Grupos o Personal clave. Por ejemplo, se pueden encontrar envueltos en un proyecto de envergadura grupos tales como: Otros Gerentes de Proyecto, de proyectos relacionados. Gerentes de rea de negocios. Grupos de proyecto (uno por cada subproyecto). Comit del Proyecto. Grupo de Alta gerencia. Diferentes grupos de Usuarios/Clientes Agencias del Gobierno Vendedores/proveedores de software/hardware Grupos de soporte tcnico interno, tales como Administracin de Base de Datos, Redes de Comunicaciones, Operaciones, etc. Auditora Interna y Aseguramiento de Calidad

El rol de esos grupos externos puede variar desde una posicin pasiva hasta una de total actividad en el proyecto. Para reflejar estas posibilidades, se deben clasificar los grupos externos al proyecto en al menos seis niveles de impacto o involucramiento: Nivel 1: Elementos fuera de la organizacin del Gerente del Proyecto que necesitan revisar o auditar pasivamente el proyecto y sus productos. Este nivel incluye a Auditora Externa, representantes de estndares de la industria o el Gobierno y usuarios indirectos. Nivel 2: Elementos fuera del rea inmediata del Gerente del Proyecto que tienen una participacin menor o un rol de consultora. Este nivel incluye Auditora Interna, reas de aseguramiento de calidad y grupos de soporte al desarrollo tales como Metodologas, Estndares y Organizacin. Nivel 3: Representantes de Sistemas externos o de Proyectos que envan o reciben datos del proyecto. Este nivel incluye a los representantes de computacin de los sistemas o proyectos relacionados y a usuarios de dichos sistemas y proyectos. Nivel 4: Grupos y proyectos que estn dentro de la organizacin pero fuera del rea inmediata del Gerente del Proyecto y que tienen una participacin o impacto importante sobre el desarrollo del proyecto. Este nivel incluye los grupos de soporte tcnico interno tales como Administracin de Base de Datos, Operaciones y Redes. Nivel 5: Grupos y proyectos que estn fuera de la organizacin del Gerente del Proyecto y que tienen una participacin o impacto importante sobre el desarrollo del proyecto. Este nivel incluye a vendedores y proveedores de software/hardware, la contratista para el proyecto, consultores externos y cualquier persona de otras organizaciones que estn involucradas en proyectos interrelacionados o dependientes. Nivel 6: Los Usuarios principales, que son los clientes/promotores principales del proyecto. Este nivel consiste de los gerentes y personas clave de las reas clientes directas del proyecto y del Comit del Proyecto: El grupo del proyecto siempre es tratado como elementos del Nivel 6. Es normal que cada uno de los grupos externos tenga diferentes percepciones de los objetivos, alcance, riesgos, calidad y otros elementos relacionados con el proyecto. Por tanto, es esencial que se logre que representantes de los niveles 3, 4, 5 y 6 se encuentren participando activamente en los procesos de planificacin, seguimiento y revisin. Es importante que al menos representantes de los niveles 5 y 6 estn presentes en las sesiones de planificacin y que representantes de los niveles 3 y 4 se involucren va su participacin activa en los procesos de revisin. Los representantes de los niveles 1, 2 y 3 deben participar, como mnimo, en los procesos de revisin y aprobacin del Business Case y de los planes del proyecto. En el caso de proyectos relacionados, es til distinguir el tipo y la naturaleza de la dependencia. En trminos de tipo de dependencia, el proyecto que est siendo planificado puede ser dependiente de otro proyecto, interdependiente con otro

proyecto, o tener a otros proyectos dependientes de l. La naturaleza de la dependencia puede incluir: Fechas. El proyecto comparte fechas con otros proyectos. Funcin. El proyecto comparte funcionalidades comunes con otros proyectos. Objetos. El proyecto puede compartir datos y funciones como unidades u objetos. Staff. El proyecto comparte personal con otros proyectos. Tecnologa. El proyecto comparte tecnologa, esto es, un proyecto instala tecnologa que el otro requiere. Financiamiento. El proyecto comparte arreglos de financiamiento, esto es, un proyecto financia a otro proyecto. Dependiendo de la naturaleza y el tipo de dependencia, es posible que el Gerente del Proyecto requiera de gente especfica involucrada en gerenciar los otros proyectos como Personal Clave. Por ejemplo, una dependencia de datos es manejada por un Administrador de Datos experto y una dependencia de fondos por un Contador o Experto Financiero. ACUERDOS DEL PROYECTO Como un resultado de la criticidad de los grupos externos, el Gerente del Proyecto encontrar que su habilidad para lograr cumplir con las fechas de entrega del proyecto, los requerimientos de calidad y las especificaciones de los productos depende de representantes de los Niveles 3, 4, 5 y 6. Previo al comienzo del proyecto, cuando ste depende de grupos externos, el Gerente del Proyecto debe obtener un compromiso formal de esos grupos externos de que estn preparados para entregar sus recursos de acuerdo con el cronograma de proyecto acordado. En muchos casos, esto requiere de una aprobacin formal del Archivo del Proyecto, el Business Case, y los cronogramas propuestos, por parte de los representantes clave de los grupos externos de los Niveles 3, 4, 5 y 6. En el caso de los grupos del Nivel 5, tales como vendedores/proveedores de software/hardware o de otros recursos, esto incluira los contratos formales de servicio. Esos acuerdos formales son documentados como los Acuerdos del Proyecto. Tpicamente, esos acuerdos documentan lo siguiente: El tipo de soporte o servicio requerido. El tiempo y costo de los servicios. Medidas especficas de rendimiento, si se aplica. Acuerdos de contingencia o incumplimiento.

Cualquier conflicto de prioridades o de requerimientos entre los diferentes grupos externos debe ser llevado al Comit del Proyecto para su resolucin. En resumen, para llevar adelante el proyecto se debe producir una serie de acuerdos formales y semiformales entre el Gerente del Proyecto y los diferentes grupos externos relacionados con el proyecto. Estos acuerdos forman las bases del proceso de Control de Cambios. Cualquier acuerdo formal debe ser aadido al Archivo del Proyecto. Para documentar estos acuerdos se utiliza la forma de Requerimiento de Servicios (Figura 5.2), as como la forma de Registro de Requerimiento de Servicios (Figura 5.3). Parte integrante de estos acuerdos es el Acuerdo Formal de Calidad a ser negociado para el proyecto. ACUERDOS SOBRE EL PERSONAL DEL PROYECTO Se debe tener presente que no todas las personas tienen la misma experiencia y habilidades, lo cual se puede traducir en una relacin de productividad entre individuos del orden de 2:1 y, en reas tales como anlisis y diseo, esta relacin puede ser de 10:1 o mayor. Como durante el proceso de planificacin se debe asumir que se dispondr de los individuos con las caractersticas requeridas, es necesario definir cuidadosamente las experiencias, habilidades y conocimientos para el personal que se requerir en el proyecto. Estas definiciones deben cubrir detalles tales como los lenguajes a utilizar, la tarea a realizar, el nivel de habilidad requerido, tales como niveles 1 a 4(donde el nivel 1 significa que entiende la habilidad y puede realizarla bajo supervisin y el nivel 4 significa que es un experto capaz de trabajar independientemente e innovar en el rea de trabajo). Una vez que los perfiles se documentan en el Acuerdo de Personal, ste sirve de insumo para los estimados de duracin del proyecto. En caso de que en la realidad del proyecto se consigan personas que no se adaptan a los perfiles definidos en la planificacin, se usar el Acuerdo para renegociar los estimados de tiempo y riesgos del proyecto. En la Figura 5.4 se muestra un ejemplo del uso del formato de Requerimiento de Servicios. ALGO MAS SOBRE LOS ACUERDOS Es importante estar muy claros en que los diferentes acuerdos negociados entre el Gerente del Proyecto y las Personas clave del proyecto, deben ser tratados como contratos entre las partes, siempre que sea posible. Por ejemplo, cuando el Gerente del Proyecto presenta el Business Case y sus planes de proyecto asociados ante el Comit del Proyecto, ste se convierte en un contrato

entre el Comit del Proyecto, el Ejecutivo Senior promotor del proyecto y el Gerente del Proyecto. Para resumir, mientras el Gerente del Proyecto es responsable por llevar adelante el Contrato negociado, l tiene que contar con que el Ejecutivo Senior promotor del proyecto y el Comit del Proyecto lo apoyan para asegurar que los diferentes acuerdos del proyecto se cumplan. Es decir, el Business Case y sus planes de proyecto asociados estn basados en que el Gerente del Proyecto est asistido por la alta gerencia de la organizacin en reas tales como manejo de riesgos y relaciones con el Personal Clave del proyecto. Finalmente, el Comit del Proyecto debe servir como un foro a la hora de dilucidar los inconvenientes que normalmente se presentan en cuanto a demandas de servicios y prioridades entre la Gerencia del Proyecto y las personas clave afectadas.

REQUERIMIENTO DE SERVICIO
Nombre del Cliente: Nombre del Proyecto: Gerente del Proyecto: Servicio requeridos: Pgina de Cdigo: Fecha:

Fechas de inicio / terminacin del servicio requerido:

Costo del servicio:

Servicios alternos:

Gerente Del proyecto: Nombre: Firma: Fecha:

Gerente proveedor del servicio: Nombre: Firma: Fecha:

Figura 5.2 Requerimiento de Servicio

REQUERIMIENTO DE SERVICIO
Nombre del Cliente: Nombre del Proyecto: Gerente del Proyecto: Pgina de Cdigo: Fecha:

Servicio requeridos: Personal de la Unidad de Tecnologa de Informacin. Analista de Sistemas: Modelamiento de Datos, Nivel 2 superior. Modelamiento funcional, Nivel 3. Anlisis de costos, Nivel 3. Analista Diseador: Modelamiento de datos, Nivel 3. Diseo Oracle, Nivel3.

Fechas de inicio / terminacin del servicio requerido: Del 01-04-98 al 31-07-98 A tiempo completo.

Costo del servicio:

Servicios alternos: Analista de Sistemas: Personal externo con las mismas habilidades Analista Diseador: Modelamiento de datos, Nivel 3. Diseo Oracle, Nivel2.

Gerente Del proyecto: Nombre: Firma: Fecha:

Gerente proveedor del servicio: Nombre: Firma: Fecha:

Figura 5.3 Ejemplo de Requerimiento de Servicio

Su Voz ...

REGISTRO DE REQUERIMIENTOS DE SERVICIO sin lmites

Pgina 1 de 1 Cdigo: VPCE.GIC.08.95 Fecha: 31/10/97 Fecha Fecha de Requerida de Recepcin de la Decisin la Decisin

Nombre del Cliente: Gerencia de InterconexinCarrier y Nombre del Proyecto: SINTEROP Gerente del Proyecto: Lisette Fuentes Nmero de Fecha Requerimiento Nombre del Requerimiento

Figura 5.4 Registro de Requerimiento de servicio

Su Voz ... sin lmites

REPORTE DE ACEPTACION PERSONAL

Carrier Gerente del Proyecto: Fecha : Fase : Lisette Fuentes

Nombre del Cliente: Gerencia de Interconexin y Nombre del Proyecto: SINTEROP Cdigo del Proyecto: VPCE.GIC.08.95

Fecha de entrega del producto para aceptacin: Producto a aceptar:

Nombre del Aceptador: Titulo del Aceptador: Fecha de aceptacin: Firma del Aceptador: Comentarios:

Figura 5.5 Reporte de Aceptacin

CAPITULO 6 ORGANIZACION PARA EL PROYECTO El xito de un proyecto depende en parte de que se entiendan los roles que desempean los equipos que definen la organizacin creada para ejecutar el proyecto. Se debe preparar ntegramente el organigrama correspondiente y asegurarse que sea del conocimiento de todas las reas de la empresa afectadas por el proyecto, para ayudar as al logro de dicho xito. El organigrama del proyecto identifica a todas las personas relevantes involucradas tales como los Usuarios clave, Gerente del Proyecto, Miembros del Comit del Proyecto, los Coordinadores de Proyecto, Aceptacin y de Desarrollo, as como al resto de los miembros de la organizacin asignados al proyecto. Es importante establecer que, aunque los miembros del Equipo del Proyecto dependen funcionalmente de diferentes unidades organizativas, una vez que han sido asignados al proyecto dependen del Gerente del Proyecto. El organigrama identifica a los participantes clave de la organizacin:

Comit Ejecutivo del Proyecto: Rene a los Ejecutivos de mximo nivel representantes de las unidades afectadas por el proyecto. Ejecutivo del Proyecto: Es el Ejecutivo interno de Alto Nivel responsable en ltima instancia del proyecto, y por tanto de la unidad usuaria cliente del sistema a construir. Ejecutivo del Contratista: Es el Ejecutivo externo de Alto Nivel responsable en ltima instancia del proyecto, y por tanto el responsable legal de la contratista ante la organizacin. Director del Proyecto (Aceptador): Es el Ejecutivo Usuario responsable directo del sistema a construir y quien tiene la autoridad ejecutiva y administrativa del proyecto, de acuerdo con las definiciones ya explicadas. El Director del Proyecto tiene la responsabilidad individual por la aceptacin de los productos del proyecto. Debe tener la autoridad para tomar decisiones en representacin de la Organizacin y debe tener suficiente tiempo para dedicrselo al proyecto. Es responsable por asegurar la cooperacin de los Usuarios Finales y de los Gerentes de la Organizacin relacionados con el proyecto, sin crear una burocracia innecesaria. Es el principal negociador para resolver dificultades de comunicacin y problemas en la adquisicin y distribucin de los recursos requeridos por el proyecto.

Asegura la disponibilidad de suficiente experticia externa a lo largo de la vida del proyecto, as como tambin la existencia de suficiente infraestructura tcnica y organizacional para los productos del proyecto. Es el responsable de reportar el progreso del proyecto ante los niveles superiores y el Comit del Proyecto, y de gestionar directamente, o de negociar con otras Unidades afectadas por el sistema, la asignacin de recursos humanos al proyecto.

Director del Proyecto (Ejecutor): Es el Ejecutivo del Contratista responsable directo del sistema a construir y quien tiene la autoridad ejecutiva y operativa del proyecto, de acuerdo con las definiciones ya explicadas. El Director del Proyecto tiene la responsabilidad individual por la aceptacin de los productos del proyecto. Debe tener la autoridad para tomar decisiones en representacin de la Organizacin y debe tener suficiente tiempo para dedicrselo al proyecto. Es responsable por asegurar la cooperacin de los Usuarios Finales y de los Gerentes de la Organizacin relacionados con el proyecto, sin crear una burocracia innecesaria. Es el principal negociador para resolver dificultades de comunicacin y problemas en la adquisicin y distribucin de los recursos requeridos por el proyecto. Asegura la disponibilidad de suficiente experticia externa a lo largo de la vida del proyecto, as como tambin la existencia de suficiente infraestructura tcnica y organizacional para los productos del proyecto. Es el responsable de reportar el progreso del proyecto ante los niveles superiores y el Comit del Proyecto, y de gestionar directamente, o de negociar con otras Unidades afectadas por el sistema, la asignacin de recursos humanos al proyecto.

Consultores Especialistas: Personal externo que provee soporte y gua al proyecto en aspectos tcnicos, metodolgicos o funcionales. Tambin puede incluir a especialistas de la Organizacin representantes de reas funcionales tales como finanzas, tarifas, personal, etc. Comit del Proyecto: Representa un factor clave en el proyecto. Vigila la calidad y el alcance de los controles, es responsable de los cambios en el proyecto, ayuda a resolver problemas tcnicos y administrativos y, lo ms importante, es el mecanismo para involucrar a la Organizacin en el proyecto. El que los gerentes estn continuamente envueltos en las actividades del proyecto, desarrolla la responsabilidad compartida por el xito del mismo. Coordinador del Proyecto: Es un profesional, preferiblemente del rea usuaria, con experiencia significativa en la administracin y control de proyectos y en el

desarrollo de sistemas, que se encarga de dirigir todos los equipos que participan en el proyecto de desarrollo de sistemas, reportando al Gerente del Proyecto. El Coordinador del Proyecto coordina y controla todas las actividades relacionadas con el desarrollo e implantacin de sistemas, prepara planes de trabajo para el proyecto y reportes de progreso que, despus de discutidos con el Gerente del Proyecto, son sometidos a la consideracin del Comit del Proyecto y a instancias superiores. En el desarrollo de sus tareas, el Coordinador del Proyecto revisa el progreso de los diferentes grupos de trabajo, dirige las reuniones de control de cambios, problemas y decisiones y discute con el Gerente del Proyecto acerca de esos problemas y sus posibles correctivos, y asegura una alta participacin de los usuarios en las actividades que stos tengan asignadas. En proyectos con las caractersticas identificadas en Sinterop, resulta difcil que el Gerente del Proyecto participe a tiempo completo, por lo que, en la prctica, el Coordinador del Proyecto es quien motoriza y dirige todas las actividades; sin embargo, en cualquier caso la buena marcha del proyecto depender que exista una estrecha comunicacin entre Gerente y Coordinador, de tal forma que las decisiones fluyan con la rapidez necesaria.

Equipo de Aceptacin: Tiene, por delegacin, la responsabilidad en la aceptacin de los productos. Su responsabilidad incluye el proveer las especificaciones y necesidades de sus reas de responsabilidad, proveer criterios y datos de prueba, ayudar en la creacin del material de entrenamiento y en la documentacin del usuario, y realizar las pruebas de aceptacin dentro de su rea funcional. Dentro del Equipo de Aceptacin est el Coordinador Administrativo del Proyecto, quin acta como coordinador del equipo de aceptacin y secretario del Comit del Proyecto, manteniendo actualizada la documentacin del proyecto. Es el responsable por la administracin de los mecanismos de control de cambios, decisiones y problemas. As mismo, colabora con el Coordinador del Proyecto en la planificacin y consolidacin de los planes a corto y mediano plazo y en el control de la ejecucin del proyecto, siendo responsable por la actualizacin del sistema automatizado de apoyo al control de proyectos. Comparte con el Coordinador de Sistemas Manuales la elaboracin de los Manuales de Procedimientos y el entrenamiento a los usuarios. En cuanto a la aceptacin del sistema, colabora en la elaboracin de los planes de aceptacin y coordina la ejecucin de los mismos. El Equipo de Aceptacin debe contar con el apoyo de: Especialista en Aceptacin de Operaciones, para evaluar la capacidad de la instalacin para atender satisfactoriamente los requerimientos de servicio (tiempo de respuesta, calendarios de proceso, frecuencia y horario de proceso, etc.) y evaluar el desempeo del sistema una vez que entre en su etapa de operacin. Auditor Revisor, para evaluar y aprobar el sistema en los aspectos relacionados con el control interno (autorizaciones, exactitud de la

informacin, seguridad, adherencia a las normas y polticas de la Organizacin). En el caso de Telcel, este rol puede ser llenado por personal de la Gerencia de Control de Cambios. Consultor/Evaluador, personas fuera del Equipo del Proyecto invitados especialmente para una revisin o colaborar en algn proceso especial de aceptacin.

Equipo de Desarrollo de Sistemas Automatizados: Tienen la responsabilidad tcnica por el desarrollo y la implantacin de los procedimientos automatizados del sistema objeto del proyecto. Est conformado por especialistas, los cuales, dependiendo de la magnitud y complejidad del sistema, asumirn roles tales como Analista Planificador de Sistemas, Analista Diseador de Arquitectura, Analista Diseador de Aplicaciones, Analista de Datos, Diseador de Base de Datos, Programador, Analista Integrador. Dentro del Equipo de Desarrollo Automatizado est el Coordinador de Sistemas Automatizados, quien dirige el equipo de desarrollo de sistemas automatizados. Es el responsable por entregar productos de calidad que satisfagan todos los requisitos que se han definido. Coordina y controla todas las actividades relacionadas con el desarrollo e implantacin de sistemas automatizados, basado en el cumplimiento de los Mtodos, Estndares y Procedimientos vigentes en la unidad de Tecnologa de Informacin de la empresa(adaptndolos a los factores de contingencia en los que se desarrolla el proyecto) y aplicando, en lo posible, herramientas modernas de CASE y desarrollo de Prototipos. Tambin es su responsabilidad la preparacin de planes de trabajo para el proyecto y los reportes de progreso correspondientes. El Coordinador de Sistemas Automatizados apoya al Gerente del Proyecto para, en el ambiente de TI, asegurar la disponibilidad de suficiente experticia externa a lo largo de la vida del proyecto, as como tambin la existencia de suficiente infraestructura tcnica y organizacional para los productos del proyecto.

Equipo de Mtodos y Procedimientos: Tienen la responsabilidad tcnica por el desarrollo y la implantacin de los procedimientos manuales del sistema objeto del proyecto. Est conformado por especialistas en las reas de mtodos, procedimientos manuales, interfaz usuario/mquina, estudios organizacionales y tcnicas de adiestramiento. EL Analista de Mtodos y Procedimientos es responsable, junto con los usuarios representantes de las diferentes funciones involucradas en el sistema bajo desarrollo, de definir y desarrollar los procedimientos que rodearn y regularn el funcionamiento de los sistemas automatizados. Tambin se encarga de perfilar y proponer los cambios a la organizacin que sean necesarios para mejorar la eficiencia operacional del negocio y asegurar un uso efectivo de los sistemas que se instalen. Dentro del Equipo de Mtodos y Procedimientos est el Coordinador de Sistemas Manuales, quien dirige este equipo. Es el responsable por entregar productos de calidad que satisfagan todos los requisitos que se han definido. Coordina y controla

todas las actividades relacionadas con el desarrollo e implantacin de sistemas automatizados, basado en el cumplimiento de los Mtodos, Estndares y Procedimientos vigentes en la unidad de Organizacin y Mtodos de la empresa(adaptndolos a los factores de contingencia en los que se desarrolla el proyecto) y aplicando, en lo posible, herramientas modernas de CASE. Tambin es su responsabilidad la preparacin de planes de trabajo para el proyecto y los reportes de progreso correspondientes. El Coordinador de Sistemas Automatizados apoya al Gerente del Proyecto para, en el ambiente de TI, asegurar la disponibilidad de suficiente experticia externa a lo largo de la vida del proyecto, as como tambin la existencia de suficiente infraestructura tcnica y organizacional para los productos del proyecto. Durante las fases de Planificacin/Anlisis/Diseo, tiene la responsabilidad de desarrollar, junto con los Analistas de Sistemas Automatizados y los Usuarios, los modelos de procesos y de datos que describen los requerimientos del sistema. As mismo, colabora en la elaboracin de los planes de desarrollo de sistemas, de entrenamiento al personal usuario y de prueba de los sistemas, que en conjunto conforman los resultados de la fase de Requerimientos(Business Case). Apoya al Gerente del Proyecto para, en el ambiente de O y M, asegurar la disponibilidad de suficiente experticia externa a lo largo de la vida del proyecto, as como tambin la existencia de suficiente infraestructura tcnica y organizacional para los productos del proyecto.

Equipo de Soporte de Sistemas Automatizados: Agrupa a especialistas de hardware, software y comunicaciones. Ponen a disposicin del Equipo de Proyecto su experticia en los diferentes aspectos de arquitectura tecnolgica, actan como coordinadores de diseo para los miembros del equipo y se desempean como administradores de base de datos para controlar las bases de datos y la Metadata. Equipo de QA: Area funcional encargada de la calidad en sistemas. Son responsables por asegurar la calidad de los productos del proyecto y la consistencia en la aplicacin de la metodologa, los estndares y herramientas de sistemas de la organizacin.

COMITE DEL PROYECTO Es necesario involucrar a la Alta Gerencia de la Organizacin en los proyectos informticos, para asegurar que la aprobacin, desarrollo y soporte de los proyectos de sistemas de informacin reflejen la direccin estratgica de la empresa, y que la bsqueda de recursos humanos, capital y equipos requeridos para el proyecto sean realizados dentro de una amplia perspectiva organizacional. En todo proyecto existen dos sistemas de control: El administrativo, que cubre los objetivos, personal, tiempo, costos, personal crtico y otros aspectos del negocio.

El tcnico, que trata con las tareas y problemas especficos asociados con equipos, tecnologa y productos del proyecto.

Es generalmente aceptado que el Gerente del Proyecto delegue el sistema de control tcnico a sus expertos mientras que l mantiene el control de los objetivos, personal, tiempos, riesgos y prioridades, esto es, el sistema de control administrativo. Al igual que los gerentes de proyectos, el Comit del Proyecto debe concentrarse en resolver el impacto de los aspectos tcnicos en los objetivos del proyecto, sus costos, etc. El inters del Comit del Proyecto debe estar en el Business Case y sus prioridades, estrategias, productos y planes asociados. Para decidir en esos aspectos, la Alta Gerencia debe estar informada de la situacin de los componentes del proyecto: objetivos, personal, tiempos, riesgos y calidad, por medio de diferentes reportes detallados a ser preparados por la Gerencia del Proyecto. Funciones y responsabilidades del Comit del Proyecto Aprobacin de proyectos y etapas de proyectos. Seguimiento y revisin de proyectos. Asistencia a los proyectos, cuando sea requerido. Solucin de los conflictos en los proyectos.

Aprobacin de proyectos y etapas de proyectos La aprobacin de proyectos es un proceso de dos etapas. La primera se relaciona con la identificacin de los proyectos potenciales (por nueva legislacin, planificacin estratgica o iniciativas normales en los negocios). Seguidamente, los proyectos para ser aprobados y convertirse en un Business Case, deben desarrollar un Estudio de Factibilidad. Para proyectos menores, normalmente el promotor del proyecto adopta el rol del Comit. En las grandes organizaciones existe generalmente un comit permanente a nivel ejecutivo, que revisa y administra todos los proyectos de sistemas de informacin desde una perspectiva estratgica y que delega el control especfico de proyectos individuales a los Comits de Proyecto. Al final del Estudio de Factibilidad, el Comit de Alta gerencia recibe un informe del Business case. Sobre la base de ste, decide si procede con el desarrollo. De ser as, el Comit debe definir las prioridades de los objetivos, aprobar el presupuesto, especificar los productos, definir las restricciones en cuanto a presupuesto y tiempos, y determinar las acciones que se deben realizar para minimizar los riesgos del proyecto, esto es, negociar los contratos con el Gerente del Proyecto. El Comit de Alta Gerencia debe as mismo determinar el grado de delegacin para el Gerente del Proyecto y los puntos de revisin clave durante el ciclo del proyecto.

Seguimiento y revisin de proyectos. Dependiendo del tamao, riesgos e impacto organizacional del proyecto, el Comit del Proyecto le har seguimiento y revisin al proyecto en varias etapas clave, utilizando los reportes del proyecto definidos. Como mnimo, el Comit debe revisar el proyecto al final de cada una de las fases del ciclo de desarrollo. Sin embargo, para proyectos que estn sujetos a altos riesgos de cambios, o que tienen alto impacto organizacional, por ejemplo, se requiere de una mayor frecuencia del proceso de seguimiento y revisin. Adicionalmente, si el proyecto est utilizando estrategias ms complejas de desarrollo tales como RAD, desarrollo hbrido o por prototipos, las revisiones sern ms dinmicas y flexibles. Tpicamente, en desarrollos complejos, las revisiones se determinan por la obtencin de productos tales como prototipos completados, sesiones JAD concluidas, etc. El proceso de seguimiento y revisin debe enfocarse en el Business Case y en cualquier variacin de sus componentes clave, tales como objetivos, riesgos, costo, fechas, productos y calidad. El Comit del Proyecto es el responsable nico para aprobar cambios al Business Case. Como regla general, el control administrativo de los puntos mencionados arriba, no debe ser delegado al Gerente del Proyecto. Cuando se tenga que proponer alguna modificacin al Business Case original, se debe requerir de la siguiente informacin para la reunin del Comit: La naturaleza y razones para el cambio. Impacto del cambio. Actualizacin del Business Case (incluyendo alternativas del plan del proyecto). Acciones sugeridas para la consideracin del Comit del Proyecto. Asistencia al proyecto. Si se presentan cambios en el proyecto, la funcin del Comit del Proyecto es apoyar al Gerente del Proyecto para la solucin efectiva del cambio y minimizar su impacto en el proyecto. En muchos casos, el cambio est fuera del control del Gerente del Proyecto, por lo que el apoyo del Comit para solucionar el problema es una funcin que tiene que hacer la Alta Gerencia. Aunque se requiere que el Comit del Proyecto se identifique con las razones para el cambio en el proyecto, es ms importante que ellos se concentren en resolver las situaciones para asegurar que el proyecto contine desarrollndose bajo su control. Resolucin de conflictos durante el proyecto

En el enfoque de proyectos actual, el Gerente del Proyecto acta como un Gerente Contratista que a su vez requerir de un cierto grupo de sub-contratistas, esto es, expertos que estn en unidades fuera del control administrativo directo del Gerente. Por ejemplo, el gerente puede requerir de personal de base de datos, proveedores, empleados de oficinas regionales y hasta de representantes de usuarios para trabajar en algunas de las fases del proyecto. En estas situaciones, es normal que el Gerente del Proyecto se vea envuelto en conflictos relacionados con la ubicacin, calidad y nivel de involucramiento de las personas asignadas al proyecto. Cada una de esas asignaciones debe estar documentada en el Acuerdo de Proyecto definido. Ante estas situaciones, el Comit del Proyecto puede aportar una ayuda valiosa al proyecto resolviendo estos conflictos nter e intra-organizacionales. Estructura de las reuniones del Comit del Proyecto Aunque la estructura y la agenda de los comits puede variar de proyecto a proyecto, todas las reuniones de comit deben abarcar los siguientes tpicos en su agenda: La situacin del proyecto: Se ha alterado el Business Case desde la ltima reunin? De ser as, Qu cambios han afectado a?: El alcance del proyecto. Los objetivos. Las prioridades de los objetivos. La estrategia de desarrollo del proyecto. Los riesgos. Los beneficios. Los costos. Los planes y cronogramas del proyecto. Los Acuerdos de Calidad. Los Acuerdos de Personal. Qu acciones ha tomado el Gerente del Proyecto para resolver estas situaciones? Qu acciones pueden ser consideradas por el Comit para ayudar a resolver estas situaciones? Quin es responsable por hacerle seguimiento a las decisiones? Qu caus los cambios? Hay expectativas por futuras situaciones? Se requiere de alguna otra accin?

Si se presentan situaciones en el mbito tcnico que requieran de una discusin detallada para su resolucin, es necesario convocar a una reunin de Revisin Tcnica separada, con el objeto de que los representantes de la alta gerencia en el Comit del Proyecto no se distraigan de su objetivo primordial que es el control administrativo del proyecto. En la Figura 6.1 se muestra un ejemplo de Agenda para el Comit del Proyecto.

AGENDA DE PROYECTO
Su Voz ... sin lmites
Nombre del Cliente: Nombre del Proyecto: Gerente del Proyecto: Status del Proyecto: Presupuesto Cronograma Progreso Fecha: Cdigo: Preparada por:

Responsabilidad del Ususario:

Control del Alcance: Solicitudes de Cambios Solicitudes de Decisiones Reporte de Problemas

Aspectos para accin del Comit de Alta Gerencia:

Otros Aspectos a tratar:

Prxima Reunin:

Figura 6.1 Agenda para el Comit del Proyecto

ALGO MAS SOBRE EL COMITE DEL PROYECTO Debido a que parte de los miembros del Comit del Proyecto son Gerentes Senior, y a que ellos normalmente estn muy ocupados, es tpico que los gerentes de proyecto estn presionados en simplificar y resumir las situaciones a presentar del proyecto, especialmente si el proyecto es largo y complejo. Independientemente de esta actitud a presentar las situaciones en una pgina o menos, el Gerente del Proyecto debe asegurarse de que los miembros del Comit tienen suficiente informacin para garantizarles que estarn realmente al tanto de la situacin y los problemas del proyecto. De no ser as, la actividad del Comit se ver reducida a una sesin de firmas de documentos. El uso de un cuerpo de formatos comunes, una buena calidad de impresin y el uso de grficas, junto con una buena calidad en el uso del lenguaje para lograr explicaciones claras y sencillas, puede ayudar a que los miembros del Comit tengan un entendimiento ms profundo y realista de las situaciones a veces necesariamente complejas de la mayora de los proyectos. Lamentablemente, los proyectos complejos requieren de modelos complejos. En las figuras 6.2 a la 6.5 se muestran ejemplos de organizaciones para proyectos. ORGANIZACIN MATRICIAL BALANCEADA
PRESIDENCIA

VICEPRESIDENTE COMUNICACIONES ESTRATEGICAS

VICEPRESIDENTE TECNOLOGIA DE INFORMACION

VICEPRESIDENTE INGENIERIA

VICEPRESIDENTE FINANZAS

STAFF DEL USUARIO

STAFF

STAFF

STAFF

STAFF DEL USUARIO

GERENTE DE SISTEMAS

GERENTE DE PLANIFICACION

ORGANIZACIN Y METODOS

GERENTE DEL PROYECTO

Coordinacin del proyecto

COORDINADOR ADMINISTRATIVO

COORDINADOR TECNICO

INGENIERO DE PLANIFICACION

ANALISTA OYM

Figura

ORGANIGRAMA DE PROYECTO CON EMPRESA CONTRATISTA

COMITE EJECUTIVO DEL PROYECTO

GERENCIA DEL CLIENTE

GERENCIA DEL CONTRATISTA

COMITE DE GERENCIA

DIRECTOR DEL PROYECTO (ACEPTADOR)

COORDINADOR DE LOS USUARIOS

GERENTE DEL PROYECTO

QUALITY ASSURANCE

CONSULTORES ESPECIALISTAS ADMINISTRADOR DEL PROYECTO

STAFF DEL USUARIO

STAFF DE SISTEMAS (CLIENTE)

STAFF DE SISTEMAS (CONTRATISTA)

ARQUITECTURA TECNICA

ARQUITECTURA DE APLICACIONES

Figura 6.3

ORGANIGRAMA DE PROYECTO
EJECUTIVO DEL PROYECTO COMITE ALTA GERENCIA

COMIT DEL PROYECTO

GERENTE DEL PROYECTO

CONSULTORES ESPECIALISTAS

COORDINADOR DEL PROYECTO

EJECUTIVO DEL CONTRATISTA

EQUIPO DE QA

EQUIPO DE ACEPTACION

EQUIPO DE DESARROLLO SISTEMAS AUTOMATIZADOS

EQUIPO DE SOPORTE SISTEMAS AUTOMATIZADOS

EQUIPO DE METODOS Y PROCEDIMIENTOS

VERSION 06-05-98

ORGANIGRAMA DE PROYECTO
COMITE DEL PROYECTO

ADMINISTRACION DEL PROYECTO

GERENTE DEL PROYECTO

CONSULTORES ESPECIALISTAS

Quality Assurance

Grupo de pruebas del sistema

Arquitectura tcnica

Equipo de desarrollo de aplicaciones

Equipo de apoyo para aceptacin de sistemas

Equipo de Ingeniera

Equipo Tcnico

Representantes del Usuario

Expertos tcnicos

Coordinador de diseo

DBA

Estndares Metodologa

Hw, Sw Telecom.

DBMS

Software de Aplicaciones

Red

Tecnolgica

Figura 6.4

O R G A N IG R A M A D E P R O Y E
E J E C U T IV O DEL PROYECTO C O M IT D E L PRO YECTO L IS E T T E F U E N T E S B LA N C A FE RNA N D EZ (G . S IS T E M A S ) C A R O L IN A S E N IO R (G . P L A N IF IC A C IO N ) A N T O N IO F R A N C E S K I N (G . O P E R A C IO N E S ) H E L E N A P I A (G . A U D IT O R IA O P E R A T IV A ) M IG U E L IN A R E N Z U L L O (G . F A C T U R A C IO N ) L U IS H E R N A N D E Z (G . M T S O C A R A C A S ) JESUS HERNAND EZ (G . P R O Y E C T O S T R A N S M IS IO N E IN T E R C O N E X IO N ) S U S A N A G A R C IA M IG U E L C O L O M B O R IC A R D O N A P O L IT A N O ( S E C R E T A R IO C O M I T ) HAYDEE DE SALAS (V P C O M U N IC A C IO N E S E S T R A T E G IC A S ) C O M IT E A L T A G E R E N C IA
HAYDEE DE SALAS G U S T A V O R E Y E S (V P T E C N O L O G IA D E IN F O R M A C IO N ) C A R L O S U R B IN A ( V P O P E R A C IO N E S E IN G E N IE R IA ) L A Z A R O E S P IN O Z A (V P F IN A N ZAS) L IS E T T E F U E N T E S

GERENTE DEL PROYECTO L IS E T T E F U E N T E S (G E R E N T E D E IN T E R C O N E X IO N Y C A R R IE R )

CO NSULTO RES E S P E C IA L IS T A S CA R LO S R O D R IG U E Z

C O O R D IN A D O R DEL PRO YECTO M IG U E L C O L O M B O

E J E C U T IV O D E L C O N T R A T IS T A

A N T O N IO C A R C IA (B U S IN E S S W A R E )

E Q U IP O D E M E T O D O S Y E Q U I P O D E A C E P T A C I O NE Q U I P O D E D E S A R R O L LEOQ U I P O D E S O P O R T E P R O C E D IM IE N T O S S I S T E M A S A U T O M A T I Z S ID O E M A S A U T O M A T I Z A D O S A STS P E D R O M I G U E L P E R ER I C A R D O N A P O L I T A N O S U S A N A G A R C I A Z C E S A R P IN O C H E T CO ( A N A L I S T A D E Q R A ) ( C O O R D I N A D O R A D M I N I( S T RO. )R D I N A D O R D E S R RC S I S T ) D I N A D O R S O P O RVTOE N N E O R T E G A ( OOR I ) ( A D M I N Y C O N F I G C O N V J O S O SA) N G E L M A T A ( B W U A N C A R L O S N A V A S ( A N A L I S T A D E M E T O D O S Y ENI E J) (A N A L IS T A D E B D ) C A R O L IN A S E N I O R (O R A C L E ) P R O C E D IM IE N T O S ) A LE X I FR A N C O A N T O N IO M A R T I N E A U (A N A L IS T A D E F A C T U R A C IO N ) D IL C IA Q U IR O Z L O U R D E S S E N IO R (C O N F IG U R A D O R D E L A R E D ) E Q U IP O D E Q A V E R S IO N 0 6 -0 5 - 9 8

CAPITULO 7 MODELO DE EVALUACION DE RIESGOS Introduccin La evaluacin de riesgos es la formalizacin de un proceso intuitivo que est siempre presente en la mente de los gerentes de proyectos cuando realizan su trabajo de planificacin. El modelo de evaluacin de riesgos que se desarrollar intenta establecer cierto rigor, objetividad y consistencia en una actividad tpicamente subjetiva y medio encubierta. El riesgo es un elemento crtico para la comprensin de la dinmica de los proyectos. El factor de riesgo en los proyectos afecta cuatro elementos clave de la gerencia de proyectos: Cronograma, Personal del proyecto, Calidad y Costos. El comprender los riesgos de un proyecto ayuda a que los gerentes determinen si pueden proceder y si tienen asignado los suficientes recursos para ello. En general, a medida que aumentan el riesgo de un proyecto, disminuye la calidad esperada, aumentan los estimados/costos y se alarga el cronograma: A mayor calidad exigida a los productos, mayor riesgo del proyecto. Mientras ms corto sea el cronograma, mayor riesgo del proyecto. A mayores restricciones de costos, mayor riesgo del proyecto. A mejor calidad del personal, menor riesgo del proyecto.

Como se mencion en el Captulo 3, la evaluacin de riesgos se realiza inicialmente durante las sesiones de Planificacin Rpida de Aplicaciones. Normalmente, la evaluacin de riesgos se realiza conjuntamente con la evaluacin y seleccin de la estrategia de desarrollo del proyecto y previo a las estimaciones. Cualquier factor valorado como de alto riesgo, debe ser sujeto a un anlisis profundo para determinar las acciones necesarias para reducirlo o contenerlo antes del inicio del proyecto. El Gerente del Proyecto y su equipo deben buscar la asistencia de la Alta Gerencia, los promotores del proyecto y de los Grupos clave para que colaboren productivamente en la reduccin o contencin del riesgo. La reduccin del riesgo en los proyectos es una situacin de Ganar y Ganar, al mejorarse las posibilidades de xito del proyecto. Aun as, es normal encontrar situaciones en las que el proyecto se ve expuesto a riesgos que estn fuera del control del Gerente del Proyecto y de su organizacin. La dependencia de organizaciones externas es un ejemplo de tales factores de riesgo. Los factores de alto riesgo que no pueden ser controlados o eliminados durante las sesiones RAP, deben ser documentados mediante un Memorndum de Riesgos, definiendo el impacto y las acciones a ser tomadas por el Comit del Proyecto, el Promotor del Proyecto o por la Alta Gerencia para reducir el riesgo. Para riesgos de alto impacto, se debe elaborar tambin un plan de contingencia. La Figura 7.1 muestra un ejemplo de dicho memorndum.

FACTOR DE RIESGO POR RESOLVER

Nombre del Cliente: Nombre del Proyecto: Gerente del Proyecto: Factor de Riesgo: Dependencia del proveedor para recibir la nueva versin del software de Base de Datos Pgina de Cdigo del Proyecto: Fecha:

Impacto del Factor de Riesgo: El proyecto se atrasar, a partir del evento XXXXXX, la misma cantidad de das que la nueva versin no est disponible y probada. Si la nueva versin no est disponible para el 8 de octubre, los valores obtenidos para el Retorno sobre la Inversin se impactarn negativamente

Estrategias para la minimizacin del Riesgo: Obtener un convenio contractual con el proveedor, incluyendo penalidades por atrasos en la entrega. Programar reuniones quincenales de seguimiento con el proveedor. Incluir en el contrato con el proveedor un bono por entrega temprana de la versin

Planes de contingencia: Preparar una solucin alterna para el sistema utilizando la versin actual del software.

Preparado por:

Figura 7.1Memorndum sobre Factores de Riesgo

El riesgo puede cambiar a medida que progresa el proyecto. Por ejemplo, es posible que un proyecto que inicialmente fue estimado como de bajo riesgo escale rpidamente a uno de alto riesgo. Cualquier modificacin en los factores de riesgo del proyecto debe estar sujeta al mecanismo de control de cambios detallado en el Captulo 4. La identificacin de riesgos debe ser realizada regularmente durante la vida del proyecto, y es necesaria cada vez que ocurran cambios en el proyecto. El Cuestionario Se han identificado tres criterios principales que contribuyen a crear riesgos en los proyectos: el Ambiente del Usuario, el Ambiente del Equipo del Proyecto, la Complejidad del Sistema y el Ambiente de Gerencia del Proyecto. Cada uno de esos criterios presenta una cantidad de factores que han sido catalogados como de Bajo, Mediano y Alto Riesgo. La suma de los diferentes valores da una indicacin del grado total de riesgo del proyecto. Es esencial entender que como la evaluacin de riesgo es subjetiva, diferentes personas percibirn los riesgos en forma diferente. La evaluacin de riesgos debe recopilar todas las evaluaciones democrticamente, aceptando la opinin de la mayora como la gua para el proyecto. Si en algunas circunstancias no se puede lograr el consenso en forma democrtica, se recomienda utilizar los valores de mayor riesgo sobre el aspecto en discusin: en este caso vale la pena ser paranoico! Se presenta una gua para valorar los factores definidos, la cual no debe tomarse como algo rgido, es decir, mientras los valores se mantengan dentro de los rangos utilizados se pueden hacer variaciones para tomar en cuenta las experiencias del equipo que aplicar el cuestionario. Pesos para la Evaluacin del Riesgo Los resultados del cuestionario deben ser contrastados contra la siguiente tabla: Criterio de riesgo Ambiente del Usuario Ambiente del Equipo Proyecto Complejidad del Sistema Gerencia del Proyecto Riesgo total del Proyecto Bajo Riesgo 32 - 127 32 - 110 33 - 126 97 - 363 Mediano Riesgo 128 - 223 111 - 199 127 - 218 366 - 640 Alto Riesgo 224 - 330 200 - 269 219 - 308 643 - 907

del

Debido a la naturaleza subjetiva de los procesos, el uso de estas valoraciones para comparar proyectos no es vlido. Por ejemplo, un proyecto con un factor de riesgo de 650 es considerado tan de alto riesgo como uno con un factor de 895.

Ms acerca de las Mtricas de Software Como se discuti en el Captulo 3, la cuantificacin de los factores de riesgo se conoce como Mtricas de Software. En lo posible, el Modelo de Riesgo definido en este captulo ofrece una medida para ayudar a determinar el impacto de los factores de riesgo. Sin embargo, muchos de los factores de riesgo siguen siendo subjetivos, por lo que el modelo total de evaluacin de riesgos continua siendo una mezcla de medidas objetivas y subjetivas. Siempre que sea posible, el Gerente del Proyecto debe tratar de aplicar aquellas mtricas que le ayuden a soportar la parte subjetiva de la evaluacin. Adicionalmente, el lograr que el Equipo del Proyecto y los Usuarios clave se involucren totalmente en el proceso de evaluacin de riesgos provee un mecanismo invaluable para sacar el mejor provecho del cuestionario presentado y de la tabla de evaluacin final. Como muchas de las tcnicas que se describen en este manual, el evento crtico de asumir activamente el proceso de evaluacin del riesgo es valioso para lograr que se compartan las suposiciones y las preocupaciones, as como tambin para lograr una visin comn del proyecto. Diferentes Modelos de Riesgo. Es importante distinguir entre el riesgo inherente a los procesos de desarrollo de productos y el riesgo asociado con el fracaso del proyecto. Por ejemplo, a un nivel elemental, el riesgo asociado con un fracaso del proyecto puede ser slo financiero: el costo del proyecto debe ser cargado a prdidas. En casos ms complejos, el riesgo puede ser:

Poltico: La organizacin entra en conflicto con el Gobierno. Recursos humanos: El personal se siente desagradado por los efectos del nuevo proyecto. Financiero: La organizacin pierde dinero y equipos. Seguridad: La organizacin queda expuesta a fraudes, acceso ilegal a datos o servicios, etc. Legal: La organizacin entra en litigios. Mercado: La organizacin pierde imagen o participacin del mercado.

Si el Gerente del Proyecto toma muchos riesgos, las consecuencias pueden ser, entre otras, las siguientes: El tiempo de culminacin puede ser mayor al esperado. Los costos pueden ser mayores a lo presupuestado. El sistema puede llegar a ser incompatible con el software o el hardware seleccionado, o El rendimiento tcnico puede ser insatisfactorio. Pero sta es una visin tcnica y restringida del Gerente del Proyecto. Existen otros aspectos que tienen que tomarse en cuenta. Entre los ms complejos estn: La posible actitud negativa de los Usuarios Finales. Falta de aceptacin (y apoyo) por parte de los Altos Ejecutivos de la Empresa. Problemas de cooperacin entre Diseadores y Usuarios.

Estos y otros riesgos se identifican durante la planificacin del proyecto y son normalmente expuestos en el Business Case para que sean considerados durante la fase de aprobacin del proyecto. En resumen, los modelos de riesgo para el desarrollo de proyectos (como el elaborado aqu), proveen una indicacin de la probabilidad de falla en el proyecto y la subsecuente exposicin a la amplia gama de riesgos comentada. Para minimizar el riesgo, el Gerente del Proyecto tiene que prepararse para trabajar en todos las acciones de su incumbencia mencionadas en los cuestionarios desde el inicio del proyecto; en segundo lugar, hacer el seguimiento y control de los factores crticos de xito del proyecto durante su progreso y, tercero, aplicar sin demoras las acciones correctivas siempre que sean necesarias.

Cuestionario para la Evaluacin de Riesgos Criterio de Riesgo: Ambiente del Usuario Criterio
1. Est el usuario comprometido con una metodologa de desarrollo de sistemas estandarizada? S No Conoce el Usuario, y est preparado para apoyar, un procedimiento de control de cambios? S No Est comprometida la Alta Gerencia Usuaria con el sistema? Totalmente Lo apoya Neutral Estn comprometidos los Usuarios Finales con el sistema? Totalmente Lo apoya Neutral Qu prioridad tiene el proyecto dentro del rea usuaria? Alta Baja Variada: diferentes prioridades para diferentes departamentos Qu tan crtico ser el sistema para la continuidad de las operaciones en el rea usuaria, cuando est terminado? Bajo impacto Impacto significativo Gran impacto Nmero de Unidades externas involucradas en el desarrollo, aprobaciones y otras decisiones relacionadas con el sistema: Ninguna 1 Ms de 1 Departamentos/Sucursales usuarias involucrados en el desarrollo, aprobacin y otras decisiones relacionadas con el sistema: 1 2 Ms de 2 Secciones de las reas usuarias involucradas en el desarrollo, aprobaciones y otras decisiones relacionadas con el sistema: 1 2 Ms de 2 Nmero de sindicatos afectados por el sistema: Ninguno 1 Ms de 1

Factor de riesgo
Bajo Alto Bajo Alto Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Bajo Alto Muy alto

Peso seleccionado

0 4 0 4 2 6 8 2 8 16 2 4 8 2 4 12 0 16 20

Bajo Alto Muy Alto Bajo Medio Alto Bajo Medio Alto

4 12 20 1 5 10 0 10 20 Peso seleccionado

10

Criterio
11 Nmero de sitios diferentes/oficinas/plantas usuarias

Factor de riesgo

12.

13

14

15

16

17

18

involucrados en el sistema: 1 2 - 10 Ms de 10 Cul es la severidad de los cambios o eliminacin de procedimientos en el rea usuaria, como consecuencia de la puesta en operacin del sistema propuesto? Menor Significativa Mayor El sistema propuesto obliga a realizar cambios estructurales en la organizacin del usuario? Menor Significativa Mayor Qu tan estables son los requerimientos del sistema? Son estables y difcilmente cambiarn Son estables pero podran cambiar Son inestables y abiertos a cambios en el futuro Situacin de la documentacin del sistema actual: No aplicable Completa(puede necesitar rehacerla) Aceptable pero incompleta No disponible Qu porcentaje de las funciones existentes deben ser reemplazadas en una base de uno por uno? 0% Menos del 25 % 25 al 50 % 50 al 100 % Hay disponibilidad de modelos o prototipos del sistema? Hay un sistema semejante Existen algunas subfunciones Existen algunas subfunciones en diferentes departamentos y sucursales Nunca se ha hecho nada semejante Las fechas de culminacin de los eventos crticos del proyecto son: Flexibles: se establecen en conjunto con el Equipo del Proyecto. Firmes: se establecen internamente, pero el incumplimiento de las fechas puede afectar las funciones/operaciones del usuario. Fijas: Establecidas por operaciones especficas, requerimientos legales o decisiones que se escapan al control de la organizacin.

Bajo Medio Alto

2 6 12

Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Bajo Bajo Medio Alto Bajo Bajo Medio Alto Bajo Medio Medio Alto Bajo Medio Alto

0 8 12 0 8 16 2 10 20 0 2 4 6 0 2 4 6 2 4 6 8 1 6 16

Criterio
19 Cmo es la participacin del usuario? Totalmente comprometido: Usuarios expertos asignados para trabajar a tiempo completo en el proyecto. Con responsabilidades importantes: No hay un compromiso de dedicacin exclusiva. Con alguna responsabilidad: Intervencin limitada a los procesos de revisin y aprobacin. Qu tanto conocimiento tiene el Representante del Usuario en el rea del negocio relacionada con el proyecto? Conoce el rea y ha estado involucrado previamente en procesos de implantacin de proyectos. Tiene alguna experiencia. Tiene una experiencia limitada. Cmo son las comunicaciones entre el rea usuaria y la unidad de Sistemas de Informacin? Buenas Regular Pobre El sistema propuesto requiere de tecnologas o tcnicas a ser controladas por el usuario (por eje: Equipos de monitoreo, terminales grficos, CAD/CAM, etc.)? No S El proyecto depende de un usuario experto nico? No S Existen normas, reglamentos o leyes del Gobierno de las cuales dependa el proyecto para cumplir con las metas fijadas en cuanto a fechas de culminacin de eventos? No S Existen Proveedores, Consultores o Expertos externos a la organizacin, de los cuales dependa el proyecto para cumplir con las metas fijadas en cuanto a fechas de culminacin de eventos? No. Expertos. Proveedores. Expertos y Proveedores.

Factor de riesgo
Bajo Medio Alto

Peso seleccionado 4 12 16

20

Bajo Medio Alto Bajo Medio Alto

2 8 20 3 6 9

21.

22

Bajo Alto Bajo Alto

0 9 0 20

23 24

Bajo Alto

0 20

25

Bajo Medio Alto Muy alto

0 8 12 20

Cuestionario para la Evaluacin de Riesgos Criterio de Riesgo: Ambiente del Equipo de Proyecto Criterio
1. Cul es la prioridad del proyecto dentro de la unidad de Sistemas de Informacin? Alta Media Baja Qu tan comprometida est la Alta Gerencia de Sistemas de Informacin con el sistema? Entusisticamente comprometida Apoya Neutra Cul es la prioridad del proyecto dentro de la unidad de Organizacin y Mtodos? Alta Media Baja Qu tan comprometida est la Alta Gerencia de Organizacin y Mtodos con el sistema? Entusisticamente comprometida Apoya Neutra Cul es el tamao del equipo de proyecto (incluyendo a los representantes de usuario a tiempo completo)? Menos de 5 5 a 10 Ms de 10 Cul es el tamao estimado del proyecto medido en personasmes? Menos de 3 meses 3 a 20 meses Ms de 20 meses Cul es el tiempo total estimado para el desarrollo del proyecto? Menos de 6 meses 6 a 12 meses Ms de 12 meses Cul es la actitud general del rea usuaria hacia la computacin? Buena: entiende el valor de la unidad de Sistemas de Informacin. Regular: Hay cierto rechazo Pobre: hay una actitud anti-sistemas de informacin Qu tanto conocimiento tiene el usuario sobre el rea de Sistemas de Informacin? Alto grado de formacin. Contactos previos pero experiencia limitada. Primer contacto con Sistemas de Informacin. Factor de riesgo Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Peso seleccionado 2 4 8 2 6 8 2 4 8 2 6 8 4 8 16 4 8 16 4 8 20 3 6 12 3 6 12

Criterio
10 Qu tanto conocimiento tiene el usuario sobre el rea de Organizacin y Mtodos?

Peso Factor de seleccionado riesgo

Alto grado de formacin. Contactos previos pero experiencia limitada. Primer contacto con Sistemas de Informacin. 11 Est previsto contar con un Gerente del Proyecto (GP) a tiempo completo, experimentado y entrenado? GP con una experiencia reciente y exitosa en un proyecto (de tipo y de tamao) similar. GP con una experiencia reciente y exitosa en administrar, ya sea parte de un proyecto similar u otros proyectos diferentes. GP con conocimientos pero con poca experiencia en el manejo de proyectos. GP sin experiencia Los requerimientos sobre el nivel del personal y sus habilidades clave pueden ser satisfechos por: Los miembros a tiempo completo del Equipo del Proyecto. Una mezcla de los miembros a tiempo completo del Equipo del Proyecto y Especialistas externos a tiempo parcial. Una mezcla de los miembros del Equipo del Proyecto y Especialistas externos, todos a tiempo parcial. Qu proporcin de los miembros del Equipo del Proyecto ser obtenida de una contratista? Ninguna. Menos del 25 %. Ms del 25 %. Qu cantidad de miembros del Equipo del Proyecto han trabajado juntos y exitosamente en proyectos previos? Un equipo de una sola persona. Todos Algunos Ninguno. Qu tanto conocimiento tiene el Equipo del Proyecto sobre el rea de aplicacin propuesta? Ha estado involucrado en esfuerzos previos de implantacin. Entiende el rea de aplicacin pero no tiene experiencia de implantacin. Mixta Limitada Qu experiencia tienen los miembros del Equipo del Proyecto con el lenguaje/s de programacin a ser utilizado? Buena experiencia dentro de la organizacin. Buena experiencia en otras organizaciones. Poca experiencia.

Bajo Medio Alto

3 6 12

Bajo Medio Medio Alto Bajo Medio Alto

4 6 8 16 3 6 9

12

13.

Bajo Medio Alto Bajo Bajo Medio Alto Bajo Medio Medio Alto Bajo Medio Alto

0 8 16 0 3 6 12 2 8 6 12 0 8 16

14

15

16

Criterio
17 Qu experiencia tienen los miembros del Equipo del Proyecto con el sistema de base de datos a ser utilizado? No se utilizar base de datos. Buena experiencia dentro de la organizacin. Buena experiencia en otras organizaciones. Poca experiencia. Qu experiencia tienen los miembros del Equipo del Proyecto con comunicacin de datos? No se utilizar comunicacin de datos. Buena experiencia dentro de la organizacin. Buena experiencia en otras organizaciones. Poca experiencia. Qu experiencia tienen los miembros del Equipo del Proyecto con los paquetes a ser utilizados? No se utilizarn paquetes. Buena experiencia dentro de la organizacin. Buena experiencia en otras organizaciones. Poca experiencia. Qu experiencia tienen los miembros del Equipo del Proyecto en la metodologa de Administracin y Control de Proyectos a ser utilizada? Buena experiencia. Variada: no todos los miembros clave la dominan. Poca experiencia. Se requerir instalar nuevos sistemas operativos? No S Qu cantidad del hardware a utilizar es nueva tecnologa para el Equipo del Proyecto? Ninguno o CPU y/o Perifricos y/o Telecomunicaciones y/o Terminales y/o Otros(mini, micros, etc.)

Factor de riesgo
Bajo Bajo Medio Alto Bajo Bajo Medio Alto Bajo Bajo Medio Alto

Peso seleccionado

0 0 8 16 0 0 8 16 0 0 8 16

18

19

20

Bajo Medio Alto Bajo Alto Bajo Alto Medio Alto Medio Alto

0 8 16 0 12 0 12 6 12 6 12

21 22

Cuestionario para la Evaluacin de Riesgos Criterio de Riesgo: Complejidad del sistema Criterio
1. Cul es la calidad del documento de propuesta realizado por los Usuarios/Analistas? Completo Aceptable pero incompleto No existe Cul es la vida esperada para el sistema propuesto? Para solucionar una situacin puntual. Menos de un ao en operacin Funcin permanente Qu tan crtico es el rendimiento del sistema? No crtico Crtico debido a los volmenes de transacciones/ tiempo total de proceso Crtico debido a los requerimientos de espacio/memoria Crtico debido a los tiempos de respuesta Con relacin a la documentacin del sistema existente, sta es: Completa (puede necesitar ser reescrita) Aceptable pero incompleta No est disponible. Qu porcentaje de las funciones existentes ser reemplazado sobre la base de una por una? 0 Menos del 25 % Del 25 al 50 % De 50 a 100 % Hay modelos o prototipos disponibles? Existen sistemas similares Existen subfunciones Existen subfunciones en diferentes sucursales/departamentos Nada disponible El software ser: Independiente del hardware Dependiente de parte del hardware Totalmente dependiente del hardware Se requiere de recursos adicionales de hardware de algn tipo que haya sido utilizado previamente por otros proyectos? No S Hay disponibilidad de los recursos adicionales de hardware requeridos? S Limitado No

Factor de riesgo
Bajo Medio Alto Bajo Medio Alto Bajo Alto Alto Alto Bajo Medio Alto

Peso seleccionado

0 2 4 1 4 12 0 16 16 16 3 6 13

Bajo Bajo Medio Alto Bajo Medio Medio Alto Bajo Medio Alto Bajo Alto Bajo Medio Alto

0 4 8 12 1 4 6 12 0 6 16 0 4 0 5 16

Criterio
10 Cantidad de entradas lgicas manejadas por el usuario, tales como pantallas especiales, transacciones. 1-5 6 - 40 40 + Cantidad de salidas lgicas manejadas por el usuario, tales como pantallas especiales de salida, reportes. 1-5 6 - 40 40 + Cantidad de vistas de datos lgicas manejadas por el usuario, tales como archivos lgicos especiales, tablas, etc. 1-5 6 - 20 20 + Cantidad de archivos de entrada/salida transferidos automticamente de/a otros sistemas manejados por el usuario. 1-5 6 -20 20 + Cantidad de consultas lgicas manejadas por el usuario. 1-5 6 - 40 40 + Cantidad y calidad de los datos a ser transferidos al sistema en la carga inicial, medidos por las vistas lgicas del usuario. 1-5 6 - 20 20 + Complejidad de la edicin de los elementos de datos: Simple Compleja Muy compleja Se requiere de elementos de seguridad para ver y/o actualizar los datos? No S Complejidad de los algoritmos requeridos en los procesos: Simples Complejos Muy complejos

Factor de riesgo
Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto

Peso seleccionado

3 6 12 3 12 20 3 12 16

11.

12

13

Bajo Medio Alto Bajo Medio Alto Bajo Medio Medio Bajo Medio Alto 3 6 Bajo Medio Alto

3 12 16 3 12 20 2 4 8 3 9 12

14

15

16

17

18

3 9 16

Criterio
19 Interfaces que tendr el software desarrollado: Independiente Sistemas bajo el control del Equipo del Proyecto Sistemas bajo el control de otras unidades Sistemas complejos bajo el control del Equipo del Proyecto Sistemas complejos bajo el control de otras unidades El software consistir de: Un paquete totalmente externo que satisface todos los requerimientos del sistema y/o Mdulos precodificados in-house escritos por el Equipo del Proyecto y/o Mdulos precodificados in-house escritos por personal de la unidad de Sistemas de Informacin externos al proyecto y/o Mdulos en paquetes o precodificados escritos por proveedores/Consultores externos y/o Un paquete totalmente externo que satisface tal menos un 90 % de los requerimientos del sistema y/o Mdulos escritos especialmente para este sistema

Factor de riesgo
Bajo Medio Medio Alto Alto Bajo Medio Medio Medio Alto Alto

Peso seleccionado 0 3 6 10 16 0 6 6 8 10 10

20.

Cuestionario para la Evaluacin de Riesgos Criterio de Riesgo: Gerencia del Proyecto Criterio
1. Est la Organizacin comprometida con una metodologa de Administracin y Control de Proyectos? Totalmente En vas de implantacin No existe Est el Comit de Alta Gerencia comprometido con el proyecto? Totalmente Medianamente Poco Tiene definido el Gerente del Proyecto un esquema de comunicacin y reportaje para el proyecto? S, de forma integral en cuanto a los afectados por el proyecto. S, de alcance reducido No Tiene definido el Coordinador Tcnico del Proyecto un esquema de comunicacin y reportaje para el proyecto? S, de forma integral en cuanto a los afectados por el proyecto. S, de alcance reducido No El Gerente del Proyecto ha logrado integrar al Comit del Proyecto a todos los Gerentes clave requeridos? S Aceptable pero incompleto No. Est definida y operativa la organizacin para el Proyecto, con una definicin precisa de la autoridad y de las responsabilidades? S Aceptable pero incompleto No. Estn definidos e implantados los procedimientos para revisin y toma de decisiones en el proyecto? S Aceptable pero incompleto No. La Gerencia de Sistemas ha definido la metodologa de desarrollo de sistemas automatizados adecuada al proyecto? No S La Gerencia de O y M ha definido la metodologa de desarrollo de sistemas manuales adecuada al proyecto? No S

Factor de riesgo
Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto

Peso seleccionado

0 4 10 0 8 20 0 8 20 0 8 20 3 6 16

Bajo Medio Alto Bajo Medio Alto Bajo Alto Bajo Alto

0 8 12 1 6 15 0 10 0 10

Criterio
10 Qu nivel de integracin tcnica existe entre las unidades de Sistemas Automatizados y de Sistemas Manuales? Alta Media Poca Nivel de detalle de las funciones y tareas en el Pert del proyecto Alto Medio Bajo Se utilizarn herramientas CASE para el anlisis y el diseo del sistema? S No Se utilizarn herramientas CASE para apoyo la construccin de los procedimientos automatizados? S, la misma definida en (12) S, diferente a la definida en (12) No Se utilizarn herramientas CASE para apoyo la construccin de los procedimientos manuales? S, la misma definida en (12) S, diferente a la definida en (12) No Estn definidos los contactos formales para resolver los problemas que se presenten en las reas tcnicas, de capacidad, de recursos y elementos de entrada de datos? S No Estn definidos y aceptados por el Equipo de Proyecto los estndares de documentacin requeridos para el sistema? S No Se exige en los estndares de documentacin que los manuales del sistema sean entregados en medio?: Magntico Papel Estn definidos y aceptados por el Equipo de Proyecto los procedimientos de control de proyectos requeridos? S No Posee el Equipo de Proyecto los procedimientos de Aseguramiento de la Calidad para el desarrollo de los sistemas y sus productos finales, implantados en la Organizacin? S No

Factor de riesgo
Bajo Medio Alto Bajo Medio Alto Bajo Medio Bajo Medio Alto Bajo Medio Alto

Peso seleccionado

3 6 12 1 10 20 3 9 0 6 9 0 6 9

11.

12

13

14

15

Bajo Medio Bajo Alto Bajo Alto Bajo Alto

1 10 0 20 0 10 0 20

16

17

18

19

Bajo Alto

3 16

Criterio
20 Posee el Equipo de Proyecto los procedimientos de la Gerencia de Control de Cambios requeridos para el pase del sistema a Produccin? S No Posee el Equipo de Proyecto los procedimientos de la Gerencia de QRA requeridos para el desarrollo y pase del sistema a Produccin? S No

Factor de riesgo

Peso seleccionado

Bajo Alto

3 16

21

Bajo Alto

3 16

CAPITULO 8 ADMINISTRANDO EL EQUIPO DEL PROYECTO Para la administracin del proyecto, ste se divide en etapas, tareas y productos. Adicionalmente, el proyecto cuenta para su realizacin con un equipo de trabajo definido por la asignacin de las diferentes responsabilidades requeridas por el proyecto. A continuacin se presenta una lista indicativa de productos del proyecto, que puede servir como gua para asignar dichas responsabilidades. Esta lista puede variar, aumentando o disminuyendo la cantidad de productos, dependiendo de la metodologa y estndares vigentes en la Unidad de Tecnologa de Informacin de la empresa. El esquema de revisin que implemente el Gerente del Proyecto tomando como base la lista de productos a definir, le permitir un control efectivo del progreso del proyecto. Responsabilidades para cada etapa del ciclo de vida del proyecto En la organizacin para proyectos recomendada, la responsabilidad final por la entrega de los productos recae en el Gerente Usuario designado como Gerente del Proyecto. Durante el desarrollo del proyecto la responsabilidad de direccin de cada etapa se transfiere entre el Gerente del Proyecto y el Coordinador Tcnico del Proyecto, as como la responsabilidad sobre los productos obtenidos se divide entre los Coordinadores Tcnico y Administrativo.

RESPONSABILIDADES EN CADA ETAPA DEL CICLO DE VIDA Gerente de Responsable por Productos la etapa los productos claves Estudio de Ejecutivo Coordinador Tcnico Descripcin del sistema Factibilidad del proyecto Organizacin del Equipo del Proyecto Propuestas de solucin para el sistema Cronograma del proyecto (Compartido con Gerente del Proyecto) Gerente del Evaluacin de riesgos Proyecto Anlisis Costo-Beneficio Business Case Definicin de Gerente del Gerente del Anlisis del sistema actual los Proyecto Proyecto Requerimientos del nuevo requerimientos sistema Alcance del nuevo sistema Estimados para las siguientes etapas (Compartido con Coordinador Tcnico) Especificacin Gerente del Coordinador Descripcin del sistema del sistema Proyecto Administrativo Requerimiento de datos (Compartido con Coordinador Tcnico) Revisin anlisis CostoBeneficio (Compartido con Coordinador Tcnico) Coordinador Tcnico Requerimiento de Hardware, Software, Redes y Telecomunicaciones Controles del sistema Estimados para las siguientes etapas(Compartido con el Gerente del Proyecto) Resumen del sistema Descripcin detallada del sistema Descripcin de los sistemas de control Etapa

Etapa Diseo del sistema

Desarrollo del sistema

Gerente de Responsable por Productos la etapa los productos claves Coordinador Coordinador Tcnico Alternativas de diseo. Tcnico Recomendaciones para la programacin. Recomendaciones para la implantacin. Resumen del sistema Diseo detallado del sistema Descripcin de los sistemas de control Protocolo de pruebas preliminar(Compartido con el Gerente del Proyecto y el Coordinador Administrativo) Estimados para siguientes etapas (Compartido con Gerente del Proyecto) Revisin Anlisis CostoBeneficio(Compartido con el Gerente del Proyecto) Coordinador Administrativo Coordinador Analista Lder o Diseo detallado y Tcnico Coordinador Tcnico documentacin de los programas Lgica detallada para cada programa Documentacin detallada para cada programa Descripciones de entrada/salida Programas fuentes Lenguaje de control, si es necesario Guas de operacin Resultados de las pruebas unitarias Resultados de las pruebas de integracin

Productos claves Desarrollo del Estimados para las Sistema siguientes etapas, (Continuacin) incluyendo cronograma de implantacin, de conversin y planes de contingencia (compartido con los gerentes de Usuario, de Proyectos, QA y Operaciones) Coordinador Protocolo de pruebas del Administrativo sistema (Compartido con los gerentes de Proyectos y de QA) Manuales del usuario Entrenamiento a los usuarios Gerencia de Operaciones Manuales de Operacin Entrenamiento a los Operadores Protocolo de Coordinador Coordinador Tcnico, Protocolo de pruebas pruebas Tcnico Gerentes de Usuarios y actualizado QA Resultados totales de las pruebas del sistema Documentacin de los resultados de las pruebas, variancia con respecto a los resultados esperados y planes para la solucin a esas variancias Coordinador Tcnico Cronograma de implantacin Plan de conversin Planes de recuperacin, contingencia y reinstalacin. Protocolizacin del Acuerdo de Niveles de Servicio

Etapa

Gerente de Responsable por la etapa los productos Coordinador Coordinador Tcnico Tcnico

Etapa Implantacin

Gerente de la etapa Gerente del Proyecto

Responsable por los productos Coordinador Tcnico

Revisin postimplantacin

Gerente del Proyecto

Coordinador Administrativo Coordinador Administrativo

Mantenimiento Gerente del Proyecto

Productos claves Procedimientos para nuevas versiones y para mantenimiento Cronograma y planes para las revisiones postimplantacin Reporte de Revisin postimplantacin Protocolizacin de la Aprobacin del Sistema Plan de cambios al sistema (Compartido con el Coordinador Tcnico). Revisiones regulares del Acuerdo de Niveles de servicio. Reportes regulares de las Revisiones Postimplantacin.

Puntos de revisin en cada etapa del ciclo de vida del proyecto En cada etapa del proyecto existen productos intermedios y productos finales. Los productos intermedios deben ser revisados por el Equipo del Proyecto que trabaja en la Etapa y el Responsable de la Etapa. Los productos finales de la Etapa deben ser revisados por el Gerente del Proyecto y al menos los siguientes miembros del Comit del Proyecto: Gerentes Usuarios Gerente de Sistemas Gerente de Organizacin y Mtodos Gerente de Operaciones Gerente de QA Coordinador Tcnico Coordinador Administrativo Estudio de Factibilidad. Slo se requiere de un punto de revisin en esta etapa, que se produce al final, cuando se presenta el Business Case a la gerencia. Definicin de los requerimientos. Se deben revisar los siguientes productos, en la medida que se producen: Anlisis del sistema actual (si existe). Documento de definicin de requerimientos del nuevo sistema (documento final de la etapa), incluyendo el prototipo, en caso de existir. Alcance del nuevo sistema. Lista de beneficios tangibles e intangibles. Especificacin del sistema. Se deben revisar los siguientes productos, en la medida que se producen: Definicin del tipo de sistema. Diagrama del sistema y su diccionario de datos. Anlisis de Costo/Beneficio actualizado. Documento de especificacin del sistema (documento final de la etapa).

Diseo del sistema. Se deben revisar los siguientes productos, en la medida que se producen: Diagrama total del sistema.

Evaluacin de las alternativas de diseo. Diseo detallado del sistema, para cada alternativa propuesta. Anlisis de Costo/Beneficio actualizado. Plan de prueba del sistema para cada alternativa. Documento de diseo del sistema (documento final de la etapa). Desarrollo del sistema.

Se deben revisar los siguientes productos, en la medida que se producen: Diseo detallado para cada programa. Cdigo del programa y resultado de la prueba unitaria para cada programa. Resultado de las pruebas de integracin. Protocolo de pruebas del sistema. Documentacin para usuarios, operaciones y entrenamiento. Documento de diseo y desarrollo de los programas (documento final de la etapa). Protocolo de pruebas. Para esta etapa, se presenta una lista detallada de las tareas que se deben desarrollar, adicionalmente a los productos que se deben obtener. Prueba unitaria: Mdulos de programas y programas. Prueba de integracin: Grupos de programas interrelacionados. Prueba funcional: Comparacin entre las especificaciones funcionales y el componente o sistema que lo ejecuta. Prueba de sistema: Complementa a la prueba funcional, verificando los aspectos tcnicos vs. los lineamientos de diseo. Prueba de aceptacin tcnica: Someter al sistema a condiciones extremas con el fin de detectar errores en el manejo de tales condiciones. Prueba de aceptacin funcional: Se lleva a cabo conjuntamente con los usuarios y Operaciones para determinar si el sistema cumple con sus necesidades bajo condiciones reales, tanto de datos como de volmenes y niveles de servicio. En el caso de reemplazo de sistemas, es el desarrollo de los paralelos.

Se deben revisar los siguientes productos, a la medida en que se producen: Los resultados de las pruebas antes enumeradas. Los manuales de usuario y de operaciones, utilizndolos durante la prueba de aceptacin funcional. Plan de implantacin, revisando entre otros aspectos los siguientes: Disponibilidad de recursos. Factores de contingencia que pueden afectar la implantacin: Procesos de cierres mensuales, anuales, especiales. Vacaciones, feriados, etc. Disponibilidad de soporte por parte de la Contratista (si existiere): Durante las pruebas, durante la implantacin, Garanta post-implantacin.

Planes de recuperacin, contingencia y "fallback. En cuanto a este ltimo, definir los criterios de fallback, identificar los recursos para contingencias, definir los tiempos crticos para recuperacin o abandono. Acuerdo de Niveles de Servicio. Definir criterios sobre: Volmenes Respuesta del usuario Precisin Calendario de procesos batch Horario on-line Condiciones especiales o periodicidad con que determinados procesos deben ser producidos Controles especiales que deben ser establecidos Consideraciones especiales que deben ser tomadas en cuenta por Operaciones ( ej.: Backups) Documento final de aceptacin de las Pruebas del sistema Implantacin.

Se deben revisar los siguientes productos, en la medida que se producen: Procedimientos para versiones y para mantenimiento Plan y cronograma para las revisiones post-implantacin. Reporte de revisin post-implantacin. Documento de aprobacin del sistema (documento final de la etapa).

1. Revisin post-implantacin. Para esta etapa, se deben obtener los siguientes productos: Encuestas de satisfaccin de los Usuarios. Reporte de Revisin Post-implantacin (incluye los resultados de las encuestas de satisfaccin de Usuarios). Protocolizacin de la Aprobacin del Sistema.

Mantenimiento. Se deben revisar los siguientes productos, en la medida que se producen: Log de cambios del sistema (regularmente, al menos mensualmente). Revisin del Acuerdo de Niveles de Servicio. Reporte de revisin post-implantacin.

Basado en el documento que te entregu y en la reunin que tuve con Jos Gregorio esta tarde, te presento los siguientes puntos para que luego los trabajemos y concretemos la documentacin para el control del proyecto a continuacin, te enumero los puntos: 1. Se haba acordado que las reuniones de seguimiento para el control del proyecto sern los mircoles a las 8:30 am, con duracin mxima de 1 1/2 horas en la modalidad 8/80 (quincenales) y comenzando el 28/03/2012. 2. Se requiere el Gant del proyecto que est en open Project que tu tienes y que se arm entre Comersso, MdeC, Crowe Horwath, Niacaury Bentez y Jos Gregorio Vivas, el mircoles 22 de febrero. 3. Establecer y formalizar los documentos y formatos para el libro del proyecto y para el control del proyecto:

1.

INICIO 1. 2. 3. Acta de constitucin del proyecto. Alcance preliminar del proyecto. Business Case, que debe contener la siguiente informacin: Antecedentes y descripcin del proyecto: Una descripcin breve de los antecedentes y del proyecto. Es importante en este punto incluir una definicin muy clara de los objetivos del negocio. En la implantacin de sistemas complejos, la ausencia de una real necesidad produce dificultades casi insuperables, porque no se encuentra colaboracin entre los usuarios, casi siempre reacios a invertir tiempo y esfuerzos para facilitar el xito del proyecto. Alcance del proyecto: Una definicin clara de las reas de impacto del proyecto y de sus lmites. Objetivos del proyecto: Una descripcin precisa de los objetivos del proyecto desde los puntos de vista estratgico, de negocios y de sistema. El proyecto tiene necesariamente que basarse sobre objetivos del negocio claros y ponderables. Beneficios del proyecto: Los beneficios que la organizacin espera obtener al poner en operacin el proyecto. Costos del proyecto: Los costos de personal, tiempo, equipos, etc. involucrados en la ejecucin del proyecto. Estrategia de desarrollo: La secuencia y segmentos del proyecto en versiones y subproyectos. Evaluacin de los riesgos del proyecto: Una evaluacin formal de los riesgos potenciales asociados con el proyecto. Cronograma de desarrollo: Los planes y cronogramas del proyecto. Leyes, normas y reglamentos relevantes al proyecto: Una descripcin y recopilacin de cualquier legislacin o poltica gubernamental o privada que est asociada con el proyecto. Grupos clave: Grupos clave y Unidades fuera del control directo del Gerente del Proyecto, y de los cuales depende en alguna forma el proyecto. Personal del proyecto: Una definicin clara de los perfiles requeridos para el personal necesario en el proyecto, as como una primera propuesta de organizacin para el proyecto.

El soporte y la colaboracin de todos los niveles de la gerencia de la empresa son condiciones bsicas e imprescindibles para el desarrollo continuo del proyecto. La responsabilidad del proyecto tiene que ser manejada por un gerente con competencia y conocimiento profundo del negocio y, si es posible, acompaado por un miembro exitoso del equipo de Tecnologa de Informacin. Proyectos relacionados: Una descripcin de cualquier otro proyecto que dependa o est interrelacionado con el proyecto propuesto, as como la integracin del sistema bajo estudio con los sistemas existentes. Suposiciones, condiciones y restricciones: Se refiere a elementos tales como fechas de culminacin propuestas o impuestas, tecnologa seleccionada, etc. Calidad en el proyecto: Una definicin que incluya medidas de la calidad requeridas de los productos del proyecto. Descripcin tcnica del proyecto: Este es un anexo que debe cubrir al menos los siguientes tpicos: Necesidades o deficiencias potenciales de sistemas existentes. Una conceptualizacin que ofrezca una gua estratgica para eliminar deficiencias existentes o potenciales, sobre todo en cuanto a la fuente y uso de los datos crticos del sistema. Propuestas de alternativas de diseo. Diagrama de flujo de procesos de alto nivel. Diagrama de flujo de datos de alto nivel.

2.

PLANEACION 1. 2. 3. 4. 5. 6. 7. 8. Alcance Detallado WBS Plan de costos. Plan general de calidad. Plan de pruebas. Plan de gestin de comunicaciones. Plan de administracin de datos. Plan de gestin de la configuracin.

3.

EJECUCION 1. Kickoff del proyecto.

4.

MONITOREO Y CONTROL 1. 2. 3. 4. 5. informes del Proyecto Control de Cambios Control de Problemas Control de Riesgos y su mitigacin Control de Decisiones.

5.

CIERRE 1. 2. Obtener documento firmado de aprobacion formal ejecutar proceso de cierre del contrato

1. 2.

Formalizar el Comit Ejecutivo del Proyecto. Formalizar el comit Operativo del proyecto

Estamos abiertos a cambios y sugerencias de tu parte, debemos formalizar esto a mas tardar esta semana, para poder cumplir con las fechas de presentacin de este informe.