Mailchimp

lunes, 22 de junio de 2020

Caso de estudio PMP e ITIL: Teoría y Práctica




 

En 2007 La OSR, Organización de Servicio de Registro, afrontaba uno de los momentos más difíciles desde su fundación. Con más de 200 oficinas a nivel nacional carecía de un sistema de información eficaz. El sistema estaba diseñado según el esquema básico cliente-servidor y presentaba inconvenientes en el diseño de la arquitectura y procesos. La descentralización del sistema generó silos de información, aumentando costos en el  mantenimiento, control y coordinación del SIR (Sistema de Información de Registro).

Por su parte, las directivas de la OSR realizaron una licitación pública en 2004 la cual ganó la unión temporal WB (en adelante contratista), conformada por las compañías Willie Nelson Systems Inc y Bacatá Telecomunicaciones. El objeto de la contratación era realizar la migración del sistema SIR a uno centralizado cuyo nombre sería SIRC. Sin embargo, a 2007 el contratista sólo había conseguido migrar 30 oficinas de las cuales cinco correspondían a ciudades principales. Lo anterior representó sólo ⅕ de  toda la información de la OSR a nivel nacional.


Debido a esta situación fue necesario delegar el problema a un director de proyectos llamado Miguel Huertas. El director de proyectos determinó llevar a cabo un proceso de auditoría para el contratista por intermedio de una entidad externa denominada Phil Audit. Los resultados de la auditoría mostraron los siguientes problemas:


  • Canales de comunicaciones insuficientes.
  • Demoras en los tiempos de respuesta de la Mesa de Ayuda.
  • El personal de las 30 oficinas migradas no estaba capacitado para operar de manera efectiva el SIRC.
  • El rendimiento del software no era el esperado, presentaba demasiados errores de funcionalidad.
  • No había un seguimiento del cambio de los requerimientos del software. No estaban claras las responsabilidades del contratista en caso de errores e inconvenientes en la aplicación del SIRC.

A nivel de dirección del proyecto PMP, Miguel tuvo que conformar un equipo de trabajo para poder coordinar y ejecutar la acciones que permitieran encontrar las causas de los problemas, así como sus soluciones. El equipo estaba conformado por representantes de las dos entidades contratistas; un representante de las directivas, otro de funcionarios de la OSR y un representante de la Mesa de Ayuda.


Miguel empezó a trabajar directamente con la Mesa de Ayuda puesto que es la parte de la organización que presta servicios de gestión y solución a incidencias del sistema experimentadas generalmente por el usuario final, el ciudadano.


La representante de la Mesa de ayuda, Laura Jiménez, informó al director de proyecto la transición en la que se encontraba el Centro de Atención al Usuario. Las directivas habían decidido implementar el marco de referencia ITIL, la Biblioteca de Infraestructura de Tecnologías de la Información, el cual permitió brindar un servicio de soporte integral. Debido a esto el Centro de Atención al usuario cambiaba su nombre por el de Centro de Servicios.


La OSR decidió implementar un Centro de Servicios tipo service desk local para las treinta oficinas migradasEn ITIL este tipo de servicio es el adecuado para negocios con necesidades locales ya que permite tener varios service desk en cada localización geográfica y optimizar el tiempo de respuesta para la solución de incidencias. Sin embargo, Laura Jiménez se mostró escéptica respecto a aquella decisión; pues a pesar de la optimización en tiempo de respuestas, el Centro de Servicios de esa característica presentó las siguientes desventajas:


  • Mayores Costos
  • Difícil monitoreo
  • Poca optimización de los recursos
  • La gestión de incidencias no mejoró


De igual manera, el Director de Proyecto fue informado acerca de los componentes de la Mesa de Ayuda de la OSR que, según la representante Jiménez, son roles particulares que adoptan los integrantes dentro de la misma. Se tenía un personal encargado de resolver solicitudes simples; la mayoría comunicadas vía telefónica y que podían ser resueltas casi al instante. Este personal brindaba un soporte de primer nivel. El siguiente rol era el soporte de segundo nivel; correspondiente a grupos técnicos encargados de resolver solicitudes de mayor complejidad en las que se requería llevar a cabo procesos determinados según la espacialidad de la solicitud. El último componente era el nivel de supervisión; en el cual la señorita Jiménez como supervisora de la Mesa de Ayuda ejercía una influencia directa ya que era donde se efectuaba el seguimiento y control del correcto funcionamiento de estándares aplicados a los tiempos de resolución de cualquier solicitud.


