A lot of the current literature on the topic of Leadership (ProjectManagement.com’s theme for October) focusses on the relationship between the leader and the team that follows him, usually along the lines of eat-your-peas-style hectoring on how said leader treats the individuals in the organization. Does she treat them with respect? With absolutely no trace of partiality? Do the individual organization members receive sufficient training, or mentoring? Why not? Etcetera, etcetera.
I find this type of discourse tiring in the extreme. It strikes me as a kind of micro-organizational navel-gazing exercise, spending energy on the quality of the relationships within the team rather than the project’s actual scope. Sure, relationships within the organization matter, but what matters more is the ability of the putative leader to correctly identify the optimal technical approach to resolving the problem(s) facing the Project Team, and to execute it with the resources at her disposal.
An easy litmus test for which type of organization GTIM Nation members belong to is this: is your superior happier if your Project is late or over budget, but you executed a technical agenda entirely within the organization’s guidelines? Or are they happier if you bring in your Project on-time, on-(or even under) budget, but had to ignore some admonishments from the risk managers (no initial caps) about the absence of a “risk register,” even though your organization’s procedures required you to have one? The former category has to manage by metaphorically maintaining a view from over-the-shoulder, spending time and energy on demonstrating the execution of an approved process, whereas the latter category has the latitude to pursue the Project’s goals in what the PM perceives as the best manner available. (Note: I am absolutely NOT talking about safety or security guidance here. Those must be observed in their totality, no exceptions.) It makes for a huge difference in not only the organization’s culture, but in the odds of successfully executing all of the elements within Project portfolio. The answer to this question is also an indicator of the adaptability of the organization’s business model to changing, unpredictable circumstances. If it is pliable enough to maximize the odds of Project success, then I would consider that a notable advantage. However, if Project success is considered secondary to demonstrable adhesion to business-related policy and procedure, odds are that the business model has become so ossified as to almost guarantee Project portfolio sub-par performance.
I want to be crystal clear here: identifying the optimal technical approach to PM problems is not simply dropping copies of the PMBOK Guide® on managers’ desk (with a satisfactory “thud”), and expecting them to spontaneously develop Work Breakdown Structures (WBSs) and Work Packages. From a Project Management Office (PMO) Director’s point of view, this would be the equivalent of trying to advance a capability by using the Argument from Authority – a logical fallacy – with that “authority” being our beloved PMI®. But unless I’ve missed something over my over-thirty-year association with the Project Management Institute®, they do not maintain an Enforcement Division (and, if they do, I want to be part of it!). Even if such an appeal to authority was not considered a logical fallacy, I would be cautious of assuming that everything that appears in any guidance document is timelessly true. If that were the case, there would not be seven editions of the PMBOK Guide® as of 2021.
Which brings me back to my original point. So-called “best practices” achieve that status only after they have been tried out in a variety of Project circumstances and found to be consistently useful. Then and only then can they become candidates for addition to any kind of codex or PM practices, like the PMBOK Guide®. In-between the time that these practices are discovered and implemented, and then published or codified, a wide array of decisions await the typical PM, decisions that might not be able to be informed by what has gone before. Sure, some Project work is so routine that adherence to the tried-and-true (or the novel and recently-released) is the best way to achieve success. But in a lot of (most?) Project work, key decisions will have little or no precedent, and yet must be addressed in real time. These are the situations where managerial leadership is key, where there is no precedent or codified technical approach to the newly-presented problem. PMs resolve these kinds of problems all the time.
And they can’t do so by looking over their shoulders.
Community Champion
