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
No, a year is not equivalent to 365 days (that is, project-wise).
I hope that through the title I already have your attention: it´s a bold statement, I know. Still, my point is not driven from a post holidays´ bad hangover or an astronomical delusion. Because yes, the 2021 gregorian calendar has 360 days to go (five gone by now), but this is more sort of a reminder, a call for awareness for decision makers, namely C-Suite, Executives, Managers, PMs etc. now that we are opening the 2021 cycle. In the following paragraphs I´ll explain myself, so bear with me.
For starters, unless your projects run in the same way as your operations (24×7), we are tricking ourselves from the very beginning of our planning exercise: most of us have a deep, almost subconscious assumption (sort of a collective verbal agreement) that concurs that the project has 365 days per year to exploit. Well, that is normally not the case. Let´s start with the ends, I mean the weekends. I have done some research (my data sources are Wikipedia and ourworldindata.org) and assuming Saturdays and Sundays are off and 52 weeks per year in average, then we got 104 days less. After adding the average number of paid holidays (11 is a rounded average worldwide, 13 is the mode), the result is that we loose about 34% of the year calendar days due to weekends and holidays. That leaves us with approx. 240 days to go. Still, if we examine this count from a realistic perspective, we must consider that the last weeks of the year are quite low productive, as the first one usually is. So I dare to say that the real result of this initial filtering exercise leaves us with about 230 or 225 days to produce whatever deliverables are expected. But wait, there is more…
The aforementioned 225 available days need to have paid vacations deducted as well. Now, leave-time varies a lot across countries & legislations. Let´s again use statistics as our allies: world average paid-day vacations based on a five-days work week is 16, and the mode is 20 (source: Wikipedia, these final aggregated numbers were calculated by Fernando). So now we are down to about 205 days to work. Is this the magic number? No, there is always a catch
The 205 days are also a mirage: this number is not accounting for sick, grief and other type of leaves, not to mention travelling days if your endeavor implies such needs. So at the end, I believe we have circa 200 days to go per individual, per calendar year. For the sake of keeping it short & sweet, I am not going in detail about historical trends on leave days. Let´s just mention that diminishing working hours is a historical fact and that 4 days work week is one of the big topics of our time: “experiments” on this idea are happening as we speak. All that being said, and for the peace of your minds, the translation of the work days into work hours provides some relief, especially now that work-from-home is ubiquitous and extended working hours are a new normality: to what extent this simultaneous trend counters/balances the day availability reduction is yet to be assessed as the post-COVID era matures.
As a conclusion, I want to leave you with three ideas in mind: first, if your projects run on a 5 work days week basis, you have in fact about 200 work days per year to go (in other words, you loose 45% upfront!). Secondly, if time is of the essence (and according to my experience, it always is) we should consider for budget to work during Saturdays and/or double or triple shifts and/or a follow-the-sun tactic. A buffer for delays should be embedded into the plan as well. And then last but not least: at the end, our results depend not so much on calendars but on productivity. The point is simple: one truly devoted, focused hour – not to mention a day of undivided attention – produces more relevant outcomes than hours of “multitasking” and mediocre efforts. So let´s strive to be human and deal with one thing at a time – the correct one, the current priority – with all our capabilities and skill in this brand new 2021.
My sincere best wishes to you and your kin, may this new cycle around our star be more productive, focused, happy and healthy for all Humankind.
Fernando
Photo by Debby Hudson on Unsplash
Pick up that phone!
“The medium is the message.” – Marshall McLuhan
In days to come, 2020 will be referred not only as the COVID pandemic year, but as the Work-From-Home super-spreader. Globally, jobs not requiring our presence at a physical office are running from our homes, with all the pros & cons that this externally imposed statute implies. In this post, I dare to share the simplest yet most underrated productivity tip for these convoluted times, which is (drums rumble) … pick up the phone! Please don´t tell me you don´t have a physical handset; that is not the point. What we are saying is that we need to bear in mind, carved in letters of gold, that a voice call expedites almost any back-office process you can think about. Yes, I am not talking about fixing a meeting (enough we have, don´t we?) or an unproductive status checkpoint, this is about the old-fashioned 1:1 call – just you and the other stakeholder. For heaven´s sake, don´t email if urgent – pick up the phone and call “John”. And if you have not interacted in a time, if deemed appropriate, ask “Mary” about the family & friends – let´s keep a healthy “layer 8” (human) network functioning: times have shifted, but relationships are still (and perhaps) more important than ever.
On a related line of thought, turning on the camera during meetings and calls is mostly a good idea. Not only it conveys humanism, but it forces you to be “there” and to prepare for the meeting or call. This preparation also implies taking an early shower, dressing appropriately, shaving, make-up being the case, etc. Yes, we are physical beings and taking a shower is part of the daily personal boosters routines. If “cameras on” is what is needed for that to happen, so be it.
In conclusion, we should all develop a sixth-sense, just not for seeing dead people, but for detecting “zombie” email threads (“The Walking Mail?”). We are becoming more and more afraid to pick up the phone and call a co-worker, a customer or a supplier. Think about it: why the hesitation? It’s just a business call – talking to a peer or liaison. What is all this anxiety about? What are we afraid of? COVID cannot spread through the lines but apparently we kind of assume so. We are confusing physical social distancing with self-inflicted isolation. This is a bad thing for the industry, for the business, for our relationships, and for ourselves… and the fix is easy: pick up the phone!
Enough said, this is the end of the post. Let me hear any comments, thus, just give me a call :o)
Fernando
The Quest for (True) Sponsors
“Who finds a Friend finds a Treasure”, says the old adage. The same applies for the wild “Project Kingdom”, where we can paraphrase and say the same thing, just only for Sponsors. Alas! It is just that true Sponsors are really an uncommon thing in the Project Management world: a rara avis within the modern business jungle. Now, a disclaimer is necessary upfront: it is not the case that sponsors are actually deliberately acting against PMs or more importantly, against the project and its goals. It actually doesn’t makes sense for a Sponsor to sabotage his/her own interests & organization. The project´s success is their success. So what is going on here? Answer: in the vast majority of the cases, sponsorship issues can be grouped in five general categories, as follows…
Sponsorship Problem Categories
- Work Overload: the Sponsor role demands someone with criteria, someone with experience, someone with enough ascendancy & power in the organization. These are individuals entrusted to make decisions. They manage budgets and resources. Sponsors are normally high-ranking persons within the org: C-suites, VPs, Directors. Thus, they are very busy and get pulled simultaneously from many directions. You see the in-built conflict here? The Sponsor role demands for high-profile staff who is already over-allocated. The result is that many sponsors – logically – privilege day-by-day work and “keeping the lights on” in detriment of their sponsor “additional hat”, all this to a negative effect on the projects.
- Organizational Immaturity: The Random House Dictionary defines maturity as “full development or perfected condition”. So this factor actually refers to lack of development in our entities. To put it simple, the organization (or its division) is not ready for a “projectized ecosystem”. Actually, the prior bullet point is a reflection of this, since the entity as a whole is not aware of the current workload distribution within its leads or simply lacks enough headcount to cover the sponsor roles. Another possibility is that the governance process and/or body managing the portfolio is weak. This is a common situation: the organization is immature and fills roles with names “just to fill the field”, to a total misunderstanding of the actual requirements, consequences and implications of this behavior. The governance process (Portfolio Management, “Approval Gates” system, Resource Allocation, etc.) is probably weak. Moreover, the Sponsor is not understood as the ultimate accountable person as of the project success. Au contraire, a mature organization with a solid governance process is nearly “vaccinated” against “sponsor-virus”, to put the topic in hands in our era´s terms.
- Lack of Knowledge: lets recall the actual definition of a Sponsor. According to PMI´s PMBOK 6th Edition, a Sponsor is “A person or group who provides resources and support for the project, program or portfolio and is accountable for enabling success.” I don´t know about you, but that short statement really raises my eyelash. There is a lot in there: “provides resources and support”. Also, “accountable”. And then, “enabling success”. What an explosive combo! And yet, Sponsor role training is really uncommon when compared to the Project Manager role (PMP vs ???), not to mention other technical and business areas abundance of training & education. Actually, my research found just a couple Sponsor certifications, such as PPS by APMG. This is quite interesting: if all projects should have both a PM and a Sponsor, how come this total disproportion? How come there is no specific Body of Knowledge for that role? A final disclaimer on this point: if the org runs under a PRINCE2 framework (back to the maturity point, I guess), then precisely the “Controlled Environment” part should tackle many of these issues away.
- Shared (fake) Accountability: I (Fernando) personally disagree with the PMI inclusion of a “group” as a possible entity to play the Sponsor role. In my personal opinion, “shared-accountability” is sort of an oxymoron. Accountability is personal or it isn´t. Therefore, more than one name listed as Sponsor is a contradiction in terms. I also think that there may be exceptions to this principle in the real world, especially in really mature places (CMMI L5, Prosci CM L5, PMI OPM3 L4 and similarly rated organizations) but exceptions are precisely that: rare, sparse, in a word – exceptional.
- Any possible combination of the above… which, in my experience, tends to be indeed the most common case.
How to solve this mess
What´s to be done with this situation? Let me quote Plato: “Ignorance is the root and stem of all evil”. What I mean is that education both to the individual and the organization should be the first step: we need to fully understand & digest that a Sponsor is not just a signature or a name in a PPT slide. Project Sponsorship implies active engagement, dedication, time & energy. A Sponsor should be a champion for the Project, acting sometimes as a lightning-rod in order to shield from external attacks to the endeavor, sometimes dealing with the complex organizational politics, sometimes serving as a guide to the PM. Sponsors promote, authorize, fund, approve, distribute and receive info, resources & outcomes for and to the project. They are also escalation paths, priority masters and scope definers.
Sponsors should be educated (certified), and the organization should acknowledge its maturity level and perhaps even more importantly, assign time & resources for the role. Building on this idea, and thinking outside of the box, perhaps for really busy, high-level individuals sponsoring many projects, a dedicated Sponsor Assistant may be an option. That would be a really savvy business individual, someone empowered to make decisions within pre-defined thresholds/limits/rules and with the responsibility to compile, filter and summarize key insight to the Executive he/she serves: sort of a smart funnel point for sponsorship affairs. That being said, accountability must reside in the official Sponsor and him/her only: it is a personal requirement, period.
Then for really large corporations, here´s an original idea: some organizations may require an “SMO”, the equivalent to a “PMO”, specifically, the Supportive type, but tweaked for the Sponsor role. I devise this entities as similar to their PMO equivalent, providing a purely consultative/assistant role to Sponsors by “supplying templates, best practices, training, access to information and lessons learned from other projects” (Giraudo, L. & Monaldi, E. (2015). PMO evolution: from the origin to the future. Paper presented at PMI® Global Congress 2015—EMEA, London, England. Newtown Square, PA: Project Management Institute.). Moreover, SMOs could be “Delivery support functions/services – these focus on supporting the delivery of change and may be provided through a central flexible resource pool of delivery staff, with capacity planning, and HR management processes.” (Giraudo, L. & Monaldi, E. (2015). PMO evolution: from the origin to the future. Paper presented at PMI® Global Congress 2015—EMEA, London, England. Newtown Square, PA: Project Management Institute.) So there you go: SMOs, an internal consultant agency for Sponsors, if you will, is born.
Conclusion
Sponsors are the top liaison, the ultimate bridge between the organization and the project. There is a reason why they are the ultimate accountable staff for the project success – their active commitment & engagement is proof of it. Furthermore, the mandatory time, processes, tools & resources required to execute the role must be provided by the organization, else, the organization is tricking itself.
I´d love to hear your thoughts on this topic. Email me or preferably state them as a comment to this post.
Cheers,
Fernando
