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: 515

Reply to This

Replies to This Discussion

Hi Miles,
I am approaching your theme from a different view. I hope it is understandable and helpful.

From my point of view, it is very difficult to apply the same methodology to different projects. I co-owned a company in Brazil and we had had to build and do all installations including high tech surveillance system in two buildings. Both projects seemed so similar considering the structure plant of the buildings, the systems they were supposed to have, what they have been constructed for, and so on. But one of them was located in the south and the other one in the centre west of Brazil. That was the point. That made all difference. However, let me bring some substance to this discussion.

Methodology has been defined as a body of methods, rules, and postulates employed by a discipline: a particular procedure or set of procedures , which help us, project managers, to deliver projects. A good methodology would step us trough every phase, activity and task needed to complete the project we are involved in from start to finish.

Some authors in the engineering field try to define methodology as the use of techniques or methods with the following features:
- can be described quantitatively, as well as qualitatively;
- can be used repeatedly, each time achieving similar results;
- can be taught to others within a reasonable timeframe;
- can be applied by others with a reasonable level of success;
- achieve significantly, and consistently, better results than either other techniques, or an ad hoc approach, and
- are applicable in a relatively large percentage of cases.

Back to my example, how could we use the same methodology to what could be supposed the same project if in that case the entire environment was extremely different: the climate , the difficulties to deliver supplies due to the distance between that place and the businesses centres, the lack of good system of transportation, the absence of skilled workers, and the distance between the workplace and the main office from where the vital decisions were made.

Therefore, due to what I had experienced, it seems to me that when talking about methodology we have to watch our steps more carefully. In methodology, the power of a method is inversely proportional to its generality. I mean, the more general its use the more powerless it becomes. For example, “when in doubt, cut it off”. This habit some of us get used to, especially when we are working under pressure, it is not an effective method; it is just a quick way to think that things are again under control. However, nothing had been solved.

Hence, from what I have pointed out about the transposition of methodology from project to project all of you can take a guess on what I do believe about doing the same from industry to industry. I would be redundant by extending to that direction. What I had not said here in any sentence is that we need to throw away everything we have and for each project we start create a totally new methodology. Don’t take me wrong.

Rather than trusting only in methodology and conduct my projects based in fixed steps, I prefer the concept of thinking, the mental manipulation of information to form concepts, engage in problem solving, reason and make decisions . Thus adding both methodology and thinking I do believe we can get the perfect equation to reach the best-practice. The thinking helps us to do the necessary adjustments in the methodology; on the other hand, methodology assists us in the sense of not going so far away in our thoughts at the point of losing the origin.

In other words, the methodology help us to deal with the uncertainty bring from the internal and external environment to the project and the thinking is a counteraction or a regulatory system which help us to bring back balance (or control) to the project by covering the failures of the methodology. According to Ashby, the regulatory system has to be bigger enough to absorb all uncertainty brought into the system in order to stabilize it.

I would say that it is necessary both the ability to foresee whatever it is possible and the capacity of be flexible to change direction whenever it is needed. Be enclosed by a methodology allows the project manager to seek none of that options. When I think in a methodology I think in a description of a project management model sufficiently open to be fulfilled with needs, ideas, innovations, and to be used by people with all different background. I will not prescribe one here to you, because there exist none. What do exist are some good frameworks, I would say, to start up with and build your own.

Just to summarize and finish my ideas, if I had used the same methodology (in the common sense of the word) to do the two projects I have mentioned here certainly I would end up dead. Many problems happened in the second one which was not predictable. Just to give some flavor, the topology of the second building had nothing to do with the first one and the engineers who projected all the foundations missed that “small” detail; although the building plant was exactly the same, the particularities of the soil, weather, position of the sun and other “small” details had caused big changes in the steps of the construction. The idea of methodology simply blew out.

Best regards,

Geovania Pimenta
Project Manager and
Grad Student at University of Waterloo, ON, CA
Geovania,

I agree with you. The discipline I follow is in how I conduct the thought processes and apply the methodologies to components within the overall project. In more than 40 years of application I have not found one methodology (or guru) sufficient to cover all cases. As my experience grows it allows me to stay flexible with changing technology and environments.

