Project Managers

The Project Management Social Network | Project Manager Jobs

I would like to hear people's opinions on how transferable methodologies are between projects... and industries. Is it adequate to understand a formal, industry-agnostic methodology for a particular project, or is each industry application so different as to neccessitate a different approach?

What are people's thoughts on this? To what extent should methodology cross industries, products, and applications - in a sense, how much good can a general methodology create? If your opinion is that certain industries or applications call for entirely seperate methodologies, from what resources have you drawn upon for assistance?

In short, how can this site function as a driver of methodology and practices for specific verticals? Any ideas or approaches you would like to see?

Views: 566

Reply to This

Replies to This Discussion

This is a good question Miles. I have a suggestion for a different way to approach it, and hopefully get some discussion going.

The way you've phrased it, you will probably only get feedback from people who have worked in two very different industries and seen GOOD project management in both. Might be rare.

Instead, how about making a separate discussion topic for each industry, starting with a solicitation for people to describe methodologies that worked well for them. Then you can look across these to identify the similarities and distinctions. It will also give you a sense for how to structure the site and guide the interaction.

Josh Nankivel
Hi Miles,

Based on my personal experience, the only "great divide" is between technical projecs and non-technical projects. I tend to use the same documentation standards and methodologies across industries and project types...except when it's a specifically technical (ie, software development) project. The whole purpose of the PMI training is to establish continuity for project managers, and I adhere to that as much as possible. However, as a side note...a rose by any other name...the documentation labels are different across industries, but if I focus on intent and content rather than the name, I'm able to get the results I'm looking for.

For example, in many of my real estate projects I work with the "Average Joe" who doesn't understand the concepts of scope documents, project charters and project plans. In those cases I call my documentation "proposals" and clarify within the text the correct title and usage.

My purpose for joining the network is to leverage other project management documents and practices as much as possible and then offer the same support as needed.

My background is corporate change management project management, but I also do pro-bono work for local charities as fund raising projects, establishing new businesses, etc. Currently I'm working on "green" real estate initiatives in our local market as the first EcoBroker (aka "green" Realtor) in East Contra Costa County in CA. I'm working with city officials to establish "green" programs, and buyers/sellers to establish a network of proivders. I'm also venturing into technical (okay, really blog and twitter..more social than technical) initiatives with several of my real estate counterparts (see my site at My "industry" is whoever needs help with a project!

Deb Miller

You raise a really interesting point about 'tech' and 'non-tech' projects, but increasingly I think the differentiation will prove to be a fasle one. And/or surely all technical projects should be driven by a clear business need (project) and business drivers?

Having done a lot of work across multiple industries (including retail, process, consumer food/beverage manufacturing, hospitals, media and entertainment, and pharma/life sciences), I can tell you from personal experience that much of what you do in one industry can translate either directly or adapted to fit the client's specific situation in another. For example, the key business processes often translate from one industry to another, especially if you are looking across various types of retailers (grocery, department stores, chain stores, etc.) and the methods you use to improve them are the same. The functions common to all companies (e.g., IT, HR, Finance, Accounting, etc.).

One of the industries with the most to gain from utilizing best practice methodologies from other industries is the hospital industry. While they may appear to be totally different (and often use that to reject ideas), transferring appropriate best practices to them can make a huge difference in financial performance, patient care, and provider relations.

There are some unique aspects to any company/industry that have to be taken into account, of course but a smart program/project manager/consultant knows how to adapt a methodology to suit the client's situation.
Whilst I do feel that it can be transferable I think that one is wise to ‘cherry pick’ after a proper analysis of the environment. Critical thinking is the key.
For example it could be said that neither PMI nor the OGC provide aspects within their frameworks for traditional business administration practice’s. Therefore in this regard it really is a tactical framework reflective of its Construction/IT origins and as such could be quite limiting a framework for some organisations.

One example of this is its failure to address strategy in its true form. What I mean by this is that strategy exits as a means to gain competitive advantage – yet no programme/portfolio framework incorporates Porters five forces (e.g barrier to entry etc) as a part of the process;

Another example is that some organizations require certain nimbleness agility for competitive advantage – thus traditional Project Management may simply be too bulky and time consuming with little value add;

In addition some organizations struggle bridging the gap between project management and support (e.g ITIL) and neither PMI nor the OGC frameworks provide a real solution for this;

Moreover the PMI’s depiction of organizational design (e.g their “Matrix’) leaves a lot to be desired in comparison to traditional business administration org. behavior and design principles; and

Complete project life cycle costing can prove a lot more complicated than is referenced within PMI/OGC material. Once again traditional business administration practices such as financial analysis (not just NPV/IRR and ROI), taxation and perhaps even economics needs to be utilized so as to ‘fill the gap’ for most industries.

In summary - despite the PMI’s push for it to be adopted by most typical organizations (ala OPM3) at the end of the day it could be stated that we have to remember that this is a framework that is developed by those in construction / IT for those in Construction/IT.

Don’t get me wrong. I do feel that it is transferable to most industries – just be sure to adapt it for your needs.
It is my experience, working in a variety of industries, that there is commonality between industries, but there is always a level of detail at which a solution becomes applicable only to one particular industry.

If we view project management as the application of the scientific method in an engineering fashion, we can see the commonality. When we talk about particular document names or the precise distribution of tasks between parties to a project, we get into the specifics that are industry- and sometimes project-specific.

What is common to project management, and what has become the de facto standard in almost all business, is the use of a scientific approach to doing anything. What we can measure, describe, define, limit, verify, we believe we can also plan, control, and predict.

We believe that we can take the large and complex and break it down into smaller and more manageable packets until we can thoroughly understand it, control it, and predict it. We then assume that plugging that pieces back together allows us to iteratively predict the outcome. Yes, I know some processes are repeated based on probability within a project (such as software development or systems integration or design), but in the end we assume some level of predictability and base our project management approach on this concept.

I am not sure that verything in the world works this way, but within the limited world we are addressing in this group I am sure that this concept is true enough to work most of the time.

Comments invited and thoughtfully considered.
Methodoligies are transferable, as easy as knowledge. You may have to tweak a few steps based on the type of industry and business culture. There are plenty of methodologies out there, because experts want recognition with their system. They all started from the same core concept of project management and evolved to serve different industries, products, applications and some of them are pure crap, in my own opinion.

The most basic methodology can be found in any graduate program, based on Joseph's Juran (a Romanian jew) that has tried to explain to US manufacturers the importance of PM and TQM (along with Deming in the 1900s). Guess what, Japan thought it was a great idea (this is where the business culture comes into play) and now they are probably the best at using the both, (PM and TQM). US manufacturers started to pay close attention to TQM and PM in the late 70s, early 80s, when we all know the japanese manufacturers started to wreck havoc on the markets with their quality and innovative products and efficient and cost cutting manufacturing techniques.

Toyota may have a specific PM methodologies, but there are plenty of other japanese models that if one can truly understand them and able to follow them, will only lead to success (but you need the business culture also). Good luck finding one (hard to get by a reputable one)

I am not sure how this site can function as a driver of methodology and practices, but it sure helps as a collaborative effort, and beats hours of searching online or through books:)

I hope this can contact me for more detailed discussions.
In general, methodology of the web-development project could be easily transferred into the game-development. I believe - pretty the same with the manufacturing, etc.
But when you look into the details - two different web-development projects may require different methodologies and this depends on project scope, client and his/her requirements to the team, process, tools etc.
So, I'm not ready to generalize the methodologies.
I'm a manufacturing guy so this might not apply to industries like retail, insurance or banking - but I find that the closer you get to the actual manufacturing process itself, the more different projects become.

Applications like accounting, order management, purchasing, shipping, etc. all have differences between industries - but they tend to be minor.

Closer to the process - applications like product configuration, recipe management, process models, material management, and the like tend to be more industry specific.

I believe managing projects, IT or not, is all about structured methods, understanding group behavior, and having the ability to lead and motivate people - but it does help to have a knowledge of the application you are working on - so at least you have an idea of what you could be missing.
Yes industries are different and yes processes can differ widely (or not so widely) across industries but the bottom line for any tech or non-tech project is that the methodology stays the same.

Only in that way, can a project manager take on any project that is thrown at them and manage them successfully with a proven methodology.

That's my belief and experience and of course, penny's worth.
Hey Miles,

Agnostic in what way? Across any kind of work efforts? -- No. Across -- cultures and industries? Yes, professional PM methodologies are totally agnostic. I have used the PMBoK in many situations and many industries over the last 25 years. As I have hinted, there is a secret.

You must come to understand and accept that a project is a process type, not a process choice. Project processes are one of four process types and they do not apply to all work situations.

There are great blended hybrids like SCRUM, which is a hybrid between Project processes and Artisan processes. Again, neither Artisan, Project or SCRUM can be applied to just any work situation.

The selection of the process is driven by 1) the relationship with the consumer; 2) the product being produced by the process; and 3) the information available to plan the process.

Once the process type is determined, the rest flows, because each process has an ideal skill set and organizational structure.

Hi Miles,
I've developed a simple visual tool, the Project Storyboard, which can be used to flexibly collect, organize, manage, and explore ideas as well as tasks in projects. The Project Storyboard can be applied across different methodologies not only in project planning and management but also in other domains.

The Project Storyboard (which I sometimes call the "Galaxy Map") can be used for visually organizing massive amounts of information such as images, topics, and videos in Internet search engine results. For an application of the Project Storyboard in the area of Internet search, please visit

I am currently writing an E-book on the Project Storyboard. I shall make this E-book freely available on the Internet. The E-book also contains an 'agnostic' framework for project planning and management. Any problem solving or project management methodology can be used within the Project Storyboard methodology. The Project Storyboard methodology also provides a simple and visual framework for using David Allen's "Getting Things Done (GTD)" methodology.

I'll keep you posted on developments.

Rod King, Ph.D.


© 2018   Created by Mike.   Powered by

Badges  |  Report an Issue  |  Terms of Service