In my last post, I described the third project management “meta-problem” as being the vast and unbounded dimension of project management. This post will cover the fourth meta-problem of project management: project management competence (or lack of it) and its implications.
There are at least 1000 discrete elements in a relatively simple assessment of the skills requirements for project management. These skills aren’t arcane or radical, but a collection of “meat and potatoes” skills from both predictive and agile domains. They are, after all, derived from one or more branded frameworks or BOKs.
Given that much of the industry promotes a constrained view of project management, and that this view is both fractured and conflicted, it’s not surprising that there is a pretty low level of competence of project management practice. This is underscored by the trend to commoditised and packaged certification approach to skills development.
I’m not just talking about the ability to practice project management, but also the ability to analyse and critique objectively or to identify and propose a rich range of alternative approaches to unique project situations. Reflective practice is either uncommon or almost entirely private.
Pop Quiz: what would you do?
Answer honestly: when you ask yourselves: “what should I do in such and such situation?”, do you simply regurgitate whatever you’ve memorised from some BOK or book? Or do you critically and objectively assess the situation and select from a range of tools, techniques and strategies that are right for the job at hand, regardless of labelling or categorisation?
If someone says to you “I don’t know what stakeholders are”, do just give them to a template for a “stakeholder management plan” or do you provide principle-based guidance on the need to understand different perspectives, influence and interest and facilitate the optimum fulfilment of each group’s interests in any given project.
As a PM, do you find yourself swamped in unforseen events, despite diligently executing a Risk Managment process and maintaining your risk register? Does this mean you spent too much time on the process and not enough time on project design or detecting and mitigating risks?
I recall a PM in my team asking for help in filling out a new kind of template. When I tried to give him the background to the template and explain how it worked, he said “Adam, I don’t want to know how it works. Just help me fill it out so our boss doesn’t give me grief.”
One side effect of commoditisation is superficiality. As I mentioned when describing the first meta-problem of narrow viewpoints, the packaged knowledge bases used for certification have to be both “learnable” and “testable” within limited resource constraints. As such everything is neatly packaged and structured for simple execution.
Models of Competency: Shu Ha Ri
Alistair Cockburn popularised the notion of Shu-Ha-Ri as a framework for skill levels and progression. I think it’s a great model and has the added authority of historical tradition, refined over at least decades if not longer.
But transposing this model to the modern world of Agile practice (as Cockburn has) or even Project Management, creates to big problems.
Firstly, the domain being taught/learned needs to have certain characteristics: it has to provide efficacy to its practitioners in the domain (e.g. Akido or other forms of martial arts). Secondly, it has to be practiced over time and in a particular way– we know that master-level skills come from a particular kind of practice (called “deliberate practice”) executed in a very specific way. And thirdly, it has to be practiced under the close and watchful eye of a master, who can provide immediate feedback and guidance.
The learning experiences of Project Managers in this age of crash qualifications and rote-learning certification certainly fails the second and third points. Whether they fail the first point is a matter of opinion.
But when one looks at the results, the common behaviours of project managers who come up through this process, they are often found wanting.
Operate a process or Deliver an outcome?
I’m fond of telling people that there are two kinds of project managers: on the one hand there are project managers who believe that their job is to operate a process called project management. On the other hand, there are project managers who believe that their job is to deliver outcomes for their stakeholders. There are very strong clusters around those two types and the cluster around “delivering outcomes” is very small.
People who are (or feel they are being assigned to) the “operate a process cluster” may simply feel that I’m wrong. They may object and say “but of course I want to deliver outcomes, see my project schedule, my risk log, my decision log etc. – this is how you deliver outcomes.”
Wax On! Wax Off!
The Karate Kid meme of a subtle but caring Mr Miyage guiding a novice to mastery has a deeper truth than its comedic foundation might indicate.
There are plenty of “Wax On; Wax Off!” opportunities to lead someone towards better skills. But it takes deep knowledge, a highly developed sense of instruction and time. In fact, Cockburn extended Shu-Ha-Ri to add “Kokoro” which loosely speaking includes teaching.
But unless a better approach to skills development is established within the broader project management industry, we risk “Wax Off; Wax Off!” being seen as acceptable practice and perhaps not even noticing the problem.
How do we find this better approach? That’s a matter for posts in the near future.