TABLA DE CONTENIDO INTRODUCCION.........................................................................................................................................3 CAPITULO 1...............................................................................................................................................5 CONCEPTOS DE LA GERENCIA DE PROYECTOS..................................................................................5 CONTROL ADMINISTRATIVO Y CONTROL TÉCNICO ........................................................................................................5 LA GERENCIA DEL PROYECTO COMO UN PROCESO DE RESOLUCIÓN DE PROBLEMAS..............................................................6 GERENCIA DE PROYECTOS BASADA EN EL EQUIPO DE TRABAJO.......................................................................................7 PARTICIPACIÓN ACTIVA DE LA ALTA GERENCIA...........................................................................................................7 SESIONES DE PLANIFICACIÓN RÁPIDA DE APLICACIONES (RAP)....................................................................................7 EL CONJUNTO DE INFORMACIÓN CRÍTICA 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: PLANIFICACIÓN DETALLADA DEL PROYECTO.................................................................................................20 TAREA 1: REVISIÓN DEL BUSINESS CASE................................................................................................................20 TAREA 2: SELECCIÓN DE LA ESTRATEGIA DE DESARROLLO..........................................................................................20 FIGURA 3.2 ESTRATEGIAS DE DESARROLLO.....................................................................................23 Acerca del Desarrollo Rápido de Aplicaciones (RAD)...........................................................................24 TAREA 3: DESARROLLO DE LA EVALUACIÓN DE RIESGOS............................................................................................25 Complejidad del sistema.........................................................................................................................25 Ambiente de los Usuarios clave.............................................................................................................25 Ambiente del Grupo de Proyecto...........................................................................................................26 Acerca de las Métricas de Software ......................................................................................................26 TAREA 4: SELECCIÓN DE LAS TAREAS.....................................................................................................................27 TAREA 5: ESTIMACIÓN DE LAS TAREAS....................................................................................................................30 ESTIMANDO EL ESFUERZO DE LA TAREA...................................................................................................................30 Estimando el esfuerzo y la duración de las tareas.................................................................................31 TAREA 6: CRONOGRAMA DEL PROYECTO.................................................................................................................32 UNA REVISIÓN A LA PLANIFICACIÓN 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 situación del proyecto..........................................................................................................37 FIGURA 4.1REPORTE SEMANAL DE SITUACIÓN..........................................................................................................37 FIGURA 4.2 REPORTE MENSUAL DE SITUACIÓN.........................................................................................................38 FIGURA 4.3 SOLICITUD DE CAMBIO........................................................................................................................39
1
Figura 4.6 Registro de Solicitudes de Decisión......................................................................................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 Aprobación de proyectos y etapas de proyectos...................................................................................63 Seguimiento y revisión de proyectos......................................................................................................64 Asistencia al proyecto.............................................................................................................................64 Resolución 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 INTRODUCCIÓN....................................................................................................................................................72 EL CUESTIONARIO...............................................................................................................................................74 PESOS PARA LA EVALUACIÓN DEL RIESGO...............................................................................................................74 MÁS ACERCA DE LAS MÉTRICAS 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 REVISIÓN EN CADA ETAPA DEL CICLO DE VIDA DEL PROYECTO.......................................................................95 Estudio de Factibilidad............................................................................................................................95 Definición de los requerimientos.............................................................................................................95 Especificación del sistema......................................................................................................................95 Diseño del sistema..................................................................................................................................95 Desarrollo del sistema............................................................................................................................96 Protocolo de pruebas..............................................................................................................................96 Implantación............................................................................................................................................97 Mantenimiento.........................................................................................................................................98
2
INTRODUCCION En un ambiente de sistemas de información caracterizado en sus aspectos técnicos y tecnológicos por una alta integración entre los datos, las funciones, el usuario y el ambiente de computación, se hace necesario también definir un nuevo paradigma en cuanto a la gerencia de proyectos de sistemas de información se refiere. Se requiere de un nuevo enfoque para la formación de equipos humanos, estructura organización y técnicas de administración 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 organización como la existencia de sus empleados. Se dice que sólo podemos manejar aquellas cosas que podemos medir. Luego, si no podemos medir lo que creamos, surgirán factores subjetivos o indirectos que serán 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 precisión, y monitorear constantemente, el esfuerzo realizado contra un conjunto de estándares 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 ayudarán 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 mínimos del usuario, o es implantado tan tarde que ya no es efectivo, o excede inaceptablemente sus presupuestos de desarrollo o de operación. También existen razones puramente políticas que llevan al fracaso de un proyecto, pero esas son las más impredecibles y menos previsibles. Entre las razones previsibles más comunes están: • Ausencia de especificaciones claras y entendibles. • Documentación de baja calidad.
• • • • • •
Una pobre comunicación. 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.
¿ Cómo 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 políticas para que fracase el proyecto, se pueden hacer muchas cosas que ayudarán a mejorar las probabilidades de culminar el proyecto exitosamente. Conceptos como dividir para conquistar, mínimo producto mensurable, revisiones, presencia activa de QA, conjunto mínimo aceptable de pruebas, equipo de proyecto adecuadamente organizado, control de cambios, y acuerdo de niveles de servicio, están 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 organización.
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 través de la vida de un proyecto, utilizando técnicas de administración modernas, para lograr objetivos determinados en cuanto a alcance, costo, tiempo, calidad y satisfacción de los participantes. Existe un grupo de conceptos críticos que definen el enfoque de Gerencia de Proyectos que se quiere desarrollar e implantar: • • • • • • •
Control Administrativo y Control Técnico. La Gerencia de Proyectos como un proceso de solución de problemas. La Gerencia de Proyectos orientada a Equipos de Trabajo. El involucramiento de la Alta Gerencia en los proyectos. Sesiones de Planificación Rápida de Aplicaciones. El conjunto de información crítica para la gerencia del proyecto. Gerencia de Proyectos en tiempo real.
Control Administrativo y Control Técnico La gerencia de proyectos se enfoca hacia los aspectos administrativos y del negocio de un proyecto. Su interés 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 información: la información administrativa o del negocio, y la información técnica. ADMINISTRATIVA
Proyectosdependientes Riesgos Beneficios Costos Cronogramas Prioridades Estimados Recursos Suposiciones
TECNICA
Especificacionesfuncionales Modelo dedatos Diagramas dediseño Alcance Diseño de bases dedatos/archivos Objetivos Especificaciones demódulos Estrategia Documentación Calidad Entrenamiento Programas y procedimientos Planes deprueba
Figura 1.1 Definición del proyecto: Aspectos Administrativos y Técnicos
Estos dos grupos tienen en común los objetivos, alcance, calidad y estrategia del proyecto. Los aspectos técnicos del proyecto deben ser resueltos por el personal técnico y controlados por el sistema de control técnico. Por ejemplo, problemas como defectos en el software, fallas de la red local, etc., son aspectos técnicos que debe resolver el personal técnico más calificado. El problema que el Gerente del Proyecto debe resolver es el impacto de los aspectos técnicos en el ambiente de administración tales como fechas de entrega, productos, personal, etc. El Gerente del Proyecto debe facilitar el proceso de solución técnica, sin involucrarse en la solución del problema, pero sí en el qué y el por qué de la solución. En resumen, el proceso de administración del proyecto está interrelacionado con la naturaleza técnica del proyecto, pero debe mantenerse tan independiente como sea posible de los detalles en cuanto a los aspectos técnicos. La gerencia del proyecto como un proceso de resolución de problemas. Es razonable afirmar que todos los proyectos estarán sujetos a cambios, interrupciones y presión. La experiencia demuestra que los proyectos, a medida que se desarrollan, sufren cambios en los objetivos y ampliación del alcance, que dejan a los estimados iniciales del proyecto muy lejos de la realidad. Adicionalmente, los proyectos están sujetos a rotación del personal, problemas de calidad, cambios de prioridades y otros aspectos relacionados con una duración más prolongada de ellos. Como resultado de esto, la gerencia del proyecto debe estar pendiente del seguimiento, evaluación y control de las variaciones con respecto a los conceptos iniciales del proyecto. Muchos proyectos dedican más tiempo y esfuerzos a tareas reactivas para arreglar los inconvenientes que se presentan, que lo que estarían dispuestos a invertir en la planificación productiva para prevenirlos. Se debe luchar por eliminar la idea arraigada en el personal técnico, que la planificación es una carga que los distrae del objetivo principal de diseñar, programar e implantar sistemas. Se debe enfatizar que las actividades de planificación y administración 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 identificación de los problemas potenciales en un proyecto y su resolución proactiva o su minimización, son la clave del enfoque de la gerencia de proyectos.
Gerencia de proyectos basada en el equipo de trabajo. El uso de técnicas de trabajo en equipo y de métodos formales orientados a la solución 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 mayoría de los miembros del equipo de trabajo, los representantes de usuarios y los diferentes grupos de soporte técnico y administrativo. Entre las ventajas del trabajo en equipo se tienen: • Los planes del proyecto, la información de soporte y la información de seguimiento del proyecto serán más precisas. • Los miembros del equipo estarán comprometidos más profundamente con los planes en la medida que ellos sean parte integral de su desarrollo. • La información del proyecto será aceptada con más facilidad en la medida en que la base de entrada de los datos sea compartida por la mayoría de las personas involucradas. Participación Activa de la Alta Gerencia Este es uno de los aspectos más críticos del enfoque que se está exponiendo. Hay oportunidades en que se presentan situaciones que requieren de decisiones que están fuera del control o delegación 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 reestructuración 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 “añadir valor” a los procesos de administración de los proyectos. Finalmente, La Alta Gerencia debe desempeñar su rol en la resolución de los problemas así como también continuar desempeñando sus tareas tradicionales de aprobación, seguimiento y revisión. Sesiones de Planificación Rápida de Aplicaciones (RAP) Un elemento adicional a los procesos de planificación basados en trabajo en equipo, es el uso de sesiones de planificación altamente estructuradas. Al igual que los procesos de desarrollo de sistemas se han acortado debido a la utilización de Planificación Conjunta de Requerimientos (JRP), Diseño Conjunto de Aplicaciones (JAD) y
Desarrollo Rápido de Aplicaciones (RAD), se hará uso de las técnicas asociadas a dichos procesos para el mejoramiento de la planificación. 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 técnico (Operaciones, Redes, Administración de base de datos, etc.). Típicamente, las sesiones RAP duran de uno a tres días. Las sesiones RAP pueden ser apoyadas por el uso de sistemas automatizados para la estimación y preparación de cronogramas. El conjunto de información crítica para la Gerencia del Proyecto. Como se muestra en la Figura 1.1, se requiere de dos grupos de información para entender las características de un proyecto. La primera se refiere a los aspectos técnicos 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 información de los aspectos administrativos del proyecto. Esta información 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 información administrativa debe ser tan independiente como sea posible de la naturaleza técnica específica del proyecto. El contenido del informe administrativo del proyecto se irá detallando en los siguientes capítulos; sin embargo, un esquema general del mismo es como sigue:
• • • • • • • • • • •
Objetivos Alcance Áreas, grupos y proyectos clave externos Fechas de eventos críticos Beneficios Costos Riesgos Calidad en los productos Estrategias de desarrollo Personal Cronogramas/tareas
La información para la gerencia del proyecto debe ser considerada como la base para un acuerdo/contrato del proyecto, y será el vehículo 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 podría catalogar de turbulento, impredecible, con tecnologías 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 microplanificación como la macroplanificación. La planificación en tiempo real o microplanificación implica la planificación detallada de un proyecto por períodos limitados, en el entorno de 3 a 6 meses. El enfoque de microplanificación, aunado a las sesiones RAP, conduce a la ejecución de sesiones periódicas e intensivas de planificación (con una frecuencia mínima quincenal) para el desarrollo detallado de actividades del siguiente período (lo que es diferente de la planificación de la siguiente fase o subproyecto), a la actualización de la información de la gerencia del proyecto, a desarrollar la solución a los problemas presentados y a informar al Comité del Proyecto sobre cualquier variación potencial para su revisión y aprobación a nivel gerencial. Se debe enfatizar que la frecuencia de los procesos de microplanificación depende en gran medida de los niveles de riesgo del proyecto. Lo que es esencial es que la información y la planificación del proyecto siempre reflejen la realidad de éste. Mientras más turbulencia se presente en un proyecto, más frecuentemente se deben realizar las microplanificaciones. En cada oportunidad que se presente un cambio en cualquiera de los componentes del conjunto de información 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 sesión RAP para evaluar el impacto del cambio, determinar alternativas y opciones de solución, desarrollar planes alternos y, si se requiere, buscar la aprobación de la Alta Gerencia y del Usuario Cliente para poder continuar el proyecto.
CAPITULO 2 INICIO DE UN PROYECTO El modelo de administración de proyectos que se va a desarrollar define 4 procesos administrativos y un proceso de tecnología de información, como se muestra en la siguiente figura: Roles Ejecutivos
SELECCION, APROBACION, REVISION Y SEGUIMIENTO DE LOS PROYECTOS
Business Case Aprobado
Reportes del Proyecto
Business Case
REVISION DEL PROYECTO
PLANIFICACION DEL PROYECTO ESTUDIO DE FACTIBILIDAD (BUSINESS CASE) Planes del Proyecto
Detalles de Replanificación del proyecto
Detalles de seguimiento del Proyecto
SEGUIMIENTO AL PROYECTO ROLES DEL GERENTE Y DEL GRUPO DE PROYECTO
Figura 2.1Modelo de Administración del Proyecto
Los cuatro procesos administrativos son: • • • •
Selección, aprobación y revisión del proyecto. Planificación del proyecto. Seguimiento del proyecto. Revisión del proyecto.
El proceso correspondiente al Ciclo de Desarrollo de Sistemas es: •
Desarrollo de los Términos de Referencia o Business Case.
Este capítulo 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 más importante. Paso 1: Inicio del proyecto Este proceso implica una compleja interrelación entre el nivel gerencial, los planificadores estratégicos, 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 críticas para el proceso de selección, aprobación y revisión de los proyectos, ellos dependen para su trabajo de un conjunto de información clave del proyecto. Esta información 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 técnicamente. La forma en que esto normalmente ocurriría está basada en que durante el ejercicio de planificación estratégica la alta gerencia ya habría identificado los proyectos clave, es decir, aquellos que reflejan su adecuación a la misión y dirección corporativa. Este plan estratégico podría también incluir algunos proyectos adicionales o algunas iniciativas resultantes de eventos externos sucedidos luego de la finalización del ejercicio de planificación estratégica (Figura 2.2). En la mayoría de los proyectos, la alta gerencia aprueba la primera etapa de inicio del proyecto: la culminación del Estudio de Factibilidad, que se refleja en el producto Términos de Referencia o Business Case. Esto implica un estudio de alto nivel del proyecto, incluyendo el análisis inicial del sistema y la producción de dos conjuntos clave de información: • •
La descripción técnica del proyecto y las propuestas de solución. El Business Case o Términos de Referencia del proyecto.
El desarrollo de la descripción técnica debe incluir modelos de datos iniciales de alto nivel, diagramas de flujo de datos, descripción del problema y propuestas de alternativas de diseño. La calidad del material preparado es crítica para el Business Case, ya que es la base para las estimaciones y los requerimientos de calidad.
Nuevos proyectos
Clientes
Business Case Aprobado
INICIO DEL PROYECTO
Planes estratégicos
SELECCION, APROBACION, REVISION Y SEGUIMIENTO DE LOS PROYECTOS
Unidad de Planif. Estrat.
Clientes
Business Case Requerimiento Inicial
PLANIFICACION DEL PROYECTO
Reportes del Proyecto
REVISION DEL PROYECTO
ESTUDIO DE FACTIBILIDAD (BUSINESS CASE)
Detalles de Replanificación del proyecto
Planes del Proyecto
Grupo del Proyecto
Detalles del seguimiento 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 Términos 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 planificación del proyecto. El proceso típico para desarrollar el Business Case es la producción de un “borrador” inicial, al comienzo del Estudio de Factibilidad, el cual se va puliendo a medida que progresa el estudio. La versión final se produce con la finalización del Estudio de Factibilidad y se remite al Comité del Proyecto para su aprobación 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 información, y evitar involucrarse en el “cómo”. Las preguntas pertinentes son: ¿qué se quiere hacer? (La especificación) y ¿ por qué se quiere hacer? (El beneficio o retorno de la inversión). Como Gerente Usuario incorporado al negocio de sistemas, se está más cerca de la cuestión del “por qué” que el personal de Tecnología de Información. Cuando se está envuelto en una reunión de sistemas de información, 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 básicos para el seguimiento del proyecto, desde su inicio hasta su culminación. Como ya se ha mencionado, es normal que un proyecto esté sujeto a variaciones y cambios. El Business Case es la herramienta básica para hacer el seguimiento y controlar los cambios en el proyecto. El Business Case debe contener la siguiente información: •
• •
• • •
Antecedentes y descripción del proyecto: Una descripción breve de los antecedentes y del proyecto. Es importante en este punto incluir una definición muy clara de los objetivos del negocio. En la implantación de sistemas complejos, la ausencia de una real necesidad produce dificultades casi insuperables, porque no se encuentra colaboración entre los usuarios, casi siempre reacios a invertir tiempo y esfuerzos para facilitar el éxito del proyecto. Alcance del proyecto: Una definición clara de las áreas de impacto del proyecto y de sus límites. Objetivos del proyecto: Una descripción precisa de los objetivos del proyecto desde los puntos de vista estratégico, 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 organización espera obtener al poner en operación el proyecto. Costos del proyecto: Los costos de personal, tiempo, equipos, etc. involucrados en la ejecución del proyecto. Estrategia de desarrollo: La secuencia y segmentos del proyecto en versiones y subproyectos.
• • •
• •
•
• • •
Evaluación de los riesgos del proyecto: Una evaluación 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 descripción y recopilación de cualquier legislación o política 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 definición clara de los perfiles requeridos para el personal necesario en el proyecto, así como una primera propuesta de organización para el proyecto. El soporte y la colaboración de todos los niveles de la gerencia de la empresa son condiciones básicas 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, acompañado por un miembro exitoso del equipo de Tecnología de Información. Proyectos relacionados: Una descripción de cualquier otro proyecto que dependa o esté interrelacionado con el proyecto propuesto, así como la integración del sistema bajo estudio con los sistemas existentes. Suposiciones, condiciones y restricciones: Se refiere a elementos tales como fechas de culminación propuestas o impuestas, tecnología seleccionada, etc. Calidad en el proyecto: Una definición que incluya medidas de la calidad requeridas de los productos del proyecto. Descripción técnica del proyecto: Este es un anexo que debe cubrir al menos los siguientes tópicos: Necesidades o deficiencias potenciales de sistemas existentes. Una conceptualización que ofrezca una guía estratégica para eliminar deficiencias existentes o potenciales, sobre todo en cuanto a la fuente y uso de los datos críticos del sistema. Propuestas de alternativas de diseño. Diagrama de flujo de procesos de alto nivel. Diagrama de flujo de datos de alto nivel.
Para producir esta información se requiere del concurso del Gerente del Proyecto, quien es responsable por los estimados, estrategia de desarrollo, evaluación de riesgos y cálculo 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 técnicos en sistemas. Es también 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 planificación del proyecto es la relacionada con su alcance.
Para muchas personas, alcance y objetivos son similares, cuando es más útil verlos como interrelacionados pero diferentes. El alcance de un proyecto define los límites de responsabilidad del Gerente del Proyecto, mientras que el objetivo del proyecto define lo que el Gerente del Proyecto debe lograr dentro de esos límites. 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 estándares de calidad. En proyectos de sistemas de información, uno de los aspectos críticos 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 crítico en grandes proyectos, donde los elementos del sistema que no están computarizados pueden llegar a ser significativamente mayores que los computarizados.
Alcance del proyecto
Alcance del sistema computarizado
Fig . 2.3 Alcances del sistema computarizado y del proyecto
Figura 2.3 Alcances del proyecto y del sistema automatizado El alcance de los procesos automatizados puede ser definido gráficamente utilizando técnicas tales como diagrama de flujo de datos (DFD) y modelos de datos. Sin embargo, como ya se mencionó, excepto para pequeños procesos automatizados, el alcance de la parte automatizada es un subconjunto del alcance del proyecto. Todos los sistemas de información impactan, en alguna forma, a la organización y a su personal. La implantación exitosa de un nuevo sistema de información, o de las
mejoras a uno existente, requerirá del rediseño o creación de procedimientos, alteraciones de la planta física, definición de nuevos roles en la organización y nuevos procesos de control gerencial y administrativo. Adicionalmente, los grandes proyectos pueden abarcar aspectos legales, gerencia financiera, un soporte administrativo mayor que incluya logística de viajes y compras mayores, alquiler de espacios de trabajo, etc. Esos proyectos requieren de un número de actividades externas al sistema de información 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 explícitamente tanto los objetivos de la parte automatizada como de la parte manual del sistema de información. 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 crítico y se convierte en área de alto riesgo. Una mecanismo muy útil para establecer el alcance del proyecto es utilizar una modificación de una técnica desarrollada por Kepner y Tregoe (1981) para la definición de problemas. Como se muestra en la figura 2.5, esta técnica 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 cuándo proceder con el Paso 2 del proceso de planificación del proyecto; la Planificación Detallada del Proyecto y su subsecuente desarrollo. Es importante entender que la aprobación de un proyecto es más una decisión de negocios que una decisión técnica.
Definición del Alcance Proyecto: Automatización de la oficina Está en el alcance No está en el alcance Instalación de estaciones Suplir las LAN’s de trabajo Diseño del entrenamiento
No se sabe Definición de la interfaz del Usuario
Dar el entrenamiento
Producción de las guías Soporte al software del Usuario Figura 2.5 Modelo modificado de Kepner y Tregoe para definición del Alcance Sobre los estimados iniciales Es problemático justificar económicamente los proyectos al inicio del estudio. Los análisis 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 variación 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.
Revisionesdel Com itédel Proyecto
Presentacióndel BusinessCase
REVISIONDELCOM ITE (Aprobaciónpara procederconel EstudiodeFactibilidad)
PLANIFICACION INICIAL ESTUDIODE FACTIBILIDAD (BUSINESSCASE)
REVISIONDELCOM ITE (Aprobaciónpara procederal análisisde Requerim ientosocon el desarrollototal)
PLANIFICACION DETALLADA
BusinessCase aprobado
ANALISISDELOS REQUIRIM IENTOS PLANIFICACION DETALLADA DISEÑODEL SISTEM A PLANIFICACION DETALLADA DESARROLLODEL SISTEM A PLANIFICACION DETALLADA INSTALACIONDEL SISTEM A PLANIFICACION DETALLADA
BusinessCase aprobado
M I C R O P L A N I F I C A C I O N
REVISION PO ST-IM PLANTACION
REVISIONDELCOM ITE (Aprobaciónpara procederconla siguientefasede desarrollo) REVISIONDELCOM ITE (Aprobaciónpara procederconla siguientefasede desarrollo)
REVISIONDELCOM ITE (Aprobaciónpara procederconla siguientefasede desarrollo)
REVISIONDELCOM ITE (Revisióndela culm inacióndel proyectoyaprobación dem ejorasiniciales)
CONTINUANDO CONLA PLANIFICACION DELDESARROLLO
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 planificación: Una sesión de planificación detallada del proyecto. La técnica a utilizar para este trabajo es la de sesiones de Planificación Rápida de Aplicaciones, RAP. La Figura 3.1 muestra los seis pasos del modelo, sistemáticamente:
que deben ser ejecutados
C ronogram adelProyecto y B usinessC aseA ctualizado
B usinessC ase A probado
PL A N IFIC A C IO ND E LPR O Y E C TO
R EV ISIO N D EL B U SIN ESS C A SE
C R O N O G R A M A D EL PR O Y E C T O
B usiness C ase R evisado
Estim ados delas Tareas
SE L E C C IO N D EL A E ST R A T E G IA D E D ESA R R O L L O
E ST IM A C IO N D EL A S T A R E A S
Estrategiasde desarrollodel proyecto D ESA R R O L L A R L A E V A L U A C IO N D ER IE SG O D EL A S E ST R A T E G IA S
Tareas
R iesgos Evaluados
SE L E C C IO N D EL A S T A R E A S
Figura 3.1Planificación Detallada del proyecto El plan resultante de la aplicación del modelo es la base para el seguimiento y el reportaje del proyecto. La situación 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 replanificación. El Reporte de Progreso recopila información de todas las tareas del proyecto, para su revisión por el Comité del Proyecto y otros gerentes y usuarios que se vean afectados por el proyecto.
La planificación es realizada al comienzo de cada proyecto y repetida regularmente durante la vida del proyecto vía microplanificación y sesiones RAP. Este el concepto de Gerencia de Proyectos en Tiempo Real que se aplica en la metodología 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 preparación del cronograma y la planificación detallada no se comienzan hasta el inicio de la etapa de Análisis de Requerimientos de la primera fase del ciclo de desarrollo. Este enfoque de proyectos implica el desarrollo de una planificación detallada y la producción del cronograma respectivo al comienzo de cada fase y sólo para esa fase. El plan general del proyecto ofrece información de todas las fases en una forma menos detallada y en muchos casos, se debe considerar esta información como una aproximación a los tiempos y recursos requeridos por el proyecto. Sólo hasta que se evalúen las diferentes alternativas, el Gerente del Proyecto no puede precisar el Plan de Diseño de Sistemas y las fases subsecuentes. Paso 2: Planificación Detallada del Proyecto Como se observa en la Figura 3.1, la planificación detallada se realiza mediante 6 pasos interrelacionados e iterativos. Aunque están 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 conformaría 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 revisión de los estimados iniciales. La planificación del proyecto está basada en el desarrollo de sesiones con alta participación del equipo, el Gerente del Proyecto, representantes de los Grupos clave y de otros proyectos relacionados, y de representantes de los grupos de soporte técnico que interesan al proyecto. Tarea 1: Revisión del Business Case El primer proceso es la revisión del Business Case. Si el proyecto que está siendo planificado no tiene el Business Case, entonces se comenzará con la recopilación de esta información (en particular, la evaluación 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: Selección de la Estrategia de desarrollo.
Se debe distinguir entre la metodología 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 metodología se refiere a las tareas específicas que deben realizarse durante el ciclo de desarrollo de sistemas. La estrategia adecuada es altamente dependiente del riesgo y del tamaño del proyecto. Se pueden definir cuatro estrategias básicas de desarrollo: •
Monolítica: Define al desarrollo del sistema como un todo, con cada fase como una actividad independiente y predecesora de las siguientes. Por ejemplo, el diseño no se comienza hasta que el análisis esté completado. Esta estrategia es recomendable para proyectos de bajo riesgo o cortos (menos de 6 meses) y para grupos de trabajo pequeños (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 Versión 1; luego se añade un segundo subsistema como Versión 2, etc. El usuario podrá obtener componentes “semi-operacionales” del sistema por adelantado. Por ejemplo, la Versión 1 podría incluir todos los componentes de la entrada de datos que crean las bases de datos activas del sistema. Mientras la Versión 2, que se encarga de los componentes de salida está siendo desarrollada, los usuarios pueden accesar los datos mediante queries. En la Versión 3, todas las facilidades de base de datos podrían ponerse a disposición 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 producción de “prototipos” tan rápido como sea posible. Esto puede ser logrado minimizando la adherencia a los estándares y/o utilizando lenguajes de alto nivel o generadores de aplicaciones. El primer “prototipo” operacional será optimizado a través 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. •
Híbrido: Es una modificación de la estrategia de Versiones Concurrentes. La estrategia híbrida 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 desarrollaría utilizando la estrategia monolítica. •
El siguiente cuadro ofrece lineamientos para la selección apropiada de la estrategia:
Duración del Proyecto
Riesgo
Estrategia
Menos de 3 meses
Bajo Medio Alto
Monolítico Versiones Desarrollo Acelerado
3 - 6 meses
Bajo Medio Alto
Monolítico o por Versiones Versiones Versiones o Acelerado
Más de 6 meses
Bajo Medio Alto
Versiones Versiones Híbrido o Acelerado
Generalmente, cuando se manejan grupos de proyecto mayores a 5-7 personas, se recomienda el uso de las estrategias de Versiones o Híbrida. 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. ESTRATEGIA MONOLITICA
FASE A
FASE B
FASE C
FASE D
ESTRATEGIA DE VERSIONES SECUENCIALES Versión 1 FASE A
FASE A
FASE B
Versión 2 FASE C
FASE D
FASE A
FASE B
FASE C
FASE D
ESTRATEGIA DE VERSIONES CONCURRENTES Versión 1 FASE A
FASE A
FASE B
FASE A
FASE B
FASE C
FASE D
Versión 2 FASE C
FASE D
ESTRATEGIA DE VERSIONES ACELERADAS Versión 1 FASE A
FASE B
FASE C
Versión 2 FASE D
FASE A
EVALUACION
ESTRATEGIA HIBRIDA
FASE B
Monolítica Versión 1
FASE A
FASE A
FASE B
FASE C
FASE D Concurrente
Versión 2 2.1
FASE A
FASE B
FASE C
FASE D
2.2
FASE A
FASE B
FASE C
FASE D
Figura 3.2 Estrategias de Desarrollo
FASE C
FASE D
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 Análisis 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 diseño, el desarrollo y la implantación, por lo que pudiera adoptar una estrategia más conservadora, tal como Versiones Secuenciales o Monolíticas. Si tuviese que elegirse una estrategia Híbrida o de Versiones, el sistema se podría empaquetar en versiones en tres puntos clave: • • •
Al final del Estudio del Business Case. Al final de Análisis Detallado de Requerimientos. Al final del Diseño de Sistemas.
Se debe enfatizar que previo a la partición del sistema en subsistemas, el Gerente del Proyecto y su Grupo, deben desarrollar una representación del sistema (DFD, Cartas Estructuradas, DFP) con suficiente detalle como para poder asegurar una mínima interdependencia de datos. Mientras más temprano se quiera dividir el sistema, más riesgos se tendrá de que los subsistemas no se puedan separar limpiamente. Esto se hace para poder asegurar que cada versión pueda ser tratada como un subsistema virtualmente independiente. Para realizar esta partición se debe contar activamente con el Administrador de Datos o el Supervisor de Recursos de Información durante la etapa de planificación del proyecto. Adicionalmente, al estar desarrollándose concurrentemente múltiples 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 modificación o alteración 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 preocupación debe tenerse sobre las funciones de negocios comunes que deben ser compartidas entre los subsistemas. Acerca del Desarrollo Rápido 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 diseño estructurado, diseño de los archivos, especificaciones de programas, etc. El proceso de partición de los sistemas en pequeñas versiones, que son luego desarrolladas utilizando estrategias secuenciales o concurrentes, ha sido denominado como Desarrollo Rápido de Aplicaciones. Algunas versiones de esta estrategia sugieren la partición del sistema en versiones que pueden ser desarrolladas e implantadas en un término de 90 a 120 días.
Tarea 3: Desarrollo de la Evaluación de Riesgos. La Evaluación de Riesgos normalmente se realiza durante el desarrollo del Business Case y es revisada y actualizada durante cada proceso de planificación por el Grupo de Proyecto. La Evaluación 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 composición del Grupo de Proyecto, el uso de la metodología, las estrategias para el desarrollo del sistema, y sobre todo, sobre la decisión de la Organización de aprobar el proyecto. En otras palabras, a mayores riesgos en el proyecto, es más grande la probabilidad de que los estimados, los cronogramas y la planificación 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 técnica de Puntos Función de la IBM y se considerará la complejidad de sus datos, es decir, cuántas entradas, salidas, consultas, archivos lógicos internos y archivos compartidos están involucrados en el sistema. Otros aspectos que también afectan la complejidad o el riesgo son: • Funciones y algoritmos. • Controles complejos, decisiones por excepción, y/o operaciones matemáticas. • Procedimientos actuales. • Impacto significante en los puestos de trabajo. • Requerimientos de comportamiento. • Grandes volúmenes de datos, tiempos de respuesta rápidos para minimizar el uso de la red, CPU, etc. • Requerimientos especiales de tecnología. • Uso intensivo de Hardware y/o Software especialmente diseñados para el sistema. Ambiente de los Usuarios clave La complejidad o riesgo de los Usuarios clave está relacionada con las siguientes áreas:
• El número de sitios donde opera el usuario (secciones, departamentos, agencias, sucursales y otras instalaciones) y que están afectados por el sistema. • El nivel de conocimientos y la actitud de participación 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 físico 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 físico para el Grupo de Proyecto.
Es obligatorio que el Gerente del Proyecto considere todos estos criterios de riesgos a través de los diferentes procesos del proyecto, y especialmente durante la planificación, utilizando el cuestionario formal contenido en el Capítulo dedicado a desarrollar el Modelo de Evaluación de Riesgos. Si el Gerente del Proyecto considera que la combinación 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 Memorándum 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 Métricas de Software La evaluación de riesgos que se ha definido es subjetiva. El proceso de cuantificar los diferentes factores de riesgo se define como Métrica 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 implicaría riesgos mayores que con los experimentados (manteniendo todas las demás variables iguales). Aunque se han realizado muchos intentos por cuantificar estas medidas de experiencia, los resultados obtenidos no permiten llegar a una conclusión única: diferentes autores del área han presentado trabajos donde la relación de productividad varía desde una de 26:1, otra de 10:1 hasta una tan pequeña como 2:1. Definitivamente esto es un problema. Se han estimado más de 100 factores que influyen significativamente en la productividad y en el riesgo de un proyecto y muchos de ellos son, para todos los propósitos prácticos, inconmensurables (por ejemplo, ¿cuál es el impacto cuantificado de las políticas de una organización entre dos grupos de Clientes clave?). Como se observa, el área de métricas de software es bastante imperfecto. Sin embargo, el uso más efectivo de las métricas de software es utilizar las que estén disponibles para apoyar los criterios subjetivos de la evaluación de riesgo y así, ajustar los estimados siempre que sea posible. Tarea 4: Selección 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 identificación 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 estimación de abajo hacia arriba y la obtención final de un cronograma detallado del proyecto. Con el tiempo, las organizaciones van desarrollando cronogramas estándares para los diferentes tipos de proyectos, tales como desarrollos internos, selección de paquetes, etc. Dependiendo del riesgo y naturaleza del proyecto, se deben combinar, eliminar, o añadir tareas y subtareas de los estándares ya desarrollados. Por ejemplo, se puede requerir añadir tareas para una selección de hardware, y no necesitarse las tareas relacionadas con base de datos. Esta adaptación la realiza el Gerente del Proyecto junto con especialistas de las áreas de interés requeridas por el proyecto. En caso de no existir los estándares, o si el proyecto bajo estudio no se adapta a los existentes, el grupo de planificación debe realizar sesiones especiales para obtener la lista detallada de las tareas que representarán posteriormente al proyecto. Idealmente, las actividades de una fase del proyecto (tareas, subtareas) no deben tener una duración de más de 10 días calendario. Esto no debe confundirse con la cantidad de trabajo que se realizará en ese período ya que, por ejemplo, una tarea podría requerir de 2 personas por 15 días, lo que nos daría 30 días de esfuerzo de trabajo. Cuando una tarea excede de los 10 días, se la debe separar en tareas más pequeñas. 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 separación del proyecto en tareas es clave para la estimación, ya que asegura que el equipo de trabajo entiende la magnitud del trabajo que debe ser hecho. Una de las causas más 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 participación integral del equipo de trabajo y los Usuarios clave usualmente conducen a lograr una lista exhaustiva y precisa de las tareas requeridas.
Examinar documentación del paquete Contactar a usuarios del paquete Preparar los datos de prueba Evaluar el paquete
Verificar la información económica-financiera Auditar al proveedor del paquete Visitar a usuarios del paquete Probar el paquete Verificar los acuerdos de servicio
Figura 3.3 División del trabajo para su control Macro-estimado
Obtenido utilizando Punto función
(75) Proyecto A Fase 1, (15)
Fases 2 + 3 (61)
Micro-estimado
Obtenido utilizando porcentajes
Fase 1 (15)
Tarea A
Fase 2
(20 %)
(5) Tarea B
Micro-estimado
(6) Tarea C (4) Obtenidos utilizando estimados basados en las tareas
Figura 3.4 Macro y Micro-técnicas de estimación
(38)
(50 %)
Fase 3
(23)
(30 %)
Tarea 5: Estimación de las tareas Existen actualmente varias técnicas de estimación, entre las cuales destaca la macrotécnica de Punto Función, con la cual se puede lograr un estimado para el esfuerzo de desarrollo total del proyecto y luego, con microtécnicas tales como bottomup o basadas en las tareas individuales, ir ensamblando los tiempos hasta lograr llegar a la fase completa. La microtécnica se requiere para poder desarrollar el cronograma del proyecto. Como se muestra en la figura 3.4, el enfoque típico es el de un estimado inicial usando Punto Función y luego usar éste para correlacionarlo con un segundo estimado desarrollado bottom-up vía una microtécnica tal como “Wide-Band Delphi” (Ver Capítulo 9). Los estimados a nivel de tareas son agregados para lograr un estimado de la fase el cual, de existir una metodología estándar, puede ser usado para derivar otro valor del esfuerzo total de desarrollo utilizando el porcentaje de cada fase como una guía. 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 días necesarios para realizarla. Con el tiempo, las organizaciones cuentan con metodologías maduras que incluyen el registrar y mantener información sobre nombres comunes de tareas y sus duraciones provenientes de todos los proyectos, lo que servirá de guía para saber el tiempo y los recursos que consumen las tareas en proyectos similares. Con esto se obtiene la base de datos de métricas de los proyectos. Mientras no se cuente con esta base de datos, se sugiere las siguientes guías: • • •
•
Mientras más pequeñas y específicas sean las tareas/subtareas de una actividad, más fácil será obtener sus estimados. Mientras mayor sea el riesgo de un proyecto, serán mayores las posibilidades de errores de estimación. Los estimados realizados por un grupo, por ejemplo durante las sesiones de definición de las tareas, deben ser obtenidos promediando los estimados de cada uno de los miembros para cada tarea/subtarea, utilizando técnicas como la WideBand Delphi. Realice los estimados asumiendo que el trabajo lo realiza una sola persona, y calcule el esfuerzo de trabajo en días-hombre y no en duración. El traslado de díashombre a días calendario y la distribución de los recursos disponibles se hará durante la construcción de los cronogramas.
Es esencial definir los estimados como un rango y no un número único, especialmente durante las fases iniciales del desarrollo del proyecto. El uso de técnicas de análisis de sensibilidad será de gran utilidad para lograr los mejores valores para el proyecto. Esta técnica involucra la obtención de estimados de tres categorías:
• Valor optimista/el mejor caso. • Valor realista/más probable. • Valor pesimista/el peor caso. El valor optimista se logra suponiendo que todo marcha sobre ruedas. El realista refleja la situación más probable y en general la experiencia de trabajo de cada elemento del grupo, y la pesimista supone que lo que podría 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 utilizarían los estimados optimistas o realistas. A medida que el proyecto presenta más 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 más 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 utilizarán 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 ecuación: Valor esperado = [Optimista + (4 x Realista) + Pesimista] / 6 Estimando el esfuerzo y la duración de las tareas Una de las causas que más influyen en una mala estimación tiene que ver con la diferencia entre el trabajo o esfuerzo directo (horas-hombre) y la duración calendario requerida para realizar el trabajo. El proceso de estimación implica comenzar por calcular el esfuerzo de trabajo para luego llegar a la duración calendario requerida para realizar dicho trabajo. Por ejemplo, un proceso puede haber sido estimado en cuatro horas-hombre de esfuerzo pero requerir de dos días calendario para su ejecución debido a las características 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 duración calendario (DC). Entre las razones típicas que marcan la diferencia entre el esfuerzo y la duración están: • • • • • •
Reparación de defectos en tareas predecesoras completadas con anterioridad. Días no laborables. Asesorías a otros grupos de trabajo. Actividades administrativas extra proyecto. Entrenamiento extra proyecto. Reuniones extra proyecto.
• • • •
Interrupciones, incluyendo el teléfono. Preparación 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 días por cada día de ET, dependiendo de cada proyecto en particular y del ambiente administrativo de la organización en general. Además, la cantidad de “tiempo perdido” varía con el nivel de la persona que realiza el trabajo. Por ejemplo, un 30% de pérdida es típico en el caso de Analistas y Programadores Junior, mientras que se consiguen cifras de “ pérdida” de un 50% o superior cuando se trata de Analistas Senior o Líderes de Proyecto que dedican más tiempo a entrevistas, administración, reuniones, asesoría 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 asignación 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 asignación de recursos. Por ejemplo, las tareas pueden ser programadas linealmente o concurrentemente dependiendo de la disponibilidad de recursos y de la interrelación 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 interés para obtener las personas requeridas en la oportunidad y por el tiempo que se necesite. Idealmente, los representantes de las áreas de interés estarán presentes en las sesiones RAP y llegarán 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 versión 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 cronológico de ejecución, asignarle las personas requeridas. Se debe tener en cuenta en esta actividad que: • Algunas tareas necesitan de habilidades especiales o de un entrenamiento específico para la persona asignada. • Las tareas que dependen de la finalización 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 trabajarán varias personas. De ser necesario, se extenderá la duración 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 construcción 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 estimación acerca de las habilidades y conocimientos de un recurso, tales como la de contar con un Analista Senior con mucha experiencia en el diseño 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 precaución 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 duración probable de la misma es sólo un estimado que necesitará ser revisado posteriormente, una vez que se conozcan las características de las personas asignadas. • El Gerente del Proyecto sólo 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 (días calendario) a todas las tareas, se debe hacer una nueva revisión para asegurarse que están reflejadas todas las interdependencias y que en el caso de tareas que comparten recursos, las personas asignadas realmente están 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 crítico para el proyecto. Este camino crítico produce el tiempo máximo de duración (días calendario) del proyecto y por ende, la trayectoria más larga a través 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 días y la Tarea C se estima en 3 días, lo más temprano que la Tarea D puede comenzar es 4 días después que termine la Tarea A. La Tarea C tiene 1 día de holgura y la Tarea B está en el camino crítico. 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 planificación de proyectos también produce una Carta Gantt (Figura 3.5). Esta carta muestra la duración de las tareas vs. la línea de tiempo e indica
aquellas que están en el camino crítico 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 planificación y seguimiento del proyecto. Toda esta información será usada como base para preparar el reporte de avance de los proyectos. Estos paquetes de software son un ejemplo clásico de lo que conocemos como “si entra basura, sale basura”. Si el proceso de planificación es realizado con información irreal, los cronogramas resultantes son falsos y su uso puede resultar peligroso para el proyecto. Una revisión a la Planificación en Tiempo - Real El enfoque de tiempo real para la planificación implica la repetición del proceso de planificación a lo largo del proyecto. Adicionalmente, en caso de salirse de control el proyecto, se necesitará realizar nuevamente el ciclo de planificación integral. Es muy importante planificar sólo aquellas tareas/fases que “razonablemente” se pueden incluir en un cronograma. El disponer de un paquete de software de planificación hace de la reprogramación una tarea sencilla, por lo que no tiene mucho significado programar inicialmente con alta precisión, en cuanto a su duración, aquellas tareas que, por ejemplo, dependen de que otras 20 tareas culminen en tiempo para ella arrancar. Adicionalmente, la duración de las tareas está en días calendario, lo que hace menos probable que a mediano plazo, las fechas definidas se logren al 100 %. Sencillamente, realice la programación detallada sólo para un período de 3 a 6 meses o hasta el final de la fase actualmente en ejecución. El resto de las tareas deben ser sumarizadas a nivel de fase y pasar al detalle en sesiones posteriores de planificación.
TAREA A
Dependencia
TAREA B
TAREA D
TAREA C
TAREA F
TAREA G
TAREA E
TAREA A
TAREA F
TAREA B
TAREA G
TAREA D
TAREA C
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 técnicas. 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 revisión de la situación del Business Case para determinar cualquier variación actual o potencial. En caso de detectarse alguna variación, en particular sobre el alcance, objetivos o calidad, ésta debe ser formalizada a través del mecanismo de Control de Cambios. De no haber cambios mayores en el Business Case, un objetivo secundario es la comparación, 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 disposición y a su efectividad para cumplir con el plan del proyecto aprobado. Para el propósito tanto del proyecto como de cada tarea individual, las tareas deben ser tomadas como terminadas o no terminadas; los términos “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 síndrome del 90% completado tan común en el medio. Esta técnica 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 algún 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 están en el camino crítico; 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 definirán varios reportes del portafolio que trae el paquete para ser presentados semanal o quincenalmente y mensualmente. Paso 4: Informe del Proyecto
La información 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 tópicos: •
• •
El estado del proyecto: ¿Se mantiene o no de acuerdo con lo planificado? Si no: 1. ¿Cuál es la situación fuera de control y las causas de la variación? 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 situación 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 atención a las fechas de los hitos clave del proyecto. Las Figuras 4.1 y 4.2 ilustran los Reportes de Situación quincenales y mensuales del proyecto. REPORTE SEMANAL Nom bredel Cliente:
Página
Nom bredel Proyecto:
Códigodel Proyecto:
de
Gerentedel Proyecto:
Fecha:
Sem ana queterminael: Logros(esteperíodo):
Planificadoperonocompletado(esteperíodo):
Realizadoperonoplanificado(esteperíodo)
Objetivos (siguienteperíodo):
Problem as/ advertencias:
Figura 4.1Reporte semanal de situación
REPORTE M ENSUAL Nom bredel Cliente:
Página
Nom bredel Proyecto:
Códigodel Proyecto:
de
Gerentedel Proyecto:
Fecha:
Mesreportado: Logros(esteperíodo):
Planificadoperonocom pletado(esteperíodo):
Realizadoperonoplanificado(esteperíodo)
Objetivos (siguienteperíodo):
Problem as/ advertencias:
Figura 4.2 Reporte mensual de situación 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 implantación del sistema. Sin la existencia de un riguroso proceso de negociación que evalúe el cambio y su impacto, es posible que el Business Case y su plan de proyecto asociado desemboquen en una situación tal que haga necesaria una reprogramación drástica 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 estimación, cambio de los miembros del Equipo del Proyecto, lógicas incorrectas, o aspectos técnicos que no pudieron ser previstos durante la planificación inicial del proyecto.
•
Externos, cuando se originan por decisiones políticas de los Usuarios Clave, por descuido o falta de involucramiento en los procesos de definición del proyecto, por nuevas ideas, por requerimientos de otros proyectos o, lo más 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 evaluación y la decisión. •
Solicitud de cambio. Debe venir por escrito en el formato diseñado para tal fin, independientemente de dónde 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 organización.
REQUERIMIENTODECAMBIOS ALPROYECTO Nom bredel Cliente:
Núm erodel Requerim iento:
Nom bredel Proyecto:
Códigodel Proyecto:
Gerentedel Proyecto:
Fecha:
Nom bredel Requerim iento: Motivodel Cam bio- Preparadopor:
Descripciondel Cam bio- Preparadopor:
Costodel Cam bio- Preparado por:
Interrelaciones:
Aprobado (A) Rechazado (R) Por el Contratista:
Por el Cliente:
Nom bre:
Nom bre:
Firm a:
Firm a:
Fecha:
Fecha:
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 línea por cada Solicitud de Cambio. El mismo provee al Comité del Proyecto y al Gerente del Proyecto con una referencia rápida de la situación de los cambios. Se utilizan tres códigos para indicar la situación 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 acción adicional con respecto a esa solicitud.
•
Evaluación. El Gerente del Proyecto, junto con el Equipo del Proyecto y posiblemente otros expertos, evaluarán el cambio. Esto se realiza normalmente mediante una sesión de RAP. La evaluación debe cubrir puntos tales como: • ¿Se justifica realmente el cambio? De ser así: • ¿Es esencial que sea realizado en este momento, o podría ser diferido hasta la fase de Revisión de Post-Implantación, al final del proyecto? • ¿El cambio altera el Business Case del proyecto? • ¿Qué tareas (completadas, en progreso o por comenzar) se afectan? • ¿Cuál es la duración estimada y el esfuerzo requerido para implementar el cambio? • ¿Se requerirá de una reprogramación del proyecto y/o una extensión del tiempo de culminación del proyecto? • ¿Se requerirán recursos adicionales para implantar el cambio? • ¿El cambio afecta a otros proyectos, subproyectos o sistemas? • ¿El cambio requiere de una alteración 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 evaluación y del análisis de impacto deben ser anexados a la forma de solicitud de cambio. •
Decisión. Asumiendo que el Gerente del Proyecto no tiene dudas sobre la implantación 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 extensión del proyecto, el cambio puede ser aceptado. Sin embargo, si al menos uno de los supuestos no se da, se debe llevar la decisión al Comité del Proyecto para su consideración.
Si existe alguna duda o si el cambio es muy grande, el Gerente del Proyecto debe convocar a una reunión del Comité del Proyecto. En esta reunión se deben discutir todos los aspectos relacionados con el cambio y se debe llegar a una recomendación sobre proceder o no con el cambio. Esta recomendación puede requerir de involucrar a los gerentes de las unidades de sistemas y/o usuarias para su confirmación y finalmente al Comité de Alta Gerencia para su aprobación final e implantación.
La decisión 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 culminación del proyecto. Tales decisiones se consideran como definitivas mientras dure el proyecto, para evitar pérdidas de tiempo en la reevaluación de solicitudes viejas. Siguiendo a la decisión de adoptar un cambio, el Gerente del Proyecto debe tomar las previsiones necesarias para ponerlo en funcionamiento. Esto incluirá una nueva sesión RAP (planificación 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 planificación del proyecto. En caso de cambios severos, será necesario repetir la fase de Estudio de Factibilidad.
REGISTRODEREQUERIM IENTOS DE CAM BIOSALPROYECTO Nom bredel Cliente:
Página
Nom bredel Proyecto:
Códigodel Proyecto:
de
GerentedeProyecto:
Fecha: Estatus
Núm erodel Requerim iento
Fecha Envío
Nom bredel Requerim iento
Costo
Pendiente Aprobado
Fecha
Rechazado
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 secretaría de apoyo estará dedicado a tiempo completo al grupo del proyecto. Esos supuestos están parcialmente documentados en el modelo de Evaluación de Riesgos. Otros están 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 Decisión La Solicitud de Decisión es un mecanismo para obtener y documentar decisiones o requerimientos de información durante el curso del proyecto. La figura 4.5 muestra el formulario de Solicitud de Decisión. Las Solicitudes de Decisión documentadas aseguran que los participantes del proyecto están conscientes de cualquier decisión 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 Decisión, presentado en la figura 4.6, contiene un asiento de una línea por cada Solicitud de Decisión. Ello provee al Gerente del Proyecto y al Comité del Proyecto con una referencia rápida a los asuntos que esperan por decisiones y la fecha que se espera las decisiones sean tomadas, con el fin de mantener la programación actual del proyecto.
SOLICITUD DE DECISION Nombre del Cliente:
Número de Requerimiento:
Nombre del Proyecto:
Nombre del Requerimiento:
Gerente del Proyecto:
Fecha : Decisión Requerida por:
Código del Proyecto: Descripción de la Decisión Requerida:
Recomendación:
Impacto de la Recomendación:
Decisión Lograda:
Por el Contratista:
Fecha:
Por el Cliente:
Nombre:
Nomnre:
Firma:
Firma:
Fecha:
Fecha:
Figura 4.5 Solicitud de Decisión
REGISTRO DE REQUERIMIENTOS DE DECISION Nombre del Cliente:
Página
Nombre del Proyecto:
Código del Proyecto:
Gerente del Proyecto:
Fecha:
Número de Requerimiento
Fecha
Nombre del Requerimiento
de
Fecha Requerida de la Decisión
Fecha de Recepción de la Decisión
Figura 4.6 Registro de Solicitudes de Decisión
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 Aceptación durante los procesos de prueba de aceptación. El formulario cubre varios propósitos: • • • •
Formaliza el proceso de registro de problemas. Actúa para detener cambios innecesarios. Ayuda a detectar los errores oportunamente. Permite actuar objetivamente en el proceso de corrección de problemas.
El Reporte de Problemas debe ser usado también 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 límites Nombre del Cliente:
Número de Fallas:
Nombre del Proyecto:
Código:
Gerente del Proyecto: Descripción del Problema
Preparada por:
Fecha:
Acción Tomada:
Preparada por:
Fecha:
Asignado a:
REGISTRO DE PROBLEMAS EL PROYECTO Nombre del Cliente: Gerencia de Interconexión yCarrier
Página
de
Nombre del Proyecto: SINTEROP
Código del Proyecto:
Gerente de Proyecto: Lisette Fuentes
Fecha: Estatus
Número de la falla
Fecha Envío
Identificación 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 planificación, que son la base para desarrollar la fase de Estudio de Factibilidad (o de definición de los Términos de Referencia) y la fase de definición 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 diferenciación entre la administración del proyecto y el desarrollo de los aspectos técnicos 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 Administración del Proyecto. Es importante mantener los documentos de este archivo separados de los documentos técnicos 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. Evaluación de riesgos. Cronograma de desarrollo. Legislación relevante. Grupos clave. Personal del proyecto. Proyectos relacionados. Suposiciones, condiciones y restricciones. Calidad en el proyecto y en sus productos. Descripción técnica del proyecto.
El Libro del Proyecto debe incluir además otros papeles de trabajo tales como estándares, 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 Aceptación Cronograma del proyecto Reporte semanal Reporte mensual Minutas del Comité del Proyecto Requerimientos de cambios Requerimientos de decisión Reportes de problemas Requerimientos de servicios First Class Otras correspondencias Detalle de los estimados Detalle de los cronogramas Información 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 típico 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 técnico interno, tales como Administración de Base de Datos, Redes de Comunicaciones, Operaciones, etc. Auditoría Interna y Aseguramiento de Calidad
El rol de esos grupos externos puede variar desde una posición 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 organización del Gerente del Proyecto que necesitan revisar o auditar pasivamente el proyecto y sus productos. Este nivel incluye a Auditoría Externa, representantes de estándares de la industria o el Gobierno y usuarios indirectos. Nivel 2: Elementos fuera del área inmediata del Gerente del Proyecto que tienen una participación menor o un rol de consultoría. Este nivel incluye Auditoría Interna, áreas de aseguramiento de calidad y grupos de soporte al desarrollo tales como Metodologías, Estándares y Organización. Nivel 3: Representantes de Sistemas externos o de Proyectos que envían o reciben datos del proyecto. Este nivel incluye a los representantes de computación de los sistemas o proyectos relacionados y a usuarios de dichos sistemas y proyectos. Nivel 4: Grupos y proyectos que están dentro de la organización pero fuera del área inmediata del Gerente del Proyecto y que tienen una participación o impacto importante sobre el desarrollo del proyecto. Este nivel incluye los grupos de soporte técnico interno tales como Administración de Base de Datos, Operaciones y Redes. Nivel 5: Grupos y proyectos que están fuera de la organización del Gerente del Proyecto y que tienen una participación 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 estén 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 planificación, seguimiento y revisión. Es importante que al menos representantes de los niveles 5 y 6 estén presentes en las sesiones de planificación y que representantes de los niveles 3 y 4 se involucren vía su participación activa en los procesos de revisión. Los representantes de los niveles 1, 2 y 3 deben participar, como mínimo, en los procesos de revisión y aprobación 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 términos 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. Función. 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. Tecnología. El proyecto comparte tecnología, esto es, un proyecto instala tecnología 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 específica 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 están preparados para entregar sus recursos de acuerdo con el cronograma de proyecto acordado. En muchos casos, esto requiere de una aprobación 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 incluiría los contratos formales de servicio. Esos acuerdos formales son documentados como los Acuerdos del Proyecto. Típicamente, esos acuerdos documentan lo siguiente: • • • •
El tipo de soporte o servicio requerido. El tiempo y costo de los servicios. Medidas específicas 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 resolución. 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 añadido 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 relación de productividad entre individuos del orden de 2:1 y, en áreas tales como análisis y diseño, esta relación puede ser de 10:1 o mayor. Como durante el proceso de planificación se debe asumir que se dispondrá de los individuos con las características 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 supervisión 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 duración del proyecto. En caso de que en la realidad del proyecto se consigan personas que no se adaptan a los perfiles definidos en la planificación, 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 están basados en que el Gerente del Proyecto esté asistido por la alta gerencia de la organización 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:
Página de
Nombre del Proyecto:
Código:
Gerente del Proyecto:
Fecha:
Servicio requeridos:
Fechas de inicio / terminación del servicio requerido:
Costo del servicio:
Servicios alternos:
Gerente Del proyecto:
Gerente proveedor del servicio:
Nombre:
Nombre:
Firma:
Firma:
Fecha:
Fecha:
Figura 5.2 Requerimiento de Servicio
REQUERIMIENTO DE SERVICIO Nombre del Cliente:
Página de
Nombre del Proyecto:
Código:
Gerente del Proyecto:
Fecha:
Servicio requeridos: Personal de la Unidad de Tecnología de Información. Analista de Sistemas: Modelamiento de Datos, Nivel 2 ó superior. Modelamiento funcional, Nivel 3. Análisis de costos, Nivel 3. Analista Diseñador: Modelamiento de datos, Nivel 3. Diseño Oracle, Nivel3.
Fechas de inicio / terminación 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 Diseñador: Modelamiento de datos, Nivel 3. Diseño Oracle, Nivel2.
Gerente Del proyecto:
Gerente proveedor del servicio:
Nombre:
Nombre:
Firma:
Firma:
Fecha:
Fecha:
Figura 5.3 Ejemplo de Requerimiento de Servicio
Su Voz ...
REGISTRO DE REQUERIMIENTOS DE SERVICIO sin límites
Nombre del Cliente: Gerencia de InterconexiónCarrier y
Página 1 de 1
Nombre del Proyecto: SINTEROP
Código: VPCE.GIC.08.95
Gerente del Proyecto:Lisette Fuentes
Fecha: 31/10/97
Número de Fecha Requerimiento
Nombre del Requerimiento
Fecha Fecha de Requerida de Recepción de la Decisión la Decisión
Figura 5.4 Registro de Requerimiento de servicio
Su Voz ... sin límites
REPORTE DE ACEPTACION PERSONAL
Nombre del Cliente: Gerencia de Interconexión y
Carrier
Gerente del Proyecto:
Nombre del Proyecto: SINTEROP
Fecha :
Código del Proyecto: VPCE.GIC.08.95
Fase :
Fecha de entrega del producto para aceptación: Producto a aceptar:
Nombre del Aceptador: Titulo del Aceptador: Fecha de aceptación: Firma del Aceptador: Comentarios:
Figura 5.5 Reporte de Aceptación
Lisette Fuentes
CAPITULO 6 ORGANIZACION PARA EL PROYECTO El éxito de un proyecto depende en parte de que se entiendan los roles que desempeñan los equipos que definen la organización 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, Aceptación y de Desarrollo, así como al resto de los miembros de la organización 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 organización: •
Comité Ejecutivo del Proyecto: Reúne a los Ejecutivos de máximo 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 organización.
•
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 aceptación de los productos del proyecto. Debe tener la autoridad para tomar decisiones en representación de la Organización y debe tener suficiente tiempo para dedicárselo al proyecto. Es responsable por asegurar la cooperación de los Usuarios Finales y de los Gerentes de la Organización relacionados con el proyecto, sin crear una burocracia innecesaria. Es el principal negociador para resolver dificultades de comunicación y problemas en la adquisición y distribución de los recursos requeridos por el proyecto.
Asegura la disponibilidad de suficiente experticia externa a lo largo de la vida del proyecto, así como también la existencia de suficiente infraestructura técnica 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 asignación 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 aceptación de los productos del proyecto. Debe tener la autoridad para tomar decisiones en representación de la Organización y debe tener suficiente tiempo para dedicárselo al proyecto. Es responsable por asegurar la cooperación de los Usuarios Finales y de los Gerentes de la Organización relacionados con el proyecto, sin crear una burocracia innecesaria. Es el principal negociador para resolver dificultades de comunicación y problemas en la adquisición y distribución de los recursos requeridos por el proyecto. Asegura la disponibilidad de suficiente experticia externa a lo largo de la vida del proyecto, así como también la existencia de suficiente infraestructura técnica 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 asignación de recursos humanos al proyecto.
•
Consultores Especialistas: Personal externo que provee soporte y guía al proyecto en aspectos técnicos, metodológicos o funcionales. También puede incluir a especialistas de la Organización 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 técnicos y administrativos y, lo más importante, es el mecanismo para involucrar a la Organización en el proyecto. El que los gerentes estén 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 administración 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 implantación de sistemas, prepara planes de trabajo para el proyecto y reportes de progreso que, después de discutidos con el Gerente del Proyecto, son sometidos a la consideración 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 participación de los usuarios en las actividades que éstos tengan asignadas. En proyectos con las características identificadas en Sinterop, resulta difícil que el Gerente del Proyecto participe a tiempo completo, por lo que, en la práctica, 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 comunicación entre Gerente y Coordinador, de tal forma que las decisiones fluyan con la rapidez necesaria. •
Equipo de Aceptación: Tiene, por delegación, la responsabilidad en la aceptación 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 creación del material de entrenamiento y en la documentación del usuario, y realizar las pruebas de aceptación dentro de su área funcional. Dentro del Equipo de Aceptación está el Coordinador Administrativo del Proyecto, quién actúa como coordinador del equipo de aceptación y secretario del Comité del Proyecto, manteniendo actualizada la documentación del proyecto. Es el responsable por la administración de los mecanismos de control de cambios, decisiones y problemas. Así mismo, colabora con el Coordinador del Proyecto en la planificación y consolidación de los planes a corto y mediano plazo y en el control de la ejecución del proyecto, siendo responsable por la actualización del sistema automatizado de apoyo al control de proyectos. Comparte con el Coordinador de Sistemas Manuales la elaboración de los Manuales de Procedimientos y el entrenamiento a los usuarios. En cuanto a la aceptación del sistema, colabora en la elaboración de los planes de aceptación y coordina la ejecución de los mismos. El Equipo de Aceptación debe contar con el apoyo de: ⇒ Especialista en Aceptación de Operaciones, para evaluar la capacidad de la instalación para atender satisfactoriamente los requerimientos de servicio (tiempo de respuesta, calendarios de proceso, frecuencia y horario de proceso, etc.) y evaluar el desempeño del sistema una vez que entre en su etapa de operación. ⇒ Auditor Revisor, para evaluar y aprobar el sistema en los aspectos relacionados con el control interno (autorizaciones, exactitud de la
información, seguridad, adherencia a las normas y políticas de la Organización). 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 revisión o colaborar en algún proceso especial de aceptación. •
Equipo de Desarrollo de Sistemas Automatizados: Tienen la responsabilidad técnica por el desarrollo y la implantación de los procedimientos automatizados del sistema objeto del proyecto. Está conformado por especialistas, los cuales, dependiendo de la magnitud y complejidad del sistema, asumirán roles tales como Analista Planificador de Sistemas, Analista Diseñador de Arquitectura, Analista Diseñador de Aplicaciones, Analista de Datos, Diseñador 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 implantación de sistemas automatizados, basado en el cumplimiento de los Métodos, Estándares y Procedimientos vigentes en la unidad de Tecnología de Información de la empresa(adaptándolos 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. También es su responsabilidad la preparación 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 también la existencia de suficiente infraestructura técnica y organizacional para los productos del proyecto.
•
Equipo de Métodos y Procedimientos: Tienen la responsabilidad técnica por el desarrollo y la implantación de los procedimientos manuales del sistema objeto del proyecto. Está conformado por especialistas en las áreas de métodos, procedimientos manuales, interfaz usuario/máquina, estudios organizacionales y técnicas de adiestramiento. EL Analista de Métodos 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 rodearán y regularán el funcionamiento de los sistemas automatizados. También se encarga de perfilar y proponer los cambios a la organización 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 Métodos 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 implantación de sistemas automatizados, basado en el cumplimiento de los Métodos, Estándares y Procedimientos vigentes en la unidad de Organización y Métodos de la empresa(adaptándolos a los factores de contingencia en los que se desarrolla el proyecto) y aplicando, en lo posible, herramientas modernas de CASE. También es su responsabilidad la preparación 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 también la existencia de suficiente infraestructura técnica y organizacional para los productos del proyecto. Durante las fases de Planificación/Análisis/Diseño, 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 elaboración 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 también la existencia de suficiente infraestructura técnica y organizacional para los productos del proyecto. •
Equipo de Soporte de Sistemas Automatizados: Agrupa a especialistas de hardware, software y comunicaciones. Ponen a disposición del Equipo de Proyecto su experticia en los diferentes aspectos de arquitectura tecnológica, actúan como coordinadores de diseño para los miembros del equipo y se desempeñan 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 aplicación de la metodología, los estándares y herramientas de sistemas de la organización.
COMITE DEL PROYECTO Es necesario involucrar a la Alta Gerencia de la Organización en los proyectos informáticos, para asegurar que la aprobación, desarrollo y soporte de los proyectos de sistemas de información reflejen la dirección estratégica de la empresa, y que la búsqueda 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 crítico y otros aspectos del negocio. •
El técnico, que trata con las tareas y problemas específicos asociados con equipos, tecnología y productos del proyecto. •
Es generalmente aceptado que el Gerente del Proyecto delegue el sistema de control técnico 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 técnicos en los objetivos del proyecto, sus costos, etc. El interés 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 situación 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 • • • •
Aprobación de proyectos y etapas de proyectos. Seguimiento y revisión de proyectos. Asistencia a los proyectos, cuando sea requerido. Solución de los conflictos en los proyectos.
Aprobación de proyectos y etapas de proyectos La aprobación de proyectos es un proceso de dos etapas. La primera se relaciona con la identificación de los proyectos potenciales (por nueva legislación, planificación estratégica 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 información desde una perspectiva estratégica y que delega el control específico de proyectos individuales a los Comités 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 delegación para el Gerente del Proyecto y los puntos de revisión clave durante el ciclo del proyecto.
Seguimiento y revisión de proyectos. Dependiendo del tamaño, riesgos e impacto organizacional del proyecto, el Comité del Proyecto le hará seguimiento y revisión al proyecto en varias etapas clave, utilizando los reportes del proyecto definidos. Como mínimo, el Comité debe revisar el proyecto al final de cada una de las fases del ciclo de desarrollo. Sin embargo, para proyectos que están 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 revisión. Adicionalmente, si el proyecto está utilizando estrategias más complejas de desarrollo tales como RAD, desarrollo híbrido o por prototipos, las revisiones serán más dinámicas y flexibles. Típicamente, en desarrollos complejos, las revisiones se determinan por la obtención de productos tales como prototipos completados, sesiones JAD concluidas, etc. El proceso de seguimiento y revisión debe enfocarse en el “Business Case” y en cualquier variación 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 modificación al “Business Case” original, se debe requerir de la siguiente información para la reunión del Comité: • La naturaleza y razones para el cambio. • Impacto del cambio. • Actualización del “Business Case” (incluyendo alternativas del plan del proyecto). • Acciones sugeridas para la consideración del Comité del Proyecto. Asistencia al proyecto. Si se presentan cambios en el proyecto, la función del Comité del Proyecto es apoyar al Gerente del Proyecto para la solución 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 función 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 más importante que ellos se concentren en resolver las situaciones para asegurar que el proyecto continúe desarrollándose bajo su control. Resolución de conflictos durante el proyecto
En el enfoque de proyectos actual, el Gerente del Proyecto actúa como un “Gerente Contratista” que a su vez requerirá de un cierto grupo de “ sub-contratistas”, esto es, expertos que están 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 ubicación, 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 comités puede variar de proyecto a proyecto, todas las reuniones de comité deben abarcar los siguientes tópicos en su agenda: •
• • • • • •
La situación del proyecto: ¿Se ha alterado el “Business Case” desde la última reunión? 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? ¿Quién es responsable por hacerle seguimiento a las decisiones? ¿Qué causó los cambios? ¿Hay expectativas por futuras situaciones? ¿Se requiere de alguna otra acción?
Si se presentan situaciones en el ámbito técnico que requieran de una discusión detallada para su resolución, es necesario convocar a una reunión de Revisión Técnica 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 límites Nombre del Cliente:
Fecha:
Nombre del Proyecto:
Código:
Gerente del Proyecto:
Preparada por:
Status del Proyecto: •Presupuesto •Cronograma •Progreso
Responsabilidad del Ususario:
Control del Alcance: •Solicitudes de Cambios •Solicitudes de Decisiones •Reporte de Problemas
Aspectos para acción del Comité de Alta Gerencia:
Otros Aspectos a tratar:
Próxima Reunión:
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 están muy ocupados, es típico que los gerentes de proyecto estén 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 página o menos”, el Gerente del Proyecto debe asegurarse de que los miembros del Comité tienen suficiente información para garantizarles que estarán realmente al tanto de la situación y los problemas del proyecto. De no ser así, la actividad del Comité se verá reducida a una sesión de firmas de documentos. El uso de un cuerpo de formatos comunes, una buena calidad de impresión y el uso de gráficas, 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 más profundo y realista de las situaciones a veces necesariamente complejas de la mayoría 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. ORGANIZACIÓN MATRICIAL BALANCEADA PRESIDENCIA
VICEPRESIDENTE TECNOLOGIA DE INFORMACION
VICEPRESIDENTE INGENIERIA
VICEPRESIDENTE FINANZAS
STAFF DEL USUARIO
STAFF
STAFF
STAFF
STAFF DEL USUARIO
GERENTE DE SISTEMAS
GERENTE DE PLANIFICACION
ORGANIZACIÓN Y METODOS
VICEPRESIDENTE COMUNICACIONES ESTRATEGICAS
GERENTE DEL PROYECTO
COORDINADOR ADMINISTRATIVO
Coordinación del proyecto
COORDINADOR TECNICO
INGENIERO DE PLANIFICACION
ANALISTA OYM
Figura
ORGANIGRAMA DE PROYECTO CON EMPRESA CONTRATISTA
COMITE EJECUTIVO DEL PROYECTO
GERENCIA DEL CLIENTE
COMITE DE GERENCIA
DIRECTOR DEL PROYECTO (ACEPTADOR)
GERENCIA DEL CONTRATISTA
GERENTE DEL PROYECTO
COORDINADOR DE LOS USUARIOS
QUALITY ASSURANCE
CONSULTORES ESPECIALISTAS ADMINISTRADOR DEL PROYECTO
STAFF DEL USUARIO
STAFF DE SISTEMAS (CLIENTE)
ARQUITECTURA TECNICA
STAFF DE SISTEMAS (CONTRATISTA)
ARQUITECTURA DE APLICACIONES
Figura 6.3
ORGANIGRAMA DE PROYECTO EJECUTIVO DEL PROYECTO
COMITÉ DEL PROYECTO
GERENTE DEL PROYECTO
COORDINADOR DEL PROYECTO
EQUIPO DE QA
EQUIPO DE ACEPTACION
EQUIPO DE DESARROLLO SISTEMAS AUTOMATIZADOS
COMITE ALTA GERENCIA
CONSULTORES ESPECIALISTAS
EJECUTIVO DEL CONTRATISTA
EQUIPO DE SOPORTE SISTEMAS AUTOMATIZADOS
EQUIPO DE METODOS Y PROCEDIMIENTOS
VERSION 06-05-98
ORGANIGRAMA DE PROYECTO COMITE DEL PROYECTO
ADMINISTRACION DEL PROYECTO
Quality Assurance
CONSULTORES ESPECIALISTAS
GERENTE DEL PROYECTO
Grupo de pruebas del sistema
Equipo de Ingeniería
Equipo Técnico
Expertos técnicos
Coordinador de diseño
Hw, Sw Telecom.
Estándares Metodología
Red
Equipo de desarrollo de aplicaciones
Arquitectura técnica
Tecnológica
Equipo de apoyo para aceptación de sistemas
Representantes del Usuario
DBA
DBMS
Software de Aplicaciones
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 )
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 )
C O O R D IN A D O R DEL PRO YECTO
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
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
E J E C U T IV O D E L C O N T R A T IS T A
M IG U E L C O L O M B O 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 SA IDS OT ES M A S A U T O M A T I Z A D O S P E D R O M I G U E L P E R E RZ 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 C E S A R P IN O C H E T ( 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( SC TO RO. )R D I N A D O R D E S R R( C SOI SO TR ) D I N A D O R S O P O RI VTOE N) N E O R T E G A ( A D M I N Y C O N F I G C O N V JE ON SI OE SA) N G E L M A T A ( B WJ 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 (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 Introducción La evaluación de riesgos es la formalización de un proceso “intuitivo” que está siempre presente en la mente de los gerentes de proyectos cuando realizan su trabajo de planificación. El modelo de evaluación de riesgos que se desarrollará intenta establecer cierto rigor, objetividad y consistencia en una actividad típicamente subjetiva y medio encubierta. El riesgo es un elemento crítico para la comprensión de la dinámica 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 más 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 Capítulo 3, la evaluación de riesgos se realiza inicialmente durante las sesiones de Planificación Rápida de Aplicaciones. Normalmente, la evaluación de riesgos se realiza conjuntamente con la evaluación y selección de la estrategia de desarrollo del proyecto y previo a las estimaciones. Cualquier factor valorado como de alto riesgo, debe ser sujeto a un análisis 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 reducción o contención del riesgo. La reducción del riesgo en los proyectos es una situación 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 están fuera del control del Gerente del Proyecto y de su organización. 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 Memorándum 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 también un plan de contingencia. La Figura 7.1 muestra un ejemplo de dicho memorándum.
FACTOR DE RIESGO POR RESOLVER Nombre del Cliente:
Página
de
Nombre del Proyecto:
Código del Proyecto:
Gerente del Proyecto:
Fecha:
Factor de Riesgo: Dependencia del proveedor para recibir la nueva versión del software de Base de Datos
Impacto del Factor de Riesgo: •El proyecto se atrasará, a partir del evento XXXXXX, la misma cantidad de días que la nueva versión no esté disponible y probada. •Si la nueva versión no está disponible para el 8 de octubre, los valores obtenidos para el Retorno sobre la Inversión se impactarán negativamente
Estrategias para la minimización 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 versión
Planes de contingencia: Preparar una solución alterna para el sistema utilizando la versión actual del software.
Preparado por:
Figura 7.1Memorándum 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 rápidamente a uno de alto riesgo. Cualquier modificación en los factores de riesgo del proyecto debe estar sujeta al mecanismo de control de cambios detallado en el Capítulo 4. La identificación 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 indicación del grado total de riesgo del proyecto. Es esencial entender que como la evaluación de riesgo es subjetiva, diferentes personas percibirán los riesgos en forma diferente. La evaluación de riesgos debe recopilar todas las evaluaciones democráticamente, aceptando la opinión de la mayoría como la guía para el proyecto. Si en algunas circunstancias no se puede lograr el consenso en forma democrática, se recomienda utilizar los valores de mayor riesgo sobre el aspecto en discusión: ¡en este caso vale la pena ser paranoico! Se presenta una guía para valorar los factores definidos, la cual no debe tomarse como algo rígido, 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 Evaluación 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
del
Bajo Riesgo 32 - 127 32 - 110
Mediano Riesgo 128 - 223 111 - 199
Alto Riesgo 224 - 330 200 - 269
33 - 126
127 - 218
219 - 308
97 - 363
366 - 640
643 - 907
Debido a la naturaleza subjetiva de los procesos, el uso de estas valoraciones para comparar proyectos no es válido. Por ejemplo, un proyecto con un factor de riesgo de 650 es considerado tan de alto riesgo como uno con un factor de 895.
Más acerca de las Métricas de Software Como se discutió en el Capítulo 3, la cuantificación de los factores de riesgo se conoce como Métricas de Software. En lo posible, el Modelo de Riesgo definido en este capítulo 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 evaluación de riesgos continua siendo una mezcla de medidas objetivas y subjetivas. Siempre que sea posible, el Gerente del Proyecto debe tratar de aplicar aquellas métricas que le ayuden a soportar la parte subjetiva de la evaluación. Adicionalmente, el lograr que el Equipo del Proyecto y los Usuarios clave se involucren totalmente en el proceso de evaluación de riesgos provee un mecanismo invaluable para sacar el mejor provecho del cuestionario presentado y de la tabla de evaluación final. Como muchas de las técnicas que se describen en este manual, el evento crítico de asumir activamente el proceso de evaluación del riesgo es valioso para lograr que se compartan las suposiciones y las preocupaciones, así como también para lograr una visión común 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 sólo financiero: el costo del proyecto debe ser cargado a pérdidas. En casos más complejos, el riesgo puede ser: • • • • • •
Político: La organización entra en conflicto con el Gobierno. Recursos humanos: El personal se siente desagradado por los efectos del nuevo proyecto. Financiero: La organización pierde dinero y equipos. Seguridad: La organización queda expuesta a fraudes, acceso ilegal a datos o servicios, etc. Legal: La organización entra en litigios. Mercado: La organización pierde imagen o participación del mercado.
Si el Gerente del Proyecto toma muchos riesgos, las consecuencias pueden ser, entre otras, las siguientes: • El tiempo de culminación 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 técnico puede ser insatisfactorio. Pero ésta es una visión técnica y restringida del Gerente del Proyecto. Existen otros aspectos que tienen que tomarse en cuenta. Entre los más complejos están: • La posible actitud negativa de los Usuarios Finales. • Falta de aceptación (y apoyo) por parte de los Altos Ejecutivos de la Empresa. • Problemas de cooperación entre Diseñadores y Usuarios.
Estos y otros riesgos se identifican durante la planificación del proyecto y son normalmente expuestos en el Business Case para que sean considerados durante la fase de aprobación del proyecto. En resumen, los modelos de riesgo para el desarrollo de proyectos (como el elaborado aquí), proveen una indicación de la probabilidad de falla en el proyecto y la subsecuente exposición 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 críticos de éxito del proyecto durante su progreso y, tercero, aplicar sin demoras las acciones correctivas siempre que sean necesarias.
Cuestionario para la Evaluación de Riesgos Criterio de Riesgo: Ambiente del Usuario Criterio 1.
2
3
4
5
6
7
8
9
10
¿Está el usuario comprometido con una metodología 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 ¿Están 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 crítico será el sistema para la continuidad de las operaciones en el área usuaria, cuando esté terminado? Bajo impacto Impacto significativo Gran impacto Número de Unidades externas involucradas en el desarrollo, aprobaciones y otras decisiones relacionadas con el sistema: Ninguna 1 Más de 1 Departamentos/Sucursales usuarias involucrados en el desarrollo, aprobación y otras decisiones relacionadas con el sistema: 1 2 Más de 2 Secciones de las áreas usuarias involucradas en el desarrollo, aprobaciones y otras decisiones relacionadas con el sistema: 1 2 Más de 2 Número de sindicatos afectados por el sistema: Ninguno 1 Más de 1
Criterio 11
Número de sitios diferentes/oficinas/plantas usuarias
Factor de riesgo
Peso seleccionado
Bajo Alto
0 4
Bajo Alto
0 4
Bajo Medio Alto
2 6 8
Bajo Medio Alto
2 8 16
Bajo Medio Alto
2 4 8
Bajo Medio Alto
2 4 12
Bajo Alto Muy alto
0 16 20
Bajo Alto Muy Alto
4 12 20
Bajo Medio Alto
1 5 10
Bajo Medio Alto
0 10 20 Peso seleccionado
Factor de riesgo
12.
13
14
15
16
17
18
involucrados en el sistema: 1 2 - 10 Más de 10 ¿Cuál es la severidad de los cambios o eliminación de procedimientos en el área usuaria, como consecuencia de la puesta en operación del sistema propuesto? Menor Significativa Mayor ¿El sistema propuesto obliga a realizar cambios estructurales en la organización del usuario? Menor Significativa Mayor ¿Qué tan estables son los requerimientos del sistema? Son estables y difícilmente cambiarán Son estables pero podrían cambiar Son inestables y abiertos a cambios en el futuro Situación de la documentación 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 culminación de los eventos críticos 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 específicas, requerimientos legales o decisiones que se escapan al control de la organización.
Bajo Medio Alto
2 6 12
Bajo Medio Alto
0 8 12
Bajo Medio Alto
0 8 16
Bajo Medio Alto
2 10 20
Bajo Bajo Medio Alto
0 2 4 6
Bajo Bajo Medio Alto
0 2 4 6
Bajo Medio Medio
2 4 6
Alto
8
Bajo
1
Medio
6
Alto
16
Criterio 19
20
21.
22
23 24
25
¿Cómo es la participación del usuario? Totalmente comprometido: Usuarios expertos asignados para trabajar a tiempo completo en el proyecto. Con responsabilidades importantes: No hay un compromiso de dedicación exclusiva. Con alguna responsabilidad: Intervención limitada a los procesos de revisión y aprobación. ¿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 implantación de proyectos. Tiene alguna experiencia. Tiene una experiencia limitada. ¿Cómo son las comunicaciones entre el área usuaria y la unidad de Sistemas de Información? Buenas Regular Pobre ¿El sistema propuesto requiere de tecnologías o técnicas a ser controladas por el usuario (por eje: Equipos de monitoreo, terminales gráficos, 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 culminación de eventos? No Sí ¿Existen Proveedores, Consultores o Expertos externos a la organización, de los cuales dependa el proyecto para cumplir con las metas fijadas en cuanto a fechas de culminación de eventos? No. Expertos. Proveedores. Expertos y Proveedores.
Factor de riesgo
Peso seleccionado
Bajo
4
Medio
12
Alto
16
Bajo
2
Medio Alto
8 20
Bajo Medio Alto
3 6 9
Bajo Alto
0 9
Bajo Alto
0 20
Bajo Alto
0 20
Bajo Medio Alto Muy alto
0 8 12 20
Cuestionario para la Evaluación de Riesgos Criterio de Riesgo: Ambiente del Equipo de Proyecto Criterio 1.
2
3
4
5
6
7
8
9
¿Cuál es la prioridad del proyecto dentro de la unidad de Sistemas de Información? Alta Media Baja ¿Qué tan comprometida está la Alta Gerencia de Sistemas de Información con el sistema? Entusiásticamente comprometida Apoya Neutra ¿Cuál es la prioridad del proyecto dentro de la unidad de Organización y Métodos? Alta Media Baja ¿Qué tan comprometida está la Alta Gerencia de Organización y Métodos con el sistema? Entusiásticamente comprometida Apoya Neutra ¿Cuál es el tamaño del equipo de proyecto (incluyendo a los representantes de usuario a tiempo completo)? Menos de 5 5 a 10 Más de 10 ¿Cuál es el tamaño estimado del proyecto medido en personasmes? Menos de 3 meses 3 a 20 meses Más de 20 meses ¿Cuál es el tiempo total estimado para el desarrollo del proyecto? Menos de 6 meses 6 a 12 meses Más de 12 meses ¿Cuál es la actitud general del área usuaria hacia la computación? Buena: entiende el valor de la unidad de Sistemas de Información. Regular: Hay cierto rechazo Pobre: hay una actitud anti-sistemas de información ¿Qué tanto conocimiento tiene el usuario sobre el área de Sistemas de Información? Alto grado de formación. Contactos previos pero experiencia limitada. Primer contacto con Sistemas de Información.
Criterio 10
¿Qué tanto conocimiento tiene el usuario sobre el área de Organización y Métodos?
Factor de riesgo
Peso seleccionado
Bajo Medio Alto
2 4 8
Bajo Medio Alto
2 6 8
Bajo Medio Alto
2 4 8
Bajo Medio Alto
2 6 8
Bajo Medio Alto
4 8 16
Bajo Medio Alto
4 8 16
Bajo Medio Alto
4 8 20
Bajo
3
Medio Alto
6 12
Bajo Medio Alto
3 6 12
Peso Factor de seleccionado riesgo
Alto grado de formación. Contactos previos pero experiencia limitada. Primer contacto con Sistemas de Información. 11
12
13.
14
15
16
¿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 tamaño) 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é proporción de los miembros del Equipo del Proyecto será obtenida de una contratista? Ninguna. Menos del 25 %. Más 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 aplicación propuesta? Ha estado involucrado en esfuerzos previos de implantación. Entiende el área de aplicación pero no tiene experiencia de implantación. Mixta Limitada ¿Qué experiencia tienen los miembros del Equipo del Proyecto con el lenguaje/s de programación a ser utilizado? Buena experiencia dentro de la organización. Buena experiencia en otras organizaciones. Poca experiencia.
Bajo Medio Alto
3 6 12
Bajo
4
Medio
6
Medio
8
Alto
16
Bajo Medio
3 6
Alto
9
Bajo Medio Alto
0 8 16
Bajo Bajo Medio Alto
0 3 6 12
Bajo Medio
2 8
Medio Alto
6 12
Bajo Medio Alto
0 8 16
Criterio 17
18
19
20
21 22
¿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 organización. Buena experiencia en otras organizaciones. Poca experiencia. ¿Qué experiencia tienen los miembros del Equipo del Proyecto con comunicación de datos? No se utilizará comunicación de datos. Buena experiencia dentro de la organización. Buena experiencia en otras organizaciones. Poca experiencia. ¿Qué experiencia tienen los miembros del Equipo del Proyecto con los paquetes a ser utilizados? No se utilizarán paquetes. Buena experiencia dentro de la organización. Buena experiencia en otras organizaciones. Poca experiencia. ¿Qué experiencia tienen los miembros del Equipo del Proyecto en la metodología de Administración 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 tecnología para el Equipo del Proyecto? Ninguno o CPU y/o Periféricos y/o Telecomunicaciones y/o Terminales y/o Otros(mini, micros, etc.)
Factor de riesgo
Peso seleccionado
Bajo Bajo Medio Alto
0 0 8 16
Bajo Bajo Medio Alto
0 0 8 16
Bajo Bajo Medio Alto
0 0 8 16
Bajo Medio Alto
0 8 16
Bajo Alto
0 12
Bajo Alto Medio Alto Medio Alto
0 12 6 12 6 12
Cuestionario para la Evaluación de Riesgos Criterio de Riesgo: Complejidad del sistema Criterio 1.
2
3
4
5
6
7
8
9
¿Cuál es la calidad del documento de propuesta realizado por los Usuarios/Analistas? Completo Aceptable pero incompleto No existe ¿Cuál es la vida esperada para el sistema propuesto? Para solucionar una situación puntual. Menos de un año en operación Función permanente ¿Qué tan crítico es el rendimiento del sistema? No crítico Crítico debido a los volúmenes de transacciones/ tiempo total de proceso Crítico debido a los requerimientos de espacio/memoria Crítico debido a los tiempos de respuesta Con relación a la documentación 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 algún 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
Peso seleccionado
Bajo Medio Alto
0 2 4
Bajo Medio Alto
1 4 12
Bajo Alto
0 16
Alto Alto
16 16
Bajo Medio Alto
3 6 13
Bajo Bajo Medio Alto
0 4 8 12
Bajo Medio Medio Alto
1 4 6 12
Bajo Medio Alto
0 6 16
Bajo Alto
0 4
Bajo Medio Alto
0 5 16
Criterio 10
11.
12
13
14
15
16
17
18
Cantidad de entradas lógicas manejadas por el usuario, tales como pantallas especiales, transacciones. 1-5 6 - 40 40 + Cantidad de salidas lógicas manejadas por el usuario, tales como pantallas especiales de salida, reportes. 1-5 6 - 40 40 + Cantidad de vistas de datos lógicas manejadas por el usuario, tales como archivos lógicos especiales, tablas, etc. 1-5 6 - 20 20 + Cantidad de archivos de entrada/salida transferidos automáticamente de/a otros sistemas manejados por el usuario. 1-5 6 -20 20 + Cantidad de consultas lógicas 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 lógicas del usuario. 1-5 6 - 20 20 + Complejidad de la edición 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
Peso seleccionado
Bajo Medio Alto
3 6 12
Bajo Medio Alto
3 12 20
Bajo Medio Alto
3 12 16
Bajo Medio Alto
3 12 16
Bajo Medio Alto
3 12 20
Bajo Medio Medio
2 4 8
Bajo Medio Alto
3 9 12
3 6 Bajo Medio Alto
3 9 16
Criterio 19
20.
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 Módulos precodificados in-house escritos por el Equipo del Proyecto y/o Módulos precodificados in-house escritos por personal de la unidad de Sistemas de Información externos al proyecto y/o Módulos 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 Módulos escritos especialmente para este sistema
Factor de riesgo
Peso seleccionado
Bajo Medio Medio Alto Alto
0 3 6 10 16
Bajo
0
Medio
6
Medio
6
Medio
8
Alto
10
Alto
10
Cuestionario para la Evaluación de Riesgos Criterio de Riesgo: Gerencia del Proyecto Criterio 1.
2
3
4
5
6
7
8
9
¿Está la Organización comprometida con una metodología de Administración y Control de Proyectos? Totalmente En vías de implantación No existe ¿Está el Comité de Alta Gerencia comprometido con el proyecto? Totalmente Medianamente Poco ¿Tiene definido el Gerente del Proyecto un esquema de comunicación 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 Técnico del Proyecto un esquema de comunicación 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 organización para el Proyecto, con una definición precisa de la autoridad y de las responsabilidades? Sí Aceptable pero incompleto No. ¿Están definidos e implantados los procedimientos para revisión y toma de decisiones en el proyecto? Sí Aceptable pero incompleto No. ¿La Gerencia de Sistemas ha definido la metodología de desarrollo de sistemas automatizados adecuada al proyecto? No Sí ¿La Gerencia de O y M ha definido la metodología de desarrollo de sistemas manuales adecuada al proyecto? No Sí
Factor de riesgo
Peso seleccionado
Bajo Medio Alto
0 4 10
Bajo Medio Alto
0 8 20
Bajo Medio Alto
0 8 20
Bajo Medio Alto
0 8 20
Bajo Medio Alto
3 6 16
Bajo Medio Alto
0 8 12
Bajo Medio Alto
1 6 15
Bajo Alto
0 10
Bajo Alto
0 10
Criterio 10
11.
12
13
14
15
16
17
18
19
¿Qué nivel de integración técnica 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 utilizarán herramientas CASE para el análisis y el diseño del sistema? Sí No ¿Se utilizarán herramientas CASE para apoyo la construcción de los procedimientos automatizados? Sí, la misma definida en (12) Sí, diferente a la definida en (12) No ¿Se utilizarán herramientas CASE para apoyo la construcción de los procedimientos manuales? Sí, la misma definida en (12) Sí, diferente a la definida en (12) No ¿Están definidos los contactos formales para resolver los problemas que se presenten en las áreas técnicas, de capacidad, de recursos y elementos de entrada de datos? Sí No ¿Están definidos y aceptados por el Equipo de Proyecto los estándares de documentación requeridos para el sistema? Sí No ¿Se exige en los estándares de documentación que los manuales del sistema sean entregados en medio?: Magnético Papel ¿Están 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 Organización? Sí No
Factor de riesgo
Peso seleccionado
Bajo Medio Alto
3 6 12
Bajo Medio Alto
1 10 20
Bajo Medio
3 9
Bajo Medio Alto
0 6 9
Bajo Medio Alto
0 6 9
Bajo Medio
1 10
Bajo Alto
0 20
Bajo Alto
0 10
Bajo Alto
0 20
Bajo Alto
3 16
Criterio 20
21
¿Posee el Equipo de Proyecto los procedimientos de la Gerencia de Control de Cambios requeridos para el pase del sistema a Producción? Sí No ¿Posee el Equipo de Proyecto los procedimientos de la Gerencia de QRA requeridos para el desarrollo y pase del sistema a Producción? Sí No
Factor de riesgo
Peso seleccionado
Bajo Alto
3 16
Bajo Alto
3 16
CAPITULO 8 ADMINISTRANDO EL EQUIPO DEL PROYECTO Para la administración del proyecto, éste se divide en etapas, tareas y productos. Adicionalmente, el proyecto cuenta para su realización con un equipo de trabajo definido por la asignación de las diferentes responsabilidades requeridas por el proyecto. A continuación se presenta una lista indicativa de productos del proyecto, que puede servir como guía para asignar dichas responsabilidades. Esta lista puede variar, aumentando o disminuyendo la cantidad de productos, dependiendo de la metodología y estándares vigentes en la Unidad de Tecnología de Información de la empresa. El esquema de revisión 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 organización 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 dirección de cada etapa se transfiere entre el Gerente del Proyecto y el Coordinador Técnico del Proyecto, así como la responsabilidad sobre los productos obtenidos se divide entre los Coordinadores Técnico y Administrativo.
RESPONSABILIDADES EN CADA ETAPA DEL CICLO DE VIDA Gerente de Responsable por Productos la etapa los productos claves Estudio de Ejecutivo Coordinador Técnico Descripción del sistema Factibilidad del proyecto Organización del Equipo del Proyecto Propuestas de solución para el sistema Cronograma del proyecto (Compartido con Gerente del Proyecto) Gerente del Evaluación de riesgos Proyecto Análisis Costo-Beneficio Business Case Definición de Gerente del Gerente del Análisis del sistema actual los Proyecto Proyecto Requerimientos del nuevo requerimientos sistema Alcance del nuevo sistema Estimados para las siguientes etapas (Compartido con Coordinador Técnico) Especificación Gerente del Coordinador Descripción del sistema del sistema Proyecto Administrativo Requerimiento de datos (Compartido con Coordinador Técnico) Revisión análisis CostoBeneficio (Compartido con Coordinador Técnico) Coordinador Técnico Requerimiento de Hardware, Software, Redes y Telecomunicaciones Controles del sistema Estimados para las siguientes etapas(Compartido con el Gerente del Proyecto) Resumen del sistema Descripción detallada del sistema Descripción de los sistemas de control Etapa
Etapa Diseño del sistema
Desarrollo del sistema
Gerente de Responsable por Productos la etapa los productos claves Coordinador Coordinador Técnico Alternativas de diseño. Técnico Recomendaciones para la programación. Recomendaciones para la implantación. Resumen del sistema Diseño detallado del sistema Descripción 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) Revisión Análisis CostoBeneficio(Compartido con el Gerente del Proyecto) Coordinador Administrativo Coordinador Analista Líder o Diseño detallado y Técnico Coordinador Técnico documentación de los programas Lógica detallada para cada programa Documentación detallada para cada programa Descripciones de entrada/salida Programas fuentes Lenguaje de control, si es necesario Guías de operación Resultados de las pruebas unitarias Resultados de las pruebas de integración
Etapa
Gerente de Responsable por la etapa los productos Coordinador Coordinador Técnico Técnico
Productos claves Desarrollo del Estimados para las Sistema siguientes etapas, (Continuación) incluyendo cronograma de implantación, de conversión 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 Operación Entrenamiento a los Operadores Protocolo de Coordinador Coordinador Técnico, Protocolo de pruebas pruebas Técnico Gerentes de Usuarios y actualizado QA Resultados totales de las pruebas del sistema Documentación de los resultados de las pruebas, variancia con respecto a los resultados esperados y planes para la solución a esas variancias Coordinador Técnico Cronograma de implantación Plan de conversión Planes de recuperación, contingencia y reinstalación. Protocolización del “Acuerdo de Niveles de Servicio”
Etapa
Gerente de la etapa Gerente del Proyecto
Responsable por los productos Coordinador Técnico
Gerente del Proyecto
Coordinador Administrativo
Mantenimiento Gerente del Proyecto
Coordinador Administrativo
Implantación
Revisión postimplantación
Productos claves Procedimientos para nuevas versiones y para mantenimiento Cronograma y planes para las revisiones postimplantación Reporte de Revisión postimplantación Protocolización de la “Aprobación del Sistema” Plan de cambios al sistema (Compartido con el Coordinador Técnico). Revisiones regulares del “Acuerdo de Niveles de servicio”. Reportes regulares de las Revisiones Postimplantación.
Puntos de revisión 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 Organización y Métodos Gerente de Operaciones Gerente de QA Coordinador Técnico Coordinador Administrativo Estudio de Factibilidad.
Sólo se requiere de un punto de revisión en esta etapa, que se produce al final, cuando se presenta el Business Case a la gerencia. Definición de los requerimientos. Se deben revisar los siguientes productos, en la medida que se producen: •
Análisis del sistema actual (si existe). Documento de definición 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. Especificación del sistema.
Se deben revisar los siguientes productos, en la medida que se producen:
Definición del tipo de sistema. Diagrama del sistema y su diccionario de datos. Análisis de Costo/Beneficio actualizado. Documento de especificación del sistema (documento final de la etapa).
Diseño del sistema. Se deben revisar los siguientes productos, en la medida que se producen:
Diagrama total del sistema.
Evaluación de las alternativas de diseño. Diseño detallado del sistema, para cada alternativa propuesta. Análisis de Costo/Beneficio actualizado. Plan de prueba del sistema para cada alternativa. Documento de diseño del sistema (documento final de la etapa). Desarrollo del sistema.
Se deben revisar los siguientes productos, en la medida que se producen:
Diseño detallado para cada programa. Código del programa y resultado de la prueba unitaria para cada programa. Resultado de las pruebas de integración. Protocolo de pruebas del sistema. Documentación para usuarios, operaciones y entrenamiento. Documento de diseño 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: Módulos de programas y programas. Prueba de integración: Grupos de programas interrelacionados. Prueba funcional: Comparación entre las especificaciones funcionales y el componente o sistema que lo ejecuta. Prueba de sistema: Complementa a la prueba funcional, verificando los aspectos técnicos vs. los lineamientos de diseño. Prueba de aceptación técnica: Someter al sistema a condiciones extremas con el fin de detectar errores en el manejo de tales condiciones. Prueba de aceptación 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 volúmenes 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, utilizándolos durante la prueba de aceptación funcional. Plan de implantación, revisando entre otros aspectos los siguientes: Disponibilidad de recursos. Factores de contingencia que pueden afectar la implantación: Procesos de cierres mensuales, anuales, especiales. Vacaciones, feriados, etc. Disponibilidad de soporte por parte de la Contratista (si existiere): Durante las pruebas, durante la implantación, Garantía post-implantación.
Planes de recuperación, contingencia y "fallback”. En cuanto a este último, definir los criterios de fallback, identificar los recursos para contingencias, definir los tiempos críticos para recuperación o abandono. Acuerdo de Niveles de Servicio. Definir criterios sobre: Volúmenes Respuesta del usuario Precisión 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 aceptación de las Pruebas del sistema Implantación.
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-implantación. Reporte de revisión post-implantación. Documento de aprobación del sistema (documento final de la etapa).
1. Revisión post-implantación. Para esta etapa, se deben obtener los siguientes productos: • • •
Encuestas de satisfacción de los Usuarios. Reporte de Revisión Post-implantación (incluye los resultados de las encuestas de satisfacción de Usuarios). Protocolización de la Aprobación del Sistema.
Mantenimiento. Se deben revisar los siguientes productos, en la medida que se producen:
Log de cambios del sistema (regularmente, al menos mensualmente). Revisión del Acuerdo de Niveles de Servicio. Reporte de revisión post-implantación.
Basado en el documento que te entregué y en la reunión que tuve con José Gregorio esta tarde, te presento los siguientes puntos para que luego los trabajemos y concretemos la documentación para el control del proyecto a continuación, te enumero los puntos: 1. Se había acordado que las reuniones de seguimiento para el control del proyecto serán los miércoles a las 8:30 am, con duración máxima 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 Benítez y José Gregorio Vivas, el miércoles 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.
Acta de constitución del proyecto.
2.
Alcance preliminar del proyecto.
3.
Business Case, que debe contener la siguiente información: • Antecedentes y descripción del proyecto: Una descripción breve de los antecedentes y del proyecto. Es importante en este punto incluir una definición muy clara de los objetivos del negocio. En la implantación de sistemas complejos, la ausencia de una real necesidad produce dificultades casi insuperables, porque no se encuentra colaboración entre los usuarios, casi siempre reacios a invertir tiempo y esfuerzos para facilitar el éxito del proyecto. • Alcance del proyecto: Una definición clara de las áreas de impacto del proyecto y de sus límites. • Objetivos del proyecto: Una descripción precisa de los objetivos del proyecto desde los puntos de vista estratégico, 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 organización espera obtener al poner en operación el proyecto. • Costos del proyecto: Los costos de personal, tiempo, equipos, etc. involucrados en la ejecución del proyecto. • Estrategia de desarrollo: La secuencia y segmentos del proyecto en versiones y subproyectos. • Evaluación de los riesgos del proyecto: Una evaluación 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 descripción y recopilación de cualquier legislación o política 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 definición clara de los perfiles requeridos para el personal necesario en el proyecto, así como una primera propuesta de organización para el proyecto.
El soporte y la colaboración de todos los niveles de la gerencia de la empresa son condiciones básicas 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, acompañado por un miembro exitoso del equipo de Tecnología de Información. • Proyectos relacionados: Una descripción de cualquier otro proyecto que dependa o esté interrelacionado con el proyecto propuesto, así como la integración del sistema bajo estudio con los sistemas existentes. • Suposiciones, condiciones y restricciones: Se refiere a elementos tales como fechas de culminación propuestas o impuestas, tecnología seleccionada, etc. • Calidad en el proyecto: Una definición que incluya medidas de la calidad requeridas de los productos del proyecto. • Descripción técnica del proyecto: Este es un anexo que debe cubrir al menos los siguientes tópicos: Necesidades o deficiencias potenciales de sistemas existentes. Una conceptualización que ofrezca una guía estratégica para eliminar deficiencias existentes o potenciales, sobre todo en cuanto a la fuente y uso de los datos críticos del sistema. Propuestas de alternativas de diseño. Diagrama de flujo de procesos de alto nivel. Diagrama de flujo de datos de alto nivel.
2.
3.
PLANEACION 1.
Alcance Detallado
2.
WBS
3.
Plan de costos.
4.
Plan general de calidad.
5.
Plan de pruebas.
6.
Plan de gestión de comunicaciones.
7.
Plan de administración de datos.
8.
Plan de gestión de la configuración.
EJECUCION 1.
4.
Kickoff del proyecto.
MONITOREO Y CONTROL 1.
informes del Proyecto
2.
Control de Cambios
3.
Control de Problemas
4.
Control de Riesgos y su mitigaciòn
5.
Control de Decisiones.
5.
CIERRE 1.
Obtener documento firmado de aprobacion formal
2.
ejecutar proceso de cierre del contrato
1.
Formalizar el Comité Ejecutivo del Proyecto.
2.
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 presentación de este informe.
