LIBRO PEOPLEWARE Y EQUIPOS ÁGILES

Título original: Peopleware y Equipos Ágiles

Autor: Javier Garzás

Editorial: 233gradosdeTI

Páginas: 200 (color)

Idioma: español

ISBN: 978-84-697-7450-2

Palabras clave: Proyectos, gestión equipos

Esta reseña nació cuando, hace unos meses, un grupo de compañeros de empresa asistimos a una keynote de Javier Garzás llamada  “Qué es la Agilidad y cómo te puede ayudar a no acabar en una empresa zombi“:  Keynote en la Universidad de Alicante.

La verdad es que nos pareció muy interesante, pues  ya seguíamos desde hace tiempo el blog de Javier.

Así que cuando saltó la noticia  de que Garzás había publicado un nuevo libro, varios fuimos los que nos apresuramos a adquirirlo.

Destacar que es todo un detalle que el autor te dedique el libro bajo petición. Adicionalmente, yo obtuve un dibujo de Darth Vader de bonus. ¡Mola!

Ya entrando en materia,  el objetivo del libro es profundizar en el cambio en la organización de las personas y en los equipos dedicados al software/hardware que se ha producido en las últimas décadas. Según la Wikipedia, Peopleware es “…cualquier cosa que tenga que ver con el papel de las personas en el desarrollo o uso de software y sistemas hardware, incluyendo cuestiones como productividad de los desarrolladores, trabajo en equipo, dinámicas de grupo, la psicología de la programación, gestión de proyectos, factores de organización, diseños de interfaces de usuario e interacción hombre-máquina.”

Originalmente, “Peopleware, Projects and Teams” es el título de un libro de los años 80 de los autores De Marco/ Lister, referido específicamente al desarrollo de software.

Javier desea remarcar la importancia de las personas en los proyectos/productos /equipos, pues en el fondo son la clave del éxito de cualquier proyecto.

El principal mensaje del autor, adquirido a través de una experiencia de haber trabajado en un montón de empresas remarcables, es que en el desarrollo de software se debe  dejar atrás el taylorismo y la industrialización. Pues se implantó esa visión también en los proyectos de desarrollo de software, un verdadero error, pues no es adecuado y ha generado muchos más problemas de los que ha solucionado. Desarrollar software no es lo mismo que construir un puente o levantar un edificio.

El nacimiento de la agilidad y del Manifiesto Ágil fue una reacción a lo poco apropiados que eran los métodos de trabajo tradicionales para gestionar el desarrollo de proyectos de software. Es más, cambiando la palabra “Software” por “soluciones” se puede aplicar el manifiesto ágil más allá del desarrollo de software.

La visión del Management ya no es gestionar a las personas como a máquinas y procesos (versión 1.0), sino orientada a personas y equipos en una estructura organizativa pensada para ello (versión 3.0).

Destaca que en las empresas existen “tribus” entendidas como la forma en la que trabajan, que hace que se entienda mejor el concepto de “Peopleware” y que van desde el tipo 1 (individualismo por la superviverncia)  hasta el tipo 5 (equipo ágil).

Se mencionan los equipos Good to Great, que cumplen con  siete pautas que distinguen  a las empresas punteras del sector, que pasaron de lo bueno a lo excelente.

Los equipos son complejos. Por eso, la adaptabilidad es adecuada para los sistemas complejos y para las incertidumbres.

Ante todo, en la gestión de equipos debería evitarse tratar de resolver problemas complejos con soluciones fáciles, que suelen acabar empeorando el problema que pretendían solucionar: es lo que se llama reduccionismo o “populismo tecnológico”  (véase el caso del efecto cobra). Pensad en ejemplos que se os ocurran (fomentar el presencialismo en la empresa en lugar de la productividad, montar sistemas para fichar todas las mañanas, exigir un montón de documentación, nombrar un comité para resolver un problema, etc…)

Los equipos de trabajo deberían de contar con las siguientes características:

  • Estar motivados. El tema de las motivaciones y recompensas tiene mucha miga. El autor alerta de que las recompensas pueden hacer que las personas trabajen casi exclusivamente para obtenerlas.
  • Ser Auto organizados, pero que un equipo sea dirigido y organizado por sus propios miembros no significa que non haya jefes o managers. lLa diferencia es que estos se reducen a lo necesario.
  • Ser Mutifuncionales, todos deberían de poder hacer casi cualquier tarea dentro del equipo
  • Por supuesto, ser Productivos. en este punto, ojo con medir el trabajo con sistemas que no favorecen la calidad, como el de contar las lineas de código/hora.

Y un equipo debería de estar orientado a la mejora continua, es preciso fomentar una cultura de la reflexión y de la mejora (a través de sesiones de Retrospectiva o de Lecciones Aprendidas).

Resumiendo, un gran libro que merece una lectura detenida, (yo ya lo he releído un par de veces), pues la gestión de los equipos y de las personas tiene actualmente más importancia que nunca si se desea obtener el éxito en  proyectos o iniciativas.

 

 

 

 

 

 

 

 

LIBRO AGILE PRACTICE GUIDE

Título original: Agile Practice Guide

Autores: PMI + Agile Alliance

Editorial: Project Management Institute, año 2017

Páginas: 210

Idioma: inglés

ISBN: 978-1628251999

Palabras clave: Proyectos, Metodología, Agile, PMP, Project Management, Predictiva

Interesante este libro escrito conjuntamente entre PMI y Agile Aliance. Un apunte, si formas parte de PMI y pagas las cuotas anuales de socio, puedes descargar este libro de forma gratuita en formato pdf desde la web de www.pmi.org 

Y da que pensar que el PMI (que ya cuenta con una certificación especifica en materia de agilidad) da por sentado que la agilidad es una metodología que ha llegado para quedarse durante mucho tiempo entre los Project Managers.

Dado que la agilidad se ha expandido a otros ámbitos de desarrollo, el enfoque de este libro se expande más allá del mundo de desarrollo de software

Esta guía está dividida en siete secciones.

1. Introducción

¿Por qué un manual de este tipo ahora? Porque la agilidad es una metodología que busca proporcionar al cliente una inmediata entrega de valor, a través de varias interacciones y esto es muy valorado ahora, pues las empresas buscan ser competitivas orientándose a la experiencia que obtiene el usuario. Son adecuadas para manejar la disrupción.

Los autores comentan que no está en alcance de este libro estudiar cómo extender la agilidad entre toda la organización sino extenderla a uno o varios proyectos. Es una lástima, porque si la organización no cambia es difícil que los proyectos ágiles tengan éxito.

2. Introducción a la agilidad

  • Esta sección trata fundamentalmente del origen de la agilidad y de los principios que lo sustentan
  • la justificación de la agilidad se basa en que el manejo de la incertidumbre es algo que las metodologías predictivas no manejan bien, pues no están orientadas a aceptar el cambio, la complejidad y el riesgo.
  • El manifiesto ágil de desarrollo de software del año 2001 puso por encima de todo a las personas por encima de los procesos. Se crearon cuatro valores y doce principios
  • Me llama la atención la referencia a la relación entre Lean/agile, pero el enfoque de ambos es diferente
  • Interesante la matriz de complejidad de Stacey. Un proyecto puede empezar en un sitio de la matriz y acabar en otro.

Resumiendo, los proyectos más adecuados para ser abordados por la metodología agil son aquellos que:

  • Requieren de investigación
  • Tienen altas posibilidad de sufrir cambios
  • Presentan requerimientos desconocidos o poco claros
  • Tienen un propósito difícil de describir

3. Selección del ciclo de vida

Es la parte más interesante del libro, con diferencia.

Habla de los cuatro tipos de ciclos de vida de los proyectos: predictiva, iterativa, incremental y ágil y de sus características.  Estoy de acuerdo con su apreciación de que no hay un ciclo de vida perfecto para todos los proyectos:

  • Los ciclos de vida predictivos se benefician de entornos en los cuales los requerimientos están bien definidos y marcados (ej. un proyecto fruto de una exigencia legal). Su punto débil son los cambios y que no entregan valor hasta el final del proyecto.
  • Los ciclos de vida iterativos son beneficiosos si existe una alta complejidad, si hay cambios frecuentes o si el alcance depende de diferentes interesados. Están optimizados para el aprendizaje. Un ejemplo son las “refactorizaciones” de software.
  • Los incrementales se orientan a la velocidad de la entrega. Se entregan frecuentes y pequeños entregables. Un ejemplo puede ser completar un aplicativo de software mediante el desarrollo de diferentes módulos. O mostrar cómo quedaría una habitación en el proyecto de construcción de un edificio.
  • Los agiles son excelentes aproximaciones cuando se espera una gran cantidad de cambios en un proyecto. La diferencia de ágil con los ciclos interactivos e incrementales es que estos últimos proporcionan feedback para la siguiente parte del proyecto, pero, sin embargo, en proyectos ágiles, la entrega incremental descubre ocultos o requisitos incomprendidos. A su vez, los ciclos agiles pueden basarse en iteraciones o en flujos de trabajo. los ciclos ágiles combinan aproximaciones incrementales e iterativas para entregar valor de forma frecuente al cliente.
  • Como síntesis de todo lo anterior surgieron los ciclos de vida híbridos, que son los que se combinan para obtener ciertos objetivos. Por ejemplo, se puede trabajar en las primeras fases de un proyecto con metodologías ágiles (si se necesita investigación) y luego pasar a una metodología predictiva (si se debe cumplir una certificación). O combinar ambas metodologías según para qué aspectos (a mí esto me parece más complejo). Hay muchas combinaciones posibles.
  • Este apartado es tan interesante y está descrito a tan alto nivel, que necesita más desarrollo.

4. Implementando ágil: Creando un entorno ágil

Mencionan que un entorno ágil exige un líder “sirviente”, (que haga de facilitador del éxito del equipo), en lugar de un líder tal y como se describe en los proyectos predictivos. Este tipo de lider debería de pasar de “gestionar” la coordinación a “facilitar” la coordinación.

No se ha tocado la parte correspondiente al “mapeo” de roles entre metodologías predictivas/ágiles. Otro tema interesante pendiente.

Y le impone al líder “sirviente” una tarea adicional, tratar de remover los impedimentos organizativos al equipo del proyecto que pudieran hacer de “cuello de botella”. Sinceramente pienso que si la organización no se orienta a la agilidad, es bastante complejo que el líder sirviente pueda solucionar por sí solo este problema.

Precisamente y dado que el papel del project manager no se contempla dentro de la agilidad, pues según el PMOK 6 son los encargados de obtener los resultados del proyecto y esta responsabilidad en ágil se distribuye por igual en el equipo del proyecto, propone que hagan de lideres “sirvientes”, es decir, que sirvan al equipo del proyecto, allanando su camino.

Si el enfoque predominante es ágil, entonces el papel del PM cambia radicalmente y debe orientarse hacia el liderazgo servil que requiere este tipo de enfoque.

Se habla de los atributos de los equipos agiles exitosos. Comenta que a los equipos ágiles se les debe evitar el coste que supone la “multitarea” de trabajar en varios proyectos de forma simultánea, así como que idealmente deberían de compartir el mismo espacio físico. Se alerta contra el peligro de querer trabajar en forma de “mini waterfalls” que es lo que sucede si se presupone que ya se tienen todos los requerimientos y ya se puede hacer todo el diseño (por ejemplo) o todo el desarrollo. El equipo se dará cuenta de que esa asunción en el mundo ágil no es válida.

Los tres roles que menciona son: product owner, equipo multifuncional y facilitador del equipo (llámese scrum master, project manager o team coach). Apunta que lo ideal es contar con especialistas de tipo “T”, que son los que complementan ser expertos en una materia con conocimientos en otras areas.

Alerta acerca de evitar “silos” en la empresa que impidan que la comunicación fluya en el equipo.

5. Implementando ágil: entregando en un entorno ágil

Todo proyecto necesita un acta de constitución donde se defina el proyecto. Pero esto no es suficiente n un entorno ágil. También necesita una visión, un propósito y unas normas de cómo trabajar en equipo.

Las prácticas agiles más importantes son:

  • Retrospectivas. Permite al equipo aprender, mejorar y adaptar su proceso. No es necesario que sea al final de una iteración de dos semanas. se puede solicitar en cualquier momento. Busca las causas raíz de los problemas sufridos y se desarrolla un plan de acción para solucionarlos.
  • Preparación del backlog (lista del trabajo presentado en forma de historias de usuario). No es necesario tener todo el trabajo que el proyecto requiera sino solo el que se va a desarrollar en siguiente sprint o iteración. Esta es tarea del product owner
  • Refinamiento del backlog. Es la preparación de historias de usuario para la siguiente iteración. Si no se conocen las dependencias entre tareas entonces el product owner puede solicitar al equipo la realización de un “spike“, con el fin de conocer los riesgos. Señala que el equipo no debería de emplear más de una hora a la semana en refinar historias. En caso contrario podría indicar que al equipo le faltan habilidades técnicas necesarias para evaluar y refinar el trabajo.
  • Reuniones diarias. Las mini reuniones diarias (de no más de 15 minutos) se usan para declarar lo trabajado, lo que se va a trabajar, así como para hacer aflorar posibles problemas. No se deben convertir en sesiones de análisis de situación del proyecto ni tampoco se deben usar para tratar de resolver problemas.
  • Demos/reviews. Para proporcionar feedback al product owner, se organizan demos de lo desarrollado en cada iteración. Deben ser frecuentes para así poder dar con la dirección adecuada.
  • Planificación de la iteración. La capacidad de cada equipo es diferente. Se debe hacer una estimación de la capacidad.
  • Prácticas de ejecución que ayudan a los equipos a entregar valor:
    • Integración continua
    • Test en todos los niveles
    • ATDD test de aceptación.
    • TDD y BDD test driven development y behavior driven development
    • Spikes. Útiles para aprender sobre elementos técnicos o funcionales críticos.
  • Cómo las iteraciones y los incrementos ayudan a entregar producto. Las iteraciones ayudan al equipo a crear una cadencia de entrega y muchos tipos de feedback. Las demos son una parte necesaria dentro del flujo de los proyectos ágiles.

Por otra parte, se señalan los desafíos que implican los proyectos ágiles y las posibles soluciones. Muy interesante esta parte.

Medidas en los proyectos ágiles:

  • Es un desafío tratar de determinar la medida de avance en un proyecto ágil. Además de las medidas cuantitativas habituales, cobra importancia añadir medidas cualitativas, como la satisfacción del usuario o la moral del equipo de desarrollo.
  • Los valores de avance en agil son empíricos y tratan de lo que se ha hecho, en lugar de que va a realizar. Por su naturaleza, la estimación se limita a unas pocas semanas.
  • La velocidad del equipo calculada en story points es lo que realmente puede permitir hacer una estimación de cuando se podrá terminar el proyecto.
  • Si el quipo depende de las tareas de externos al proyecto, esto puede interferir en su velocidad notablemente.
  • Para que el progreso de un proyecto ágil sea comprensible a un project no iniciado en ágil, se hace una equivalencia de cómo calcular el Valor Ganado (EMV) haciendo un sencillo cálculo del índice SPI (cronograma) características completadas/características planificadas y del CPI (coste) valor ganado/costes actuales

6 Consideraciones organizativas para proyectos agiles

Los autores son conscientes de que los proyectos existen en un contexto determinado. Por eso se considera fundamental el cambio organizativo que permita aplicar la agilidad, en especial se consideran fundamentales los cambios asociados a la entrega rápida y frecuente y a los cambios constantes en los requerimientos. El mismo PMI publicó una guía para gestionar el cambio en las organizaciones: Managing Change in Organizations: a Practice Guide

Dice la frase de Peter Druker “Culture eats strategy for breakfast”, la cultura de la empresa, que es su ADN, siempre impacta de forma intensa en las estrategias y en especial en el uso de aproximaciones ágiles en la gestión de proyectos.

Respecto a la parte de la gestión de contratos con proveedores, los autores animan a seguir un esquema de contratos de tipo “win-win”, (todos ganan con el acuerdo) que no es una característica en absoluto privativa de los enfoques ágiles.

Por otra parte, los típicos contratos con proveedores que se firman en ciclos de vida predictivos pueden generar grandes riesgos si se trasladan a ciclos de vida ágiles. En especial, puede ser muy arriesgado firmar tanto contratos de tipo “Time and Materials” o “llave en mano” con precio cerrado.

Se menciona cómo gestionar varios equipos ágiles, cuando se requiere la gestión de un portfolio o un programa se hace necesaria. En Scrum se desarrolla el “Scrum of Scrums“.

Es destacable la parte que habla de la relación entre proyectos ágiles y la PMO (Oficina de Gestión de Proyectos). La PMO ayuda a los equipos de proyectos a tener éxito. Y dado que la agilidad crea un cambio, por consiguiente, la PMO debe cambiar y debería perseguir ayudar a los equipos ágiles, una PMO ágil debería de ser una PMO que busque la satisfacción de los usuarios y compatibilizar este objetivo con ser un centro que busque la excelencia.

7 Llamada a la acción

La demanda de agilidad está incrementándose en todos los sectores, la cuestión es cómo enfocar los proyectos para que se aprovechen los beneficios de la agilidad. Y los autores son conscientes de que sus lectores pueden haber echado en falta más información. Precisamente por eso apuntan a seguir cubriendo este interesante tema en sucesivas entregas.

 

 

 

APÉNDICES:

El libro finaliza con una interesante selección de apéndices, entre los cuales destaca el Apéndice X3 Modelo para la Idoneidad del Enfoque Ágil, enfocado a determinar cuándo es mejor utilizar un enfoque ágil en los proyectos

CONCLUSIÓN:

¿Cuál es el objetivo de este libro? Se trata de buscar una aproximación e integración entre las metodologías predictivas y el mundo ágil. ¿Y cómo enfocar esa integración? Está claro que no se trata solamente de añadir más apartados al PMBOK que ya está en su sexta edición. Se trata de construir una versión unificada de ambos puntos de vista. Creo que, aunque se trate de metodologías muy diferentes, el project manager deberá escoger la más adecuada que dependerá del tipo de proyecto de que se trate. Tan sencillo como que se aproveche lo mejor de cada una de ellas, es decir, la aproximación “híbrida” a la gestión de proyectos. Un project manager que se precie, debería saber qué enfoque adoptar, en base a las características del proyecto. Una tendencia que se destaca después de una lectura del PMBOK 6 es que las diferentes metodologías empiezan a converger y cada una adopta lo mejor de las otras.

Es un libro hecho para ser leído por project managers expertos en proyectos predictivos, que deseen conocer lo que les puede aportar el enfoque agile. A un experto en agilidad no le va a aportar nada nuevo.

Esta lectura me ha sabido a poco. Es un tema muy interesante y que tiene mucho recorrido por delante. Esperemos que no tarden en publicar más libros sobre esta temática.

REFERENCIAS:

What is the Purpose of the New PMI Agile Practice Guide?

ACTUALIZACIÓN DE 2018:

Ya ha salido publicada en español la Agile Practice Guide.

Este libro se puede obtener en estos dos sitios:

  • Siendo miembro de PMI:
    • Se puede descargar de forma gratuita en formato pdf (protegido) desde la web de PMI
    • Alternativamente, se puede encargar en formato papel a mitad de precio que los no miembros
  • No siendo miembro de PMI:

 

 

 

 

 

 

 

 

 

SCRUM LEVEL

Esto se había quedado en el tintero. Hace unos meses realicé un interesante curso de Scrum Level, que merece la pena ser comentado. 

Cuando se desea implantar la agilidad en las empresas, se pueden producir problemas  o conflictos con la “cultura” o las prácticas aceptadas dentro de la propia empresa, pues cada una es diferente del resto.

Scrum Level está orientado a evitar esos conflictos, estableciendo las mejores prácticas que se deben implantar y lo hace realizando un diagnóstico personalizado de lo que se necesita poner en práctica  para hacer que las empresa se aprovechen de los beneficios de los enfoques ágiles, sin romper con todo lo anterior.

¿Cómo se define Scrum Level? Es un modelo de evaluación y mejora de la agilidad de las empresas, tanto a nivel técnico, como de la organización en su conjunto.

Extraido de su web: “Propone un método sistemático con el que analizar y evaluar las dimensiones y aspectos que determinan el nivel de agilidad organizacional. El análisis obtenido con Scrum Level revela las fortalezas y debilidades de los diferentes ejes que define el modelo, y apunta las áreas susceptibles de mejora, así como las actividades o prácticas que pueden reforzarse”

http://scrumlevel.com

Scrum Level nace de la experiencia de un reducido número de profesionales y  busca reducir la variabilidad  típica de las implantaciones y progreso de la agilidad,  a partir de los proyectos desarrollados entre sus clientes.

Para ello Scrum Level analiza indicadores y evidencias deforma separada en dos dimensiones:

DIMENSIONES:

  • Dimensión técnica:  flexibilidad.
  • Dimensión organizativa:  fluidez.

FACTORES ANALIZADOS:

  • Ejes orgánicos.
  • Técnicas y prácticas de trabajo.
  • Capacitación técnica de las personas.

Las organizaciones que desean implantar o mejorar un entorno de trabajo ágil, necesitan una guía y criterios de referencia para identificar y analizar las áreas de mejora.

“Scrum Level cubre este objetivo, definiendo una guía de referencia y apoyo para mejorar la agilidad de las organizaciones”

En curso  se aprende el uso del modelo de evaluación y mejora Scrum Level, y se dispone de la guía, herramientas de protocolo y competencia necesarios para llevar a cabo procesos de evaluación con los que identificar las fortalezas y áreas de mejora en la agilidad organizativa de equipos y empresas. Es un curso eminentemente práctico.

Respecto al modelo de licenciamiento, derecho de uso del material y de la certificación, se distinguen tres niveles:

  1. Consultor independiente:
    El modelo y los materiales de Scrum Level se ofrecen con derechos de uso liberados (Creative Commons By). Pueden emplearse libremente en actividades profesionales de mejora o evaluación, con o sin ánimo de lucro.
  2. Consultor certificado:
    La certificación garantiza el conocimiento profesional del modelo Scrum Level adecuado para el desempeño en actividades de mejora o evaluación. Para conseguir la certificación es necesario aprobar el examen oficial de consultor Scrum Level que forma parte de los cursos profesionales de Scrum Manager®.
  3. Evaluador certificado:
    Profesional autorizado por ScrumLevel para realizar evaluaciones oficiales como evaluador responsable.
    Para ser evaluador certificado es necesario ser consultor certificado y acreditar los requisitos profesionales necesarios:

    1. Experiencia profesional mínima de 5 años en asesoría o gestión en organizaciones TIC.
    2. Experiencia profesional mínima de 3 años en asesoría o gestión en organizaciones TIC, y experiencia previa en evaluaciones Scrum Level independientes

Por otra parte, señalar que para los que hayáis realizado el curso de Scrum Manager, que la realización y superación del curso de certificado en  Scrum Level en un centro asociado os proporciona 65 PDUS válidos para el mantenimiento de la certificación  Scrum Manager. Recordad que Scrum Manager distingue entre Acreditación (examen aprobado con nota mínima de 8, pero no realizado ante centro asociado) y Certificación (examen aprobado con nota mínima de 8 y realizado en un centro homologado).

Usar técnicas y prácticas ágiles en un marco de producción sin una cultura ágil, no es propiamente agilidad, sino ingeniería concurrente (solapamiento de fases) con ciclo de vida incremental, o lo que se podría llamar “agilidad técnica”

 

Referencias:

 

 

 

 

 

 

 

 

 

 

LIBROS SOBRE GESTION DE RIESGOS EN PROYECTOS

Dado que uno de mis objetivos de este año a nivel de empresa es poner en marcha un sistema de gestión de riesgos en nuestra PMO (Oficina de Proyectos), me puse a explorar por Internet para ver material de apoyo y encontré estos dos libros de la autora Liliana Butchik que son objeto de la reseña.

La verdad es que me llamaron la atención, puesto que  no suele haber mucha literatura sobre este tema en idioma español.

Por eso los compré. Destaco que el único sitio donde pueden adquirirse “on line” es en la web de la autora, exactamente aquí: libros Secretos Riesgos en Proyectos

El envío tardó unos 15 días en llegar vía Correo Uruguayo y lo recibí sin problemas, lo mismo que otro libro que compré, “Secretos para Dominar el Portfolio de Proyectos” y del que más adelante escribiré su reseña.

El libro Secretos para dominar la gestión de riesgos sigue la metodología establecida por PMI acerca de la gestión de riesgos y está enriquecido por las experiencias personales de la autora, que trabajó en el staff de PMI USA

Destaco que tiene una sección de plantillas, pues se trata de un libro pero que muy práctico, cuyo objetivo es  ayudar a poner en marcha la gestión de riesgos en una empresa.

Sobre su nivel, está orientado a ser utilizado tanto por personas sin experiencia previa, como por profesionales que desean investigar más en alguna faceta particular del campo de la gestión de riesgos.

A destacar la parte referente a la sección de software orientada para gestionar riesgos. No es sencillo encontrar este tipo de información comparada.

Otro uso de este libro es para preparar la certificación de RMP-PMI. En este aspecto, se complementa  con el siguiente libro adquirido.

Secretos para salvar el examen RMP-PMI

Este libro tiene dos partes, de los capítulos 1 al 4 habla de qué es la certificación PMI-RMP, qué memorizar, qué dominio y habilidades requiere y una serie de consejos para afrontar con garantía el examen.

La segunda parte (capitulo 5) se corresponde a trescientas  preguntas, muy similares a las que se pueden esperar en el examen oficial de PMI.

Una  vez leídos ambos libros, destaco que me han gustado mucho, me ha interesado especialmente su enfoque práctico, es decir, que la lectura sea util.  Un gran valor añadido está en la experiencia aportada por la autora. Por sacarle alguna pega, pediría que las plantillas estuvieran disponibles para su descarga, (manteniendo su autoría) pues esto evitaría tener que elaborarlas manualmente una a una.  Pero mi experiencia leyendo los libros ha sido muy positiva. Me gustaría que hubiera disponible más material de esta calidad en idioma español.

Ah, y si la autora se decidiera a escribir sobre su experiencia gestionando proyectos bajo metodologías ágiles, ya tiene un ejemplar vendido.

 

 

 

 

 

 

 

 

 

 

CERTIFICACION PRINCE2 PRACTITIONER

¿QUÉ ES PRINCE2?

Después de haber realizado la certificación de Scrum Level y para cerrar el círculo de las metodologías, me propuse conocer lo que me podía aportar Prince2 Practitioner a la gestión de proyectos.

Para superar los exámenes de Prince2 no es obligatorio pasar un curso en un preparador oficial (como se exige en la certificación PMP) pero es muy recomendable realizarlo. Asi que, junto con un compañero de trabajo, me matriculé en un curso de preparación de la certificación Prince2. El examen de certificación se planificó para enero de 2017.

¿Que es Prince2?. La web de QRP lo define así:  “Es un método estructurado de gestión de proyectos. Es una aproximación a las “buenas prácticas” para la gestión de todo tipo de proyectos que se ha convertido en el estándar de facto para la organización, gestión y control de proyectos El método divide los proyectos en fases manejables permitiendo el control eficiente de los recursos y el control periódico de su evolución. PRINCE2 está “basado en los productos”, es decir, los planes del proyecto se centran en obtener resultados concretos, y no sólo en la planificación de las actividades que se llevan a cabo; PRINCE2 proporciona un lenguaje común en los proyectos.”

Más que un conjunto de buenas practicas (como es el PMBOK de PMI), PRINCE2 propone una metodología específica de gestión de proyectos, es decir, cubre todas las temáticas y propone cómo llevarlas a la práctica.

PRINCE2 es el estándar de facto para la gestión de proyectos en varios países, empresas privadas y organizaciones, especialmente en el Reino Unido. Es la metodología seguida, por ejemplo, por la EUIPO.

CERTIFICACIONES:

Existen dos niveles de certificación:

  • Foundation: certifica el conocimiento de la terminología y metodología de gestión de proyectos con PRINCE2
  • Practitioner: certifica la capacidad para gestionar proyectos según la metodología PRINCE2. Se necesita aprobar el nivel Foundation para presentarse a este nivel.

Un apunte, si ya dispones de uno de estos certificados: CAPM, PMP o IPMA no es necesario examinarse previamente del nivel Foundation, pues se convalida automáticamente.

Adicionalmente, Prince2 también dispone de una solución enfocada al mundo Agile. Esta certificación proporciona la guía para adaptar PRINCE2 en un contexto ágil e incluye:

  • Cómo adaptar el conjunto integrado de principios, temáticas y procesos de PRINCE2
  • La forma de crear los productos de gestión de PRINCE2
  • Cómo mapear los roles ágiles a la estructura de equipo de gestión de PRINCE2
  • La manera de incorporar los comportamientos, conceptos y técnicas ágiles fundamentales dentro de PRINCE2

Durante el año 2017 se produjo una gran actualización de Prince2, tanto a nivel de guía como de exámenes. Una de las consecuencias de este cambio es que los exámenes ya no están disponibles en español.

FUNDAMENTOS:

No es mi intención hablar en detalle de la metodología, pues existen otros blogs donde detallan este punto, solo destacar que Prince2 se basa fundamentalmente en:

  • Siete temáticas:
    1. Caso de negocio: manera en que se desarrolla una idea hasta convertirse en un proyecto viable para la organización.
    2. Organización: puestos, funciones y responsabilidades del equipo encargado de ejecutar el proyecto.
    3. Calidad: Se ocupa de desarrollar la comprensión de los interesados respecto a los atributos de calidad de los productos a entregar.
    4. Planes: Describe los pasos requeridos para desarrollar los planes establecidos y las técnicas de PRINCE2 que se deben aplicar.
    5. Riesgo: gestión de las incertidumbres en sus planes.
    6. Cambio: cómo se evalúa y actúa para incorporar los posibles cambios a la línea base del proyecto
    7. Progreso: proceso de toma de decisiones para aprobar planes, seguimiento del avance real y el manejo de excepciones cuando los planes no se cumplen.
  • Siete procesos:

    1. Puesta en Marcha de un Proyecto.
    2. Dirección del Proyecto.
    3. Inicio del Proyecto.
    4. Control de Fase.
    5. Gestión de la Entrega de Productos.
    6. Gestión de los Límites de Fase
    7. Cierre de Proyecto
  • Siete  principios (que se deben seguir obligatoriamente):
    1. Justificación comercial continua
    2. Aprender de la experiencia
    3. Roles y Responsabilidades definidos
    4. Gestión por Fases
    5. Gestión por excepción
    6. Orientación a productos
    7. Adaptación al entorno del proyecto (un proyecto de PRINCE2 se debe adaptar al tamaño, el entorno, la complejidad, la importancia, la capacidad de la empresa y el riesgo del proyecto).

EXÁMENES:

Ahora vamos a hablar de los exámenes de las dos certificaciones:

  • El examen Foundation:
    • Se puede hacer on line.
    • Duración: una hora
    • Nivel de dificultad: es bastante sencillo
    • Material permitido: ninguno
    • Son 75 preguntas. Se necesitan 35 aciertos para aprobar
    • Renovación: no es necesario
  • El examen Practitioner:
    • Duración: son dos horas y media. Os aseguro que no sobra ni un minuto de tiempo. Se debe gestionar bien el tiempo para evitar sorpresas desagradables.
    • ¿Su nivel de dificultad? Pues depende, si se compara con el examen PMP de PMI  el Practitioner es mucho más sencillo pero exige dedicación y conocer los tipos de preguntas de las que se compone el examen.
    • Se basa en un escenario. Por eso es muy interesante poder realizar el examen en papel, en lugar de escoger hacerlo on line, pues es muy recomendable tener a la vista la información de cada pregunta y también del escenario propuesto.
    • Tipos de pregunta:
      • Con una respuesta correcta
      • Con múltiples respuesta y se deben escoger dos.
    • Material permitido: el manual original y oficial del año 2017: “Éxito en la gestión de proyectos con Prince2
    • Son 80 preguntas. Se deben conseguir 44 aciertos
    • Renovación: cada 5 años
    • En 48 horas ya se proporciona la nota del examen

En este sitio web puedes encontrar unos excelentes Consejos para aprobar.

CONCLUSIÓN:

Lo que me ha gustado de Prince2:

  • El enfoque basado en el Business Case. Un proyecto debe tener una justificación comercial continua.  Esto significa que la razón para iniciar el proyecto debe tener sentido desde un punto de vista empresarial y debe haber un claro retorno de la inversión. El “Business Case” se debe revisar periódicamente durante toda la vida del proyecto para comprobar su continua justificación para el negocio. Si la justificación desaparece,  el proyecto debe cerrarse.
  • La gestión por excepción. Las tolerancias a los cambios están perfectamente definidas. Esto proporciona cierta independencia al director de proyectos para tomar decisiones, siempre que se esté dentro de las tolerancias establecidas dentros de las normas de gestión del proyecto.
  • Al ser una metodología (y no un conjunto de buenas prácticas como el PMBOK) si no se dispone de experiencia en proyectos, aporta una guía y un marco para gestionar el proyecto, que es aplicable desde el primer momento. Esto es una gran ayuda para los que se inician en la gestión de proyectos, pues Price2 les va a guiar punto por punto desde el principio hasta el final del proyecto.
  • Prince2 prefiere que el Project Manager se centre en el producto/proyecto y no se implique en la realización de tareas técnicas (se separan las capas técnica y de gestión).

Lo que veo mejorable:

  • El responsable del proyecto y del éxito del mismo es la Junta del Proyecto (Directivo, Usuario Principal y Proveedor Principal) . El Project Manager es responsable de dirigir el día a día del proyecto. Puede parecer un “secretario de lujo” de la Junta de Proyecto.
  • No incluye la administración o desarrollo de los Requerimientos. Estarían incluidos dentro de la temática de “Calidad”.
  • Da por sentado que se conocen conceptos que requieren tener conocimientos previos en materia de proyectos. Por ejemplo, el WBS (Work Breakdown Structure) o el PBS (Product Breakdown Structure)

RECURSOS:

 

 

 

 

 

 

 

 

 

CERTIFICACIÓN SCRUM MANAGER

Después de leerme un par de libros sobre Scrum decidí que era momento para tomar una certificación.

Después de buscar un poco por Internet, comprobé que hay tres certificaciones que sobresalen del resto:

  • Scrum Alliance
  • Scrum.org
  • Scrum Manager

El modelo de Scrum Alliance es con diferencia el más conocido (fue creado por los fundadores de Scrum) se basa en cursos de dos jornadas presenciales (que son obligatorias) y un examen muy sencillo que se puede hacer desde casa. Este es uno de los puntos más criticados de este modelo.

De Scrum.org me llamaron la atención varias cosas:

  • Que lo fundó uno de los creadores descontentos de  Scrum Alliance (Ken Schwaber).
  • Que ni siquiera está traducido al español. Este es un punto negativo a tener en cuenta.
  • No es necesario haber tomado ningún curso para poder examinarse de la certificación. Eso sí, tiene fama de tener los exámenes más duros (y en inglés) especialmente PSM II.

Y busqué información sobre Scrum Manager y lo que encontré me hizo decidirme por esta certificación:

  • Tiene una de las comunidades de apoyo más activas de España y Latinoamerica.
  • La diferencia entre Scrum técnico y Scrum avanzado es un enfoque muy interesante.certificacion_scrum_manager
  • Sus cursos oficiales presenciales no son obligatorios. Se puede tomar el examen sin  pasar por ellos.
  • El manual en el que se basa su curso es gratuito y público. Se puede descargar desde aquí en formato Epub y PDF: …Manual SCRUM MANAGER.
  • El enfoque del curso de ampliación llamado  Scrum Level es decir, del “Modelo de Evaluación y Mejora de la Agilidad Organizacional” me parece muy interesante. Es muy difícil tener éxito en un proyecto ágil sin que la empresa esté formada en estas prácticas.
  • Me gustó su declaración de intenciones: “Scrum Manager no forma “gestores técnicos”: gestores conocedores de marcos de Agilidad con la implantación de las correspondientes reglas y técnicas. Scrum Manager forma “gestores expertos” que lejos de radicalizarse en el “agilismo”, amplían su inventario de conocimiento y práctica de gestión con las aportaciones de la Agilidad, facilitando así la creación de su propia síntesis de conocimiento para mejorar la gestión de su entorno“.

Y me puse manos a la obra.

Su formación sigue el esquema de dividir los diplomas en Certificación (si se examina uno en un centro asociado) o Acreditación (si se toma  el examen de la web sin ninguna supervisión).

Lo primero es darse de alta en su web. Se debe aprobar la llamada “parte troncal” de la certificación.

Para aprobar la parte “troncal” se puede recurrir a un curso de apoyo de un centro certificado (cuyo coste oscila entre unos 500 €)  o acceder al curso on line (disponible todo el año) en el apartado E-Learning de su web y que cuesta unos módicos 40 € (IVA incl.)

El curso “on line” está formado por doce lecciones, seis prácticas y un examen. Si se aprueba  este examen se obtiene la Acreditación y 150 PDA (puntos de autoridad) similares a los PDU del PMP.

Para obtener la certificación se debe tomar el examen presencialmente en un centro examinador autorizado (que cuesta sobre 180 euros) o hacerlo desde la web pero en un centro que disponga del sistema de  supervisión web. Se debe obtener un 70 % de rescertificado_2_largepuestas válidas para aprobar el examen presencial.

El examen si se prepara bien no es complicado de aprobar. Ayuda mucho la batería de las preguntas de prueba que se pueden comprar  en la propia web de Scrum Manager.

Los 150 PDA (puntos de autoridad)  que se obtienen por haber aprobado la certificación otorgan el nivel de “Experto”. Estos PDA se van perdiendo a razón de un 20% por año. Se pueden incrementar realizando cursos adicionales ( y se puede pasar al nivel “Autoridad” que implica disponer de más de 200 PDA).

 

 

 

NORMA ISO 21500 SOBRE GESTIÓN Y DIRECCIÓN DE PROYECTOS

Llegó a mi poder información acerca de la norna ISO 21500 sobre Gestión y Dirección de Proyectos y me pareció interesante profundizar en la misma.

Objeto y campo de aplicación de esta norma:

  • Describir conceptos y procesos que se consideran que forman parte de las buenas prácticas en dirección y gestión de proyectos.
  • Ayudar a las organizaciones de cualquier sector económico, que tengan que desarrollar proyectos de cualquier tamaño, a alcanzar sus objetivos de negocio.
  • Contribuir a un correcto desarrollo de los proyectos, mejora en su calidad y en el cumplimiento de plazos y costes

 

La norma va dirigida a:iso215001

  • Alta dirección y patrocinadores de proyectos para ayudar a dar apoyo y orientación a sus directores de proyecto, equipos de dirección de proyectos y equipos de proyecto.
  • Directores de proyecto, equipos de dirección de proyectos y equipos de proyecto ya que tendrán una base común para poder comparar sus normas y prácticas de proyectos con las de otros.
  • Redactores de normas, como base para el desarrollo de normas sobre gestión de proyectos, de modo que sean consistentes unas con otras.

Para su elaboración se tuvieron en cuenta los siguientes estandares:

  • PMBOK. Project Management Body of Knowledge
  • ICB. International Competence Baseline
  • PRINCE2. Project in Controlled Environments5affd11ab6
  • P2M. Project and Program Management for Enterprise Innovation
  • BS 6079 partes 1 a 4. Guide to Project Management
  • DIN 69901 partes 1 a 5. Project Management. Project Management Systems
  • ISO 10006. Quality Management Systems. Guideline for Quality Management in Project
  • AS 4915. Project Management. General Conditions

Y manos a la obra, me matriculé en un curso de Auditor Interno de ISO 21500 sobre Dirección y Gestión de Proyectos de una conocida empresa del sector.

Según se comenta en la web del curso “La auditoria de gestión de proyectos es una herramienta de gestión empleada por las organizaciones para evaluar la eficacia de su sistema de gestión de proyectos conforme a las directrices establecidas por la Norma ISO 21500:2013. Todo ello con el objetivo de establecer y mejorar sus políticas, objetivos y procesos, así como velar por una adecuada aplicación de los métodos, herramientas, técnicas y competencias para una eficiente dirección y gestión de los proyectos que acometen las organizaciones. Así pues, las auditorías del sistema de gestión de proyectos ofrecen a las organizaciones confianza sobre la eficacia de su sistema de gestión y su capacidad para cumplir los requisitos de las partes interesadas o stakeholders. Igualmente, las organizaciones pueden acceder a la obtención de certificados de gestión de proyectos a través de un proceso de auditoria, el cual debe ser llevado a cabo por una entidad de certificación.”

Este curso se divide en dos asignaturas bien diferenciadas:

  • Metodología para la Dirección y Gestión de Proyectos Basada en ISO 21500:
    • Esta parte busca que el alumno conozca el sistema de dirección de proyectos.
    • Si se ha aprobado alguna certificación en materia de proyectos, (PMP o Prince 2) esta parte es muy sencilla.
  • Auditoria y Certificación de Sistemas de Gestión y Dirección de Proyectos según ISO 21500. Esta asignatura se orienta a:
    • Aplicar los conocimientos sobre auditorías de proyectos en cualquier organización para verificar el cumplimiento de su Sistema de Gestión.
    • Poder asumir responsabilidades en cualquier etapa del proceso de auditoría.
    • Conocer las funciones y competencias que debe tener un auditor tanto en auditorías internas como en auditorías de certificación.
    • Conocer el proceso de certificación en una organización.
    • Reconocer las características y problemas más habituales en la consecución de la certificación de gestión de proyectos.

Este curso permite disponer del Certificado de Auditor Interno de Sistemas de Gestión de Proyectos ISO 21500 (con examen final)

Para la empresa esta norma puede tener un  gran valor añadido. pues ya es posible que empresas individuales se certifiquen en gestión de proyectos. Puede ser un potente argumento de venta. La primera empresa en certificarse  fue Sach Consultores. Más abajo disponéis de una entrevista a la General Manager de Sach Consultores.

Enlaces interesantes:

CERTIFICACIÓN PMP®

Antecedentes:

Después de haber pasado por un período de “Coaching” en materia de proyectos a cargo de una consultora, en mi empresa estábamos pensando en la posibilidad de seguir mejorando en el  desempeño en materia de proyectos de los Project Managers.

PMP

Y nos pareció una buena idea preparar la certificación PMP, es decir, la certificación Project Management Professional  que expide el Project Mangement Institute (PMI)

Dicho y hecho. A mi me tocó romper el hielo y ser el primero en preparar la certificación.

Requerimientos para poder examinarse:

Hay que acreditar los siguientes puntos:

  • Justificar el nivel de estudios, pues la horas exigidas de experiencia profesional dependen del nivel de estudios:
    • Acreditar 4.500 h de experiencia profesional en gestión de proyectos si se posee una diplomatura o superior.
    • Acreditar 7.500 horas en caso contrario.
  • Completar un curso de 35 h de formación en materia de Dirección de Proyectos.
  • Cumplimiento del Código de Conducta Profesional del Director de Proyectos.

Lo primero que hacía falta: tomar un curso de 35 horas de duración a cargo de un preparador homologado por el PMI para dar ese cursillo.  Buscamos  y encontramos un preparador cerca de la empresa y con muy buenas referencias de aprobados: Wolf Project.

diploma_certificacion_pmp

Es muy interesante darse de alta como miembro del PMI en su web, pues esto te permite obtener una buena rebaja en los derechos de examen, así como te permite descargar material interesante de su intranet. Es imprescindible bajarse un ejemplar del PMBOK. También merece la pena hojear los ejemplares de sus publicaciones PMI Today y PMI Network.

Durante las horas obligatorias de clase se busca una aproximación  al mundo de los proyectos, en especial al enfoque que marca el PMI.

Una puntualización importante: todos los ejemplos están basados en empresas americanas de tamaño medio grande, por eso choca con nuestra experiencia en empresas españolas. Es más, los test realizados durante las primeras clases suelen ser decepcionantes por no se respondidos adoptando el punto de vista de una empresa americana. Son los llamados PMIsmos (ideas o planteamientos que se presuponen para el examen), en el libro de Rita existe un apartado que los estudia.

Es importante destacar que completar el proceso de inscripción dentro de la web de www.pmi.org es un trabajo laborioso y que requiere unas cuantas horas de dedicación. Es mejor reservar dedicación suficiente para hacerlo.

Además, el PMP puede auditar en cualquier momento toda la información contenida en la solicitud. Suele tocar auditoria a uno de cada cuatro alumnos.

Material empleado para la preparación de la certificación:

  • PMBOK. Por supuesto. Pero no es suficiente para aprobar.Project Management - Business Concept. Green Arrow with "Project Management" Slogan on a Grey Background. 3D Render.
  • PMP Exam Prep Rita Mulcahy, 8ª edición. Es la base de la preparación, complementado con la lectura del PMBOK . Dispone de exámenes que hay que realizar un par de veces cada uno. Es interesante sacar un 85 % de nota en ellos antes de presentarse al examen
  • Apuntes de las clases del preparador. Muy interesantes, pues con ellos se pueden hacer resúmenes muy útiles en los últimos días antes del examen.
  • Head First: PMP, de Jennifer Greene. Es un libro muy básico pero es muy útil para los que desconocen alguno de los conceptos que se manejan.
  • Simuladores de examen:
    • Existen muchos. Son de dos tipos: basados en web o instalables bajo windows. He probado los dos y prefiero los basados en web pues están mucho más actualizados.
    • Utilicé el simulador instalable de Rita Mulcahy (RMC Project) en su versión 6 y me pareció muy desactualizado.
    • Recomiendo el simulador on line de Pablo Ledó que es de pago pero es muy útil para hacer test un poco diferentes a los del libro de Rita Mulcahy.
    • También son interesantes los simuladores de UDEMI, aunque los hay de calidad desigual. Mejor fiarse de las valoraciones de los usuarios.

 

Tipos de examen:

  • PBT, basado en papel:
    • Los preparadores hacen grupos para poder examinar “en papel”.
    • Se puede hacer tanto en español como en inglés.
    • La nota se entrega en un par de semanas.
  • CBT, basado en ordenador:
    • Es más caro. Puede hacerse en cualquier centro homologado de Prometric.
    • Se puede hacer tanto en español como en inglés.
    • La nota se entrega una vez finalizado el examen en el acto.

Nivel de dificultad:

  • Alto. Requiere dedicación y es difícilmente compatible con el desempeño laboral. Lo ideal es tomar unos días libres para prepararlo.
  • Son cuatro horas de examen, que se dice pronto. Se debe practicar progresivamente hasta llegar a hacer varios exámenes completos y en parecidas condiciones que el examen real.
  • Requiere tener muy claro el escenario del examen, es decir, una empresa americana de tamaño medio/grande.
  • Muy interesante conocer y asumir los PMismos es decir,  principios que el PMI asume como ciertos y que hay que conocer y entender para afrontar el examen de certificación, por norma general están localizados en la bibliografía relacionada (por ejemplo en el libro de Rita Mulcahy o en el PMBOK). Son importantes porque nos ayudaran a situar el marco de la pregunta del examen e incluso puede en algunas ocasiones ayudarnos a descartar alguna respuesta incorrecta.

Lo mejor de la certificación PMP:

  • Proporciona un visión muy completa de la gestión de proyectos. Incluye todas las posibilidades de gestión.
  • Proporciona un lenguaje común en el que se pueden entender proveedores y clientes.
  • Hay metodologías que se remiten al PMBOK para gestionar ciertas materias donde ellos no llegan o no quieren llegar. Es un excelente complemento.

Lo mejorable:

  • No es la mejor forma de acercarse a la disciplina de la gestión de proyectos. Es recomendable tener conocimientos previos.
  • Al ser el PMBOK un compendio de buenas prácticas (y no una metodología), no proporciona una forma definida de hacer las diferentes tareas en el día a día del proyecto.

Actualización:

GESTIÓN DE PROYECTOS EN EL MUNDO REAL

Título original: Your Project Management Coachbiafore

Autores: Bonnie Briafore, Teresa Stover

Editorial: Anaya Multimedia/ Viley, año 2012, 448 páginas

ISBN: 978-84-415-3225-0

Palabras clave: Proyectos, Metodología, PMP, Project Management

No hay muchos libros en el mercado que traten el tema de la gestión de proyectos, así que este libro me llamó mucho la atención cuando lo vi. Le eché un  vistazo y decidí comprármelo. Eso si, lo compré a pesar de que se trata de otro caso de cambio del titulo original por otro que no tiene nada que ver.

El libro me lo leí antes de que me examinara para obtener la certificación PMP del PMI. Ahora lo hubiera leído con otra actitud.

Se tata de un libro dirigido a personas con algunos conocimientos previos de gestión de proyectos. Al principiante le va a resultar un poco difícil entender algunos conceptos que se presuponen en ese libro. Lo escribe una persona que es PMP y que tiene

El libro se divide en las mismas partes que los grupos de procesos del PMBOK:

  • La Parte I está compuesta de una introducción de lo que es y lo que no un proyecto, así como qué es gestionar un proyecto.
  • La Parte II se refiere a la planificación y nos habla de qué es un plan de proyectos,cómo identificar los trabajos de un proyecto, cómo estima trabajos y costes, cómo planificar recursos, cómo establecer el cronograma, cómo gestionar la calidad, escribir el Plan de Comunicación, el plan de gestión de cambios, los riesgos
  • imagesLa Parte III está dirigida a los procesos de ejecución
  • La Parte IV habla de la monitorización y control
  • La Parte V  se refiere al cierre. Incluye cómo documentar el proyecto y cómo cerrarlos.

Una de cal, lo mas flojo de todo el libro es el capítulo Nº 13 (Parte II) que habla de la puesta en marcha y que describe la obtención de aprobación, seleccionar el equipo y eventualmente, seleccionar al proveedor.

Y otra de arena, en el capítulo Nº 8 (Parte II) se habla del calendario y de la ruta crítica, y menciona la idea de que el diagrama Gantt no es el proyecto. Esta es una gran verdad que ha hecho mucho daño a muchos proyectos.

Como información extra, también contiene ideas acerca de cómo crear una PMO en una empresa y los motivos por los cuales es una buena decisión.

Destaco que dentro de los capítulos hay excelentes anotaciones que son fruto de la experiencia y que hacen mas valioso el contenido, por ejemplo, el autor destaca que las “Lecciones aprendidas” es una de las partes más importantes de la gestión de los proyectos, pero que hay que ser muy cuidadoso para que los objetivos o incentivos del Project Manager y del equipo no impacten con ellas, pues de otra forma nos encontraríamos con una simple descripción de lo bien que se realizó el proyecto, eludiendo cualquier tipo de análisis o crítica.

Otro detalle a destacar, menciona  lo que son preguntas específicas del examen PMP, por ejemplo, las fases en el desarrollo de un equipo de trabajo de Bruce Tuckman. Pero hay que hacer una advertencia, con este libro no es suficiente para prepararse para el examen PMP . Hace falta bastante más material adicional para poder tener éxito en el examen.

Muy interesantes y aprovechables son las plantillas para obtener soporte a las tareas habituales de gestión del proyecto, que se ofrecen para ser descargadas directamente de la web de Anaya Multimedia.

Es de agradecer que es un libro claro, conciso y escrito con un lenguaje que todo el mundo puede entender.

Como conclusión, un libro muy recomendable para profundizar en el mundo de la gestión de proyectos.

Valoración: 8/10

 

LIBRO: LEGAL PROJECT MANAGEMENT

Título originalLegal Project Management

Autores: Anna Marra

Editorial: Rasche, año 2012, 140 páginas

ISBN: 978-84-15560-06-7

Palabras claveProyectos, Metodología, PMP, Legal Project Management

Este libro aborda una tendencia que nace en USA, Canadá, Reino Unido y Australia y que se está extendiendo por el mundo, el Legal project Management (LPM), que, según la Wikipedia,  se define como la “aplicación de los conceptos de gestión de proyectos para el control y gestión de casos legales o asuntos“.

Su autora es Anna Marra, una abogada italiana, que también es Directora académica del Programa de Desarrollo “Legal Project Management”, organizado por IE Law School.

Vayamos pues a lo que nos cuenta el libro. Un primer detalle es que no existe un índice del libro,meste es un punto mejorable. La obra está dividido en dos partes: 1.- Hablamos de LPM y 2.- Aplicamos  el LPM.

Y hace una importante reflexión en la página 63, este libro solo pretende ser una introducción al LPM. Para profundizar se deben buscar otras fuentes.

Entrando en la parte 1.- “Hablamos de LPM”,  Anna Marra comenta que la situación de partida en el mundo de los bufetes es la de ser un sector caracterizado por cierto inmovilismo. Se trata de un sector que solo ha considerado superficialmente la necesidad de adaptarse al nuevo contexto social y económico. En resumidas cuentas, el sector legal se resiste al cambio. En este punto, el LPM puede ser una ventaja competitiva para los despachos que lo adopten.

La autora detalla las ventajas que pueden obtener los despachos de abogados del uso del LPM. Los bufetes de abogados que se benefician especialmente de la gestión de proyectos  son los que trabajan bajo acuerdos de honorarios alternativos tales como honorarios fijos o planos o con límites de coste.

Por otra parte, los clientes de bufetes que han adoptado el LPM se benefician de que la información es más transparente (en especial los costes están más detallados) y que se reducen las incertidumbres propias de los servicios jurídicos  en cuanto a alcance, coste y ejecución.

Ventajas del LPM (fuente: programa de LPM de IE):

  • Alinea la práctica organizativa a la estrategia y cultura del despacho.
  • Permite prever costes y beneficios, aumentando la rentabilidad.mazo
  • Permite asignar los recursos necesarios atribuyendo responsabilidades y tareas.
  • Permite saber cuántos recursos estarán ocupados, cuándo y por cuánto tiempo.
  • Reduce o elimina el nivel de incertidumbre, a través de una correcta identificación de los riesgos.
  • Permite gestionar el cambio.
  • Mejora el proceso de control y seguimiento desde el inicio hasta el cierre del encargo.
  • Mejora la comunicación con el cliente generando más confianza y satisfacción.
  • Permite centrarse en las verdaderas necesidades del cliente y ofrecer la solución más
    apropiada.
  • Evita desperdicio de recursos.
  • Mejora el ambiente de trabajo

Dicho esto, la autora introduce en el libro las ideas básicas de la gestión de proyectos como es la triple restricción (tiempo, coste, calidad), las estructuras empresariales con las que debe contar la gestión  de proyectos, las áreas de conocimiento (alcance, tiempo, coste, riesgo, calidad, rrhh, comunicación, adquisiciones, integración).

Un detalle importante que remarca la autora es que por la misma naturaleza del trabajo que desempeña, el abogado no puede comprometerse a obtener un resultado determinado, (a diferencia de otros sectores como la construcción o la informática). Puede parecer que esto iría  en contra de abrir un acta de constitución del proyecto, pero no sería  un problema, le bastaría con actuar con la “diligencia debida” en el desarrollo de su labor.

El segunda parte del libro “2.-Aplicamos el LPM”, se aplica la gestión de proyectos a un caso jurídico ficticio basado en dos sentencias del Tribunal Supremo: una empresa compra a otra un terreno afectado por residuos tóxicos y le reclama que abone los gastos de limpieza de los mismos. Desde que el cliente entra por la puerta del despacho, se busca enfocar los trabajos tal y como se realizarían gestionando el caso como un proyecto. Esta es quizás la parte más interesante del libro.

Como conclusión, el libro deja con ganas de conocer más sobre el LPM. Con la información que proporciona el libro un abogado puede hacerse una pequeña idea de lo que es la gestión de proyectos, pero es absolutamente insuficiente para aplicar el LPM a un despacho. Eso si, la autora ya avisó de que esto es una introducción al LPM.

Sospecho que el LPM va a ser una tendencia imparable en el mundo legal. Los clientes van a desear trabajar con bufetes que les proporcionen información sobre su caso que ellos puedan entender.

Un ejemplo: el departamento de servicios jurídicos de Telefónica España ya apuesta por el LPM.

Un desafío interesante es analizar cómo combinar el mundo agile de gestión de proyectos con el LPM.

Enlaces interesantes sobre el LPM: