Artículos

AON 2012: "Negocio y Clientes (Llevando Agile fuera de la empresa)"

publicado a la‎(s)‎ 3 abr. 2012 3:13 por Raúl Sanz de Acedo

CEIN organiza en colaboración con la Zona Norte de Agile Spain un Open Space: "Negocio y Clientes (Llevando Agile fuera de la empresa)": http://respuestadigital.es/2012/03/15/aon2012-agile-open-navarra-negocio-y-clientes/

Gestión Por Proyectos - Artículo de prensa

publicado a la‎(s)‎ 5 dic. 2011 1:40 por angp angp   [ actualizado el 5 dic. 2011 1:43 ]

Con el fin de difundir la Gestión Por Proyectos en Navarra la asociación ha preparado un artículo divulgativo que ha remitido a los dos principales diarios de la región. 

El pasado 4 de diciembre se publicó en el Diario de Navarra, en el apartado Tribuna de la sección Dinero y Empleo, un artículo titulado "Gestión Por Proyectos" firmado por nuestro Presidente, D. Carlos Monreal.

Escalado de Scrum y Scrum distribuido

publicado a la‎(s)‎ 9 sept. 2011 4:33 por Iñaki Agirre

CEIN celebra la jornada gratuita sobre metodologías ágiles de gestión de proyectos, "Escalado de Scrum y Scrum distribuido"

Pon un Project Manager Profesional en tu Empresa y…

publicado a la‎(s)‎ 23 nov. 2010 0:12 por angp angp   [ actualizado el 23 nov. 2010 0:14 ]

9. Y realizará estas tareas para no dejarse nada ni nadie clave ya en el minuto 1 de partido (3)

Daniel Echeverría Jadraque


 
c.  seguimos con las partes interesadas (pero es que son MUY importantes)

Y todo ello antes de que empiece el proyecto ya que, cuanto más tarde se identifiquen, más problemas y más gordos.  
Si tu gente se deja una parte interesada en el proyecto sin identificar (o la ha identificado pero no ha captado bien sus expectativas, sus requisitos,…) y aparece a mitad de la ejecución preguntando cándidamente “¿Pero porqué no habéis incorporado… …si es fundamental para que luego en la fase de operación podamos…? … es que hay que cambiarlo o no valdrá para nada…”.
En ese momento se acordará del malhadado día en que por empezar a “trabajar” pensaste que los temas de mantenimiento te los conocías razonablemente bien y no operaciones. A los PMP también les pasa, pero menos, porque tienen sus plantillas y listados de partes interesadas que guardan de proyectos anteriores y que van enriqueciendo con estas omisiones (errores se llama a lo que les pasa a otros)  para repasar que no se deja a nadie.
Como los Reyes Magos viven en casa y el presupuesto no llega para todos, de la revisión de las necesidades, requerimientos, sugerencias, expectativas,… de las partes interesadas se deberá seleccionar las prioritarias.
Y cómo las priorizamos?. La tríada Tiempo-Coste-Plazo no permite juegos de magia.
Pues, como dirá tu PMP ( o mi hija), ¡Chupadico!
Evaluando el potencial impacto que su apoyo o rechazo puede tener en el desarrollo exitoso del proyecto:
·          Quien nos la puede liar parda y quien puede simplemente molestar.
·          Quien manda y quien manda menos o nada –pero nos la puede jugar…-.
Sería grave para un project manager atender las solicitudes de un interesado con poca influencia y autoridad y que cuando aparezca el realmente importante, se deba rehacer trabajos ya avanzados con el siguiente coste, retraso y conflictos.
Tu PMP te presentará:
·          una lista con todas las partes interesadas (en ella estarás tú y estará él, y estarán personas que ni si te hubiera ocurrido que convenía ver “qué pensaban”).
·          una estrategia individualizada para los interesados como más relevantes. Será un documento que indique cómo gestionar a todos estos individuos o grupos –en este caso, al agruparlos, pudiendo mejorar la eficiencia en los recursos y dedicarles menos tiempo- para que, de forma proactiva, el project manager vaya analizando posibles problemas o conflictos durante la ejecución.
Además, estos PMP valen para todo¡ sabe que, además de potenciales riesgos, las partes interesadas son activos importantes para el proyecto, y buscarán su apoyo cuando sea necesario.
A los que no se pueda hacer caso, ….
·          se les informará –aquí se ve la asertividad de un buen comunicador, cuando hay que decir que no- de aquellos requerimientos que no han sido atendidos y las razones del rechazo de tal manera que tengan claro que se ha estudiado su propuesta pero, dentro del resultado final, no estará ese requisito solicitado.
·          eso sí, dando por seguro que lo intentarán… más tarde… en otro momento… cuando estemos despistados… cuando en el barullo de la ejecución bajemos la guardia…
Menos mal que el PMP les enseñará el acta de constitución, la lista de requerimientos aprobados que guardará lista y actualizada y les dirá “¡pues va a ser que no¡”O dicho más fino, “¡No, porque no está ni en el Acta de Constitución ni en el Enunciado del Alcance del Proyecto y además aquí puedes ver cómo en la lista de requerimientos se decidió no hacerlo por esta y esa razón!” Y se callará…. hasta la siguiente….

Gestión del riesgo en PYMES

publicado a la‎(s)‎ 24 oct. 2010 22:26 por Iñaki Agirre   [ actualizado el 8 nov. 2010 3:48 ]

