Identificación de los grupos de interés de un proyecto

oct 30, 2013 Posted by eduocastella In Project Management Tagged Product management, proyecto Comments 2

La correcta identificación de los interesados es determinante para la consecución de los objetivos del proyecto. Una de las novedades más importantes que se han incluido en la versión 5 del PMBoK®, ha sido la inclusión de los stakeholders o interesados como otra área de conocimiento. Este reconocimiento nos da idea de cómo de importante es la buena gestión de todos los implicados, directa e indirectamente, en cualquier proyecto.

Una correcta identificación y clasificación, nos va a permitir poder gestionar los intereses y expectativas de los diferentes interesados en el inicio y durante el proyecto, evitando futuros malentendidos o contratiempos que puedan comprometer el desarrollo y la consecución de los objetivos fijados. Nos va permitir desarrollar los diferentes planes; por ejemplo de comunicación, en los que de forma sistemática y específica para cada grupo de interesados se va a llevar a cabo dicha comunicación. Pues todos no tienen que mostrar interés por el mismo tipo de información o actividad con respecto al proyecto, o no tienen por qué estar al mismo nivel de conocimiento técnico para poder entender las diferentes implicaciones del proyecto. En definitiva, nos permite tratar de forma más personalizada y especifica las diferentes necesidades de cada grupo de interesados, para que todos puedan mostrar el grado de aceptación o implicación oportuno.

Así pues, esta identificación y clasificación es una tarea lo suficientemente importante como para tenerla en cuenta durante la definición o iniciación del proyecto, identificando a los interesados de alto nivel. Y durante la planificación, elaborando el plan de gestión de los interesados, donde incluso podemos ampliar esta identificación y clasificación.

Sin embargo, en esta 5ª versión del PMBoK®, aún no se han definido de forma clara cuáles deberían ser los criterios y las herramientas para establecer de forma apropiada esta identificación. Una idea podría ser la utilización de las herramientas de identificación de riesgos, como las Prompt List o la revisión de la documentación. Pero seguramente hay otros criterios o herramientas que se podrían utilizar para realizar esta identificación. ¿Cuáles utilizáis vosotros o creéis que se podrían utilizar?

Post realizado por los alumnos del MPM: Mónica Delgado, Susanna Estany, David López, Irene Riñones, Francesc Teixidó y Manel Teixidó.

Rating: 0.0/5 (0 votes cast)

La Fábula de los 3 Project Managers

jun 25, 2013 Posted by luisballo In Project Management Tagged evaluación, Product management, project manager Comments 19

Érase una vez tres Project Managers que gestionaban la construcción de tres casas en un bosque cercano a Oklahoma.
A pesar de que las parcelas eran contiguas y que las obras empezaron al mismo tiempo, los propietarios tenían diferentes expectativas y decidieron que cada uno utilizaría el diseño y los materiales que considerasen oportunos. En la reunión de Kick off, alguien recordó que era tierra de lobos.

Los escenarios finalmente seleccionados fueron los siguientes:

La primera casa se construyó de paja. El Project Manager quería entregarla con rapidez y a un coste ajustado, por lo que escogió un material sin problemas de suministro y que se pudiera manipular con facilidad.
El segundo Project Manager decidió construir la casa de madera, según la tipología propia de la zona. Aunque sabía que los plazos y costes serían mayores, confiaba recuperar la inversión con rapidez.
La tercera casa se construyó de ladrillos, porque el Project Manager priorizó la solidez y la estabilidad por encima de otros criterios.

Con las obras ya finalizadas, un tornado tan fiero y malvado como el lobo apareció sin avisar y arrasó las casas de paja y de madera en un instante. La casa de ladrillos, por el contrario, aguantó y pudo dar cobijo a los habitantes de las otras casas mientras se activaba el Plan de Emergencia.

Evaluando los daños ocasionados y desarrollando las lecciones aprendidas, se vio que los Project Managers habían tenido una actitud muy distinta respecto a los riesgos, tanto a nivel de identificación y análisis, como del Plan de Respuesta:

El Negligente: el primer Project Manager había llegado accidentalmente a la Dirección de Proyectos y, por desconocimiento o por omisión, no realizó ninguna gestión de riesgos. Igual que el avestruz, escondió la cabeza para no ver los peligros, como si realmente no existiesen.
El Temerario: la formación y experiencia en gestión del segundo Project Manager le permitieron reconocer el riesgo, pero decidió dedicarse a cosas más urgentes o simplemente ignorarlo, confiando en que nunca aparecería. Curiosamente, el error más frecuente que un equipo de proyecto comete en relación a la gestión de riesgos es que después de identificarlos, no hace nada al respecto.
El Responsable: el tercer Project Manager, mucho más experimentado, entendió desde el principio el impacto que podría ocasionar el riesgo por lo que, a pesar de que la probabilidad de que sucediera era incierta, decidió condicionar todo el proyecto, tanto en el diseño como en los objetivos de coste, plazo y calidad.

Viendo el final de la historia y que únicamente fueron felices y comieron perdices en uno de los escenarios, la moraleja de esta fábula podría ser: “asegúrate de que el lobo no te coja desprevenido”, que trasladado al lenguaje de los Proyectos quiere decir: “¿podemos asumir el coste de no realizar una gestión eficaz de los riesgos?”

Y vosotros, ¿qué moraleja le pondríais a esta historia?

Rating: 0.0/5 (0 votes cast)

WBS vs Cronograma

jun 20, 2013 Posted by jibaez In Project Management Tagged Product management, WBS Comments 0

En todo proyecto, se considera que una de las primeras actividades de planificación es el desarrollo de la WBS, lo que nos permitirá organizar y exponer nuestra visión del proyecto. Una vez tenemos clara la estructura de entregables y las actividades que los conforman, ya podemos proceder a desarrollar el cronograma.

El hecho de que tengamos que emplear nuestro tiempo haciendo ambos, junto con las capacidades actuales de la mayoría herramientas de software, hace que muchas veces tengamos la tentación de empezar nuestro proyecto directamente por el cronograma. Craso error, puesto que estaremos desarrollando el alcance con técnicas y herramientas de gestión del tiempo, con los inconvenientes y limitaciones que ello supone. En algunos foros se propone incluso hacer la WBS después de desarrollar el cronograma!!!

Entre dichas capacidades de las herramientas, figura el poder trasladar la WBS directamente al cronograma, lo que nos evitara esfuerzo y errores. Hay que tener muy en cuenta que determinadas herramientas de desarrollo de la WBS se sincronizan con las de desarrollo del cronograma, como por ejemplo WBS Chart Pro® con MsProject®.

Esto que a priori puede suponer una ventaja, es un serio inconveniente, puesto que todos los cambios que hagamos en el cronograma, se reflejaran en la WBS y viceversa, con lo que ésta perderá su enfoque a entregables, siendo una representación más de la temporalidad del proyecto. Dejara de tener sentido como exposición del alcance.

Mi consejo es que se utilicen las capacidades de vinculación para un primer volcado de la WBS, pero que una vez hecho, se rompa dicho vínculo para permitir que alcance y tiempo no se vean interferidos, manteniéndose la máxima de que la WBS debe estar orientada a entregables, nunca reflejar la temporalidad en detalle del proyecto.

No debería suponer un inconveniente mantener dos documentos, puesto que si bien deben estar alineados, ambos reflejan aspectos bien distintos del proyecto. Como prueba de ello, esta que cualquier cambio que hagamos en ambos, deberá reflejarse en el presupuesto, y no por ello gestionaremos este último con las herramientas para elaborar WBS o cronogramas, apaños aparte….

Para terminar, insistir en que nunca debe obviarse la WBS pensando en que con un cronograma tendremos la misma información. Si partimos de esta visión, estaremos renunciando a estructurar el alcance de nuestro proyecto, centrando nuestros esfuerzos en el aspecto temporal de la triple restricción, que aunque importante, no deja de ser uno más.

Rating: 0.0/5 (0 votes cast)

Lessons learned: Lecciones de grandes empresarios y un project manager.

jun 7, 2013 Posted by evamarini In Project Management Tagged empresarios, Product management, project manager Comments 11

El presente post ha sido enviado por Javier Coca, profesional con una dilatada experiencia en ONG’s y consultoría para el establecimiento de Joint Ventures entre empresas africanas y occidentales, además de alumno del MPM On-line. Escribe habitualmente sobre tecnología y empresas africanas en http://www.adventurenetwork.org/es/category/blog/

Un project manager y un CEO tienen algo en común: los dos llevan un timón en sus manos, y constantemente intentan tomar decisiones correctas para llegar a buen puerto, capeando temporales y tormentas tropicales si es necesario. Ambos tienen un alto nivel de responsabilidad, ambos dirigen equipos formados por personas. Bien es verdad que no comparten en absoluto el nivel de autoridad en la estructura de la empresa, pero de eso no vamos a hablar ahora. Vamos a ver buenas prácticas de buenos CEOs en relación a las lecciones aprendidas.

En su libro Good to Great (2001), Jim Collins analiza de arriba abajo empresas que consiguieron resultados económicos apabullantes de manera sostenida durante al menos 15 años. No lo hace de cualquier modo. Invierte 5 años con la ayuda de 20 investigadores que tabulan y analizan decenas de miles de artículos, conceptualizan gigas de datos, entrevistan exhaustivamente a decenas de implicados… Parte de lo que comprobaron Collins y su equipo fue que en aquellas empresas, una mayoría de CEOs y ejecutivos tenían un hábito que el equipo de investigadores de Collins llamó blameless autopsy: “autopsia sin culpa” o “autopsia inocente”.

¿En qué consistía? Collins identifica que estas personas siempre afrontaron los hechos en bruto, independientemente de la situación. No pretendían tener todas las respuestas. Preguntaban, preguntaban y volvían a preguntar. Dialogaban y debatían, incluso muy acaloradamente, pero no se imponían. Buscaban acuerdos. Analizaban los errores clínicamente, sin culpables ni víctimas.

Esta costumbre parece haber sido crítica a nivel estratégico en algunos casos. En otros, era parte de la filosofía de la empresa. Una de ellas adquirió en 1978 otra entidad, en lo que terminó siendo un enorme fracaso comercial de alto costo para la empresa. Collins cuenta cómo él y su equipo quedaron estupefactos al ver que en las entrevistas, los responsables de la debacle no sólo no evitaban hablar del tema, sino que por iniciativa propia la comentaban abiertamente (el líder de la empresa dedicó 5 páginas enteras de sus memorias a analizar el error, sus implicaciones y las lecciones aprendidas). Aparentemente, se invirtieron cientos de horas de recursos a todos los niveles a analizar el fracaso. Analizaron. Una autopsia sin culpa. Un patrón que Collins y su equipo encontraron repetidamente en equipos que lideraron empresas extraordinarias.

Nosotros no tenemos autoridad para fracasar comprando empresas, pero sí tenemos una responsabilidad hacia la empresa y hacia el equipo, por lo que nos interesa además saber qué dice un project manager al respecto, ¿no? Pues para eso tenemos al agradable Joseph Heagney, que en su libro Fundamentals of Project Management (2011), comenta lo siguiente:

Cuando el trabajo se ha terminado, la fase de cierre requiere que se lleve a cabo una revisión. El propósito es aprender lecciones que podamos sacar para futuras ocasiones. Preguntamos dos cosas: “¿Qué hemos hecho bien?”, y “¿qué queremos mejorar la próxima vez?”.

Nótese que no preguntamos qué hemos hecho mal. Esta pregunta tiende a poner a la gente a la defensiva y le hace esconder cosas por temor a llevarse un castigo. De hecho, una revisión de lecciones aprendidas nunca debería dirigirse en un estilo culpable/castigo. Si lo que quieres es llevar a cabo una inquisición, eso ya es otra cosa. El propósito de una inquisición suele consistir en encontrar a los responsables de grandes desastres y castigarlos.

Las sesiones de lecciones aprendidas deberían ser exactamente lo que sus palabras implican.

¿Qué habilidades son necesarias para desarrollar una correcta sesión de lecciones aprendidas?

Analiza una situación profesional que conozcas donde se buscaron culpables en vez de hacer una autopsia sin culpa. ¿Qué podría haberse hecho mejor?

Imagen: Jcarlosbulas

Rating: 0.0/5 (0 votes cast)

Evaluar y Valorizar un proyecto innovador. Pregunta Nº 3

jun 4, 2013 Posted by evamarini In Project Management Tagged inversor, MPM, Product management, proyecto Comments 0

Post realizado por Víctor Espinosa

Recordad, que seguimos trabajando algunas preguntas y sus respectivas respuestas, para poder superar la primera fase de un proyecto innovador, que no es otra que la de obtener la aprobación de mi dirección y los fondos para llevar a cabo el proyecto y saber como internacionalizar mi proyecto.

Vamos con la tercera y última pregunta de esta serie:

3 – ¿Cómo piensa y que valora más, el inversor o mi propio director general, a quien voy a tener en frente? ¿Qué es lo que más le motiva al inversor, a la hora de invertir en un proyecto o iniciativa de negocio?

Al inversor aunque no os lo creáis le gusta de todo menos el riesgo, y sobre todo lo que más le gusta es cuál es el retorno de su inversión y en qué plazo de tiempo. Si no le gusta el retorno ni el plazo acabaréis la presentación en 2 minutos. Es por ello que es fundamental reflejar de forma correcta y objetiva los ratios de valor de la inversión como son el VAN y el TIR (y algunos otros), y cuando digo reflejar no sólo es saber cómo se calculan, sino como se argumentan y sustentan en un plan de negocio. Si empezáis por aquí y esto les gusta, tendréis dos minutos más de vida, por lo menos hasta que os pregunten si tienes previsto trabajar y producir con las garantías que proporciona la normativa UNE166000/1/2.

Podríamos seguir con decenas de preguntas como estas pero con tres basta por el momento. Ni que decir tiene que es muy útil para cualquier director o gestor de un proyecto o de una iniciativa innovadora de cambio, el hacerse las preguntas correctas. Si las preguntas son buenas las respuestas serán mejores. Vayamos a ellas.

Hay más semáforos, pero de ellos seguiremos hablando en el futuro. Hasta pronto.

Rating: 0.0/5 (0 votes cast)