Saturday, October 25, 2014    
   You are here : PM Topics  >  Introduction to Project Management  >  PM Methodologies
   Login    
PM Methodologies

Methodologies contain guiding processes for those who are doing project management. The true definition is that methodologies are not tool specific, however in today's softward-reliant world the reality is that the methodology and the organization's project management software tool are often heavily intertwined.

 

Below are a few of the project management methodologies popular today.

 
Agile

The Agile method tries to provide rapid, continuous delivery of product to the customer. Whereas traditional methodologies such as the Waterfall method or other linear processes require detailed requirements that are defined in the beginning where the end product is like what what defined in the beginning. With Agile there is no clearly defined end product at the onset. In Agile there is still a disciplined prioritization process, but the non-static requiremenets, flexibility, constant change, and regular communication approach this as part of the culture and process.

 

This is most commonly used in software development but the approach can also be powerful in some other types of projects as well. Some users say that practitioners must have lightweight project management processes in place in order to deliver in the short timeframes that Agile demands.

 

Instead of building the project all togehter, the development is broken up into sprints with small deliverables.

 
Waterfall

Waterfall methodology is the one that is the most used across all industries, and it is very common in software development and construction. There are many versions of the waterfall method, but the original one included these high-level phases:

  1. Requirements specification
  2. Design
  3. Construction (AKA or coding)
  4. Integration
  5. Testing and debugging (AKA Validation)
  6. Installation
  7. Maintenance

 

 
Scrum (not an acronym, but a reference to rugby)

Scrum is a type of Agile methodology that focuses around 30-day "sprints" and  monthly "scrum sessions" where project deliverables are broken down into 30-day intervals. When teams switch to scrum, those previously paralyzed by heavy "process" or difficulty in prioritizing work, can see great gains in productivity.

 

In scrum, there is no title of project manager. Instead there is a "Scrum Master" whose role is to facilitate the daily project communications and tackle any distractions that are trying to interfer with team members ability to do work on the project.

 

Scrum is applicable only in certain types of environments - mainly those with colocated, 100% dedicated team members (not working of multiple projects), with unlimited support for the project team (not a heavily constrained time and materials budget).

 
RAD (rapid applications development)

Mostly used in software development, RAD calls for the interactive use of structured techniques and prototyping to define user's requirements and design the final system. This has a cycle of models then prototypes over and over in the process.

 

Some criticism of this methodology claim that the short interactions don't allow the complex or deep functionality to be thoroughly developed. However with newer, light applications, such as development for Web 2.0 it may be coming back into favor.

 
NPI (New Product Introduction)

NPI is not really a full project management methodology, because it does not include all of the required project management steps that are needed for project success (lacking such things as development of a WBS), but it still is the process that many organizations follow for their product-related projects.

 
PER (packaged enable re-engineering)

Not a commonly referenced methodology today, but one worth noting because of its familiarity in the service and business traditional approach to project management.

Here is full 868-page paper on the methology.

 
PRINCE2

PRINCE2 is both a methodology and a de facto standard used extensively by the UK Government and is widely recognised and used in the private sector, both in the UK and internationally. This makes it quite different from the Project Management Institute's publication the Project Management Body of Knowledge (PMBOK), which is not a methodology but rather a broad collection of good practices.

 
Kanban

The Kanban project work is displayed on a board (often using stickies that move across a white board from left to right).  The benefit is the visual display of what is coming up next and it makes it easy to reprioritize. Kanban charts usually consist of general categories of projects or tasks "in queue", "in progress", and "recently completed".

 

When an executive comes in to "drop off work" they can easily be shown what work is going on and what is coming up and how dumping something new in will effect the entire group. 

 

This works particularly well for small co-located project teams. Many individuals also promote the use of personal Kanban boards.

 
Six Sigma

Six Sigma is a disciplined, data-driven product and process-improvement methodology that was originally developed by Motorola. The idea was to improve processes by eliminating defects,  which are defined as "nonconformity of a product or service to its specifications."  Those of us in project management generally do not think of it as a project management methodology.

 

The process steps go by the acronym DMAIC-S, which stands for Define, Measure, Analyze, Improve, Control, and when it is done to Synergize through the organization.

 

 
DMAIC

This is part of the Six Sigma methodology, but it also is often used as a stand-alone method. DMAIC (an abbreviation for Define, Measure, Analyze, Improve and Control) refers to a data-driven improvement cycle used for improving, optimizing and stabilizing business processes and designs. It and can be used as the framework for improvement projects outside of Six Sigma.

The framework is described briefly here:

 

Define – who are the customers and what are their needs. Define the project purpose and scope. Define the current process and what customer wants from it.
 
Measure – how is the process performing and how is it measured. Gather data on how well the current process performs in meeting customer needs
 
Analyze – what are the most important causes of problems.  Identify root causes of performance gaps and confirm with data.
 
Improve- how do we remove the causes of problems?  Plan, test, and implement solutions that eliminate root causes (use data to evaluate both the solutions and plans used to carry them out).
 
Control – how can we maintain the improvements? Maintain the gains by standardizing work methods or processes. Anticipate future improvements and preserve the lessons from this effort.

 

 

 
Outcome Mapping

Outcome mapping consists of two phases: a design phase and a record-keeping phase. During the design phase, project leaders identify metrics in terms of which records will be kept. It is most commonly used in charitable projects in developing countries funded by large donars. Outcome mapping was designed by the grant-making organization International Development Research Centre (IDRC).

It differs from traditional metrics in that it does not focus on measuring deliverables. It focuses on behavioural change exhibited by secondary beneficiaries.

Since outcome mapping is more concerned about contribution than attribution, it is unlikely to be utilized in most projects.

 
Copyright 2014 by Successful Projects