Gestión de riesgos: Los imprevistos ocurren

Te gustaría saber mas sobre la gestión de riesgos en proyectos, inscríbete en el webinar gratuito: Gestión de Riesgo ¿cómo disminuir la incertidumbre en tus proyectos?

Artículo por: Thomaz Ottoni da Fonseca.

"Usted no puede predecir el futuro, pero aún así puede multiplicar sus posibilidades de éxito!" 

Solemos pensar de forma lineal: trabajamos pensando en alcanzar determinados resultados y nos parece natural que el resultado será obtenido. Así, no nos preparamos para las ocurrencias que no se planean.

Pero la gran verdad es que no tenemos ningún control sobre lo que efectivamente va a suceder. Podemos tener la ilusión, pero ella es revelada cuando los imprevistos suceden. Estos, por no ser previstos, están fuera de nuestro control, generando escalofríos en quienes apostaron por la certeza de que sucedería como planeado.

Cuando hablamos de proyectos, hacer frente a los imprevistos es un gran desafío. En general, si invierte mucho dinero, tiempo y energía para alcanzar los objetivos deseados y no tener éxito con ellos puede ser un gran dolor de cabeza o incluso trágico.

Plantilla del plan de gestión de riesgos

Imagen de: pmoinformatica.com

En el marco de la Gerencia de Proyectos, un Plan de Gestión de Riesgos describe como se estructurarán y llevaran a cabo las actividades de Gestión de Riesgos en el Proyecto y es uno de los componentes que integra el Plan de Dirección del Proyecto.  (Fuente: La guía del PMBOK).

En el se describen la Metodología de Gestión de Riesgos, Roles y Responsabilidades, Presupuesto asignado, calendario para estas actividades, formatos de los informes y describe como se realizará el seguimiento. Asimismo, contiene las categorías en las que la organización clasifica los riesgos, las definiciones de probabilidad e impacto, los criterios para jerarquizar los riesgos según la matriz de probabilidad e impacto y el resultado de la revisión de la tolerancia al riesgo de los interesados (Stakeholders).

PMOInformatica.com, “La Oficina de Proyectos de Informática”, presenta la plantilla del "Plan de Gestión de Riesgos". Está plantilla está basada en el PMBOK.

Errores clásicos en la gestión de desarrollo de software

Imagen obtenida de: comerecommended.com

En 1996, Steve McConnel, un influyente consultor de la industria del desarrollo del software, público su obra “Desarrollo Rápido: Domesticando Cronogramas Salvajes de Software” (Rapid Development: Taming Wild Software Schedules).

Una de las secciones del libro, describen los errores clásico al tratar de acelerar (o hacer Fastrack) de los proyectos, prácticas de desarrollo de software que son seleccionadas con tanta frecuencia y con los mismos malos resultados predecibles, que merecen ser llamadas “clásicos”, y que siguen estando muy vigentes a pesar que la obra se público hace 17 años.

¿Algunas de estas prácticas erróneas le son familiares?, por ejemplo, ¿Qué hacemos si un proyecto está retrasado?, ¿incorporamos más gente?, ¿que hacemos si algún integrante está dañando la productividad del equipo?, ¿esperamos hasta el final del proyecto para despedirle?, o ¿que haría si le han asignado un proyecto agresivo en fecha?, ¿reclutar a todos desarrolladores disponibles (inclusive si son novatos) e iniciar lo antes posible sin planificación?.

A continuación dejamos la lista, si conoces algún error clásico que no esté incluido, te invitamos a dejar un comentario.

5 preguntas y respuestas sobre la identificación de riesgos

Imagen de: Picasa Web Albums

Todo proyecto siempre poseen niveles de incertidumbre sobre la actividad a realizar y el producto a entregar, son riesgos que deben ser gestionados.

En este artículo se exploran 5 preguntas y respuestas sobre la identificación de los riesgos en un proyecto, incluyendo quien debe participar, cuando debe hacerse, cuando termina (o más bien no termina) la identificación de riesgos, la importancia de la creatividad, el pensamiento innovador, herramientas y técnicas para la identificación de los riesgos.

El verdadero valor de un plan de riesgos, no reside en el cálculo de valor monetario, sino en la identificación de todos los riesgos y en la definición de planes de respuesta.

Identificar riesgos en un proyecto no se trata sólo de herramientas y técnicas, la creatividad, el pensamiento innovador y participación de todos los integrantes del equipo juegan un papel importante.

Presentamos a continuación 5 preguntas y respuestas sobre la identificación de riesgos:

10 actividades críticas a incluir en todo plan de desarrollo de un software

Imagen de: Picasa Web Albums

En el mundo de la informática, los clientes e inclusive nuestros Gerentes y Directores, esperan que cuando nos presenten un problema de ingeniería de software estemos en capacidad de responder de inmediato ¿para qué fecha cree usted que podría estar desarrollado y entregado?

Sin embargo, debe tenerse extremo cuidado al proporcionar fechas, pues los desarrollos de software suelen presentar muchos imponderables, que deben ser cuidadosamente analizados.

Una de las peores situaciones que se le pueden presentar a un analistas-programador de software, arquitecto, líder de equipo o Gerente de proyecto, es darse cuenta en la mitad de la ejecución, que actividades críticas no fueron consideradas cuando se planificó y comunicó una fecha de entrega.

En este artículo, se exploran una serie aspectos con frecuencia omitidos, pero que deben considerarse en la planificación de todo desarrollo de software. Van desde los tiempos para aprobaciones de los diseños, integraciones de códigos, instalación de ambientes de prueba, entre otros.

Para ayudar a los analistas-programadores, líderes de grupo y Gerentes de Proyectos de Software en esta tarea, presentamos a continuación las actividades críticas que no deben faltar en un plan de desarrollo de software.

Cómo hacer el seguimiento de los riesgos en proyectos

Imagen de: Picasa Web Albums

La Gestión de riesgos de un proyecto no concluye cuando se ha terminado la planificación, se han identificado los riesgos y se han comunicado a los responsables, sino que la misma debe continuar durante toda la ejecución, por medio del seguimiento de los riesgos y a la implementación de los planes de respuesta.

En este artículo, se explora una agenda para hacer seguimiento periódicamente a los riesgos de un proyecto, que abarca el proceso de monitorear la implementación de los planes de respuesta, seguimiento de los riesgos identificados, monitoreo de riesgos residuales, identificación de nuevos riesgos y la evaluación de la efectividad de los planes de respuesta al riesgo.

El artículo, está basado en la guía de estándares definidos por el “Project Management Institute” (PMI), organización que describe en amplio detalle los procedimientos de la gestión de riesgos en un proyecto.

Presentamos a continuación la agenda para el seguimiento de riesgos de un proyecto:

Plantilla para el registro y seguimiento de riesgos en proyectos

Imagen de: La Oficina de Proyectos de Informática

Presentamos a continuación una versión revisada y actualizada a Octubre de 2012 de la Plantilla de Gestión de Riesgos del blog de “La Oficina de Proyectos de Informática”.

La Gestión de Riesgos, es una de las áreas más importantes de la Gestión de Proyectos, y para ejecutarla se recomienda usar una plantilla que permita documentar el problema u oportunidad, causa raíz de la situación, valoraciones de probabilidad e impacto y planes de respuesta.

En esta versión se ha agregado un esquema de valoración de probabilidades e impactos con escala del 0 al 1, diferenciando el impacto sobre cada objetivo de proyecto (Alcance, Tiempo, Costo y Calidad), para luego calcular una valoración global basada en ponderaciones de dichos objetivos, permitiendo asignar un nivel de prioridad al riesgo.

Adicionalmente, se han agregado columnas para la fecha de identificación, fecha de activación del riesgo, dueño (owner) del riesgo distinto del responsable y una columna para describir y hacer referencia.

Presentamos a continuación la versión Octubre de 2012 de la Plantilla de Gestión de Riesgos:

Ambientes de pruebas integrales de software: Buenas prácticas

Imagen de: Picasa Web Albums

El desarrollo de software hoy en día está caracterizado por múltiples equipos de proyectos y mantenimientos trabajando de forma simultánea, bajo cronogramas cada vez más exigentes y desarrollando sistemas que interoperan con variedad de otras aplicaciones y plataformas. Bajo un escenario como este, la gestión de los ambientes (entornos) de pruebas integrales (System Integration Tests, o SIT), adquiere gran importancia para asegurar que el Software sea puesto en producción con los niveles necesarios de calidad.

En este artículo se exploran una serie de buenas prácticas en la administración de ambientes de prueba integrales de sistema (SIT). Abarcan la definición de características del ambiente de pruebas SIT, restricciones que deben aplicarse sobre el ambiente, homologación con producción, procedimientos a implementar para una buena gestión de los ambientes y prácticas que deben tener en cuenta los equipos de pruebas de los diferentes proyectos.

Muchas de estas prácticas también aplican para los ambientes de desarrollo (Ver aquí).

A continuación las buenas prácticas para la administración de ambientes de pruebas SIT:

Plantilla para el registro y seguimiento de riesgos en proyectos

Imagen de: Picasa Web Albums

Nota: La plantilla de gestión de riesgos ha sido actualizada, ver versión actualizada aquí.

Una de las áreas más importantes de la Gestión de Proyectos es la Gestión de los Riesgos. Para ejecutarla de forma adecuada, se requiere manejar una plantilla de listado o registro de los riesgos en la que se documente la descripción del problema u oportunidad, causa raíz de la situación, objetivo de proyecto afectado, tipo y categoría de riesgo, planes de respuesta predefinidos, asignación de responsable, estrategia de respuesta y plan de respuesta.

En este artículo, se explora la Plantilla para la Gestión de Riesgos en Proyectos, elaborada por: “La Oficina de Proyectos de Informática”.

Ambientes de desarrollo de software : Buenas prácticas

Imagen de: Tron Legacy. Disney

Cada vez adquiere una mayor importancia la definición de procedimientos adecuados para administrar los ambientes de desarrollo de software, considerando que las empresas en la actualidad demandan la ejecución de múltiples proyectos simultáneos, con tiempos de puesta en producción exigentes, lo que conlleva a muchos desarrolladores de software, tanto internos como externos a la organización, compartiendo los mismos ambientes de desarrollo.

En este artículo, se exploran algunas buenas prácticas para la administración de ambientes de desarrollo, que van desde la definición las características adecuadas de infraestructura, base de datos, organización, planeación y procedimientos de cambios, homologación, altas y bajas.

Presentamos a continuación las buenas prácticas para ambientes de desarrollo de software.

Como lidiar con interesados (stakeholders) problemáticos

Imagen de: Picasa Web Albums

Todo proyecto de cualquier área tendrá que enfrentar tarde o temprano algún participante o interesado problemático (Ej. Usuarios finales, Clientes, jefes de departamento, integrantes de equipo, etc.), diversas pueden ser las situaciones, amenaza para la agenda personal, estabilidad, resistencia al cambio o a las nuevas tecnologías.

Para lidiar con esto, en primer lugar debe entenderse su visión de la organización, motivaciones y objetivos, para luego desarrollar estrategias en función de sus niveles de influencia y participación en el proyecto.

Presentamos a continuación algunas estrategias para entender las motivaciones de los interesados problemáticos, contrarrestar su influencia e inclusive ganar su cooperación.

Que son los riesgos en los proyectos

La siguiente definición de riesgos es cita textual del Libro del Project Management Institute (PMBOK) cuarta edición, página 275:

Un riesgo es un evento o condición incierta que, si sucede, tiene un efecto en por lo menos uno de los objetivos del proyecto. Los objetivos pueden incluir el alcance, el cronograma, el costo y la calidad. Un riesgo puede tener una o más causas y, si sucede, uno o más impactos. Una causa puede ser un requisito, un supuesto, una restricción o una condición que crea la posibilidad de consecuencias tanto negativas como positivas. Por ejemplo, las causas podrían ser el requisito de obtener un permiso ambiental para realizar el trabajo, o contar con una cantidad limitada de personal asignado para el diseño del proyecto.

El patrocinador (Sponsor) del proyecto: Rol que debe asumir y lo que no debe hacer

Imagen de: Picasa Web Albums

El rol del patrocinador (Sponsor) es fundamental para la ejecución exitosa de proyectos en cualquier área profesional, incluyendo la Tecnología de Información (TI), pues es quien realiza la principal labor de promoción y la procura del apoyo necesario dentro de la organización.

Sin embargo, ciertas conductas de un patrocinador pueden incrementar los riesgos y conducir al fracaso, que van desde querer inmiscuirse demasiado, no realizar su labor de promoción de los beneficios en los altos niveles de la organización, no proteger el proyecto de cambios innecesarios o ser indiferente al proyecto.

Sin embargo, es necesario que los Gerentes de Proyectos entendamos un aspecto clave: El tener un patrocinador con estas conductas no nos exime nuestra responsabilidad de asegurar el éxito del proyecto, es nuestro trabajo comunicarnos con él o ella acerca de esta situación y hacérselo ver.

Conductas negativas como por ejemplo no trabajar en equipo con el patrocinador o desobedecer sus instrucciones sólo contribuirá acelerar el fracaso del proyecto y por lo tanto el nuestro.

Presentamos a continuación el papel a desempeñar por el patrocinador del proyecto y lo que este no debe hacer.

Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)

Imagen Obtenida de: Picasa Web Albums

Un aspecto importante a la hora en que seamos participes en proyectos de tecnología de información (TI) o desarrollo de software, es que nuestro día a día tomemos acciones preventivas que nos permitan evitar retrabajos y anticipar situaciones que puedan causarnos retrasos en desarrollos y entregas.

En este artículo exploraremos distintas acciones preventivas que podemos tomar en proyectos de TI, que van desde identificar todos los requerimientos de todas las áreas implicadas desde la fase de análisis, hasta prevenir situaciones con los entornos y ambientes de base de datos.

Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución

Imagen obtenida de: Picasa Web Albums

Una situación que puede tocar en algún momento de la carrera de todo Jefe de proyectos de informática, es tener que encargarse de un proyecto ya comenzado. En esta situación es conveniente comenzar con una evaluación del proyecto y lo que se ha hecho en fases anteriores, a efectos de identificar situaciones y tomar acciones correctivas.

Presentamos a continuación las preguntas que debe hacer al encargarse de un proyecto de informática.

Diseño y desarrollo de software en proyectos Fastrack: Como minimizar los riesgos

Imagen proporcionada por Picasa Web Albums

Hoy en día muchos proyectos de informática se están ejecutando bajo un enfoque de “Fastrack”, buscando disminuir el tiempo de desarrollo de software, por medio de la aplicación de diseños prefabricados y la ejecución en paralelo de actividades como el análisis, diseño, desarrollo y pruebas.

La aplicación de este enfoque implica comenzar a desarrollar el Software antes de tener el diseño detallado completo y aprobado en su totalidad, situación que de por sí supone riesgos de retrabajo más adelante en el proyecto, originado en nueva información técnica o cambios en los requerimientos.

En este artículo se exploran las consecuencias negativas de comenzar a desarrollar sin tener un diseño detallado aprobado y se presentan algunas recomendaciones que minimizarán dichos riesgos.