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