Monthly Archive August 30, 2022

Divide and Conquer: A different PM per phase?

A baton race approach…

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

A veces pienso que…

[Un (intento) de poema original]

A veces pienso que yo pienso

Que los vivos no están vivos
Que los muertos no están muertos
Que en este, el único instante
No hay de estos ni de aquellos

Que mis hijos te redimen
Que tus hijos son mis verbos
Que solo soy porque tú eres
Que no hay horas, ni desiertos

Que la vida es antesala
Que somos solo los recuerdos
Que lo único que importa…
es que otros gocen, de la sombra…
…de los árboles, que siembro.

Fernando

Agosto 2022

Foto: Café con Nostalgia / Photo: Coffee with Sigh

ESPAÑOL: una última planta de café. Una casona que se cae con el peso del tiempo. Una postal de una época que no volverá.

ENGLISH: one last coffee plant standing. The plantation house falling apart. A postcard from a time gone by…

Not Agile, not Waterfall, not Hybrid: my FAVORITE approach is…

The verdict 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