GRAN FINAL: Reflexiones de un PM en un mal día / GRAND FINALE: The deliberations of a PM on a bad day

Versión en Español / English version below

“Enfrentarse, siempre enfrentarse, es el modo de resolver el problema. ¡Enfrentarse a él!”. – Joseph Conrad

Si han estado siguiendo esta serie de artículos (véanse secciones anteriores I, II, III), es natural que a estas alturas del partido estén algo frustrados. Y es que la mezcla de problemas técnicos y humanos detrás de la epidemia de fallas en proyectos es apabullante: ¡En que “broncón” nos hemos metido!.  Pero no estamos aquí para llorar, así que vamos valientes con el contrataque. Divide y vencerás: aprovechemos más bien que tenemos agrupados a los “enemigos” en dos subgrupos para entrarle al tema. Primero la parte de los procesos – la menos interesante a mi parecer – y luego hablemos de las personas y nuestra (valga la redundancia) absurda capacidad para el absurdo, para equivocarnos y para engañarnos. Veamos:

Cómo mejorar los procesos y la organización

Acerca de este tema (debilidades organizacionales y procesales), mi opinión es que debemos implementar un enfoque más estructurado, que nos ayude a “ordenar la casa”: salgamos del “cajón PMI”. Afortunadamente, no tenemos porque “re-inventar la rueda”: la metodología PRINCE2 del Gobierno Británico tiene precisamente esa perspectiva (no en vano se refiere a “Projects in Controlled Environments“). Rescato de ella los siguientes puntos a ser emulados en este nuestro hemisferio occidental:

• El PM como Manager: Primero que todo, la estructura organizacional debe reflejar el hecho de que el Gerente de Proyecto, léase el PM es…  ¡un Gerente y punto! Eso significa que esta persona tiene las potestades y habilidades para gestionar el proyecto, pero nada más. No es el PM la persona que debe generar el caso de negocio, el project charter o quien autoriza proyectos o fases. La metodología PRINCE2 es clara y estipula tres niveles: Nivel Directivo, compuesto por un “Board” que dirige el proyecto, nivel de Gerencia (Management), al cual pertenece el PM, y el nivel de Delivery el cuál ejecuta las tareas como tales.  Ese Board es quien toma las decisiones ejecutivas – es “su” proyecto, el “accountability” reside últimamente sobre el Board. Agrego de mi parte que el PM debe tener voz pero no voto en ese organismo.
• El “Project Executive”: es equivalente al “Project Sponsor” en terminología PMI, pero que ostenta un grado de involucramiento y proactividad mucho mayor. El Project Executive es algo así como un coach y guía activo para el PM y toma decisiones ejecutivas para el proyecto, pero desde un punto de vista de NEGOCIO. Podría decirse que el “Project Executive” es el “Project Sponsor” que todo PM sueña con tener: alguien que, siempre desde un punto de vista estratégico, pero que no teme “ensuciarse las manos” por y para el proyecto .
• Rescatar la importancia del “Business Case”. Los proyectos se hacen por una razón. Sus entregables y objetivos deben ser deseables, valiosos y alcanzables. Todo esto debe de estipularse claramente por escrito en el Caso de Negocio, y este documento debe ser el verdadero punto de referencia para las decisiones directivas sobre el proyecto (eg, aprobación, VoBo para la siguiente fase, Cierre, Cancelación prematura, etc.). Debe consultarse por el Board y el PM a lo largo de todo el proyecto con énfasis al inicio y al cierre del mismo.
• Definición de rangos de tolerancia para el presupuesto, tiempo y alcance, entre otros: el PM toma las decisiones en tanto no se salga de esos rangos. En cuanto la tendencia sea claramente hacia salirse del rango o bien se salga del mismo, debe escalar inmediatamente al Project Executive para recibir instrucciones ad-hoc sobre el caso en particular. Cuando las cosas se salen de control entonces el Board debe “tomar el timón”.
• Utilización de los 7 principios mencionados en PRINCE2: justificación continua / revisión continua del caso de negocio, gerenciamiento por fases, gestión por excepciones, roles y responsabilidades definidos, enfoque en los beneficios, entre otros.
• Cierre del proyecto: esta decisión NO debe ser competencia del PM. En realidad, esta es una responsabilidad exclusivamente del “Board”. En pocas palabras, el proyecto no fue una ocurrencia o idea del PM, tampoco debe ser el PM quien autorize y comunique su cierre. El PM es un delegado, un ejecutor que lleva a cabo el proyecto, pero el proyecto como tal y su enfoque dentro del negocio (la consumación de los beneficios) es un asunto del Board y de nadie más. Valga mencionar que esto aplica también para los CAMBIOS al proyecto, sean estos de alcance, tiempo o fondos.
• Implementar un Reporte de Cierre del Proyecto: en mi opinión personal, si este reporte es implementado y ejecutado de manera correcta sería entonces mucho más valioso para la organización que las (casi, casi siempre) difuntas, marchitas, inertes y olvidadas “lecciones aprendidas”. En mi experiencia, casi nunca se generan las famosas “lessons learned” y cuando sí se recolectan terminan convertidas en listados olvidados en un rincón de “SharePoint” o en un archivo de Excel. Es por eso que sugiero enfáticamente que se implemente la generación de un Reporte de Cierre del Proyecto, lo más corto y sencillo posible, en donde se indique claramente el alcance original vs el final, costo original vs final, duración original vs final, recursos originalmente programados vs utilizados y los “gaps” correspondientes así como (muy brevemente) las razones detrás de esos “deltas” o diferencias. Además, este reporte debe tener “tags” o etiquetas que permitan alimentar una base de datos (eg, tamaño del proyecto por unidad de ejecución – número de servidores, número de agentes, número de licencias, número de metros cuadrados, etc. etc.. tipo de proyecto, etc.) de forma tal que esta información SI sea accesible y de fácil consulta a la hora de lanzar un nuevo proyecto. La base de datos se convierte entonces en una verdadera referencia , un registro histórico que con hechos y evidencia demuestra cuanto es lo que verderamente tardamos en promedio en un proyecto de X cantidad de servidores, Y cantidad de líneas de código ó Z cantidad de metros cuadrados, ¿Se imaginan ustedes el valor que tiene esta información para el Board y para los que venden los proyectos? ¿Y qué tal como fuente de datos para sistemas expertos / inteligencia artificial? (véase punto más abajo)
• Finalmente, la gobernanza organizacional como tal debe mejorar. Resumiendo, la gobernanza organizacional se encarga de definir los objetivos así como las políticas (reglas) & restricciones a respetar a la hora de ir por esos objetivos. En otras palabras, la gobernanza organizacional es asunto del más alto nivel (VPs, C-Suite, Exec Board) y nada más. Es a este nivel que se crean las condiciones, diríamos el “medio ambiente” para que la Gerencia pueda operar exitosamente. En mi opinión, el PMI en el “Practice Guide for the Governance of  Portfolios, Programs, and Projects” comete el error de mezclar aspectos de gerencia con aspectos de gobernanza, y por lo tanto le asigna responsabilidades de gobernanza a niveles medios y bajos de la organización. De mi parte, quedo con la tarea de estudiar el estándar ISO/IEC 38500:2015 “Governance of IT for the organization” y el estándar ISO/AWI 37000 “Governance of organizations”: debe haber una manera de “cocinar” correctamente la mezcla de gobernanza organizacional con la de gobernanza de los proyectos (quizás esto implique además el estudio del estándar ISO 21500 “Guidance on Project Management” y aún otros documentos). Creo que solo este punto amerita, en el futuro, un nuevo post…

Cómo mejorar la gestión y las decisiones tomadas por las personas

¡Ah, el ser humano! He aquí el verdadero quid de la cuestión: si tan solo fuéramos todo lo lógicos, racionales e informados que se supone que somos. Si tan solo el personal de las organizaciones y particularmente los tomadores de decisiones tomarán sentencias en función de criterios objetivos y evidencia… pero no. Lamentablemente, los seres humanos somos cualquier cosa menos eso, estamos llenos de sesgos, subjetividades y heurísticos. Errare humanum est… Siendo así, tratemos de que el sistema compense un poco nuestras faltas personales, propongo los siguientes puntos:

• Metodología de las votaciones: Las votaciones de los Boards deben ser públicas… pero no “seriales” ni en tiempo real. A lo que voy es que para evitar el sesgo mental de “mentalidad de manada”, las tomas de decisiones de organismos colegiados (Boards y similares) deben ser ciertamente públicas (cada miembro debe ser responsable de su voto ante los demás y ante la organización) PERO eso no significa que deba votarse uno después del otro y a sabiendas de cuál fue el voto de mi antecesor. El ejercicio del voto de aprobación o rechazo de un proyecto, fase, cambio, cancelación, presupuesto etc. debe ser simultáneo para todos los miembros y debe comunicarse el resultado minutos después por una figura de “secretario” o similar. De esta forma evitamos el comportamiento “de manada”.
• Veto: Aunado a lo anterior, debe existir la figura del VETO. No tengo aún claro si esta figura debería ser potestad de todos en el Board o solo de un grupo aún más selecto, pero alguien debe de poder poner al menos en pausa una idea o proyecto. La figura del Project Executive arriba mencionada es tentadora para esta atribución tan especial.
• Otras herramientas para las decisiones: Existen otras metodologías que podemos implementar para mejorar la calidad de las decisiones. Algunas de ellas son:
  • “Murder Board”: este interesantísimo ejercicio mental nos propone explícitamente el ponernos en el papel del fiscal y tratar de “asesinar” a las iniciativas y proyectos. Esto es un valioso punto de vista porque en caso que todos los proyectos tengan un ROI positivo (lo cual es esperable, nadie va a proponer un proyecto que no tenga ese carácter financiero) entonces todo es apetecible. Y entonces los seres humanos caemos en la gula… no podemos decir que no: ¿cómo vamos a justificar el decir que no si tal proyecto va a redituar X cantidad de dólares y ese otro Y cantidad? Por supuesto, lo que no estamos viendo es que esos dos proyectos van a sobrecargar la capacidad de la organización y al final atrasaremos a toda el portafolio, causaran multas, problemas de calidad, fricciones con los clientes, “quemarán” al personal. etc.
  • Comparación 1-a-1: se trata de poner a los proyectos a competir uno-contra-uno. Como en la Copa del Mundo, los proyectos compiten unos con otros hasta descubrir quién es el campeón, sub-campeón y en general producir un ranking.
  • Mercado Virtual: excelente metodología de trabajo que nos induce – literalmente – a(y me disculpan el coloquialismo) “ap poner la plata donde ponemos la boca”. A cada representante del Board (cada Director, VP o lo que fuere) se le asigna un monto virtual de dinero y esa persona debe entonces decidir que monto va a asignarle a cada uno de los proyectos / propuestas en el pipeline. Lo que sucede entonces es que la mente pasa de modo “se vale todo” a modalidad “recursos limitados” y se dispara un proceso analítico que genera una priorización automática.
  • Implementación de la metodología “Six Thinking Hats”: este método de pensamiento creado por Edward de Bono nos propone ponernos deliberadamente diferentes “sombreros”, diferentes “modos” o roles de análisis: Procesos, Hechos, Sentimientos, Creatividad, Beneficios y Precauciones. Se asumen entonces diferentes perspectivas que permiten analizar el proyecto/caso/situación desde todos los ángulos.
• Cuéntame… pero no un cuento: Para atacar sesgos mentales/cognitivos como el Anclaje y la Disponibilidad, no veo otra solución mas que, como diría Steven Pinker, contar. Es decir, dejémonos de tonterías e intuiciones y vamos a los DATOS: “gimme facts baby, facts!“. Es aquí donde la implementación y uso del reporte de cierre de proyectos y una base de datos “for dummies”, de uso fácil e intuitivo es crucial. Necesitamos SABER cuánto es lo que tarda/cuesta/demanda-de-personal/equipo en la vida real un proyecto de este tipo y este tamaño. Los datos están ahí pero no en una forma digerible: no es información. Sugiero que nos olvidemos (al menos de momento) de los cuentos y prosas de las lecciones aprendidas (las cuales, como mencioné, casi siempre solo “apilan polvo”) y vayamos directo a los números. De esta forma, si el caso de negocio o el Charter del proyecto indica una duración que supone la mitad del promedio del tipo X de proyecto… necesitaremos una justificación al respecto: no es eso lo que dice la experiencia: ¿Está usted tratando de timarnos?
• El ROI: Y hablando de hechos, evidencias, datos y números, un elemento adicional a “rescatar del olvido” es el ROI. Y digo rescatarlo del olvido no porque no se presente junto con el “Business Case”… sino porque (muchas veces) inmediatamente despúes se olvida. Vamos a ver: cuando se está manejando un portafolio dinámico y grande de proyectos, en muchas ocasiones se exige la presentación del ROI como un requisito para aprobar el proyecto, PERO:
  • No se comparan los ROIs de diferentes proyectos, ni se realiza un ranking.
  • No se revisa/actualiza el ROI conforme el proyecto se desarrolla (conforme cambia la duración, alcance o costo)
  • Y – peccata mortalia (pecado mortal) – no se revisa AL FINAL del proyecto ni tampoco cuando el producto(s)/entregables se han implementado: en otras palabras, no sabemos si financieramente el proyecto hizo sentido o si el ROI fue nada más una linda postal presentada para cumplir con un requisito.
• Rapidez: Un criterio & parámetro adicional que puede ser agregado a los proyectos es el “speed-to-market”: en el mundo actual, la velocidad de implementación es cada vez más importante. De esta manera, proyectos “low-hanging-fruit”/”early winners” pueden tener su nicho en el portafolio/pipeline.
• No va más: Debemos “prohibir” el así llamado “one-time-estimate” de una vez y por todas. Necesitamos como mínimo utilizar el enfoque de mejor escenario – más probable – peor escenario (y la fórmula de ponderación asociada), pero lo idóneo es utilizar probabilidad / estadística y registros históricos.
• “Watson-time”: Además, creo que ha llegado la hora de darle espacio a la Inteligencia Artificial. Esto aún es incipiente pero la AI tiene la ventaja de que es un enfoque fáctico: utiliza datos y proyecciones matemáticas, no intuiciones, rezos y esperanzas. Una correcta implementación de esta herramienta puede “iluminarnos” no solo acerca de las verdaderas fechas esperadas para finalizar tal o cual fase, entregable o proyecto (proyecciones estadísticas), sino que también puede proveer poderosos insumos a la hora de evaluar la alineación de los proyectos y sus cambios con la estrategia organizacional (véase el artículo II de esta serie, en donde se menciona el top 7 de causales de fallos de los proyectos). Veo incluso una oportunidad para mejorar la comunicación organizacional (intra e inter proyecto) por medio de la AI.

Y nos vamos: cierre

No pretendo tener todas las respuestas. Tampoco estoy sugiriendo que el conjunto de propuestas e ideas arriba enlistadas sean una solución total, una “bala de plata” que acabe con este problema. Sin embargo, la mezcla adecuada de estos factores puede servir – cuando menos – como un poderoso paliativo para esta epidemia de proyectos enfermos y fallidos que nos asolan cual zombis de película de terror.

Tengo aún otras ideas en mente (entre ellas, la integración del Riesgo en el análisis), pero primero quisiera escucharles. No dejen de enviar sus comentarios o bien escríbanme a [email protected] . Einstein dijo una vez “No esperes resultados diferentes si sigues haciendo lo mismo” – pensemos entonces “fuera de la caja” y ataquemos de frente este engorroso asunto. Debemos abandonar de una vez y por todas esa visión fantástica e imaginaria en la que el PM es algo más que un simple Gerente y se le adosan funciones directivas y estratégicas, una especia de superhéroe sin capa: difiero completamente de esta idea. Hay un nivel organizacional adecuado para cada nivel de decisión. Así, el PM tiene un rol táctico y una voz sobre las decisiones globales del proyecto, más ciertamente su rol no es estratégico.

Y bueno, supongo que es suficiente: ¡He dicho! Ahora, les escucho…

ENGLISH VERSION

“Facing it, always facing it, that´s the way to get through. Face it.” – Joseph Conrad

If you have been following this series (see prior posts I, II, III), it´s totally understandable that at this time you feel somewhat frustrated. It´s just that the mix of technical and human problems is overwhelming: what a monster! But we are not here to play the cry-baby, lets proceed with a brave counterattack. So, divide and conquer: let´s seize the fact that we got the issues divided into tech and human categories. Let´s start with the process/organizational aspects and then let´s jump to the (to my taste) more interesting human side of the conundrum. Check this out:

How to improve the processes and the organization

On org and process weaknesses, my opinion is that we should implement a more structured approach that attacks the “house divided against itself” syndrome. My take: let´s jump outside the “PMI box”. Luckily, we don´t need to re-invent the wheel, UK´s PRINCE2 methodology enforces that holistic, org perspective (after all, it´s name is “Projects in Controlled Environments“). I want to highlight the following points which should be emulated in this our Western Hemisphere:

• The PM as PM: First and foremost, the org structure needs to reflect the fact that the Project Manager is… just a manager! That means that this person has the skills and authority to manage the project but that´s about it. It is not the PM the one supposed to create the business case, the project charter or the one approving projects, phases or changes. The PRINCE2 methodology is clear on this, listing three org levels to deal with three levels of concerns: Directive Level, composed by a “Board” that actually leads and steers the project, then a Management level that is concerned with tactical stuff (the PM is part of it) and a Delivery level that is executing tasks and creating deliverables. It is the board the one taking executive decisions: at the end, it is THEIR project, since accountability rests on the Board. From my end, let me add that the PM should have a voice but not a vote in the Board.
• Project Executives: Summed to the prior point, we desperately need to implement the role of the “Project Executive”, a PRINCE2 equivalent to the “Project Sponsor” (as per PMI framework), but with a level of involvement and proactivity much farther ahead. The Project Executive is sort of a coach and active guide for the PM and actually takes executive decions for the project, but this person has a BUSINESS vantage point. We could say that the the Project Executive is the Sponsor that all PMs dream for: someone who, with a strategic and business perspective, is always willing to take decisions and actually “get the hands dirty” in order to make the project succesfull.
• The “Business Case”: Projects are done for a reason. Their deliverables must be desirable, valuable and achievable. All this – and more – must be clearly stated in the Business Case. This doc is the real anchor and “map” serving as a reference for exec decisions (eg, Phase approval, Closure, Cancellation, etc.). It must be regularly checked by the Board, the Exec and the PM, especially during project Launch and Closure.
• Tolerances: one-point definitions for budget, time, QA-aspects and others are a bad idea. The PM should have tolerances in order to properly manage the project. When there is a trend pointing toward upcoming out-of-range or factual out-of-range/tolerance, the PM must immediately escalate to the Executve and receive ad-hoc instructions. Possibly, the Board could be involved in order to steer toward more “calmed seas”.
• Usage of the 7 PRINCE2 principles:
  • Continued business justification, the project should be beneficial, and stay so.
  • Learn from experience, we are not supposed to reinvent the wheel.
  • Define roles and responsibilities,each person should know what others expect from them, and what they can expect from others.
  • Manage by stages, project should be broken down into stages, and planned/executed/controlled accordingly.
  • Manage by exception, there should be a well-formed system for delegation and escalation.
  • Focus on products, rather than on activities.
  • Tailor to suit the project environment.
• Project Closure is NOT a decision/competence of the PM: this is something to be defined by the Board. In other words, the project was not the PM´s idea, so… why should him/her determine its ending? The PM is a delegate, responsible for the day to day management of the project in behalf of the Project Board, but the project and its business perspective (such as benefits) is beyond his/her duties. Let me add that this applies to Changes as well, regardless those being related to scope, time or budget.
• Implement a Project Closure Report: in my opinion and as long as it is implemented correctly, this report is far much valuable to the org than the (almost always) passed-away, dead, withered, droopy lessons learned. As a matter of fact, lessons learned are seen as of a bureaucratic hurdle to be avoided or dealt with on a “get-rid-of-it” basis. That´s why they tend to be forgotten in “dusty” lists in SharePoint or Excel. That´s why I strongly advise to collect DATA: original scope vs actual final scope, original budget vs actual final spending, original duration vs actual final duration, planned ROI vs actual ROI (among other) and (really briefly) the rationale behind the deltas/differences. And perhaps even more importantly, this data needs to be fed into a DB under the right tags and search criteria, in order to make it truly available for next project (and possibly, even AI-powered advisers). The project associated to the data should be characterized in the adequate terms (eg, number of servers, number of agents, number of licenses, number of square meters/feet, etc.) In this way data becomes info. The DB is a handy tool, a historical repository of truth that with facts and evidence states the true cost, duration, ROI, etc. of X type of project. Can you imagine the value of this info for the C-suite, Sales, Consulting and the Board?
• Last but not least, organizational governance needs to improve – and a lot! Briefly, org governance deals with the definition of the org objectives as well as the policies, rules and restrictions to respect when operating toward those goals. In other words, org governance is a topic for the highest org levels (VPs, C-Suite, Exec Board) and no one else. It is at this level that the conditions, that a successful environment is created for Management to operate (in turn) successfully as well. In my humble opinion, the PMI mixes management and governance aspects within the “Practice Guide for the Governance of  Portfolios, Programs, and Projects” doc.  I will put into my to-do list the study of the ISO/IEC 38500:2015 “Governance of IT for the organization” and the ISO/AWI 37000 “Governance of organizations” standards: there must be a way to correctly “cook” the blend between organizational and project governance (perhaps this also implies a deep-dive into the ISO 21500 “Guidance on Project Management” title and even other documents). I guess just this point accounts for a new post in the future: stay tuned!

How to improve the human factor (especially, the decision process)

Gosh, the human being! This is THE issue… if we just could be as logic, rational and informed as we are supposed to be. If org staff – and decision takers in particular – could make their calls as a function of solid criteria, facts and evidence, but… no. Sadly, we human beings are totally prompt to bias, subjectivity and heuristics. Errare humanum est… Being that the case, let´s try to make the system a little less easy to hack by our humanity, I suggest the following practices:

• Board votings should be public… but indeed not “serial” nor in 100% real-time. What I mean is that in order to avoid the “herd mentality” bias, decisions from boards and the like should be kept public for the sake of accountability, but that does NOT means that each member should vote one after the other, getting to know each one´s vote. The voting exercise should be simultaneous for all members and the result should be communicated a couple minutes later through a secretary-like figure. In this way, we avoid the herd behavior.
• Plus, the VETO figure should be available. I am not sure if this capability should be available to all the Board members or just to a select group, but someone must have the power to pause an idea or project. The Project Executive figure is a nice candidate for this (more on this figure below).
• There are other methodologies we can use to improve the quality of decisions. Some of them are:
  • “Murder Board”: this is a really interesting mental exercise, which actually puts us in the prosecutor role and we try to “kill” initiatives and projects. This is valuable because (normally) all projects have a positive ROI (else, why should we do them – no one is going to suggest a project with a negative financial outcome), thus, everything looks just “yummy”… and orgs get greedy. I mean, how can we say no to project “A” if it´s going to generate actual revenue? Its good for us! And what about project B? And C? And X?  Of course this line of (no) thought leads into “stack overflow”, overloading the pipeline, delaying the entire portfolio, frictions with customers, fines, staff “burnout” etc.
  • Paired comparison: this one is about putting the projects to compete F2F. Like the World Cup, the projects “eliminate” against each other until we have a champ, a runner-up and a general ranking. Great for priotitization!
  • Virtual Market: superb methodology that literally makes us put the money where we put the words. Each Board representative (Director, VP, you name it) is assigned an amount of “virtual money” and then they got to assign funds to the projects according to their best criteria. What happens is that the decision takers shift from a “anything goes” to an analytical mindset.
  • “Six Thinking Hats” methodology:  this method, created by Edward de Bono, pushes for the person to play different thinker roles, including the Process, Facts, Feelings, Creativity, Benefits and Caution ones. As such, we got a structured approach to analyse the project/topic through a variety of angles.
• 1…2…3… lets count: In order to attach cognitive biases such as the Anchoring and Availability ones, I don´t see any other option but actually (as Steven Pinker says) counting. I mean, let´s cut to the chase: I want to see DATA.  No more poppycock: “gimme facts baby, facts!“. It is here where the implementation and usage of the Project Closure Report and a “for dummies” DB is crucial. We need to KNOW how much/how long/how much staff & equipment does this type of project actually entails. In my experience, data is there but not as info: its nebulous. I suggest for us to forget (at least for the time being) about the dusty prose in lessons learned and go direct to numbers. In this way, if the Business Case or Charter states a duration of, say, half the average for this kind of project, there will be an immediate warning sign – a justification is needed. Is someone lying?
• ROI: And speaking of facts, evidence, data and numbres, an additional element to rescue from oblivion is the ROI indicator. And I am saying “rescue from oblivion” not because it is not calculated, but because it is done once (during the business case or charter creation) and then sent to another pile of dusty docs. It is created as a requirement to present the project but that´s about it. Hence:
  • There is no comparison of the ROIs of different projects, needless to mention the absence of a ranking.
  • The ROI is not updated as per the unfolding of the project, not to mention when the scope/time/budget changes.
  • And – peccata mortalia (mortal sin) – it is not validated at the END of the project nor when the actual product/deliverable is implemented. As such, we don´t know if the project was actually a success from the business/financial standpoint. Nonsense…
• The Fast and the Furious: Another criterion / parameter to add to the analysis is “speed-to-market”: nowadays, the actual velocity of the project delivery or implementation is key. As such, “low-hanging-fruit”/”early winners” projects will have their niche in the portfolio/pipeline.
• No more: We should ban once and for all the so-called “one-time-estimate”. We need at least to use the best-case-scenario / most-probable / worst-case scenario formula, and ideally we should jump into statistics derived from solid data: history, facts!
• “Watson-time” – let AI come:  Finally, I think it is time to give a space in the stage to Artificial Intelligence (AI). This is still somewhat crude but we need to acknowledge that AI has the superb advantage of using a factual, objective standpoint all the time: data, trends, math instead of gut feelings, hopes and prayers. A correct implementation of this tool could certainly enlighten us not just about the realistic dates for finishing the phase or project but also provide valuable insight as of the alignment of the projects vs org strategy (see section II of this series of articles for the 7 main reasons behind project failure) and the reasons behind gaps and pitfalls. Furthermore, AI can also improve communication, both intra & inter projects and with the org.

Closure remarks

Let me say that I don´t pretend to have all the answers. Neither Im suggesting that the above list of ideas should be taken as a “silver bullet” that will solve this problem like an aspirin takes over a headache. Still, the adequate blend of those (plus others to be identified as per project/org/analyst) can really help to improve the health of projects and portfolios that currently pursue PMs as zombies in a bad movie.

I have even more ideas in mind (eg, the integration of Risk within the analysis, Problem Solving tools, etc.), but I would really like to hear from you first. Please don´t hesitate to send your comments here or write to [email protected] . Einstein said that “the definition of insanity is doing something over and over again and expecting different results” – lets think “outside the box” and tackle this monster directly. We need to abandon once and for all the false vision of a PM with “superpowers”, a magical mix of operational, tactical and strategical skills: kind of an org superhero. There should be an org level for each level of responsibility.

I guess enough is enough. Now, let me hear you guys… cheers!

“Management is doing things right; leadership is doing the right things.” – Peter Drucker

Material Adicional:

• Six Thinking Hats: click here
• About PRINCE2: click here 
• ISO Standards: click here

Nota/Photo Credit: Photo by Nikita Kachanovsky on Unsplash