Calificación: 8/10
Leer más en Amazon
Lee gratis mi colección de más de 250 resúmenes de libros
Pensamientos de alto nivel
Un recurso de productividad fantástico sobre cómo hacer más cuando gestiona varios proyectos. Incluso si no es un CIO (que no lo soy), puede aprender mucho de este libro sobre cómo administrar mejor sus muchos proyectos.
Resumen en español
Cuando hablamos de mejoras revolucionarias en toda la cartera, nos referimos a la selección de proyectos de mayor impacto, al menos duplicando el número de ellos que su organización puede completar y siendo capaz de entregar más del 90 por ciento de ellos dentro del plan, todo dentro de las limitaciones de recursos existentes..
Los tres objetivos más importantes para cualquier cartera de proyectos son:
- Seleccionar los proyectos adecuados.
- Maximizar el rendimiento de la cartera de finalizaciones de proyectos.
- Optimización de la fiabilidad de la cartera de finalización de proyectos.
Dos de ellos son la Integración del Modelo de Madurez de Capacidades (CMMI) del Instituto CMMI y el Cuerpo de Conocimiento de Gestión de Proyectos (PMBOK) igualmente generalizado de PMI y los estándares y certificaciones asociados. CMMI se enfoca en mejorar los procesos subyacentes requeridos para la entrega exitosa de proyectos de TI, mientras que PMI proporciona un conjunto de “buenas prácticas generalmente reconocidas” y fundamentales que refuerza a través de sus certificaciones.
Hay un énfasis significativo en lo que consideraríamos “métricas de entrada”, como procesos y prácticas repetibles, sin las métricas de resultados correspondientes para evaluar si esta repetibilidad realmente ayuda a mejorar el rendimiento o la confiabilidad.
Esta disciplina proviene de la Teoría de Restricciones (TOC), y su lógica es sencilla: en cualquier sistema, hay una función, recurso, área de proceso o paso de proceso que limita la capacidad de todo el sistema para cumplir con su misión.
Una vez que una organización ha identificado la restricción de su sistema, sabe que cualquier mejora en cualquier otro lugar que no sea la restricción tendrá poco o ningún impacto en la eficacia general de la organización. Poner este concepto en práctica ayuda a proporcionar una claridad muy necesaria sobre dónde enfocar los esfuerzos de mejora.
Rendimiento por unidad de restricción (T / CU). Una forma de pensar en T / CU es en términos de “rendimiento efectivo”, ya que representa lo que realmente esperamos lograr, dado lo que sabemos sobre cómo la restricción de nuestro sistema limita el rendimiento. Simplemente necesito obtener estimaciones defendibles de T / CU para cada candidato de proyecto y financiar los de mayor puntuación para los que tengo presupuesto y CU disponibles para respaldar.
Ahora tenemos una métrica de selección de proyectos algo mejorada que llamaremos “ROI efectivo ” , ya que calcula el ROI real esperado cuando se tiene en cuenta la restricción del sistema: rendimiento por unidad de restricción, por inversión (T / CU / I)
Sin embargo, en algún momento, la mayor parte o la totalidad de esta capacidad oculta se agotará, de modo que cualquier proyecto adicional que entregue nuevas capacidades en funcionamiento solo servirá para sobrecargar la restricción y degradar el rendimiento. Como resultado, los únicos proyectos que tienen sentido en ese momento son aquellos que realmente pueden expandir la capacidad en la restricción.
Mantén a Susan concentrada. Protéjala de las tareas ad-hoc, mientras maximiza el enfoque de una sola tarea que está alineado con las prioridades de la organización. Deje en claro que su prioridad ya no es responder a los incendios, sino mantenerse concentrada en ejecutar la tarea asignada. Programe su recurso para que se encargue de las tareas del proyecto de acuerdo con un número determinado de horas disponibles por día o por semana, y tareas de operaciones durante el resto de su tiempo.
Delegue todos los demás recursos a Susan. En otras palabras, todos los recursos que no sean Susan (no CU) deben hacer todo lo posible para ayudar a aliviar la presión sobre Susan. Incluso la asistencia menor puede tener un gran impacto; incluso hemos visto ejemplos de organizaciones que piden a las personas que no pertenecen a la UC que le lleven el almuerzo a Susan para que pueda maximizar el tiempo disponible de la UC. Aún mejor es cuando las personas que no son CU siguen a Susan y documentan algunos de sus enfoques más repetibles, como la mejor manera de solucionar los problemas de un sistema en particular ; A menudo, las personas que no son CU incluso encuentran formas de automatizar o simplificar estos enfoques, liberando aún más a Susan.
Genera más Susans. Si bien esto puede llevar más tiempo y esfuerzo, y es probable que inicialmente requiera aún más UC de Susan, simplemente debe hacerse. Por ejemplo, debe haber esfuerzos deliberados para que las personas que no pertenecen a la UC adquieran conocimientos o habilidades que solo Susan tiene actualmente, como adquirir experiencia en un sistema operativo crítico que Susan conoce muy bien.
Un punto final críticamente importante sobre esto: si puede encontrar una manera de hacer más proyectos sin agregar recursos, tendrá una mayor capacidad tanto para expandir la capacidad en la restricción como para usar esa capacidad adicional para aumentar el rendimiento.
Cuando decimos “rendimiento de la cartera”, nos referimos específicamente a cuántas finalizaciones de proyectos puede lograr una organización durante un período de tiempo determinado.
Podemos aumentar el rendimiento de las carreteras de varias formas; aquí hay algunas comunes: Podemos mantener la carretera libre de obstáculos y en buen estado de funcionamiento. Podemos aumentar la densidad del tráfico (p. Ej., Viajes compartidos). Podemos medir las rampas de acceso siempre que su entrada ralentice el flujo principal de tráfico. Podemos reclutar recursos infrautilizados en otros lugares (como carriles normalmente dedicados al tráfico opuesto). Podemos intentar hacer que los coches vayan más rápido. Podemos construir uno o dos carriles adicionales.
En PPM, tendemos a enfocarnos principalmente en tratar de hacer que los autos vayan más rápido, incluso cuando la carretera está atascada , lo que a veces causa accidentes y, por lo general, frustra a todos los que no pueden llegar a donde quieren ir. También tendemos a saltar directamente para tratar de agregar uno o dos carriles, lo cual rara vez es rápido, fácil o económico, si es que es una opción factible.
Si bien la velocidad es importante y es posible que sea necesario agregar capacidad, comencemos por hacer que el tráfico fluya.
Por lo tanto, debemos medir el flujo del tráfico en la rampa de una manera que mantenga el flujo del tráfico en la carretera. En el mundo de PPM, llamamos a este proyecto asombroso.
la primera persona en entrar en la carretera irá tan rápido como quiera, pero si todo lo que tenemos es ese individuo, obviamente nuestro flujo es muy bajo. Si agregamos una segunda persona, duplicamos el flujo instantáneamente, ya que todavía hay mucho espacio para ir tan rápido como les interese a ambas personas. Podemos seguir agregando más personas, una a la vez, y el flujo aumentará en consecuencia, hasta que alcancemos una cierta densidad, momento en el que nuestras mejoras de flujo comienzan a disminuir. Si seguimos agregando más viajeros, llegaremos a un punto en el que nuestro flujo alcanza su punto máximo y luego comienza a degradarse. Si continuamos empujando más autos en la carretera, empeoraremos el flujo dramáticamente, hasta que nuestra densidad sea tan alta que tengamos muy poco flujo.
En PPM, ¿cómo puedo visualizar la capacidad total del proyecto de mi organización?
Pero también debemos tener una buena idea del tiempo para el que se necesitará cada recurso del proyecto y comprender dónde se encuentran realmente mis mayores limitaciones de recursos. La única forma de saber con certeza estas cosas es tener todos los proyectos planificados, con las tareas y las dependencias de las tareas identificadas y los recursos de las tareas asignados. Sin embargo, en nuestra experiencia, puede comenzar a tener una idea bastante clara de dónde es probable que ocurran los cuellos de botella de los recursos, ya que tienden a seguir un patrón en los proyectos de TI.
Con asombro, vemos que los tres proyectos terminan de cuatro a ocho semanas antes, aunque el tercer proyecto ni siquiera se inicia hasta la semana 7.
Para los CIO, los gerentes de cartera de proyectos de TI y otros altos ejecutivos que buscan un enfoque híbrido más práctico para mejorar el rendimiento de la finalización de proyectos, el escalonamiento de proyectos es su primer paso.
La verdad, sin embargo, es que el cambio de tareas nos está ralentizando mucho, en un enorme 40 por ciento, según muchos estudios.
Por ejemplo, muchos de nosotros dedicamos una o dos horas al trabajo, ya sea temprano en la mañana o tarde en la noche, “porque es ahí cuando realmente puedo hacer las cosas”. Sabemos intuitivamente que somos mucho más productivos cuando podemos minimizar las interrupciones y el cambio de tareas.
Por supuesto, el simple hecho de tener las tareas de su proyecto encuadradas en el tiempo en un sprint no hace nada para eliminar el cambio de tareas.
Suponiendo que la mayoría o todos nuestros proyectos sufran cambios de tareas generalizados, esperaríamos un beneficio de productividad promedio del 40% de la ejecución enfocada en una sola tarea.
Si todo lo que hacemos es escalonar nuestros proyectos y ejecutarlos con un enfoque de una sola tarea, podemos más que duplicar el rendimiento de la cartera.
Al combinar el escalonamiento del proyecto, la ejecución de una sola tarea y la eliminación de compromisos a nivel de tarea / sprint, vemos que ahora podemos triplicar el rendimiento de la cartera, y ninguna de estas técnicas es compleja o difícil de aprender y aplicar. [7]
Resulta que esto es más alto de lo normal, pero no mucho; los ingenieros de procesos experimentados le dirán que el proceso comercial típico contiene un 70-90 por ciento de hinchazón. El desafío es dedicar tiempo, energía y el talento adecuado para mejorar los procesos antes de habilitarlos con el software.
Para satisfacer la definición de Lean de un paso de “valor agregado”, ese paso debe cumplir con tres condiciones: 1. Cambiar el objeto que se mueve a través del proceso. 2. Obtenga un resultado bien hecho la primera vez. 3. Entregar valor, según lo definido por el cliente de ese proceso.
La siguiente figura proporciona algunos de los ejemplos más típicos de pasos sin valor agregado.
- El “sistema de tracción” de Lean, que impulsa el flujo de manera más eficaz que un “sistema de empuje”. En Ultimate Scrum, los desarrolladores de software extraen sus tareas del backlog, a diferencia de los gerentes que asignan (empujan) tareas.
- El “flujo de una sola pieza” de Lean como la unidad ideal de flujo en un proceso de alto rendimiento. En Ultimate Scrum, el flujo de una sola pieza se manifiesta como una regla que los desarrolladores pueden realizar solo una tarea a la vez, y que ningún desarrollador puede comenzar una nueva tarea hasta que termine la que está en progreso.
- El principio de TOC de que el rendimiento de un sistema se maximiza solo cuando se rige por el ritmo de la restricción de ese sistema. En Ultimate Scrum, los desarrolladores de software son la limitación, y su velocidad de finalización de tareas marca el ritmo de todos los aspectos de apoyo del flujo de tareas.
Un beneficio secundario importante de los sprints de Agile es que reducen el tamaño de los lotes de tareas en comparación con la mayoría de los enfoques tradicionales. Ultimate Scrum lleva este concepto al límite al lograr un tamaño de lote de 1, eliminando efectivamente los sprints por completo, a favor de un flujo de tareas de una sola pieza.
Finalmente, Ultimate Scrum emplea el método “Drum-Buffer-Rope” (DBR) de TOC para maximizar el rendimiento efectivo de las tareas completadas de la manera más eficiente posible. El tambor se refiere a los desarrolladores, ya que son la restricción del sistema para el desarrollo de software y, por lo tanto, marcan el ritmo o el ritmo de la ejecución de la tarea. Para asegurarnos de que los desarrolladores siempre tengan un suministro listo de tareas, nos aseguramos de almacenarlas en búfer con suficientes tareas abiertas en curso. Y para saber cuándo necesitamos liberar una nueva tarea abierta al búfer, necesitamos tirar de la “cuerda”, lo que en este caso ocurre cada vez que se termina una tarea.
En pocas palabras, el objetivo aquí es asegurarse de que los desarrolladores siempre tengan algo en lo que trabajar.
Todo está dirigido por el volumen de tareas planificadas en el búfer de tareas. Le recomendamos que comience con un tamaño de búfer de 2 para esto. Entonces, si solo quedan dos tareas, entonces uno de los desarrolladores toma la siguiente historia de la cartera de productos y la divide en tareas.
Si persisten los agujeros de amortiguación, siga aumentando el tamaño de la zona de amortiguamiento en uno, hasta que no se produzcan más agujeros de amortiguación. Si su búfer aumenta hasta el punto en el que tiene más de una tarea en el búfer por cada dos desarrolladores, lo más probable es que el problema radique en cuánto tiempo le lleva dividir las historias en tareas.
La encuesta de PMI citada en el Capítulo 1 informa que incluso los proyectos de mayor prioridad de las organizaciones no logran cumplir sus objetivos originales y su intención comercial el 44 por ciento de las veces; sólo podemos suponer que la tasa de fracaso de los proyectos de menor prioridad es considerablemente más alta.
Lo alentamos a que apunte alto; para la mayoría de las carteras, el objetivo de confiabilidad óptimo debe estar en el rango del 90-95 por ciento (o más del doble de la tasa típica de alrededor del 40 por ciento).
En la gestión de proyectos tradicional, el almacenamiento en búfer se ha introducido a menudo como la “regla de la triple restricción”, que sostiene que debemos tener cierta flexibilidad en el cronograma, el presupuesto y / o el alcance para poder entregar con alguna esperanza de confiabilidad.
no solo la realización de una sola tarea es aproximadamente un 40 por ciento más rápida en promedio, sino que el rendimiento también es significativamente más predecible y, por lo tanto, más confiable. También es interesante notar que los peores ejecutantes de una sola tarea son tan buenos como los mejores ejecutantes de cambio de tarea.
Bajo el enfoque de almacenamiento en búfer a nivel de tarea, puedo seguir el camino a lo largo del proyecto, pero luego, si las cosas salen mal en la tarea final, solo tengo el búfer de cinco días de esa tarea para evitar que todo el proyecto no se complete dentro de plan. Compare este enfoque a nivel de tarea con el enfoque de almacenamiento en búfer a nivel de proyecto, en el que es probable que tenga más de cinco días de búfer disponible cuando llegue a la tarea final, porque es relativamente raro que las primeras tres tareas salgan tan mal que consumir 25 días de mi búfer de 30 días.
Pida a todos los miembros del equipo que bloqueen, digamos, seis horas todos los días en sus calendarios para el trabajo centrado en las tareas, dejando el resto del tiempo para responder a los mensajes y abordar problemas específicos.
- Un ROI efectivo es esencial para seleccionar proyectos de alto impacto.
- A nivel de tarea, la tarea única y la eliminación de compromisos a nivel de tarea son esenciales para maximizar las mejoras en velocidad y confiabilidad.
- A nivel de proyecto, Project Staggering es indispensable para maximizar el rendimiento de la finalización de proyectos, mientras que monitorear los búferes basados en el tiempo es esencial para aumentar la confiabilidad.
- A nivel de la cartera, se requiere un balance de búfer mediante el índice de protección de búfer (BPI) para optimizar la confiabilidad.
Y finalmente, aquí está la imagen combinada de las nueve técnicas, integradas juntas:
Obstáculo # 3: Convencer a los PM y Scrum Masters de que abandonen los plazos de las tareas.
A ningún corredor se le pide que se comprometa con un tiempo o velocidad específicos, y si les preguntaras, probablemente te mirarían como si estuvieras loco, porque todos los atletas saben que el rendimiento variará de una carrera a otra. Si podemos configurar nuestros entornos de ejecución de tareas para que se parezcan más a una carrera de relevos, los comportamientos seguirán, al igual que los beneficios de velocidad y confiabilidad.
Si bien recomendamos implementaciones en toda la organización, no recomendamos intentar adoptar todas las técnicas a la vez. Aquí está la progresión lógica que recomendamos:
- Proyecto asombroso
- Almacenamiento en búfer del proyecto
- Balance de búfer de cartera
- Selección de proyectos utilizando un ROI efectivo
- Eliminar compromisos a nivel de tarea
- De una sola tarea
- Scrum definitivo
- Mostrar todos los buffers según el tiempo
- VSA de procesos ajustados
