Globedia.com

×

Error de autenticación

Ha habido un problema a la hora de conectarse a la red social. Por favor intentalo de nuevo

Si el problema persiste, nos lo puedes decir AQUÍ

×
×
Recibir alertas

¿Quieres recibir una notificación por email cada vez que Katbyan escriba una noticia?

Gestión de proyectos y Gestión del Riesgo

06/04/2011 08:53 0 Comentarios Lectura: ( palabras)

La gestión del riesgo define alguno de los procesos más importantes a ejecutar como parte de la definición del PMBook. Los procesos son rígidos y permanentes, mientras los proyectos son flexibles y limitados en el tiempo. Difícil contradicción..

Acometer la gestión de los riesgos en un proyecto TI supone una de las tareas más exigentes y complejas, en el caso de una correcta y normal ejecución de los procesos de gestión. La realidad, muchas veces machacona, se interpone entre las buenas prácticas y la realidad. Su resultado en el caso que nos ocupa es una transformación, la crisálida (riesgo), se transforma en mariposa (incidencia), pero no precisamente en una agradable mariposa de vivos colores que revolotea tranquila entre las flores del jardín...

Desde nuestro punto de vista, el trabajo con el riesgo ha de comenzar desde la definición del proyecto, si es un proyecto interno, o desde la negociación de contrato, si somos proveedores. Generalmente en estas fases previas, la visión del futuro proyecto suele ser altamente optimista, un departamento que está a punto de conseguir el tan ansiado proyecto que mejore su situación, o un nuevo contrato que va a mejorar los números del departamento comercial. En esta fase se da un buen momento para poner el riesgo sobre la mesa y bajar las optimistas perspectivas de todos los participantes al menos a un nivel realista.

Europa  PressBien, el proyecto arranca, y se puede dar la circunstancia en los dos casos identificados, que el proyecto inicie sus primeras fases sin un jefe de proyecto. No es necesario, en este momento todos los implicados saben lo que quieren hacer, y parece que tienen claro el cómo. El resultado es que el jefe de proyecto es asignado e incorporado cuando ya se inicia la fase de desarrollo o implantación, según el objetivo del proyecto. En este caso ya no existe el riesgo, el proyecto es ya una incidencia, le han salido patas y persigue al jefe de proyectos por los pasillos.

Puede ocurrir, según las buenas prácticas que el jefe de proyecto esté desde el momento cero, sea el principal actor del kickoff, ejecute la fase de lanzamiento, lidere las primeras fases de análisis, ... Aquí siempre decimos que estas fases del proyecto son como el descubrimiento de un nuevo mundo. Colón pensó haberlo descubierto, y con esta guisa volvió a Castilla, pero realmente no, sólo pisó una isla, el nuevo mundo estaba un poco más allá y era de dimesiones extraordinarias, como más tarde descubrirían. Pues bien, esta imagen es la realidad, a pesar de ser el principal actor en las primeras fases, el jefe de proyecto, basándose en su experiencia, conocimientos y apoyo del equipo, podrá identificar el nuevo mundo, saber que existe, estimar sus dimensiones y probabilidades de conquistarlo en su totalidad, sólo a priori.

Evalúen, por favor, cuando salgan de su asombro, cambien de proveedor o, busquen un jefe de proyectos externo, de alto nivel, que les acompañe en su ejecución

Pero será el devenir del proyecto el que vaya ajustando estas estimaciones. Si bien ajustar debería ser la realidad, no es desafortunadamente con lo que se encuentra el jefe de proyectos, pues las únicas verdades serán el coste y la fecha de entrega (el primero con tendencia a la baja y la segunda inamovible). El conocimiento adquirido en fases tempranas permite identificar riesgos, pero comenzamos a descartar también. En primer lugar hay que desestimar el publicitar los riesgos cuyo origen estuviera en la empresa cliente (si somos proveedores), claro ponerlo sobre el papel puede suponer que no les guste oirlo, pongan reticencias, estamos al inicio del proyecto... Ah, bueno, son riesgos críticos, pero lo comercial manda, no aparecerán. Luego están nuestros riesgos internos, claro no vamos a poner sobre la mesa nuestras deficiencias, es que les hemos vendido que éramos los mejores y si registramos eso, ... Ok, comercial manda. Resultado, la lista de riesgos que aparece en el documento de salida de las primeras fases es un compendio de obviedades, con estimaciones obvias y representatividad ninguna. Resultado, si no asumimos los riesgos, estos no existen, mejor para todos, y si finalmente terminan siendo reales, como ya no serán riesgos sino incidencias, pues nunca existieron.