(eu) Dentro del mundo de las tecnologías de la información, está totalmente aceptado que los esfuerzos por implantar una metodología de seguridad deben partir de los estándares nacionales o internacionales disponibles. En el campo industrial, y específicamente en la gestión de proyectos, poco se ha escrito sobre la gestión de riesgos en PYMES no orientadas a proyectos. Un reciente trabajo de S. Marcelino Sádaba y A. Pérez Ezcurdia, de la UPNA, viene a rellenar este vacío, ligando los modelos internacionales con su aplicación práctica en el entorno regional. El artículo comienza citando el Chaos Report 2009, donde se encuentra que sólo el 32% de los proyectos alcanzan los objetivos planteados en plazo y presupuesto, para después repasar los modelos de gestión de riesgos más internacionalmente adoptados. En núcleo del artículo lo constituye el estudio de ocho casos de proyectos internos abordados por PYMES en Navarra. Tras discutir con los participantes los problemas fundamentales detectados en la gestión de riesgos, se define una serie de herramientas para cada fase de dicha gestión que pueden adecuarse a las necesidades propias de las PYMES. Como extensión de este trabajo, las escritoras están trabajando en el diseño de guías específicas de gestión de riesgos en pequeños proyectos, en función del tipo de proyecto. En resumen, este artículo supone una aportación bien planteada a un campo menos estudiado que otros, y que todo jefe de proyectos en una PYME debería leer y considerar.

  • Gestión del riesgo en proyectos abordados por PYMES / Sara Marcelino Sádaba; Amaya Pérez Ezcurdia. Dyna 85, no. 6 (2010): 504-512

Cómo ser Project Manager y no morir en el intento (VI)

publicado a la‎(s)‎ 12 oct. 2010 5:14 por angp angp

Daniel Echeverría Jadraque <decheverriajadraque@acciona.es>


Sexta Parte: Dónde aprenderemos a gestionar las expectativas de los interesados y también las alucinaciones de algunos de ellos, aprenderemos algo de los viejos comerciales, daremos una definición de infelicidad pero nos mostraremos incapaces de hacerlo con la felicidad, veremos cómo Julio Iglesias podía haber sido un gurú del Project Management, y animaremos a no cometer los mismos errores una y otra vez sino nuevos y más apasionantes errores.


11. Entonces. ¿No era esto lo que esperaba?

Decía Henry Ford, el de los coches, que “no puedes labrarte una reputación con lo que dices que vas a hacer”. Algo parecido a lo que quizás le pase a Barak, el de la Whitehouse, que generó tantas expectativas que lo mejor que podrá pasarle es que las cumpa todas, algo que, como es imposible incluso para él, ya ha empezado a generar decepciones.

Dejando a los Yankees de momento, cierto es que uno de los caminos que llevan al fracaso de un proyecto es el no ser capaces de gestionar las expectativas de la cantidad de gente que juzgará el éxito de nuestro proyecto. Y eso aunque lo hagamos según alcance, en tiempo y en plazo. Curiosamente, puedes fallar en uno o en los tres aspectos y que tu proyecto sea considerado un gran éxito. Puedes entregar un proyecto en tiempo y plazo, tal como lo quería el cliente y que el éxito no sea tal…

Alrededor de un proyecto hay un montón de gente interesada, directa o indirectamente afectada, personas que esperan ansiosamente (demasiado) los resultados del proyecto, personas que se oponen al mismo, personas que temen sus resultados, personas que nos deberán dar información, personas a las que deberemos mantener informadas,…

Identificar desde el inicio cuáles son las personas y grupos interesados en el proyecto, es un aspecto clave que, cuando se omite, puede crear problemas en fases posteriores. Debemos identificar quien va a utilizar los resultados de nuestro proyecto y, sobre todo, sus expectativas específicas, sus necesidades y sus intereses. La gestión de expectativas de las partes interesadas, sobre todo clientes o usuarios del producto, aparece como un elemento clave. No solamente debemos cumplir sus necesidades sino también, y esto requiere más arte, sus expectativas.

Un comercial bregado en mil batallas te dirá que el secreto para tener contento al cliente es ofrecerle menos y darle más. Pero cuando, como ocurre a veces, ni tú sabes lo que quiere el cliente ni el cliente sabe lo que él mismo quiere, seguir este sabio consejo resulta complicado.

En cualquier caso, conviene evitar sorpresas de última hora por no haber mantenido informado, consultado a alguno de los posibles interesados y haber satisfecho sus legítimos intereses. La habilidad para identificar las partes interesadas de un proyecto y para conocer y gestionar sus expectativas puede tener más que ver con el éxito del proyecto que cumplir con el mágico triángulo de las Bermudas (tiempo, coste, alcance).

La infelicidad es el espacio que queda entre lo que espero y lo que obtengo. La felicidad es más difícil de definir. Esta relatividad hubiera emocionado (seguro que ya la pensó) al mismo Einstein.

Efectivamente nuestras expectativas influyen en la percepción de nuestras experiencias. La frustración o la felicidad tienen más que ver con la diferencia entre lo que estaba esperando y lo que realmente ocurri, que con la resultado objetivo en sí. Teniendo en cuenta esto, la diferencia entre lo que el cliente, jefe, esposa (o sea: jefe),… espera y lo que le ofrecemos determinará el grado de felicidad o enfado más que lo que realmente hagamos. Por ello es tan importante que los Project managers establezcan y gestionen las expectativas de todos los interesados en el proyecto desde el inicio hasta la fiesta de celebración del final del proyecto.

La clave para satisfacer a un cliente, jefe, será por tanto… (redoble de tambores) darles algo más de lo que esperaban, un poquito antes de lo previsto y con un toque de calidad no prometido. Si prometes el sol y únicamente entregas la luna, no lograrás impresionar a nadie.

Algunas expectativas son fácilmente medibles (cumplimiento de coste, plazo y alcance), otras no tanto y tienen que ver con la frecuencia y el tono de la comunicación, el formato de los informes de avance, y otras cosas aparentemente, solo aparentemente, secundarias. Todos sabemos lo sensibles que somos a sentirnos ninguneados, a que se olviden de nosotros, a que nos enteremos por otro de las cosas,…

Una conversación inicial con los interesados al inicio del proyecto es una buena manera de empezar a conocer las expectativas de cada uno: preguntándoles que consideran ellos que será un éxito cuando acabemos el proyecto y cómo lo van a medir, preguntándoles en qué rol (le he cogido manía a esta palabra…) se ven ellos en el proyecto, en qué parte les gustaría participar, explicándoles cuál es tu papel, qué necesitarás de ellos y cómo les vas a mantener informados.

No estará de más advertirles que durante el proyecto puede haber malentendidos, errores, despistes, pero que confíen en tu gestión y con toda confianza te llamen en cuanto vean algo que no es lo que esperaban de ti.

