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?
Hi Jesse, love your post and can’t wait to read the next one.
Two short questions:
- With leaving room or even the necessity to tailor the process an even bigger challenge is created: how to tailor? In which situation what to apply. How do you see this challenge?
- With Scrum a lot of advice is geared to the fact that you have to apply all rules otherwise it gets useless. I am very interested on your take on that.
Personally, I almost am to the point I almost say that it doesn’t care which approach you apply, as long as everyone (emphasis) is using the same one.
BTW Have a fab Christmas and looking forward to speaking you also in the new year
Cheers
Bas
Thanks for your comment, Bas.
1) With regards to how-to-tailor, I’ve started advocating a simple 4-step approach: (1) start with what’s easiest, (2) Deliver early & often, (3) inspect & adapt, (4) go back to step (2). I presented on this at the P2P conference in Cairo, and will post on it very very soon.
2) Yes, most Scrum advocates will warn that it is an all-or-nothing “project framework”. However, I find disagreement among trainers and coaches as to what parts are fixed and which are flexible. Is your daily standup meeting broken if the team chooses to have some dialog? Is your team dysfunctional if they deliver more often than at the end of the iteration/sprint? What if the team chooses to have a retrospective only every other Sprint? It turns out some things in Scrum are more flexible than either the Scrum Guide or the trainers initially let on. HOWEVER, you should not assume you know HOW to tailor a methodology like Scrum, until you have completed steps (1) and (2) fully and completely…that is where the danger lies.
Agree – with proviso that you take a methodology and USE it – adapt & adopt.
Also have a look my take on the subject…
http://blogs.oracle.com/asparks/2008/10/have_i_got_a_methodology_for_y.html
Good post. I like the phrase “Adopt & Adapt”. However, I must confess I had to roll my eyes when reading about the Oracle Unified Method. The irony is that even if no one productized methodology is best-of-all, project managers are still consumers quickly drawn to such products.
Excellent post Jesse.
Your 4-step approach reminds me of Deming’s Plan-Do-Check-Act cycle and from what I can tell, just about all successful approaches model this in some way.
As with anything, it’s very helpful to start with a theory. A model by which you can start to implement and then modify as you find out what does and does not work in your organization, with your team, and with yourself.
“Rational behavior requires theory. Reactive behavior requires only reflex action.” — W. Edwards Deming
To me, the problem comes when people interpret whatever theory they are following as “the literal truth” and deviations are seen as forbidden. We need to stop worrying about things like “can we call it Scrum anymore if we change this?” and focus on the ROI of that change to the system we work in.
Josh Nankivel
pmStudent.com
Totally agree, Josh. The recent debates about ScrumBut (“we do Scrum, but we don’t do daily standups”) have left many teams focusing on the letter of the methodology, and forgetting to address the organizational issues Scrum is designed to surface.
Many experts present Scrum as absolute truth, but Scrum itself encourages context-specific improvement. PMI promotes the PMBOK as an international standard, but the document merely calls itself a guide. Perhaps our methodologies are pointing to the ancient cliche: “the only aboslute truth in project management is that nothing is absolute.”
Great post! I have stopped participating in many discussion because of this crazy stuff! Many are so stuck in using just one but we have so many! Pick and choose what works for the present project at the present moment. No process is perfect in every way!
Don’t give up on the dialog yet, Kimba. I know the debates can get frustrating at times, but that’s all the more reason the more level-headed down-to-earth thought leaders like yourself are needed.
You nailed it Jesse. I always preached “do whatever suits you well” approach to methodologies which basically comes down to choosing right tools for right situation, no matter how you label them. After all you don’t get points for being 100% Scrum but for successful delivery of your projects.
There’s no such thing as silver bullet and project management isn’t any different here. If someone says so, he either tries to sell you something or he’s very naive.
I agree with your point. However, it’s worth noting that not all the blame lies with methodology experts. I wonder why it is that so many of us fall for the silver bullet. In our heads, we know there’s no easy answer or quick shortcut to successful management…but yet we still spend millions on bootcamps, certifications, and process improvement rollouts. Yes, it is appropriate to call out the naive salesmen as you suggest, but only as a means to an end. My mission is to help project managers around the world choose the higher road. If we can inspire others to do the hard work of surfacing roadblocks and thinking through alternatives, then we’ve done something worthwhile.
Pingback: WUPM #5 – Methodology, What Makes a Good PM and more… | What's up in Project Management
That’s by the way something worth further discussion – why so few people takes some time to learn about things they use everyday at work. Sometimes I feel like we reach a teeny slice of audience we should. The problem isn’t any longer about valuable sources to learn from – there are plenty of them. It’s just about people don’t feel need to get better at what they do. And that’s sad.
After all, how much more smooth our project would go if everyone would take some time to unwind themselves.
I can say that debates among different methodologies advocates are useless, people spend long time before adopting one methodology and once they believe it they defend it blindly! the reason the debate is useless is that “if I believe in the other methodology why wouldn’t I adopt it!”.
I believe no one completely adheres to a methodology, people look for a framework not methodology, a framework is more practical, and easy to understand, while methodologies are always speaking about building sand castles!
I think we should start focusing on the outcome rather than how to reach to the outcome, everyone should pick what works for him, no harm in trying different methodologies and even merge different ones to form a new one!
Bottom line, no methodology is wrong no methodology is right!
Kareem, I appreciate your passion. Indeed, many people get stuck on their favorite rule book for doing things. But I wonder what would you consider to be the difference between a “framework” and a “methodology”? Scrum calls itself a framework, but meets the criteria of a methodology above. PMBOK calls itself a “Guide” but also fits the definition. I contend that the terms are not the key issue, but rather the connotations, the baggage that those terms carry. This is what I’ll explore in the next post…
Pingback: The Real Reasons Behind the Methodology Wars
Jesse,
Thanks for the thought stimulation. I’ve come to understand over recent years that the notion of starting with a method is seriously flawed.
Here’s an idea I’ve started to champion
http://herdingcats.typepad.com/my_weblog/2010/01/does-methodology-matter.html
Glen, thanks for the follow-up post. Your 5 questions help us draw up some common-sense, real-world definitions for cost, schedule, scope, and risk. Good stuff.
But hang on… the one (possibly the only) outstanding advantage of using a methodology is that of interchangeability. If your party and other parties on a project are all participating in a particular methodology, then you have an element of interchangeability as a platform – or a language – with which to understand the motions and actions and things that you do, between you and the other parties. It’s simply a means – a handy externalised procedural vocabulary – to get all your ducks singing from the same hymn-sheet. Other than that, the more one sticks to methodologies rigidly, the less they’ll ever evolve into more suitable methodologies, and hopefully, more transparent and invisible methodologies.
Ian, this post is focused on the uselessness of debating method A over method B. However, I do agree with the point you’re making. At some point, you need to start with something. Even if it’s just the 5 questions that Glen offers in his post below, a project team needs some common set of expectations to start with. Specifically, my next post will reveal my own take on the debate between consistency and flexibility. Stay tuned…
Pingback: 4 Simple Steps For Tailoring Your Methodology
I wrote an article about this in 08. Below is an excerpt and the full article can be viewed here http://sebasolutions.com/dev/newsletter/?id=16&PHPSESSID=c6eed6e50132f74c6edacaf81a1bc4c6
One of the greatest debates in project management is what is the best project management methodology? There are numerous articles and books touting particular methodologies. Each usually talks about the deficiencies of other methodologies and uses some version of the high failure rate of projects to meet cost, schedule and scope targets to prove their point. Some methodologies are overtly or covertly backed by vendors and consultants selling software and/or services related to the methodology. I have come across no credible proof of one methodology outperforming another methodology. I hope the following isn’t a news flash…
The methodology isn’t the primary factor of success. It is the leadership!
James, ditto on your excerpt! I would add the problem isn’t solely with vendors or consultants advancing their productized set of practices. Instead, I would lay equal blame to project managers who adopt these methodology products towards blind compliance. To your point, the reason we take refuge in the rules of a given methodology is that we are afraid to lead. If a stakeholder complains about our deliverable, we believe for some reason that being process-compliant will bail us out. It took me a few failed projects to realize that myself. I wonder how we can help other PMs learn it an easier way.
Pingback: Does methology matter for Cottage PM? « CottagePM.com
Pingback: Does methodology matter for Cottage PM? « CottagePM.com