The largest single variant is the people we need to interact with. If it only concerned the mechanics of the environments it would be easier to establish a “methodology.” Even in a relatively confined environment a methodology must be flexible and adjusted by a thought process. When a methodology becomes inflexible (sometimes just due to the enormity of the defined rigor and or the imposition of regulations or law), it is subject to failure. The tailoring necessary will always need to go beyond the limits of a single methodology.

The most difficult part of this to overcome is the desire of the sources of methodologies to promote themselves and to make money. Most start as an academic endeavor or a solution to a specific problem. They are successful and grow until they become enamored of themselves and their “success.” Then even with the expanding “BOK” they eventually collapse under their own weight and are replace with the next latest-and-greatest. This is fostered by those who want to publish the “new” thing and the readers (individuals) that want the latest “silver bullet). They are largest variant we need to satisfy because they fund the projects and they want to guarantee success.

If logic prevails then thought will overcome the methodology. Sponsorship needs to empower not confine. This is the risk and the challenge involved.
I have been using my own model for Process Engineering for over 30 years. I have used it in conjunction with PMI, CMM, ISO, ITIL, TQM, MBNQA, etc. It is simple and straight forward and can be applied to personal use as well as businesses (technical and non-technical)
It is an engineering discipline (some might call it a scientific method). I have applied it in IT, Aeronautical Engineering, Civil engineering, GIS, general business and other disciplines in over 2 dozen industries; in large and small organizations; to facilitate teams and to manage projects.
The only factor that varies is the syntax required to accommodate the environment. I have used it to communicate with and train: mechanics in a garage environment, construction workers, administrative assistants, manufacturing engineers, in HR, in IT, for recruiters, sales people, and even the Board of Supervisors for government entities.
Based on my experiences, the processes are very similiar if not identical. The difference is in the language and terminology used and the culture of the environment.

I have always been in a 'consultant' capacity whether in-house or working with customer projects. I have worked on projects in many different industries (healthcare, government, manufacturing, retail, telecom, hospitality -- just to name a few) and in software product development, customer software services, development, support -- US only and global. You name it, I've probably done it.

It has been relatively easy to adopt the processes and methodologies to the industry. The challenge for me has always been learning the terminology, understanding the nuances of the business drivers in each situation and, perhaps, learning the unwritten rules of the culture. My bag of 'project management tools' is always a great asset, but I think adapting to the 'soft side' is the biggest challenge.

At the PMI Global conference in Denver in October I attended two entirely different seminars on the topic of 'what makes projects fail' or 'what makes a successful project'. Although the seminars approached the topic from different directions they were in agreement that the Project Manager or methodology WAS NOT the key factor influencing success or failure. The key factor was organizational: SPONSOR SUPPORT.
My experience seems to be similar to Pat's in that I've worked as a project manager across telecom, insurance, banking, wireless, government, etc. I've worked on IT and business process re-engineering projects. I've worked in-house and as a consultant with project budgets ranging from relatively small to $50+ million.

My formal education and experiences had nothing to do with any of those industries. My initial career was as a high school English teacher. Despite that background, I have been able to successfully complete projects that industry-savvy "project managers" were not able to complete.

I believe my project successes can be boiled down to two things. First, I am a strong believer in project management methodology. I live it. Not rigid, straight-out-of-the-book methodology, but melded-to-the-situation methodology. Some industry savvy folks let their knowledge of the details pull them down into the trenches until they neither see the big picture nor the benefits of the methodology. To these people charters are viewed as unnecessary drivel, WBS outlines become terribly out of date and useless from fear of "losing the baseline", issues and risk logs are non-existent, or worst of all... communications act as a veil to cover up serious project blemishes rather than a means for the sponsors and/or stakeholders to contribute to resolutions.

Second is "soft skills". That is a really catch-all phrase, but includes such things as gaining critical support from sponsors; keeping stakeholders involved and happy; identifying the SMEs that are knowledgeable and respected and aligning with them; gaining trust so that the team will contribute to identifying issues and risks; and finding ways to add real value to all members of the team.

Every successful project I have completed (despite my complete lack of industry knowledge) re-confirms for me that both project management methodology and soft skills are universally applicable, valuable, and critical across industries.
Hi Miles

I have been working as an IT Programme and Project Manager for over 20 years and found that most methodologies get watered down to fit the industry concerned, so in essence they cross industries by default.

I have always found the basics of Project Management, Programme Management and Man Management is what delivers results and delivers the projects. I have worked in Payment Processing, Banking, Investment Banking, Travel, Manufacturing, Utilities etc and applied the same Project Management approach successfully across them all. In most cases each industry adopted a different methodology, but my management approach remained the same.

This has proven to be the case with the publication of my book (http://www.trafford.com/07-2722), I find people from all industries purchase my book and report that my management approach applies to their industry, little reference is made to methodologies. Methodologies don’t delivery projects, people do, more specifically how the people are managed.

I hope this is of value.

Regards
Ian
Attachments:
My opinion has been that the methodologies for project management can cross any boundary. I have used the same methods in the military, engineering, information technology, and holiday party planning. In either situation I used the same methodology and successfully went through the lifecycle.

The differences I've found is more in the approach. For example, not all projects needed the earned values calculated. Some businesses wanted it some didn't. It's like this, the content might be different but the framework should be the same.

Make sense?
My experience tells me that there is no simple answer. There are many aspects of a methodology (particularly a PM methodology as opposed to a specific performance domain methodology like an SDLC) that are transferable across industries and domains. For example issues management and change management procedures cvary more with size of project than vertical industry or domain. On the other hand, it is not sufficient to to only understand an industry agnostic methodology. The practitioner should deeply understand the specific methodology he or she is working with and see how it relates to more generic models.
Though I have real life experience in only one field, I think there are rather principles than methodologies that could be applied to different projects in different areas.
For me, a methodology tell me how do to a certain thing. A principle helps me to identify what to do in order for my project to succeed.
So, the principles would be the most important, because help you have a clear view of what to do. After having a clear understanding of the path to take in order to reach your goal, methodologies could greatly help in moving faster and better to the goal.
Daniel,

We are dealing with semantics.
The process of applying "principles" in a rigorous, repeatable and disciplined manner is a methodology. There are many variations of this definition with several nuances; however, this is applicable and sufficient for this discussion.

What I promote is a core methodology (based on a few logical concepts and simple graphical representation) that allows thought processes to intelligently use other methods and disciplines is needed to drive results. It can be applied to a problem or set of problems in order to discover the most appropriate vector that leads to a successful solution. The set of methods driven by the core methodology can be varied by the environment, technologies and industry involved in the project being addressed. The key is for everyone to know and understand the core methodology (process) in order to facilitate communication. Numerous methodologies and "best Practices" are espoused/sold without a clear understanding of how they can be adapted to changing criteria. A core methodology or discipline is the key to understanding.

The solution may or may not be the best depending on numerous variables; however it allows for self-correction based on feedback. As with any methodology; the primary determining factor of success is in the skills of the practitioners, including the stakeholders that are requesting the results.

Biases toward any single set of tools or the limitations they dictate, will inhibit success over time and with variation of the criteria involved.
Beside the well known general definition (task-timeline-budget-quality) all projects have common charachteristics (well known as well) which i would like to underline as main for the project success: 1. Sourcing (as the participants in the project are a temporay team, quickly built, a very important role has the selection of the correct members for the corresponding positions in a well prepared org chart with reduced number of vertical and horizontal connections and resource plan precalculating part and full time activity and shared functions, further - maintenance of motivation, risk readiness, soft amd permanent controlling of their activity, beside reporting). 2. Outsourcing - again the correct selection of the general and subcontractors and control (not soft) of their performance, preferably on a team level and a half daily basis.3. Good organized procurement (materials and equipment). 4. Payment plan, change order, bonus and penalty system allowing permanent performance and efficient results control.
The project success is depending on the quality of the selected ones, which is a result of the quality of work of the selectors.

Georgi Krastev
The methods are the same and univrsally transferable, IMO. On the technology changes. For example, I just witnessed some smart people tranfer their Enterprise Architecture managm

RSS

© 2018   Created by Mike.   Powered by

Badges  |  Report an Issue  |  Terms of Service