Ah! Entonces el proyecto se ejecuta, y en fases posteriores de manera casi mágica aparece una incidencia, cuyo riesgo estaba identificado, pero del que nadie quiso oir hablar. Primer resultado, el jefe de proyecto es llamado al orden "¿cómo podemos encontrarnos con este problema?" Segundo resultado, el riesgo, que se negó, y cuya resolución podría haber significado una imputación de costes en su momento de identificación que fueron evitados, lo cual a fecha de hoy ha supuesto un "control" del coste del proyecto (esta fue una idea genial del comercial), es una incidencia. Se va a proceder a solventar ¿cómo? Fácil, resolver las incidencias tiene un coste cero, sólo supone exigir al equipo que haga más horas para que ésta quede resuelta y la senda crítica no sufra un solo día de retardo. ¡Brillante! Como no se van a pagar más horas extras, el coste marginal tiende a cero, la planificación y los costes no se ven afectados. Además el cliente nos verá el sobreesfuerzo y se sentirá contento con nuestra empresa por "su" compromiso. ¿Compromiso de la empresa? Ninguno, si no, no tendríamos hoy esta incidencia sobre la mesa. ¿Esfuerzo de la empresa? Ninguno, las personas jurídicas no hacen sobreesfuerzos, sólo existen. Quien lo hace es el equipo, y se llama Juan, María, ... El resultado, el equipo que no es el responsable de la incidencia es quien la sufre, bajan los niveles de motivación, los niveles de compromiso, de calidad, y ¡oh! un nuevo riesgo, que tampoco se deberá registrar. Resultado, la pescadilla que se morderá la cola por todo lo queda del proyecto, proyecto que además tiene pocos visos de ser exitoso. Pocos no, ninguno...

Toda esta problemática en torno a la gestión del riesto tiene su disparador real en el tratamiento de los costes. Sólo parecen existir los costes económicos y de tiempo imputados. Pero, nada más lejano, los costes reales son los de oportunidad. Negar el riesgo demora los proyectos o provoca que el impacto positivo de éste en los procesos del departamento en que se implantan sea inferior a lo esperado. Eso es un coste, y seguramante multiplique n veces el valor económico que hubiera supuesto minimizar el riesgo en su momento. Negar el riesgo supone que los proyectos llegan a un punto de no retorno, o se cancelan o han de ser negociados. En el primer caso, el derroche económico es obvio, luego se suele acudir a la segunda opción, la renegociación; aquí participan los "mayores" de la empresa y del proveedor (si lo hubiera). Sus horas de trabajo, aún teniendo costes muy altos, no quedan registradas en el proyecto, son costes fijos. ¡Ah!, pues tengan claro que su dedicación mientras negocian, es un coste, y un coste oportunidad brutal. ¿Por lo que se les paga cuántas alternativas más productivas tendrián para el tiempo dedicado a negociar?

Evalúen, por favor, evaluénlo, y después, cuando salgan de su asombro, cambien de proveedor o, si su proyecto es interno, busquen un jefe de proyectos externo, de alto nivel, que les acompañe en su ejecución.

Los procesos son rígidos y permanentes, mientras los proyectos son flexibles y limitados en el tiempo. Difícil contradicción..

Katby@n


Sobre esta noticia

Autor:
Katbyan (55 noticias)
Visitas:
8080
Tipo:
Reportaje
Licencia:
Creative Commons License
¿Problemas con esta noticia?
×
Denunciar esta noticia por

Denunciar

Comentarios

Aún no hay comentarios en esta noticia.