Así que Miguel decidió identificar cuáles eran los problemas que generalmente los usuarios experimentaban y que requieren un soporte de primer nivel, segundo nivel y otros problemas que precisaban supervisión. También recibió los informes periódicos que la Mesa de Ayuda emite a las directivas para la toma informada de decisiones.Posteriormente, recurrió por consejo de la supervisora al administrador del software actual de la Mesa de Ayuda, el ingeniero Camilo Rodríguez. El ingeniero brindó información sobre el comportamiento mensual de los índices y datos del servicio, así como el intento por efectuar acuerdos a nivel de servicio para la temporal, los cuales no fueron debidamente desarrollados y ejecutados.


Simultáneamente, coexistía un problema relacionado con las comunicaciones de la OSR. La infraestructura de telecomunicaciones difería entre las oficinas de ciudades grandes y  pequeñas; mientras que la tecnología de unas estaba provista de banda ancha, la información transmitida a otras era vía satélite.

En definitiva, la OSR no había logrado una migración exitosa de su sistema de información, optimizar los costos del Centro de Servicios y solucionar los problemas derivados de las comunicaciones e infraestructura.

Preguntas Clave


De acuerdo a la anterior situación problemática Miguel Huertas debía lograr comprender el origen de los problemas de la OSR. Por otro lado, las directivas de la organización consideraron necesario establecer un estándar para la gestión de proyectos. Debido a esto el director de proyecto comenzó a identificar las preguntas rectoras que desde la metodología PMI dieron claridad en la comprensión del problema.

Planeación

La primera de estas fue ¿Qué falló desde la metodología PMP?. El director de proyecto identificó que muchos de los problemas de la OSR tenían su origen en la planificación del proyecto para centralizar el sistema SIR. El proyecto tenía un plan que sólo comprendía cronogramas de actividades y la discriminación de la ejecución del presupuesto. Por consiguiente el plan no contenía directrices para situaciones como las que presentaba la OSR. También este plan carecía de un juicio de expertos para las situaciones que se presentaran o los cambios que se fueran durante la gestión del proyecto.


Sin embargo el director de proyecto debía identificar los procesos del grupo de planeación que según el PMI no se realizaron correctamente. De allí surgiría la una pregunta secundaria que ayudaría a resolver la primera ¿Qué procesos de planeación fallaron en el proyecto?


El plan de proyecto comprendía la ejecución detallada del presupuesto y una completa descripción del cronograma, por tanto Miguel determinó que había fallas en los grupos de procesos de alcance, recursos humanos, comunicaciones y riesgos.

Alcance

El primer inconveniente identificado radicaba en que las directivas tenían como plan de gestión el acta de constitución de la OSR: los entregables del proyecto que debía presentar el contratista estaban identificados de manera global. Por tanto era preciso elaborar un plan de gestión del alcance que describiera detalladamente los entregables que correspondían a Willie Nelson Systems Inc y Bacatá Telecomunicaciones.

Riesgos
Un aspecto importante de la planificación de cualquier proyecto es planificar la gestión de riesgos. En el ciclo de vida de un proyecto existe un grado de incertidumbre de riesgos imposible de mitigar en su totalidad pues no se sabe a ciencia cierta qué factores externos o internos afecten el contexto del proyecto. Sin embargo es posible prever los riesgos del proyecto y minimizar el impacto de sucesos negativos.


Para el proyecto SIRC de la OSR no se realizó una planificación de los riesgos. El contratista puso en marcha su actividad y la dirección del proyecto no contempló las dificultades que presentó el software en su rendimiento. De igual manera no tuvo presente las inconsistencias contractuales que se presentaron entre el desarrollador del software y su operador, es decir entre Willie Nelson Systems Inc y Bacatá Telecomunicaciones. Por consiguiente la pregunta a responder fue ¿cómo realizar una planificación de la gestión de los riesgos el proyecto?


