8
2015
Adivina el Modelo de Gestión de Proyectos: La Fábula del Rey que soñó con un Palacio (I)
Léelo aprox. en 3:36 minutos.
Te propongo que participes en este ejercicio. Es sencillo, sólo debes adivinar el nombre de este modelo de Gestión de Proyectos. Lee la fábula y luego muestra tu propuesta. ¿Lo acertarás? ¡Supera el reto!
Dicen que hace mucho tiempo en un Reino muy muy lejano, un Rey mandó llamar a su primer ministro.
Cuando el ministro llegó, el Rey le dijo que esa noche había soñado con el palacio más maravilloso del mundo. Tanto le había impresionado el palacio que todavía mantenía un recuerdo vívido en su memoria y recordaba todos los detalles que tenía: escalera principal de mármol con pasamanos de ébano, cúpula coronada por una cristalera de vidrios de colores, salas de música, salas de baile, etc.
El primer ministro estaba impresionado por la excitación del Rey y le preguntó que podía hacer él, si le había mandado llamar únicamente para contarle el sueño o si necesitaba que hiciera algo.
El Rey le contestó que algo no, que necesitaba que hiciera mucho: quería que le ayudara a construir el palacio que había soñado. Y que quería que estuviera hecho en 2 años para cuando celebrara el 25º aniversario de su coronación.
Para ello, lo primero que le pidió el Rey fue que eligiera al mejor arquitecto del reino y que lo enviara a hablar con él para que tomara nota de todos los detalles.
¿Quieres llevar tus Proyectos a otro nivel?
¿Las vas a dejar escapar? ¡Quiero ser el mejor! ¡Quiero ser la mejor!
El Rey recibió al día siguiente al mejor arquitecto del reino y comenzó con él una árdua y extenuante tarea: definir todo el palacio. El nivel de detalle que describía el Rey sorprendió al arquitecto que comentó lo impresionado que estaba por la capacidad de decisión y el nivel de implicación del Rey en la obra.
A lo largo de las semanas siguientes, el arquitecto fue incorporando algunas personas más a su equipo, personas que se encargarían de confeccionar y presentar un plan al Rey donde se determinaría el coste final de la construcción del palacio con el nivel de detalle descrito y finalizándolo en los 2 años de plazo que se había planteado.
El monarca, movido especialmente por la obra que estaba realizando, no escatimó ningún esfuerzo en revisar personalmente los trabajos previos elaborados por el arquitecto y su equipo. Juntos realizaron algunas modificaciones y finalmente lanzaron la construcción del palacio 3 meses después del sueño del Rey.
El arquitecto dividió la colosal obra en fracciones de trabajo más pequeñas que fue repartiendo entre los miembros de su equipo. Entre todos diseñaron una planificación de cuando debería cumplirse cada una de las tareas y el propio arquitecto en persona monitorizaba cada una de ellas para comprobar que todo iba según lo establecido.
Cuando se toparon con algunos impedimentos graves como la huelga de los trabajadores de las canteras de marmól que comprometía la finalización de la obra en el tiempo establecido, fué a tratar este tema con el Rey. Ambos sabían lo que tenían que hacer ya que este riesgo existía desde el inicio del proyecto (en varias obras anteriores había sucedido algo similar) y las medidas de actuación estaban establecidas de antemano. El Rey realizó los planes trazados y logró solventarse la situación sin retraso en la obra.
Cuando por fin se cumplió el plazo de dos años que había sido establecido, pudo inaugurarse el palacio en todo su esplendor.
El rey, que no cabía en sí de gozo, felicitó al arquitecto y a todo su equipo, desde los jefes de obra hasta el último peón, todo había salido según lo previsto y el resultado era espléndido.
El arquitecto sin embargo no sólo se contentó con la gratitud del rey sino que habló con su equipo y recopiló todo aquello que habían aprendido durante el desarrollo de la obra para que a futuro lo pudieran manejar mejor.
El baquete de celebración del 25º aniversario de la coronación del rey fue tan magnífico, en un palacio tan majestuoso que fue recordado durante muchos años en el reino y todos ponían de ejemplo ese proyecto…
Espero que hayas disfrutado con la fábula pero ahora te toca a tí.
¿Cuál crees que es el modelo de Gestión de Proyectos que se ha descrito?
Es fácil, ¡atrévete a dar una respuesta!
Consigue Más de 100 Libros gratis
Suscríbete a nuestro newsletter por email y conseguirás Más de 100 Libros Gratis sobre Gestión de Proyectos, Innovación, Emprendimiento, Empresa, etc. directamente en tu correo
Últimos artículos de Julián Gómez (ver todos)
- Ultimo video del viernes del año: Sé diferente - hace 8 meses
- Vídeo del viernes: Kadenko, una luz en la navidad - hace 8 meses
- El Haiku: Antes que nada, la clave del éxito es… (Graham Bell) - hace 8 meses
Otros artículos que te pueden interesar
29 Comentarios+ Escribir Comentario
¿Te ha gustado? Pues sólo cuesta un Comentario. ¡Gracias por adelantado!
Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.
PMP+SCRUM+LEAN
Parte si parte no pero no te voy a decir cual es cual…
Julian, esto es un sueño de una gestión predictiva….lo cual si no hubiera sido tan afortunada y hubieran tenido más complicaciones y riesgos absolutamente imposibles de gestionar o predecir, no lo hubiera hecho un fracaso. En el peor o mejor ?de los casos yo hubiera priorizado aquello que mas soñaba el rey. Y cumpliria con el alcance sacrificando el tiempo.
Claro esto es un sueño, a un cliente de verdad, no le causaría ninguna gracia.
Hola Amalia, no entiendo lo de sacrificar tiempo. A mi modo de ver y basándome en la pirámide alcance-tiempo-coste-calidad y dejando la calidad, el alcance y el tiempo fijado como pide el monarca, la variable a jugar con ella es el coste, no le importa cuanto equipo deba contratarse. Incluso en la huelga de canteros de mármol seguro que o accedió a exigencias (sobrecoste) o envió al ejército para “incentivar” (influencia).
Lo del coste sí que no les suele hacer ninguna gracia a los clientes, mucho menos que el tiempo y es uno de los principales malos hábitos en España, ofertas a la baja, escatimar en tiempo de management, en pruebas y demás (bueno este último no es nacional ejemplos microsoft y muchos videojuegos con patch más grande que el propio juego original)
Gracias Miguel, en realidad este fue un comentario sobre un caso absolutamente utopico, las estadisticas americanas de fracaso de proyectos llegan al 80%.
Y no me quedo con la triple restriccion, yo hoy hablaría de la hexarestriccion y podría agregar una mas según la última version PMbok.
Ningún proyecto es perfecto, las solicitudes de cambio ni aparerecieron, por eso hice el comentario.
Pero todos sabemos que no hay dos proyectos iguales sobre un mismo servicio o bien.
Gracias Amalia 🙂
sobre la triple restricción en si son solo esas, no hay más.. ya que las otras incluido a interesados o stakeholders que creo es a lo que te refieres con la ultima version del PMBOK en si esta ultima y las otras 6 áreas del conocimiento son de apoyo, a que se cumpla la piramide o triple restricción. Como PM solo debe estár pendiente de mantener estas 3 areas del conocimiento y en caso ocurriese algun incidente, problema, retraso ya es tarea del PM y el equipo de como con las demás areas restantes solucionar estos inconvenientes.
Saludos
La triple restricción son tres Alcance, Coste y Tiempo pero no nos olvidemos de los factores que los hacen variar.
Los interesados pueden afectar a los tres a la ves 🙂
Otro buen análisis el tuyo Miguel!
En general estoy de acuerdo contigo en que lo que más motiva al cliente es el precio, el alcance (con unos mínimos) puede sacrificarse con una buena justificación.
Los de los patch es muy bueno porque ya salen hasta coches a la venta a los que tienes que actualizarle el software nada más comprarlo… ¿donde iremos a parar?
Bueno alguna vez tendríamos que tener una situación ideal y aquí está. Has hecho un análisis bastante bueno y has visto que lo importante aquí eran las espectativas del cliente, mantenerlas cubiertas… que será será….
Primero creo que no existe nada imposible. Cualquier sueño se puede realizar. Creo que hay en esta historia se presentan varios tipos de gestión.
* Primero hay una planeación hacia atrás (como casi todo proyecto real). Sabiendo la fecha de terminación se buscan los recursos necesarios.
*En cuanto al diseño y la ejecución, creo que es un médodo híbrido entre metodologías ágiles y pesadas. El arquitecto, realmente no requirió hacer ningún diseño particular, sino interpretar lo que el Rey quería, entonces buscó al equipo perfecto para que tradujeran lo que el rey quería. Por su parte para asegurar que el trabajo debería estar listo en dos años exactos, las metodologías pesadas son buenas y debieron (creo yo) ser necesarias para llevarlo a cabo.
* En la división de los grupos más pequeños se pueden ver los sprint backlogs. La monitorización y el trabajo en equipo, convierte al arquitecto en un híbrido entre product owner y project manager y bueno, no es una metodología ágil en toda su plenitud porque no no se ve el master scrum.
Esto es lo que se me ocurre por el momento.
En este caso lo que nos puede ayudar más es el nombre para distinguir las técnicas unas son ágiles y otras predictivas, no tienen porque pesar más unas que otras todo depende.
Por ahí está el secreto…
Me parece que es Lean Construction, por el dato de pequeños paquetes de tareas que deben cumplir
Oscar ahora te hago yo a ti una pregunta ¿no hay más técnicas donde el trabajo se divida en bloques más pequeños?
Una pista ¿te suena el WBS? 🙂
Es un modelo predictivo, con claros tintes de pmbok, estructura de desglose de trabajo, grupo de expertos, lecciones aprendidas, etc…
Raro que el Rey no haga ninguna gestión del cambio, ya sabemos que el caso predictivo ideal rara vez se cumple y menos aún por completo.
jejeje, buen apunte los casos ideales rara vez se presentan, tomamos nota para la próxima vez que el Rey tenga un sueño…
Es un proyecto predictivo, donde se observan las diferentes fases de manera general de un proyecto guiado por metodologia PMI.
Interesante y excelente ejemplo de un caso de estudio, sencillo y de facil recordacion.
Muchas gracias.
Gracias Miguel Ángel pero para que veas lo sencillo que te parece y la de juego que ha dado
PMI, totalmente predictivo. De echo es el caso ideal de un enfoque predictivo. O así lo veo yo…
hecho, con h 🙂
uhmmmm pues por aquí te lo discuten 🙂
Me gustaría saber, los que proponéis metodologías ágiles, cómo habéis llegado a esas conclusiones.
No quiero que me malinterpretéis, no es una crítica, estoy realmente interesado como implementador de PMO’s y metodologías en qué os basáis para llegar a esta conclusión, ver si coincide con lo que profesionalmente me he ido encontrando en CEO’s y técnicos varios, o si tenéis un motivo diferente para inferir esto.
Bajo mi punto de vista como ya puse en mi comentario es waterfall tradicional y expongo por lo que no me casa que sea ágil.
Los cilcos de desarrollos ágiles son iterativos incrementales, es decir que se repiten los ciclos o sprints e incrementales porque el producto resultante siempre debe ser un producto final viable, con mayor o menor calidad, pero viable.
Tendría sentido usarla si el monarca hubiera dicho, bueno mientras vamos construyendo necesito irle sacando partido (ROI), vamos a construir los muros exteriores y techos, despues ampliamos detalles a las salas de baile y recepción-sala de trono porque puedo ir celebrando cosas mientras llegamos al hito de todo acabado en dos años.
También tendría sentido usarla si el monarca hubiera dudado de cosas, no recordara bien detalles y esta INCERTIDUMBRE hiciera mejor que fueran ciclos para no incurrir en gestiones del cambio continuas.
Repito que no es con afán de dejar mal a nadie sino con el de obtener este conocimiento.
Estoy preparando el siguiente caso cuando lo publique podremos hacer una comparativa a ver cual es cual.
Y tu demanda me parece muy justa!
PMI Ágil
Para emprender se necesitan herramientas varias, básicas. Gracias por brindar las mismas. Un saludo desde el Perú
A ti por tu comentario Fernando!
Bueno fue demasiado corto el comentario, asi que me explayare un poco xD, claramente se notan algunas caracteristicas del enfoque del PMI, ahora también se hace referencia a los pequeños entregables que podrían significar el uso de Lean o SCRUM, faltaría precisar, ahora la diferencia con este proyecto es que, el rey ya sabia exactamente y con lujo de detalle que es lo que quiere, como, donde, y esto es algo que en la realidad no suele pasar, a menos que se lo sueñen identico a el, el tema de cambios no se tomo mucho en cuenta ya que el sabia que es lo que exactamente quiere -y claro se nota que sabia hasta los materiales y todo, punto a favor del conocimiento del rey- y concluyo que el arquitecto al fin y al cabo uso todos y al final ninguno, su experiencia y los detalles precisos del rey, le hizo dar cuenta que solo tenia que preocuparse por el tiempo que era fijo.
Saludos
Estoy contigo que tu anterior comentario fue muy corto 😛
Te despista un poco el tema de dividir el trabajo en pequeñas tareas…
¿es exclusivo de las técnicas ágiles?
En los desarrollos en predictivos ¿el trabajo se hace en bloques grandes inmanejables?
Creo que la clave del cumplimiento de dos de las tres restricciones básicas, porque al parecer el costo no era una restricción, era el trabajo llevado a cabo de forma conjunta entre el interesado y el administrador cada vez que se reunían para ultimar los detalles, en realidad formulaban la WBS de cada concepto, con lo cual, el hábil administrador podía designar equipos precisos con cada concepto de obra y ejecutarlos en el tiempo adecuado, no importando su coste.
Sergio entonces tienes claro que modelo seguían ¿predictivo o ágil? 🙂