« Kanban - The Next Step in the Agile Evolution?
How to Effectively Communicate With Your Project Team »

The Wars Between Project Management Methodologies

November 6, 2009 | Author: PM Hut | Filed under: Project Management Musings

The Wars Between Project Management Methodologies
By William R. Duncan

I’ve been seeing lots of discussions lately, about “methodologies.” Most seem to have a hidden agenda … which methodology is “best”? And even more subtly … an assumption that the “best” certification will be based on the “best” methodology.

Most of the posters either miss or ignore the fact that every project involves at least two methodologies. One is product-oriented which means that it tells you how to go about figuring out what the characteristics of the product or service of your project should be. The other is project-management-oriented and tell you how to go about planning and managing the work of the project. There is obviously an interplay between the two, and a high degree of mutual interdependence, but they aren’t the same. Quite simply, a PM methodology should be either applicable to “most projects, most of the time,” or it should at least be adaptable to many types of projects.

Product-oriented methodologies may be similar at a high level, but they are specific to the product or service involved. For example, whether you are developing real estate or software, you’ll have to go from feasibility to requirements to design to construction to test to turnover. But the detail steps and the content of the artifacts produced will be vastly different.

Take a look at “agile project management.” It’s really “agile software development.” Trying to build a high-rise office building in the absence of a substantially complete design borders on willful stupidity. But that product-oriented methodology works just fine for many kinds of software projects, and even some kinds of non-software projects.

On the other hand, estimating and scheduling is pretty much the same no matter what the product or service.

My position: methodologies of both kinds are like ethical standards. I think it is absolutely vital that you have one, but there isn’t one that fits all cultures and all people. Even something as seemingly obvious as “don’t accept bribes” isn’t so obvious in practice. Just ask yourself the difference between a bribe and allowing a salesperson to buy you lunch.

Every methodology is simply a map that provides guidance. Some provide better guidance than others in some cases. No map is perfect. No map is best. And for sure, no map is a substitute for knowing the land.

Originally published at pmtip.wordpress.com

William R. Duncan is the principal of Project Management Partners of Lexington, MA USA. He currently chairs the Board of PMCert, the certification body of the American Society for Advancement of Project Management (asapm). He was the primary author of the original (1996) version of A Guide to the Project Management Body of Knowledge and was one of the founding members of the Global Alliance for Project Performance Standards (GAPPS) which has recently published a framework for performance-based competency standards for project managers.

© 2009 William R. Duncan - http://www.pmpartners.com/

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Friday, November 6th, 2009 and is filed under Project Management Musings. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 people have left comments

William, thanks for posting! Firstly: why a methodology? To use proven practice and not invent exotic standards, that lead to a dead end road. And to use a common approach within an organization, that is compatible with the managment control, project members’ (other) work and the supporting processes. Secondly: what is a good methodology? I guess it deals with providing the right results from the project’s Processes, the Product (deliverables) and People. So a product development methodology (eg. IT product) could serve as a sub-methodology for the project. When it doubt, just ask the right questions. Best regards, Primoz

Primoz Frelih, PMP wrote on November 7, 2009 - 3:48 pm | Visit Link

William, I fully agree with you.
Methodology is a BKM (best known method) which proved itself in the past, but it is not the only way we can do things.
It can give us direction, but a clever PM will know how to adjust it according to his specific project demands.

I posted few posts about change in projects which talk about it:

http://giladlsh.wordpress.com/2009/10/26/changing-the-status-quo-thoughts-about-alexander-laufer-articles/

http://giladlsh.wordpress.com/2009/09/29/projects-unexpected-change-as-a-way-of-life-for-today-pm/

Gilad

Gilad Lev-Shamur wrote on November 8, 2009 - 1:59 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories