It’s known by several different names and it is the most used methodology 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:
- Requirements specification
- Construction (AKA or coding)
- Testing and debugging (AKA Validation)
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 at the beginning where the end product is like 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 requirements, 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 together, the development is broken up into sprints with small deliverables.
Check out our Fundamentals of Agile/Scrum courses to learn more.
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 interfere with team members ability to do work on the project.
Scrum is applicable only in certain types of environments – mainly those with co-located, 100% dedicated team members (not working of multiple projects), with unlimited support for the project team (not a heavily constrained time and materials budget).
Make no mistake, Agile & Lean ways of thinking & working are now extremely important, representing 2 very important pieces in the puzzle to help us all to cope with an increasingly VUCA (Volatile, Uncertain, Complex and Ambiguous) world where the pace of change is accelerating.
To survive, grow and prosper in such an environment ALL organizations need to become more ADAPTABLE and make the most efficient use of all resources available. To enable this, many organizations are increasingly embracing Agile & Lean values, principles & practices which is (& will continue to have) a massive impact on the way projects get delivered.
Everybody needs to be on the same page from top to bottom in the organization, and by doing this it will ensure the right & most important conversations are happening, rather than, possibly focusing attention on the wrong things which are not as important!
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.
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.
PRINCE2 is both a methodology and a de facto standard used extensively by the UK Government and is widely recognized 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.
The Kanban project work is displayed on a board (often using stickies that move across a whiteboard 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 it will affect 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 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.
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 the 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 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 donors. 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 behavioral change exhibited by secondary beneficiaries.
Since outcome mapping is more concerned about contribution than attribution, it is unlikely to be utilized in most projects.