El director de proyecto y su equipo realizaron cinco procesos de planificación de los riesgos independientemente de que estos ya se hubieran presentado, a saber: planeación de la gestión del riesgo, identificación de riesgos, análisis cuantitativo de los riesgos, análisis cualitativo de los riesgos y planeación de la respuesta a los mismos.


Al planificar la gestión de los riesgos, el equipo y el director de proyecto analizaron y anticiparon los riesgos de corregir los problemas en el proyecto de centralización del SIR. En términos prácticos la planificación se materializó en un documento estratégico que detalló cómo la gestión de riesgos se llevó a cabo a lo largo del proyecto. Un factor elemental en la  planificación en este punto fue determinar el nivel de riesgo que la OSR podía enfrentar.


Posteriormente identificaron los riesgos de procesos anteriormente realizados en fases como el alcance, cronograma, presupuesto y comunicaciones del proyecto. De igual manera identificaron factores ambientales correspondientes a las actitudes de los interesados hacia el riesgo. Para analizar todos los riesgos emplearon técnicas analíticas y juicios de expertos en los tipos de riesgos identificados. Como resultado obtuvieron el plan para la gestión de los riesgos.


Dentro de dicho plan contemplaron las amenazas y oportunidades que representan los riesgos que afrontaba la OSR y los que probablemente tendría. El director de proyecto detalló los diferentes riesgos involucrando los planes de las fases anteriormente mencionadas del proyecto con el fin de explotar las oportunidades y responder efectivamente a las amenazas.


Su equipo trabajó en el procesamiento y análisis de los riesgos identificados a partir de técnicas de documentación y recopilación de información, análisis de lista de control, análisis de hipótesis, técnicas de diagramación para la producción de diagramas de flujo y un análisis DOFA. Como resultado obtuvieron un documento detallado denominado registro de riesgos. Este proceso de identificación de riesgos fue revisado varias veces debido a que en en el ciclo de vida de un proyecto se pueden presentar más riesgos de los esperados.


El siguiente paso fue priorizar todos los riesgos identificados realizando un análisis cualitativo. En el caso de la OSR se abordaron primero los riesgos del sistema de información y los problemas de migración. En este aspecto definieron categorías para los riesgos del SIRC y registraron los problemas que se presentarían en este. Para procesar estos problemas realizaron una evaluación de la probabilidad del impacto de los riesgos en el costo, calendario, alcance y calidad del proyecto. Dicha información fue organizada en una matriz. El resultado de esta planificación se expresó en una actualización de todos los documentos del proyecto.


Luego de realizar un análisis cualitativo se efectuó un análisis más a fondo de los riesgos de prioridad alta, un análisis cuantitativo de los riesgos. Mientras que en el primero se realizó una categorización subjetiva de los riesgos, en el segundo se asignó un valor numérico de cuánto dinero podría perderse en el proyecto.


En ese sentido se determinó que el 80% de incidentes tenían su causa en el 20% de problemas del SIRC. El principio de Pareto se confirmó también para los problemas que Phil Audit identificó. El análisis cuantitativo respaldó las categorías y el proceso que se llevó a cabo en el análisis cualitativo. Como resultado se obtuvo una actualización de la documentación del proyecto.

Por último, el director de proyecto presentó la manera más adecuada de enfrentar los riesgos frente al SIRC y los diferentes procesos organizacionales de la OSR. Luego de haber planificado la gestión de riesgos, haberlos identificado y analizado cualitativa y cuantitativamente abordó los problemas de rendimiento de software e incumplimientos de contrato de la siguiente forma:

Rendimiento del Software


El equipo del director de proyecto estaba conformado por ingenieros de sistemas los cuales habían realizado diferentes pruebas, pero no encontraron las causas del error de funcionalidad en el SIR. Entonces la pregunta a resolver fue ¿cuáles son las causas para no encontrar los problemas de funcionalidad con las pruebas correspondientes? el equipo sugirió contratar una entidad externa encargada de hacer pruebas de arquitectura para el SIR. Dicha entidad encontró que efectivamente los problemas no se podían solucionar con pruebas de funcionalidad, sino con simulación de carga.


