Los resultados de la encuesta online (nuevo servicio de Linkedin, ojo no me pagaron por esa mención), han votado 2771 usuarios, supongo que todos miembros del grupo The Project Manager Network, la pregunta exacta es: Is PMP certification becoming more or less important for project managers?

Está bastante parejo el resultados, contrario a lo que se podría pensar, un 57% lo encuentra importante y un 43% menos importante.  Digo que sorprende ya que en un grupo como ese la mayoría a favor de la certificación sería bastante más abrumadora.

Al revisar los comentarios surgen básicamente dos ideas fuerza asociadas a cada posición

• A Favor, la certificación PMP (Project Management Professional) es un must que todo gerente de proyecto debe tener si quiere ascender en su carrera gestionando proyectos cada vez más importantes, y por lo tanto debe enfocarse en obtener la referida certificación, como un prerequisito para aquello.

• En contra, que básicamente se trata de un negocio del PMI, ya que por un curso de aproximadamente 1.500 dólares, más el costo del examen y la declaración de una experiencia de 4.500 horas gestionando proyectos (la otra forma es tomar otros cursos de organizaciones certificadas por el PMI) se puede obtener el PMP, pero ello no asegura que tengan las competencias necesarias.

Debo reconocer que en el año 2007, realice todas las gestiones para certificarme, para lo cual presenté las horas de pre requisito, según me consta las personas de contacto (contrapartes de los proyectos presentados) que puse en mi solicitud, algunas fueron contactadas y otras no.  Tenía programado un curso intensivo de una semana para preparar el examen, finalmente tuve que abortar mi proceso ya que fui nombrado Secretario Ejecutivo de la Estrategia Digital y la verdad es que se me hizo inviable cerrar el referido proceso.

Los Europeos, en particular los ingleses con su metodología de gestión de proyectos Prince2, su gran argumento a su favor es que no existe un modelo de negocios detrás de ella, el PMI se defiende con el argumento de que se trata de un método reconocido a nivel mundial y un estándar desde el punto de vista de la gestión d proyectos.

En todo caso se debe señalar que las certificaciones Prince2 o PMP no aseguran calidad, es igual que las certificaciones ISO, aseguran que se cumple un método/procedimiento para el proceso, lo cual al menos da garantías de consistencia en el proceso y los artefactos que se utilizan para su desarrollo.

Usted,  ¿qué piensa al respecto? , los gerentes PMP desempeñan una mejor labor a la hora de administrar proyectos, en este punto me encantaría contar con la retroalimentación de Eduardo Díaz, digo yo para seguir con el debate sobre proyectos TI y su gestión.

Al menos esto, hace que el impacto y consecuencias de este tipo de fracasos sea menor, por otra parte cada gerente de proyecto debe estar monitoreando si su proyecto tiene potencial para transformarse en un Cisne Negro o no, ya que con 17% no sería raro que en su carrera le toque encontrarse con uno

¿Se imaginan que sólo el 32% de los proyectos inmobiliarios o de infraestructura fueran exitosos?

Hace unos días Mario Waissbluth me pidió unos datos sobre tasa de éxito/falla de proyectos tecnológicos en el Estado, o dicho de otra forma proyectos eGov, lo que me llevó a buscar entre mis cachureos, y me di cuenta que mis datos estaban un poco añejos, por lo que me puse a investigar nuevamente y llegué a números un poco más recientes, dicho sea de paso, creo que en Chile nos hace falta una investigación seria al respecto, todos los números que andan dando vuelta, tienen bastante de dígitos oscilantes, si sirve de consuelo los números que existen a nivel internacional tampoco hacen segmentación por industria o sector (público o privado).

El estudio más referenciado es el que realiza la consultora Standish Group, el cual es recurrente y existen datos desde 1994, que apareció por primera vez, estudio denominado Chaos Report.  He escuchado algunas críticas a este informe, por ejemplo relacionadas con la definición de exitoso que es muy  estricta, pero al menos sirve como referencia y además permite tener una evolución en el tiempo ya que es el único estudio que conozco que se realiza en forma periódica.

Antes de mirar esos números démosle una mirada a otras cifras que andan dando vuelta

• Chaos Report (1994) - 16.2% de los proyectos son exitosos.  Del 70% de proyectos no exitosos, 52% corresponden a fallas parciales (expectativas, o tiempos o $)
• Encuesta OASIG (1995) - Las respuestas más optimistas sitúan la tasa de éxito entre 20% y 30%
• Encuesta KPMG Canada (1997) - 61% de los proyectos se consideran fracasados
• Encuesta Conference Board (2001) - 40% de los proyectos no cumplen expectativas de negocios, luego de un año en operación
• Encuesta Robbins-Gioia (2001) - 51% de las implementaciones de ERP son fallidas
• Encuesta Revista Dr. Dobb's (2007) - 72% de los proyecto de desarrollo e implementación de Data Warehouse con metodologías ágiles, versus 63% con metodologías tradicionales.

Como se puede ver, todos los estudios coinciden en que la tasa de éxito de los proyectos es bastante baja, independiente de cual sea la definición de éxito se utilice.  Al observar la evolución de las diferentes mediciones del Chaos Report de Standish como se aprecia en el siguiente gráfico, podemos apreciar un aumento de las tasas de éxito no demasiado significativa pero al menos con una curva positiva, esto se debe fundamentalmente a mejores prácticas de gestión de proyecto, tipo PMI u otros, uso de mejores herramientas y metodologías de desarrollo.



En el ámbito del Estado el comportamiento es incluso peor, según el estudio de eGovernment for Development de la Universidad de Manchester, sólo el 15% de los proyectos son considerados exitosos, la definición que utiliza eGov4Dev es:

Los principales stakeholders del proyecto dicen que se han logrado los principales  objetivos y no han experimentado resultados no deseados significativos

En la gráfica se detalla el resultado de dicho estudio:

Sería interesante que las autoridades locales pudieran medir nuestro comportamiento, ya que si estamos en los mismos niveles, esto es, 35% totalmente fracasados (nunca se implementaron o abandonaron según definición del eGov4Dev) unos 100 millones de dólares del presupuesto de la nación van a dar a la basura.

Todos los estudios coinciden han las mismas causas de fracaso de los proyectos, las que se pueden resumir en:

• Especificaciones y requerimientos cambiantes o incompletos;
• Falta de involucramiento de usuarios
• Pocos conocimientos técnicos del equipo de proyecto
• Uso inadecuado de métodos y herramientas
• Expectativas poco realistasFalta se soporte gerencial
• Gestión de proyectos débil, lo que incluye no identificación de riesgos, falta de planificación, comunicación deficiente

Referencias

• Standish Group
• ProjectSmart  
• The business end of IT project failure 
• Why IT projects Fail, Al Niemat, Taimour 
• eGovernment for Development, Universidad de Manchester

Fuente Imagen: www.drdudd.co.uk

En el último tiempo me han llegado muchas solicitudes por herramientas para gestión de proyectos y PMO en general.  Lo primero a decir es que existe una cantidad enorme de herramientas para la gestión de proyectos, de hecho en uno de los repositorios que les menciono más abajo aparecen más de 400 herramientas, desde planillas adecuadas para tal efecto hasta sistemas de clase mundial, tales como: Primavera (Oracle), Mercury (HP) o Clarity (CA), pasando por sistemas en modalidad SaaS (Software as a Service), de desktop o bien para ser instalados en servidores corporativos.

Dado que existen una enorme variedad de soluciones de software para la gestión de proyectos, diría que el principal problema no es encontrar herramientas sino identificar cual es la que mejor se adapta a mis necesidades.  Estas herramientas cubren las diferentes necesidades funcionales: gestión de tareas y actividades, gestión de recursos, calendarios, colaboración, gestión documental, administración de portafolios, gestión de riesgos.  A continuación les adjunto un listado de sitios donde se pueden encontrar información de herramientas de gestión de proyectos.

Algunos de los sitios donde pueden encontrar referencias y análisis comparativos de estas herramientas son:

• Análisis comparativos de herramientas de gestión de proyectos en Wikipedia
  

• Evaluación de las principales herramientas de gestión de proyectos en el sitio Top ten Reviews 
  

• En el sitio Gantt Head existe una herramienta que permite seleccionar por tipo diferentes sistemas de gestión de proyectos (muy interesante)

• Portal de herramientas de gestión de proyectos del tipo web cuenta con un listado de 468 herramientas y una pequeña descripción de sus características el mismo sitio cuenta con una revisión de un panel de especialistas de algunas de las herramientas

• Artículo de revista francesa Journal du Net en el cual se analizan las principales herramientas de gestión de proyectos del tipo Open Source (afortunadamente el artículo está en francés para aquellos que nos gusta ese idioma) 

Los estándares de “Proyecto” corresponden a un conjunto de guías que buscan establecer un modelo de diseño y ejecución de proyectos, predecible, escalable y que cuente con un esquema de gobierno de los proyectos.  Para esto existen diversos enfoques metodológicos pero me atrevo a decir que los más difundidos a nivel mundial el estándar PMI y estándar Prince2.  Estos estándares proveen de guías para todo tipo de proyectos, sin importar su tamaño ni industria.  Ambos tienen una terminología y un ciclo de vida de los proyectos diferentes, les recomiendo que analicen ambos y adopten uno de ellos.

Con la idea de entregar algunos elementos al momento de la selección de la metodología a utilizar, me parece adecuado dar algunos antecedentes de ambos métodos

PMI, es un estándar desarrollado en los Estados Unidos de Norteamérica, con el mercado americano en mente cuando se desarrolló, PMI desarrolló su metodología denominada PMBOK en cual ya va en su cuarta versión (recientemente lanzada) y cuenta con esquemas de capacitación y certificación.  Adicionalmente cuenta con capítulo en cada país donde está presente en Chile, lo pueden ver en .  En nuestro país esta metodología se ha utilizado con mucha fuerza en proyecto industriales en particular en el caso de proyectos mineros.  No cubre las etapas de pre-proyecto y tiene un enfoque a las actividades (WBS), es decir es un “project management process”. 

Project Management Body of Knowledge (PMBOK)

Prince2, se trata de un estándar desarrollado en Gran Bretaña, por la OGC, oficina del gobierno británico, su foco original fue el sector público, pero ha sido adoptada en otras industrias, tiene una fuerte presencia en Europa y en las zonas de influencia del Reino Unido.  Los seguidores de este método le critican a PMI su excesivo enfoque comercial al momento de adoptar dichas prácticas y en los procesos de certificación.  No cubre las etapas de adquisición, define roles estándares para los miembros de los equipos de trabajo y tiene un enfoque a producto más que a actividad, es decir es un product oriented process.

Les adjunto un documento que compara ambas metodologías, esto es a partir del PMBOK realiza un análisis de Prince2, es bastante interesante y permite tener una mejor visión de ambos métodos. Ver en A comparison of Prince2 vs PMBOK

Cualquiera sea su decisión de metodología a utilizar, es fundamental tener en consideración algunos elementos que pueden ayudar su adopción

• Instalar la nomenclatura, todas las metodologías de proyecto cuentan con sendas terminologías y glosarios (de hecho para certificarse PMI hay que aprenderse todos esos términos), los más importante es que sus equipos de proyecto al momento de utilizar el método entiendan todos lo mismo por un determinado concepto.

• Implementar el ciclo de vida de los proyecto para los nuevos proyectos, no tiene sentido insertarlo en los proyectos en curso.  Esto logrará una mayor motivación el los equipos de trabajo y no afectará a los proyectos en curso.

• Utilice las guías y recomendaciones del estándar, evalúe las herramientas que el estándar provee y adóptelas en su  proyecto, sea selectivo, recuerde que estos estándares están pensados en forma genérica y son para cualquier tipo de proyecto en cualquier industria, existirán etapas, prácticas que en sus proyectos no aplican “no fuerce su uso”.

• Realice importante esfuerzos de capacitación e inducción del método en su equipos de trabajo, debe contar con un proceso de entrenamiento constante de su personal.

• Utilice herramientas tecnológicas como apoyo, idealmente herramientas de gestión de proyectos, sea majadero en su uso ya que eso implica mayor orden en el proceso.  Seleccione la mejor herramienta para el soporte (interna, comercial, Web u otra)

¿Seleccionó la metodología de su agrado?

En este artículo me permito porponer algunas recomendaciones,  a la hora de realizar el monitoreo y reporte de proyectos, recopiladas a partir de la experiencia propia, buenas prácticas y recomendaciones de los gurús en esta materia.

Frecuencia: Desarrollar un reporte semanal del estado de los proyecto que permita analizar su avance y establecer las brechas entre lo planificado y lo real, en los diferentes ámbitos, tiempos, recursos y producto/entregables.  El estado e avance debe presentar las predicciones de avance, sea conservador en esas predicciones, existen una tendencia de los informáticos a ser más optimista de lo razonable, y muchas veces ni siquiera incorporar la historia organizacional (¿cómo se han comportado los proyectos pasados?).

Tareas: mostrar el estado de las tareas y actividades definidas en el proyecto, es fundamental mostrar a los stakeholders de los proyectos y en particular al sponsor las actividades finalizadas y aquellas en curso.  Debe entregar toda la información necesaria para el proceso de toma de decisiones.

Hitos: Su proyecto debe incorporar hitos, esto es, etapas del proyecto en el que existen entregas de productos sean estos intermedios y/o finales. En sus reportes debe entregar el estado de avance de cada uno de los productos comprometidos, muestre su avance real y su brecha respecto del esperado a la fecha del reporte.  Muestre a su equipo de trabajo los productos terminados, esto permite mejorar las relaciones al interior del equipo.

Pida ayuda: El reporte de proyecto es una instancia para solicitar ayuda del resto de los stakeholders, plantee sus problemas y posible soluciones y/o decisiones necesarias para destrabar situaciones.  Si necesita más recursos solicítelos, la instancia de reportes es la adecuada para ello.

Una versión de la verdad: su modelo de reportes debe contener una sola versión de la “verdad” del estado del proyecto.  Sea lo más certero en su reporte, una de las cosas que más confusiones genera al momento de entender el estado real de un proyecto, son las diferentes versiones de su desempeño.

Herramienta: Utilice para dar cuenta del proyecto una herramienta simple, dependiendo del tamaño de su organización y del proyecto esta puede ser desde una lámina de presentación (tipo power point u openoffice) o templates predefinidos (Method 123) hasta tableros de control de herramientas en la web (Base Camp, Project Manager, Easy Project, Planzone, Daptiv- ex eProject, y otros) o productos comerciales (Primavera recientemente adquirido por Oracle, Clarity de CA, MS Project  u otra) o bien productos Open Source como es el caso del dotProject

El tablero de control debe entregar información precisa y acotada del estado del proyecto, en ella se debe incluir al menos:

• Carta Gantt del proyecto (real versus esperado), en el reporte se muestra carta gantt de alto nivel
• Actividades/Hitos  finalizados
• Actividades a desarrollar hasta próximo reporte
• definiciones críticas que deben ser adoptadas por el equipo directivo del proyecto (Sponsor, PM)
• Riesgo existentes y medidas de mitigación

Algunos elementos que motivan el uso de otros mecanismos para conceptualizar el conocimiento, es que el pensamiento se ha expresado a través de los siglos en forma lineal (análisis, hipótesis y finalmente una tesis), pero resulta que nuestra mente por lo que plantean los expertos y de mi experiencia personal, funciona en forma diferente, nuestra mente más que un análisis lineal y en esquema de documento tradicional , funciona más como un sitio Web (hipertexto multidemensional), sino basta ver como los grandes pensadores de la humanidad expresan y desarrollan sus ideas.

Partamos por analizar que son los mapas mentales, según Tony Buzan (1970), se trata de una expresión del pensamiento irradiante, en la cual a través del uso de texto e imágenes se pueden expresar pensamientos e ideas, en forma complementaria según Wikipedia, un mapa mental es una técnica inventada por el mismo Buzan:

 "un mapa mental consta de una palabra central o concepto, en torno a la palabra central se dibujan de 5 a 10 ideas principales que se refieren a aquella palabra. Entonces a partir de cada una de las palabras derivadas, se dibujan a su vez de 5 a 10 ideas principales que se refieren a cada una de ésas palabras."

Según el mismo Buzan se trata de una potente técnica gráfica que permite de mejor forma acceder  al potencial del cerebro.

El asunto o motivo de atención cristaliza en una imagen central, los temas principales del asunto irradian de la imagen central de forma ramificada, Las ramas comprenden una imagen o una palabra clave  impresa sobre una línea asociada. Los puntos de menor importancia también están representados como ramas adheridas a las ramas del nivel superior: Todas las ramas forman una estructura nodal conectada.

Existen algunas confusiones entre mapa conceptual (la imagen representa un mapa conceptual del Grid Computing, para visualizar con más detalle clickearlo) y mapa mental, la diferencia entre estos, es que un mapa mental tiene sólo un concepto principal, mientras que un mapa conceptual puede tener varios. Esto se reduce al punto de que un mapa mental se puede representar como un árbol, mientras que un mapa conceptual puede necesitar una representación de red.


¿Para que se pueden utilizar los mapas mentales?

• Organizar un tema
  
• Ubicar nuevas ideas en una estructura
• Tomar apuntes
• Comunicar ideas complejas
• Brainstorming
• Resumir
• Diseñar y Planificar proyectos
• Ingeniería de Software
• y muchos otros

¿Cómo se utilizan?

1. Escribir idea fuerza al centro
2. Rodear de un círculo
3. Ubique otras palabras importantes o claves alrededor
4. Conéctelos (en general se utilizan conexiones del tipo jerárquicas padre-hijo)
5. Use colores, formas, imágenes y vínculos
6. Estructure una jerarquía
7. Itere con su mapa sucesivamente (son modelo dinámicos y cambiantes en el tiempo)

Para leer estos mapas, se leen desde el centro hacia las ramas, la palabras e imágenes cercanas al centro representan temas centrales, la forma de lectura es de izquierda a derecha y de arriba a abajo.

Algunas herramientas

Para utilizar esta técnica existen múltiples herramientas desde su uso en forma manual (papel y lápiz) hasta una multiplicad de aplicaciones de escritorio y en la Web que permiten estructurar mapas mentales, les quiero presentar algunas alternativas (he utilizado varias de ellas y hace algunos días atrás descubrí The Brain que me ha impresionado mucho)

Manual

Para desarrollar esta técnica en forma manual se requiere de muy poco, una pizarra blanca, plumones de colores y post-it (idealmente de diferentes colores)

Software
En esta categoría existen múltiples productos, open source, en la Web y aplicaciones de escritorio y como en el mundo del software existen para todos los gustos

Open Source

• Freemind, es la herramienta OSS más difundida, muy simple de usar está basada en Java por lo que se puede utilizar en diferentes ambientes (windows, mac y linux), no permite mapas de gran complejidad, ideal para alguien que se quiere iniciar en esta materia y que no quiere gastar dinero.
• View Your Mind, herramienta poco amistosa  y funcionalmente limitada, no recomendable.

Web

• Mindmeister , servicio en la web con modalidades gratuitas y pagadas, ganador del Red Herring award  100 de Europa, el servicio premium tiene un costo de USD$ 4 mensual.  Para aquellos amantes de mac cuenta con un Widget para el Exposé
• Mindomo, también tiene modelos de uso gratuitos bastantes restrigidos y pagados, el servicio premium tiene un costo de USD$ 6 mensalues y permite trabajar con varios mapas simultaneos y compartirlos con otros usuarios.

Software Comercial

• MindManager, (windows y MAC OSX, US 350), probablemente el software más dinfundido con un gran nivel de integración con software de Microsoft en particular el Office.
• Novamind, (Mac OS, US$ 79), software para ambiente MAC, muy buena gráfica y buena integración con aplicaciones mac, tiene una aplicación complementaria para el diseño y seguimiento de proyectos denominada Merlin.
• Smart Draw, (windows, US$ 197), software más orientado al diseño y desarrollo de mapas conceptuales, esta herramienta se utiliza para especificación de sistemas utilizando metodología UML
• The Brain, (windows, MAC OSX, Linux, US$ 249), Herramienta extremadamente potente permite desarollar mapas mentales y conceptuales, es multiplataforma y permite exportar resultados en sitios web dinámicos utilizado Ajax.
• Otras Herramientas; les comento otras herramientas de las cuales no puedo comentar gran cosa ya que no las he utilizado, a difrerencia de las anteriores: Visual Mind (windows US$ 199), Inspiration (windows y MAC OS, US$ 69), MindMapper, (windows, US$ 180)

Algunos ejemplos de uso que me parece interesantes mostrarles son:

• Proyecto genérico- Project Management
• Seis sombreros - Six Hats
• Nuevas formas de pensar - New Ways
• Otros usos - Usos

Referencias

• Tony Buzan (1996): El libro de los mapas mentales (se los recomiendo es muy bueno está en Amazon en Inglés y Castellano)
• Seminarwork Mind Maps, Christoph Rissner, 2003 - Seminar Works Mind Maps
• How to use mind mapping software for project management, Chuck Frey
• Tutorial de Freemind (Lai Ye Tao Gabriel) - Tutorial Freemind
• Freemind can free your mind, Jeffrey Causey - FreeMind Can Free Your Mind
• Sitio Mapas Mentales
• Otra fuente es en google utilizando el patrón "mind maps"

Pueden ver una evalución muy interesante de diferente productos en este link

Pueden revisar este artículo presentado en una modalidad de mapa mental utilizando el producto The Brain en esta dirección

• ¿Que tan alineados están mis proyectos con los objetivos estratégicos del negocio?
• ¿Tengo un entendimiento adecuado del valor ganado de los proyectos de mi organización?
• ¿Cuáles son los riesgos claves de mis proyectos?
• ¿Cómo interactúan (se complementan) los proyectos en mi organización?
• ¿Cómo mi organización prioriza los proyectos?
• ¿ Cuál es el nivel y capacidad de absorción de mi organización al cambio?
• ¿Cuáles y porqué son los proyectos con bajo desempeño en mi organización?

• Mentoring Gerentes de proyecto
• Consultoría a proyectos en problemas
• Asistencia en la puesta en marcha de "best practices"
• Difundir las lecciones aprendidas
• Auditorías de proyectos
• Apoyo a las unidades de negocios en el diseño de proyectos, selección de proveedores y en el proceso de desarrollo de los proyectos

• Recopilar el conocimiento organizacional y estructurar el aprendizaje
• Identificar y documentar las "best practices" de la organización
• Generar y proveer acceso a repositorios de conocimiento
• Generar material de entrenamiento
• Capacitar a los gerentes de proyecto
• Desarrollar repositorio documental (libros, papers, journals, conferencias y otros)

• Definir los estándares del proceso de proyectos
• Crear las herramientas (artefactos) para utilizar en las diferentes disciplinas de los proyectos: estimación, diseño, seguimiento y control
• Definición y puesta en marcha de los tableros de mando de los proyectos

• Fuerte: En este modelo la organización PMO opera como una organización central de administración de los proyectos. Este tipo de modelos maneja la cartera de proyectos (portfolio) a su interior y los gerentes de proyectos dependen del administrador de la oficina.

• Consultivo/Staff: En este modelo la oficina de proyectos entrega capacitación, acompañamiento, coaching y mentoring a los gerentes de proyecto de las diferentes unidades de negocio de la organización. La ventaja de este modelo es que es menos invasivo a la organización.

• Mixto: En el cual la PMO toma control de algunos proyectos (más críticos, en problemas, u otro criterio) y otros quedan en las unidades de negocio utilizando un modelo más consultivo

• Tienen una PMO que gestiona los proyectos de la organización y que está en un buen nivel dentro de la organización
• Reportan al directorio regularmente el estado de los proyectos relevantes
• Cuentan con gerentes de proyectos calificados y con incentivos claros
• Realizan rigurosos análisis de riesgos en la fase inicial de planificación y en muchos casos monitoreo externos

1. Fundamentos de la Dirección de Proyectos, (Guía del PMBok), 3ra Edición, Project Management Institute
2. The Program Management Office, Craig Letavec, Editorial J. Ross Publishing, 2006
3. KPMG: Global IT Project Management Survey