lunes, 5 de abril de 2010

Gestión de la Incertidumbre ¿Nueva área de Conocimiento?


Me he permitido tomar un artículo de Diego Navarro del Blog direccion-proyectos.blogspot.com por ser por demás interesante y de interés común.


Su índice el fallo escribe: si tu piedad impetra,si tu ingenio excogita, si tu fe intercedepor borrar una línea, tu voz nunca penetra;ni tus lágrimas juntas lavarán una letra.” Rubaiyat, Omar Khayyam.


Primera parte: de la incompetencia inconsciente

A lo largo de estos largos cuatro años de blog se me ha preguntado bastante sobre la incertidumbre, sobretodo solicitando dónde se puede encontrar información sobre “incertidumbre”, concretamente en el contexto de los proyectos –no en balde, pues no cabe duda que la incertidumbre es uno de esos misteriosos personajes ocultos tras la penumbra de la próxima esquina que claramente acechan de manera no menos misteriosa en los proyectos-. Y, la verdad, es que lo primero que se me viene a la cabeza es coger una guitarra que nunca he podido afinar y emular a Manolo Tena y desentonar su “y yo no sé que contestar”.
Bueno, en realidad, así como tal, como un tema en sí, no existe. Más que una guitarra desafinada, ni tan siquiera hay guitarra. Quién sabe si en la edición 69 del PMBOK –ahora acabamos de estrenar la cuarta-, en un futuro no se sabe cuán próximo o lejano, el capítulo 13 –buen número para tan escurridizo asunto, jeje- contenga la décima área de conocimiento, a saber, Gestión de la Incertidumbre.
Pero la verdadera verdad de la buena, es que sí que puedo dar información. Existen cosas muy interesantes ahí fuera sobre el tema sin necesidad de recurrir al agente Mulder; excepto que se encuentran dispersas formando parte de diferentes disciplinas, como pueden ser la psicología, la neurología, la biología, la filosofía, la economía, las matemáticas e, incluso, la literatura. Aunque a la incertidumbre se la conoce sobretodo experimentando la vida, viviéndola, exponiéndose a ella, aprendiendo de ella, sufriendo y/o disfrutando de algunos revolcones con ella. Todo esto que he dicho puede parecer muy pluridisciplinar y fenomenológico, pero es que un director de proyecto que se precie es un verdadero hombre del Renacimiento.
Como, hasta donde llega mi conocimiento, no he visto ningún tratamiento unificado de la incertidumbre en el contexto de los proyectos –concretamente en la línea donde confluirían los estudios de las materias que he citado anteriormente- y, además, se me suele preguntar por ello, he decidido afrontar yo mismo el reto en esta serie indefinida de entradas, a pesar de que un primer pronóstico augure un resultado bastante incierto.Antes de entrar en cualquier discusión acerca de tan escurridizo concepto, deberíamos hacer un esfuerzo por definirlo o, al menos, acotarlo. Para ello voy a enunciar la que considero que es la mejor definición operativa de incertidumbre que, por cierto, no es nada nueva y que se debe a G. L. S. Shackle:
Incertidumbre es anticonocimiento

Y para ilustrarlo voy a valerme de la magistral metáfora que utiliza Nassim N. Taleb en su libro El cisne negro. Cuenta Taleb que Umberto Eco clasifica a los visitantes de su biblioteca personal de más de 30.000 libros en base a dos categorías: aquellos, la gran mayoría, que se quedan impresionados ante el tamaño de su biblioteca y le preguntan cuántos de esos libros ha leído; y esa pequeña minoría que ha captado la verdadera utilidad de la biblioteca como una herramienta de investigación y no como una extensión del ego. Porque, en realidad, los libros ya leídos son menos valiosos que los que quedan por leer y, cuanto mayor es el conocimiento adquirido a través de los libros que hemos leído, mayor debería ser el número de libros no leídos de nuestra biblioteca. Por el contrario, solemos tender a tratar el conocimiento como una propiedad personal que protegemos y defendemos a toda costa, como algo que nos permite escalar puestos en los diferentes niveles de nuestras sociedades, mientras ignoramos, subestimamos en el mejor de los casos, los drásticos efectos que pueden producir todas aquellas sorpresas que se encuentran ocultas en todos los libros no leídos. Nos tomamos el conocimiento demasiado en serio; como poco, mucho más en serio que el anticonocimiento, y esto nos deja en una situación muy desfavorable ante lo desconocido, a merced de la incertidumbre.
Una consecuencia muy importante de esta definición es que el riesgo no es incertidumbre. Que no sepamos en qué medida un hecho concreto y conocido, como por ejemplo que un proveedor no haga cierta entrega crítica a tiempo, pueda o no suceder en un futuro no significa que dejemos, por ello, de tener un conocimiento acerca del hecho ni de sus consecuencias en caso de hacerse una realidad. Resultados inciertos son aquellos que llegan a ocurrir sin haber tenido, ni tan siquiera, un atisbo de conocimiento acerca de su mera existencia. Para los riesgos, existe una disciplina muy bien conocida que es la Gestión de Riesgos; para la incertidumbre, en cambio, sólo podemos esperar a la salida del sol por Antequera.
Se suele vender la Gestión de Riesgos como una panacea, pero creo que no pecaría de atrevimiento temerario si afirmara que es un silencio a gritos entre la mayoría de los directores de proyecto que, en el fondo, no acaba de resolver su problema frente a la incertidumbre. Porque, en realidad, la Gestión de Riesgos nunca ha dejado de aferrarse a lo conocido. En el peor de los casos, la Gestión de Riesgos puede llegar a extrapolar el conocimiento a esa región oscura que aún le está vetada, ejercicio que puede resultar peligroso y desastroso cuando sólo conduce a falsas y erradas ilusiones.Todos los viajes a lo desconocido son inciertos, y son viajes que deben ser realizados sin alforjas porque en la mayoría de los casos sólo son un lastre en ese viaje, unas gafas opacas que nos impiden ver con claridad el paisaje ignoto que se nos va descubriendo a medida que avanzamos. Pueden parecer viajes poco agradables. Hasta peligrosos. Pero son los únicos que ensanchan las fronteras y conducen a grandes recompensas. Porque, como una vez dijo Richard Feynman, es “en la admisión de la ignorancia y de la incertidumbre hay una esperanza para el movimiento continuo de los seres humanos en alguna dirección que no esté confinada y permanentemente bloqueada, como ha sucedido tantas veces en diversos periodos de la historia del hombre”. Y como sucede en tantos proyectos.

Por cierto, curioso título el de esta entrada…

miércoles, 31 de marzo de 2010

Gestión de Requerimientos - Inicio del éxito


Por: Luis Alberto Oviedo Tejada
Los objetivos de un proyecto nos definen el producto o servicio o resultado final a construir por el proyecto. Entonces nuestros esfuerzos como equipo de proyecto se orientan a construir un producto que cumpla con las expectativas de los interesados (stakeholders), tanto internos como externos es un fin primordial, además de hacerlos a tiempo y en el presupuesto establecido. Todo esto se va lograr, sólo si, somos capaces de realizar una gestión de requerimientos efectiva.
Podemos remontarnos a estadísticas básicas del éxito de un proyecto y éstas dejan mucho que desear. Son más los proyectos que terminan fuera de tiempo, presupuestos altos y con aprobaciones de clientes, que se sienten obligados a aceptar porque no tienen otro remedio o porque las inversiones ya se realizaron y hay que justificarlas.
¿Cuáles son las causas para que un proyecto fracase?
Pueden ser muchas las razones, sin embargo se ha demostrado que una incorrecta gestión de los requerimientos (procesos que permiten identificar y documentar las necesidades de los interesados a fin de cumplir con los objetivos del proyecto), trae consigo el fracaso del proyecto. Los requerimientos incluyen las necesidades, deseos y expectativas cuantificadas y documentadas del patrocinador, del cliente y de otros interesados.
Los problemas se inician con la forma en que la compañía compromete a sus usuarios a identificar y manejar sus requerimientos. Se han identificado 4 factores determinantes:
1. Debilidad en el proceso de la retroalimentación del usuario.
2. Requerimientos y especificaciones incompletos
3. Cambio de requerimientos y especificaciones.
4. Falta de apoyo ejecutivo
Entre las posibles causas se encuentran:
¨ La definición de los requerimientos de negocios fue simplemente una serie de
enunciados de las habilidades y por tanto, muy vagos para su implementación.
¨ El flujo de los datos, y las reglas de negocios detrás de cada requerimiento
nunca fueron discutidos.
¨ Los formatos usados por la empresa recibieron una atención superficial.
Ninguna metodología, guía y/o propuesta de gestión de Proyectos puede arreglar un proyecto cuyos requerimientos han sido pobremente definidos. Un proyecto en ese contexto terminará bajo el peso de la frustración y antipatía de los usuarios. Y recuerde que arreglar el problema, requerirá obtener 4 veces más información en un cuarto del tiempo disponible.
Un requerimiento debe cumplir ciertos criterios y características:
Único: El requerimiento debe poder ser interpretado inequívocamente de una sola manera.
Verificable: Su implementación debe poder ser comprobada. El test debe dar como resultado CORRECTO o INCORRECTO.
Claro: Los requerimientos no deben contener terminología innecesaria. Deben ser establecidos de forma clara y simple.
Viable (realístico y posible): El requerimiento debe ser factible según las restricciones actuales de tiempo, dinero y recursos disponibles.
Necesario: Un requerimiento no es necesario si ninguno de los interesados necesita el requerimiento o bien si la retirada de dicho requerimiento no tiene ningún efecto
¿Entonces, que hacer para que nuestro proyecto tenga buenos requerimientos?
¿De qué manera se logra obtener los requerimientos correctos de las diferentes
niveles de la organización?
¿De qué manera se logra obtenerlos en un tiempo prudente?
Existen muchas técnicas y herramientas que podemos utilizar, por ejemplo:
Entrevistas, grupos de opinión, talleres facilitadores (JAD – Join Applications Development, QFD – Quality Funcion Deployment, etc.), Técnicas grupales de creatividad (tormenta de ideas, técnicas de grupo nominal, técnica Delphi, mapas conceptuales, diagramas de afinidad), Técnicas grupales de decisión, cuestionarios, encuestas, observaciones, prototipos, casos de uso, análisis FODA, diagramas de causa – efecto, listas de verificación (checklist), etc.
Todos los esfuerzos que hagamos para obtener buenos requerimientos son ampliamente justificados pues nos llevan al éxito, pero no olvidemos, que éstos requerimientos pueden cambiar durante la ejecución del proyecto y que tendrán efectos (en tiempo y costos) mayores, dependiente del grado de avance en el proyecto. La gestión de estos cambios debe aprobar o desaprobar el Comité de Cambios del Proyecto. Tema de otro artículo.

Proyecto exitoso ¿Una dificil tarea?


Por: Luis Alberto Oviedo Tejada
Los directores de proyecto tenemos el deber y obligación de terminar nuestros proyectos a tiempo (cumplir con la entrega final del proyecto), en el presupuesto estipulado y cumpliendo a cabalidad con las características del producto y/o servicio o resultado.
Las organizaciones emprenden continuamente diversos proyectos, como un medio de darle sostenibilidad a sus inversiones y mantener o mejorar su posicionamiento en el mercado. Sin embargo, siguen manteniendo estructuras y tratamientos, quizás eficaces y eficientes para sus operaciones del día a día, pero que generan situaciones y conflictos no habituales con los equipos de proyectos.
En este contexto, donde estas situaciones y conflictos ponen en riesgo el cumplimiento de los objetivos del proyecto, es donde deben aflorar las habilidades de liderazgo del director de proyectos, para remar en medio de esta agua turbulentas para arribar a buen puerto.
Muy independientemente de su particular estilo o metodología de trabajo de gestión, un director de proyecto debe desarrollar las siguientes habilidades y destrezas.
Prevenir. El director de proyectos debe ser capaz de mirar el camino a recorrer en su proyecto y hacer algunas predicciones razonables basadas en supuestos prácticos. Es una destreza que debe desarrollar.
“El hombre cauto jamás deplora el mal presente; emplea el presente en prevenir las aflicciones futuras.” – William Shakespeare
Organizar. Debe mantener la información necesaria, cumplir con los planes de comunicación a todos los interesados. Debe garantizar la actualización de los cronogramas. Debe mantener la unidad e integración del proyecto.
“El hombre no ha sabido organizar un mundo para sí mismo y es un extraño en el mundo que él mismo ha creado” – Alexis Carrel
Liderar: Aunque hay algunas personas que son líderes naturales, las habilidades básicas de liderazgo puede ser aprendido, practicado y mejorado. Debe generar confianza y ser coherente a través del tiempo.
"Si tus acciones inspiran a otros a soñar más, aprender más, hacer más y ser mejores, eres un líder" - Jack Welch
Comunicar. Debe poseer habilidades excepcionales de comunicación. Es importante ser capaz de comunicarse con todos los involucrados en el proyecto y satisfacer sus diversas expectativas. Todos los involucrados en un proyecto necesitan información diferente en términos diferentes. Esta es una habilidad que es vital para el éxito de un jefe de proyecto.
“Para comunicarse con eficacia, debemos darnos cuenta de que todos somos diferentes en la forma en que percibimos el mundo y utilizamos este conocimiento como una guía para nuestra comunicación con los demás” – Tony Robbins
Pragmatismo. Un enfoque pragmático para resolver problemas es una habilidad que es esencial para una disciplina que se enfrenta a las revisiones periódicas y los cambios que se enfrentan los administradores de proyectos.
“Todos los medios son buenos cuando son eficaces.” – Jean Paul Sartre.
Empatía. Con el fin de llevar al éxito a nuestro proyecto y a sus integrantes, usted necesita entenderlos y conocer qué los motiva. Cada persona es diferente y por lo tanto los diversos enfoques del liderazgo diferirán de acuerdo a las características de ellos.
".. caminar o ponerse en los zapatos de otro hombre”.
Como conclusión, el director de proyectos debe saber que entender y comprender a las personas que participan en su proyecto corresponde a la mitad de la batalla ganada en la búsqueda del éxito del proyecto.

Proyectos - Restricciones y Asunciones


Por: Luis Alberto Oviedo Tejada
!Nadie conoce el futuro y éste nos puede dar muchas sorpresas!
Las restricciones son limitaciones que afectan el desempeño del proyecto. Las restricciones más populares son el: presupuesto, alcance y tiempo. Por ejemplo. ¿Alguna vez haz trabajado algún emprendimiento que tenga una fecha límite? ¿Tú proyecto tenia un presupuesto impuesto el cual tenias que cumplir?¿No crees que las características y especificaciones de un producto o servicio limitan el trabajo requerido?
El éxito de un proyecto depende de las habilidades y del conocimiento del gerente del proyecto para tomar en consideración todas estas restricciones y poder desarrollar los planes y los procesos para mantenerlos en balance.
Un cambio en una de estas limitaciones normalmente afecta a las otras dos y puede influir en la calidad global del producto o del servicio o del proyecto mismo. Por ejemplo, reducir la duración del proyecto (programa) puede aumentar el número de trabajadores necesarios (recursos) y reducir el número de funciones que se pueden incluir en el producto (ámbito). El gerente de proyecto debe determinar si este equilibrio es aceptable.

Una asunción o suposición es una circunstancia o evento fuera del proyecto que pueden afectar a su éxito y que el equipo de proyecto cree que va a suceder, pero que están fuera de su control total. Es necesario que su identificación se realice durante la planificación, pues en ese momento muchas preguntas rondarán sin respuestas precisas. Por ejemplo. ¿Los recursos solicitados estarán en la fecha solicitada?¿las estimaciones de las tareas a realizar y sus duraciones se basan en información sólida o en conjeturas?¿Habrá modificaciones en el precio de los materiales requeridos? ¿Los proveedores entregarán los productos solicitados en el plazo establecido?.
¿Qué pasa si las suposiciones son falsas?

Pues dependiente de la importancia de la suposición ante el proyecto su impacto puede ser muy diferente para el proyecto. En todo caso, las suposiciones con fuerte impacto deberíamos tratarlos como fuentes de riesgos.

En conclusión, ambos restricciones y suposiciones (asunciones) importantes deben ser supervisadas a lo largo de la vida del proyecto