En cualquier caso, incluso aunque hayas hecho un trabajo fantástico estableciendo con el cliente objetivos claros, específicos y bien definidos que el cliente ha aceptado con gran entusiasmo, puedes pensar que esto es ya coser y cantar. Pero no. No te relajes, amigo Project manager, lo tuyo es mantener la tensión. Cuando hablamos de clientes, no hay requerimiento, especificación o acuerdo que no pueda ser malinterpretado. Es por ello, que la gestión de las expectativas del cliente es un trabajo que se prolonga durante toda la vida del proyecto.

Una pequeña checklist nos ayudará a tratar de definir bien las expectativas ante nuestros clientes e interesados: qué es nuestro proyecto, qué no es, cómo definiremos el éxito del proyecto, cómo lo mediremos, quién trabajará en él, cuáles son los factores críticos del proyecto para nuestros interesados, qué estamos asumiendo (y si no se cumple, aparecerá un riesgo) con nuestros interesados, a qué le dan más importancia (al plazo, el alcance, el presupuesto, la calidad, la innovación o la generación de nuevas ideas), el presupuesto aproximado del que estamos hablando, los entregables y fechas aproximadas que se esperan,… casi nada.

Pero si esto no está claro al principio y no estamos atentos que el cliente y resto de interesados lo mantiene durante la vida del proyecto, tendremos algún problema.

Cómo ser Project Manager y no morir en el intento (V)

publicado a la‎(s)‎ 12 oct. 2010 5:11 por angp angp

Daniel Echeverría Jadraque <decheverriajadraque@acciona.es>

9. ¿Que ha cambiado? ¿Qué quieres decir con que el proyecto ha cambiado?.

Times they are a’changing…” Bob Dylan.

Ya nos lo avisó Charles Darwin que no son las especies más fuertes las que sobreviven, ni siquiera las más inteligentes, sino las que tienen mayor capacidad de adaptación al cambio. O nos lo recordó el conocido anuncio de BMW con Bruce Lee diciendo aquello de “Be water my friend”.

¿Conocéis a alguien que haya trabajado alguna vez en un proyecto que sus premisas, objetivos, responsables,… no hayan cambiado durante el proyecto? Entonces, ¿Por qué seguimos sorprendiéndonos, enfadándonos y frustrándonos cuando algo cambia en el proyecto? Desde hace unos años se ha venido aplicando en Estados Unidos y está llegando ahora a nuestro país una nueva corriente de gestión de proyectos llamada Scrum (o Agile) Project Management que nos da algunas herramientas para no sufrir tanto y trabajar en un entorno de cambio. Pero esta es otra historia…

¿Conocéis a alguien que haya tenido un cliente que sabía lo que quería desde el primer momento? Entonces por qué nos quemamos cuando cambia de opinión? Los planning se retrasan, es así. Los directores prometen recursos humanos suficientes pero buena parte de ellos están todavía tratando de cerrar los marrones y flecos del anterior.

El cambio es tan inevitable como la meteorología (de momento) y el pago de impuestos (para aquellos que estamos atados a una nómina). Hay quien divide las clases de cambios en el proyecto en 3 tipos: inevitables (estaba claro desde el inicio; solamente nuestro deseo de que no ocurriera nos impedía verlo); desafortunados (miramos por el rabillo del ojo, cruzamos los dedos pero… ahí está) y completamente sorpresivos (nadie hubiera podido preverlo, ni un mago que nos hubiera leído el futuro).

Después de la broma de la clasificación, prácticamente todos los riesgos son predecibles (otra cosa es que sean evitables). Así que cuando lleguen, como ocurría con los riesgos, mírales a los ojos y haz algo ¡ya!. Nuestro Project manager, además de todo lo que ya hemos visto que debe tener, además tiene que tener cintura, mucha cintura para ir acogiendo los cambios e integrándolos en el avance de su proyecto.

Una cosa es que los cambios son inevitables pero otra cosa muy distinta es que no podamos tener una idea de alguna de las cosas que pueden pasar y que pueden cambiar mi proyecto: los clientes (o jefes) cambiarán de opinión; los recursos humanos se reasignarán a otros proyectos, los mercados, el entorno económico cambiará (en fin, qué nos van a contar ahora); los miembros del equipo se ponen enfermos, tienen la manía de cogerse vacaciones, si se enfadan o encuentran algo mejor dejan la empresa,…; las prioridades pueden cambiar, y volver a cambiar y a cambiar otra vez; los intereses y estrategias con los socios pueden revisarse; los presupuestos pueden recortarse (¡no me lo creo!); los proveedores y suministradores pueden retrasarse o enviar componentes que no cumplan las especificaciones; las programaciones se retrasan, retrasan,… Por 1 euro, dígame más cosas que pueden cambiar en un proyecto (seguramente lleguemos a 100), Un, Dos, Tres, responda otra vez (a lo mejor los que tengan menos de 30 años no entiendan esto…).

Así que no tenemos excusa, ¡sabemos qué es lo que puede cambiar! ahora nos toca ver la manera de anticiparnos al cambio y reducir la probabilidad de que ocurran (salvo que sean para bien). De todas formas está en la naturaleza humana temer o estar incómodo con los cambios (si quieres tener enemigos, intenta cambiar algo). Aunque, en un ejercicio de pensamiento positivo podemos hasta pensar “¿qué ventajas y oportunidades podrá traer consigo este maldito cambio que ha echado al traste el trabajo de toda una semana?”, por ejemplo.

Y una vez que nos ha quedado claro que el cambio es nuestro amigo invisible que nos dará sorpresas durante nuestro proyecto, veamos algunas ideas para gestionarlos:

Mantén los ojos bien abiertos (qué obviedad no?) y por si acaso haz una lista de los cambios que pueden tener más impacto en tu proyecto y trata de tener previsto tu plan B;

Sígueles la pista: mantén una lista de cambios que van ocurriendo, para al final del proyecto, por una parte aprender para la próxima y, por otra, reírte de lo mal que lo pasaste cuando ocurrió;

Estima el impacto: cuantifica las consecuencias del cambio sobre el proyecto. Para ello ayúdate del equipo siguiendo un protocolo que te ayude a que se tomen decisiones correctas (o al menos de forma sistemática y con los datos y opiniones más fundadas), habiendo realizado un análisis completo antes de tomar una determinación sobre si realiza o no el cambio y habiendo sido informadas las personas que necesitan saberlo:

  • Al recibir una solicitud de cambio en algún aspecto del proyecto (alcance) conviene que el Project manager clarifique qué es exactamente lo que le proponen (haciendo un proceso reducido de la elaboración del documento de requisitos del proyecto) y que quien lo pide y el receptor entienden lo mismo.

Una buena manera de asegurarse esto, es pedir al solicitante que lo envíe por escrito o que sea el Project manager quien por escrito comunique al solicitante lo que ha entendido.

  • Una vez clarificado, el Project manager debe evaluar el efecto potencial del cambio sobre los diferentes aspectos del proyecto por lo que deberá informar del posible cambio a las personas y equipos participantes e interesados para que, desde su punto de vista, valoren las implicaciones del cambio.

  • Recogidas las respuestas de los implicados, el Project manager decide si poner en marcha el cambio y si no lo aplica, comunicárselo al solicitante con las razones de su negativa.

  • Si se decide implementar el Project manager debe elaborar un pequeño plan de implantación del cambio: los pasos a dar, las personas a implicar,… y, si procede, integrarlo en el planning y en la estructura desglosada de tareas (EDT), en el presupuesto,…

  • Y, por último, informar a los interesados del cambio, de pasos a dar,…

Y no pasa nada, a seguir trabajando hasta que otro librepensador ligado al proyecto se levante imaginativo y proponga otro cambio.

10. El peligro de suponer cosas, asumir situaciones, autoimponerse limitaciones,…

¿Por qué asignas a esta recién llegada el despacho libre cuando yo llevo aquí ya cinco años, Don?”. “Bueno, es la única que me lo ha pedido”. Serie Mad Man, temporada 2.

Ya lo hemos comentado anteriormente. La suposición es la madre de todos los desastres en un proyecto. Darlo todo por hecho, no preguntar (a ver si se va a ofender…). Cuando se pregunta a un project manager cuál es su principal problema, suele quejarse de que no tiene presupuesto ni tiempo para hacer bien el proyecto. Que, por otra parte, parece ser lo que suele ocurrir. Pero, cuando se le pregunta a continuación, ¿Y qué te dijo el Director cuando le pediste un aumento de plazo y de presupuesto?, la respuesta suele ser… No se lo he preguntado. Suponía que me lo iba a denegar.

Una de las primeras cosas que se enseña a los futuros ejecutivos que se precien es a decir que no al menos a la primera y segunda solicitud, muy especialmente cuando procede de alguien que pide ayuda desesperadamente sin ningún tipo de justificación, razonamiento o documentación. Pero si lo intentas una tercera vez, lo haces de forma razonada y con datos y no tienes la mala suerte de que se haya hartado de ti y te despida, lo conseguirás. En cualquier caso, estás condenado al fracaso.

Seamos serios, cuántas veces hemos ido o nos han venido pidiendo más recursos sin nada más que un “es que si no, no llegamos”. Si no vemos mal que un Project manager pida sin datos, ¿porqué vamos a juzgar a un director que rechace sin más contemplaciones? Un Project manager de lujo es aquel que consigue aumento de personal cuando no se contrata a nadie, presupuesto adicional cuando no lo hay,…

El dicho popular de “quien no llora, no mama” es aplicable al Project manager siempre que mientras enternece al llorar, convence al desgranar una buena argumentación, con datos, indicadores, ventajas, inconvenientes,… si no, su director le dará un pañuelo y el finiquito.

Hay algunos principios de sentido común que a mí casi siempre se me olvida aplicar como los siguientes:

Trata de entender los objetivos de la persona a la que estás tratando de pedir algo. Aunque el Director no quiera ayudarte existe al menos una remota posibilidad de que quiera ayudarse a sí mismo. Si somos capaces de convencerle que echándonos una mano le va a venir bien a él, se volverá algo más proclive (no necesariamente entusiasta) a considerar tu propuesta.

Prepárate bien la argumentación, la documentación, lleva algo más sólido que un “créeme, soy el Project manager y sé lo que necesito”. Detalla cómo va el proyecto, las hipótesis de base, los cambios que se han producido, cuáles serán los resultados en caso de conseguir o no el apoyo, demuéstrale que has estudiado todas las alternativas posibles,…

Si la cosa va regular, pregúntale qué haría posible que te dieran lo que pides. A veces no estamos hablando con la persona correcta, quien puede decidir. Y la respuesta puede ser, yo no puedo conseguírtelo, vete a ver a… y entonces, llamaremos al nuevo interlocutor y empezaremos desde el principio.

No olvidar que no es él quien tiene que entender la importancia de tu necesidad, si no que eres tú quien debe hacérselo ver, ver que está perfectamente alineado con los objetivos de la compañía (y no olvidarlo, con sus intereses particulares). Y, no pasa nada si notas resistencia. Como ocurre con un barco, si no la notas, es que estás parado, es que no avanzas.

Una de las mayores plagas en el mundo profesional, y en el de los project managers en particular, es el “pesimismo preventivo”, que consiste en asumir de entrada que algo es imposible (nunca me acuerdo dónde leí aquello que me gusta tanto de “lo hicieron porque no sabían que era imposible”). Esto se puede observar a cualquier nivel: en el cliente, tu director, tus proveedores, los miembros de otros equipos,… El pesimismo ajeno es una buena prueba para reconocer al auténtico Project manager, quien, inasequible al desaliento, razonablemente optimista no se dejará contagiar.

Hay muchas causas detrás de la tendencia a asumir que algo es imposible. Algunas son inocentes, otras perversas. Puede llegar a ser conveniente que algo sea imposible…. Porque así, no hay que hacer el esfuerzo de intentarlo. Decir que algo es imposible, reduce las expectativas ajenas, las cargas de trabajo y, sobre todo, el riesgo de fracaso. Y a veces, simplemente no nos apetece hacerlo.

