LIBRO CADENA CRÍTICA

Título original: Critical Chain

Autor: Eliyahu M. Goldratt

Editorial: Ediciones Díaz de Santos, año 2014 (kindle)

Páginas: 296

Idioma: español

ISBN: 9788479784843

Palabras clave: Proyectos, gestión recursos, ruta crítica, cadena crítica

En esta entrada voy a hablar de “Cadena Crítica”, un libro que ha obtenido la categoría de clásico en la materia de la gestión de proyectos y cuya edición impresa data de de más ni menos que del año 1997. Y el caso es que ya conocía la teoría de la cadena crítica de haberla estudiado para la certificación PMP (un par de preguntas fueron de esta materia).  Y aún así, su lectura me ha sorprendido. Mil gracias, Juan Carlos, por proporcionarme el libro.

El autor (Eliyahu M. Goldratt) es el creador de una serie de libros de Management y creador de la Teoría de las Restricciones (TOC). Este libro “Cadena Crítica” fue dedicado por su autor a la aplicación de TOC a la materia de la gestión de proyectos. Se ha convertido en la base de la teoría de la cadena crítica, apta para un esquema de limitación de recursos.

La lectura es novelada. No es muy habitual en libros de Management, pero eso hace que se lea con interés. Además de ser interesante para la gestión de proyectos, también es interesante para formadores que desean un enfoque diferente para sus clases. Esto se debe a que el relato presenta a un profesor que busca conjugar el conocimiento teórico de la universidad  en el entorno de la impartición de un MBA con las situaciones que le presentan sus estudiantes, procedentes de su día a día en sus empresas. Al final, estamos en presencia de interesantes clases de descubrimiento del conocimiento. Un  tema secundario que subyace en el libro está de plena actualidad, ¿Están preparadas las universidades para entregar verdadero conocimiento práctico a las empresas?.

Hablando ya de la gestión de los proyectos, en las clases se duda de la eficiencia de medir el grado de avance de los proyectos como medida eficaz para establecer su progreso. Irónicamente, el proyecto puede estar al 90% de progreso una vez transcurrido un año, y luego emplear otro año para cumplir con el restante 10 %. Si se pierde el foco en la ruta crítica ( secuencia de los elementos terminales de la red de proyectos con la mayor duración entre ellos, determinando el tiempo más corto en el que es posible completar el proyecto), entonces es fácil que se produzca retraso, pero que no se sepa, que es lo peor de todo.

El mensaje está claro, es un error el modo en el cual medimos el avance de los proyectos, pues:

  1. Las mediciones deberían inducir a las partes a hacer lo que sea bueno para para el sistema entero
  2. Las mediciones deberían de guiar a los gerentes hacia los puntos que necesiten su atención.

Por lo tanto, la conclusión a la que llegan en las clases es que en los proyectos las mediciones alejan al líder del proyecto.

A través de un técnico que trabajó en otra empresa, los protagonistas conocen la teoría de las restricciones (TOC). El autor del libro había sentado las bases de la TOC en su libro previo (1984) “La Meta, Un proceso de mejora continua”. Sus características son tres:

  1. Es una nueva filosofía gerencial
  2. Es un método de investigación
  3. introduce un amplio espectro de aplicaciones

La metodología de esta teoría se basa buscar la limitación del sistema estudiado y se compone de cinco puntos:

  1. Primer paso, identificar las restricciones del sistema  (el eslabón más débil)
  2. Segundo paso, diferenciar las restricciones físicas y políticas
  3. Tercer paso, subordinar todo lo demás a la decisión tomada
  4. Cuarto paso, elevar (superar) las restricciones del sistema
  5. Quinto paso, si se rompe una restricción, no permitir la rutina y volver al primer paso

Existen tres posibles tipos de limitaciones:

1. Limitaciones físicas: son por ejemplo los recursos personales o materiales

2. Limitaciones políticas: son por ejemplo las reglas empresariales

3. Limitaciones de mercado: por ejemplo los producidos por el propio mercado al que se dirige la empresa

