Ivan Rivera, PMP

Administración de Proyectos eficaz mediante el uso de las normas ISO

noreply@blogger.com (Iván Rivera, PMP) — Wed, 25 Jan 2012 23:38:00 +0000

Ahora desde blog de Cobalt revizaremos la propuesta de Ronelle Smith que nos sugiere como usar los estándares ISO para conseguir que nuestros procesos de Administración de Proyectos sean mas eficaces.

Primero Ronelle nos recuerda que las Normas ISO constituyen un sistema de normas universales para la mejora a través de una amplia gama de industrias, incluidas las normas de gestión de calidad y normas de administración de proyectos.

Estas normas ofrecen una guía de buenas prácticas propuestas por la Organización Internacional de Estándares (ISO por sus siglas en inglés).

La norma que aplica a los procesos de Administración de Proyectos es la ISO 21500. Esta norma se basa en una serie de otras normas existentes, y es aplicable a organizaciones de todos los tamaños y naturalezas.

Cuando los Administradores de Proyecto (neófitos o experimentados) son capaces de aplicar estas normas, el resultado en un mayor nivel de gestión de la calidad en los diferentes proyectos que se implementan.

Los beneficios adicionales de la Administración de Proyectos apoyándose en el estándar ISO 21500 son:

Fomentar la transferencia de conocimientos entre los proyectos y organizaciones para una mejor ejecución de los proyectos.
Facilitar la eficiencia de los procesos de licitación a través del uso de una terminología de administración de proyectos coherente.
Permitir la flexibilidad de los empleados del proyecto y su capacidad para trabajar en proyectos internacionales.
Proporcionar un marco base para los programas de certificación.
Proveer de principios y procesos universales para la administración de proyectos.

Además, la Norma ISO 9000 también puede es útil para la gestión de proyectos. Esta norma se centra en la gestión y el liderazgo, especialmente en lo que respecta a la gestión de calidad y procesos.

Ya que ambos juegan un papel vital en la administración de proyectos, la ISO 9000 ofrece una serie de beneficios a los ejecutivos del proyecto. Esta norma introduce los ocho principios de gestión de calidad definidos por la ISO, así como el enfoque basado en procesos para lograr la mejora continua.

Finalmente Ronelle nos recuerda que la Normalización se ha convertido en una de las mejores maneras de asegurar un mayor nivel de calidad en todas las áreas de gestión, desde los procesos mas básicos hasta la administración de proyectos.

¿Que se debe preguntar al cliente potencial de un nuevo proyecto?

noreply@blogger.com (Iván Rivera, PMP) — Mon, 16 Jan 2012 16:00:00 +0000

Desde la página Project Management Tips Brad Egeland nos ayuda a responder a la siguiente pregunta: ¿Que se debe preguntar al cliente potencial de un nuevo proyecto?

Brad nos propone cinco preguntas que se deben hacer al cliente potencial en un nuevo proyecto a fin de obtener detalles sobre qué considera que necesita.

1. ¿Existe presupuesto para esta actividad?

Brad considera que es importante hacer esta pregunta en primer lugar, para no perder el tiempo defendiendo una posición que no tiene el respaldo de la organización.

Esta es sin duda una pregunta que debe hacerse lo más pronto posible, durante las primeras reuniones con un cliente potencial. Y no es necesario saber cuánto puede gastar. Pero es necesario saber que si puede invertir en el proyecto.

2. ¿Existe un plazo dentro del cual el proyecto deba ser completado?

Si hay algún compromiso de tiempo a nivel gerencial, usted necesita saberlo. Las necesidades específicas y plazos respecto al calendario del cliente del proyecto son cosas que usted necesita saber ya que influyen directamente en todas las otras decisiones que se tomen respecto al proyecto.

3. ¿Cuál es el mayor problema que enfrentamos que nos ha llevado a estar aquí?

El cliente siempre tiene una gran necesidad de la que es consciente y que le ha llevado a buscar el desarrollo de un proyecto.

Además, puede haber más problemas ocultos que se deberán determinar y reconocer. Por esto, Brad sugiere hacer las preguntas correctas para encontrar el problema que el cliente percibe, y luego hacer más preguntas para ver si el problema en realidad es sólo un síntoma del verdadero problema o problemas que necesitan resolverse.

Si el proyecto resuelve sólo el problema inicial percibido por el cliente, este será feliz a corto plazo. Pero si se localiza y resuelve el verdadero problema, se gana más con el cliente, tanto en confianza como en ingresos.

4. ¿Qué retroalimentación tiene el cliente de sus usuarios finales?

Es recomendable verificar que se haya consultado a los usuarios finales de cualquier proceso actual o los usuarios finales del proceso de nuevos potenciales que sean afectados por el proyecto.

Este es un tema que hemos tratado en forma recurrente en este blog: Hay que tomar en cuenta la opinión de todos los interesados en el proyecto (entre otras entradas, aquí y aquí).

Como sugiere Brad, hay que asegurarse de que el cliente ha discutido la situación con sus usuarios finales. Si no es así, esta actividad se vuelve trabajo del Administrador del Proyecto, por lo que necesita saberlo desde el principio, ya que afectará a su presupuesto y la forma en la que va a tratar a estas personas.

5. ¿Ha discutido el problema en detalle, con todos los expertos en la materia en su organización?

Hay que asegurarse de que el proyecto no es solo un pensamiento en la cabeza del cliente patrocinador, sino que toma en consideración a cualquier "experto" interno que pueda arrojar luz sobre el asunto o puede contar con una potencial solución al problema.

Las respuestas a estas sencillas preguntas proporcionan elementos para dimensionar el proyecto, evaluar sus riesgos y eventualmente tomar la decisión de iniciarlo o no.

Referencias: El número cinco. 2011. Culturally Authentic Pictorial Lexicon. Recuperada de http://capl.washjeff.edu/browseresults.php?langID=14&photoID=2368&size=m el 29/Dic/2011.

Harry Potter y las siete características necesarias en el Administrador de Proyectos

noreply@blogger.com (Iván Rivera, PMP) — Mon, 02 Jan 2012 16:00:00 +0000

Iniciemos el año con la continuación de un análisis que inició aquí. Ahora revisemos a Harry Potter y las siete características necesarias en el Administrador de Proyectos que Linda Richter nos propone en brighthub.

1. El Administrador de Proyectos nunca debe pensar que está solo o que es el único capaz de realizar el trabajo.

Como señala Linda, en las primeras historias a partir del momento en que descubre que él es el niño que vivió, Harry desarrolla la idea de que esta solo en su misión. Y luego conforme crece va aprendiendo a identificar de sus tareas, a confiar en su equipo, e involucrar a todos los interesados. Esto es algo que los buenos administradores de proyectos ya saben.

2. Si debe pedir ayuda, asegúrese de haber identificado el proyecto primero.

Linda apunta al hecho de que tristemente Harry no es capaz de identificar cuál es su proyecto: en los primeros cuatro libros, se dedica a descubrir quién es en realidad, y solo hasta que está a punto de morir Dumbledore identifica el proyecto y se lo explica a Harry.

Voldemort, por otro lado, está obsesionado desde el principio con su plan, que consiste en acabar con Harry: desde el principio del primer libro, dando órdenes a Quirrell para matar a Harry, en el cuarto libro cuando lo tiene a su merced en el cementerio, en el séptimo libro cuando le dice que deje de someter a sus amigos a la batalla... matar a Harry siempre es el objetivo principal de Voldemort.

Sí, él también busca la inmortalidad, pero él sabe que Harry debe morir antes de que pueda lograrlo. En el sexto libro, después de la muerte de Dumbledore, Harry decide aceptar el proyecto que Dumbledore le asigna. Pero, a dónde debe ir y que es exactamente lo que tiene que hacer sigue siendo un enigma para él. Harry nunca entiende lo que se ha trazado para él hasta poco antes de que entre en el bosque al final.

3. Si se requieren recursos, no hay que confiar en pequeños duendes.

Si bien es cierto que en este caso los recursos no son un problema porque tanto Voldemort como Harry pueden recurrir a un sinfín de oro para apoyar a sus respectivas misiones, la lección que nos enseña cualquier buen Administrador de Proyecto es hacer una parada en el Callejón Diagon antes de comenzar el proyecto, para adquirir o reemplazar cualquier cosa realmente valiosa que pueda ser requerida y evitar demoras.

4. Nunca hay que dejar que el alcance se salga de control.

Cuando Harry, Ron y Hermione finalmente se ponen a buscar los Horrocruxes, Harry es víctima de la corrupción del alcance y pasa mucho tiempo acampando en diversas áreas desoladas decidiendo cual debe ser su siguiente paso sin concentrarse en la identificación y destrucción de los Horrocruxes.

Además Harry también se obsesiona con las reliquias de la muerte debido a su interés en la Varita de Saúco. Teniendo en cuenta su propia varita ha sido destruida (otro riesgo, dicho sea de paso, que no fue previsto ni administrado).

Los muggles como nosotros, dice Linda, aprendemos a identificar los parámetros de nuestro proyecto, de preferencia con objetivos cuantificables: "Voldemort debe estar 100% muerto".

5. Administrar el cambio, pero no buscar la inmortalidad como meta.

Esta obsesión por las Reliquias, sin embargo, ayuda a Harry encontrar su verdadero carácter. Vemos que Voldemort está obsesionado con la inmortalidad. Dumbledore estaba obsesionado con la inmortalidad. Harry debe decidir si la inmortalidad es también su objetivo, o tal vez simplemente la restauración de la seguridad y la paz al reino mágico a través de una última derrota de Voldemort.

Este es el punto en el que Harry lucha con su carácter, identifica sus metas y reanuda su búsqueda. Cuando entierra a Dobby, vuelve a enfocarse en su plan de proyecto original.

Y Linda nos recuerda: aquellos de nosotros que trabajamos sin varitas debemos confiar en las técnicas de control del cambio.

6. Confiar en el equipo, y evitar estrangular al mejor asistente.

Las habilidades de colaboración de Harry son las que al final inclinan la balanza en su favor.

Tanto él como Voldemort cuentan con considerables recursos humanos:

Voldemort tiene a los Mortífagos, en especial a los Malfoy, a los dementores, a Bellatrix Lestrange, y a Colagusano. También tiene a los trolls y los gigantes. Pero Voldemort hace un trabajo pobre comunicación y de confianza con sus subordinados. Quizás su más fiel seguidor haya sido Colagusano, que muere estrangulado por la misma mano que Voldemort le había dado. Al final asesina a Snape no porque sospeche de traición, sino porque quiere convertirse en amo de la Varita de Saúco. Y si eso no fuera suficiente, también ha castiga a Lucius Malfoy asignando a Draco la misión de matar a Dumbledore.

En conjunto, esto demuestra una muy mala técnica de motivación a los miembros del equipo, y probablemente lo lleva a su caída final, que comienza cuando Narcissa Malfoy le dice que Harry está muerto.

En cambio, el equipo de Harry no sólo incluye sus dos mejores amigos, sino también el personal de Hogwarts, la Orden del Fénix, y el Ejército de Dumbledore. Los elfos trabajan con él, y tiene algún tipo de cooperación limitada de los duendes y los centauros. Todo el equipo coopera y se comunica bien, un factor clave en el éxito de cualquier proyecto.

Harry trabaja duro para asegurarse de que todo el mundo se siente apreciado.

De Harry podemos aprender los beneficios de interactuar con cada uno de nuestros diversos miembros del equipo para mantenerlos interesados y al máximo rendimiento.

7. Analizar los éxitos, especialmente si se tiene la apariencia de una serpiente.

Y, por supuesto, se necesitan las habilidades analíticas de cualquier Administrador de Proyectos de primer nivel. Harry se da cuenta de que la lealtad de la Varita de Saúco no está con Voldemort.

De esto podemos tomar lecciones para utilizar las herramientas que nos permitan analizar el estado del proyecto, por ejemplo el software de administración de proyectos para analizar las estrategias del equipo y crear gráficos de red.

Al final el proyecto de Harry se completa, a pesar de la falta de planificación y el fracaso total en la gestión de riesgos y las fallas en la gestión del alcance, a través de una colaboración efectiva y el trabajo en equipo.

Referencias: http://en.wikipedia.org/wiki/File:Kobold_artlibre_jnl.jpg

¿Que cosa (única, sencilla) puede ayudar a mejorar los proyectos o la administración de proyectos?

noreply@blogger.com (Iván Rivera, PMP) — Wed, 14 Dec 2011 22:47:00 +0000

English version follows

Michael Greer pregunta en su blog: ¿Que cosa (única, sencilla) puede ayudar a mejorar los proyectos o la administración de proyectos?

Creo que no es fácil encontrar una sola cosa (y además "simple") que ayude a mejorar la administración de proyectos.

Si debo elegir, tal vez no me incline por una herramienta, ni una mejor práctica, sino por un concepto: "comunicación adecuada".

Y entonces el tema deja de ser simple.

¿Qué es adecuado?

El administrador del proyecto deberá encontrar su respuesta aplicando algunas preguntas: ¿Que se debe comunicar?, ¿a quién?, ¿con que frecuencia?

Las respuestas a estas preguntas se pueden acomodar en una matriz, sin perder de vista que no son respuestas estáticas, es decir que van a cambiar a lo largo del proyecto.

El Administrador debe asegurarse a lo largo de todo el proyecto de estar manteniendo un flujo constante de información entre todos los involucrados del proyecto, filtrando o traduciendo lo que sea necesario, respetando la frecuencia acordada con cada uno y haciendo adaptaciones al esquema cada vez que es necesario.

Creo que un esquema adecuado de comunicación es algo que puede ayudar a mejorar la administración de proyectos, aunque insisto, no necesariamente es un asunto "simple".

Con esta entrada voy a despedir el año. Agradezco a todos los lectores del blog, a quienes me siguen por twitter/facebook, a los viejos amigos y por su puesto a los nuevos. No quiero caer en el lugar común, pero si espero que el año que cierra haya dejado éxitos y aprendizaje y que el año que empieza traiga salud, que lo demás ya podremos trabajar para conseguirlo

----

English version

I think it is not easy to find a single thing (and "simple", also ) that help improve project management . If I have to choose, I may not go for a tool, not a best practice, but by a concept of "good communication".

And then the issue is not simple any more.

Because we have to decide what is "good communication"?

The project manager will find the answer using some questions:

What should be reported? To whom, how often?

The answers to these questions can be arranged in a communications matrix, without losing sight that are not static responses, that everithing could change throughout the project.

Project Manager must be assured throughout the project to get a constant flow of information between all stakeholders, filtering or translating what is necessary, respecting the frequency agreed with each other and making adjustments each time is necessary.

I think a good communication equema is something that can help improve project management, but I insist, is not necessarily a "simple" matter.

¿Por que Darth Vader era un Adminstrador de Proyectos increible?

noreply@blogger.com (Iván Rivera, PMP) — Tue, 29 Nov 2011 16:00:00 +0000

Hoy vuelvo a tomar la vida con calma. En este blog ya vimos las 10 razones por las que Harry Potter es un gran líder. Ahora, desde Geekwire, Brandon Koeller nos propone 10 razones para considerar a Darth Vader Administrador de Proyectos increíble.

Como bien aclara Bandon, esta no es una apología del lado oscuro. Solo se trata de destacar las características necesarias en un Administrador de Proyectos que poseía Darth Vader.

10) Vader priorizaba sin dudar. Ya fuera persiguiendo a la Alianza Rebelde, mitigando el riesgo de la destrucción de la Estrella de la Muerte o reclutando a Luke, Vader siempre revisaba todos los hechos, evaluaba impactos y perseguía las cuestiones prioritarias.

Si un Administrador de Proyectos no es capaz de priorizar, no va a poder cumplir con los objetivos.

9) Vader tomaba decisiones en base a datos objetivos, no en caprichos. El evaluaba contantemente a su equipo de trabajo, haciendo los ajustes necesarios para que el desempeño sea óptimo. Brandon destaca: El equipo del Proyecto necesita sentirse apoyado y seguro, pero también debe tener claros los objetivos de que debe cumplir. Y cuando alguien no cumple los objetivos se le debe reemplazar.

8) Vader hacia compromisos y se esforzaba por cumplirlos. Cuando fue necesario construir una segunda estrella de la muerte, el entendió la importancia del compromiso y consiguió que el equipo trabajara al máximo para cumplir con el plazo pactado.

7) Vader tomaba tiempo para recargar, relajarse y ver las cosas en perspectiva. En el ámbito de proyectos es frecuente que se presenten conflictos y un buen administrador de proyectos los confronta de frente, por muy desgastante que pueda ser. Vader entendía esto y era cuidadoso para tomar tiempo para relajarse, por muy cargado que estuviera el cronograma. Y usaba este tiempo para meditar y reorientarse hacia las cosas realmente importantes.

6) Vader controlaba los riesgos y las expectativas de forma preventiva. Brandon nos dice que los buenos Administradores de Proyectos piensan en sus proyectos en forma defensiva, y actúan agresivamente para protegerlos.

5) Vader era muy persuasivo. Tal vez su capacidad más efectiva era la de persuadir al equipo para hacer lo que se necesitaba. Independientemente de si usaba el miedo, la obligación o La Fuerza, conseguía que el equipo cooperara con él. Como destaca el autor, solo sus hijos no lo obedecían... Y sí, yo he vivido eso también.

4) Vader adoptó una metodología y se aferró a ella... hasta que la metodología ya no funcionó y hubo que cambiarla. Esto con el fin de mantener el desempeño del proyecto. Cuando el método del miedo dejó de funcionar probó la manipulación, luego la agresión... Lo que fuera necesario.

3) Vader no consideraba ningún problema tan grande como para no hacer frente. Vader era escéptico, lo que le sirvió en la gestión de riesgo. Brandon considera que todos los Administradores de Proyecto necesitan esa capacidad. Sin embargo, los buenos Administradores de Proyecto también deben ser suficientemente optimistas como para impulsar grandes retos y buscar soluciones, aunque sea improbable su éxito.

2) Vader sabía que nunca es demasiado tarde para hacer lo correcto. A todos se nos presentan opciones que tienen consecuencias morales cuestionables. Lo correcto es casi siempre algo por lo que habrá que luchar. Uno de los momentos más profundos en la carrera de Vader llegó cuando tomó la responsabilidad de todas las cosas moralmente malas que hizo, y entonces hizo lo correcto.

El Administrador de Proyectos deberá tomar cientos de decisiones a lo largo del proyecto. Algunas de ellas pueden ser cuestionables desde el punto de vista moral, incluyendo la omisión de detalles, evitar conversaciones, ocultar datos para pintar un mejor cuadro del proyecto. Los buenos Administradores de Proyecto se tomarán el tiempo para reflexionar sobre sus opciones, y volver a tomar las decisiones con las que no se sienten bien. Hacer lo correcto es crucial para contar con la confianza en un equipo, incluso si lo correcto es difícil.

1) Vader nunca tuvo miedo de ensuciarse las manos. Cada proyecto tendrá límites en torno a las responsabilidades de los roles específicos, y Vader conocía su papel en el proyecto imperial. Pero él nunca pidió a nadie hacer nada que él no estuviera dispuesto a hacer por sí mismo, y se aseguró de que hubiera una clara comprensión y aprecio por las cosas difíciles que su equipo tenía que ejecutar. Esto es para Brandon su característica más importante. Vader se involucró en el trabajo del proyecto, y su equipo lo siguió porque sabían que él entendía y estaba involucrado en el éxito del proyecto.

El artículo original está lleno de referencias a escenas de las películas y algunas fotos para ubicar bien al lector. Y las ideas expuestas no solo no son descabelladas, sino que parecen casi de sentido común.

¿Como se puede definir y medir el éxito de un proyecto?

noreply@blogger.com (Iván Rivera, PMP) — Tue, 15 Nov 2011 16:00:00 +0000

Recomendado por @Project_World y @corneliusficht, el artículo "Defining and Measuring Project Success" de William R. Duncan nos sugiere como definir y medir el éxito de un proyecto.

Este es un tema trascendental para el Administrador de Proyectos, ya que como hemos expresado antes (aquí), si no sabemos cuándo terminan nuestros proyectos y como establecer si terminaron en forma exitosa, siempre estarán condenados al fracaso.

William empieza señalando que la mayoría de la gente tiene una apreciación intuitiva de qué es el éxito, pero definirlo y medirlo es un poco más difícil, y pone como ejemplo las carreras de los actores de Estados Unidos: si definimos el éxito de los actores en términos del reconocimiento de la crítica, Tom Hanks (Aproximadamente 43 films, 5 oscares) es más exitoso que Tom Arnold (Mas de 85 producciones en cine y TV, sin ningún premio). Si definimos el éxito actuando como el obtener una remuneración constante y por encima del promedio para el trabajo que te gusta, entonces Tom Arnold es un gran éxito.

Así William nos lleva a este razonamiento: Con el fin de medir el éxito, primero tenemos que definirlo.

Pero, ¿cómo definirlo? En los años 1960 y 1970 la definición se limitaba generalmente a los costos de reuniones, al control del cronograma, y obtener los objetivos del alcance - ¿el proyecto fue terminado dentro del presupuesto, a tiempo, y de acuerdo a las especificaciones? Más tarde, se empezaron a considerar la calidad y la satisfacción de los interesados, pero por separado en lugar de estar incluidos dentro del alcance.

El tema común en todos los casos fue que el éxito del proyecto se definió de manera que se pudiera medir el día en que el proyecto terminaba. Pero ¿qué ocurrió con la Casa de la Ópera de Sídney? Construirla costó dieciséis veces más y requirió cuatro veces más tiempo, comparado con las estimaciones originales. Un desastre de gestión de proyectos dio como resultado un símbolo cívico perdurable e inspirador. ¿Realmente fracasó este proyecto?

De la misma manera que la calidad requiere la conformidad con las especificaciones y la adecuación para el uso, el éxito del proyecto requiere una combinación de éxito del producto y el éxito de la gestión de proyectos:

¿Fue un éxito el producto (o servicio, resultado o resultados) del proyecto?
¿Fue bien administrado el proyecto?

Un simple sí o no es suficiente respuesta. En realidad William nos sugiere cambiar la pregunta, por ¿Qué tan exitoso fue el proyecto?

Y es que debemos recordar que los diferentes interesados consideran distintas medidas de éxito. El funcionario de salud y seguridad no quiere lesiones. El gerente de manufactura quiere un producto que sea fácil de construir. El equipo de la norma ISO 9000 considera éxito que la documentación esté completa. El vicepresidente de marketing estará encantado si el producto llega al mercado antes que el de la competencia.

A los equipos de proyecto les gusta definir el éxito como "terminar a tiempo". Pero William nos hace ver que este concepto es esencialmente inútil desde el punto de vista de gestión. Aquí hay algunas preguntas muy básicas que esa frase no responde:

¿Se puede tener un día de retraso? ¿Una semana? ¿Un mes?
¿Si terminamos antes, es malo?
¿Estamos midiendo contra el cronograma original o la línea base actual?
¿Las actividades individuales tienen que estar a tiempo también?

Para ayudar a superar la tendencia a simplificar en exceso, William recomienda tratar de usar un formato estructurado para el definir los criterios de éxito del proyecto. Por ejemplo:

Hacer una introducción clara: "una medida clave del éxito de este proyecto es tener ..."
Tener elementos medibles: "la fecha de finalización de los hitos importantes"
Usar enunciados de comparación: "dentro" (o "incluye")
Usar números: "una semana adicional a la fecha de programación de base"

La mayoría de los proyectos tendrán por lo menos tres medidas de éxito - costo, apego al cronograma, y satisfacción de los interesados. Los proyectos más grandes pueden tener más, pero tres es el mínimo que William recomienda.

A menudo es difícil definir medidas de éxito de los productos . Muchas de las medidas posibles, tales como los ingresos y ahorros en costos están fuera del control directo del equipo del proyecto y no se podrán medir hasta mucho tiempo después de finalizado el proyecto. Cuando este es el caso, el equipo debe determinar en lo que puede influir. Por ejemplo:

Con un producto de consumo, se puede influir en el costo unitario de fabricación.
Para una aplicación de software basada en web, el objetivo puede ser 100% de cumplimiento con las normas públicas.
En un proyecto de tecnología de la información, la capacitación puede ser vital para la aceptación del usuario.

Al igual que con cualquier otra herramienta o técnica, la medición del éxito del proyecto puede ser exagerada. William sugiere utilizar la siguiente lista para asegurarse de que sus medidas son buenas.

Las medidas del éxito del proyecto deben ser:

Completas - cualquier cosa sin medir probablemente se verá comprometida.
Relevantes - las variaciones indican claramente la necesidad de una acción correctiva.
Válidas - para medir lo que pretende controlar.
Fáciles de entender - para que la gente los acepte.
Económicas para obtener - se debe conocer el valor de la información.
Oportunas - en comparación con el resultado de la medición.

Al final, William recuerda: el proyecto será medido. Los interesados decidirán si fue bien gestionado. Alguien va a decidir si el proyecto fue un éxito.

Lo mejor para el equipo, la organización y el administrador es documentar y obtener la aprobación de estas medidas desde el principio.

Como empezar a controlar nuestros proyectos mediante valor ganado.

noreply@blogger.com (Iván Rivera, PMP) — Sun, 30 Oct 2011 16:00:00 +0000

Siguiendo la pauta de artículos sobre valor ganado que inicio aquí y ha seguido aquí y aquí, ahora propongo un artículo en el que Shim Marom desde su blog, nos comparte algunas notas sobre cómo empezar a controlar nuestros proyectos mediante valor ganado.

El autor nos dice que no es necesario trabajar en un ambiente donde el Análisis de valor ganado (EVM por sus siglas en inglés) se implemente a un nivel que satisfaga la norma ANSI-748-B, para poder aprovechar los beneficios de esta herramienta.

Shim se desarrolla en el ámbito de las TI, y nos dice que a pesar de la creencia popular, es casi imposible (o más correctamente - no muy creíble) basarse en proyectos anteriores para determinar las estimaciones del proyecto. Los casos de negocio se aprueban en base a estimaciones cuya validez es cuestionable, ya que normalmente se aplica a los números alguna forma magia con el fin de convencer al cliente de que el análisis costo-beneficio es favorable.

Pero Shim también reconoce la dificultad de tener todos los datos necesarios para hacer un correcto AVG antes de iniciar el proyecto, por lo que sugiere algunas tareas que se deben considerar independientemente de que se vaya a usar o no Valor Ganado para controlar el proyecto.

Tener claro el alcance del proyecto - objetivos claros dan resultados claros - seguramente todos quieren saber cuál es del destino antes de empezar el viaje. Si se pueden describir los resultados esperados del proyecto, ¡No debe existir ningún problema para incluirlos en una EDT (WBS)!
Asignación de Recursos - con su EDT completa a nivel de entregable, se debe examinar el pool de recursos (incluyendo su disponibilidad) y asignar recursos a los entregables (obteniendo de este modo la Matriz de Asignación de Recursos - RAM).

Presupuesto - Shim sugiere investigar para entender la naturaleza de la incertidumbre del proyecto. Luego, con el apoyo de los recursos, hay que acordar el nivel estimado de esfuerzo que tenga más probabilidades de ser suficiente para completar el entregable. Con el costo de los recursos y el esfuerzo estimado se puede concluir el presupuesto, teniendo en cuenta las dependencias de tareas.

Los dos últimos puntos que Shim sugiere son:

Definir un método para determinar el porcentaje completado en los entregables. Su preferencia personal es de 0% antes de que comiencen los trabajos, 50% tan pronto como se inicien las tareas y el 100% cuando la entrega se ha completado.

Registrar los costos reales a un nivel que permita reportarlos a nivel de entregable. Si no es posible Shim sugiere al menos utilizar una hoja de cálculo, y hacer que el equipo informe el tiempo invertido por entregable a la semana (o día, según aplique).

Como señala Shim, hay mucho más que se puede hacer para confirmar un sistema de registro de valor ganado. Sin embargo, no hacer nada debido a la falta de un EVMS completo no debería ser una opción.

Como se ha visto, algunos pasos simples permiten al menos encaminar el esfuerzo en la ruta correcta.

¿Como puedo saber cuando el proyecto terminó en forma exitosa?

noreply@blogger.com (Iván Rivera, PMP) — Sun, 16 Oct 2011 05:03:00 +0000

English Version Follows

Uno de los problemas más frecuentes a los que me he enfrentado desde la PMO es la incapacidad de los equipos del proyecto de decidir cuando el proyecto está terminado.

Y por equipo de proyecto no me refiero solo al equipo de trabajo que ha elaborado los entregables, sino a todos los interesados: el cliente y su personal involucrado, y las personas que participan en cada una de sus fases.

Así que una primera dificultad es decidir si el proyecto terminó o no. Pero además el esquema se complica aún más si lo que se busca es determinar si terminó en forma exitosa. Aunque puede parecer un asunto de sentido común, la verdad es que las definiciones de "terminado", "éxito" y "fracaso" son subjetivas, por lo es buena idea buscar un acuerdo entre todos los interesados sobre lo que estos conceptos representan.

Es cierto que las mejores prácticas nos sugieren registrar el enunciado de alcance preliminar y la definición del alcance del proyecto. Además sabemos que todos los cambios al alcance se deben registrar en el log correspondiente y que antes de aprobarlos se debe hacer un análisis de los riesgos y su impacto en el cronograma, en el costo, en los recursos requeridos, etc. Pero de nuevo estos documentos nos refieren a conceptos difíciles de evaluar si el equipo no se ha puesto de acuerdo previamente.

Y la percepción, los sentimientos de los interesados, rara vez tienen que ver con lo que dice el control de cambios. El sistema funciona o no, se terminó a tiempo o no, independientemente de si el documento de aceptación de entregables está firmado.

Espero que un ejemplo (ficticio) ayude a aclarar la idea: Consideremos un proyecto X, cuyo objetivo era desarrollar el sistema de nómina de la empresa Y, que permita hacer los pagos a sus 300 empleados. El plan marcaba 3 meses de desarrollo, pero a la mitad del camino se emite una nueva reglamentación gubernamental que impacta al sistema.

El equipo de trabajo hizo un esfuerzo a pesar del cual el proyecto terminó 2 semanas tarde y con un 17% de costo adicional.

El equipo de trabajo está cansado pero satisfecho. El cliente está contento porque aun cuando no se cumplieron los tiempos su portal ahora es accesible a un mercado mayor. En cambio, la gerencia media en la compañía a cargo de desarrollar el proyecto no parece muy contenta, porque incluso cuando el cliente está satisfecho el margen de ganancia se redujo.

¿Es un proyecto exitoso? No podemos dar una respuesta categórica al respecto. Es necesario hacer mediciones de valor ganado (o el método de valoración que se prefiera) para saber si la relación entre cambio de alcance, mayor costo y más trabajo es positiva o negativa. Por otro lado, dos de tres grupos de interesados están contentos, así que no debe haber salido tan mal.

Esta situación de indefinición se puede solucionar si desde el principio todos los interesados acuerdan bajo qué condiciones se va decidir que el proyecto está terminado, y como saber si ha resultado exitoso.

Bajo este orden de ideas podemos acordar con los interesados que "el sistema de nómina se considerará terminado cuando el cumpla con el siguiente listado de funcionalidades...".

Podemos acordar con todos los interesados que el proyecto es exitoso si "al finalizar el tiempo negociado (incluyendo las ampliaciones y reducciones acordadas), es capaz de realizar los pagos de una nómina de hasta 300 empleados y respeta toda la reglamentación aplicable".

Como dije, parece casi un tema de sentido común, pero no se hace.

Y a pesar de que puede parecer complicado, es un mecanismo que sin mucho esfuerzo extra puede evitar que el equipo no sea capaz de decir cuando acaba el proyecto, y cuando efectivamente termine, permite decir si el proyecto fue exitoso.

La idea de escribir este post parte de las clases que imparto en el ITESM y del #PMChat.

English Version

One of the most common problems that I have faced from a PMO perspective is the project teams inability to declare when the project is finished.

And by project team I don’t just mean people that build deliverables, but to all stakeholders: customers and staff involved, and the people involved in each project phase.

So the first difficulty is to decide whether or not the project has ended. Also it is complicated to determine if the project was finished successfully. Although it may seem a matter of common sense, the truth is that "finished", "success" and "failure" definitions are subjective, so it is a good idea to find an agreement among all stakeholders about what these concepts represent.

It is true that best practices suggest writing down the preliminary scope statement and the project scope definition. We also know that all scope changes must be registered in the corresponding log and that before approval the team should do a risk analysis and review the impact on the schedule, cost, resources, etc. But again these documents make reference to concepts that are difficult to assess whether the team has not previously agreed.

Stakeholders feelings and perceptions are rarely considered in the change control process. The system works or it doesn’t, it was completed on time or it wasn’t regardless of whether the deliverables acceptance document is signed or not.

An example (fictional) helps to clarify the idea. Lets consider project X, whose deliverable was the payroll system of company Y. It should allow make payments to 300 employees. The schedule states 3 months of development, but in the middle of the project government issues a new regulation that impacts the system.

The team made an extra effort in spite of which the project still ended 2 weeks late and with 17% additional cost.

The team is tired but satisfied. The customer is happy because even though the schedule was not met, the system still meets regulations. In contrast, middle management in your company does not seem very happy because even though the customer is satisfied the profit margin was reduced.

Is this a successful project?

We can not give a categorically right answer to this. It is necessary to measure earned value (or the valuation method you prefer) to see if the relationship between the change in scope, cost and work is positive or negative. On the other hand, two of the three groups of stakeholders are happy, so it should not be classed as unsuccessful.

This situation of uncertainty can be resolved from the beginning if all stakeholders agree under what conditions a project would be deemed successful when it is finished.

Following this idea, stakeholders can agree that "the payroll system project shall be terminated when it meets the following list of features ...".

We agree with all stakeholders that the project is successful if "at the end of scheduled time (including extensions and reductions agreed), the system is able to make payments on a payroll of 300 employees and respects all applicable regulations."

As I said, it seems almost a matter of common sense, but is not always done.

And while that may seem complicated, without much extra effort you can prevent your team from not knowing when the project ends. When the project is actually finished it is easier to understand whether it has been successful.

The idea of writing this post came from teaching Project Management classes at ITESM and from #PMChat.

Thanks to Lindsay Scott for the review and suggestions to the english translation of this post.

¿Cuál es la importancia del caso de negocio para el proyecto?

noreply@blogger.com (Iván Rivera, PMP) — Fri, 30 Sep 2011 15:00:00 +0000

Desde projectsmart me permito revisar varios artículos que hablan de la importancia del caso de negocio para el desarrollo del proyecto.

Primero John Moore nos indica que la elaboración de un caso de negocio es fundamental para el éxito del proyecto:

Con frecuencia, si los proyectos no pueden entregar los resultados esperados, las conversaciones posteriores se convierten en acusatorias. El gerente de división despliega datos negativos mientras el jefe del departamento responsable del proyecto aclara que se hizo todo lo que se había programado.

El problema es que ambos tienen razón. Pero incluso cuando todo el mundo haya hecho todo lo posible, los resultados son decepcionantes, y comienza una segunda fase de investigación: ¿las expectativas de la empresa fueron demasiado altas?, ¿el alcance original del proyecto fue evaluado correctamente? Y que la competencia desarrollara un producto equivalente, ¿fue un riesgo identificado ya sea en el inicio del proyecto o durante su ejecución? Si es así, los interesados ¿fueron conscientes del riesgo potencial y que medidas podrían tomarse para mitigarlo? O ¿se decidió el equipo estaba ahí sólo para entregar un producto y no manejar eventos externos?

Aplicando el Caso de Negocio

Preguntas como las anteriores se suelen hacer una vez concluido el proyecto. Por desgracia, en ese punto es demasiado tarde para reparar el daño. Es por eso que los equipos de proyecto exitosos se toman el tiempo para examinar cuestiones como la construcción de un modelo de negocio sólido al inicio de cada proyecto. Esto permite a un equipo hacer frente a los riesgos potenciales y establecer estrategias alternativas mientras que proporciona una herramienta para establecer las variables futuras de todo el proyecto.

Una vez que el modelo de negocio se ha desarrollado, se aplica en cuatro fases críticas del ciclo de vida del proyecto con el fin de asegurar que el este, una vez terminado, dará el retorno de la inversión que se había pronosticado originalmente.

Un caso de negocio eficaz puede contribuir enormemente al éxito de un proyecto durante estas cuatro fases críticas de su ciclo de vida:

Primera fase: definición del proyecto

En primer lugar, antes de empezar el desarrollo del proyecto, el Caso de Negocio pregunta y responde a los "por qué" del mismo, documentando la justificación de la iniciativa y la definición de “éxito”. Mientras se recaban e incorporan las estimaciones de costos, los interesados deben identificar los beneficios esperados del proyecto en términos mensurables que permitirán a la organización determinar si el proyecto fue (o no) un éxito. Estos mismos costos estimados y los beneficios esperados también crean una base contra la cual los riesgos previstos o incertidumbres (tales como la posible liberación de productos de la competencia), se pueden medir. Cuando se recaba información también se deben incluir colaboradores externos, como el personal del departamento de finanzas, ya que pueden proporcionar información clave para la previsión de rentabilidad del proyecto.

Incluso en esta primera etapa, no es raro que los interesados impugnen la validez de los datos de entrada del caso, especialmente si no les gusta lo que escuchan. Durante este proceso de recopilación de información, todos los involucrados deben estar dispuestos a desafiar las expectativas de la empresa en relación con el costo y el tiempo. Este es también el momento adecuado para desarrollar alternativas, cada una con su costo, estimación de tiempo, y riesgos identificados. Esto proporcionará un criterio con el que se puede medir el proyecto y potencialmente sugerir mejores soluciones.

Fase dos: La decisión de ejecutar o no

Después de que se ha recabado información, la empresa debe tomar la decisión de seguir adelante con el proyecto o no. Si el proyecto se ejecuta, el modelo de negocio se utilizará como base para la toma de decisiones durante la vida del proyecto.

Estas son preguntas clave sobre el caso de negocio en este punto crítico:

¿Es clara la necesidad de negocio y está alineada con la estrategia de la organización?
¿Han sido identificados claramente los beneficios?
¿Está claro lo que va a definir el éxito?
¿Está claramente establecida la opción preferida?
¿Se presentan alternativas?
¿Está claro cómo se obtendrán los fondos necesarios?
¿Son claros los riesgos y los planes para enfrentarlos?

Sin embargo, incluso después de iniciarse el proyecto, el modelo de negocio todavía sirve para revisar la decisión de continuar o no, validando si las condiciones iniciales han cambiado.

Fase tres: Los cambios ocurren

Después de que el modelo de negocio ha sido escrito y aprobado, debe ser revisado con frecuencia. A medida que el proyecto avanza, el ambiente externo del proyecto puede cambiar, los riesgos potenciales pueden convertirse en realidad, pueden identificarse nuevos riesgos y nuevas decisiones de negocio pueden impactar directamente al proyecto. En algunos casos, la justificación inicial para el proyecto desaparece. En consecuencia, el modelo de negocio tiene que ser re-examinado continuamente a medida que el contenido (sobre todo los beneficios proyectados) se ven afectados. También es fundamental que todos los actores involucrados en la recopilación de la información inicial mantengan actualizado el caso a través de su ciclo de vida, especialmente cuando los cambios ocurren.

Cuarta Fase: Cierre del proyecto

Cuando el proyecto esté terminado, debe compararse contra la última versión del caso de negocio. Sólo mediante la comparación de los resultados del proyecto contra la justificación del mismo se puede determinar su grado de éxito. Sin embargo, es importante recordar que, mientras que el proyecto puede ser evaluado inmediatamente después de terminar, muchos beneficios sólo podrán observarse después de que la solución haya estado en operación durante un periodo de tiempo.

Finalmente, la construcción de un modelo de negocio antes de comenzar cualquier proyecto es una cuestión de sentido común: no es suficiente hacer algo bien, primero hay que saber por qué se está haciendo.

En otro artículo Carole Embden-Peterson nos menciona los fundamentos de la preparación de un caso de negocio. Primero nos recuerda el cambio es una perspectiva desafiante, especialmente cuando está orientado a mejorar las operaciones de negocio. Hay mucho en juego y los proponentes de proyectos deben asegurar el involucramiento de las partes interesadas a fin de lograr un cambio eficaz en el negocio. Sin embargo, los interesados desean tener todo muy claro. El primer documento que quieren ver antes de dar su aprobación, es el caso de negocio.

El caso de negocio es, por lo tanto, un documento muy poderoso y crucial que se utilizará para comunicar y persuadir al grupo clave de personas, los interesados. Se trata de un argumento lógico que explica de manera clara por qué debe ser apoyado un proyecto.

Este documento muestra las consecuencias (financieras y de todo tipo) de tomar una acción u otra. Le da soporte a:

La Planificación
La Toma de Decisiones
La Selección de proveedores
La Implementación

Un caso de negocio efectivo indica:

Las consecuencias esperadas de la acción sobre el flujo de efectivo con el paso del tiempo.
Los métodos y fundamentos utilizados para cuantificar los beneficios y costos.
El impacto global de la propuesta en términos de flujo de caja descontado, plazo de amortización y la tasa interna de retorno.

Para producir un buen caso este debe ser:

Completo (asegúrese de que ha investigado todos los posibles impactos, costos y beneficios).
Claro y lógico en su presentación (escriba claramente la cadena de causa y efecto que lleva a cada impacto de costo / beneficio).
Objetivo (asegúrese de que los temas buenos y malos se incluyen en el producto terminado).
Sistemático (es importante que ser coherente y metódico en la presentación de las conclusiones y el resumen).

Primeros pasos

Escribir un caso de negocio no es un esfuerzo de una sola persona. Es un esfuerzo de equipo, por lo que se debe reunir al equipo para iniciar el trabajo. Mientras que una o dos personas pueden escribirlo, por lo general se necesita un equipo completo para proporcionar la información requerida. El equipo puede proporcionar información durante un período de alrededor de 4 a 5 reuniones.

Cómo funciona el equipo

Hay muchas ventajas de tener un equipo detrás de su esfuerzo. Por ejemplo el equipo:

Ayuda con información sobre los modelos de costos y beneficio.
Difunde un sentido de propiedad para el caso de negocio. Después de todo, ellos están involucrados.
Actúan como amortiguador contra los críticos de la propuesta.

Administradores de TI: Proporcionan información sobre el costo y el valor del impacto en las operaciones de TI.

Expertos financieros: Proporcionan información útil para estimar las contribuciones a los beneficios de negocio esperados.

Personal de Recursos Humanos: Identifica los costos de personal.

Altos Directivos: Ayudan en la priorización, la legitimación y la asignación de valor a cualquier contribución con los objetivos de la empresa de negocios estratégicos.

Estructura y contenido

No existe un modelo establecido para la escritura de un caso de negocio, sin embargo hay algunas secciones que deben incluirse para garantizar una buena propuesta.

En su artículo: “El núcleo de un caso de negocio”, Carole Embden-Peterson nos sugiere una estructura para este documento:

La primera sección es la visión, que sienta las bases para el lector e incluye los antecedentes del proyecto, su historia o el contexto que le rodea. Referida por Carole, la “Guía de Business Case” de Marty J Schmidt señala que la introducción “posiciona” el caso, recordando o señalando a la audiencia cosas como:

Objetivos, necesidades o problemas que aborda el tema del caso. Por ejemplo, la necesidad de reducir los gastos de operación, los problemas en la satisfacción del cliente, la necesidad de capacidad de cómputo, la necesidad de mejorar las competencias profesionales de venta, etc.
Consideraciones de negocio que puedan facilitar la toma de decisiones, incluyendo factores externos, tales como factores internos como políticas o directivas de gestión.
Otros planes de negocio importantes relacionados. Por ejemplo, planes de negocio, presupuestos, planes de proyectos o programas especiales.
Información histórica importante. Por ejemplo, el "historial" de los anteriores análisis de casos de negocios sobre este tema.
Alternativas de acción. Cuando el caso se refiere a una acción propuesta que está compitiendo con otras propuestas, este es un buen lugar para esbozar brevemente las alternativas que se pueden comparar con estos resultados.

Luego se debe indicar la metodología, señalando al lector lo que se requiere para lograr la meta. En esta sección, por tanto, se deben esbozar las siguientes métricas financieras:

Flujo de efectivo
Tasa de rendimiento
Periodo de restitución
Retorno de las inversión
Costo de Propiedad

Supuestos

En el caso de negocio se deben hacer algunas suposiciones, para predecir los precios futuros, los salarios, y el volumen de negocios. Schmidt sugiere que se registren todas las suposiciones ya que no se puede dar por sentado que en cualquier otro análisis se harán las mismas suposiciones de forma automática.

Alcance y límites

Esta sección trata sobre las reglas del caso.

Duración: Registra la duración del análisis y como se calendarizará a lo largo del año.

Ubicación: Es el análisis específico de un lugar, región o localidad en particular.

Función: Examina el departamento u organización específica que cubre el caso.

Tecnología: Cualquier hardware o software, el motor eléctrico y de mantenimiento que cubre el análisis debe ser discutido en este segmento.

Costo / Beneficio

Los datos correspondientes a los costos y los beneficios se presentan en esta sección. La información de costos comprende por ejemplo, sueldos y el costo de programas informáticos. Los beneficios incluyen los incrementos en los márgenes de venta y ahorro en tiempo. Cuando se presentan datos de costo / beneficio, se pueden usar valores completos o valores incrementales dependiendo del propósito del caso de negocio.

Puede utilizar valores incrementales si:

La acción debe ser evaluada como una inversión.
Si la hipótesis no puede analizarse plenamente.
Hay diferentes fuentes de financiamiento para cubrir variaciones en los costos.

Puede utilizar los valores completos si:

La acción debe ser evaluada en términos de los costos totales o el coste total de propiedad.
Es posible analizar todos los escenarios.
Es necesario evaluar el impacto de una acción en términos de los presupuestos existentes o planeados.

Impacto en el Negocio

Esta es una sección crucial de su modelo de negocio. Es aquí donde el lector quiere ver la forma en la que la empresa se verá afectada económicamente. Esta sección debe mostrar tablas, gráficos y explicaciones, sin ningún dato subjetivo.

Además se puede presentar:

Flujo de Efectivo: Este debe incluir sólo las partidas que representan verdaderas entradas o salidas de efectivo.

Análisis de Resultados: Use tablas, gráficos y tablas al máximo.

Resultados no financieros: Estos no son cuantificables, pero deben darse a conocer de la manera más clara y explícita posible.

Riesgos y contingencias

Los casos de negocio deben comentar los riesgos e incertidumbres. Estos deben ser registrados y evaluados de acuerdo al posible impacto que podrían tener en la empresa. En esta sección también se presenta el peor escenario y se analiza el impacto de fuerzas externas o situaciones tales como cambios de precios, la inflación y cambios en la economía.

También se vinculan los objetivos del caso y las contribuciones de los diferentes departamentos. Se señala que la consecución del objetivo está supeditada a las contribuciones del departamento ABCD o persona XYZ. Llegar a la meta también podría estar supeditado a los servicios de un proveedor externo o contratista, y esto también debe ser explicado.

Conclusiones y recomendaciones

En esta sección se repasan todas las cuestiones planteadas en la introducción. El caso completo se reitera aquí vinculando los objetivos de negocio con los criterios de decisión importante y necesaria para lograr el objetivo. Resultados inesperados de su análisis y conclusiones que aún resulten poco claros también podrán aclararse en esta sección.

Finalmente se debe incluir la recomendación que emana del análisis. Schmidt recomienda que se concluya con una declaración de recomendación formal que debe recordar a la audiencia / lectores que ahora depende de ellos iniciar las acciones, por qué debe tomar una acción positiva y por qué esta se recomienda.

Para asegurarse de que su plan de negocio tiene un aspecto profesional debe incluir portada y hojas de resumen. La portada debe incluir: Título (que dar una pista acerca de la naturaleza general del modelo de negocio), nombre, empresa, dirección o departamento, número de teléfono, fecha de presentación.

La hoja de resumen debe incluir:

El objetivo o propósito del caso de negocio. Aquí el autor del caso detallará de forma explícita para que se utilizara el caso y cómo se va a utilizar.

Resumen ejecutivo. Este es un párrafo que explica el modelo de negocio en pocas palabras. Debe ser una narración con datos para apoyar la información presentada. Algunas personas sólo leen el resumen ejecutivo, por lo tanto es necesario asegurarse de que este sea claro, completo y cuidadosamente presentado.

La presentación es el último ingrediente para el éxito de su modelo de negocio. Hable con aplomo y exude confianza.

Como puede observarse, el caso de negocio es un elemento útil, no solo para justificar la existencia y el arranque del proyecto. Usado a lo largo de la ciclo de vida del mismo, ayuda a mantener el rumbo y a alcanzar el éxito.

Referencia

Schmidt, Marty, (2002) La Guía de Business Case. Rochester, Nueva York.

¿Vale la pena certificarse como PMP?

noreply@blogger.com (Iván Rivera, PMP) — Thu, 15 Sep 2011 15:00:00 +0000

Brian Crawford responde a esta pregunta en su blog:

Como PMP (Project Management Professional) es frecuente escuchar una pregunta que todos los administradores de proyecto se han planteado en algún momento de sus carreras... ¿Vale la pena certificarse como PMP?

Pasar por el proceso de tomar el temido examen de certificación como PMP es costoso y complicado, y requiere un gran esfuerzo de preparación. ¿Vale la pena el esfuerzo para obtener la certificación?

El autor revisa algunos de los pros y los contras de la certificación PMP. Si bien sus opiniones son personales, son en su mayoría compartidas por el traductor.

La Certificación como PMP puede reforzar un CV, y puede hacer la diferencia entre conseguir un trabajo como gerente de proyectos y de ser pasado por alto en favor de otra persona (una persona que probablemente que sea PMP certificado). Lo que es más, muchos empleadores exigen la certificación PMP de sus gerentes de proyecto. Tener la credencial sin duda hará que sea más fácil encontrar un trabajo como gerente de proyecto o de programa.

Con el fin de aplicar para tomar el examen PMP es necesario haber alcanzado un cierto grado de experiencia en proyectos: 60 meses (7.500 horas) de experiencia si no se cuenta con título universitario, y 36 meses (4.500 horas) de experiencia si tiene una licenciatura. El PMI (Project Management Institute) tiene un proceso de auditoría para asegurar que los PMP potenciales están diciendo la verdad acerca de su experiencia en proyectos.

Usar la designación "PMP" después del nombre en la firma de correo electrónico da cierta credibilidad inicial cuando se conocen nuevos contactos (sólo los que ya saben lo que significa PMP).

(Además, es claro que el contar con la certificación no garantiza que una persona sea capaz de administrar un proyecto en forma exitosa. Sin embargo cómo se señala más delante y como se ha destacado en otro post, si muestra que la persona tiene el compromiso con la profesión de Administración de Proyectos, que conoce la terminología, las herramientas, los procesos y que ha sido capaz de enfrentar con éxito un proyecto personal de la magnitud que se describe).

El autor señala que tener la certificación PMP puedes ayudarle a conseguir un sueldo más alto en comparación con los gerentes de proyectos que no están certificados. Es más, una encuesta indica que el PMP es la más alta pagada certificación (por lo menos a partir de 2008). Más buenas noticias: una segunda encuesta indica que los salarios PMP siguen aumentando.

Las ofertas para líderes certificados (para cualquier área de ingeniería) en los EUA oscilan entre $40.00 y $100.00 US Dlls. la hora. Los escalones más altos son ofrecidos a consultores especializados, con muchos años de experiencia, o bien a líderes de oficinas grandes de proyectos.

Adicionalmente, el PMI® mantiene una base de datos con los resultados de su encuesta de 2005 sobre sueldos a personal de manejo de proyectos. Esta base, sin embargo, es accesible únicamente a miembros del PMI®.

Hago un paréntesis en el artículo original para citar ahora el artículo: "¿Qué sueldos están ofreciendo a líderes certificados?" de LiderDeProyecto que menciona:

...la oferta más baja: $20,000.00 Mx Pesos mensuales (aprox. $11.35 US Dlls la hora). No nos ha sido posible determinar si quienes hayan solicitado un PMP® hayan podido obtenerlo por este salario.

La oferta más alta: $65,000.00 Mx Pesos mensuales (aprox. $45.45 US Dlls la hora). Para este nivel, sin embargo, se requiere un alto nivel de experiencia en proyectos grandes (con más de 25 analistas y programadores).

Es seguro que existen ofertas más altas, pero es raro que los montos aparezcan anunciados: en México, generalmente, las ofertas superiores a $40,000.00 Mx Pesos mensuales se manejan a nivel confidencial o semi confidencial (es decir, sólo se transmiten directamente entre los interesados).

La media de las ofertas para líderes certificados, con experiencia en proyectos pequeños y medianos (5 a 20 analistas y programadores), oscila alrededor de los $35,000.00 Mx Pesos mensuales (alrededor de $20.00 US Dlls la hora)...

De nuevo en el primer artículo, el autor destaca otras ventajas de la certificación: Se puede tener contacto con todos los PMPs del mundo. (357 770 en todo el mundo de acuerdo a las estadísticas del propio PMO a Agosto de 2011). Se puede participar en las reuniones periódicas en las que se organizan aprender acerca de la teoría de gestión de proyectos, hacer networking y obtener PDUs necesarios para renovar la certificación cada tres años.

Brian considera que la metodología del PMI resulta ya un poco anticuada, y que los procesos del PMI parecen adaptarse mejor a proyectos que utilizan el método de desarrollo en cascada, que no es tan popular en estos días. Señala que el desarrollo iterativo se está imponiendo rápidamente, y me parece que el desarrollo ágil con Scrum es una metodología sólida que ayuda a mantener los proyectos en marcha.

De hecho, el PMI ya lanzó un piloto de la certificación como PMI-Agile Certified Practitioner (PMI-ACP).

El autor se inclina a pensar que los Gerentes de Proyecto certificados como PMP son mejores que aquellos que no están certificados, en general, debido al hecho de que los certificados entienden la importancia de la credencial y han dedicado tiempo y esfuerzo a obtenerla.

Brian considera que vale la pena obtener la certificación como PMP. Le ha ayudado a ser contratado para trabajos de gestión de proyectos, y continuará haciéndolo a lo largo de su carrera. Le ha ayudado a conocer a mucha gente interesada en el campo de la gestión de proyectos mediante la participación en las actividades y eventos del PMI, y le ha permitido aprender más sobre la doctrina de la gestión de proyectos. Poner la denominación PMP después del nombre en la firma de correo electrónico le ha dado cierta credibilidad adicional al tratar con los clientes, y también ha suscitado debates sobre la gestión de proyectos con sus compañeros.

Como usar la EDT en el control de riesgos del proyecto

noreply@blogger.com (Iván Rivera, PMP) — Tue, 30 Aug 2011 15:00:00 +0000

Siguiendo con los artículos sobre el uso de la Estructura Detallada de Trabajo (EDT) en los proyectos, Glen B. Alleman nos sugiere en un artículo de su blog algunas ideas para usarla EDT en el control de riesgos.

El artículo se titula: "Connecting Risk and the WBS". En él, Glen señala que en ocasiones la administración del riesgo no se maneja en el contexto adecuado y propone ideas para usarla en la administración y control de riesgos del proyecto:

1. La medición del porcentaje completado para cada "paquete de trabajo" debe ser definida de manera que realmente mida el porcentaje físico completado.

2. Para calcular el valor ganado se deben definir los "elementos de costo", sus relaciones y sus entregables.

3. Debe existir un proceso de administración del riesgo. Más importante aún, debe aplicarse.

4. Se debe determinar la Ruta Crítica del Proyecto

5. Se deben establecer Medidas de Rendimiento Técnico - ¿Cómo miden los interesados (comprador y vendedor) el progreso del proyecto?

6. ¿Se tienen procesos que agreguen valor al proyecto?

7. Se deben controlar las asignaciones de personal - ¿Donde está la gente que necesita?

8. Horas extras - ¿El equipo esta sobre trabajado? ¿Como se establece lo que significa sobretrabajado?

9. Hay una estimación clara de la conclusión - ¿se tiene alguna idea de lo que el proyecto costará cuando se haya terminado? ¿Se tiene determinado con claridad cuando acaba el proyecto?

Debemos aprovechar la EDT para responder estas preguntas en forma precisa, esto debe ayudar a mantener controlados los riesgos de nuestros proyectos.

Como manejar el estrés en los proyectos. Algunas ideas rápidas

noreply@blogger.com (Iván Rivera, PMP) — Fri, 19 Aug 2011 16:16:00 +0000

Oscar Ceceña escribe una interesante entrada en su blog Palabras necias para oídos sordos: "Una mala manera de despertar" en el que nos platica sobre como se puede volver estresante la vida de un administrador de proyectos.

Para Oscar y todos los administradores que nos encontramos en situaciones similares, justo acabo de encontrar un artículo con ideas sobre como manejar el estres en los proyectos.

Es de Simon Cleveland y se encuentra en dos partes aquí y aquí.

Espero que le sirva a Oscar y a todos.

¿Hay futuro para la administración de proyectos en la metodología ágil?

noreply@blogger.com (Iván Rivera, PMP) — Mon, 15 Aug 2011 15:00:00 +0000

El pasado mes de junio escuche un webcast de Michele Sliger en el que comparte su opinión sobre el futuro de la administración de proyectos dentro de las metodologías ágiles, organizado por la AGILE COMMUNITY OF PRACTICE del PMI.

Antes de compartir mis notas, un poco de información necesaria. Wikipedia define:

"El desarrollo ágil de software es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto".

Mas de la definición de wikipedia:

"Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica."

Referido en esa introducción, hay un artículo introductorio acerca de metodologías ágiles, cuyos autores Ricardo Colusso y Juan Gabardini nos dicen:

... "los proyectos de desarrollo de software en la actualidad incluyen desafíos muy diferentes a los que se presentan al construir puentes y casas, por lo que no sorprende que los métodos tradicionales de desarrollo de software estén en crisis".

Siguen los autores: (La) "forma (actual) de desarrollar software - dividiendo el proceso en etapas diferenciadas: Análisis de Factibilidad, Análisis de Requerimientos, Diseño, Programación, y Pruebas- genera muy serios problemas, debido a que al comienzo del proyecto, que es cuando menos se conocen las características del problema que resolver, se toman las decisiones de mayor relevancia e impacto en el resto del proyecto".

Para solventar estos problemas, un grupo de expertos propusieron el "Manifiesto por el Desarrollo Ágil de Software". De este último se destaca que se le debe dar más valor a los Individuos e interacciones sobre procesos y herramientas, Software funcionando sobre documentación extensiva, Colaboración con el cliente sobre negociación contractual, Respuesta ante el cambio sobre seguir un plan.

Estas declaraciones pueden ser duras desde la visión del Administrador de Proyectos.

Como en otros casos, no voy a entrar en los detalles sobre la metodología, sino en la conjunción entre Administración de Proyectos y los métodos ágiles.

Pat Gray da una explicación de los principios Agiles en este artículo (Agile development principles explained) y diferentes autores comentan sobre la administración de proyectos en este entorno:

Bruce Lofland en "Can Project Management be Agile?" y "Does Agile Project Management Exist?"), Pete Deemer en "MANAGER 2.0: THE ROLE OF THE MANAGER IN SCRUM", Lyssa Adkins y Michael Spayd en "The Manager's Role in Agile", y Roger Brown

en dos artículos "Where Does a Project Manager Fit in Scrum? parte 1" y "parte 2" dan sus argumentos a favor, y debe haber cientos o miles de artículos en contra.

Yo me voy a centrar en algunas notas que tomé de la presentación de Michele:

Es necesario el rol de "Líder al servicio del equipo", es decir un líder facilitador del trabajo del equipo. Es una persona que elige servir primero y luego dirigir.

Atendiendo primero las necesidades del equipo
Consiguiendo para el equipo la libertad para que puedan hacer el mejor trabajo que puedan
Persiguiendo el crecimiento personal de los miembros del equipo
Enseñando a futuros líderes al servicio del equipo

Este líder debe cambiar la forma de pensar concentrándose en servir al equipo y no en utilizarlo. En trabajar en los temas realmente importantes para el proyecto y no en el apego al calendario y al presupuesto.
El líder debe enfocarse en mediar y negociar, siendo un guardián del proceso, un facilitador que consiga un ambiente óptimo para el equipo, protegiéndolo de distracciones y consiguiendo que la información fluya entre todos los interesados.
El líder debe resguardar la memoria del equipo, recordando la visión general y el propósito, así como las decisiones que se han tomado.
El líder debe resolver las dependencias externas, coordinarse con otros equipos para las liberaciones
El líder debe ser un Agente de Cambio Organizacional, compartiendo su conocimiento con otros.

Ya sea que este rol lo asuma también el scrum master o una persona diferente, a mi parece que todas son actividades que en otros ámbitos le corresponderían al Administrador de Proyectos.

Mi conclusión: Si, hay futuro para la administración de proyectos dentro de la metodología ágil.

La EDT (WBS) es una herramienta útil, cuando está bien hecha.

noreply@blogger.com (Iván Rivera, PMP) — Fri, 29 Jul 2011 15:00:00 +0000

En un segundo artículo, Bruce Lofland nos presenta en su blog PM Technix (del que comente algo la entrada previa -Como distinguir entre un riesgo o un problema-) sus notas sobre la utilidad de la EDT cuando está bien hecha.

La estructura de desglose de trabajo (EDT o Work Breakdown Structure - WBS) es una herramienta que se utiliza para describir el alcance de un proyecto en términos de sus entregables, divididos en piezas que son lo suficientemente pequeñas para planificar y trabajar fácilmente. Estas piezas se llaman paquetes de trabajo.

La EDT se crea al arranque del proyecto justo después que se aprueba el acta del proyecto y se conforma el equipo de trabajo. El equipo de trabajo debe crear la EDT en una reunión en la que debe estar presente la gente que realmente va a hacer el trabajo.

El nivel superior de la estructura es el producto final que se espera del proyecto.

El nivel siguiente es una lista de todos los entregables que figuran en el acta del proyecto y para conformarlo se sugiere que se consideren solo los sustantivos, no los verbos (por ejemplo, "base de datos", y no "convertir los datos"). En este nivel deben incluirse los entregables principales que existirán después de que el proyecto está terminado. Estos entregables principales deben describir el 100% del producto final.

En el tercer nivel se desglosan cada uno de los entregables principales, y sus componentes deben describir el 100% del entregable de segundo nivel.

Para desarrollar la EDT Bruce sugiere una actividad de grupo: el Administrador de proyectos debe poner el producto y los entregables en un pizarrón que todo el equipo del proyecto pueda ver a la vez. Luego debe señalar al primer entregable y preguntar: "¿En qué consiste esto?" y registrar las respuestas del equipo. El Administrador debe entonces pasar al siguiente entregable y repetir la pregunta.

Algunas respuestas implicarán dividir un entregable en elementos mas pequeños, mientras que otros no deberán dividirse, ya que son lo suficientemente pequeños.

Pero ¿qué es suficientemente pequeño?, ¿Cuando detener el proceso?

Cuando la persona encargada de producir un elemento comprende bien el trabajo necesario para elaborarlo y cuando es claro para todos en qué momento el elemento está terminado. Esta última parte es especialmente importante. Saber que "hacer" es vital para el éxito del proyecto.

Bruce nos ayuda a recordar que la EDT no es el cronograma del proyecto. No contiene tareas o fases. Esto un error común que reduce drásticamente el valor de la EDT, y ejemplifica su punto de vista. Bruce considera que el PMI, en la Guía para la Dirección de Proyectos de Conocimiento, 4 ª ed. (PMBOK) da un mal ejemplo de un EDT en el punto 5.3, figura 5.9. qué se muestra a continuación:

El problema que Bruce detecta (y cuya opinión comparto) es que se ha forzado que el EDT contenga el Ciclo de Vida de Desarrollo del Sistema (SDLC) que es un artefacto para desarrollar el cronograma, no un artefacto para establecer el alcance del proyecto.

Yo preparé un EDT simple para desarrollo de Software para explicar el punto:

Hay un entregable, "Software" que se divide en tres entregables mas pequeños: el producto del diseño (especificaciones), el producto del proceso de desarrollo (código fuente, ejecutables. librerías) y el producto de las pruebas.

Bruce presenta el ejemplo de una EDT simple para un blog:

1. Blog

1.1 Posts

1.1.1 Post Attributes (Author, Date, Content)

1.1.2 Facebook Like button

1.1.3 Tweet This button

1.1.4 Multi-Share (Facebook, Digg, Email, etc.)

1.1.5 Post Edit

1.1.6 Post Publish

1.2 Comments

1.2.1 Comment Moderation feature

1.2.2 Tracebacks

1.2.3 Author attributes (name, website)

1.2.4 Comment attributes (Date, Content)

1.2.5 Comment Edit

1.2.6 Comment Publish

1.3 Blogroll

1.4 Header

1.5 Archives

1.5.1 List by month and year

1.5.2 Post List

1.5.3 Select Post

1.6 Pages

1.6.1 About

1.6.2 Home

1.7 Search Blog

1.8 Follow Me button

1.9 Hosting Service

1.10 Domain Name

Una vez que se ha desarrollado la EDT, se puede utilizar para estimar y dar seguimiento a los costos, identificar las actividades en el cronograma del proyecto, identificar riesgos y controlar el alcance del proyecto.

Por último Bruce nos deja esta pregunta ¿Cómo se utiliza la EDT en su organización?

Referencias:

Lofland, Bruce . Ejemplo de EDT incorrecta. N.d. PM Technix. Web. 18 June 2011.

Artículo invitado: Tres formas de fracasar en la auditoria previa al examen de PMP

noreply@blogger.com (Iván Rivera, PMP) — Fri, 22 Jul 2011 15:00:00 +0000

Por Cornelius Fichtner, PMP – www.pm-podcast.com

La credencial Project Management Professional(PMP) ® del Project Management Institute ® (PMI) es una certificación sobre conocimientos de temas de gestión de proyectos, habilidades y experiencia reconocida a nivel mundial, por lo que no es de extrañar que el PMI ponga atención en asegurar la calidad de su proceso de certificación, desde la solicitud hasta la post certificación.

Cuando se hace la aplicación para obtener la Certificación como PMP, se va a presentar evidencia de la educación recibida y una cuantificación de la experiencia en administración de proyectos y las horas de capacitación en estos temas. Solo si se es aceptado, se puede presentar el examen PMP. Cuando se aprueba, uno es agregado a la lista de administradores de proyectos profesionales certificados por el PMI con todos los privilegios que esto representa.

Esto es con la idea de que todos los profesionales certificados por el PMI estén seguros de que su credencial, tan dura de obtener, mantendrá su valor e integridad año tras año. El PMI toma esta responsabilidad muy en serio, y una de las formas que tiene para asegurar la integridad de la certificación es aplicando auditorías aleatorias tanto a los solicitantes como a PMPs certificados.

Su solicitud y eventualmente la credencial ya obtenida pueden ser auditados en cualquier momento. , y a pesar de que hay muchos rumores acerca de los criterios de selección de auditorías del PMI, la verdad es que el proceso de selección es completamente al azar.

Así que no se recomienda tratar de encajar en el perfil (realmente inexistente) de alguien que va a ser auditado, es mejor asegurarse de que desde el principio la información proporcionada y las acciones emprendidas puedan aprobar una eventual auditoría. El autor nos sugiere una manera positiva y proactiva para abordar la aplicación como PMP. :

Sus posibilidades de ser objeto de auditoria:

Durante el proceso de aplicación de las probabilidades de ser auditado son de aproximadamente 50/50 y caen bruscamente después de obtener la certificación. Dado que el proceso de selección de auditoria para interesados en aplicar el examen de PMP es completamente aleatorio, no se debe perder tiempo escuchando y preocupándose por los rumores de perfiles o características disparadoras. Es mejor utilizar la energía para estudiar adecuadamente para el examen tomándose el tiempo para hacer la aplicación a prueba de auditorías.

Ser veraz significa que usted no tendrá que recordar detalles:

El PMI toma muy en serio su código de ética, por lo que los aspirantes deben hacerlo también, así que mientras más tiempo le tome asegurarse de que su solicitud refleja con exactitud su experiencia, mejor podrá soportar una auditoria.

Documentar, comunicar, alinear:

Tómese tiempo para documentar de forma clara su experiencia. Asegúrese de saber dónde guardó su título, los certificados de capacitación, fechas, documentación, nombres, direcciones y números de teléfono de sus proyectos. Mejor aún, cree una nueva carpeta de proyecto con toda la información de respaldo que apoye su solicitud.

Cuando se envía la declaración de experiencia en Administración de Proyectos, el PMI pedirá proporcionar nombres de contactos para cada proyecto. Asegúrese de confirmar la dirección de correo electrónico y teléfonos actuales. Estas personas de contacto podrían ser sus gerentes, compañeros de trabajo, proveedores, clientes y otras personas involucradas en los proyectos declarados. Hágales saber que usted está aplicando para tomar el examen de PMP. Recuérdeles los proyectos, comparta con ellos lo que va a enviar y pregúnteles si están de acuerdo con lo que se ha escrito. Corrija cuando se lo soliciten.

Las tres formas de fracasar una auditoria del examen de PMP:

De acuerdo con el área de Atención al Cliente del PMI, hay tres formas en que puede fallar una auditoria: Ausencia de culpa, incumplimiento y fraude. En primer lugar vamos a ver lo que escribe PMI para cada una de ellas, y veamos la interpretación y recomendaciones que propone Cornelius.

1.) Ausencia de culpa

"No se puede verificar la educación o la experiencia, sin haber fallado - No hay periodo de suspensión y no puede volver a aplicar hasta que el candidato pueda proporcionar y documentar las horas de experiencia."

Usted debe ser capaz de evitar esto asegurándose de tener todos sus documentos antes de presentar su solicitud de examen de PMP. Sin embargo, si por alguna razón ajena a usted su educación o experiencia no se puede confirmar, el PMI declarará la auditoria como fallada. Usted podrá volver a aplicar tan pronto como pueda documentar las horas de experiencia o la confirmación de su grado.

2.) Incumplimiento

"El candidato decidió no presentar la auditoria - Aplica un período de suspensión de un año"

Usted puede optar por no dar respuesta a la auditoria. Esto es similar a declararse "no contendiente", y lo dejará sujeto a un período de suspensión de un año antes de poder aplicar de nuevo para el examen de PMP.

3.) Fraude.

"Proporcionar información falsa - suspendido permanentemente de aplicar para los exámenes de PMI".

Esto debería ser obvio... ¡No se debe mentir! ¡No vale la pena! Cuando se proporciona información falsa en la solicitud y por ello se falla la auditoria, se pierde permanentemente la oportunidad de aplicar cualquier examen del PMI. Y realmente quiere decir para siempre.

Si usted está preocupado acerca de no tener suficientes horas de contacto, considere la posibilidad de retrasar su aplicación hasta que las consiga. Si usted está buscando proyectos para llenar esas horas, hay un montón de oportunidades de voluntariado a través de la gestión de proyectos de servicio comunitario y otras organizaciones sin fines de lucro.

Si usted necesita una certificación de un plazo determinado y no tiene mucha experiencia, considere aplicar como Asociado Certificado en Gestión de Proyectos (CAPM)® mientras acumula las horas que necesita para la certificación como PMP. Una certificación CAPM requiere sólo el certificado de bachillerato (o equivalente) y 23 horas de educación en gestión de proyectos o 1,500 horas de experiencia.

A pesar de que el PMI puede optar por cambiar el proceso de auditoría en cualquier momento, si es auditado, se le pedirá proporcionar copias de sus diplomas, o sus equivalentes, las firmas de las personas que puedan verificar su experiencia (como gerentes y supervisores), copias de certificados y / o cartas de las instituciones de formación para cada curso de educación que esté declarando.

El proceso de auditoria previo al examen de PMP es un contratiempo, pero no una barrera en el camino de obtener la certificación. Ponga cuidado en la preparación previa y podrá sobrellevarlo con éxito.

Como nota final puedo decir que yo mismo pasé por un proceso de auditoría cuando aplique para el examen de certificación a finales de 2005.

Y como anécdota puedo decir que la parte mas larga del proceso fue el tiempo que tardé en reunir los documentos y luego el tiempo que estos tardaron en llegar al PMI.

Ideas para crear un entorno adecuado para nuestros proyectos

noreply@blogger.com (Iván Rivera, PMP) — Fri, 15 Jul 2011 15:00:00 +0000

Desde PM Hut, Ty Kiisel nos sugiere algunas ideas para crear un entorno adecuado para nuestros proyectos.

Ty empieza indicando que los entornos adecuados para ejecutar nuestros proyectos no ocurren en forma espontánea. De hecho, no hacer nada más que implementar una solución de colaboración u otra herramienta de administración de proyectos no es la respuesta. Implementar una herramienta de apoyo es solo el primer paso, sólo el primer paso. Ty sugiere además:

Motive al equipo del proyecto a participar en la elaboración de los planes y el diseño de los resultados finales: El comportamiento motivador es sano y crea un entorno sinérgico. Crear un ambiente en el que los miembros del equipo consideren su actividad como algo más que "sólo un trabajo" implica algo más que palabras, se requiere darles la oportunidad de contribuir a un nivel superior en la toma de decisiones y darles posesión de sus resultados.

Fomente un ambiente de solución de problemas desde la raíz: El administrador de proyectos no es el único miembro del equipo con la capacidad de identificar y resolver problemas. Dado que los proyectos suelen ser imprevisibles y a menudo se presentan numerosos desafíos, Ty considera importante fomentar un ambiente donde los miembros individuales del equipo libremente puedan ofrecer soluciones a los problemas identificados.

Pero además la gerencia debe estar comprometida con este esquema; un equipo del proyecto motivado debe tener el soporte de la gerencia por que si no las decisiones que tome estarán condenadas al fracaso.

La productividad a largo plazo es el resultado de equipos de proyectos comprometidos y motivados que están comprometidos a dar el 110%. No puede vencer (ni comprar) a ese nivel de dedicación del equipo.

10 Razones por las que Harry Potter es un gran líder

noreply@blogger.com (Iván Rivera, PMP) — Wed, 13 Jul 2011 23:01:00 +0000

Mitch Mitchell lista en Mitch's Blog, las 10 Razones por las que considera a Harry Potter como un gran líder

1. Escogía bien a sus amigos.

2. Prestaba atención a lo que pasa a su alrededor.

3. Aprendió a usar los talentos de la gente que le rodea para el bien común.

4. Era valiente.

5. Trataba a todos con justicia.

6. Aún dentro de una competencia, hacía lo correcto.

7. Cuando llegó el momento de educar a los demás por el bien común, encaró el desafío a pesar de que no tenía ningún conocimiento previo de cómo hacerlo.

8. Él siempre sabía cuándo era el momento de ceder y dejar el lugar a un líder mejor.

9. Tenía la habilidad de conseguir que los demás le ayudaran a conseguir las cosas, incluso sin pedir ayuda en forma expresa.

10. Estaba dispuesto a dar su vida para proteger de los demás.

Interesante punto de vista. Toda proporción guardada, algunos Administradores de Proyecto podrían aprender algo de Harry Potter.

Referencia: Mitchell, T. T. (n.d.). 10 Reasons Harry Potter Is A Great Leader | Mitch's Blog. T T Mitchell Consulting, Inc. Retrieved July 13, 2011, from http://www.ttmitchellconsulting.com/Mitchblog/10-reasons-harry-potter-is-a-great-leader/

Consejos para dirigir proyectos pequeños

noreply@blogger.com (Iván Rivera, PMP) — Thu, 30 Jun 2011 15:00:00 +0000

Desde ProjectSmart; Simon Buehring nos propone en el siguiente artículo algunas sugerencias para administrar proyectos pequeños.

El autor empieza señalando la importancia de definir si las mejores prácticas de la gestión de proyectos que son aplicables para los grandes proyectos se pueden aplicar en proyectos más pequeños y hace algunas recomendaciones:

Centrarse en la entrega del proyecto.

Uno de los argumentos en contra del uso de metodologías de gestión de proyectos es que están muy centradas en el proceso, lo que resulta en una cantidad de documentos del proyecto que simplemente no es práctica o deseable en proyectos pequeños. Este es un argumento poderoso y cualquier método que se centre en generar documentación a expensas de la entrega de los beneficios reales de negocio del proyecto será un obstáculo en lugar de un beneficio. Después de todo, la idea detrás de la gestión de proyectos es la entrega de los objetivos de negocio, no producir montones de documentos.

Hay un debate dentro de la comunidad de desarrollo de software sobre la mejor manera de producir software en proyectos. Recientemente algunos profesionales de software han argumentado a favor de métodos más ágiles para producir software en lugar de los pesados métodos tradicionales que se centran en la producción de grandes cantidades de documentación.

Los métodos ágiles se centran en la entrega de software en lugar de generar documentación. Con esto en mente, el autor sugiere que los directores de proyectos pueden aprender algo de los métodos ágiles empleados en el desarrollo de software. En resumen: centrarse en la ejecución del proyecto en lugar de generar documentación. Pero la pregunta crucial sigue siendo ¿cuánta documentación que es realmente necesaria?

Aplicar las mejores prácticas

Simon recomienda solo producir la documentación requerida por el proyecto. Nada más y nada menos. Una simple regla de oro es: si el documento es útil para ayudarnos a conseguir los objetivos de negocio del proyecto, entonces genérelo. Si el documento no es útil para ayudarnos a conseguir los objetivos de negocio del proyecto, no pierda el tiempo con él.

Definir Objetivos y Alcance

Incluso en los proyectos más pequeños habrá objetivos que se deben alcanzar. Como Administrador del proyecto, es de su interés definir estos objetivos ya que es probable que eventualmente se evalúe si el proyecto los cumple o no. Es su responsabilidad asegurar que el proyecto cumple con los objetivos.

Ahora suponga que no define ni registra cuáles son los objetivos del proyecto. Entonces siempre va a estar a merced de cualquier jefe que decidirá lo usted debe hacer. Un conjunto de objetivos definido y documentado es su póliza de seguro cuando alguien alegue que no se están cumpliendo los objetivos.

Sin embargo, hay otra razón por la que se tienen que definir y documentar los objetivos, incluso en un proyecto pequeño. Usted espera satisfacer las necesidades de los interesados, ya que es por lo que se le paga al administrador del proyecto. Si los objetivos no están definidos, entonces usted no será capaz de satisfacer esas necesidades.

Lo mismo ocurre con la definición del alcance. El alcance constituye el límite de su proyecto. Si no se define lo que es, lo más probable es que va a crecer y crecer conforme avanza el proyecto y aunque podría haber comenzado la gestión de un proyecto muy pequeño, en poco tiempo el proyecto podría llegar a ser mucho más grande que lo esperado.

Además usted necesita documentar quienes son los interesados (stakeholders) en un proyecto pequeño. Al definir quiénes son, puede asegurarse de que se cubren todas sus necesidades y expectativas.

Definir los entregables

Alguien va a tener que llevar a cabo el trabajo real necesario para producir el entregable del proyecto. Aun cuando los entregables puedan ser pequeños y no se tenga mucho tiempo para producirlos, deben ser descritos en forma apropiada. Documentar y revisar estas cosas permite detectar errores potenciales. Su objetivo debe ser documentar en forma suficientemente detallada las descripciones de los productos a ser entregados.

Estas descripciones serán utilizadas por la gente que produzca los resultados finales. Incluso si estas descripciones no requieren más de una página de texto, es importante escribirlas de manera clara e inequívoca. Si no se describe un entregable, la persona que lo genera puede interpretar lo que se requiere de manera inesperada, lo que más tarde se traducirá en retrabajo para corregir los errores. Por lo tanto, siempre hay que definir y documentar los entregables.

Planificar el Proyecto

Si considerara escalar el Monte Everest, nunca lo haría sin una cantidad considerable de planificación. Incluso si usted camina por la colina en la parte trasera de su casa, es probable que haya al menos un poco de planificación - ¿A qué hora es mejor hacerlo? ¿Qué debe llevar con usted? Lo mismo aplica incluso para el más mínimo proyecto: tendrá que averiguar qué actividades son necesarias para producir un entregable, estimar cuánto tiempo requieren las actividades, determinar la cantidad de personal y recursos necesarios y asignar actividades y responsabilidades al personal.

Todas estas cosas deben ser registradas por escrito y comunicarse efectivamente a los miembros del equipo de proyecto.

Además del diagrama de Gantt, usted necesitará documentar los hitos en el proyecto. Los hitos son las fechas en que tiene que entregar ciertas cosas, o puede ser la fecha en que termina una actividad importante. Las responsabilidades de cada miembro del proyecto también deben ser documentadas en el plan del proyecto.

Comunicación

Incluso en el equipo de proyecto más pequeño (integrado solo por el gerente de proyecto y otra persona), el administrador del proyecto aún tendrá que asignar tareas y responsabilidades a la otra persona. No se puede suponer que el equipo sabrá lo que debe hacer sin que sea efectivamente comunicado por el administrador del proyecto. Si el administrador del proyecto no les asigna actividades específicas, lo más probable es que van a seguir adelante y trabajar en cosas que no son necesarias para el proyecto. Así que el proyecto terminará con la entrega de las productos incorrectos, o se retrasará ya que se deberá gastar más tiempo en hacer las actividades que se deberían haberse hecho antes.

Puede comunicar los planes a través de correo electrónico, o dar una impresión del plan para cada uno de los miembros de su equipo, o mejor aún, convocar a una reunión y revisar el plan con los miembros del equipo de proyecto. Y recuerde, si cambia el plan, también tendrá que comunicar los cambios a su equipo.

Seguimiento y presentación de informes de progreso

Si seguimos considerando al equipo de proyecto de dos personas - el administrador del proyecto y otra persona - el administrador tendrá que conocer el progreso de las actividades que la otra persona está desarrollando. Esto se puede hacer en una variedad de formas: un breve correo electrónico a diario detallando el trabajo realizado, el trabajo que todavía queda por hacer, y una lista de todas las cuestiones y problemas. En la mayoría de los casos esto será suficiente.

Como alternativa, una reunión de unos 15 minutos puede lograr lo mismo. O mejor una combinación de las dos cosas. En cualquier caso, el director del proyecto todavía tiene que estar plenamente consciente de los progresos para poder realizar un seguimiento eficaz.

Gestión del Cambio

Incluso en el proyecto de dos personas, es probable que ocurran cambios. Las solicitudes de cambio por lo general vienen de los interesados y es responsabilidad del administrador del proyecto evaluar el impacto de aceptarlas. Para ello, necesita una buena estimación del impacto que el cambio tendrá en términos de esfuerzo y costos involucrados. A menudo, esto afectará el calendario, así que mediante un claro entendimiento de cómo el programa y el presupuesto se verán afectados podrá tomar la decisión de aceptar o no el cambio en el proyecto.

En un proyecto pequeño no es necesario un comité de control de cambios para decidir si el cambio es aceptado. Una breve discusión con el (los) interesado(s) clave debería ser suficiente para que se pueda llegar a una decisión.

Una de las cosas que nunca se debe hacer es simplemente aceptar el cambio. Incluso si se piensa que el cambio es pequeño, nunca se debe aceptar sin entender completamente lo que su impacto sobre el costo y el programa. Esa es una receta de lo que llamamos "la corrupción del alcance", donde el proyecto se hace más grande y más grande conforme se aceptan más y más cambios al proyecto. Antes de poder notarlo, un pequeño proyecto se ha convertido en uno mucho más grande e inevitablemente, será imposible entregarlo según el presupuesto y programa originales.

Gestión de Riesgos

Habrá riesgos, incluso en un pequeño proyecto. Hay que asegurarse de que se han considerado todos los riesgos potenciales en el inicio del proyecto, y cada semana se debe dar seguimiento a los diez riesgos principales y seguir identificando los nuevos riesgos. La falta de gestión de riesgos adecuada es una de las causas principales de fracaso de los proyectos.

La sobrecarga en la gestión de riesgos es muy baja. Una técnica sugerida considera elaborar una lista de lo todos los riesgos identificados en el proyecto. De estos, elaborar un plan para evitar o minimizar cada uno de los riesgos severos. Luego, cada semana, dedicar 30 minutos a revisar todos los riesgos y pensar en otros nuevos.

Resumen

En resumen, la aplicación de las mejores prácticas incluso en un proyecto pequeño se puede hacer sin crear demasiado papeleo o sobrecarga. Las mejores prácticas son las cosas que un sinnúmero de administradores han hecho en miles de proyectos y se consideran "mejores prácticas" por que tienden a ayudar a conseguir los mejores resultados.

A raíz de la publicación de este post, en twitter tuve una interesante charla con @fcartu que transcribo con su amable consentimiento:

@fcartu Francisco Cartusciel: Después d todo, la idea dtrás de la gestión de proyecto es la entrega d los objetivos d negocio, no producir montones de documentos

@irivera Ivan Rivera, PMP: Gracias por el comentario. Es un tema que a mi me toca vivir a diario. La clave es encontrar la cantidad precisa de documentos, que claramente es diferente entre organizaciones e incluso puede ser diferente entre proyectos... Saludos desde México

@fcartu Francisco Cartusciel: Interesante artículo, el problema esta cuando #Stakeholders valoran más la documentación que el producto final.
@fcartu Francisco Cartusciel: Actualmente tenemos un contrato AM en donde nos exigen alrededor de 10 documentos por proyecto y donde nos penalizan por no hacerlo

@irivera Ivan Rivera, PMP: Hay organizaciones que exigen hasta 30 documentos por proyecto... El tema se debe negociar entre los tres niveles de la organizacion: Directivo, Táctico y Operativo. Debe ser un tema negociado entre la Gerencia, la PMO y los Administradores

@fcartu Francisco Cartusciel: Es difícil hacerlos entender que la mitad de esos documentos no dan un valor al proyecto y más cuando la documentación entrega por el cliente es mal diligenciada y al final el proyecto es totalmente diferente a esa documentación inicial.

@irivera Ivan Rivera, PMP: Hay mucho trabajo desparovechado. Por eso es bueno que la metodología sea acordada, y se le presente al cliente al inicio del proyecto, para obtener sus comentarios sobre la misma. Al final entonces es un acuerdo entre cuatro partes: Cliente, Gerencia, PMO y Administrador, todos deben estar de acuerdo en la documentación que se va a manejar a lo largo del proyecto

Un poco de historia... “El Sistema Operativo MS-DOS 6”

noreply@blogger.com (Iván Rivera, PMP) — Thu, 16 Jun 2011 17:35:00 +0000

Hace 18 años escribí una reseña de la instalación y primeras impresiones sobre el (en ese momento "Totalmente nuevo") MS-DOS 6.

Por el tipo de trabajo que tenía entonces, pude empezar a usar el Sistema Operativo varias semanas antes de que llegara al mercado. Tomé notas y escribí el artículo.

Lo mandé a varias revistas y periódicos de TI de la época, entre ellos PC-Magazine en Español y PC Semanal, esperando que lo publicaran... Y no pasó nada.

Meses después, por accidente me enteré que si lo habían presentado, al menos estas dos publicaciones.

Acabo de rescatar una copia, y lo subí en este link.

Artículo que escribí en 1993: “El Sistema Operativo MS-DOS 6”.

PC-Magazine en Español. Vol. 4 No. 8. Agosto 1993 p.p. 75-76

articulo ms dos 6

Artículo invitado: Como empezar a tener el liderazgo de nuestros proyectos

noreply@blogger.com (Iván Rivera, PMP) — Wed, 15 Jun 2011 15:00:00 +0000

Por Cornelius Fichtner, PMP – www.pm-podcast.com

El liderazgo es importante para el éxito del proyecto, y los administradores de proyecto pueden asumir roles de liderazgo dentro de sus proyectos, mostrando integridad y dirección de sus equipos, según Tomás Juli y Rick Valegra, dos autores que recientemente han sido reseñados en The Project Management Podcast.

Ellos nos explican como empezar a tener el liderazgo de nuestros proyectos.

En mayo de 2011 The Project Management Podcast lanzó su serie sobre Liderazgo de Proyectos en www.pm-podcast.com. La serie comienza con entrevistas con Thomas Juli, autor de “Leadership Principles for Project Success”, y Rick Valerga, autor de “The Cure for the Common Project: Five Core Themes that Transform Project Managers into Leaders”. A lo largo del año se presentarán más entrevistas y debates sobre liderazgo del proyecto.

Vamos a empezar con una explicación acerca de lo que es el liderazgo del proyecto y cómo los administradores de proyectos pueden comenzar el camino de convertirse en verdaderos líderes de su proyecto.

Definición de liderazgo del proyecto

Thomas señala: "Hay muchas definiciones de liderazgo". "El liderazgo tiene que ver con la actitud correcta y la comprensión de los principios básicos de la construcción de una visión global, conocer el poder de la colaboración, saber promover el rendimiento en el equipo que se está dirigiendo, y tener la madurez para reflexionar sobre sus propias actividades y la creación de una cultura de aprendizaje. Y por último pero no menos importante, un líder se asegura de obtener los resultados esperados ya que esto justifica su existencia. "

Rick está de acuerdo. "Yo defino el liderazgo como la capacidad de influir en otros para lograr resultados", dijo. "El liderazgo del proyecto es el nexo entra la gestión de proyectos y el liderazgo general."

Tener el liderazgo del proyecto no significa ser un visionario de la futura estrategia y estar sentado en la cima de la organización. Se trata de dirigir el equipo de proyecto para alcanzar los objetivos y producir un resultado exitoso.

Cómo llegar al éxito

"Si se ejecuta un proyecto, se debe estar bien informado y tener experiencia en gestión de proyectos", dijo Thomas. "La gestión de proyectos es, básicamente, estructurar el caos. Sin estructura, realmente no se puede ser creativo. Eso significa que sin gestión de proyectos, no puede haber éxito en el proyecto. "

Sin embargo, Thomas no cree que las habilidades de gestión de proyectos son la única cosa necesaria para lograr un proyecto exitoso. "El liderazgo da al proyecto una dirección, la dirección correcta", dijo. "Cuando se habla de las condiciones suficientes para lograr el éxito del proyecto, se está hablando de liderazgo".

Sin alguien que proporcione esta dirección general, los miembros del equipo del proyecto corren el riesgo de ir en varias direcciones, o ninguna en absoluto. Es difícil lograr resultados en este contexto. Thomas cree que para llegar al éxito los proyectos necesitan tanto de la gestión como del liderazgo. Afortunadamente, una persona puede cubrir ambas funciones.

Liderazgo básico

"La integridad es la base absoluta de liderazgo de proyectos," dijo Rick. "Integridad significa no dejar que su proyecto viva una mentira. Así que si su plan de proyecto es un castillo de naipes, o su cronograma se retrasará, o si usted descubre que su producto de plano va a fallar al salir al mercado, es necesario tener el coraje de comunicar y hacer públicos estos asuntos. "

Rick dijo que la gestión de las expectativas es clave para lograr integridad. "Cuando hacemos esto, estamos haciendo compromisos responsables, incluso por la fuerza", explicó. "Eso es integridad." Asimismo, explicó que la integridad viene de la resolver los problemas más difíciles del proyecto sin destruir a los miembros de nuestro equipo o a sus familias, y comunicar mensajes frecuentes actualizados, consistentes y acordados con todos los interesados del proyecto.

Dirigir a otros

Los equipos de trabajo son el corazón de los proyectos, y los líderes de proyecto no pueden dirigir si no tienen un equipo. "Seamos realistas, los proyectos están en su mejor momento cuando la gente está en su mejor momento", dijo Rick. "No solo estoy hablando sobre el cuidar a la tropa para luego salir del camino, como hacer muchos gerentes de proyecto. Los proyectos están en su mejor momento cuando todas las personas están en su mejor momento, incluyendo al patrocinador, los clientes, proveedores, y las organizaciones funcionales adyacentes. "

Thomas está de acuerdo. "El líder tiene la responsabilidad de crear un ambiente que promueva el desempeño tanto a nivel individual y del equipo", dijo."En primer lugar, usted espera ser un modelo a seguir. Usted tiene que predicar con el ejemplo. Demostrar liderazgo auténtico". Esto significa asegurarse de que sus palabras están alineadas con las acciones. No se deben establecer normas para el equipo para que luego sea el líder quien las rompa.

"¿De verdad quieres potenciar tu equipo?", agrega Thomas. "(Entonces) hay que darle al equipo la información que necesita y se debe compartir el poder para que el equipo puede conseguir realmente la oportunidad de sobresalir y tener un papel activo en el éxito del proyecto."

Cuando el equipo se siente apoyado, no hay necesidad de hacer microgestión. Thomas cree que es importante que el equipo sienta el poder. Hay que ser capaz de confiar en los miembros del equipo. "Hay que dejar que suceda", dijo. "Hay que darle al equipo la oportunidad de mostrar cómo puede desempeñarse. Eso es muy importante. "

Por donde empezar

Si convertirse en un líder de proyecto suena difícil, Rick tiene algunos consejos simples sobre cómo empezar. "Una manera de empezar es simplemente escuchando", dijo."Tenemos una gran cantidad de conocimiento disponible para nosotros a través de nuestros grupos de interés. Tenemos que asegurarnos de que estamos regularmente cerca de ellos. "

Otro paso fácil para convertirse en un líder es celebrar el desempeño."¿Quieres buscar comportamientos que reflejen el propósito y los valores?, entonces desarrolla las habilidades y el trabajo en equipo y recompensa, recompensa, recompensa estos comportamientos", dijo Thomas. "No espere hasta el final del proyecto para celebrar los mismos resultados. Celebre el desempeño. "

Lo importante del liderazgo es que instintivamente sabrá lo que se siente cuando lo esté haciendo bien. La gente que nos rodea nos hará saber que estamos haciendo un buen trabajo. "Al final", dijo Rick, "nuestros proyectos son evaluados por gente, los clientes, el patrocinador, los miembros del equipo. La mayoría de estas personas no están imbuidas de la teoría de gestión de proyectos. Sólo juzgarán si el proyecto a la altura de sus expectativas según su propia interpretación. Es un proceso subjetivo y, sobre todo, las personas odian ser sorprendidas. Así que la mejor manera de abordar esto es convertir la gestión de expectativas en un mantra de todos los días". Este es un buen consejo para cualquier líder.

Conrnelius sugiere escuchar las entrevistas completas con Ricardo Valerga y Thomas Juli en forma gratuita en The Project Management Podcast, www.pm-podcast.com.

The Power of an Internal Franchise

noreply@blogger.com (Iván Rivera, PMP) — Tue, 07 Jun 2011 20:45:00 +0000

Few weeks ago I was invited to read the book "The Power of the Internal Franchise" by Martin O'Neill.

Let me share some notes about the book.

The book presents an interesting business model that can be used in the changing environment which today's businesses must face, understanding that having a great product or service is not enough, the success of organizations is determined by the way they can align, inspire and mobilize employees around its strategy.

The approach is really simple: The company should make explicit its business model and franchisee it to their employees. Then, employees are coordinated, directed and trained to operate the business with a high level of competition, as they have appropriate organizational culture.

Initially, in order to unlock the power of the domestic franchise, leaders must develop five entrepreneurial beliefs:

Belief in the leader
Believe in the purpose
Believe in the operational model
Believe in the empowerment
Believe in the reward

The author states that believe in the operational model is important because this is the integration of policies, procedures, processes and business structures. Similarly, belief in the empowerment means have the authority and ability to act, knowing that you have the support of the organization.

It is clear that the organization needs to strengthen its organizational culture, especially business values: the client, service flexibility and focus on the "big" goal. This organizational culture helps to build loyalty and motivation of existing employees and helps attract valuable new resources. Finally, it establishes the principles that govern the actions of employees.

The next step is to develop the business model: Object of the business, financial model, operating parameters and processes.

I will not summarize the book; I invite you to read it better. It is full of anecdotes that help better understand the concepts that the author hopes to teach. At the end of the reading is clear to me that with the support of its employees (applying the concepts suggested in the book); any organization can be consolidated as a major player in its niche market.

El poder de la Franquicia Interna

noreply@blogger.com (Iván Rivera, PMP) — Tue, 07 Jun 2011 20:42:00 +0000

Hace unas semanas fui invitado a leer el libro “The Power of the Internal Franchise” the Martin O’Neill.

Comparto ahora algunas notas respecto al libro.

El libro presenta un interesante modelo de negocio que el autor sugiere se use ante el ambiente de cambio constante en el que los negocios de nuestros días deben enfrentarse, entendiendo que contar con un gran producto o servicio ya no es suficiente; el éxito de las organizaciones está determinado por la forma en que estas pueden alinear, inspirar y movilizar al personal en torno a su estrategia.

El planteamiento es realmente simple: La compañía debe hacer explícito su modelo operativo y luego franquiciarlo a sus empleados. Luego los empleados son coordinados, dirigidos y entrenados para operar el negocio a con un alto nivel de competencia, ya que se han apropiado de la cultura organizacional.

Al inicio, el autor dice que para liberar el poder de la franquicia interna, los líderes deben instaurar en la organización “cinco creencias empresariales” (entrepreneurial beliefs):

Creer en el líder
Creer en el propósito
Creer en el modelo operativo
Creer en la propia autoridad
Creer en la recompensa

El autor precisa que creer en el modelo operativo es importante ya que este es la integración de las políticas, procedimientos, procesos y estructuras del negocio. Es la descripción de cómo opera el negocio.

Del mismo modo, creer en la propia autoridad es tener la autoridad y la habilidad para actuar, sabiendo que se cuenta con el respaldo de la organización.

Es claro que la organización debe reforzar su cultura organizacional, en especial los valores empresariales: el cliente, la flexibilidad en el servicio y el enfoque en el “gran” objetivo. Esta cultura organizacional ayuda a construir lealtad y motivación en los empleados existentes, y permite atraer a valiosos recursos nuevos. Finalmente, establece los principios que gobiernan el actuar de los empleados.

El siguiente paso es desarrollar el modelo de negocio: Objeto del negocio, modelo financiero, parámetros operativos y procesos centrales.

No voy a resumir el libro, mejor los invito a leerlo. Está lleno de anécdotas que ayudan a comprender mejor los conceptos que el autor espera transmitir. Al final de la lectura me queda claro que con el apoyo de sus empleados (aplicando los conceptos sugeridos en el libro), cualquier organización se puede consolidar como un gran competidor en su nicho del mercado.

Principales acciones y resultados esperados del Administrador de Proyectos

noreply@blogger.com (Iván Rivera, PMP) — Mon, 30 May 2011 15:00:00 +0000

Desde PMHut, Michael Greer (Twitter y página personal) nos propone las 20 principales acciones y resultados esperados del Administrador de Proyectos, organizados de acuerdo a los cinco procesos esenciales en la Administración de Proyectos: inicio, planificación, ejecución, seguimiento-control y cierre.

*Inicio*
1. Demostrar la necesidad y viabilidad del proyecto	Desarrollar un documento que confirme que existe la necesidad de los resultados del proyecto y describa, en términos generales: Los entregables Los medios para la creación de los mismos Los costos de su creación y aplicación Los beneficios que se obtendrán mediante su aplicación.
2. Obtener la autorización del proyecto	El patrocinador debe decidir si el proyecto se ejecuta. Asignar al administrador del proyecto. Crear el "acta del proyecto". Este documento: Reconoce formalmente el proyecto Es expedido por un gerente externo al proyecto y en un nivel de la organización suficientemente alto para que él o ella que pueda resolver las necesidades del proyecto Autoriza al administrador de proyecto para obtener recursos para las actividades del proyecto.
3. Obtener Autorización para la fase	El patrocinador debe decidir si la fase se ejecuta, autorizando al Administrador a aplicar los recursos de la organización a una fase en particular. Crear un documento de aprobación de la fase. Este documento: Reconoce formalmente la existencia de la fase Es expedido por un gerente externo al proyecto y en un nivel de la organización suficientemente alto para que él o ella que pueda resolver las necesidades del proyecto
*Planeación*
4. Describir el alcance del proyecto	Preparar la declaración del alcance del proyecto Desarrollar el Plan de gestión del Alcance Elaborar la estructura de descomposición de trabajo
5. Definir y ordena las actividades del proyecto	Listar las actividades (lista de todas las actividades que se llevarán a cabo en el proyecto) Determinar los cambios a la estructura de descomposición del trabajo (EDT) Crear el diagrama de red del proyecto
6. Estimación de la Duración de las actividades y recursos requeridos	Estimar la duración (tiempo necesario) para cada actividad y los supuestos relacionados con cada estimación Declarar los recursos necesarios Actualizar la lista de actividades
7. Desarrollar un programa del proyecto	Preparar el calendario del proyecto en forma de diagramas de Gantt, diagramas de redes, diagramas de hito o tablas de texto Determinar los detalles de apoyo, tales como el uso de recursos en el tiempo, proyecciones del flujo de efectivo, orden y calendario de entregas, etc
8. Desarrollar la estimación de Costos	Estimar los costos para completar cada actividad Documentar los detalles de apoyo, incluidas las hipótesis y restricciones Preparar el plan de control de costos que describa cómo se manejarán las variaciones de costos.
9. Construir un Presupuesto y Plan de Gastos	Establecer la línea base de costo o presupuesto por etapas para la medición / control de costos Preparar un plan de gastos, indicando cuánto y en que momento se gastará en recursos
10. (Opcional) Crear un Plan de Calidad formal	Preparar un plan de control de calidad, incluidas las definiciones operacionales Completar listas de verificación de calidad
11. (Opcional) Crear un Plan de Comunicaciones	Preparar un plan de gestión de la comunicación, que incluya: Estructura de reccolección de información Estructura de distribución de información Descripción de la información que debe difundirse calendario que indique cuando se producirá la información. Un método para actualizar el plan de comunicación
12. Organizar y contratar el personal	Asignar roles y responsabilidades Preparar el Plan de dotación de personal Desarrollar el organigrama con el detalle apropiado Obtener el Personal del proyecto Distribuir el directorio del equipo del Proyecto
13. (Opcional) Identificar los Riesgos y el Plan de respuesta	Elaborar un documento que describa los riesgos potenciales, incluyendo sus fuentes, los síntomas y las maneras de enfrentarlos
14. (Opcional) Planear y adquirir recursos externos	Desarrollar el plan de gestión de adquisiciones que describa cómo se reclutará a los contratistas Elaborar la declaración de trabajo (SOW) o declaración de requisitos (SOR) que describan el artículo (producto o servicio) que se espera adquirir Preparar los Documentos requeridos para concursar la solución , tales como RFP (solicitud de propuesta), IFB (invitación para la oferta), etc Establecer los criterios de evaluación, es decir, como se evaluarán las propuestas de los contratistas Desarrollar el (los) contrato(s) con uno o más proveedores de bienes o servicios
15. Organizar el plan de proyecto	Preparar un plan de proyecto integral que recabe todas las salidas de las actividades de planificación de proyectos anteriores.
16. Cerrar la fase de planificación del proyecto	Desarrollar por escrito el plan del proyecto, y obtener la aprobación del patrocinador Obtener la autorización para arrancar el proyecto
17. Revisar el plan del proyecto y replanear si es necesario	Asegurar que los planes detallados para ejecutar una fase en particular siguen siendo precisos y que efectivamente lograrán los resultados previstos.
*Ejecución*
18. Ejecutar las Actividades del Proyecto	Elaborar los resultados del proyecto (entregables). Identificar las solicitudes de cambio (es decir, las ampliaciones y reducciones al alcance del proyecto). Preparar informes periódicos sobre el progreso del proyecto. Evaluar el rendimiento del equipo se evalúa, guiando, y mejorando si es necesario. Elegir los contratistas (proveedores) , solicitar y evaluar ofertas / propuestas , y establecer contratos. Administrar los contratos para lograr los resultados deseados
*Seguimiento y Control*
19. Control de las Actividades del Proyecto	Decidir cuando se aceptan los entregables inspeccionados Tomar acciones correctivas tales como rehacer entregables, ajustar los procesos de trabajo, etc Actualizar el plan de proyecto y el alcance Listar las lecciones aprendidas Implementar las mejorar a la calidad Si procede, completar las listas de verificación
*Cierre*
20. Actividades de cierre del proyecto	Documentar por escrito que el patrocinador ha aceptado formalmente el producto de esta fase o actividad. Otorgar la aceptación formal a los productos del trabajo de contratistas y actualizar los archivos administrativos de los contratistas Actualizar los registros de proyectos y prepararlos para su archivo. Preparar el plan de seguimiento a los productos de trabajo

Actividades que un Administrador de Proyectos no debe olvidar

noreply@blogger.com (Iván Rivera, PMP) — Sun, 15 May 2011 23:39:00 +0000

En los foros de ProjectSmart encontramos un listado de cosas importantes que Duncan (dhaughey) considera se deben tener en cuenta antes, durante y después de la entrega de un proyecto:

Recuerde establecer la línea de base de su plan para que pueda medir el progreso.
Crear el ambiente adecuado para que el equipo pueda tomar posesión de su parte del proyecto.
Evaluar constantemente el progreso del proyecto preguntando: "¿Cómo vamos?"

Considere añadir un poco de holgura (a las tareas críticas). Todas las tareas llevarán más tiempo que el originalmente planeado.
Prepare documentación simple y fácil de entender.
Valide constantemente.
Asegúrese de probar, probar, probar con personas externas al proyecto.
Celebre si el proyecto avanza dentro de lo programado.
Continúe el seguimiento aún después de la entrega para asegurarse de que todo trabaja como debe o para detectar posibles mejoras.
Compruebe que los beneficios previstos se están cumpliendo.
Aprenda de y documente las lecciones de los proyectos.
Termine rápidamente los proyectos fallidos.
La gestión del proyecto tiene un principio y un final. No es un proceso continuo.
El plan del proyecto es (solo) una herramienta.
Treinta y cinco por ciento de los proyectos se consumen en los gastos generales y de administración.
Los fracasos del proyecto van a suceder.
Adquiera los conocimientos y comprensión necesarios antes de comenzar un proyecto.
Recuerde siempre usar números de versión y comprobar que todos los involucrados en el proyecto está utilizando la misma versión del plan.
Conozca (y administre) a todos los interesados en el entorno del proyecto.
Los proyectos necesitan una buena comunicación. Asegúrese de que existe una adecuada infraestructura de comunicaciones.
Los proyectos no se ejecutan sin políticas, hay que administrarla.
Analice el impacto de pueda tener cada uno de interesados en el proyecto.
Solicite la información que necesita para ejecutar un proyecto con eficacia, por ejemplo, un desglose de los gastos semanales y las horas.
Mantenga el impulso de proyectos en marcha.
Supervise y controle los riesgos.
Pregunte con cuánto dinero cuenta, cuánto tiempo y los entregables que se requieren.
Averigüe cuales son los factores personales de éxito de los interesados.
Acuerde con el cliente los factores críticos de éxito. Entregue lo que comprometió con el cliente.
Administre, minimice y controle.
Si hay que hacer algo, hágalo.

Como distinguir entre un riesgo o un problema

noreply@blogger.com (Iván Rivera, PMP) — Sun, 01 May 2011 14:00:00 +0000

photo © 2009 Steven Depolo | more info (via: Wylio)
Bruce Lofland nos presenta en su blog "PM Technix" un artículo en el que nos sugiere como establecer la diferencia entre riesgos y problemas relacionados con proyectos: "Project Risk or Issue?"

Esta es una situación que cualquier Administrador de Proyectos ha enfrentado: establecer si un evento o situación dada es un riesgo o un problema.

Una primera definición sugerida por Bruce es que un riesgo se describe un acontecimiento incierto que podría suceder. Es algo que preocupa a la gente. Si algo que afecta el proyecto ya ha sucedido, entonces se llama un problema.

Un ejemplo de un riesgo sería: "No se podrá completar el proyecto a tiempo si la pieza que se necesita no llega a tiempo." En este caso, no estamos seguros de que tenemos un problema todavía. Pero si ya sabemos que la pieza que necesitamos no estará disponible cuando lo necesitamos, este es un problema.

Un riesgo del proyecto afectará el costo, el cronograma, el alcance o la calidad del proyecto. Si el riesgo no se materializará hasta después que el proyecto ha terminado, entonces no es un riesgo para el proyecto. Puede ser un riesgo para el programa u organización, pero no del proyecto. Lo mismo puede decirse de un problema. ¿Afecta a las cosas que son responsabilidad de administrador del proyecto? Si no, entonces debe ser manejado por los responsables del programa o de la organización.

Ser capaz de distinguir entre esto suele ser una de las cosas más difíciles de entender para los administradores de proyectos, debido a que riesgos y problemas se tratan de manera diferente y hacer frente a riesgos y problemas que finalmente no afectarían al proyecto provoca pérdida de tiempo y energía del equipo del trabajo.

A continuación un ejemplo de un riesgo que no pertenece al proyecto:

"El sistema que estamos construyendo está diseñado para 100 usuarios concurrentes, pero si se conectan más puede correr lento o incluso fallar."

Si el proyecto termina cuando el sistema se ha implementado, entonces este riesgo no se producirá durante el proyecto. Si los requisitos del sistema dicen que tiene que soportar 100 usuarios simultáneos y el sistema los soporta, entonces no es un riesgo del proyecto. El riesgo de tener más los usuarios de los esperados y las consecuencias posteriores son del dominio de las operaciones de negocio, no el proyecto. Desde el punto de vista del proyecto es más bien una falla en la definición del alcance.

Generalmente el origen de esta confusión surge al no distinguir entre un proyecto, un producto, y un programa. Un proyecto ofrece lo que se pide, a menudo un producto. No se hacen afirmaciones sobre el valor o los beneficios del producto. Ese es el dominio del programa o del dueño del producto. A veces, el director del proyecto, director del programa, y el propietario del producto son la misma persona, pero a menudo no lo son.

Los riesgos se documentan cuando se descubren; es de esperar que la mayoría se documenten al inicio del proyecto. Luego se evalúan la probabilidad y el impacto y se agregan al plan del proyecto las tareas de mitigación. Se puede crear un plan de contingencia para documentar lo que planeamos hacer en caso de ocurrir un riesgo. Estos riesgos se controlan y actualizan según sea necesario durante el proyecto. Y si realmente se producen, se convierten en problemas.

Sobre los problemas hay que actuar en forma inmediata. Las acciones sugeridas pueden involucrar la adición de tareas con el plan, la ampliación del calendario o el aumento del presupuesto. Se les da seguimiento tomando acciones hasta que son resueltos y ya no afectan al proyecto.

Esa es la diferencia entre los riesgos y problemas. Manejar cada uno de forma apropiada hace mucho más fácil la gestión.