PPP: Politics, Projects, and Pitfalls
Allow me to start with a metaphor: it utterly amazes me how little is mentioned in PM trainings & courses about the political storm in which projects (nearly) always sail across the vast and unknown business oceans. Our navigation charts are flawed. (Alas, how poetic! Careful Lord Tennyson, I´m coming for you… LOL). I mean, the focus of the preparation material for a certification – including textbooks, bodies of knowledge, frameworks, professional summits, etc. – most typically hinge around theoretical & technical aspects of the profession. Business politics, in the sense of power dynamics, concealed interests, diplomacy and related are seldom discussed. Let us talk about it.
In my experience, rookie PMs tend to ignore altogether the circumstances that surround the project and assume that everyone is driving against the project charter and its objectives. The premise is that the project operates in a vacuum. Moreover, if there actually some level of situational awareness it tends to focus on external circumstances only and not so much about the internal organizational dynamics. The problem is that, in real life, we know that is not the case. Therefore, and quoting R. Feynman, “The first principle is not to fool yourself – and you are the easiest person to fool”. We end self-tripping in a cycle of masochistic addiction to a partial, fallacy-driven perspective. Let me explain: human beings love to over-simplify and assume without facts nor data, and even worse, stick to conclusions despite new evidence and arguments proving us wrong. One of the biggest traps is to assume that all the project stakeholders are neatly chasing single common goals as stated in the project manifesto. Many times, this is not the case. Professional jealousy, concealed interests, personal agendas, different sets of priorities, conflicting personalities and cultural differences – particularly at high levels of the organization – may put the project at stakes. I´ll give you an example: say there is a big Program, and two major departments are driving two components to it: Department A drives Project 1, Department B drives Project 2. The Projects are intertwined with each other. Now, if Department B is not making as much progress as expected, it may be of its best interest to slow down Department´s A pace so they (Department B) don’t appear as the sole culprit to Executive Leads. The logic is perverse but worth the shot: the Program delay´s blame will be shared, and if things get rough there is at least the possibility of a finger pointing exercise to dilute the mess. Another example: the Directors of Area X and Area Y have a history of recurrent friction. Not only their personalities don’t mix but they are continuously dragged into F2F conflicts as per their specific roles within the corporation. When an issue arises within the project and it escalates to this level, a political game – and an egos match – triggers. Results are predictable. A third hypothetical yet not very uncommon scenario Business Division Z is facing issues spending the annual R&D budget. They began (as usual) late with their key endeavors, and they will lose the funding for secondary and tertiary priorities if not at least triggered during this year. Therefore, Business Leads for Division Z artificially elevate the priority of their projects, interfering with resource allocation and general Portfolio Management for the entire organization. The result is a management crisis in which well-stewarded & higher priority Projects are derailed when their internal team members are “hijacked” and assigned to less important ones through a political stratagem. The fact that PMs nowadays operate nearly all the time in matrix organizations make the situation even more convoluted for them. Begging for team members time becomes the norm.
“POLITICS, n. A strife of interests masquerading as a contest of principles. The conduit of public affairs for private advantage.”
Ambrose Pierce
Those are solely three examples, but I think that by now my point is clear. It is a big mistake to assume that a group of people under a single title – call it Enterprise, Department, Geography, Business Line, Hierarchical Level, Project, etc. act as a monolithic, single-minded unit. There are always internal frictions, concealed purposes, and different perspectives. I strongly believe that senior PMs should raise the awareness of newer ranks about these facts as per the subtleties of each organization, and perhaps even more importantly, training courses and materials should have a chapter devoted to plant these concepts in the mind of new PMs, Admins, and similar roles. I have concluded this is an omission in most syllabuses. Time devoted to the topic would be eye-opener to the world of work in general & to the PM practice in particular to aspiring professionals. Betting it all on the future and gradual construction of experience is naïve and puts the entire burden on the apprentice, making the learning curve longer, steeper and painful; not to mention that increases the chance of project failure along the path. Newcomers deserve at least a word of caution about corporate politics and the subtle Game of Thrones occurring in many places, don’t they?
I rest my case now. Do you concur with me? Let me hear your thoughts.
Fernando
Photo by Kristina Flour on Unsplash
The project is (S/M/L/XL/XXL/XXXL). So WHAT?
Every PM suffers now and then a slight attack of anxiety when notified about the assignment of a new project. It´s just natural: he/she will have a close relationship with this “entity” for weeks, months or years, and he/she knows nothing about it. Thus, he/she jumps to the Business Case, Charter, Launch Gate document or any other available source to understand what the effort is about. Again, all good here. The part that puzzles me is how little organizations prepare to deal with the project. Let me cut to the chase: most organizations limit to a generic characterization of the effort, mainly by size; sometimes also by complexity. In a few cases there are further categorizations as per the scope, geo, nature of the effort. But the consequences of this analysis are quite limited, if any.
In my experience, for most organizations, most of the time, the sole actual result to the initial analysis (categorization) of the projects limits to allotting a predefined range of hours to the effort, in rare cases a budget. The best I´ve seen is an actual prioritization, which is not a bad thing at all, but these are scarce cases and the impact is constrained. This limited output makes me wonder if the initial set of parameters with which projects are analyzed is insufficient. Or perhaps the actual process to act upon those results is utterly flawed, if not entirely absent. Candidly, I think it’s a mix of both, but I also think that the biggest proportion of the issue relies on the latter.
I think that we need to take this topic more seriously in our organizations. It doesn’t make sense to waste time on the analysis of our projects to do it incorrectly and then to basically ignore it: this is a Portfolio Management “chronic disease”, if I may be allowed to use the analogy. I am not certain about the cure to this problem, still, I have already a couple prompt points. Let me say that a broader range of parameters to select upon (size, complexity, risk, urgency, stakeholders’ profiles, expected duration, budget) would help a lot. Then perhaps an algorithm, a formula could be used to produce a conclusion, an actual project comprehensive characterization as per the values of each one of the numbers. Finally – and more importantly – there must be a process to act upon it: there must be consequences. For example, if the project is urgent and risky, assign this type of PM, if the project is long and complex, request for a bigger management budgetary reserve. If these stakeholders are engaged, it is mandatory to inform them every two days of the status. You get the idea: the characterization of the project through pre-defined parameters derives into actual actions, guidelines, rules, strategies. I also think that using Lessons Learned and a Focus Group with the most experienced PMs would greatly benefit the creation of the mentioned algorithm (formula). I also foresee interesting opportunities for PMOs to this analytical, semiautomatic approach.
Imagine that: you would be receiving your projects with guidance, structure and “warnings”: now that would be a sight, isn´t it? Of course, these “automated” guidelines would have to be tuned & tweaked as per the project subtleties by the PM and his Team, but nothing like actually receiving insight from the shared pool of experience and knowledge of the organization – as a standard input right from the beginning. Not only that, the organization would be nudging projects toward success: better staffing, resource allocation, wisdom injection right from the launch. COOL, isn’t it?
And now… what do you think? Do you know any examples of this idea? How would you improve it? Let us hear your thoughts.
Best regards,
Fernando
Divide and Conquer: A different PM per phase?
Introduction
In a prior article I publicly confessed my affaire with the Rolling-Wave project management methodology (you can take a deep-dive into my romance right here). In short, I find this framework realistic and pragmatic; a “stoic” management philosophy pivoting around a focus-on-what-you-can-control strategy. Expanding from this paper, my mind kept wondering about ways to improve how organizations – particularly big ones – can improve projects´ efficiency and governance. The exercise proved fruitful, here is an idea that has been enticing me lately. It may be contended as counterintuitive and perhaps even as controversial and naïve. Despite the plausible opposition, it´s an exercise in out-of-the-box rational and a challenge to canons and conventions. I hold that those are sufficient-enough reasons to share it: new ideas, asking and challenging are only different faces to that sometimes elusive, ethereal conquest called thinking.
Divisions and Phases
Let me start the journey with a disclaimer: this proposal applies exclusively to waterfall and rolling-wave approaches and perhaps even solely the former. These methodologies “cut” projects in logical parts, namely phases. In the case of waterfall approaches, the PMI states that those are Initiating, Planning, Executing, Monitoring & Controlling (which runs along the entire duration of the effort) and Closing. Variations of this theory exist, of course, eg: SDLC´s Requirements Gathering, Designing, Coding, Testing, Maintenance. A third example is PRINCE2, which goes by Starting up a project, Directing a project, Initiating a project, Controlling a project, Managing product delivery, Managing stage boundaries, Closing a project. You name it, there´s “more than one way to skin a cat”: at the end it is all about dividing the endeavor into more manageable and cohesive chunks that accomplish for governance and reporting purposes. Still, to my understanding, there is a common denominator, a big underlying assumption across them all: a single PM runs the effort across its entire timeline. I want to discuss this assumption now.
A monster prone to mutation
Bottomline, my argument is simple. We divide projects in phases because it makes sense to do so. Its ultimately an application of the “Divide & Conquer” adage. The created pieces have a natural affinity among its components derived from the maturity of the effort at each stage: a project is kind of a monster that utterly mutates along its life. If that is the case, shouldn’t large organizations have their PMs (and perhaps other roles) also specialized & be assigned according to the project phases? There would be an Initiation PM, a Planning PM, an Execution PM, a Closure PM and a M&C PM (or committee) – or similar figures according to the way the project was “cut”. I suppose (quite frankly, I have not heard of any organizations doing this) that this would have remarkable pros: specialization expedites learning and mastership of specific roles and tasks. Let me put it into other terms: we all know that there is a cognitive toll to be paid when we jump from project to project, from task to task. I am advocating here for sort of a Taylorism applied to the project’s world. An even deeper specialization should increase efficiency and efficacy. A baton race to large organizational endeavors is born, with runners specialized in each part of the track.
“Defeat them in detail: the Divide and Conquer Strategy. Look at the parts and determine how to control the individual parts, create dissension and leverage it”
Robert Greene
There is no such thing as a free lunch
I know, you know, we know – there are cons to this idea. First-off, so much for comprehensive Project Integration work. The very nature of the approach changes this to a per-phase range. Line of sight may also decrease, and specialization creates specialists: individuals who superbly perform in a very specific area – and that´s it. Also, durations of phases are varied, with a powerful tendency to overextend during the Execution phase (padding, Parkinson´s Law, Peter´s principle, bad multitasking, resources stretched too thin, etc.) and to a minor degree, Closure (90% Syndrome, Student Syndrome, etc.) or to fail during earlier phases (Lakein Principle, Fitzgerald´s Law, Constantine´s Law and other). That said, we can counter these problems with some subordinate ideas. For example, the PM pool of resources could be rotated from phase to phase to avoid burnout and keep knowledge afresh. The number of resources allocated per phase should be balanced to the average duration of the phases. PMOs could lead internal bootcamps to transfer knowledge, lessons learned and feedback from phase to phase. Also, an overarching Monitoring & Controlling organization could serve as a cross-phase steward.
There is one more argument against this idea: the divided accountability of the project as a whole, associated to several PMs leading it. Moreover, hand-offs across phases can be messy. I believe this is actually its major forte. It may be counterintuitive, still, if a solid inter-phase procedure is established, the very fact that a new person receives the outputs of the phase creates an implicit audit to the quality of those products. I mean, if you are going to lead the Execution Phase, it is for of your best interest to thoroughly examine the Plan. This could have the additional benefit of solving the “relaxed” approach to mid-project Gates and Phases (in my experience, Launch and Close checks are much more solid). Furthermore, even demi-gates could be established for the biggest projects, so to ensure that partial checks are enabled before actual hand-off attempts. It’s a matter of creativity and will – a baton-race implies that you run your part of the track well, and perhaps even more importantly, that you hand-off the baton perfectly. On the lack-of-integral-accountability point aforementioned, I believe it can be solved by transferring it to the SteerCo or to the Sponsor: why not? A project is a temporary organization and a shared effort, isn´t it? Why not transferring the overarching accountability to the overarching figures?
Conclusion
In conclusion, I think that organizations could benefit from a further level of specialization for their projects. Project “Launchers”, “Closers”, “Planners”, “Boundary Masters”, “SWAT Teams” and similar figures could derive into increased efficiency and efficacy: staff mindset would be affixed to a particular maturity status of the efforts. Templates would become more and more familiar. Processes would become more routinary. True experts to their field and role. I think this could be a good thing for large organizations undergoing performance issues with their Portfolios.
All this said, this is still a mental exercise, sort of a hypothesis in search of experimentation, testing and evidence. Thus, do you know any organizations that work like this? Do you have your own opinions or ideas as of how to run projects? I would love to hear your voice.
All the best – saludos cordiales!
Fernando
Not Agile, not Waterfall, not Hybrid: my FAVORITE approach is…
I recently was asked a question that put me to ponder for a good while. This person reached out to me and asked “Hey, do you have a favorite Project Management methodology?” Nowadays, the en-vogue (oh la là), default answer would be to reply “Agile” in any – or all – of its different tastes. Still, for me, this is not the case. As efficient and trendy as Agile methodologies are, they come with cons. Our human nature drives us more toward entropy – a fancy way to say that we make are biased towards making a mess of it all – rather than organization & order and Agile could become a vehicle for havoc. The ulterior development of Disciplined Agile and similar variations are an admission to this point. Agile is not for every org nor every character. Furthermore, Agile is not the best approach for certain type of projects (the more “physical” the effort, the least space for maneuver & flexibility). Finally, I still have my reservations about beginning a project without a charter and a mature scope (we will talk more about this on a separate post).
A more academic, “can´t fail” answer to the question would be “my favorite is the one that applies to each project, as it is deemed appropriate”. I am not fond of this smarty sort of a riposte. As valid as it is, it´s more of a generic statement that sidetracks the conversation. It diverts the point from an actual exercise of selection & preference to a “rather don´t say” creative option. In more mundane terms, kind of a “beauty pageant” answer, if you know what I mean.
This takes us into the territory of actual methodologies. As shared upfront, Agile is not my preferred one. So, what about the “ancient” and mature Waterfall approach? Well, as we know, there are issues with it. Waterfall´s fortes are simultaneously its weaknesses: it requires lots of upfront planning. Also, and to put it in economic terms, it assumes a “ceteris-paribus” context to the effort (else, planning would be futile). Finally, it makes changes and adaptation cumbersome, expensive and slow (the more mature the project, the more valid this is). Alas! Then, what about a Hybrid method? It´s It’s another “nope” for me. We are still learning how to satisfactorily mix Waterfall and Agile approaches. Also, bringing these two approaches brings the good of both… and the worst of both.
By now I hope you are wondering what is left to be chosen: I can be picky, I admit it. So, drum-roll, please… After some reflection, my current favorite Project Management methodology is the… Rolling-Wave approach! (Applause, please). Why? Well, because from my perspective, it brings the benefits of a long-term aim of control (Waterfall) but the adaptability features of an Agile approach. This approach runs on a divide-and-conquer basis, severing the endeavor into logical, manageable chunks and focusing planning & control into the “next” one. Its like aiming to cross a vast jungle: you know the particular compass direction to follow, but you plan your path according to what the line-of-sight offers you. It´s worthy to mention that a decent level of phase/chunk overlap is also compatible with this approach. To me, this approach offers a healthy compromise between scope driven and time driven methods. I like it – I like it a lot.
So there you go, the Rolling-Wave method is my favorite PM approach. Of course, this is my personal palate: individual, subjective and particular: there´s no accounting for taste. I would love to hear your own opinion.
Regards,
Fernando
TOP 10 Analogies to Project Management
Analogies are one of the cleverest tools to explain and communicate. Analogies transfer knowledge from realm to realm, clarifying the alien & vague through the lens of familiarity & acquaintance. A good analogy is like a “written picture”: worth a thousand additional words. As you can tell from the prior lines, I am a big fan of analogies, metaphors, allegories, and similar idiomatic formulas. Let´s use the tool on a favorite subject of mine which is Project Management. Let´s begin with the worst and run the list top down up to my personal favorites. With no further introductions, I give you the Top 10 Analogies to Project Management, as follows:
10. Stenographer: on the bottom of the list, the comparison of a PM to a stenographer (amanuensis). It is quite a misguided correspondence since stenography accounts only for literal transcription with no value added. In other words, it assumes a laid-back mechanization to Project Management which is the case. Furthermore, modern software platforms already do this automatically. In this sense, this analogy is more of a defamation than a fair comparison – we put it at the list´s basement, thus.
9. Executive Assistant / Tracker: in this second analogy the passive automation is less evident than the previous one, therefore I like it a bit more. Still, it doesn’t transmit the drive that the role demands. Project Management does imply massive tracking efforts (e.g., holding people accountable to deliveries / ETAs, etc.) but there´s much more to it. A PM must proactively make decisions, call to action, drive, plan. This figure does not conveys that fundamental part of the role clearly.
8. Military “Commander”: now on number 8 of the scale the military ranking analogies. The pros to this category of allegories is the fact that they depict discipline, decision-taking and risk management. However, cons are as varied as they are important. Project Management is not actually about fighting an “enemy” nor it supposes the authority degree and top-down command line that military forces proudly exert. Project Management also entails much more of negotiation skills and compromise, among other soft skills.
7. Expeditor: what I like about this one is the fact that emphasizes on the Schedule (formerly Time) Management area of Project Management. In my experience – and as per our modern world needs & trends – time is indeed the key restriction / driver against which projects are mostly driven. In other words, its the ultimate restriction. The downside is that once again, it leaves outside so much there is to the job. The Expeditor metaphor makes it to this position in the ranking, no more.
6. Coordinator: in the very middle of the list, the “Coordinator” term as a reference to a PM. It’s a fair one, I must admit, since it conveys the organizational aspects to the profession, including the need of dealing with multiple stakeholders with different needs and expectations. However, in my opinion the term has a bias to be acknowledged under the hood of the Execution phase of projects, which of course leaves out the Planning part of it – the secret sauce to successful projects.
5. Coach or QB: now on the second half of the list, beginning with the sports-world comparisons. The Coach analogy is nice – it conveys motivation, strategy, decisions, risk management. Quarterbacks are also a nice one – the role is a synonym to leadership, last-minute calls, working against the odds. The flipside to it is similar to the military figure comparisons – it transmits an “us against them” context that is not realistic.
4. Air Traffic Controller / Tower: what I really like about this one is the way it depicts in a very graphic way the Integration part to project management. Departures and arrivals are akin to deliverables and work packages, and the Tower synchronizes everything to perfection, optimizing the total output of the Team. Now to the cons of this one is the fact that air traffic is more like a continuous process that a project (there is no end to it) and the products (deliverables) are basically the same. Thus, the parable is good but indeed not perfect.
3. Router: we are now on the top three! First on the final countdown, the router. A router is a very “smart” piece of equipment. It is network gear that not only forwards information, but it also distributes it to the correct parties through the best path and in the correct format (protocol). It also must manage security aspects to it, timing, and errors. I very much like all that, but then the nature of the object per se – a router is a device – somewhat transmits a robotic picture to the profession that stalls this allegory in its current 3rd spot.
2. Orchestra Director: the Orchestra Director is a lovely way to picture a PM. It denotes the art to it, the subtle adjustments to be made during the Execution (and sometimes, not so subtle ones!) and the trust there should be between the Team. But then, to me, there is again bias in this figure toward the actual interpretation of the melody, that would be, toward the Execution phase of the project. That´s why it didn’t make it to the summit.
1. English to English Translator: I heard this one recently from a dear colleague of mine and it escalated immediately to the very top of my list. In an almost “poetical” way this analogy denotes the essence of Project Management. It succinctly captures the spirit of the profession: reading “between the lines”, chasing the true priorities, requesting clarification time after time, ensuring that actual communication happened (and not the illusion of it, as G. Bernard Shaw warned us). An outstanding allegory by all means – vague, you may argue, but it applies all across the timeline of projects, methodologies and frameworks. One analogy to rule them all!
This is my list, ranked from worst to best. Thinking aloud, perhaps the ultimate analogy would be a mix of some of the above. Perhaps. But then, this is just me – what is your favorite analogy? Did I miss any interesting ones? Share your comments please – feedback is the breeze that refreshes the mind, if yet one more metaphor is allowed in this post.
Cheers,
Fernando
PS: after writing this article, I recalled even other ones, such as a Juggler, managing many different priorities simultaneously, and even “herders”. Thoughts? Shoot!
Photo by Nick Fewings 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
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:
