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
Decisions, Procedures & HIPPOs
If there´s a moment in the organizational day-by-day that majestically embodies the term “Governance” that is the moment of making an important joint decision. What amazes me day in, day out is the absence of an “architected” approach to those moments of truth. In my experience, regardless the size of the organization, its industry and maturity level decisions are quite generally taken using a “primitive” procedure that exists just due to momentum and lack of critical thinking. In the coming lines I intend to raise this situation to the reader´s awareness and provide some food for thought for you all.
Let´s start with an example. July, CIO, is presiding the monthly IT Security SteerCo for ABC Enterprises. As per the recent increase of cybersecurity attacks, the committee must make a decision. They need to increase their IT security level. Thus, they need to choose between several IT Security suites and providers. The meeting begins somewhat late and there are solely 30min booked. To make things worse, conversation digresses and when the topic comes up, July takes command of the call and states her preference. Tommy, CSO, has concerns about the suggested solution, particularly with the 3rd party implementer. Mark, IT Ops Director, too, but more from the solution itself perspective. He has heard negative feedback from peers in other organizations. Luke, CTO, has no particular position. Ditto for Emiley, PMO Lead. The clock relentlessly spins its arms and after some discussions, the “Five minutes left in meeting” alarm pops-up in everyone screens. July takes again command of the meeting and states: “Okay, let´s get to a decision – every day that passes we are at risk, we must not postpone this anymore. I also have to jump to another call. I vote for the mentioned software, and I can have our friends from SuperDeploy next week on-site to define the implementation approach in order to get a formal proposal. So what is your final take, Tommy?” Tommy feels the pressure, he´s put on the spot. So he concedes. Mark makes a couple final rebukes but alas, “if July and Tommy agree, well, me too. So, yes”. The rest of the team robotically say “yes” and that´s it. The team adjourns the phone bridge. And we all say, “Geez, so, what just happened here?”
If you were paying attention, I guess you came to the conclusion that the aforementioned meeting was engineered to fail. Or more precisely, it lacked engineering. It was an ad-hoc, impromptu improvisation with no script, no guide, no agenda and no method, particularly for the moment of truth (the voting exercise). This is my core point: smart, logical, fact-based decisions are not taken like this. The scenario was perhaps exaggerated (lack of punctuality, lack of focus, short timeframe, etc.) but I think that we all have seen stuff like this in our careers. The voting exercise is the summit and culmination of it all. Once July makes her preference utterly clear and public (and that is the Highest Paid Personal Position or HIPPO) there is nothing left to be said. Her CIO role and commanding style pushes the rest of the attendees toward her preference. And the decision is taken.
A wise man makes his own decisions. An ignorant man follows public opinion
Chinese Proverb
So what´s to be done? I don´t have a one-size-fits-all answer, but First thing is to be aware of this issue which seems to affect us like a chronic disease to which we have become anesthetized. Secondly, I believe that this is the type of meeting (and particularly in a WFH / Remote culture) is the one that demands a more strict business approach: punctuality, pre-defined agenda, pre-defined time-slots, pre-defined priorities, pre-defined roles (eg, note-taker, chairman, etc.). And Third, I say that voting must not be taken lightly. The HIPPO(s) must be left at the end, for obvious reasons. If possible, the possibility of simultaneous voting tools should be considered, and perhaps in some cases, even private voting. Disclaimers should be warranted. Even second debates for final endorsement, maybe, in business critical matters. It´s a matter of creativity and tweaking an adequate solution for each org.
At the end, I believe the point is clear now: “Management is doing things right”, said Drucker. Let´s make sure that the second part of his quote – “Leadership is doing the right things” works out during voting exercises.
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
El caso con el Caso de Negocio / The case with the Business Case
ESPAÑOL (English version below)
¿Por qué estábamos haciendo este proyecto? ¿Por qué estamos metidos en este “enredo”? ¿Para qué estábamos construyendo este producto? ¿Cuál era el objetivo último que perseguíamos? ¿Se justifica aún asignar tantos recursos a este asunto? ¿Cambió la regulación, el mercado, el contexto? Parece mentira, pero a todo Gerente de Proyectos, digo mal, a todo “Stakeholder” (Patrocinador, Gerente, Cliente, etc.) le ha ocurrido en más de una ocasión que las respuestas a estas preguntas no son cosa patente y evidente. Así es, las respuestas deberían ser casi una perogrullada. Pero el asunto no termina ahí: en la mayoría de los casos, no son las respuestas las que no están a mano, sino que olvidamos plantearnos continuamente las preguntas como tales. ¡Caramba! Es que estamos tan ocupados que casi siempre perseguimos a marchas forzadas la terminación de los entregables del proyecto sin cuestionar nada sobre el mismo. Veamos esto con un poco más de detalle, a continuación.
A lo que voy es que, en una organización gestionada de manera medianamente ordenada, en algún momento se hizo un análisis que justificaba el “dolor” asociado a la ejecución del proyecto. Eso se llama un “Caso de Negocio”. Si se hizo de manera apropiada, contendrá mínimamente una explicación del “por qué” del proyecto y el razonamiento que explica el haber escogido esa solución. Bueno,puede tener otros elementos, como las opciones para solucionar el problema ó necesidad, riesgos, costos y duración grosso modo, aprobaciones pero lo esencial es lo anteriormente explicado. Lo que ocurre es que ese problema o necesidad – ese “por qué” – y esa solución propuesta – ese proyecto – no son inmutables: nada lo es. Las circunstancias cambian. Cambia la legislación, cambia la tecnología, cambia el negocio, cambian los competidores, cambia el mercado, cambia el contexto mundial (¿alguien dijo últimamente pandemia, crisis de contenedores, crisis del mercado laboral, cambios demográficos, guerras?). El Caso de Negocio en su versión oficial 1.0 es una instantánea, una foto que respondía a un momento determinado. Sin embargo, por aprobado, se convierte en una especie de “undécimo mandamiento”, incontrovertible e incuestionable. Peor aún, normalmente se coloca “en el fondo de un cajón” – léase de un fichero digital – donde nadie lo vuelve a ver.
Atribuyo el citado comportamiento a nuestra carencia crónica de pensamiento crítico aunado a la sobrecarga laboral de la vida moderna. Actuamos entonces como autómatas, robots persiguiendo “deadlines”, hitos, entregables y semejantes. Se nos olvida pensar, cuestionar, debatir. Dicho lo anterior, la solución a este tan humano comportamiento fue identificada ya hace un buen tiempo. Me refiero a lo que plantea la metodología PRINCE2, la cual incluye en su modelo Puntos de Verificación oficiales para ventilar el Caso de Negocio – vamos, para ver si el proyecto aún “vale la pena” – al final de las diferentes etapas, incluyendo al finalizar el Proceso de Inicio de Proyecto, la Fase de Iniciación, durante las diferentes Etapas de Ejecución del Proyecto, a través del Control del mismo e inclusive al Cierre y en la Revisión de los Beneficios.
Más allá de perdernos en los detalles, lo que deseo destacar es el concepto como tal: el Caso de Negocio no debería ser nunca “letra muerta”. Supongo que podríamos hacer la concesión y en algunos tipos de proyectos de carácter iterativo o particularmente sencillos; pues limitar la revisión del mismo. Sin embargo, si el esfuerzo demanda diseño, transiciones, transformaciones, introducciones de nuevos productos & servicios o iniciativas de gran escala; pues me parece fundamental contar con validaciones periódicas del Caso de Negocio, siquiera para asegurarnos que “la brújula sigue orientada hacia la estrella polar”, si se me permite la marinera analogía.
Y usted, estimado lector, ¿tiene acaso algún caso con el Caso? Me atrevería a apostar que así es…
Saludos,
Fernando
ENGLISH (Versión en español arriba)
Why were we doing this project? Why are we in this “mess”? Why were we building this product for? What was the ultimate goal pursued here? Is it still logical to allocate so many resources to this “thing”? Did the regulation, the market, the context change? It is utterly amazing, but every Project Manager, I stand corrected, every stakeholder (Sponsor, Manager, Client, etc.) has fallen in the trap of not having the answers to these questions just at hand. That’s right, those answers should be almost a truism. But the issue does not end there: in most cases, it is not the answers that are not handy, but rather we continually forget to ask ourselves the questions as such. Alas! It’s just that we are so busy that we are almost always chasing the completion of the project deliverables without questioning anything about it. Let’s look at this in a bit more detail, below.
My point is that, in an organization managed in a fairly orderly manner, at some point an analysis was made that justified the “pain” associated with the execution of the project. That is called a “Business Case”. If properly done, it will contain at least an explanation of the “why” of the project and the reasoning behind choosing the selected solution. Well, it may have other elements, such as the options to solve the problem or need, risks, costs and duration roughly, approvals, but lets not get into the weeds. The trick is that this problem or need – the “why” – and this proposed solution – the “project” – are not immutable: nothing is. Circumstances change. Legislation changes, technology changes, business changes, competitors change, the market changes, the global context changes (someone said pandemic, container crisis, labor market crisis, demographic changes, wars?). The Business Case in its official version 1.0 is a snapshot, a photo that responded to a specific moment. However, once approved, it becomes a kind of “eleventh commandment”, incontrovertible and unquestionable. Worse still, it is usually placed “at the bottom of a drawer” – a digital folder – where no one sees it again. Oblivion.
I attribute the aforementioned behavior to our chronic lack of critical thinking coupled with the work overload of modern life. We then act like mechanisms, robots chasing deadlines, milestones, deliverables and the like. We forget to think, question, debate. That said, the solution to this very human behavior was identified a long time ago. I am referring to what the PRINCE2 methodology proposes, which includes official Verification Points in its model to air the Business Case – come on, to see if the project is still “worth it” – at the end of its different stages, including the finalize the Project Initiation Process, the Initiation Phase, during the different Project Execution Stages, through its Control and even at the Closure and in the Review of the Benefits events.
But lets not get lost in the details: what I want to highlight is the concept as such: the Business Case should never be “dead letter”. I suppose we could make the concession and in some types of projects that are iterative or particularly simple; then limit the review of it. However, if the effort demands architectural designs, transitions, transformations, introductions of new products & services or large scale endeavors, it seems essential to me to have periodic validations of the Business Case. This event for the sake of ensuring that “the compass is still oriented towards the North Star” , if I may use a nautical analogy.
And you, dear reader, do you have any case with the Case? I bet you do…
Cheers!
Fernando
Photo by Kevin Noble on Unsplash
WHO is (really) driving this project?
Today I want to share a powerful & simple thought. Or perhaps its more of a warning, or even better, let´s call it a tip. Thus, behold: Dear Project Manager, check out your current endeavor(s) and ask yourself: who is driving this project? No, stop there, I mean the question: Who is actually driving the project? Is it really the PM, as it is supposed to be? Or could it be that in reality another stakeholder has seized control? Those are actually tricky questions, lets talk briefly about them.
For starters, the default answer to the question is “I, the PM”. Default because that is what the PM was appointed for in the first place. I mean, “Manager” is in the title, isn´t it? But that´s just in theory. That may be the case (and all good thus), but chances are that for a variety of reasons and circumstances that exceed the scope of this short article, a good chunk of the project Control & Authority may have shifted to someone else. It may be the Customer, a Vendor/Supplier, a Governance Body, the Sponsor, a Consultant, a Project Team Member, a Governmental entity, a Legal Partner, a PMO Rep? Someone else? Or even perhaps no-one, and therefore the project is flying in an “auto-pilot”, “at the hands of God” basis? Even a combination of the aforementioned is possible. Regardless, the point is: as a PM, we should continuously inquire ourselves who is the actual “pilot” driving the project, no matter its stage.
The answer may surprise ourselves and not in a happy way. But information is power and self-awareness is vital. Once we understand who is actually behind the wheel, we need to make a series of secondary questions. Example: Is this the right thing at the current time? If not, who should that be – me? For how long has this been going on? Why did it happen in the first place? Has magical-thinking been implied? What about assumptions? Is there some type of bias in my perspective? Are there cultural aspects to consider? How about the overall PMO, Governance, Program, Portfolio perspective? Strategy and stratagems involved? Which is the correct way to seize back the authority, assuming that is the correct thing to do now? How does that authority grasp occur: gradually, immediately? What is the correct control / authority / accountability / decisions split across stakeholders? Should & could this happen again in the future at some stage? Should this be escalated or consulted with someone, eg, the Sponsor? Those are serious queries which demand careful analysis; the outcomes could potentially impact the success of the PM and the project. An actual plan may be required for a correct remediation , including a design and an implementation. Those are strategical, “existential” questions for a PM.
All that said, of course I am not implying that a PMs is supposed to have dictatorship-like power over the project: there are layers and layers of authority, governance, decision and perspective. Still, if the role is held accountable in some degree to the project actual results then a reasonable level of control has to be assigned to it. If that is not the case, then both the organization and the PM are deceiving themselves, and that is a dangerous game that often leads to negative results to both parties… and to the project per-se.
Alas! In conclusion, questions are always our allies. Let me finish by quoting “The Bard of Avon”: “To be or not to be, that is the question”.
Cheers,
Fernando
Photo by Kristopher Allison on Unsplash
Webinar con la Universidad Nacional: “¿Por qué fallan los Proyectos? Lecciones de la Vida Real” / Webinar with UNA: “Why projects fail? – Lessons from Real Life”
ESPAÑOL: Les invito cordialmente a ver la grabación de mi reciente webinar con la Universidad Nacional de Costa Rica – UNA, titulado “¿Por qué fallan los proyectos? – Lecciones de la Vida Real”. La exposición mezcla vivencias de mi práctica personal con anécdotas históricas de la II Guerra Mundial. Estoy seguro que mis colegas se verán retratados en más de una de las situaciones ahí dibujadas, y que alguna(s) de las propuestas de solución les serán interesantes.
Un abrazo,
Fernando
ENGLISH: You are invited to enjoy the recording of my webinar with the “Universidad Nacional de Costa Rica” – UNA (academic institution where I teach Project Management related topics), entitled “Why projects fail? – Lessons from Real Life”. I am sure that the situations there depicted – including curious anecdotes from WWII – will “ring a bell”, and that some of the ideas to correct these major problems will resonate with many of you. Feel free to turn on the captions and then the auto-translator.
Cheers,
Fernando
D-Day: Lessons from THE GREATEST Project of the XX Century
I recently finished Stephen E. Ambrose´s book “D-Day. The Climatic Battle of World War II”, a historical 600 pages masterpiece presenting the Allied perspective of what has been described as the most important day of the XX century. I also read “D-Day from German´s Eyes”, by Holger Eckhertz, which in turn provides insight from the much less publicized German perspective. After digesting both books and some interesting online documentaries (see some samples below), allow me to share with you, kind reader, some lessons learned from the Project Management perspective. And these are indeed lessons, worth to be stated, extracted from perhaps the most complex & crucial planning effort of modern times. Here we go:
Number 10: make the plan proportionate to the project.
D-Day was massive. No, I really mean it – epic, colossal, humongous, huge by all standards. Let´s check some figures: circa 160.000 Allied troops involved, storming nearly 60km of coast. Almost 7,000 ships and vessels of all type and about 2,400 aircraft; not counting gliders, tanks, trucks, jeeps and other vehicles. It is still the biggest amphibious operation of all times, a behemoth of a project. It has also one of the most bizarre Planning-to-Execution duration ratios, with about two years of Planning efforts vs a couple days of actual Execution. This context demanded a plan according to the situation. And what a plan was created. The level of granularity was astounding: massive hoax operations (“Operation Fortitude”), attack exercises and simulations, logistics to shelter, feed and train hundreds of thousands of individuals, intelligence efforts, en-masse fabrication efforts, weather analysis and forecast, enemy surveillance, attack itineraries planned to the minute and hundreds of other factors all meshed together into a gargantuan plan. Referring to solely the operation plan for his regiment, a colonel is recorded to have said “It was thicker than the biggest telephone book you have seen”. Yes, big & important projects demand big plans. Small projects usually do not demand such exercises, and then small improvements, routine changes, near-task sizes need easy stuff. The plan must raise to the need – that is the point.
Number 9: the plan is useless, still, planning is indispensable
On June 6, 1944 nearly everything that could go wrong for the Allied Forces went wrong. The weather was bad, affecting the actual approximation to the shore. Then, with the noticeable exception of the low-altitude B-26 “Marauders” aircraft, the most powerful air bombing (through B17s and other high altitude aircrafts) was a fiasco. The sky was cloudy, it was still dark and flying at 20,000 feet, pilots had no real idea of their precise location. Thousands of tons of explosives were wasted, destroying nothing but cattle and green fields. Another example? Rockets fired by the assaulting amphibious ships almost never hit the target. Then the gliders, supposed to provision thousands of tons of equipment and men failed miserably: The cause? Normandy´s hedgehogs were much higher and sturdy than English ones, making the landing a suicide. This sole factor almost caused the entire operation to jeopardize. The list goes on. Still, “In preparing for battle, I have always found plans are useless but planning is indispensable”. The author is no other but the Supreme Allied Commander himself, Dwight D. Eisenhower. This statement holds true: despite all these failures, the planning exercise made Operation Overlord a success at the end. Months of preparation created a level of awareness and perspective that allowed the troops to identify new factors and adapt as per the real circumstances. Take for example the mess made with the paratroopers. Very few men, less say regiments, landed were intended. Still, their knowledge of Normandy´s geography and their laser-focus on their goals allowed them to adapt, re-organize and cut Nazi´s supply lines. The plan can fail – but we must be aware of the circumstances.
Number 8: you need line-of-sight, you can´t control what you don´t measure
A not much-known detail about the attack is that the high command (Eisenhower, Bradley, Montgomery, Smith, etc.) and even medium rank officers were mostly blind on June 6th. The fact that the operation was launched before dawn, the bad weather and mostly the enormous amount of smoke, ashes and flying debris of all sizes & types made the coast line virtually invisible from the vessels. Tons of bombs from the bombers but mainly the ulterior navy attack with massive cannons (eg, 400mm and bigger) plus thousands of rockets launched from the lighter disembark vessels created a virtual curtain. Let me quote Ambrose book yet again: “It was most galling and depressing,” Commander W.J. Marshall of the destroyer Satterlee wrote in his action report, “to lie idly a few hundred yards off the beaches and watch our troops, tanks, landing boats, and motor vehicles being heavily shelled and not be able to fire a shot to help them just because we had no information as to what to shoot at and were unable to detect the source of enemy fire.” Furthermore, most of the primitive communication gear of the time broke up during the landing, allowing no communication from the troops at the beaches to the fleet – with some noticeable exceptions. At the end, the Navy played a primordial role, heavily bombing Nazi positions, but it took hours for decisions to be made, and for the required accuracy to be met. Let´s try by all means not to fire our cannons to invisible targets.
Number 7: don´t put all your eggs in the same basket
When I was reading the books, I came to the (general & raw) conclusion that D-Day success came mainly through a combination of plain brute force (massive numbers of everything) but mainly idiotic errors from the enemy. An idea struck my head: what if the invasion failed? What was “plan B” in case the Atlantic Wall couldn´t be breached? Well, as per historic records, there was no backup landing plan. Thus, the plan was to storm kilometers of coast, intending to make a breach somewhere and then work it from there. But the main backup was surprising: a nuclear bombing to Berlin was under consideration in case all efforts failed. Luckily, there was no need for that ultimate resource.
Number 6: don´t confuse a “how” with a “what”
Hitler, Roemmel and Co. made a supreme mistake when planning for the invasion: they – and particularly Roemmel – envisioned that the sole way to protect “Fortress Europe” (the propaganda name for the conquered Europe by the Nazis) was to construct literally a wall around it, particularly on the Atlantic coast close to the UK islands. This was a major mistake: it was Germany itself the one who proved that wars have changed forever. Fast mobility, logistics, blitzkrieg, aviation – those were the factors that had put Europe in their hands. Still, when taking a defensive position, they went back to WW I or even Middle Ages approaches, envision the Atlantic as a moat with a castle behind. If (and what an if that is) they would have put their energy not in pouring millions of tons of concrete right on the coast but in constructing more Panzers, more bridges, more secret fortifications the D-Day story could have been different. Moreover, the reconstruction of their air force would have been another good call, not to mention to station the bulk of their troops a little farther from the coast, beyond the Navy´s “columbiads”. Perhaps this would not have changed the end result of the war, but it would have altered the outcome of D-Day and provided them with time to improve and massively deploy their futuristic new weapons: V2 rockets and the impressive Messerschmitt Me 262 plus the Arado Ar 234, the first ever jet fighter and bomber. Those would have been true game changers. The lesson learned is evident: they needed to secure Europe, not to build a wall. Its a very different objective: never confuse a “how” with a “what”, with a final goal.
Number 5: there is no perfect timing – you have to take risks
On June 4th, 1944, Commander Eisenhower asked to the Supreme Headquarters Allied Expeditionary Force committee a question. He said: “Do you see any reason for not going Tuesday?”. Montgomery replied: “I would say – Go!”. Eisenhower continued walking, chin to the chest. “The question is… how long can you hang this operation on the end of a limb and let it hang there?”. Some minutes later, after more thought, he said: “I am quite positive that the order must be given”. The fleet was immediately deployed for the assault. He had to confirm again the attack next day as per the bad weather affecting the region. When reading the history, I just cant avoid feeling pity for the Supreme Commander. There was just so much at stake. It was perhaps the single most important decision of the century, and there were nothing but gray clouds around – literally and metaphorically. Will the weather get worse and sink the landing gear? Will the bombardment help enough the troops? How will the Nazis and their Panzer divisions react to the attack? Uncertainty was the word of the day. Still, a call had to be made, and he made the right one. Operation Overlord was too big and important to keep it on hold any longer. The troops were impatient and tired of the delay. Logistics were close to impossible. And each day the attack was delayed was an additional day granted for the Nazis to prepare their defenses. Risks have to be taken – calculated risks indeed, but calls and actions are a must.
Number 4: tools & tech help!
Have you heard about a Higgins boat? What about Hobart´s funnies? Well, these and many other were vehicles and gadgets crafted for that climatic day. A Higgins boat (more properly, an LCVP for Landing Craft, Vehicle and Personnel) was exactly that: a light landing vessel designed to ferry an entire platoon to the coast. Hobart´s funnies were tanks and similar powerful vehicles modified in crazy ways. There was the “Crocodile”, a tank with the cannon replaced with a massive flamethrower, the ARK, half tank, half bridge, the Crab, which had an enormous rotating cylinder on front with chains, designed to safely trigger mines. Then DD tanks (floating tanks – believe it or not) and many many other. These vehicles proved to be of true value to the troops, facilitating the excruciating task of seizing the beach. Technology helps indeed, when it is up to the task: right tool for the right job.
Number 3: adapt to survive
Reading the personal stories of the troops, it is utterly evident the level of a mess they were in. It is said that in war, each man fights its own battle, but this was never so true as in June 6th, 1944. Chaos was everywhere: paratroopers were dropped at night and got dispersed over kilometers. Tides sent troops and vehicles randomly. Enemy fire put everyone on cover. Air Force bombardment was a big fail. Still, the job was done, by adaptation means: agility at its best. The troops assembled under new leads (the close ones!), the available weapons were used, routes were changed, the brief available information was used to brilliant extremes. Teams were empowered and had the major goals clear, this allowed them to keep focused and save the day.
Number 2: use the right skills for the right job
A big factor in the success of the Allies was not only the general training of the troops, but the specialization in tasks: the assignment of the correct staff to the correct job. A good example was the exemplary performance of the 2nd Division Rangers to Omaha Beach – the 7th circle of hell during that day. These guys were the best of the best, and they proved their expertise and particularly, their motivation and stamina. These were volunteers, true patriots serving the free world while risking their lives at their own will. And they did the impossible: they climbed an almost vertical cliff under heavy fire and then secured the positions for the rest of the troops. This is in utmost contrast to the performance of the so-called Oost battalions: conscripts from all over Europe, men forced to work for the Axis cause. Most of them preferred to surrender at the first opportunity, and some even rebelled against the Germans. The lesson is clear: right skills for the right job, let´s devote the right time to allocate our resources to the tasks.
Number 1: TRUST – the troops are the ones who do the real job.
At the end, when the final “go” was given, and walking slowly toward his car after seeing the bombers depart, Supreme Commander Dwight D. Eisenhower simply said “Well, it´s on”. The interesting thing to notice is that, from the moment the orders to proceed with the assault were given, he was basically a spectator. He had empowered his Navy, Air Force and Army commanders, all through the line of command – to proceed as per their best criteria. He had led the planning effort, and made the final call. But it was now a matter of trust. Perhaps that is the most important lesson that we must learn: let the troops do their job – we got to trust them. Once the plan is ready, staff is trained, tools and systems are loaded, its on the tsoldiers, the technicians, the engineers, the developers, the staff – at the end, they are the ones doing the job. Tools, procedures, technology are good, but at the end people make things happen, they make the difference. Thus, TRUST.
“In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing.”
Theodore “Teddy” Roosevelt
To finish, a powerful “extra” lesson – and free of charge 🙂 Good ol´ Teddy Roosevelt, uncle of Franklin D. Roosevelt (coincidently, US President during most of WWII) put it in crystal-clear terms, as follows: “In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing.”. In other words, the worst decision is indecision. And that was if not the greatest perhaps the most evident mistake made by the Führer right after the beaches of Normandy were attacked. Believe it or not, after Hitler was debriefed about the situation, and having plenty of the powerful Panzer divisions – terror of the Allied forces all through the war – within hours of the invasion area in Normandy, he never ordered a counterattack. As a matter of fact, he had one of his infamous tantrums and then took a powerful sleep-pill, thus going for a long nap. No attack, no regroup, no location shift, no camouflaging, no preparation… not even a retreat. Nada. Why? Its inexplicable. Possibly he was hijacked by his emotions & temper (another lesson per-se!). What we can say now, nearly 80 years after, is that it he really blew it. Let´s learn from one of the major bloopers in war history: make your call – and make it on a timely basis; a mediocre resolution on due- time is better than a “perfect one” that comes late.
Good luck in your projects, or better-said, “V” for Victory as Churchill waved – cheers!
Fernando
Photo by Museums Victoria on Unsplash
