Maria Eugenia Arevalo's Blog

Principios Fundamentales Aplicados a la Administración de Riesgos en MSF octubre 14, 2010

Posted by arevalomaria in MSF, PMBOK.
add a comment

Definición de Riesgo y Administración del Riesgo

Antes de comenzar a desarrollar el tema sobre la administración del riesgo con MSF, es importante hacer una definición de riesgo, en este sentido cabe destacar que el riesgo es una situación de probabilidad de ocurrencia de un evento, una vulnerabilidad, una amenaza. Subrayo probabilidad porque así debemos enfocarlo, no es una certeza, en otras palabras la probabilidad de ocurrencia no puede ser 0 ni puede ser 1, ¿Por qué? Si es 0 es porque estamos seguros de que un evento jamás va a ocurrir entonces no hay riesgo y si es 1 es un evento seguro de que ocurrirá y allí estaríamos más bien preparados para el hecho.

Basándonos en la definición estricta del riesgo y analizando el momento que planificamos las actividades de un proyecto, observaremos que no estamos seguros de que todas las actividades puedan ejecutarse, sin embargo no podríamos decir que todas las actividades del proyecto  son un riesgo, ¿Por qué en la vida practica NO consideramos todas las actividades como un riesgo?, sencillo sabemos que existen actividades que tienen mayor probabilidad de ocurrencia que otras.

Continuando con el párrafo anterior, dentro del manejo de riesgo del proyecto ponemos aquellas actividades que tengan una probabilidad de afectar a nuestro proyecto en tiempo, costo y alcance más alta que otras.

Un riesgo es un evento que nos pueda afectar en tiempo, costo, alcance y calidad al proyecto.  Es aquí donde surge la importancia de la Administración del Riesgo.

La Administración del Riesgo aumenta la probabilidad de éxito en un proyecto, minimizando el potencial para el fracaso.

La Administración del Riesgo puede definirse como una forma de abordar un problema desde un punto de vista gerencial para disminuir los riesgos inherentes al proyecto La administración del riesgo pretende identificar, estudiar y eliminar las fuentes de riesgo antes de que comiencen a amenazar el éxito o la finalización exitosa de un proyecto

Principios Fundamentales Aplicados a la Administración de Riesgos en MSF

1 Mantenernos Alertas y preparados para el cambio.

Como administradores del riesgo debemos desarrollar habilidades básicas para mantenernos alertas, habilidades que nos permitan ejecutar un buen papel frente a los cambios que podemos estar haciendo durante todo el ciclo de vida del proyecto, producto del análisis de riesgos del mismo. Estas habilidades son:

1. Identificar: Tenemos que tomar estándares o guías, que pueden ser propios del proyecto, del cliente, de la empresa donde laboramos, para aprender y visualizar que es un riesgo y que no.
2. Analizar: Es la habilidad más importante porque el análisis arroja sobre una actividad de riesgo su impacto en costo, tiempo y calidad.
3. Planear: Acciones concretas para contener el riesgo, poner en blanco y negro que hacer para que los riesgos se minimicen.
4. Controlar, administrar y monitorear los riesgos con todas las actualizaciones.  A menudo puede pasar que un riesgo que planeamos no se convierte en un evento, sin embargo el riesgo una vez que transcurre el proyecto desaparece y aparecen otros  nuevos, es un proceso constante de identificación, análisis, evaluación y monitoreo de los riesgos, es importante estar pendiente hacia todos los riesgos que puedan ocurrir al principio del proyecto y durante todo el ciclo de vida.

Producto del constante monitoreo sobre los riesgos durante el ciclo de vida del proyecto puede originar cambios en las actividades del proyecto en momentos determinados con la finalidad de minimizar amenazas y aumentar la probabilidad de éxito.

Un enfoque proactivo permite al equipo aceptar el cambio y convertirlo en una oportunidad, y con ello evitar que el cambio pueda  convertirse en una fuerza perturbadora, en algo negativo.

2  Promover una Comunicación Abierta en el Modelo de equipo de trabajo MSF

MSF alienta una actitud de comunicación abierta hacia debatir los riesgos, tanto con los miembros de equipo de trabajo como con los principales interesados externos del  proyecto. Todos los miembros del equipo deben participar en la identificación de riesgos y en el análisis de los mismos.

Los jefes de equipo y la administración de riesgos deben apoyar y fomentar el desarrollo de una cultura de no culpar a ningún miembro del proyecto sobre la probabilidad de que ocurra un riesgo, al contrario, se debe promover una discusión franca y abierta de los riesgos del proyecto con todos los afectados por ese riesgo, para conducirnos a una mayor precisión en la evaluación del estado del proyecto y una mejor toma de decisiones, tanto dentro del equipo como en la dirección ejecutiva y los patrocinadores.

3 Cuentas Claras, Responsabilidad Compartida.

Como describimos en un artículo publicado anteriormente sobre el El Modelo de equipo MSF, este modelo se basa en la premisa de que cada función presenta una perspectiva única en el proyecto y que ninguna persona por sí misma puede representar de una manera satisfactoria todos los objetivos de calidad de todas las funciones. Sin embargo, el cliente necesita una sola fuente de información que cuente con autoridad sobre el estado del proyecto, las acciones y los problemas actuales. Para resolver este dilema, el equipo de compañeros debe combinar una línea clara de responsabilidad hacia el cliente con la responsabilidad compartida con el fin de lograr el éxito en general.

Dentro del equipo, cada función es responsable de todas las actividades que son necesarias para lograr su propio objetivo de calidad.  Cada miembro del equipo es responsable del éxito general del proyecto y de la calidad de la solución y se espera que contribuya con ideas y observaciones que se deriven de su conocimiento incluso en áreas en las que no es responsable de una manera personal.

En concreto, las funciones del equipo MSF comparten responsabilidad en muchos aspectos de la administración del proyecto, por ejemplo, la administración del riesgo, la administración del tiempo, la administración de la calidad, el planeamiento, la programación, la selección de los miembros del equipo y la administración de los recursos humanos.

 Bajo esta premisa, no hay una sola persona que administre el riesgo dentro de MSF, cada integrante del equipo debe rendir  cuentas claras sobre sus actividades actividades y la administración de riesgos.

Sin embargo es el área de Gerencia de Proyectos quien lidere en general la administración del riesgo.  Es el Gerente de Proyecto el responsable general de la Administración del Riesgo.

4. Aprender de Todas las Experiencias

En todas las disciplinas, y dentro de la vida misma el aprendizaje continuo sobre las experiencias o hechos nos dan la condición de mejorar perennemente.

MSF nos invita a analizar constantemente las actividades del proyecto, los factores de éxito, los factores de riesgo, el conocimiento acumulado de un proyecto puede disminuir la incertidumbre en torno a la toma de decisiones.

Documentar las versiones del proyecto, los cambios efectuados, como se abordaron las situaciones de riesgos, es colocar conocimiento disponible para que otros puedan aprovechar en el próximo proyecto.

Gerenciando una sesión de resolución de problemas mayo 30, 2010

Posted by arevalomaria in MSF, PMBOK.
add a comment

Generalmente, ponemos en practica las opciones que tradicionalmente nos han funcionado bien, que aunque la experiencia es un aval que puede garantizar el exito, en algunas oportunidades puede convertirse en un enemigo para poner en marcha soluciones creativas nuevas.  El escrito que les presento hoy es una invitacion a reflexionar sobre como enfrentamos situaciones y planteamos resolverlas, mecanismos, y una autoevaluacion que nos permitira mejorar cuando tengamos que liderar un proyecto.

Si pertenecemos a un equipo de proyecto como lideres, debemos plantear sesiones creativas, donde cada integrante pueda exponer su punto de vista acerca de como abordar la solucion a un punto expuesto. Evalue estas sesiones mejor conocidas como reuniones de proyecto,  por ejemplo grabandolas y luego sorprendase al escuchar su propia negativa a los planteamientos expuestos por sus compañeros de equipo. Cuidado puede estar generando la sensacion a sus compañeros de reuniones que al final le quitan tiempo, no son productivas y no estimulan la creatividad del grupo.

Probablemente encontrara en su equipo algunas de estas personalidades: (a) El experto:  conoce con profundidad la tecnologia, (b) El Persuasor que es una personalidad de tipo amistosa, que insita al grupo a aceptar ideas y aproximaciones basadas en una logica inherente, (c) El confrontador: tiene la personalidad de no creer en nada y no deja nada oculto bajo la mesa, (d) El soñador quien provee pensamientos fantasiosos y (e) El ayudante: quien suaviza cualquier sentimiento de roce y mantiene el proceso de grupo refrescandolo.  La presencia de cualquier tipo de personalidad en el grupo añade ingredientes esenciales que nos hace reflexionar sobre que tecnicas manejar para poder guiar realmente a la resolucion de problemas.

A continuacion las tecnicas mas usadas:

1. Tormenta de Ideas:  El objetivo es generar, entre un grupo de personas el mayor numero de ideas y alternativas de respuestas.  Nada es rechazado ni criticado. Sin embargo las ideas son escritas en forma secuencial para su evaluación y desarrollo.

2. Tormenta de Ideas Inversa:  Consiste en ser criticos en vez de suspender el juicio.  Nos prepara para evaluar las cosas malas de las operaciones, procesos, sistema o producto para sugerir formas para solucionarlo.

