Methodology Doesn’t Matter

NOTE: This post is an elaboration of my column in an upcoming issue of PM Network magazine

Recently, I was reading an online discussion board, where two project managers were arguing whether a particular project management approach could be described as a “methodology”.

Their discussion had 37 entries.

My first reaction was to roll my eyes at the waste of time involved in such a debate. What is so important about whether we use the “methodology” label when referring to the PMBOK, Method/1, Scrum, ITIL, or Prince2? It used to be that we argued over which of these methodologies was the best one to use. Today however, experts will detail for us the finer points of why their product absolutely is NOT a methodology, and must instead be called a “toolkit” or “framework”. Seriously, what’s the big deal? Every project manager should know that how you do your work depends on the the context of that work. So then whether we call our specific approach a “standard”, a “process”, or (gasp!) a”methodology” is irrelevant, right?

However, the more I think a about this religious debate of terminology, the more I see legitimate anxieties. At least some of the time, this is not a debate of “I’m right, you’re wrong”. Rather, there are deep-seeded concerns about the negative impact an organization’s processes and policies have on project teams. The arguments associate “methodology” to a variety of bad management practices. So, if we assume this debate as childish as at first glance, let’s explore some key reasons why methodology doesn’t matter.

Reason 1: According to English, anything intentionally organized is a “methodology”.
A common objection to the M-word is that it explicitly means we have to do all of the steps all of the time. However, a quick review of the definition reveals that’s not the case
The Oxford English Dictionary defines a methodology as “a system of methods used in a particular field”. It further defines a system as “a set of things working together as a mechanism or interconnecting network”. So if we put those together, we find:

A Methodology is a set of things working together as a mechanism or interconnecting network, which is used in a particular field.

It would be hard to argue that the PMBOK or Scrum do not qualify as a set of methods that work well together in an intentional fashion. Even the Agile Manifesto, which is a document of values and principles, advocates specific methods like regular reflection and face-to-face conversation. There’s nothing in the definition that mentions rules, let alone saying you have to follow all the rules, or that you’re less of a person if you don’t follow all the rules. Indeed, even the experiential and emergent Montessori approach to primary school is called a methodology. According to English, christening your management practices as a methodology says almost nothing about what those practices are.

Reason #2: Methodologies themselves tell us NOT to follow all the rules.
If the primary anxiety is that methodologies require us to manage-by-the-book, we do well to actually read the book:

• The PMBOK references process tailoring 14 times.
• The Agile Manifesto values individuals and interactions of a team that tunes and adjusts its behavior throughout the project.
• The Unified Process describes the relative emphasis of skill sets at different phases.
• ISO 9001, Section 8 explains the goal of formalizing business operations is facilitating continual improvement (read tailoring) of those processes.

…and these are just the examples I have on hand. I would challenge you to find a process methodology that explicitly states you have to follow all the rules, all the time, now and forever.

Reason #3 No methodology asserts it is always better than another
The examples I’ve given above lay out a set of practices that accomplish a specific goal within a specific context. The PMBOK is a set of practices for managing projects, whereas ISO 9001 is focused business operations. The Agile manifesto was crafted for the knowledge work of software, but Six Sigma was designed manufacturing. None of them explicitly state they are better than any other.

It’s worth noting that even though these methods don’t assert superiority over each other, people do. Process Champion X can preach all he wants that his method is better than the others, but that doesn’t change the fact that his method doesn’t say so. People do like to be right, over and above others, but that’s a different blog post.

Summary and a Question
So, now that we see that methodologies pose no danger in and of themselves, where does the impassioned debate stem from? I’ll explore that in my next post. But for now, what are your thoughts? Have you seen a formalized approach to work that contradicts the observations above? Have you found a methodology that DOES mandate following all the rules is a better approach than any other?