La TOC exige definir un problema con precisión, pues un problema no está bien definido hasta que no puede representarse como un conflicto entre dos condiciones necesarias.

Otra experiencia que aportan los estudiantes del relato es el de tener prevención con los indicadores operativos obsoletos (en la novela se habla de la medición de tonelada/hora de la industria metalúrgica) . La gente se comporta según se la mide.

Para resolver problemas, el método que introduce la TOC es el de la “evaporación de las nubes“,  es decir,  proponer una estructura lógica diseñada para identificar e ilustrar todos los elementos en una situación conflictiva o dilema y sugerir formas de resolverlas. Por ejemplo, no puede haber arreglos a medias (un edificio o mide 30 o 40 metros, pero no se puede dejar a la mitad, pues esto es lo que pasaría si se tratara de optimizar la respuesta).  Si se detectan  situaciones ganar-perder, es porque no se está observando adecuadamente el problema: ganando en amplitud, identificaremos la situación ganar-ganar. Al estudiar y comprobar las suposiciones adyacentes es posible encontrar  soluciones en las que ambas partes ganen (win to win), y nos permitan “Evaporar la nube”.

Otra cosa que descubren los estudiantes del relato es que en sus propias empresas nadie quiere reconocer que mete un factor de protección en sus estimaciones de tiempo de las tareas que componen los proyectos. Es más, a mayor incertidumbre mayor protección se suele añadir. Y los managers agregan su propio factor de protección. Así las estimaciones de tareas de un proyecto están realmente infladas. Pero ¿que es lo irónico de todo esto?. Pues que si las estimaciones incluyen tanta protección, ¿Por qué tantos proyectos no se acaban a tiempo?. La conclusión a la que llegan los estudiantes en las clases es sencilla: si las tareas se acaban antes de lo planificado las siguientes no se inician antes, por lo que este tiempo se desperdiciará. Es decir, las demoras se acumulan, pero lo avances no.

Otros factores destacados que se suman para hacer que la protección se desperdicie son:

  • El síndrome del estudiante. Es decir, retrasar las tareas hasta las últimas fechas y pedir mas plazo para hacer un mejor trabajo.
  • La multitarea y el robo de tiempo que implica, por el gran trabajo que cuesta volver a enfocarse cuando se trabaja en múltiples proyectos a la vez
  • Las dependencias entre las tareas, pues las dependencias son las verdaderas culpables de que las demoras se acumulen, pero los retrasos se desperdicien

La idea surgió casi por sí sola, poner amortiguadores (o buffers) protegiendo la ruta crítica y claro está, teniendo cuidado de que las tareas que no estén en la ruta crítica se convierta en parte de ella. La experiencia dice que la ruta crítica cambia durante el proyecto.

Existen tres tipos de buffers:

  • Buffer de Proyecto: Para proteger el camino o ruta crítica del proyecto.
  • Buffers de Alimentación: Para proteger las tareas que podrían  convertirse en camino crítico en un futuro
  • Buffers de Recursos: se protege la cadena crítica avisando a los recursos críticos del comienzo inminente de sus tareas. Es una tarea virtual que queda insertada justo antes de las actividades de la cadena crítica, cuando requieren de la utilización de recursos de idéntica importancia.

Un problema especial se puede producir con las entregas de los proveedores. No están condicionados a entregar a tiempo sino que compiten en base al precio. En sus estimaciones de entrega se ponen un generoso colchón de tiempo para resolver conflictos entre los pedidos. Pero las demoras en la entrega cuestan mucho dinero a las empresas contratantes. La idea para solucionare esto es añadir a las RFP un “precio tope” pero también un “tiempo tope”. Es interesante no dar una fecha de finalización al proveedor para evitar el mencionado “síndrome del estudiante” .

Respecto a la gestión de los recursos, hay que entender que la restricción es la cadena más larga entre pasos dependientes, tanto de tareas como de recursos. En este punto hay que tener cuidado, pues si si existe competencia por los recursos, entonces la cadena crítica puede ser muy diferente de la ruta crítica. Un problema con los recursos puede hacer que la ruta crítica salte por los aires. Por eso, la cadena crítica busca eliminar la competencia entre los recursos de un proyecto y debe esforzarse en tratar de eliminar la competencia entre los diferentes proyectos que compongan un  portfolio.

Por cierto, la traducción del libro es bastante pobre y muy mejorable. Dicho lo cual, se trata de una lectura imprescindible para todo Project Manager.

 

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 ágil) da por sentado que es una metodología que ha llegado para quedarse durante mucho tiempo entre los Project Managers.

Dado que la agilidad  se ha expandido a otro á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 agil 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 dificil 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 de ciclos de vida de los proyectos: predictiva, iterativa, incremental y agil 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 constucción de un edificio.
  • Los agiles son excelentes aproximaciones cuando se espera una gran cantidad de cambios en un proyecto. La diferencia de agil con los ciclos interactivos e incrementales es que estos ultimos 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 cicloes á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 investigacion) y luego pasar a una metodología predictiva (si se debe cumplir una cerf¡tificación). O combinar ambas metodologías según para qué aspectos (a mi 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 lider “sirviente”, (que haga de facilitador del éxito del equipo), en lugar de un lider 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 coordinacion.

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

Y le impone al lider “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 lider 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 agil 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 simultanea, asi 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 ejmplo) 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 raiz de los problemas sufridos y les 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 maás de 15 minutos) se usan  para declarar lo trabajado, lo que se va a trabajar, asi como para hacer aflorar posibles problemas. No se deben convertir en sesiones de analisis 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 asi 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 contínua
    • Test en todos los niveles
    • ATDD test de aceptacion.
    • TDD y BDD test driven development y behavior driven development
    • Spikes. Utiles 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 desafios 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. Ademas 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 poryecto á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) caracteristcas completadas/caracteristicas 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 cambos 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 enfocado a determinar cuando es mejor utilizar un enfoque ágil en los proyectoss

CONCLUSIÓN:

¿Cual 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 como 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 leido 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?

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.

MÉTODOS ÁGILES Y SCRUM

Título original: Métodos ágiles y Scrum mays

Autores: Alonso Álvarez, Rafael de las Heras, Carmen Lasa

Editorial: Anaya Multimedia, año 2012, 350 páginas, 

ISBN: 978-84-415-3104-8

Palabras clave: metodología, proyectos, software, scrum, métodos ágiles

En la empresa en la que trabajo hemos comenzado a gestionar varios proyectos por medio de metodologías ágiles, así que me he comprado este libro para ver de qué va la moda de los métodos ágiles y en concreto de Scrum.

Una peculiaridad de este libro es que el prólogo lo firma Mike Breedle, unos de los firmantes del llamado ” Manifiesto Agil”, del que ya hablaremos. Ademas, para ser prácticos, utilizan la realización de este libro como ejemplo de proyecto realizado en Scrum

Entrando en materia, los autores destacan que el origen de los métodos ágiles se basó en la frustración del mundo informático de poder tener éxito cuando los requerimientos son indefinidos, es decir, en proyectos donde la incertidumbre de lo que se busca es alta, pues si el cliente tiene claros los requisitos entonces es mucho más adecuado optar por una metodología de proyectos clásica (en cascada o waterfall).  El cambio de paradigma que implica es adoptar el enfoque de señalar un presupuesto y una fecha de entrega y que el trabajo sea lo que se pueda hacer aplicando el principio de que el desarrollo será iteractivo.

Srum es solo uno de los muchos métodos ágiles que existen, aunque es sin duda el más popular.

Un resumen rápido del modo en el que se trabaja en Scrum es el siguiente:

  • Ante al solicitud de un proyecto, el Product Owner crea un  equipo, solicita unos recursos y fija los primeros requisitos.
  • Desarrolla el Product Backlog con los trabajos detectados necesarios, que se compone de temas, épicas e historias.
  • Se debe dividir el trabajo en varios Sprints, que se agrupan en Releases o entregas.
  • El equipo de trabajo valora el esfuerzo implicado y traduce las historias en las que se compone el proyecto en unidades menores o tareas.
  • El trabajo se va realizando y se expone en la Daily Meeting.
  • Los impedimentos detectados va a a un Impediment Backlog y el Scruim Master vigila que se resuelvan.
  • El final del Sprint lo señala la Review Meeting
  • En la reunión de Retrospectiva el equipo revisa lo realizado y lo que se ha hecho bien y lo mejorable.
  • Y vuelta a empezar.

Y esto es todo…

Vamos a verlo con un poco más de detalle.

VALORES:

  • Mejora continua
  • Calidad
  • Time Boxing
  • Responsabilidad
  • Multidisciplinar
  • Flexibilidad
  • Ritmo (latido)
  • Compromiso
  • Simplicidad
  • Respeto
  • Coraje
  • Foco
  • Predictibilidad
  • Personas

cambio-de-paradigma2

 

 

 

 

 

 

 

 

ROLES:

  • Product Owner:
    • Es el intermediario entre el cliente y el equipo. Es la voz del cliente.
    • Fija las fechas de entrega y prioriza los distintos requisitos
    • Mantiene la “visión” actualizada del producto o proyecto. La “visión” es un resumen de las metas a medio y largo plazo donde se quiere llegar. es muy importante por ello disponer de un “caso de negocio”. La “visión” del producto implica:
      • Unas características básicas u obligatorias, que el producto debe tener
      • Unas características de rendimiento o lineales
      • Características inesperadas o emocionantes
    • Mantiene al día el Product Backlog. Describe los elementos, con las condiciones de aceptación y priorizadas)
    • Traduce los requisitos de negocio en elementos del Backlog (temas, épicas e historias)
    • Es quien acepta o rechaza las entregas de trabajo
    • Asiste  a la Review y al Planning
    • Es el responsable del éxito no fracaso del proyecto y de su ROI. Controla el presupuesto
    • Gestiona las expectativas del cliente y de los stakeholders
    • Qué no debe ser un PO: Que no tenga poder, que esté  saturado de trabajo.
    • Hay una interesante historia acerca de los roles dentro de Scrum y  de lo que es estar implicado y estar comprometido.  Pues bien , el PO tendría el rol de”cerdo”, pues está totalmente comprometido con  el proyecto
  • Scrum Manager:
    • No es un jefe de proyecto. No tiene autoridad formal ante el equipo.
    • Supervisa todo el proceso. No está subordinado al PO.
    • Es un experto en la metodología Scrum debe enseñar esta metodología a cada integrante implicado en el proyecto, preocupándose de poner la metodologia en practica de modo que se encuentre dentro de la cultura de la organización y así entregue las ventajas previstas, asegurándose de que cada uno siga las Reglas y prácticas de Scrum.
    • Pilota los Sprints.
    • Debe velar por la productividad del equipo.
    • Debe procurar que fluya la comunicación y la colaboración.
    • Analiza la velocidad del equipo y debe buscar la calidad
    • Los roles de Scrum Manager y Product Owner son muy diferentes y es incompatible con que sean la misma persona.
    • Último objetivo: no ser necesario
  • Equipo:
    • El equipo se debe auto-organizar
    • Debe estar comprometido con el proyecto
    • Su responsabilidad es entregar el producto, en base  a lo que existe en el Product Backlog
    • Los equipos auto-suficientes, auto-organizados y funcionales, tienen la responsabilidad, en cada iteración, de transformar el Product Backlog en un incremento en la funcionalidad del producto y planificar su propio trabajo para lograrlo.
    • Debería de eligir al Scrum Master, porque es su representante. debe confiar en él.
    • Debería de tener dedicación suficiente y continuada
  • Coach:
    • No es una figura obligatoria
    • Es un formador y mentor. Elabora las guías de actuación.