A veces parece que asumir que algo es imposible significa simplemente que no se me ocurre cómo hacerlo inmediatamente. Y pensar, acordémonos, nos gusta menos que trabajar, trabajar, trabajar. Como humanos, cuando menos sabemos, más seguros estamos y, como Project managers, ávidos de saber y de crecer, debemos ser capaces de que nos dejen, al menos, intentarlo.

Ser negativo está muy bien en la fase de identificación y análisis de riesgos. En esos momentos nos debemos poner el gorro de pesimista. E incluso un cierto pesimismo es garantía de prudencia y de sensatez ante una evaluación de un nuevo reto porque necesitamos tomar decisiones valientes, no suicidas. Pero tampoco podemos hacer como hacen los calculistas, minorar por tres nuestras capacidades y multiplicar por dos con cinco las dificultades y riesgos.

Nadie puede darnos aquello que nosotros mismos nos negamos. No te das lástima, no te lo mereces¡ Busca un libro de autoayuda del tipo “cómo salir del agujero yo solito” y trata de practicar. Poco a poco serás capaz de abordar otros problemas mayores y, como la Reina de Corazones de Alicia en el País de las Maravillas, haz cada semana una lista de las seis cosas que perecen imposibles pero que, de resolverse, harían mejorar notablemente nuestro proyecto o nuestro trabajo y, una vez hecha, mira a ver cuál eres capaz de tratar de abordar tú o busca quién puede dártelo. El No lo llevas puesto. Pero si no preguntas…

Cuentan que a un elefante al nacer le ataron con una cuerda a una estaca. Creció atado a esa estaca. Ya de mayor, se le ocurrió a su cuidador soltar la estaca. El elefante no se movió, porque asumía que no podía moverse”.

Cómo ser Project Manager y no morir en el intento (IV)

publicado a la‎(s)‎ 12 oct. 2010 5:09 por angp angp   [ actualizado el 12 oct. 2010 5:11 ]

Daniel Echeverría Jadraque <decheverriajadraque@acciona.es>

Cuarta Parte: donde vemos que ante un riesgo podemos hacer el avestruz o jugar al suicida, donde vemos que lo más sensato es afrontarlo y cómo podemos hacerlo, aprenderemos la diferencia entre un buen y un gran Project manager, veremos si es más importante los pulmones o los riñones y buscaremos la manera de que nuestro jefe nos priorice las cosas (no garantizamos el éxito…).


7. Riesgos? Qué puede ir mal? .

Ni Dios mismo seria capaz de hundirlo” E.J.Smith, Capitán del Titanic.

Ante un posible riesgo podemos actuar de cuatro maneras: haciendo el avestruz (meter la cabeza bajo tierra para no verlo o ignorar que existe), rezando (para que no ocurra y si ocurre que el todopoderoso sea magnánimo), jugando al suicida (reconocer los riesgos, saber que van a ocurrir y decidir dedicarse a otras cosas más urgentes) y, por último, mirando a los ojos a los riesgos, identificando los más importantes y, siguiendo el proverbio chino de que “cuando tengas que comerte tres sapos grandes y horribles, empieza con el más grande y horrible”, poniéndote a trabajar para que los más graves no lleguen y si llegan no nos haga mucho daño.

Sin embargo, no esta última no se práctica. Aunque parezca mentira, el error más frecuente que un equipo de proyecto comete en relación a la gestión de riesgos es identificar los riesgos pero no hacer luego nada al respecto (tipo suicida?). Es curioso como mucha gente contribuye de forma entusiasta a elaborar la larga lista de riesgos que pueden llevar el proyecto al desastre pero luego no dedica la más mínima atención a vigilarlos y mitigarlos. El documento de riesgos, se guarda bien encuadernado y únicamente se utiliza al final como checklist para documentar las razones del fracaso del proyecto.

Ahora que no nos oye ninguno, normalmente los directores no suelen tener imaginación para imaginar posibles desastres. Cuando les presentas la lista de posibles riesgos, responden “¿Pero qué es lo que puede ir mal? Sabemos a lo que nos dedicamos¡ No podemos prever todo¡¡”. Sirve de poco consuelo ver al final del proyecto que los tres temas que hicieron descarrilar el proyecto estaban en los primeros puestos de la lista presentada.

Pero, nuestro Project manager no es así. Ni juega al avestruz, ni es milagrero ni tiene ganas de suicidarse. Mira a los ojos al sapo más grande y horrible y se lo va cocinando…:

Primero y a la luz de los objetivos del proyecto y las tareas a realizar, identifica los riesgos de cada tarea y determina los efectos en nuestro proyecto (si nos afectará al alcance o producto, al plazo o al coste). Para cada tarea analiza la causa raíz (porqué ocurre), se identifica el riesgo (en qué aspecto del proyecto nos va a afectar) y se describen sus consecuencias (se cuantifica) sobre el proyecto.

En segundo lugar, prioriza los riesgos (no tenemos ni tiempo, ni dinero, ni tiene sentido abordar todos). Para ello, los evalúa en función de la probabilidad de que ocurran y del impacto (el lío que nos puede montar). Hace un análisis cuantitativo y cualitativo de cada riesgo (cuadro probabilidad-impacto).

Y se queda con los más probables e impactantes y aquellos que aunque no sean muy probables, no pueden ocurrir de ninguna manera. Puede ocurrir que un riesgo tenga una probabilidad mínima pero considerar inaceptable que ocurra. En este caso, se decidirá gestionar el riesgo.

En tercer lugar, nuestro prudente Project manager (a que empezamos a ver al Project manager como el yerno/nuera que toda madre/padre querría para su hijo/a?) elaborará el Plan de Contingencias con las medidas a tomar si aparecen signos de que el riesgo amenace (semáforo naranja) con acercarse.

Las actuaciones podrán ir en la línea de: aceptar el riesgo y prepararnos para afrontar las consecuencias del impacto; evitarlos actuando sobre la causa raíz; mitigarlo reduciendo la probabilidad y/o el impacto a niveles aceptables; transferir la responsabilidad a un tercero (suena a dejarle el marrón a otro pero tiene sentido si, por ejemplo, no queremos arriesgarnos a desarrollar una tecnología propia que otro tiene ya lista) y, por última, pero no por ello menos importante, contratar un seguro de riesgos.

Todo lo anterior lo hacen los grandes Project managers. Pero los Project managers galácticos, además, están atentos a los “riesgos positivos”, bueno, llamémosles oportunidades. En el fragor de la batalla, lo último que se nos ocurre a los participantes es que haya cosas que puedan ir mejor de lo esperado. Pero esto es algo que los mejores equipos hacen cuando estudian los riesgos: estudiar las oportunidades. Preguntarse ¿qué puede ir mejor de lo esperado? ¿Cómo podemos aprovecharnos de que ocurra? Tengamos en cuenta lo que personas de éxito ya aprendieron: cuanto más trabajas, más suerte tienes (que Picasso decía tal que así: “a mí la inspiración me suele pillar trabajando”).

En estos casos, también tenemos un plan para aprovechar las oportunidades. Ante una oportunidad podemos actuar: aceptándola y preparándonos para afrontar y maximizar las ventajas de la oportunidad; tratar de incrementar la probabilidad de que ocurran y de que el impacto (positivo en este caso) sea máximo; explotándola, asegurando que la oportunidad se materializa y, por último, compartiéndola, asignando la responsabilidad a un tercero que pueda aprovecharla mejor.

8. Qué prioridad tiene este proyecto? Prioridad máxima¡¡¡ (…o sea como los demás…)

Todos odiamos elegir entre cosas que parecen igualmente vitales. ¿Cómo priorizarías entre mantener los siguientes órganos: corazón, riñones, pulmones, bazo, cerebro,…? Alguna decisión habrá que tomar…

Pero si todo es urgente, nada lo es. Si todo tiene prioridad máxima, nada la tiene. Así de claro. Y además tenemos que tener claro que la triple restricción tiempo-coste-plazo nos impide que si tenemos que hacer algo en la mitad de tiempo el alcance y la calidad se queden igual. Antes se diferenciaba entre lo que debía estar incluido (must-have) y lo que querían (need-to-have) que estuviera incluido. Ahora hay que incluir todo¡

Al final cuando te dicen “esto es urgente”, lo tomas con calma y piensas en el cuento de Pedro y el Lobo y valoras si hacerlo aunque no esté el lobo, o no hacerlo tan rápido y que, entonces sí, esté. Lo más grave de que no haya prioridades claras es que al final cada uno de nosotros tomamos nuestras propias decisiones sobre lo que es y no es prioritario, asumiendo qué creemos que realmente lo es.

Si bien no conozco este caso (para que no haya suspicacias) me han contado que los directores de algunas empresas tienen poco que hacer una vez sino están constantemente reasignando recursos, moviendo gente de un proyecto a otro para que parezca que su departamento está en continua ebullición productora, en continuo movimiento (E. Hemingway advertía: no confundamos acción con movimiento), abordando fuegos urgentes, resolviendo desacuerdos sobre qué fuego apagar a continuación, dejando que alguna pequeña chispa pase a ser una llamarada.

Y hay razones para que insistamos en que nos dejen claras las prioridades: las usaremos para decidir entre el proyecto 2 y el 3, sin tener que preguntar e incordiar al ocupado director; nos ayudarán a dirigir nuestras elecciones de asignación de recursos y tiempo; deberán revisarse, reestablecerse y comunicarse periódicamente para que no parezca que no están actualizadas; deberán estar accesibles a los miembros del equipo (alguno propone tenerla como salvapantallas…no me parece mala idea… mejor ver al abriri el ordenador que al señor este que se desintegra y reacciona en el anuncio de una conocida gran empresa).

Y ¿qué hacer si no te dan las prioridades? Pregunta, insiste, ruega,… y si todo falla, establécelas tu mismo, publícalas y dalas a conocer a todos los interesados. En ese momento, al menos, podrás saber si las elegiste bien.

¿Por qué no establecemos prioridades? Creo que es porque no sabemos cómo usarlas debidamente y tememos que podemos equivocarnos. Pero una lista de prioridades realmente incrementa la cantidad y calidad del trabajo hecho, llegando a doblar la productividad, reduciendo las pérdidas de tiempo y concentración de ir saltando de un proyecto a otro.

Además, creámoslo: si cogemos le hábito de establecer prioridades, luego no podremos vivir sin ellas¡ bueno, tanto como no poder vivir sin ellas…

Cómo ser Project Manager y no morir en el intento (III continuación)

publicado a la‎(s)‎ 12 oct. 2010 5:06 por angp angp

Daniel Echeverría Jadraque <decheverriajadraque@acciona.es>


6. Planificar? Para qué? No podemos perder el tiempo, manos a la obra¡¡

La Ley de Golub dice que un proyecto mal planificado acaba en un plazo tres veces superior al previsto, y que un proyecto bien planificado acaba en un plazo dos veces superior al previsto….

O sea que planificar parece en principio útil. Pues sí. Y de esto tratará este punto: de la necesidad de crear planificación y programaciones viables que disfruten del favor y compromiso de quien trabaja con nosotros.

El sentido común dice que cuando trabajas en un proyecto con objetivos importantes, los equipos deben acordar cómo alcanzar esos objetivos, pensar conjuntamente qué puede ir mal y asegurarse de que todo aquel que tiene que colaborar en alguna tarea sabe cuál es y está comprometido para lograrlo. Pero, el sentido común, en ocasiones (por algo dicen que es el menor común de los sentidos) no coincide con la práctica habitual.

Si nos dan la opción preferiremos planificar lo justo o nada para ponernos hacer lo que verdaderamente nos gusta: trabajar. Buena parte de las malas experiencias en la ejecución de los proyectos tienen su origen en una mala planificación en las fases iniciales. Y ello porque buena parte de los proyectos tienen fechas de entrega muy ajustadas y la planificación se debe hacer rápidamente para poder lograr esos plazos alocados.

Nunca tenemos por tanto tiempo para planificar, siempre hay algo mejor que hacer. Qué? Trabajar¡¡¡¡. Cuando tu correo electrónico y tu teléfono queman, lo último que se nos ocurre es pensar en tonterías como saber cuál es el verdadero objetivo del proyecto, que es lo que realmente quiere el cliente, reducir al mínimo el número de asunciones, establecer hitos, responsables,…

Un sabio que paseaba por el bosque observó como un afanoso y trabajador leñador se rompía los huesos tratando de cortar más y más leña con un hacha roma, sin afilar. Cuando el sabio le preguntó porqué no afilaba el hacha ya que así cortaría más leña y con menos esfuerzo, el leñador airadamente le contestó: ¡no se da usted cuenta que no tengo tiempo¡ Planificar es afilar el hacha, prepararnos para hacer el trabajo mejor y más rápido dedicándonos un tiempo a prepararnos.

La primera tentación de nuestro Project manager, trabajador infatigable, es empezar a trabajar en el proyecto antes de que los objetivos estén claros. y no le falta razón, planificando no construyes caminos, no produces informes,… y por el contrario, estás más bien un tanto distraído, pensativo (algo muy mal visto en un ambiente de grandes y sufridos trabajadores). Planificar no se ve como un trabajo real, un trabajo serio.

Nos gusta la acción. Corrijo, nos gusta el movimiento porque como decía E. Hemingway, no debemos confundir la acción con el movimiento. Podemos trabajar días y días (en el mejor de los casos) sin darnos cuenta de lo que estamos haciendo no va a contribuir en absoluto al éxito de nuestro proyecto. Pero es que es tan apasionante sentirte ocupado, muy ocupado, corriendo con el móvil de un lado a otro, apagando todo fuego que ose aparecer en tu camino de bombero infatigable y entregado a la empresa¡

Y, entonces ¿qué hacemos? Convencer, evangelizar, seducir,… lo que sea¡¡ a nuestro equipo (y, algo más difícil a nuestros superiores) para que vean que planificar es trabajar, que requiere tiempo y atención y que es más importante que tirarnos de cabeza a trabajar (en el sentido real) en el proyecto.

Cuando perdamos el control del proyecto, parémonos, hagamos un alto y dediquemos un tiempo a afilar el hacha. No olvidemos nunca que “Cada hora dedicado a planificar nos ahorra un día de trabajo inútil” (S. McConnell).

Otra pregunta interesante: ¿Porqué los plannings nunca (bueno, casi nunca) se cumplen?

En ocasiones porque los proyectos nacen retrasados, tenían que haberse empezado meses antes y aparecen de improviso en nuestro ordenador (cara a cara, alguna rara vez) con un escueto “hacedlo cuanto antes”.

En otras por razones como el optimismo consustancial al carácter mediterráneo (esto se hace en dos patadas…);

la falta de consideración del tiempo que lleva tomasr decisiones, los tiempos de tramitación, las tareas de integración;

el gusto por jugar a mentirse que encanta a directores y project managers (que juegan a darse y pedirse fechas que no se cree nadie)

a que los equipos no intervienen hasta que el planning ya se ha retrasado;

o a que, más grave, acabamos de cometer los mismos errores que en el proyecto anterior.

A que os ha pasado alguna vez que algunos plannings provocan risas sofocadas por parte de los equipos mucho antes de que se demuestre que efectivamente era una gran ilusión.

¿Cuántas veces pasa un Project manager horas, días o semanas creando un plan de proyecto detallado que incluya detallados fechas de entrega, recursos, riesgos previstos y sus planes de contingencia para recibir, como única respuesta del director “recórtalo en tres meses” sin reducir, por supuesto el alcance ni logrando nuevos recursos para lograrlo. Y este es el momento de la verdad, en el que se distingue a un Project manager profesional y a uno que ocupa la silla así denominada. Decir que sí a la no razonada respuesta del superior, hará flaco favor a ti, tu equipo y vuestro prestigio como profesionales.

Debes planificar. Que te guste es opcional, hacerlo, es obligatorio. Eso sí no es necesario una mega plan perfectamente desarrollado en 300 tareas agrupadas en 30 tares resumen en MS Project. Probablemente baste con una tablita o diagrama de red con fechas que marque los hitos más importantes:

Además, y tras darle tanta importancia al planning anterior, me atrevo a decir que, esta tabla es lo menos importante. Lo más importante que ha ocurrido ha sido que las partes interesadas se han sentado juntas, han dedicado una parte de su precioso tiempo a pensar en grupo, se han implicado en la planificación del proyecto, han dado ideas y todas las partes lo sienten como propio.

Cerraremos este punto con un comentario a los apagafuegos tan populares, reconocidos (incluso con variables máximos por su ardor guerrero) y “necesarios” según el orden tradicional. Estos señores acaban siendo adictos (y contagiando su adicción) a trabajar con la adrenalina a tope, a apagar todos los fuegos que por todas partes amenazan el proyecto. Un consejo: ten cuidado con ellos, los bomberos llevan cerillas. No les animes más prestándoles demasiada atención, no es el tipo de persona que necesitamos.

Y busquemos personas (los apagafuegos pueden hacerlo también pero necesitan desaprender algunas cosas…) que piensen en QUIEN está afectado por el proyecto (participantes, interesados y accionistas), priorizar los interesados (unos son más importantes que otros), desarrolla el QUÉ tareas hay que realizar, qué indicadores nos van a medir el éxito, estar atento al PORQUÉ NO (para detectar riesgos, obstáculos, limitaciones,…) y decidir el CÓMO haremos el proyecto (creando planes y programaciones detalladas que revisaremos y corregiremos durante la fase de proyecto).

Cómo ser Project Manager y no morir en el intento (III)

publicado a la‎(s)‎ 2 oct. 2010 13:43 por angp angp

Daniel Echeverría Jadraque <decheverriajadraque@acciona.es>


Tercera Parte: Dónde aprendemos a distinguir entre los que dan un paso adelante y los que se borran en un proyecto, donde nos cuentan que nuestro Project Manager debe ser paciente en la adversidad, resistente a la crítica y animoso en la batalla, y donde nos encontraremos con leñadores muy atareados y bomberos que encienden más fuegos que los que apagan.


5. Esto no tenía que hacerlo yo ¡era de otros!!!

Todas las organizaciones están perfectamente diseñadas para obtener los resultados que obtienen. Para lograr mejores resultados, necesitarán mejorar el diseño de su organización. Como a menudo decía A. Einstein si haces las cosas de la misma manera, obtendrás los mismos resultados.

En algunas organizaciones las personas que se supone que están para liderar y organizar suelen abdicar de esta responsabilidad, evitando comprometerse y recluyéndose en sus zonas de confort y descripción de funciones. Esto puede explicarse si sabemos que la primera razón para no ponernos objetivos es el miedo a no cumplirlos.

Y, esto, amigo Project manager, es algo que no puedes permitirte. Si no te atreves a fracasar, ten cuidado que proyecto lanzas. Si temes no lograr el éxito, ni te muevas, cambia de trabajo. Porque si no recibes objetivos, mírate al espejo y aquel que ves será quién te los dé, no alguien más arriba del organigrama. Aunque esto pueda ser peligroso en organizaciones en las que las personas con iniciativa son consideradas peligrosas o, al menos, incómodas.

Para personas que quieren participar del problema y de la solución abundan las posibilidades, las ideas, las alternativas; para personas que tienen la valentía para arriesgarse a fallar y para navegar en aguas revueltas. No así para aquellas que, prefieren esperar sentadas, tranquilas, a que llegue una orden “del más arriba”. Y, curiosamente, evitar responsabilidades funciona relativamente bien en algunos entornos organizativos.

Los Project managers responsables y verdaderamente profesionales se implican en asuntos sobre los que se les pedirá responsabilidades. Y, claro, son blanco fácil para los ya mencionados CCCC, Compañeros Contra Cualquier Cosa, así como para la gran mayoría de personas para las que la crítica y la queja es un hábito. Un Project manager debe dar un paso adelante y decir “Puedes contar conmigo¡”.

Frecuentemente subestimamos nuestras capacidades, así que trata de comprometerte a algo más. Eso sí, ten claro que las personas que se comprometen de esta manera son una amenaza para la mediocridad. No sé quien dijo aquello de que “Lo hicieron porque no sabían que era imposible” pero me gusta y viene a cuento.

Como Project manager, debes trabajar en entornos matriciales que requieren una coordinación entre departamentos muy intensa y buscar el apoyo y la complicidad de personas que no dependen ni remotamente jerárquicamente de ti. Rara vez una persona del equipo reporta al Project manager, sino a su jefe jerárquico, cuando décadas de experiencia indican los beneficios que se obtendrían si así se hiciera. Por eso, un proyecto puede embarrancar o llegar a otro puerto porque no hay una asignación clara de funciones y responsabilidades (y en estos entornos los especialistas en borrarse son los reyes). El Project manager acaban chocando contra los llamados directores funcionales en una guerra por los recursos, en pos de lo que son frecuentemente objetivos diferentes. Acaba mendigando colaboración entre los técnicos con los que se lleva bien.

Así que, una vez claro lo que hay que hacer, crear una matriz de asignación de responsabilidades que indique quien ejecuta, quien revisa, quien aprueba y quien se responsabiliza de cada tarea es condición sine qua non para seguir adelante. Y si esta matriz está en un lugar visible para los miembros del equipo, mucho mejor. Y si el gran jefe, indica a los jefes de departamento, que al Project manager hay que atenderle un tiempo determinado, mejor.

Hay quien piensa que para la asignación de responsabilidades y funciones ya están los organigramas de las empresas. Pero, si echas una mirada a la mayoría de ellos te permitirá discernir quién tiene el sueldo más alto pero ni remotamente se parecerá ni dará información de cómo funciona un proyecto, de cómo se organizan y se realizan los trabajos en un proyecto.

Además, los proyectos se desarrollan en entornos cada vez más cambiantes en los que no solamente se requieren la colaboración cruzada de equipos sino también relacionarse con proveedores, clientes, contratistas, socios,… y todo este mundo no se refleja en el organigrama de la empresa.

Así que, si el organigrama de la empresa no sirve y necesitamos uno, al inicio de cada proyecto tendremos que crear un organigrama temporal para ese proyecto que, ayudado por los diagramas de red, nos permita establecer los flujos de trabajo, las líneas de comunicación, las funciones y las responsabilidades de cada participante. Este organigrama se desvanecerá conforme el proyecto llegue a su fin y, de forma natural, se recompondrá para afrontar un nuevo reto, adaptándonos así a las necesidades cambiantes de este mundo.

Eso sí, el organigrama oficial, escrito en letras de oro y publicado en la intranet correspondiente permanecerá como un dios adorado, fijo, intocable, hasta la próxima adquisición, compra, fusión o reorganización estratégica.

Si grandes civilizaciones enteras se han extinguido por no adaptarse, por no cambiar, ¿podemos esperar que cambie la manera en que las compañías se estructuran? Va a ser que no¡

Y como un Project Manager es ante todo un hombre que tiene ánimo para cambiar lo cambiable, paciencia para aceptar lo incambiable y sabiduría para distinguir entre ambas, tratará de lograr un ambiente razonablemente efectivo en su entorno. Tratará de buscar fórmulas para que la estructura organizativa de la compañía sea irrelevante para su proyecto.

K. Wiefling propone cuatro: La primera, demuestra a tu equipo que su participación impactará positivamente en el proyecto; la segunda, aprende qué preocupa e interesa a cada miembro y busca la manera de alinearlo para que apoye el proyecto; la tercera, trata de reconocer la contribución de cada persona al proyecto más allá de el que la estructura funcional ofrezca; la cuarta, créate tu propio esquema organizativo del proyecto que haga inútiles los existentes en la medida en que afecta al proyecto (eso si, discretamente, para que no se note).

Funciones poco claras son el inicio del fin de un proyecto. Si cada participante no tiene claro su sitio y su función, pueden pensar que no sirven para nada. Si no saben lo importante que es su papel en el proyecto, acabará sentándose a esperar a que alguien vaya sacando adelante los temas urgentes de cada día.

Por ello, valiente Project Manager, ármate de valor y una buena dosis de discreción y mano izquierda y crea tu propio organigrama temporal y deja la estructura jerárquica egocéntrica de los burócratas del Siglo XXI para otros.

1-10 of 12