El resultado de estas pruebas determinó los cuellos de botella de la aplicación y adicionalmente encontró que las aplicaciones distribuidas poseían problemas en el diseño de la base de datos. Dicha entidad realizó un análisis completo del rendimiento empleando profilers o perfiladores para especificar los cuellos de botella y encontrar que había un exceso en el consumo de memoria y de procesador.

Incumplimiento en los contratos

El equipo de proyecto decidió que la mejor alternativa sería establecer una bolsa de horas para el contratista, lo que significa que para ambas empresas existiría un contrato que les obligaría a solucionar sin dilación los problemas que se presentarán en sus horas de trabajo. De no ser así se incurriría en una falta y por consiguiente se haría una deducción a la factura del contratista.


Esto generó que el contratista fuera más cuidadoso con los costos. Adicionalmente se establecieron Acuerdos a Nivel de Servicio en los tiempos de respuesta para la Mesa de Ayuda generando que el contratista estableciera prioridades para brindar un mejor servicio. Para llevar a cabo un seguimiento de las responsabilidades del contratista el director de proyecto acordó con su equipo mediciones de desempeño y cumplimiento las cuales se hacían saber a los interesados.


De esta manera logró efectuar correctamente la planeación de los riesgos ya que estableció cómo responder a las amenazas presentes y los riesgos que pudieron presentarse. Identificó oportunidades para resolver los problemas en cuanto a comunicaciones, gestión de personal y mejora del SIRC. Como resultado tuvo una actualización del plan de la dirección general del proyecto y el éxito total de su intervención como director.

Lecciones

Las lecciones de un proyecto pueden realizarse al final del ciclo de vida del mismo. Sin embargo una sección de lecciones aprendidas puede desarrollarse en el transcurso del proyecto, es decir al terminar cada una de sus fases. Las lecciones aprendidas son un activo de los procesos de la organización y se tienen en cuenta para cada área del conocimiento (integración, alcance, tiempo, costos, calidad, recursos humanos, comunicaciones, riesgos e interesados), así como para cada grupo de proceso (inicio, planificación, ejecución, cierre, monitoreo y control) dentro de la metodología PMI.

 

En la metodología PMI cada grupo de proceso se efectúa siguiendo la dinámica planificación, gestión y monitoreo. Por lo que cada paso genera unas lecciones aprendidas que deben ser documentadas. Lo anterior hace parte de las buenas prácticas para la dirección de proyectos. A continuación se exponen las lecciones aprendidas del caso anterior.


El grupo de procesos que falló en el proyecto fue el de planeación específicamente en las áreas de conocimiento de alcance, comunicaciones, recursos humanos, comunicaciones y riesgos. La planeación del proyecto debe realizarse desde el inicio y se debe realizar de manera detallada, describiendo exhaustivamente las actividades que se llevan a cabo en cada área de conocimiento.


A pesar de que las directivas de la OSR tenían definido un plan de proyecto, los entregables no contaban con un plan de contingencia u otras alternativas para completarlos en caso de que se presentaran contratiempos y existieran sobrecostos. El plan de proyecto no estaba descrito con el nivel de detalle suficiente. Sin embargo intentaron solucionar los problemas que esto generó a través de la aplicación del estándar ITIL.


Pero aún los problemas no tenían una solución definitiva a través del Centro de Servicios en las oficinas. En ese sentido uno de los problemas de la organización era el no tener definido el alcance del proyecto. Por tanto la primera lección a aplicar en todo proyecto es realizar un plan de proyecto lo suficientemente detallado para todos los interesados. Aquí se deben involucrar los entregables de cada una de las partes interesadas en el proyecto.


En ese sentido se debe realizar un plan de gestión del alcance del proyecto como lo realizó Miguel Huertas para la OSR. En este plan se detallaron las responsabilidades de los interesados y los entregables que debían presentar. Adicionalmente el plan de gestión del alcance incluyó los límites del proyecto así como la aclaración de tareas del equipo de trabajo para desarrollar el proyecto eficazmente.


Otro aspecto que no funcionó correctamente fue la planeación de la gestión para el recurso humano. Los funcionarios no fueron capacitados en el nuevo sistema con la regularidad que ameritaba y además, no se tuvo en cuenta la opinión de los funcionarios respecto a la experiencia con el sistema de información anterior. Consecuencia de esto la OSR presentó demoras en los tiempos de respuesta, baja productividad del personal e inconvenientes en el ambiente de trabajo. ¿Cómo pudo el director de proyectos solucionar esta situación? identificando los roles, funciones y relaciones de los operarios con el SIR y cada cargo administrativo en todas las oficinas de la OSR. De igual manera estableció estrategias motivacionales para todas las oficinas de la organización para mejorar el ambiente de trabajo.


Respecto a las comunicaciones el proyecto ya presentaba inconvenientes desde sus inicios puesto que la infraestructura de la organización no podía soportar la migración de datos en todas las oficinas: unas empleaban tecnología satelital y otras banda ancha. Adicionalmente las directivas de la OSR no tenían establecido el número de canales de comunicación suficientes.


Para planear la gestión de comunicaciones, el director de proyecto y su equipo debe realizar un plan de comunicaciones que comprenda las necesidades informativas de los interesados.


El director de proyectos del caso realizó dicho plan en el que incluyó la definición de los canales de comunicación y las métricas para los mismos aplicadas en las oficinas de ciudades grandes. Para las ciudades donde la tecnología para la comunicación era satelital decidió aplicar medidas en los tiempos de respuesta al usuario para determinar las causas operacionales que las propiciaban. Tuvo en cuenta los métodos de comunicación que la organización estaba efectuando y detalló la manera en que los mensajes por medios electrónicos debían ser direccionados. De igual manera especificó el propósito de cada conferencia en las ciudades donde se llevaron a cabo.


Por otro lado, el director de proyecto debe estar en condiciones de asegurar a los interesados del proyecto que los entregables serán completados a tiempo y dentro del presupuesto estimado independientemente de los riesgos que se presenten. Por lo que el proceso de planificación de riesgos debe empezar tan pronto inicia el proyecto.


Las fases de cada proceso y toda actividad que se realice dentro del proyecto genera un grado de incertidumbre y un impacto en la planeación inicial. Los riesgos son ineludibles pero mitigables. Por tanto es pertinente llevar a cabo un plan para la gestión del riesgo. En el caso de la OSR nunca se contempló la planeación de los riesgos respecto al rendimiento del SIRC. Tampoco se tomaron medidas para el contratista en cuanto a los incumplimientos en los contratos.


Una vez identificados los problemas en cuanto a la planeación de riesgos, el director de proyecto y su equipo desarrollaron un plan de gestión de riesgos que comprendía las acciones para mitigar los problemas que pudieran presentarse en el rendimiento del software y en el incumplimiento de contratos.


Como actividad principal para evitar problemas de funcionalidad con el software se determinó llevar a cabo pruebas de sistema con profilers o perfiladores para especificar los cuellos de botella y encontrar que había un exceso en el consumo de memoria y de procesador.

Respecto a los inconvenientes con los contratos se estableció una bolsa de horas para el contratista y una deducción a la factura en caso de incumplimientos. Se trabajó de la mano con la mesa de ayuda para llegar a acuerdos a nivel de servicios y priorizar los entregables y funciones del contratista.


Finalmente se documentaron las lecciones aprendidas en cada área de conocimiento para el grupo de procesos de planificación. Se designó un responsable para establecer acciones correctivas y preventivas con el fin de no cometer los mismos errores. Llegados a este punto las lecciones de un proyecto a las preguntas ¿qué salió bien? y ¿qué no salió bien? con el fin de identificar los problemas y los elementos de los cuales un director de proyecto puede prescindir o emplear para comenzar a solucionarlos. Finalmente se estipula qué hacer para mejorar el desempeño general del proyecto y la aplicación de las lecciones aprendidas en proyectos futuros.



No hay comentarios.:

Publicar un comentario

AddThis