EL PROCESO:

  • Lo primero de todo, el Sprint Cero: 
    • Es responsabilidad del Product Owner
    • El él se define la misión, herramientas y el equipo
    • El objetivo es definir las condiciones y el contenido del trabajo
    • De esta forma se establece la primera versión del Producto Backlog
    • También se elige la duración de cada sprint y el calendario de releases o entregas
  • Sprints:
    • El Sprint Backlog contiene aquello que se llevará a cabo en cada sprint.
    • Hay tres etapas:
      • Sprint Planning, donde se realizan los criterios de aceptacion y la valoración de los trabajos
      • Daily Meetings. Reunión diaria donde se revisa de forma rápida qué se hizo, que se va a hacer y los problemas encontrados
      • Review.
    • Retrospectiva. Los resultados se valoran aquí.

scrum de un vistazo

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ENTIDADES:

  • Tareas
  • Historias de usuario.
  • Épicas. Son agrupaciones de historias

ARTEFACTOS:

  • Product Backlog:
    • Es la lista de requerimientos. Los requisitos del sistema o del producto desarrollado se enumeran en el Product Backlog. Es responsabilidad del  PO.
    • No contiene todos los requisitos. Cualquiera puede crear requisitos, es si, requieren de la aprobación del PO. El Backlog es dinámico
    • Tipos:
      • Funcionales. Son las Historias de Usuario.
      • No funcionales. Son las cualidades que debe tener el producto.
    • El nivel de detalle debe ser alto para los requisitos prioritarios y no tanto para el resto.
    • Estructuración:
      • Temas
      • Épicasscrum_2-4_week
      • Historias de Usuario
      • Tareas
    • Características de un buen Product Backlog:
      • Card. Deben caber en una tarjeta
      • Conversation. Deben ser resultado de conversaciones
      • Confirmation. Deben ser fácilmente confirmables
      • Con historias de usuario bien definidas
    • El mejor producto Backlog debe ser DEEP: Detallado, Emergente, Estimado, Priorizado
    • Es una lista ordenada por prioridad, esta tarea  de priorización es del PO, pero el equipo le debe ayudar.
    • Técnicas de priorización del Product Backlog:
      • Priority Poker
      • Moscow (Must, Shoul, Could, Won’t)
      • Kano
      • Criba de temas
      • Puntuación de elementos
      • Posibles problemas del Product Backlog:
        • Es muy grande y detallado. Encubre una especificación de requisitos encubierta. En este caso no se debería de  trabajar con Scrum
        • Historias de usuario siamesas. Encubre un problema con las dependencias. Se debería de dividir en partes más pequeñas y hacer historias de usuario conjuntas.
        • No se cierran las Historias de Usuario. Encubre un problema con las tres C’s: Card, Conversation, ConfirmationExample_Sprint_Task_Board
        • Infección Operativa. Si se dice cómo hay que hacer las cosas y no lo que hay que hacer. Se deben eliminar del PB las tareas operativas
        • Plaga de requisitos. Es síntoma de que el PB se está usando como una lista de peticiones.
        • No hay requisitos no funcionales. El PB no está completamente definido. Solución: prestar atención tanto a las Historias de Usuario como a los requisitos no funcionales
        • Inmunización tardía. Se deben priorizar todos los elementos sobre los que se tengan incertidumbres para poder trabajar sobre ellos. Si esto nop se hace pronto, luego será un problema
        • Muerte dulce por contrato. Si el PB funciona como un contrato con el cliente. El PB no es un acuerdo formal con el cliente.
        • No se debe consentir que el PO delegue la gestión del Product Backlog  en el Scrum Master o en otra persona
  • Sprint Planning:
    • Los sprints son fijados en el Sprint 0. En el Sprint Planning el equipo junto con el PO y el SM planifican los sprints.
    • Cada Sprint se divide en:
      • Planificación del contenido del sprint
      • Desarrollo del trabajo
      • Revisión de los resultados
    • Se deben establecer los límites temporales adecuados (time boxing)
    • Se debe garantizar que el objetivo, mecánica y resultados sean conocidos
  • Sprint Backlog:
    • Son los trabajos a realizar durante un determinado Sprint
    • Es propiedad del equipo, que es quien lo gestiona y actualiza.
    • Su contenido es mucho más detallado y debe de disponer de una definición de lo que se debe alcanzar para poder saber cuando se ha alcanzado el resultado
    • Dimensiones:
    • Prioridad
    • Detalle
    • Estado.  Será pendiente, en curso, terminado, impedida (se documenta y se asigna)
    • El Tablero de Tareas permite visualizar cómo va el sprint
  • Impediment backlog:
    • Es una lista de incidencias que tienen que ser resueltas por el equipo y que el Scrum Master debe gestionar y asignar al alguien para que trabaje en ellas, y que será revisada en la reunión Scrum diaria
  • Burndown Chart.
    • Mide la evolución del trabajo. Lo mantiene el Scrum Master

MECÁNICA DE TRABAJO:

  • El PO lee la primera historia de usuario junto con su criterio de aceptación. los miembros del equipo le asignan “Story points” y se suman hasta que alcancen la velocidad media del equipo (si se sabe). Estas historias deben ser divididas en tareas.
  • El compromiso del equipo es muy importante. Por eso no se aceptan presiones del PO. La calidad debe ser el criterio que debe primar
  • La cantidad de historia de usuario cerradas por el equipo según el Product Owner es el valor de la velocidad real de ese equipo
    • el valor de la complejidad, dificultad o cantidad de trabajo se mide en story points
    • También puede medirse la velocidad por días ideales que se requerirían para hacer esas historias.
    • O también se podría poner un porcentaje, un focus factor.
  • La estimación es una acción colectiva. Puede usarse el Planning Poker
  • Si la estimación coincide se acepta, si no, se discute sobre ello.
  • Sumando todos los story points se obtiene la velocidad estimada de la iteración.
  • El seguimiento del cumplimiento se realiza a través de la  Burndown Chart

PILOTANDO EL SPRINT:

El Scrum Master:

  • No tiene poder real
  • No es el jefe del proyecto
  • Es un facilitador
  • No está subordinado al Product Owner
  • No persigue a los demás
  • Cometido: velar por el seguimiento de los principios del Scrum
  • Cómo lo hace:
    • Velando por la productividad del equipo
    • Procurando que fluya la comunicación y la colaboración
    • Responasble de introducir y fomentar la prácticas ágiles
    • Supervisa el backlog
    • Analiza la velocidad
    • Es el intermediario entre el mundo exterior y el equipo de trabajo
    • Es responsable de la formación del equipo
  • Muy importante: es incompatible que una sola persona sea el PO y el SC
  • Objetivo último: no ser necesario

Planificación detallada:

  • Objetivo: pasar las historias de usuario a unidades más manejables, como son la tareas
  • En esta tarea no se necesita al PO
  • La tarea es una descripción simple de lo que se va a hacer. No es validable

Mantenimiento del backlog, el grooming:

  • Es muy recomendable hacerlo mucho antes de cada planificación del Sprint Backlog
  • El PO revisa el product Backlog para depurarlo.
  • Es un trabajko contínuo y puede asistir todo el equipo.

 DESARROLLO DEL SPRINT:

Duración de los sprints. es mejor que sean cortos al inicio o en actividades poco definidas o si el equipo es inmaduro

Frecuencia de los releases: es responsabilidad del PO

Aspectos del sprint: estabilidad, obtención de resultados, mejora continua, anticipación

Quien lo lleva a cabo: el equipo de trabajo:

  • Características: diversificado, autónomo, auto organizado, responsable, sin jerarquias o nivelss, estable y dedicado
  • Responsabilidades:
    • Realizar el trabajo del proyecto
    • Identificar formas de mejorar su productividad, junto con el SC
    • Hacer la estimación de los elementos del backlog
    • Dividir las historias en tareas
    • Comprometerse a realizar una lista de historias en cada sprint
  • Dimensión del equipo: sobre 4 a 10 miembros
  • Es muy recomendable la proximidad física

La Daily Meeting:

  • Lo realizan el equipo y el SC, que no la dirige.
  • El PO puede asistir o no.
  • Contenido:
    • Qué se ha hecho
    • Qué se hará
    • Impedimentos