3. Sinergia.  Funciona como el juego de “pinball” menta.  Se buscan soluciones creativas a un problema especifico en dos fases.  Fase I, los participantes hacen lo extraño familiar a través del análisis, generalizaciones y busquedas de modelos. Fase II, se hace el intento de hacer lo familiar extraño a traves de la analogía personal, directa, simbolica o fantasiosa. La sinergia es una maniobra alegre , dinamica en la cual soluciones racionales y obvias son abandonadassustituyendola por lo que pudiera ser absurdo o irrelevante.

4. Metodo Grodon: Su finalidad es generar en el equipo nuevos puntos de vista.  se utiliza en grupos pequeños que no estan concientes de la naturaleza exacta del problema actual.  El intento es minimizar ideas preconcebidas y patrones de hábitos.  Con esta tecnica podemos evitar que se alcance una solución prematura antes de haber terminado la discusion general del problema.

5. Metodo de lista de chequeo:  El problema es analizado contra una lista preparada de retos hasta obtener una idea gancho.

Existen otros metodos como listas de entrada y salida, asociacion libre, metodo de la libreta de coleccion entre otros.

Como lideres de proyectos, debemos hacer renovaciones de nuestras tecnicas de trabajo con la finalidad de motivar a nuestro equipo, evaluar la creatividad de nuestra gente, aceptar puntos de vistas y sugerencias de nuestro equipo creativo, todo con la finalidad de alcanzar resolver situaciones de la mejor forma posible, pensando siempre en el crecimiento, mejora y puesta en marcha con exito del proyecto que manejamos.

Ejemplo de Documento Vision y Alcance enero 7, 2010

Posted by arevalomaria in MSF, PMBOK.
18 comments

Como bien se menciono en la Fase de Inicio de todo proyecto, uno de los factores bases del exito futuro del mismo es el dejar bien claro cual es la Vision y el Alcance del proyecto donde quede bien enmarcado que vamos hacer y hasta donde vamos a llegar.

En una oportunidad evaluando la plataforma de un cliente, nos propusieron crear un mapa de apliaciones para poder desarrollar nuevamente todas sus aplicaciones en .NET, debido a que las que se encontraban en operaciones estaban desarrolladas en Access 2003 y evidentemente esta el tema de crecimiento, performance, seguridad, replicaciones, etc, etc.

Lo primero fue proponer una Arquitectura Orientada a Servicios con un mapa de aplicaciones que iba a permitir focalizar poco a poco cada desarrollo, donde este seria el macro proyecto y cada aplicacion un proyecto con objetivos, tiempo, recursos, metas independientes pero que eran parte de un objetivo general y parte de una meta final.

La estructura del Documento de Vision y Alcance que les voy a presentar esta compuesto por:

• Oportunidad de Negocio
• Declaracion de Oportunidad
• Análisis de Beneficios
• Concepto de Solución
• Requerimientos
• Alcance
• Estrategia de Entrega de Versiones
• Criterios de Aceptacion

A continuacion Ejemplo Completo:
Oportunidad de Negocio

En la actualidad, la Gerencia de Sistemas de ABC plantea la inquietud de definir una arquitectura de software que le permita definir los diversos servicios que le van a dar soporte a los requisitos de negocio. Se desea estudiar y presentar la creación de sistemas altamente escalables que reflejan el negocio de la organización, y que a su vez brinde una forma estándar de exposición e invocación de servicios, lo cual facilita la interacción entre diferentes sistemas propios o de terceros. A continuación se presenta la declaración de oportunidad y declaración de visión.

Declaración de Oportunidad

La capacidad para responder rápidamente ante los cambios y optimizar los procesos de negocio es un factor clave para la competitividad y el crecimiento de las organizaciones. La agilidad de éstas puede verse cuestionada si se apoya en entornos de IT que no pueden responder de forma flexible a los cambios que afectan a la actividad de negocio. Liberar el potencial que poseen las aplicaciones y recursos de IT y hacerlo disponible de forma general a toda la organización facilita la optimización de procesos y mejora la agilidad empresarial.

La Arquitectura Orientada a Servicios (SOA, Service Oriented Architecture) es una filosofía de diseño que permite un mejor alineamiento de las Tecnologías de Información (IT) con las necesidades de negocio, permitiendo a empleados, clientes y socios comerciales responder de forma más rápida y adaptarse adecuadamente a las presiones del mercado.

Hoy día, en ABC se encuentran instalados diversos sistemas que componen el ciclo de ingreso como son Romana, Despacho, Distribución, Ventas desarrollados en Access 2003, así como algunos procesos como planificación y presupuestos llevados en hojas de calculo Excel, otros desarrollos como Datastring en .Net y Notas Contables plataforma AS-400.

La empresa necesita poder interconectar los procesos, personas e información tanto con la propia organización ejemplo con Administracion y Finanzas asi como -atravesando sus fronteras- con Centro de Distribucion y Proveedores. Tal como están diseñados e implementados los sistemas en la actualidad hace presentar falta de integración entre los componentes de IT –sistemas, aplicaciones y datos- lo que hace difícil obtener una respuesta rápida y efectiva ante los cambios que afectan de forma natural a los negocios. La inflexibilidad genera costes, reduce la capacidad de respuesta ante los clientes, compromete el cumplimiento con las normativas legales y afecta negativamente a la productividad de los empleados.

En suma, una deficiente integración es uno de los problemas más importantes a lo que las organización debe hacer frente para mantener su competitividad y garantizar su crecimiento.

Se propone una Arquitectura SOA para establecer un marco de diseño para la integración de aplicaciones independientes de manera que desde la red pueda accederse a sus funcionalidades, las cuales se ofrecen como servicios. La forma más habitual de implementarla es mediante Servicios Web, una tecnología basada en estándares e independiente de la plataforma, con la que SOA puede descomponer aplicaciones monolíticas en un conjunto de servicios e implementar esta funcionalidad en forma modular.

Bajo este esquema emprender la migración de las diversas aplicaciones y como será la integración completa de todas.

Declaración de Visión

La meta principal de esta propuesta, es diseñar una arquitectura empresarial orientada a servicios para emprender la migración de las diversas aplicaciones que comprenden en ciclo de ingreso y garantizar la integración de aplicaciones independientes donde se pueda acceder a las funcionalidades de cada aplicación, ofertadas como servicios.

• Análisis de BeneficiosUna vez concluido el Diseño de la Arquitectura los beneficios a obtener son:

Reducir los costos y el tiempo de desarrollo—Los servicios SOA pueden reutilizarse fácilmente y pueden convertirse en nuevas aplicaciones compuestas
Reducir los costos de mantenimiento—Los servicios reutilizables reducen el grado de complejidad interna de los servicios de IT
Aumentar la calidad de los servicios—Una mayor reutilización de servicios crea servicios de mejor calidad en múltiples ciclos de prueba de diferentes consumidores de servicios
Reducir los costos de integración—Los servicios estandarizados pueden trabajar en conjunto, permitiendo que las aplicaciones dispares se conecten con rapidez y facilidad
Reducir el riesgo—Menos servicios reutilizables brindan mayor control sobre las políticas corporativas, y reducen el riesgo general relacionado con el cumplimiento

Concepto de Solución
Metas, Objetivos, Supuestos y Restricciones

· Metas: representa el destino, o el estado al que se quiere llegar por medio de la propuesta
o Generar un mapa con todas las aplicaciones que componen el ciclo de ingreso o interoperabilidad entre las aplicaciones internas y las aplicaciones externas futuras.

· Objetivos: consisten en desglosar las metas en componentes, con el fin de obtener el verdadero nivel de detalles de los fines que se persiguen con las propuesta, y lo que se debe hacer para llegar a ellos.
o Diseñar una arquitectura empresarial con la que se logre:
- Reducir los tiempos de desarrollo
- Integrar procesos aislados
- Automatizar procesos
- Crear servicios web que permitan interacción directa con los clientes y la empresa

· Supuestos: son aquellos factores, que se pueden expresar como elementos que esperan validación por parte de un tercero.
o Apoyo Corporativo para alcanzar las metas y objetivos.

· Restricciones: son aquellos requerimientos no funcionales que delimitan el proceso de desarrollo.
o La propuesta debe generar desarrollos como Aplicaciones Web y/o aplicaciones Windows.

Requerimientos

Requerimientos Operacionales
· Análisis multidimensionales de la data.

Requerimientos de Sistemas
Manejar esquema de arquitectura en tres capas MVC.
Uso de mejores prácticas para el desarrollo de software.

Estrategia de Entrega de Versiones

Se utilizará un modelo de publicación incremental, es decir, se irán cargando en un directorio estándar, todas aquellas versiones que ya hayan sido probadas y validadas por parte de ABC, tomando en cuenta que se hará una revisión previa por cada entregable que sea terminado.

La validación referida consiste en una evaluación basada en umbrales de aceptación (próxima sección), esto consiste en asignar a cada entregable un valor que debe estar comprendido en un intervalo, con un límite inferior y uno superior como calificaciones posibles. Este proceso debe realizarse hasta terminar con el desarrollo de todos los entregables, al final, cuando se hace una prueba de todo el sistema, el criterio de evaluación puede ser un tope mínimo, o un promedio que se debe satisfacer para que la solución entregada pueda pasar al entorno productivo.

Criterios de Aceptación

El valor mínimo para asignar a la evaluación de un entregable es cero (0) puntos.
El valor máximo para asignar a la evaluación de un entregable es diez (10) puntos.
El tope mínimo de aceptación de un entregable es ocho (8) puntos.
El tope mínimo para la aceptación de la solución es un promedio de 9 puntos, promedio que debe calcularse utilizando la ecuación de Media Ponderada.