Pick up that phone!
“The medium is the message.” – Marshall McLuhan
In days to come, 2020 will be referred not only as the COVID pandemic year, but as the Work-From-Home super-spreader. Globally, jobs not requiring our presence at a physical office are running from our homes, with all the pros & cons that this externally imposed statute implies. In this post, I dare to share the simplest yet most underrated productivity tip for these convoluted times, which is (drums rumble) … pick up the phone! Please don´t tell me you don´t have a physical handset; that is not the point. What we are saying is that we need to bear in mind, carved in letters of gold, that a voice call expedites almost any back-office process you can think about. Yes, I am not talking about fixing a meeting (enough we have, don´t we?) or an unproductive status checkpoint, this is about the old-fashioned 1:1 call – just you and the other stakeholder. For heaven´s sake, don´t email if urgent – pick up the phone and call “John”. And if you have not interacted in a time, if deemed appropriate, ask “Mary” about the family & friends – let´s keep a healthy “layer 8” (human) network functioning: times have shifted, but relationships are still (and perhaps) more important than ever.
On a related line of thought, turning on the camera during meetings and calls is mostly a good idea. Not only it conveys humanism, but it forces you to be “there” and to prepare for the meeting or call. This preparation also implies taking an early shower, dressing appropriately, shaving, make-up being the case, etc. Yes, we are physical beings and taking a shower is part of the daily personal boosters routines. If “cameras on” is what is needed for that to happen, so be it.
In conclusion, we should all develop a sixth-sense, just not for seeing dead people, but for detecting “zombie” email threads (“The Walking Mail?”). We are becoming more and more afraid to pick up the phone and call a co-worker, a customer or a supplier. Think about it: why the hesitation? It’s just a business call – talking to a peer or liaison. What is all this anxiety about? What are we afraid of? COVID cannot spread through the lines but apparently we kind of assume so. We are confusing physical social distancing with self-inflicted isolation. This is a bad thing for the industry, for the business, for our relationships, and for ourselves… and the fix is easy: pick up the phone!
Enough said, this is the end of the post. Let me hear any comments, thus, just give me a call :o)
Fernando
The Quest for (True) Sponsors
“Who finds a Friend finds a Treasure”, says the old adage. The same applies for the wild “Project Kingdom”, where we can paraphrase and say the same thing, just only for Sponsors. Alas! It is just that true Sponsors are really an uncommon thing in the Project Management world: a rara avis within the modern business jungle. Now, a disclaimer is necessary upfront: it is not the case that sponsors are actually deliberately acting against PMs or more importantly, against the project and its goals. It actually doesn’t makes sense for a Sponsor to sabotage his/her own interests & organization. The project´s success is their success. So what is going on here? Answer: in the vast majority of the cases, sponsorship issues can be grouped in five general categories, as follows…
Sponsorship Problem Categories
- Work Overload: the Sponsor role demands someone with criteria, someone with experience, someone with enough ascendancy & power in the organization. These are individuals entrusted to make decisions. They manage budgets and resources. Sponsors are normally high-ranking persons within the org: C-suites, VPs, Directors. Thus, they are very busy and get pulled simultaneously from many directions. You see the in-built conflict here? The Sponsor role demands for high-profile staff who is already over-allocated. The result is that many sponsors – logically – privilege day-by-day work and “keeping the lights on” in detriment of their sponsor “additional hat”, all this to a negative effect on the projects.
- Organizational Immaturity: The Random House Dictionary defines maturity as “full development or perfected condition”. So this factor actually refers to lack of development in our entities. To put it simple, the organization (or its division) is not ready for a “projectized ecosystem”. Actually, the prior bullet point is a reflection of this, since the entity as a whole is not aware of the current workload distribution within its leads or simply lacks enough headcount to cover the sponsor roles. Another possibility is that the governance process and/or body managing the portfolio is weak. This is a common situation: the organization is immature and fills roles with names “just to fill the field”, to a total misunderstanding of the actual requirements, consequences and implications of this behavior. The governance process (Portfolio Management, “Approval Gates” system, Resource Allocation, etc.) is probably weak. Moreover, the Sponsor is not understood as the ultimate accountable person as of the project success. Au contraire, a mature organization with a solid governance process is nearly “vaccinated” against “sponsor-virus”, to put the topic in hands in our era´s terms.
- Lack of Knowledge: lets recall the actual definition of a Sponsor. According to PMI´s PMBOK 6th Edition, a Sponsor is “A person or group who provides resources and support for the project, program or portfolio and is accountable for enabling success.” I don´t know about you, but that short statement really raises my eyelash. There is a lot in there: “provides resources and support”. Also, “accountable”. And then, “enabling success”. What an explosive combo! And yet, Sponsor role training is really uncommon when compared to the Project Manager role (PMP vs ???), not to mention other technical and business areas abundance of training & education. Actually, my research found just a couple Sponsor certifications, such as PPS by APMG. This is quite interesting: if all projects should have both a PM and a Sponsor, how come this total disproportion? How come there is no specific Body of Knowledge for that role? A final disclaimer on this point: if the org runs under a PRINCE2 framework (back to the maturity point, I guess), then precisely the “Controlled Environment” part should tackle many of these issues away.
- Shared (fake) Accountability: I (Fernando) personally disagree with the PMI inclusion of a “group” as a possible entity to play the Sponsor role. In my personal opinion, “shared-accountability” is sort of an oxymoron. Accountability is personal or it isn´t. Therefore, more than one name listed as Sponsor is a contradiction in terms. I also think that there may be exceptions to this principle in the real world, especially in really mature places (CMMI L5, Prosci CM L5, PMI OPM3 L4 and similarly rated organizations) but exceptions are precisely that: rare, sparse, in a word – exceptional.
- Any possible combination of the above… which, in my experience, tends to be indeed the most common case.
How to solve this mess
What´s to be done with this situation? Let me quote Plato: “Ignorance is the root and stem of all evil”. What I mean is that education both to the individual and the organization should be the first step: we need to fully understand & digest that a Sponsor is not just a signature or a name in a PPT slide. Project Sponsorship implies active engagement, dedication, time & energy. A Sponsor should be a champion for the Project, acting sometimes as a lightning-rod in order to shield from external attacks to the endeavor, sometimes dealing with the complex organizational politics, sometimes serving as a guide to the PM. Sponsors promote, authorize, fund, approve, distribute and receive info, resources & outcomes for and to the project. They are also escalation paths, priority masters and scope definers.
Sponsors should be educated (certified), and the organization should acknowledge its maturity level and perhaps even more importantly, assign time & resources for the role. Building on this idea, and thinking outside of the box, perhaps for really busy, high-level individuals sponsoring many projects, a dedicated Sponsor Assistant may be an option. That would be a really savvy business individual, someone empowered to make decisions within pre-defined thresholds/limits/rules and with the responsibility to compile, filter and summarize key insight to the Executive he/she serves: sort of a smart funnel point for sponsorship affairs. That being said, accountability must reside in the official Sponsor and him/her only: it is a personal requirement, period.
Then for really large corporations, here´s an original idea: some organizations may require an “SMO”, the equivalent to a “PMO”, specifically, the Supportive type, but tweaked for the Sponsor role. I devise this entities as similar to their PMO equivalent, providing a purely consultative/assistant role to Sponsors by “supplying templates, best practices, training, access to information and lessons learned from other projects” (Giraudo, L. & Monaldi, E. (2015). PMO evolution: from the origin to the future. Paper presented at PMI® Global Congress 2015—EMEA, London, England. Newtown Square, PA: Project Management Institute.). Moreover, SMOs could be “Delivery support functions/services – these focus on supporting the delivery of change and may be provided through a central flexible resource pool of delivery staff, with capacity planning, and HR management processes.” (Giraudo, L. & Monaldi, E. (2015). PMO evolution: from the origin to the future. Paper presented at PMI® Global Congress 2015—EMEA, London, England. Newtown Square, PA: Project Management Institute.) So there you go: SMOs, an internal consultant agency for Sponsors, if you will, is born.
Conclusion
Sponsors are the top liaison, the ultimate bridge between the organization and the project. There is a reason why they are the ultimate accountable staff for the project success – their active commitment & engagement is proof of it. Furthermore, the mandatory time, processes, tools & resources required to execute the role must be provided by the organization, else, the organization is tricking itself.
I´d love to hear your thoughts on this topic. Email me or preferably state them as a comment to this post.
Cheers,
Fernando
Re-learning to LISTEN!
“Wisdom is the reward you get for a lifetime of listening when you would rather have talked.” Mark Twain
Have you thought how much of your free time is devoted to visual-driven activities VS. the time associated to audio-driven ones? No, I mean it: think about it. If you are an average person, your hobbies probably range from Netflix to watching live sports: NFL, NBA, MLB, soccer, hockey, cricket, UFC, etc. There are also TV sitcoms, talk shows, YouTube, Disney+, video games and a whole menu of other visual pleasures (should I say drugs?). Then there is the old taste of going to the movies. There are still even some of us who read for pleasure or go to the theater or live shows.
Furthermore, what nowadays goes viral in social networks are either pictures, memes or videos. They are the virtual “sugar” of our times.
Curiously enough, when talking about professional time (work) we are required, many times, to only listen. Yes, just LISTEN: long phone calls, audio conferences, presentations from your leaders, etc.
I strongly believe that the absolute imbalance between the personal time devoted to visual vs listening activities is correlated to our terrible performance when required to solely listen at our jobs. If we are totally used to guide our minds mainly through the eyes, then it is logical that we feel lost, awkward and uneasy when having to guide ourselves solely by the ears: our main compass is lost. We are just not used to listen, and therefore our attention focuses on the slides on the screen, missing what the presenter is saying. We are attracted to the photos within the Skype chat and whatever stuff is available in our phone and screens… our sole captain is the eye.
Of course, this is a recipe for failure: we are missing crucial information during those key meetings, calls, conversations. What´s to be done? I have three simple yet useful suggestions to improve our listening skills at work:
- Listen to radio shows / opinion programs / podcasts during our free time. Audio-books also work. It is all about re-wiring our brains so they are capable of focusing on audio info only during extended periods of times. Repetition is key to mastery: we need to re-balance visual and audio activity.
- When attending a business meeting, have pen & paper around and take notes. Involving our hands changes the whole equation, deriving in more focus and retention. Ditto for virtual meetings: even typing/transcribing the call helps.
- Try not to interrupt… and I´m not even talking about raising your voice. I am referring to consciously avoid judgments while our interlocutors are talking. The moment our internal voice speaks up, we are not attentively listening. Let’s shut up the internal monologue during those times.
In this XXI century when the vast majority follows the eyes, being capable of following the ears can be a true differentiation. This applies to all of us in the knowledge economy, but particularly to Managers, Leaders, Execs, Coaches, PMs. Let´s re-learn to listen. Yep: as simple as it sounds and as tricky as it is, let´s just LISTEN.
Cheers,
Fernando
PS: The Buggles made a song in 1979 which is almost an omen for these times. Listen below to “Video Killed the Radio Star”…
Photo by Alireza Attari on Unsplash
When projects fail (WHY?)
“Most people are so focused on technical details that they can’t see the bigger picture. Don’t bother “checking the numbers” instead “check your assumptions.“ – Eli Goldrattt
“Check your assumptions”. YES! The entire post hinges around this master advice – you will see. Thus, under its empowering light, let me continue with (another) quote, this one from the PMI Pulse of the Profession 2019 (2019) document. Let´s try to digest this with slow, analytical thinking: “Data from the new 2019 Pulse survey show organizations wasted almost 12 percent of their investment in project spend last year due to poor performance—a number that’s barely budged over the past five years.” Hmmm. Seems that despite all the efforts in the Project Management sphere, we are stuck. Why? Well, last year´s edition of this very publication (PMI Pulse of the Profession 2018 (2018)) states that:
“1) Organizations fail to bridge the gap between strategy design and delivery.
2) Executives don’t recognize that strategy is delivered through projects.
3) The essential importance of project management as the driver of an organization’s strategy isn’t fully realized.”
Let that slowly sink in and in the meantime, let me quote the survey within the same document (PMI Pulse of the Profession 2018 (2018)) which has this question: “Of the projects started in your organization in the past 12 months that were deemed failures, what were the primary causes of those failures? (Select up to 3)”. The top three answers were “Change in organization´s priorities (39%), Change in project objectives (37%), Inaccurate requirements gathering” (35%). Bonus track – the next one is “Inadequate vision or goal for the project” with 29%. Hmmm…
“So Fernando, lots of fancy quotes but… what´s your point, man?” ANSWER: my point is that the problem with projects is (mostly) not within/about projects themselves. The project is not the problem – the problem is the ORGANIZATION itself, being it a corporation, SME, NGO, government agency or any other. The problem is that there is an underlying assumption that organizations are ready to execute projects (or at least certain types of projects) for which they just lack the necessary skills and the required maturity level. And we got evidence – smoking guns, in my opinion. In my experience, the chronic demand (lack of) competent project sponsors is just the tip of the iceberg, but a huge one it is: hitting this sole tip has sunk thousands of “Titanics” (meaning, projects of course). But then 90% of the mass of ice is submerged. The very PMI states that there is an abyss between the organization strategy and leadership and its project´s ecosystem. Projects need to align to the organization, but I say that the organization needs to be ready (aligned) for projects as well. It is the organization the one that must raise to the challenge of a “projectized” reality. Organizations should function in such a way that projects are condemned to success. An utopia? Perhaps. But my experience and the provided evidence demonstrates that the current average org is more on the other end of the spectrum – chronic chaos – which is in turn absolutely unacceptable. This sad reality translates into projects that are sentenced to failure even before they are formally “born”: no real sponsor, no real budget, unclear scope, governance mess, chronic resource overallocation… you name it. Alas! That´s why we are seeing the current state of things, where seemingly no progress is possible (5 years in a row with no improvements as per 2019 Pulse of the Profession, remember?).
But let me finish on a brighter note. Organizations are human constructs and, so long we don´t break natural laws of the Universe, we can mold them. As of how to do this – how to craft project-compatible organizations (more flexible, change-driven, congruent both horizontally and vertically) – we will talk about it in a coming post. Let me give you just a teaser for curious minds (yet another quote – I just can´t help it):
“Quod obstat viae fit pro via.” – Marcus Aurelius.
PS: the “check your assumptions” advice applies not only to projects or business. As you can guess, this is wisdom that applies for life as a whole.
Photo by Sarah Kilian on Unsplash
Photo by David Kovalenko on Unsplash
“One graph to rule´em all”: the Project Mgmt continuum
“Change occurs on a continuum and does not move in a straight line.”
― Sharon Weil
Perhaps you, as I do, perhaps both of us like to see patterns, trends, relationships. It is sometimes quite a mania, but it has also plenty of pros. For starters, it drives you into a scout mindset, open to curiosity and intellectual adventure. It also teases you into “why” mode, looking for rationale and causality. And it even helps with memorization – our mind is a “sense-making machine”. Thus, when we see relationships between concepts or events the ideas stick to our skin like crazy glue sticks to… well, to skin. But, alas! enough with the preliminaries, let´s dive into today´s topic (as per below´s pic, pun intended).
On the flipside, “siloed” concepts are hideous. Their isolation is just an appearance, a cloak, a false display of purity that derails from reality and objectivity. That´s why the apparent segregation between the Agile and Waterfall categories of Project Management methodologies has always annoyed me. I mean, is there really no bridge across them? Is this truly an opposition, an antithesis of insular approaches? I recently came to an angle that disproves the apparent discrete (discrete in the sense of disconnected, discontinuous) and conflicting nature of these two Project Management methodologies. Even better, it can be scaled to provide a common reference across ALL Project Management approaches. The novelty is to map the methodologies, standards and frameworks against their intended time-control target: this in turn creates a continuum across a single axis. A picture is worth a thousand words, hence please take a look:
The above is “One graphic to rule´em all” (sorry if you were expecting it to have the shape of a ring). In any case, it pretends to be a one-stop, quick depiction for ALL Project Management approaches. Of course there are other methodologies not listed in the diagram (eg, ISO 21500, GAPPS, LEAN, GREEN PM, and even regional approaches as in Russia, Japan and other large countries) but I´m keeping it short for the sake of clarity – we don´t want to create a TLDR situation within the image.
Moreover, as of hybrid approaches, I believe those should be placed precisely in the limit of the aforementioned categories/boxes. This in turn applies to the SAFe, LeSS, Scrum@Scale, Nexus, DAD, Watergiles and similar of this world. I would even dare to extend the idea to DevOps and related practices.
BTW, I don´t know if you already noticed, but the graphic has the additional advantage of providing common ground across different categories of entities: methodologies, frameworks and standards. We will talk about the differences – and relationships – in a later post.
But for now, let´s keep it short n sweet: may this simple thought exercise help us, PMs of this world, to put a little order in the ever expanding universe of Project Management. Hope you enjoyed reading this short article as much as I did researching for it. Now, let me hear you: what do you think – would you concur? Or perhaps not? Ideas to improve or amend? I am all ears...
Cheers,
Fernando
Photo by Blake Richard Verdoorn on Unsplash
Conferencia próximo 7 de Septiembre – Congreso PMI, Medellín, Colombia
Un breve comercial: el próximo 7 de Septiembre estaré presentando una charla en el IV Congreso Internacional de Dirección de Proyectos organizado por el Antioquía Colombia Chapter. De hecho, el Congreso tendrá lugar durante dos días consecutivos, iniciando desde el 6 de Septiembre y cerrará al día siguiente, espacio durante el cual estaré presentando mi charla “El Futuro del Project Management: una predicción para los próximos 15-20 años“.
Y… ¿sobre qué trata la charla en cuestión? Bueno, pues es ya vox populi que la Inteligencia Artificial (AI) está “de moda”: lo que fuera una eterna promesa es hoy por hoy una realidad que permea poco a poco múltiples dominios, desde la conducción de vehículos, pasando por la práctica legal e inclusive el arte. Curiosamente, las implicaciones para la disciplina del Project Management han sido poco exploradas y menos aún difundidas entre la comunidad de PMs.
Reflexionemos: muy pocos de nosotros somos conscientes sobre los cambios que afectarán a nuestra profesión. Esta charla de 45 minutos ataca esta brecha ilustrando las siguientes 4 etapas evolutivas del Project Management. Se incluyen incipientes ejemplos de herramientas afines a la profesión que utilizan tecnología AI. Se presenta además la interpretación personal del autor sobre estas tendencias y desarrollos por medio de la identificación y caracterización de tecnologías que automatizan procesos afines a nuestra disciplina. Concluiremos conversando como adaptarnos a esta nueva era de colaboración hombre-máquina.
Les invito a revisar la página de la charla para mayores detalles… ¡Nos vemos en Medellín, Colombia!
Fernando
There ain´t no such thing as a “good, pretty, fast & cheap” project
The core argument of this article is so simple that it has already been stated in the title. It´s a straightforward idea: to my humble criterion, a self-evident truth. But… alas, reality is complex and we humans are masters of self-deception. Moreover, self-deception has the terrible mania of becoming part of organizational culture, especially in large organizations. What I just said is wrong, beg your pardon. The inverse is the correct statement: organizations have the suicide obsession of self-deception. Hence, it is time to talk about project drivers, restrictions and priorities. Buckle up, here we go:
In my experience, every project has a driver. What do I mean by “driver”? In this context, it means the ultimate restriction to respect. It could be time if urgency is key. It could be cost if a limited budget is cornerstone. It could be quality if excellence is the choice. It could even be scope, if it is all about meeting a list of requirements. But the argument stands: there is always an upmost aspect to attain above all the other. Not two, not three. There is one and only one driver. Of course, this doesn’t means that there could be a secondary parameter to respect or even a third, but a scale of priorities is always inherently present. Moreover, as per the nature of projects (of reality we may say), if we accelerate the pace, the rate of resource usage increases, which translates in more costs (unless you cut scope or quality). If the scope increases, this implies more time and/or cost. If the budget is reduced, it will impact the pace, the scope and/or the quality of the outcomes. These are hard, historically proven facts: it’s the old triple-restriction story yet once again. Nonetheless, and as stated in the opening, we don’t have these truths as clear and present in our minds as they should. BTW, when I say “we”, I mean mainly the PM community but this applies to the entire universe of project stakeholders: Sponsors, PMOs, Steering Committees, Managers, Directors, SMEs, you name it. All right, but “So what?” you may ask. Let’s conclude this short article then with a practical conclusion:
PMs should be the first evangelists of this truth. Every time we receive an endeavor, we must ask: “What is the project driver?” – and explain the nature of the question and the implications of the answer as well. It should be a mantra, a fixation, a standard procedure, over and over again. On the other hand, organizations and their leaders (Managers, Directors and especially C-Suite staff) must acknowledge this truth, once and for all. People making org decisions must align the project portfolio to strategies, priorities and drivers. There ain´t no such thing such as a “good, pretty, fast & cheap” project. Sometimes the election of the driver isn’t easy, but that is the nature of life: deal with it. You need to choose. Omitting or even deferring this crucial point is a recipe for failure.
The “fast, cheap, flawless, all-requisites in” endeavor is an absurd lie: an utopia that crashes with reality. Let´s stop daydreaming. We see the consequences of this every day in the Project Management world. In the intent of finishing with a positive note, I have also seen the POWER of enforcing the project-driver good practice. It works as an strategical enabler that provides clarity, an ultimate criterion for decisions and a leverage for success: a no-brainer for a true Sponsor. Thus, let´s choose. And let´s choose wisely.
Cheers!
Fernando
Photo by Brian Wertheim on Unsplash
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:
Nota/Photo Credit: Photo by Nikita Kachanovsky on Unsplash
Reflexiones de un PM en un mal día (parte II) / The deliberations of a PM on a bad day (part II)
El Pensador / The Thinker – A. Rodin (photo by Andrew Home)
VERSION EN ESPAÑOL (ENGLISH VERSION BELOW)
“La ignorancia es la semilla de todo mal” – Platón
En un artículo/post anterior (adivinen su nombre…) dijimos que la causa última – lo que en inglés se llama la “root cause” – asociado al fallo de tantos proyectos (en mi humilde opinión, de la mayoría) es la organización: la empresa o entidad como tal. Más aún, dijimos que eran los procesos organizacionales los culpables: procesos mal diseñados, mal implementados o mal ejecutados (o una combinación de estos aspectos). Tenemos entonces a un sospechoso: el sistema como tal, y caracterizamos a este sospechoso bajo el calificativo de una deficiente o incluso ausente gobierno corporativo: se trata de ORGANIZATIONAL GOVERNANCE. Postulo entonces que el fallo de la mayoría de los proyectos no se debe a causas nacidas dentro del proyecto, sino a aspectos coyunturales asociados al entorno del mismo. Antes de brindar algunas ideas para atacar este “enemigo universal”, permítaseme justificar por qué sostengo que es ese el meollo del problema. Quiero decir, de momento es solo mi opinión: no he argumentado ni he brindado evidencia que sostenga la hipótesis. Procedamos entonces a aportar una justificación.
Comienzo con datos. Vamos entonces al ultimo informe “Pulse of the Profession”, edición 2018, por el Project Management Institute (PMI). Es en la página 25 de este informe (parte del Anexo), se pregunta (la traducción es mía): “De los proyectos iniciados en su organización en los últimos 12 meses que fueron juzgados como fallidos, cuáles fueron las causas primordiales? (Seleccione hasta 3).” Luego se provee el compilado de las respuestas, que incluye 17 causales. Me permito transcribir aquí el top 7:
- Cambio en las prioridades de la organización: 39%
- Cambio en los objetivos del proyecto: 37%
- Recopilación incorrecta de los requerimientos: 35%
- Visión o meta inadecuada para el proyecto: 29%
- Comunicación pobre o inadecuada: 29%
- Oportunidades o riesgos no fueron definidos: 29%
- Inadecuada gestión del cambio: 28%
Propongámonos la meta de tratar de encontrar un mínimo común denominador en esta lista. Es retador puesto que a primera vista, estas razones para el fallo en los proyectos aparentan ser algo disconexas. Sin embargo, si miramos más atentamente, podemos ver que la palabra “cambio” se menciona en tres de ellos. En otros tres de ellos se habla de una meta inadecuada y de requerimientos incorrectos (una visión inconexa con la estrategia organizacional o bien ajena a las necesidades), además se menciona una mala gestión del riesgo (nótese que el mismo PMI utiliza el término “riesgo” de una manera cuestionable, puesto que en este informa lo utiliza como sinónimo de “Amenaza” y no como sinónimo de evento incierto; véase la definición de “Risk” transcrita abajo). Los otros dos factores mencionan aspectos de comunicación y costos. Sostengo que el mínimo común denominador (o al menos, la mejor aproximación que puede haber a una causa común) es un asunto ajeno al proyecto: no es una “infección local”, se trata más bien de un “mal pandémico” asociado más bien a la ORGANIZACIÓN.
Prosigo: las tres razones que expone Mr. Mark A. Langley (Presidente & CEO del PMI) para justificar el hecho de que el 10% del presupuesto global en proyectos se “vaya a la basura” debido a un desempeño inadecuado son (PMI´s “Pulse of the Profession” report 2018, página 2):
- Las organizaciones fallan a la hora de intentar cerrar el “gap” entre el diseño de la estrategia y su ejecución/delivery.
- Los ejecutivos no reconocen que la estrategia se implementa a través de los proyectos.
- La importancia fundamental de la disciplina del Project Management como el “driver” de la estrategia organizacional no es adecuadamente interiorizada.
Lo interesante es que el PMI (ciertamente no en ese informe y – que sea de mi conocimiento – en ninguna otra parte) se pregunta el POR QUÉ se presentan esos problemas. De nuevo, postulo aquí que se trata de un asunto de (deficiente) gobernanza: en una analogía, cual si fuera una persona que desea bajar de peso y no puede imponer su voluntad para mantenerse a dieta, la organización carece del “auto-dominio” para comer nutritiva y sanamente – léase que le falta la capacidad de imponer la estrategias que define (ya hablaremos de las razones). Siguiendo la analogía, la organización tampoco acepta que los proyectos adecuados son esos platillos nutritivos y correctos que la llevarán al peso deseado y desconoce el valor del ejercicio y la nutrición (el Project Management).
Me voy a permitir seguir argumentando: el mismo reporte 2018 indica que solo el 37% de las non-enterprise-wide PMOs están altamente alineadas con la estrategia organizacional. Es decir, el 63% no lo están. En el caso de las enterprise-wide PMOs (EPMOs) el resultado no es mucho mejor: solo el 41% lo está. A mi parecer, esto es grave: si bajando un solo nivel de management (C-Suite a Enterprise PMO) se perdió el alineamiento en el 60% de los casos… ¿qué podemos esperar a la hora de bajar al nivel de los proyectos, por no hablar de sus requerimientos y entregables? Además, la disciplina del Portfolio Management es gestionada solo por el 48% de las EPMOs, y marcos normativos como PRINCE2 es usado solo por el 2% (!) de las organizaciones. Los resultados de la pregunta asociada a la madurez organizacional en torno a proyectos, programas y portafolios tampoco son alentadores. Otro resultado altamente contrastante es la respuesta a la pregunta “”Qué tan exitosa calificaría a su organización desarrollando lsa siguientes actividades sobre los siguientes tres años – formulación de una estrategia adecuada para las condiciones cambiantes del mercado?” Los ejecutivos calificaron como “Excelente” en el 43% de los casos y “Bueno” en un 50%, mientras que los líderes de PMOs indicaron un 13% yu un 46% en esas categorías de respuesta… Hmmm… me pregunto cuáles serían las respuestas en el caso de preguntarle esto a los Program y Project Managers. La distribución de respuestas también contrasta a la hora de preguntar por la priorización de los proyectos: aparentemente los Ejecutivos creen estar haciendo un excelente trabajo… pero el resto de la organización no coincide con esta apreciación. Tengo algún otros puntos, pero para efectos de mantener este artículo de un tamaño “digerible”, voy a dejar mi argumentación hasta aquí: el “fiscal” descansa.
Sostengo entonces que esta pandemia está asociada a problemas de carácter estratégico, como lo son la visión, misión y objetivos organizacionales, y el alineamiento de los portafolios, programas y proyectos con los mismos. Finalmente, sostengo que este problema de alineamiento se deriva a su vez de un modelo de gestión de la gobernanza obsoleto, que como la teoría económica de hace solo unos 30-40 años, se erige sobre una serie de supuestos erróneos que desconocen la curiosa naturaleza del ser humano.
En el siguiente artículo de esta serie, vamos a explorar cuáles son esos supuestos que corrompen la toma de decisiones y ahondaremos en los problemas del modelo “usual” de gobernanza en las organizaciones, modelo que está “diseñado para fallar” y termina haciéndolo “brillantemente” de mil y una formas: aprobando el lanzamiento de proyectos que no deberían aprobarse, sobrecargando el “pipeline” con más trabajo de lo que los equipos organizacionales pueden gestionar, apurando de manera desmedida esfuerzos, etc. etc.
¿Curioso? Eso espero – le espero en el siguiente post…
Material complementario / fuentes:
- Informe “Pulse of the Profession 2018” por el PMI, haz click aquí
- Definición de riesgo del PMI: “El riesgo de un proyecto es un evento o condición incierta que, de producirse tiene un efecto positivo o negativo en uno o más objetivos del proyecto, tales como el alcance, el cronograma, el costo y la calidad”
- “El pensador”, la estatua mostrada al principio, haz click aquí
ENGLISH VERSION
“Ignorance, the root and stem of all evil” – Plato
In the prior article of this series (guess that post´s title…) we said that the root cause behind the failure of so many projects (in my humble opinion, of the majority) is the organization itself: the company or entity. Moreover, we said that the organizational processes are the ones to be blamed: processes that are faulty designed, faulty implemented, or faulty operated (or a mix of those faults). We got as such a suspect: the org system, and we characterized the suspect under the ORGANIZATIONAL GOVERNANCE tag. As such, I state that the failure of the majority of the projects is a cause not hidden within the project itself, but in the environment around it. Before I suggest some ideas in order to tackle this “universal enemy” of Project Management, let me justify why I state that this is the real enemy. I mean, to this point, this is basically an opinion, but I have not provided arguments nor evidence to back it up: let´s proceed with those right away.
Data comes first… There is “gold” hidden in the last Project Management Institute (PMI) “Pulse of the Profession” report v. 2018. Let´s jump to page 25, where this question is raised: “Of the projects started in your organization in the past 12 months that were deemed failures, what were the primary causes of those failures? (Select up to 3).” Then the stock of answers is provided. Below the top 7:
- Change in organization’s priorities 39%
- Change in project objectives 37%
- Inaccurate requirements gathering 35%
- Inadequate vision or goal for the project 29%
- Inadequate/poor communication 29%
- Opportunities and risks were not defined 29%
- Poor change management 28%
Let´s try to figure a lowest common denominator to this list. It is a challenge because at first glance, the reasons seem to be rather arbitrary. But when we take a closer look, we notice that the word “Change” is mentioned in three of those. Another two mention an inadequate goal and inaccurate requirements (in other words, a project vision not aligned to the organizational strategy or goals – changes and changes are required to adapt along the way). Failed risk management is also there (notice that the PMI itself is doing a corrupt use of the term risk in this report, since it it uses it as a synonym of threat instead of the official definition associated to uncertainty – see official definition below). The other factor is linked to communication. I assert that the lowest common denominator (or its best approximation, if you will) is associated to the organization: its a pandemic fault, not a “local disease”.
Let me continute: the three reasons that Mr. Mark A. Langley (Presidente & CEO, PMI) mentions as the rationale behind the fact that 10% of the global project budget is literally wasted are (PMI´s “Pulse of the Profession” report 2018, page 2):
- Organizations fail to bridge the gap between strategy design and delivery.
- Executives don’t recognize that strategy is delivered through projects.
- The essential importance of project management as the driver of an organization’s strategy isn’t fully realized
The interesting thing here is that the PMI (certainly not in this report and to my current knowledge, nowhere else) ever asks WHY do these things happen. Again, I avow that this happens due to deficient organizational GOVERNANCE: in an analogy, like a person that wants to cut weight but cannot stick to the diet, the organization lacks the “self-control” to eat in a healthy and nutritive way (it lacks the ability to implement the defined strategy and select the right projects, we will talk as of the why soon). Continuing with the analogy, the organization also neglects the importance of those nutritive meals and of exercise which are the driver to the right weight (meaning, the importance of enforcing healthy Project Management).
And I have even more reasons to support my point: according to the same Pulse of the Profession report v.2018, just 37% of non-enterprise-wide PMOs are highly aligned to the org stratetgy. In other words, 63% are not. In the case of enterprise-wide PMOs (EPMOs) the result is frankly not much better: only 41% are. To my understanding, this is a big issue: if going down just one step of the org ladder (C-Suite to an EPMO level) generates strategical misalignment in 60% of the cases, what can we expect when we go down to the project, requisites and deliverables level? To make things worse, the same report states that Portfolio Management is steered just by 48% of the EPMOs and that powerful normative and structuring frameworks such as PRINCE2 is used just by 2% (wow!) of the organizations. The results that measure maturity level aren´t also heartening.
Yet another enlightening point is the answer to the question “How would you rate your organization’s success in performing the following activities over the last three years? – Formulating strategy appropriate for changing market conditions?” Execs went for “Excellent” in 43% of the times and “Good” in a 50%, whereas PMO-leads stated 13% and 46% for those categories (Excellent and Good) Hmmm… I wonder which would be the percentages if those questions were raised to PgMgrs and PMs. The contrast between Execs and PMO-leads perception is also apparent when asking about the quality of the project prioritization efforts: it seems Execs are quite positive about their work but the rest of the org is not very fond of it. I have even more arguments and evidence to support my case against organizational governance, but for the sake of brevity, I´ll leave it here: the prosecutor rests.
CONCLUSION: I affirm that the core cause is associated to strategic issues and its steering through the org: misalignment of the portfolios, programs and projects to the org strategy. And I finally assert that these alignment problems are due to an outdated governance model across our organizations that, like the economic theory that ruled just about 30 or 40 years ago, relies on a series of faulty assumptions associated to the way we human beings live, take decisions, enact and act.
In the next post of this series we will examine which are those assumptions and biases that corrupt the strategic and decision-making processes and we will deep-dive in the problems associated to the “standard” organizational governance model, which is “designed to fail”: and indeed it fails brilliantly, overloading the pipelines, approving for launch or for next-phase a load of “mutant” endeavors, smashing timelines, etc. etc. And we will also suggest some ways to tackle the problem – or at least reduce its intensity.
Curious? I hope so: see you in the next post of this series…
BONUS MATERIAL:
Reflexiones de un PM en un mal día (parte I) / The deliberations of a PM on a bad day (part I)
VERSIÓN EN ESPAÑOL (ENGLISH VERSION BELOW)
“Los cántaros, cuanto más vacíos, más ruido hacen.” – Alfonso X el Sabio
Serrat canta “Hoy puede ser un gran día”… pero ciertamente hay días que no son así. Como Gerente de Proyectos (Project Manager – PM) estos días aciagos se presentan más seguido de lo que quisiéramos. Recuerdo uno de esos días sucedido recientemente. Con la cabeza fría, puedo identificar (al menos) los siguientes factores como parte de la receta del desastre:
- Un Portfolio Manager con una visión sesgada de los proyectos y programas bajo su cargo: diríamos que el caballero en cuestión vivía su puesto mirando siempre “hacia arriba”, hacia la Alta Dirección y el “C-Suite”, y nunca hacia el portafolio, salvo para dar direcciones.
- Un Program Manager del área en que me desempeñaba (a la cual reportaba directamente) con un estilo gerencial absurdo. Su mantra era “quédese en su caja”: una manera muy directa y poco poética de enarbolar la bandera de los “silos” o “compartimentos estancos” organizacionales. Además de ello, una limitada capacidad de escucha. y el sistema de escalación era disfuncional.
- Ausencia de un Project Charter o SOW confiable: me encontraba luchando en el proyecto desde hacía casi 6 meses y aún no existía un documento que oficializara su alcance, objetivos, presupuesto y otros “detalles”.
- Ambiente generalizado de premura y urgencia: deadline inamovible y, por decir lo menos, poco realista. Todo es “para ayer”.
- Alcance (scope) “saltarín”: la cantidad de elementos a desarollar en el proyecto cambiaba a un ritmo insólito, inclusive semana a semana – el término “scope creep” se quedaba muy corto.
- Juego de la “papa caliente” con la responsabilidad: más que un esfuerzo conjunto entre los diferentes equipos desarrollando los diferentes proyectos y programas del portafolio para entregar a tiempo la masiva cantidad de productos (entregables), el tema recurrente en el día a día era un juego político en donde lo más importante era que la culpa no recayera “en mí”: un juego de búsqueda de culpables y evasión de responsabilidades, amén de falta recurrente de coordinación y por supuesto de visión y trabajo en equipo.
- Mal ambiente laboral, epidemia del síndrome de “burnout”, faltante crónico de staff, alta rotación, etc.
Coincidará conmigo en que esta es la “tormenta perfecta”: una acumulación de factores que solo puede devenir en un proyecto / programa / portafolio fallido – independientemente del presupuesto, el cual, como adivinarán, era limitado y controlado con “marca personal”. Con el paso del tiempo, reflexioné: ¿Existirá un factor común que es el verdadero causante de todos estos (en algunos casos aparentemente inconexos) problemas? ¿Hay una causa raíz “maestra” subyacente a todo este desastre, un mínimo común denominador? Y, para rematar: ¿Es esto culpa del PM o de alguien más, y quién es ese “alguien más”? Unas cuantas lecturas, incluyendo breves repasos del PMBOK, el “Rita”, PMI´s “Pulse of the Profession”, algunas conferencias y artículos varios de estrategia y gerencia pero sobre todo un análisis concienzudo me llevaron a una conclusión general: efectivamente, hay una causa raíz detrás de todo esto: la organización como tal. Puede sonar en primera instancia como una perogullada, pero analicemóslo un momento: el problema no es el PM, tampoco el PgM y tampoco el PfM. Así que no hay que “echarse encima el muerto” en la conciencia. El problema es el SISTEMA: cuando en una organización la norma es el desorden, la sobrecarga laboral, la corrupción de prioridades, sobrecarga del pipeline de proyectos, etc. etc. entonces no es alguien, son los procesos globales de la organización los que están mal diseñados, mal implementados o mal ejecutados (o estos tres problemas a un tiempo). Y esto a su vez puede traducirse en una palabra: mala (o ausente) gobernanza: léase gobierno corporativo, pasando por elementos tácticos y cuasi-operativos.
Tenemos entonces un diagnóstico: un sospechoso, el supuesto “villano de la película”. Pero… ¿Cómo podemos estar seguros de que este es ciertamente el culpable y qué hacer ante esta triste realidad? Ánimo, hay esperanza: dejaremos esas reflexiones para las siguientes partes de este análisis, nos vemos en los próximos posts…
“Un hombre con una idea nueva es un loco hasta que la idea triunfa.” – Mark Twain
ENGLISH VERSION
“The empty vessel makes the loudest sound.” – William Shakespeare
Cat Stevens sings “Morning Has Broken” in an all-positive mood, but sometimes… oh gosh it isn´t a good day. As PMs, those bad times come more often than what we would linger for. I remember one of those days. With a cushion of months in between and a fresh and more objective perspective, now I can identify (at least) the following list of factors behind the “Perfect Storm” scenario hailing over that particular project:
- A Portfolio Manager with a biased, unbalanced perspective of the programs and projects under his accountability: this person was leading with the eyes always pointing at the Executives, Sponsors and the C-Suite, with virtually no time nor attention for the team under his command.
- A Program Manager directing the area in which I was working (I reported directly to that person) with an absurd management style: that person´s Project Management mantra, preached to all the team, was “stay-in-your-box” – do not ask about other areas and projects, do not request info on the general effort status, shut up and look down. Of course, this translates into the official empowerment of organizational silos, not to mention a very limited capacity to listen.
- No Project Charter or SOW available: we were six months already into the effort, and there was no official charter nor Statement of Work… requisites were managed in a pretty muchinformal way and in any case, there was no definitive document stating the project objectives, terms and conditions.
- An universal environment of urgency: if anyone received a task or an instruction, the rationale was always urgency, “it is late”.
- Project and Program scope capable of competing in the “Calaveras County Jumping Frog Jubilee” (remember Mark Twain´s short story? Check the link below): the scope changed week by week. The list of applications in our scope mutated sometimes even twice per week.
- Responsibility was managed like the a hot potato game: as such, the spirit was not to work as a team and actually solve issues, but to toss the blame on someone else, fast, before it hurts you. As such, the Project Team behaved in a political and evasive way, creating lack of trust and unnecessary antagonisms.
- Staff issues: we were always short on staff, people were demotivated and “burned-out”, the project suffered due to high staff turnover and attrition.
Of course, the sum of these factors create a nearly impossible scenario, regardless the budget allocated for the effort (which, of course, was limited and strictly controlled). This set of conditions steer the project / program / portfolio towards failure. As stated above, with the perspective of time and distance, I have meditated: is there a common factor, a root-cause, a minimum common denominator behind all the above listed issues? Moreover, if that is the case, what is that “sum of all fears” thing, and is the PM to be blamed? A series of lectures, including the new PMBOK v6, Rita Mulcahy´s famous training book, PMI´s latest “Pulse of the Profession” report, a couple conferences and other technical articles but mainly a lot of internal deliberation have led me to a sound conclusion: YES, there is a common cause, and it is the organization itself, the company. This may sound initially as a “duh” statement, but before you bully me, let me present the nuts and bolts to extract the real value out of it. First of all, we need to be clear that the PM (nor anyone in the project, nor the PgM of the PfM or even the Sponsor) is to be ultimately blamed. This is not a small thing: so first and foremost, don´t feel personal frustration or take the blame. The root cause lies in the SYSTEM behind the projects: its not the actors, its not the play, its the stage and the theatrical company (Shakespeare would be proud of the analogy I guess). When disorder, lack of priorities, lack of staff, work overload, high attrition, pipeline “cholesterol” and overload are the norm, then something is utterly wrong at a general level. This means that the blame is not to be put on someone – and especially not you as the PM (perhaps C-Suite, but let´s avoid the blaming exercise for the time being) but on the organizational PROCESSES, which may be faulty designed, faulty implemented or faulty executed (or a combination of those). In a nutshell, all this mess can be translated into a single evil: tainted, degraded organizational GOVERNANCE.
So, we have come to a conclusion and we now have a SUSPECT. Still, how can we be sure that this is indeed the despicable villain behind all this mess and how to tackle this inconvenient reality? We will deal with these questions in the coming posts. Stay tuned…
“A person with a new idea is a crank until the idea succeeds.” – Mark Twain
Bonus material:
- Mark Twain´s short story – “The Celebrated Jumping Frog of Calaveras County“
- PMI´s “Pulse of the Profession” report 2017: click here
- PMI´s “Pulse of the Profession” report 2018: click here
- Alfonso X of Castile: click here – he is the author of the top quote in the Spanish version of the article: “Pitchers, the emptier they are, the louder they sound”