Backlog de impedimentos:

  • Recoge todo lo que impide alcanzar los oobjetivos
  • Se recogen los impedimentos, se describen y se asignan a un responsable
  • Es gestionado por el SC
  • Deben priorizarse

Sprint Review:

  • También llamado Customer Sprint Review
  • Se revisa qué se ha hecho y como se ha hecho
  • Finalidad:
    • Recoger comentarios
    • Recoger la aceptación de las tareas seleccionadas
    • Analizar si se necesitan mejoras en el trabajo realizado o si se precisan nuevos items
    • Pueden acudir personas de fuera del equipo
  • Posibles problemas:
    • Cambiar la fecha de la reunión frecuentemente
    • Que sea una presentación d eresultados
    • Que se trabaje solo para la sprint review
    • Foco en los items del backlog y no en los objetivos
    • Desviación del propósito de la reunión por los asistentes
    • Convertir la review en una reunión de aprobación de requisitos
  • La mejor práctica:
    • Establecer normas y reglas.
    • Repasar los objetivos
    • Recapitulación del PO sobre lo finalizado y no finalizado
    • Revisión por el equipo de estadisticas y métricas

La retrospectiva:

  • Objetivo: mejorar la forma de trabajar de forma más efectiva
  • Debe concluir con las acciones de mejora que deben implementarse
  • Cuando: al final de un sprint, después de un release y al final del proyecto
  • Etapas: que se hizo bien, que se debe mejorar, que se vaa hacer en la nueva iteración
  • Consejo: se debe ser positivo y debe haber un moderador (el SM)

Los Scrum Buts:

  • Son malas prácticas. Se debe diferenciar entre Scrum Ands, que son modificaciones positivas, y Scrum Bad, que son modificaciones negativas
  • Los Scrum Buts exponen una disfuncionalidad que hay que solucionar. La culpa no es de Scrum.
  • Top 10 de Scrum Buts:
    1. No hacemos reuniones de fin de sprint
    2. No se eligen voluntariamente las tareas. Ojo esto es micro gestión
    3. No hacemos mejoras o corrección de problemas porque hay demasiadas funcionalidades que implementar.  A esto se le llama la Death March
    4. No hacemos retrospectivas. Esto puede ser un síntoma de que hay conflictos internos en el grupo
    5. No hacemos reuniones diarias ya que nos las necesitamos
    6. El Scrum Master y el Product Owner son la misma persona. Ojo, son roles que consumen mucho tiempo y que son incompatibles porque sus atribuciones pueden entrar en conflicto
    7. Usamos Scrum pero no hacemos el diseño, la implementación y las pruebas de cada historia de usuario en el mismo sprint, porque no os da tiempo a llevar a cabo todas estas tareas en el mismo sprint y las hacemos en sprints consecutivos. esto puede tener dos causas: el equipo no está estimando bien las historias de usuario y el product backlog no está suficientemente trabajado
    8. No se hacen iteraciones cortas porque todo está claro y las hacemos cada 3 meses. Entonces, ¿Por qué se usa Scrum?. Puede ocultar disfuncionalidades
    9. No hacemos reuniones diarias porque no está el Scrum Master. Ojo, esto no es un reporte
    10. Nosotros no lo llamamos Srum pero ya estabamos haciendo todas esas cosas.

¿Cómo detectar Scrum Buts?. Con el método de los 5 porqués (Un ejemplo. ¿Por qué no asiste el SM al Daily Meeting del proyecto?–> Porque está muy ocupado. ¿Por qué está tan ocupado? —> Porque gestiona muchos proyectos— > ¿Por qué gestiona muchos proyectos?—> Porque no hay más SC en toda la empresa….)

En fin. la teoría del método Scrum es muy sencilla. Pero hacerlo bien es muy difícil.

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

 

LEGAL PROJECT MANAGEMENT

lpmTítulo original: Legal Project Management

Autores: Anna Marra

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

ISBN: 978-84-15560-06-7

Palabras clave: Proyectos, 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 muy mejorable  es que no existe un índice del libro. 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 mas 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 actual 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.

Enlaces interesantes sobre LPM: