Category: PM Methodologies

If you’re discovering potential project management methodologies for a new project, you might’ve come across a lot of project management jargon. If you aren’t already familiar with them, terms like the waterfall, scrum, agile, lean, and kanban methodologies aren’t immediately digestible. 

This guide is all about explaining one of these terms: the waterfall methodology, also known as the waterfall model. If you’re interested in learning more about this project management method, and whether it suits your project goals or not, you’re at the right place. 

Try The best PM software for waterfall methodology

Best Project Management Software for Waterfall Methodology

• Monday.com
• Wrike
• Smartsheet

Historical Overview of the Waterfall Methodology

The waterfall methodology is the oldest project management procedure out there. Construction and manufacturing firms have traditionally used similar management methods albeit it was not formally recognized until Dr. Winston Royce introduced the idea. 

He developed the waterfall management approach in 1970 to manage the development of large software. Though the term ‘waterfall’ still wasn’t linked to it, it was Dr. Royce’s design that later came to be known as the waterfall model. 

The step-by-step approach helped it gain support from managers quickly, making it the most widely used management methodology. Since then, waterfall project management has been a popular choice, especially for software development projects and other relatively sequential fields of work. 

The waterfall model is named so because it mimics a waterfall in its trajectory. Just like water flows down in one direction, your operations will flow from one step to the next. The flowing water cannot take a u-turn and flow back to a point it has already passed from. Similarly, this management method doesn’t allow you to return to previous phases. The only way to do so is to start over from the beginning. 

Principles of the Waterfall Methodology 

Every management process follows a set of principles. If you’re confused about whether or not the waterfall model suits your operations, we recommend you review the principles it follows. The right project management model should follow the same principles as you want for your project. 

Here are the three basic principles the waterfall project management methodology goes by. 

• Sequential structure: The waterfall model divides your operations into sequential phases. You can only move to the next stage in your project once the current one is complete. This also means there’s no space for changing course or revisiting a phase after its completion. The only way to go back is to start all over again.

• Minimal customer involvement: A waterfall project involves minimal customer interaction. This is primarily due to the fact that operations only start after the customer’s requirements and objectives are clearly defined. The first meeting takes place before operations begin and the next when the project is in its final stages. 

• Robust documentation: This methodology also involves in-detail documentation of all requirements, the development process, and the final outcome. This includes everything from the timeline to the precise route you will take to solve the client’s problems. Since there’s minimal to no customer communication during the development process, every essential detail needs to be documented upfront. 

If these principles are in-line with the project you’re planning, the waterfall model is indeed a suitable option. Let’s dive deeper to discover the different phases involved in the waterfall system development cycle. 

5 Stages of the Waterfall Model – Software Development Cycle

Waterfall usually breaks down a project into five to seven distinct phases. The stages, also known as the waterfall software development cycle for software development projects, are strictly chronological. Each phase has a fixed timeline, requirements, and objectives. 

Although most waterfall systems have five project management stages, more complicated plans have more stages in their development process. Here is what a typical waterfall model looks like:

Here’s an in-depth look at each of these phases and what each one entails. Oftentimes, a single phase can involve multiple subsections, but everything is part of the plan taking on one task at a time. 

Stage 1: Documenting Requirements

The waterfall model calls for extensive documentation upfront. In the first stage, you gather information from clients or end-users regarding their requirements and the results they expect from the software or product. 

This is a planning phase and is the last one where you can communicate with clients before work starts on the project. You want to document as much information as you can to make sure you take off in the right direction and have everything mapped out. 

The requirements phase is crucial since it lays the foundation for the next phases. This is also why a lot of time is allocated to gathering requirements. By the end of stage one, you should be able to describe each of the upcoming phases in detail. This includes timelines, costs, risks, assumptions, and dependencies of the project.

Stage 2: Design

The second stage, also known as the analysis stage, is when you review the requirements and develop a design to meet them. Here, your team identifies the path it will take to deliver a solution and the relevant specifications. 

The second stage is often divided into two parts: the logical design and the physical design stage. In logical or high-level design subphase, you will come up with all theoretical solutions that have the potential to meet the client’s objectives. 

Physical design, also known as the low-level design, entails more concrete specifications. This is where you specify the hardware, software, architecture, data sources, and services you will be employing during the project. Note that no on-ground work or coding takes place in this stage. 

Stage 3: Implementation

This is where the action starts. The implementation phase is where the construction or coding, in the case of software development projects, happens. But this might be the shortest stage of all since the entire design is already in place. Your team will follow the documentation from the first two phases to flesh out the actual deliverable.

More complex projects break down large software into smaller programs. Teams employ unit testing where they build and test one unit at a time which is later merged together for the final product. 

Stage 4: Verification

After the implementation phase is complete, the testing or verification stage is where you make sure all requirements are met and whether the product needs debugging. Here, the quality assurance team thoroughly scans the deliverable before it reaches the client. 

In case they find major faults or the requirements are not met, the project goes back to stage one. However, a forced repeat of the design phase takes care of minor bugs. 

You can also utilize a UAT (user acceptance test) for clients or end-users to check for faults and user experience. In case the product passes testing and verification, we move on in the waterfall.

Stage 5: Maintenance

The maintenance stage starts after you release the product and users start using it. You can only identify some issues once the client brings the deliverable to practical use. In case a bug or faulty feature arises, your maintenance team can take care of it. This stage ends when the client is fully satisfied or continues in case they need frequent updates. 

When to Use Waterfall Methodology

The extensive documentation and painstaking planning in the initial stages are two of the best features of the waterfall model. They make sure your time and money are invested right. However, its inflexibility gives you limited space to revise your plans. 

Different projects have different circumstances and requirements. Let’s take a look at some instances where a waterfall system would make a great choice. 

• Project has clearly defined requirements: If you’re clear about the ultimate objective you want to achieve with a project, go for waterfall management. However, if you or your clients are not sure about the end goal, have ambiguous requirements, and may change course, go for agile project management.

• Project has firmly set tasks and deadlines: The waterfall model is highly structured by nature. It’s best for projects in the construction or manufacturing industry where you need to maintain deadlines. This is a rigid management methodology for rigid businesses where meeting deadlines is a must.

• You have time for planning: A considerable amount of time is spent in the first two stages when you use waterfall management. You can go for waterfall if you have ample time to spend on gathering requirements and planning. But if you’re short on time and need to start right away, an agile methodology is a better option.

Pros and Cons of Waterfall Methodologies 

Every project development methodology has its pros and cons. Similarly, the waterfall method has its own which makes it suitable for some projects and unsuitable for others. 

Its straightforward approach and the robust documentation involved are two of the best things about it. On the other hand, the inability to adapt to change is its greatest weakness. 

Advantages of the Waterfall Method

• In-depth analysis and design phases make sure the implementation follows the correct route. This helps your team take all the right steps and finish the implementation phase quickly.
• The waterfall method gives an accurate estimate of the total cost and time required for a project.
• It’s easier to evaluate progress since the model has a highly structured approach and defined milestones.
• This methodology lets you create repeatable processes. This means new team members can easily get familiarized with the project as everything they need to know is already documented.
• Limited customer involvement means customers aren’t adding new suggestions or requirements. This helps you avoid delays and reach completion according to the set timeline.

Disadvantages of the Waterfall Method

• The waterfall management model assumes all requirements can be enlisted at once, but this is not always the case. This incurs higher costs if a client requests an additional requirement midway through the development process.
• Since requirements and design planning take up a lot of time, projects can take longer to reach completion.
• Limited communication with the clients during design and implementation.
• If one stage gets delayed, all subsequent stages are delayed.
• Doesn’t allow processes to overlap, hence reducing efficiency.
• A working deliverable isn’t available until the final stages.

Final Thoughts on Waterfall Methodologies

The waterfall methodology is simple, sequential, and easy to apply. It’s most commonly used for software development and construction projects where you need to finalize one phase before you move to the next. 

That said, this project management method lacks flexibility and involves high risk when it comes to complicated projects. It’s a suitable option only if you’re working on a shorter project with clearly defined requirements, and enough time for planning. If you think the waterfall isn’t for you, feel free to discover other project management methodologies to get off on the right foot.

Agile project management (APM) is a project philosophy that breaks projects down into iterations or sprints. The purpose is to produce bigger ROI, regular interactions with clients and end-users, and improved delivery of product features. 

Today, Agile is used in virtually every industry from software development to real estate. Keep reading to learn more about Agile project management, how it can help projects succeed, and the different project management software that uses Agile today.

Key Takeaways: Agile Project Management

• Agile project management (APM) offers a flexible and innovative approach to managing projects by breaking them down into sprints.
• Agile projects help reduce risk and improve overall product quality by encouraging feedback at each stage of the process.
• In 2001, Agile was started by a group of 17 software engineers who created the Agile Manifesto, a set of values and principles that govern Agile.
• Agile project management has produced seven frameworks. They are Kanban, Scrum, Crystal, Lean, FDD, Extreme Programming, and the Dynamic System Development Method (DSDM).
• Of the seven Agile frameworks, Kanban and Scrum are the most widely used.

What Is Agile Project Management?

Agile project management (APM) is a project management method that divides work into sprints to help reduce risk and improve overall product quality with an open feedback loop between the project owner, team members, and customer. 

Definition of APM

Used by product owners and managers worldwide, Agile project management offers a flexible and innovative approach to managing a project by breaking the project down into stages, also known as sprints. It is considered a flexible, iterative design and build process that does not rely on a pre-planned process, executed as the situation demands.

One major difference between the Agile framework and Agile workflow versus other methodologies is in its approach to adaptability to build projects and manage projects. Other project management methods conduct all planning before the project starts.

On the other hand, Agile project management methods rely on an iterative nature that accepts changes mid-way throughout the process with a face-to-face conversation between the project manager, scrum team, and clients. 

How Does Agile Project Management Work?

In a typical Agile development cycle, there are several small cycles or sprints. Each phase contributes to project completion and comprises a product and sprint backlog. A sprint backlog consists of a list of tasks to be completed, revolving around planning, design, testing, and release. With every sprint, new features are added to each product.

According to VersionOne’s 13th Annual State of Agile Report, “97 percent of respondents reported that their organizations use Agile development methods—up from 80 percent in 2011”.

History of Agile 

The earliest instances of Agile occurred around 1913, starting with Ford’s first Michigan automotive plant that reinvented the process of manufacturing with the first moving assembly line. The line assembled an entire vehicle from scratch, cutting the time spent building a car from half a day to less than two hours.

In the late 1970s with the advent of personal computers, consumer demand for electronic products hit an all-time high. This spurred the demand for effective project management systems for a customer’s competitive advantage. However, it continued to see a disparity between the client’s requirements and delivered projects with a nod to creating comprehensive documentation over client satisfaction.

In 2001, a group of 17 software developers led by Martin Fowler and Jim Highsmith created the Agile Manifesto, a document that drilled down four key values and Agile processes essential to project management and Agile projects.

In addition to the four key values, there were 12 additional principles based on customer satisfaction, streamlined delivery of the final product, dividing the project into sprints, and other Agile development methods its founders thought were critical towards completing a project.

Today, there are seven different Agile project management methodologies born out of Agile project management, which include Kanban, Scrum, Crystal, Lean, FDD, Extreme Programming, and the Dynamic System Development Method (DSDM) based on Rapid Application Development (RAD).

Why Choose Agile Project Management?

There are four major reasons for managing projects using Agile:

1. High product quality.
2. High customer satisfaction.
3. Reduced risk.
4. Better and faster ROI.

High Product Quality

One of the major reasons for choosing Agile project management over other methodologies is high product quality. High product quality takes into account demands by all stakeholders. Regular quality control testing is done throughout the project development process.

High Customer Satisfaction

High customer satisfaction is another reason to choose Agile project management over other methodologies. This high customer satisfaction refers to periodic updates made to each customer, continuous and fast delivery of each sprint, and accepting change requests by the customer.

Reduced Risk

Using the Agile methodology in any project reduces the risk of exceeding budget and surpassing a deadline. This is done with improved communication between the project owner, stakeholders (developers), and the client. There are daily or weekly scrum meetings that have each team member asking what they have achieved since the last meeting.

Agile also encourages proper risk assessment and response. For example, many software development teams classified risk by assigning a value to each risk to determine which ones to prioritize. These are known as risk burndown charts or risk probability and impact matrices. There are also different response strategies depending on the risk, such as avoidance, exploitation, transfer/sharing, mitigating/enhancing, and accepting.

With Agile methodologies, collecting feedback early on and incorporating quality assurance testing throughout the project all contribute to reduced risk.

Better and Faster ROI

One of the biggest benefits of an Agile approach is turning in a better and faster ROI for all types of projects, including software development projects. A reason for this is due to Agile’s iterative process, where the first iteration or sprint can offer new functionality that increases ROI. This is in contrast to waiting until the end of the project to introduce a new feature.

In an Agile environment, better ROI also extends to reduced costs, defects and delays. Spring cycles make it easy to identify and repair defects before they make it onto production.

Principles and Values of Agile Project Management

According to the Agile Manifesto, the four key values for Agile management are:

• Individuals and interactions over processes and tools.
• A working product is more important than comprehensive documentation.
• Customer collaboration comes before contract negotiation.
• Responding to change is preferred over following a plan.

Agile project management focuses on the importance of client communication and keeping the customer involved in all project phases. This is in stark contrast to the Waterfall development method that allows customers to provide feedback before and after work is completed.

Read: Waterfall vs Agile Methodology: What’s Better for Your Project?

Agile processes harness change, and unforeseen circumstances could include a revision to the final project scope, demand for extra features, and other customer-led feedback that alters time, cost, and resources.

Popular Agile methodologies adhere to the following 12 principles:

• Customer satisfaction through continuous delivery of the product.
• Divide large chunks of work into smaller and achievable tasks for quicker completion and easier integration of changes.
• Adhere to the decided timeframe for the delivery of a working product.
• Stakeholders must collaborate frequently to make sure the project is moving in the right direction.
• Create a supportive environment to motivate team members and encourage them to get the job done.
• Prefer face-to-face communication over other methods.
• Working software is the primary measure of progress.
• Try to maintain a constant pace indefinitely for development.
• Maintain the quality of the product by paying attention to details, leading to technical excellence.
• Maintain simplicity.
• Promote self-organization in the team.
• Regularly reflect on your performance for continuous improvement.

All of these project management Agile principles pay a nod to disciplined Agile delivery over traditional project management methods, dividing large volumes of work into smaller, manageable chunks, and getting buy-in from all stakeholders. It also believes in a customer-centric approach that demands face-to-face communication and gives team members a platform to speak on proposed changes.

Despite the changes to work, the goal continues to be producing all final deliverables, as evident by its “working software is the primary measure of progress” principle.

Lastly, a key Agile methodology principle is continuous improvement through iteration, where all mistakes are recognized and learned from. Many project managers may decide to engage team members in one-on-one or group sessions for this purpose.

6 Phases of Agile Project Management

The six phases/stages of Agile project management are:

1. Concept.
2. Inception.
3. Iteration.
4. Release.
5. Maintenance. 
6. Retirement.

Concept

The Concept phase of Agile project management refers to determining project scope. In this stage, the product owner discusses all requirements and deliverables with the client, prioritizing a list of features in order of most to least important. All time, resources, and costs are factored in with a thorough and detailed analysis.

Inception

Inception in Agile project management refers to assembling the right development team to proceed. Team members will be identified and given all the tools and resources added to start the design process. The design process can incorporate mock-ups and light sketches of product infrastructure, taking input from the product owner, team members, and client. Consider this stage the brainstorming section.

Iteration

Iteration is the longest phase in Agile project management. The first iteration or sprint will produce a bare-bones foundation, whereas future iterations will focus on additional features and improvements. Remember, the goal of Agile product development is to conduct work in short cycles or sprints, with each sprint allowing enough time to gather feedback, assess new risks, and guide future iterations.

Release

Release in Agile project management refers to quality assurance. All checks are in place to evaluate the product and check for bugs, defects, and effective code. During this stage, developers are hard at work clearing out bugs and creating documentation and user training. Once the release stage is complete, the product’s final iteration can be released to the wild.

Maintenance

Maintenance is the critical stage where the product is fully available to customers by a development team and self-organizing teams. During this time, all product end-users are engaged with incoming documentation and user training by product builders. With Agile methodology demanding a dynamic systems development method, new iterations may often occur to upgrade the existing product for early and continuous delivery.

Retirement

In Agile project management, retirement refers to the time a product becomes expired, soon to be replaced with new software, or phased out altogether due to new business demands, a lack of sustainable development, increased competition, etc. These result in “end-of-life”: activities by developments, including withdrawing all support and notifying end-users the product is no longer available.

APM Methodologies

One of the benefits of Agile is its flexibility. Five popular Agile methodologies or frameworks used in Agile project management are:

• Scrum.
• Kanban. 
• Extreme Programming. 
• Lean Development
• Crystal. 

All of these Agile methods and Agile project management practices have their own strengths and weaknesses connected with sprint planning and the composition of software teams.

Scrum

Scrum is a visual way of managing projects that groups tasks into columns based on progress. The technique helps teams work together and adapt to changes and problems by breaking the project up into chunks — these tasks are then worked on in sprints. With feature driven development, this allows only one sprint to be planned and managed at a time.

Kanban

Another one of the key benefits of Agile is powerful visualization tools. Kanban is a highly visual representation of projects that allows users to create a Kanban board and label tasks and subtasks into three key categories: “to do,” “doing,” and “completed.” Many popular project management tools like ClickUp and monday.com feature Kanban boards that use intuitive drag and drop functionalities to project cards. Consider the Kanban board a preferred choice for Agile team visual learners and designers.

Unlike Scrum’s Agile methodology, sprints are not planned and managed one at a time, but collectively.

Extreme Programming

Also referred to as XP, this framework works similar to Scrum but incorporates 12 supporting Agile approaches that are software-centric, which include:

• Planning games.
• Small releases.
• Customer acceptance tests.
• Simple design.
• Pair programming.
• Test-driven development.
• Refactoring.
• Continuous integration.
• Collective code ownership.
• Coding standards.
• Metaphor.
• Sustainable pace.

Lean Development

Lean development shares some of the same Agile project management methodologies as Agile with newer principles that include the following:

• Eliminating waste.
• Build quality in.
• Create knowledge.
• Defer commitment.
• Deliver fast.
• Respect people.
• Optimize the whole.

Crystal

Started by Alistair Cockburn, one of the original Manifesto authors, for a 1991 IBM project, Crystal is an Agile project management process that focuses on individuals and interactions, not processes and tools.

It is based on two beliefs:

• Teams can find ways on their own to improve and optimize their workflows.
• Every project is unique and always changing, which is why that project’s team is best suited to determine how it will tackle the work.

Some family members of the Crystal methodology include Crystal Clear, Crystal Yellow, Crystal Orange, and Crystal Red.

Final Thoughts on Agile Project Management

There are many APM projects that can be used. Some notable types of projects include small to large software development, product development, and virtually any business where the deliverable can be produced in incremental sprints. Consider Agile even valid for opening up a new book store or upgrading a new franchise location.

Remember, all products could benefit from feature-driven software development thanks to collaborative working, shorter development cycles, and Agile practices. All of this can be achieved with improved communication between project owners/developers/clients, more frequent reviews, two-way communication, and a more collaborative work environment that values feedback.

To become proficient in Agile Development methodologies, there are several certifications available. Some of the more notable ones include PMI Agile Certified Practitioner (PMI-ACP) and the APMG International Agile Project Management certification. Both require a secondary degree and several hours of Agile training in addition to thousands of hours of general experience on project teams. With heavy study and real-world experience, these certifications enable you to become a scrum master.

Anyone working on Agile teams or looking to understand and use Agile principles in project management is encouraged to obtain PMI Agile Certified Practitioner (PMI-ACP) or APMG International Agile Project Management certification. Many members of teams work with these certifications on hand.

In the last two decades, software development has undergone an Agile transformation because of the many benefits like improved quality and predictability across projects. Agile methods have become the standard in many contexts, using small, self-directed teams to create a product in short order. In this article, we’re going to cover the basics of the Agile methodologies and discuss when it might be appropriate to adopt one for your own project.

Key Takeaways: Agile Methodology

• Agile methodology focuses on key ideas, like producing working software and an iterative development process.
• Agile teams are usually smaller, working on smaller projects.
• While many methods are older, Agile was defined in the Agile Manifesto in 2001.
• The Agile Manifesto included four values and 12 principles.
• There are many Agile methods, with different advantages.
• Some Agile approaches can be scaled to larger teams and projects.
• Before Agile, project management used traditional or waterfall methods.

Historical Overview of Agile Methodology

The modern approach to project management is considered to have developed during the Cold War, as project managers brought together existing ideas and added their own. Many concepts that are now thought of as Agile actually have their roots much further back, in that early era of project management. 

An Alternative Approach to Project Management

Early project management focused on large projects that required tight organization. The methods developed, now thought of as waterfall or traditional approaches, reflect those strict needs. However, even in that era, people were finding faults with waterfall methodologies.

Read: Waterfall vs Agile Methodology: What’s Better for Your Project?

Core Agile concepts, such as iterative and incremental development, have been in use at least since the 1970s. The concept of customer collaboration, as well as a focus on products rather than documentation, can also be found in use in the 70s.

Lightweight Software Development

As computers got smaller and more powerful, small groups began developing software in a volatile business environment. Things came to a head during the computer boom of the 1990s when many Agile methods were developed. Examples include:

• Extreme programming.
• Scrum.
• Rapid Application Development.
• Crystal methods.
• Dynamic Systems Development.

While each of these project management methodologies software are now considered examples of Agile development, at the time they were instead called “lightweight”. All were created in the context of software development and were considered suited only for small teams and projects.

The Age of Agile

In 2001, 17 project managers and software developers met. Each was a leader in a different type of Agile software development, including extreme programming, scrum, adaptive software development, and others already mentioned. 

Together, they wrote the Agile Manifesto, a brief document that outlines the values and principles behind Agile methodology. Doing so rebranded their areas of expertise as Agile, a name that implied an ability to manage to change circumstances.

What Is the Agile Manifesto?

The Agile Manifesto is the defining document of Agile project management. The values and principles found in the manifesto are less a formal methodology than guiding principles. It doesn’t define project management phases, for example, but instead questions whether they’re worth worrying about.

As mentioned, the concepts in the Agile Manifesto are expressed in four values and 12 principles. The four values include:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

The 12 principles of Agile project management are:

1. The highest priority is meeting customer needs, achieved through early and continuous delivery of valuable software.
2. Accept changing requirements throughout development. Agile methodology uses change to the customer’s competitive advantage.
3. Deliver working software frequently throughout the project lifecycle, the sooner the better.
4. Agile teams should include developers, business people, and other stakeholders.
5. Give motivated individuals the resources and support they need. Then, trust them to produce high-quality software.
6. The most effective way to communicate, within the team or otherwise, is a face-to-face meeting.
7. Working software is the primary method of judging progress.
8. Agile aims to be sustainable, so that the pace of work could be continued indefinitely.
9. A focus on continuous improvement and technical excellence improves agility.
10. Keeps things simple by maximizing the amount of ‘work not done.’
11. The best results arise from self-organizing teams.
12. Iterative development means the team meets and reflects on how to become more effective, then adjusts its behavior accordingly.

Both these values and principles are also used in large projects with multiple teams, using tools like the Scaled Agile Framework to contain what could be a hectic methodology.

7 Different Types of Agile Methodologies

As important as the values and principles are, it’s not straightforward to apply them to the project management process. Additionally, the manifesto doesn’t offer a single, formal Agile definition that can be generalized. Instead, there is a collection of methods that are considered Agile software development.

The seven on our list are some of the most common, though there are other Agile methodologies out there, including many specialized methods. Additionally, variations like Disciplined Scrum and Scaled Agile Frameworks can be used with larger projects.

Scrum: Sprint Through Software Development Projects

Perhaps the most popular Agile framework, Scrum methodology outlines how to manage an iterative process in constantly changing circumstances. The development process is broken up into sprints, before which tasks are broken down and assigned during Sprint Planning.

Planning includes the entire scrum team. In a traditional process, the bulk of the manager’s time is spent assigning tasks and following up. The team takes care of that in Scrum, so the manager instead becomes the Scrum Master. Their role is more of a facilitator, rather than a manager.

The Product Owner acts as a representative for the customer. They are the only person able to add additional features or requirements throughout the project. They do so using a list called a product backlog, which includes the tasks to be completed in each sprint. After each sprint, the development team meets once more to assess how work went. 

Key Principles:

• Small working teams maximize communication and informal information sharing, while minimizing overhead.
• Adapting to the technical requirements or marketplace ensures the best possible product.
• Work focuses on executables that can be tested, documented, and built upon as the project progresses. 
• Partition the work assignments into discrete packets without overlap.
• Testing and documentation are performed constantly throughout the build.
• The product could be declared finished at any time.

Strengths:

• Detailed process.
• Breaks tasks into manageable parts.
• Progress can be made even if requirements change.
• Fosters good communication.

Weaknesses:

• Focuses purely on development without addressing any other aspect of business.

Extreme Programming: User Stories and Pair Programming

As the name implies, Extreme Programming (XP) is used for software development projects.

Extreme programming starts when the customer produces user stories, which are short descriptions of functions. Ideally, these can be built and tested in as little as a week. The features are then presented to the customer, who evaluates and picks another week’s worth of stories to focus on.

One characteristic that’s often associated with XP is pair programming. With this practice, programmers work together, with one writing new code while the other observes and checks work. 

Key Principles:

• The planning game: Planning begins with user stories and a discussion with the customer about priorities.
• Small releases: Start with the smallest and simplest features. Release new features frequently.
• System metaphor: Each project has an organizing metaphor that provides a shared story regarding how the system works.
• Simple design: Always use the simplest design that will do the job.
• Continuous testing: Before a feature is added, write a test for it. Test frequently.
• Refactoring: Remove duplicate code.
• Pair programming: All code is written by two programmers at one machine.
• Collective code ownership: Any developer should be able to work on any part of the system.
• Continuous integration: Changes are integrated daily, if not more often. Tests run before and after integration.
• Forty-hour work week: No overtime.
• On-site customer: Development team has access to someone who will use the system.

Coding standards: Everyone codes to the same standards.

Strengths:

• Good communication.
• Focus on simplicity and feedback.
• Social activity.
• Emphasis on design.

Weaknesses:

• Doesn’t produce documentation.
• Can be expensive.
• Weak in some areas of business management.

Feature Driven Development: Know What It Does

Another one where the hint is in the name. Feature-driven development (FDD) focuses on creating features derived from a model of the end product. It is considered to only cover two parts of the software development process: design and build. 

Software development teams are divided into chief programmers and class owners. Chief programmers are generally more experienced. They lead a team of class owners, acting as a guide and organizer. Class owners are less experienced programmers who may do the bulk of the coding.

FDD is broken down into five steps, including:

1. Develop a model: A domain expert presents a model of the desired end product. Team members work to create a ‘walkthrough’ of the model.
2. Using the model and walkthrough, a list of desired features is created.
3. Plan by feature: The features list is broken down into design packages, which are assigned to chief programmers.
4. Design by feature and build by feature: These two steps are often handled together, as they are the iterative, or repeating, part of the method. The chief programmer chooses features to work on for the next period, usually a week or two.
5. At the end of that period, further features are chosen for another period of work. 

Key Principles:

• To scale to larger projects, there must be an organized method of producing systems.
• A simple and well-defined process is best.
• Steps in the process should be logical and obviously worthwhile.
• Process pride can prevent substantive work.
• A good work process fades into the background while the focus is on the product.
• Short, iterative cycles focusing on features work best.

Strengths:

• A practical method with strong modeling of features
• Detailed guidelines for design and build

Weaknesses:

• Focuses on design and build and therefore requires supporting methods.
• Requires subject experts to produce reliable models.

Crystal Method: Agile Communication

Crystal Methodologies is an Agile framework that is less a software process than a people process. It was developed to address the problem of poor communication between team members in projects.

The solution proposed by Crystal is to emphasize face-to-face communications among development teams. Informal knowledge is shared more easily, so the overall project is more likely to be successful.

This approach is also designed to scale to the size and number of Agile teams. Different ‘shades’, or sub-methods, can therefore be used by project management teams according to their needs. Variations, from most to least Agile, include:

• Crystal Clear.
• Crystal Yellow.
• Crystal Orange.
• Crystal Red.

Three key factors:

• The amount of communication between development team members, taking into account details like physical location, office layout, and personalities.
• The potential consequences of undiscovered software defects, including lost money, work, or even life.
• The presence of corporate goals that affect project decisions.

Strengths:

• Strong focus on communication addresses a common problem in projects.
• Well-defined guidelines for different team sizes.
• Well-defined risk control and technical practices.

Weaknesses:

• Not widely used or tested.
• Lack of guidance for wider business concerns.

Dynamic Systems Development: Build What You Can Afford

Dynamic systems development method (DSDM) expands and refines one of the earlier Agile development methods, Rapid Application Development (RAD), adding an iterative component.

According to some, DSDM is actually a framework, a more rigid approach to problem-solving. However, proponents say it has Agile development principles at its heart. The underlying principle is to fix time and resources available to the project, then adjust the product’s functionality to those constraints.

Unlike some of the other methods on this list, DSDM actually provides some guidance on wider business issues, rather than focusing purely on development. It uses a five-step approach to project management:

1. Feasibility Study: This step assesses the product and organization. Informed decisions can then be made, including whether DSDM is the correct method.
2. Business Study: Usually, this step takes the form of a workshop in which stakeholders and experts meet. The result is the Business Area Definition, which identifies potential markets and users.
3. Functional Model Iteration: This step includes analysis of requirements and production of a prototype. This step is then repeated until a ‘final’ prototype is produced, along with the results of the analysis.
4. Design and Build Iteration: Prototypes are reviewed by users. Their comments are included in further development, with a releasable product as the end goal.
5. Implementation: The product or system is transferred to the users, including training and documentation. Maintenance is sometimes viewed as continued, iterative development.

Key Principles:

• Active user involvement is imperative.
• Teams must be empowered to make decisions.
• Focus on frequent delivery.
• Fitness for business is a criterion for accepted deliverables.
• Iterative and incremental development is mandatory.
• All changes during development must be reversible.
• Requirements are baselined at a high level.
• Testing is integrated throughout the lifecycle.
• A collaborative and cooperative approach is important.

Strengths:

• Based on RAD principles, so well tested and reliable.
• Offers guidelines for wider business decisions.
• Scales to larger teams.

Weaknesses:

• DSDM is a proprietary methodology that isn’t available to everyone.

Lean Software Development: Trimming the Fat

Strictly speaking, Lean development is more of a management philosophy than a method of Agile development. Its concepts draw both from Agile practices and from the Lean manufacturing approach that gained popularity in the 1980s. 

As a result, Lean development doesn’t offer a specific set of project management tools. Instead, it’s an attempt to apply Agile principles at the very top of a company starting with the CEO, and propagating them down from there. The 12 principles of Lean software development draw both from Agile and from the Lean principles that preceded them.

Key Principles:

• The top priority is to satisfy the customer.
• Offer the best value for the money possible.
• The customer must participate for the project to succeed.
• Lean development is always a team effort.
• Anything can be changed.
• Domain, not point, solutions.
• Complete, do not construct.
• An 80% solution today is better than a 100% solution tomorrow.
• Minimalism is essential.
• Needs determine technology.
• Product growth is feature growth, not size growth.
• Never push Lean development beyond its limits.

Strengths:

• Focus on the top.
• Guidelines for business systems.
• Risk control is well defined.

Weaknesses:

• Lacks some key Agile features, like easy adaptation to changing requirements.
• Limited application to software development.
• Technical practices aren’t defined.
• No guidance for small teams.

Adaptive Software Development: Harnessing Complex Systems

Adaptive software development is based on some complex math concepts focusing on complex adaptive systems. A frequently cited real-world example of such a system is the flocking of sparrows. While each moves independently, because of behavioral rules, the whole flock seems to move as if choreographed. 

That sort of self-organization can be crucial in a volatile development process, when the business environment may change rapidly. ASD combines some of those ideas of emergent organization with Agile software development methodologies. As a result, it’s most useful in extreme projects.

The ASD approach is divided into three steps. They are:

1. Speculate: Define the project mission.
2. Collaborate: High change systems require a balance between teamwork and managing.
3. Learn: Recognize mistakes and make changes.

Key Principles:

• Mission focused: Mission artifacts guide development.
• Component focused: Each cycle develops a specific list of components.
• Iterative cycles: Do and redo to improve.
• Time-boxing: Evaluate goals in light of time estimates and resources.
• Critical risk: Recognize risks so they can be avoided.
• Change tolerant: Changes are inevitable and advantageous.

Strengths:

• Best suited for high pressure or rapidly changing projects.
• Addresses non-technical aspects of development.
• Well-defined risk control.

Weaknesses:

• Provides a management culture, not development guidelines.
• No guidelines for small teams or individuals.
• Lacks technical and testing guidelines.

Pros and Cons of Agile Methodologies

Agile methodology is innovative in many ways and can be applied in a wide range of circumstances. However, it can’t productively be used in every project. Understanding the benefits and disadvantages of an Agile framework can help clarify where it will be most useful.

Pros:

• Produces working software quickly.
• Values individuals.
• Focuses on customer input and collaboration.
• Responsive to changing requirements and circumstances.
• Cross-functional teams create a multi-disciplinary approach.
• Prioritizes face-to-face communication.
• Allows for a healthy work/life balance.
• Continual problem-solving.

Cons:

• Scaling to larger teams and projects is difficult or impossible.
• Face-to-face communication is limiting in some ways.
• Project scope can be constantly redefined.
• May not be suitable for life-critical systems.
• Relies on individual skills, including social skills.
• Produces no or poor documentation.
• Can produce a subpar user interface.

Bottom Line on Agile Methodology

There’s no question that Agile methodologies are here to stay for the right projects. While there are some projects that will always require a traditional approach, businesses continue to change more rapidly every day, as does the world at large. In the Agile approach, it’s possible to find a framework for harnessing that rapid flow of progress to your advantage. 

One of the most important books in the project manager’s library is the Project Management Book of Knowledge. It contains processes that smooth any aspect of a project, grouped into five process groups or project management phases. While they don’t contain a specific method of organizing a project, they can be used with any sort of project management methodology.

Try some of the best project management software for small businesses.

Key Takeaways: Project Management Phases

• The five process groups described in the Project Management Body of Knowledge are initiating, planning, executing, monitoring and controlling, and closing.
• They might be used in many places in a project life cycle and are not sequential steps for completing a project.
• Despite not truly being project phases, they are often referred to as the 5 phases of project management.
• A project manager has to understand how and when to apply these processes.
• Processes have inputs and outputs, which can be documents, deliverables, or other items.
• Project management tools and techniques like the critical path method and a work breakdown structure can be used in these processes.

Overview: About Project Management

The definition of project management is straightforward: the use of skills, tools, and techniques to meet a project’s goals. A successful project manager meets objectives within the constraints of time, cost, and scope.

Today’s project managers use tools and techniques developed by their predecessors, helping them identify risks and address problems. They also help better allot valuable team members’ time, as well as other resources.

In the past, project management responsibilities might have been attached to another role or divided among the project team. It’s becoming more common for ‘project manager’ to be a separate discipline, one that relies on sophisticated concepts and tools.

Project Management Body of Knowledge (PMBOK)

In North America, the professional project management body is the Project Management Institute. As part of their mission to advance quality management in their profession, they released a guide that detailed a set of best practices for achieving a project’s objectives. 

That first version of the PMBOK was released in the early 1980s and has been revised several times. It has become an often-cited text and an important reference in a project manager’s job, providing proven ways of improving project performance. Most of the information is arranged into process groups or areas of knowledge. 

While the processes are important parts of the project management life cycle, they don’t detail separate phases of a project’s progress. However, we’ll discuss that a bit more further down.

Project Management Methodologies

Project management methodologies are sort of like generic project plans. They provide a set of related tools for keeping projects organized. They are often used by project managers as a starting point or template for planning the project. In the past, traditional or waterfall methodologies were more common.

Today, an IT project will commonly use Agile project management methods to cope with new challenges. Methods like these may provide ways to break projects up into different phases. However, the different process groups found in the PMBOK should work with any methodology, Agile or waterfall methodology.

Project Management Phases

It has become somewhat common usage to describe the five process groups found in the PMBOK as the five phases of project management. Those project management process groups are:

Today’s project managers use tools and techniques developed by their predecessors, helping them identify risks and address problems. They also help better allot valuable team members’ time, as well as other resources.

In the past, project management responsibilities might have been attached to another role or divided among the project team. It’s becoming more common for ‘project manager’ to be a separate discipline, one that relies on sophisticated concepts and tools.

Project Management Body of Knowledge (PMBOK)

In North America, the professional project management body is the Project Management Institute. As part of their mission to advance quality management in their profession, they released a guide that detailed a set of best practices for achieving a project’s objectives. 

That first version of the PMBOK was released in the early 1980s and has been revised several times. It has become an often-cited text and an important reference in a project manager’s job, providing proven ways of improving project performance. Most of the information is arranged into process groups or areas of knowledge. 

While the processes are important parts of the project management life cycle, they don’t detail separate phases of a project’s progress. However, we’ll discuss that a bit more further down.

Project Management Methodologies

Project management methodologies are sort of like generic project plans. They provide a set of related tools for keeping projects organized. They are often used by project managers as a starting point or template for planning the project. In the past, traditional or waterfall methodologies were more common.

Today, an IT project will commonly use Agile project management methods to cope with new challenges. Methods like these may provide ways to break projects up into different phases. However, the different process groups found in the PMBOK should work with any methodology, Agile or waterfall.

Project Management Phases

It has become somewhat common usage to describe the five process groups found in the PMBOK as the five phases of project management. Those project management process groups are:

• Initiating processes.
• Planning processes.
• Executing processes.
• Monitoring and controlling processes.
• Closing processes.

However, as the PMBOK itself states, these process groups are not project phases. It may seem like a fussy distinction in the project management life cycle. However, confusing these two labels means missing out on a lot of the project management process groups’ utility.

Phases vs Processes

It may help to think of phases as stages of project completion. In the project planning phase, the project sponsors provide the project goals and the overall project plan is laid out. The business case may be analyzed before the project gets the green light.

With each of the project stages or phases, the project gets closer to completion. The first phase may also involve choosing a project manager and onboarding team members. In later stages, key milestones are met as work is executed.

Initiation processes are used during project initiation, during the first steps of creating a plan. However, they also may be used whenever a new aspect of a project begins. Closing processes may be used at the end of one phase and Initiating processes used at the beginning of the next. 

The processes aren’t tied to specific project phases and can be used wherever they’re needed. Instead, processes produce inputs and outputs that can take the form of documentation, deliverables, and more.

Project Initiation Processes

The output of initiation processes is not going to be a comprehensive project plan, nor will you be creating tasks yet. Initiating processes may be appropriate throughout the project lifecycle, whenever a new aspect needs the authorization to begin.

Obviously, they are useful in the planning phase of a project. The PMBOK refers to the two processes under this group as:

• Develop project charter.
• Identify stakeholders.

However, they could be restated as answering two questions:

• What is the project doing?
• Who might be interested?

Project managers may not be involved in some initiating process, as a project manager may not be hired immediately. Likewise, the project team may not be initially involved. However, that doesn’t mean they won’t use the Initiating processes.

Additionally, specific tasks aren’t liked to process groups. A feasibility study might be wise at the start of a project, but it’s not a process. In fact, it may be viewed as a project of its own, therefore using its own initiating processes, and so forth. Producing project documentation could also be considered a project itself, requiring processes from each of the phases of project management.

Develop Project Charter

A project charter outlines the initial requirements requested by the project sponsor, which often describe project objectives. However, the charter is not a complete project plan, lacking the detail required. A charter also formally authorizes the project’s beginning. 

While the charter is first developed in the initial stages of a project, this process can be used whenever a new aspect of a project begins.

Identify Stakeholders

Anyone the project affects may be considered a stakeholder. For example, stakeholders in an IT project for a hospital might include the hospital administration, doctors and other staff, patients, government agencies, other local healthcare organizations, etc.

An exhaustive list can quickly become unwieldy. However, identifying stakeholders early allows project managers to ascertain their needs from the start, reducing the chances of change later. 

This process can also be used at any point in the project management life cycle, particularly when considering potential changes.

Project Planning Processes

Planning processes accept inputs developed in the Initiation phase or process group, the project charter, and stakeholder registry. Those inputs are then expanded into several outputs, in the form of a more detailed plan, described clearly in the project documentation. A project strategy may already have been determined or be part of the planning stage.

As you would expect, the planning documents are used as inputs for some processes in the execution phase. However, remember that the process groups aren’t sequential steps in the project management life cycle. Planning outputs may also be used in project monitoring and controlling, for example. 

Some example processes include:

• Develop project management plan: The project management plan defines how the rest of the project will ideally play out. It is a document that also describes how to prepare, integrate, and coordinate plans and activities.
• Collect requirements: Collecting requirements involves identifying and documenting stakeholders’ needs. 
• Define scope: Project scope includes a definition of the product and how it will be produced. 
• Create WBS: The work breakdown structure (sometimes improperly called work breakdown schedule) divides the project into workable parts.
• Develop schedule: Outputs include a project timeline, project schedule, and schedule baseline. Many project management tools were developed to aid in these processes, from a basic Gantt chart to sophisticated project management software.
• Determine budget: The cost management aspects of planning begin with estimating potential costs. Those estimates are used to produce an estimated budget for the project.

Project Execution Processes

The execution phase or processes describe how to meet the project demands and produce the final deliverables. In other words, how to actually meet objectives and produce a finished project. 

Some processes are quite broad. For example, the directing and managing process would include assigning a task to a team member, tracking the task status, and reporting tasks completed. While there aren’t as many processes in this group, they will probably be the most expensive and time-consuming aspects of the project.

Monitor and Control phase processes run alongside execution processes, tracking performance and progress.

Some example processes include:

• Direct and manage project execution: The overall process to manage projects and project execution, from start to final phase.
• Acquire project team: While some team members may have been assembled earlier in the project, with a firm project plan, a complete team can be obtained.
• Manage stakeholder expectations: Stakeholders identified in the initiation phase process may raise issues in the course of the project management life cycle. This process describes addressing those issues.
• Distribute information: Make stakeholders aware of pertinent information, following the communication plan. Project management software often has tools devoted to distributing information.

Project Monitoring and Controlling Processes

Monitoring and controlling processes will be performed throughout the entire project, alongside Initiating, Executing, and Closure phase processes. Controlling processes are focused on collecting project performance information to better manage the project. Useful in any successful project, it is vital in more complex projects.

Among these processes are some active aspects of the risk management plan, including activating risk response plans, tracking known risks, and identifying new ones. The outputs from these processes can be useful in future projects, constituting a record of what did and did not work.

Some example processes include:

• Verify scope: This process is used to formally accept a deliverable created in an execution phase process, certifying it meets requirements outlined in the scope. 
• Control scope: Using key performance indicators to monitor for changes to project and product scope, as well as managing changes to the scope.
• Control schedule: Monitoring how much of the project remains and managing changes to the schedule.
• Report performance: The collection of project performance information, as well as distribution to the project manager and staff.

Project Closure Processes

In addition to being the last of the project life cycle phases, closure processes can be used at the end of any aspect of a project. All the deliverables created during project execution have been transferred and the project manager is wrapping up any final details.

It may also include a review and documentation of any lessons learned.

Close Project or Phase

As the name implies, the closure phase is used at the end of any part of the project life cycle. It may include the release of any remaining team members and the completion of contractual obligations. 

In the strictest sense, the project may have ended before project closure processes are needed. However, there may be loose ends that need to be addressed.

Close Procurements

Procurements may need to continue right up until the end of the project management life cycle. If you imagine the ending of a project like the cleaning out of an office, the last thing you do as you leave is turn off the lights. This process ensures project managers pay the last electrical bill.

Final Thoughts: Project Management Phases

The strength of the five process groups or project management phases is that they can be used in the context of just about any project. They provide process templates that can be filled in to meet specific needs. However, alone they may not provide every tool needed for good project management.

The issue of scope creep has bedeviled project managers since the ancient Egyptians wondered if three pyramids might be more impressive than just one. It isn’t a difficult concept to understand. However, heading off scope creep often requires a great deal of effort and expertise.

Key Takeaways: Scope Creep

• Project scope is the project’s goal and the process for achieving it.
• Scope creep in project management is when changes are made to the scope that don’t aid in its successful completion.
• Creep can be caused by stakeholders making requests or team members making unauthorized changes.
• Scope creep can cause a project to fail, so is an important concern of project managers.
• Preventing scope creep requires a clear scope, a method of handling change requests, and fostering communication between team members and other stakeholders.
• There are a wide array of tools to assist in managing scope creep.

What Is Scope Creep?

While scope creep is one of the most common reasons projects fail, there is no single agreed-upon definition of scope creep. Broadly speaking, it refers to the addition of tasks outside the original, defined project scope. Another way to think of scope creep is as uncontrolled or unexpected changes that may be opposed to the requirements of a project.

Some people would add that scope creep only occurs when unauthorized changes are made. By that definition, any scope change approved by someone in authority doesn’t qualify as scope creep. Others have determined that changes of any kind, approved or otherwise, can impact a project’s success and therefore be considered scope creep.

An example of project scope creep might be adding a feature that recommends mechanics halfway through the development of a car buying app. Requirement creep like that might introduce useful new features, but it’s not part of the goal of the project. Additionally, it adds to project cost and time.

To understand scope creep and its effects, we first have to look at the project scope itself.

Project Scope and Product Scope

The scope of a project is both the product it will produce and the process needed to produce it. The initial scope is referred to as the baseline scope, including the scope statement and work breakdown schedule. 

The product can be anything from software to a new building. Whatever it is, the product has its own defined scope which needs to be part of the project plan. 

Scope creep occurs in both product scope and overall project scope. Either can be a factor in project failure. In general, the more detailed and precise the project scope is, the less likely scope creep is to occur. As a result, the chances of successfully completing a project increases.

Agile Projects

Agile projects is a project management methodology that has been criticized as a sort of organized form of scope creep. When a project manager uses Agile methods, the product scope is not defined at the start of the project. Instead, project teams follow a process of defining and redefining the product throughout the project. That can seem like a recipe for continually redefining scope.

However, this is where separating product and project scope can be helpful. Agile methods generally have fixed resources and schedules, which are initially defined as part of the project scope. Changing either of those in the course of a project could qualify as scope creep.

How To Identify Scope Creep and Its Causes

Some degree of scope creep is often inevitable. Particularly at the rate at which daily life changes in the modern age, project requirements are likely to change in the midst of work. However, it’s the job of a project manager to keep it to a minimum. 

Despite that, there is no simple method for identifying scope creep.

Successful project management means accomplishing goals outlined in the project scope within budget and according to schedule. When scope creep occurs, it draws further on resources and takes up more time, but doesn’t contribute toward reaching goals. 

Generally speaking, methods of identifying creep involve assessing project progress while monitoring resources. Expending resources without progressing is usually a sign of scope creep. Project management tools along with project management software can be a great aid in this process.

A more effective method of managing creep is often to identify causes of scope creep and then, putting measures in place to control them.

What Causes Scope Creep?

The causes of scope creep on a project can vary depending on the nature of the project itself. Creep in software development may have a different origin than in construction. However, there are some common causes, including:

1. Unclear scope definition.
2. Poor communication with project stakeholders.
3. No effective scope management.
4. Improper collection of project requirements.
5. Length of project.

Unclear Scope Definition

The first, and perhaps most common, cause of scope creep is an insufficiently defined scope. If you don’t know what the goals of the project are, you can’t have a clear idea of how to reach them. Those issues have to be worked out in the midst of the project, leading inevitably to wasted time and resources.

Agile methods are ideal for use in contexts when outside factors could affect the scope during the project. However, Agile projects still require some aspects of the scope to be clearly outlined.

Poor Communication With Project Stakeholders

The project sponsor is the person who will overall be held responsible for the outcome. They also often don’t have the knowledge or time to precisely define every aspect of a project. 

Stakeholders are those individuals who either are involved in the project or will be affected by it. They may have agendas or desire features that would draw resources away from primary goals.

Part of a project manager’s job is managing the relationship between interested parties. If that’s not done properly, it is possible to waste time and resources due to disagreements. Too many stakeholders also cause problems, as the more difficult communication becomes, the more likely creep is.

No Effective Scope Management

It may be inevitable that the scope of a project will change. Agile methods were developed specifically because requirements or resources change so frequently during a project. If project managers recognize this and put an organized method in place of changing scope, uncontrolled change can be much reduced.

Improper Collection of Requirements

Another aspect of working with stakeholders is a clear process for collecting requirements. Stakeholders may see opportunities to add new features, find aspects they personally like and wish to be included, or otherwise add ‘requirements’ that don’t actually work toward the overall goal. 

A clear process for collecting and assessing requirements can help prevent that wasted effort.

Length of Project

A longer project doesn’t necessarily lead to more scope creep. However, it does mean there is more opportunity for it. 

What Mistakes Were Made To Allow It To Persist and Build?

Scope creep tends to stick around for two reasons:

• Unclear scope definition: If it is never clarified, an unclear scope can continue to drive creep.
• No process for incorporating changes: Some changes may be unavoidable. A defined process for making those changes can assess which are necessary and how to alter the project with minimal impact to project timeline and budget.

Fixing scope creep in any particular project usually means addressing these two issues.

How To Fix Scope Creep

The estimated percentage of successful projects varies but is usually around 30%. That means that most projects either fail or are not completed satisfactorily, in many cases likely due to the effects of scope creep. There may be no simple way to mitigate scope creep in project management, but it’s vital to successful completion. Methods for addressing creep include:

• Create a clear PSS.
• Put a change management process in place.
• Improve stakeholder communications.

Project Scope Statement

The project scope statement (PSS) provides a basis from which to make all project decisions, direct project effort, and communicate the project’s scope. It can also be a way of defining the boundaries of the project. The statement is important when creating a work breakdown structure, a clear project schedule, and a breakdown of project management phases, among many other things.

As a tool for communication, a PSS can foster a better client relationship. It can also clarify when changing requirements or adding additional features would cause scope change. Creating a statement or improving an existing one can help limit change.

Change Management Process

Some scope changes may be inevitable. In some ways, it is in the management of scope creep, project management finds its underlying purpose. Managing to control scope creep while also adhering to the project schedule and budget is difficult, and requires a clear scope management plan.

One of the most important aspects is the process for handling change requests. Requests for changes from stakeholders are a key reason for scope change. A clear process makes it easier to decide what changes are necessary.

Stakeholder Communications

A stakeholder is not just a client or project sponsor. They can also be team members, end-users, and other interested parties. Communicating the project’s status clearly is important, as are reasons for project delays. 

A project’s success is greater when new requests for change taper off as the project nears its end. Doing so helps prevent feature creep and prevents the change control process from controlling the entire project. The best way to accomplish that is by collecting all the needed requirements from the start.

A quality project management software may help in improving communications between various team members.

How To Manage Scope Creep

As we’ve mentioned, it may be impossible to entirely prevent scope creep. Instead of trying to figure out how to avoid scope creep, it’s better to have a process to manage scope creep. 

The strategies for fixing scope creep we’ve already mentioned can also help prevent and manage it, including a formal change management process, defined PSS, and process for stakeholder communications. 

Those are broad approaches to handle scope creep and it might help to focus on some tools for accomplishing those goals.

While project charter and statement of scope are sometimes used interchangeably, they are not quite the same thing. A charter is a document that launches a project and gives it the initial goal. A PSS delves into greater detail and answers questions the charter may not. Creating a PSS is part of the initiating phase of a project.

Creating a Project Scope Statement

Elements of a Scope Statement

A PSS is a bridge between the initial idea and the actual work needed to accomplish it. It fills in the outline provided by the charter with specific practical steps. A PSS includes elements such as:

• Business or project objectives: Describe the characteristics of the goal and specific objectives to reach it.
• Product acceptance criteria: Create some criteria or processes to determine when goals have been met.
• Project deliverables: Describe the end products, including products, processes, deliverables, etc.
• Critical success factors: Describe what the project must absolutely achieve in order to be considered a success. 
• External entities and exclusions: Address issues, organizations, or goals that may be related to the project, but not associated with it.
• Project constraints: Outline limiting factors, such as budget, schedule, and more.
• Project assumptions: Outline contexts and factors that can affect the project, but in any case are outside the project’s control.

Defining the Project Scope

A PSS is a complex document and creating a clear statement of scope can potentially be difficult. Defining the edges of the scope and developing a plan can both present a challenge. Some tools that can help you clarify scope include:

• Context diagram: Identify outside factors that can impact the project. Recognizing those factors can outline what the project needs to address to achieve goals. It can also identify stakeholders and prevent scope drift.
• Use case diagram: Identifying the needs that have to be met by the project plan can reveal all the additional features that need to be included in the end product.
• Product backlog: Use stakeholder and user feedback to create a wishlist of requested functions. Prioritizing such requests can offer a clear view on scope.

Creating a Change Management Process

If defining the project’s scope is difficult, changing it once the project has begun is even more demanding. Despite that, managing changes to the scope is an imperative part of a project manager’s job. A few basic guidelines can somewhat simplify this challenging task:

1. Be lean: Particularly when a project manager is coming in from outside an organization, try to keep the process as simple as possible. Doing so can often keep things moving efficiently and with minimum disruption.
2. Properly define the project scope: If a clear PSS isn’t created, how can you know when it’s changing? A clear scope is necessary when managing scope creep.
3. Understand sponsor final acceptance: Project sponsors put the project in motion and will often have the final say over its completion. Understanding their requirements allows you to aim project work toward specific goals for success.
4. Define change request process: Provide a clear path for change requests to be evaluated and then put into action. 
5. Document and communicate change process: Outline the process and, vitally, make sure project team members understand it and are on board.
6. Manage change: You’ve determined a change is needed, now it’s time to put it into action. This is a complex topic that deserves study of its own scope change.

That covers the high-level goals of a change control process. However, in practical terms, it also has to fulfill several functions to be successful, including:

• Prevent changes outside the change control system.
• Review requests quickly.
• Maintain the integrity of the baseline scope.
• Decide which requests to approve.
• Manage each approved change request.
• Coordinate approved changes through the project.
• Document the changes made.

Understanding Stakeholders and Requirements

Managing the communication between project team members and key stakeholders, as well as managing a client relationship, are arts in themselves. However, there are a few tools that can help. Some can help you understand stakeholders in a more abstract way, while others bring them together to discuss issues directly. Described below are tools for both approaches.

Facilitated Workshops

A common tool in software development is the joint application design workshop. Similar gatherings can be used to help develop a complete understanding of scope for other types of projects, as well. The goal is to gather representatives from the different groups of stakeholders to discuss the project and reach a consensus.

A neutral facilitator can lead, which may not be the project manager, and may include a variety of activities to aid in communication. As an example, the participants may identify the strengths and weaknesses of the project, as well as any opportunities or threats. 

Workshops should end with outlining the next steps in the project’s progress. A collaborative process of this sort provides a roadmap for the project team and project managers that can help in preventing creep. 

Stakeholder Analysis

Stakeholder analysis is a range of tools used for several reasons. The goal is identifying stakeholders and understanding both the communicated and uncommunicated requirements they have for the project.

Stakeholders are at the heart of every aspect of project management. Analysis helps the project team best align their efforts with the project’s goals. Tools used in stakeholder analysis include:

• Stakeholder analysis context diagrams.
• Stakeholder interest and impact table.
• Interest-influence classification.
• Stakeholder participation matrix.

Final Thoughts: So What Is Scope Creep?

Scope creep has been the cause of any number of failed projects. Managing it can seem like an incredibly expensive game of whack-a-mole. However, with a clear plan and some elbow grease, you can avoid scope creep or even turn it into a positive.

There is no single agreed-upon definition of project management methodologies. However, in broad strokes, it can be thought of as a set of guidelines, principles, and processes for meeting or exceeding a project’s requirements.

Any project management methodology may help you complete a project. That’s not quite the same thing as saying any methodology will help you successfully complete a project within budget and on schedule.

Key Takeaways: Project Management Methodologies

• Project management methodologies are a set of guidelines for running and completing a project efficiently.
• There is a wide range of methods, some very broad and others tailored to specific contexts.
• Agile methodologies feature customer input, decision-making by the entire project team, responsiveness, and an iterative process.
• Traditional project management methodologies feature a clear plan from the start and a hierarchy with the project manager on top.
• A project management methodology can be broad enough to use in several kinds of projects, or narrow enough to apply to a single person.
• The role of the project manager can vary.

How To Choose the Best PM Methodology

Many factors go into choosing the right project management methodology. However, some basic factors you’ll need to address include:

• Assessment of the project.
• Deciding what will bring the most value.
• Evaluation of your organization.
• Assessment of your team.
• Assessment of resources.

In the business world, a project is considered successful when it satisfies three criteria:

• Time: Meets required deadlines.
• Cost: Stays within an allocated budget.
• Scope: Meets requirements.

In the history of project management, these three factors were considered vital to managing successful projects and are generally referred to as the triple constraint. While they might not be the invariable guides they might once have been considered, they are still important to a successful project.

A project management methodology organized along traditional lines seeks to define each of those factors before the project begins. Newer methods, particularly Agile project management methodologies, may try to redefine them in the course of the project and the project scope may be changed several times.

Project management methodologies may include defining those goals, or they may be predefined. Either way, understanding the following basic factors can make the project management process go much more smoothly.

Assess the Project

The factor that is going to have the biggest impact on the project methodologies you choose is the nature of the project itself. Consider how the project is going to be planned. For example, construction requires very specific project management phases due to legal and financial constraints.

Project managers may also wish to consider a hybrid methodology, which combines the strengths of both traditional and newer approaches.

Decide What Will Bring the Most Value

In any project, it’s important to ask if each task actually creates a benefit, to the project or otherwise.

Deciding which value to emphasize is wrapped up in the project’s scope and goals, defining exactly what you’re trying to accomplish. It can also impact how you accomplish those goals. For example, green project management methodologies may have the same set of critical tasks but require green methods. 

Evaluation of Your Organization

Factors like skillsets and organizational goals also have to be considered. You may wish to focus on projects integrating sustainable methods, for example, if your organization prioritizes the environment. 

However, if your organization doesn’t have the proper skillsets or resources, more time may be spent obtaining those than actually working toward the project’s goal. Likewise, prior experience with a specific methodology may make it more attractive.

Assess Your Team

Just as the nature of your organization can define which methodology is going to be most successful, so can the nature of your team. 

You may wish to divide a larger group into several project teams so that multiple goals can be pursued at once. That has consequences when it comes to resource and time management that some methodologies are better suited to handling. Additionally, the role of project managers can vary depending on the project management methodology.

Assess Resources

Access to resources is important, as are other aspects of supplying what your project needs. There are some management methodologies, like PMBOK, that focus more on resource management than others.

Often, a project management tool can be a good way of tracking resources. The best project management tools offer some flexibility to meet many needs.

Types of Project Management Methodologies

Examining a number of project management methods can clarify which best fits your needs. Keep in mind that this project management methodologies list isn’t exhaustive.

Agile: Collaborate To Produce a Working Product, Which Is Improved Iteratively

Agile project management has come to refer to a whole class of different methodologies that have certain characteristics. However, it is also its own methodology, which has become one of the most popular project management methods out there.

Agile methodology focuses on responsiveness to changing conditions. We’ll cover some Agile methods, but examples include extreme project management and rational unified process.

Agile projects will involve all team members in initial planning sessions. The team then works on tasks for a set period, after which progress is reviewed and additional goals are set in continuous integration of feedback. It is an iterative process that works collaboratively with a client to produce working software in short order.

When To Use the Methodology

Agile was originally developed for small teams doing software development, which often doesn’t have or require precisely defined goals. 

Pros and Cons

Some benefits of Agile include:

• Continually improving.
• Feature-driven development.
• Response to changes.
• Cooperation with the customer.

Some cons include:

• Vulnerable to scope creep.
• Lacks a clear plan from beginning to end.

Waterfall: Plan Straight From Beginning To End

Waterfall project management is a common project management methodology. In broad strokes, it’s the basic approach to project management methodology most people would evolve on their own. Phases of the waterfall method include:

• Requirements: Analyzing needs.
• Design: Complete planning of the project.
• Coding: Following that plan.
• Testing: Features are extensively tested.
• Operations: Finished product is put into use.

When To Use the Methodology

Waterfall methodology might work best with small groups for projects in which deadlines, budget, and scope are all clearly defined from the outset. 

Pros and Cons

Some advantages of the waterfall method include:

• Clearly defined requirements.
• A well-defined plan for project completion.
• Cohesive end product.

Disadvantages include:

• Little flexibility.
• One missed deadline delays the entire project.

Scrum: An Agile Method Organized Around Short ‘Sprints’

Scrum is an Agile methodology, meaning it focuses on responsiveness to changing conditions and an iterative approach to tasks. It revolves around a couple of roles and a few events. Roles include:

• Scrum master: A facilitator that helps the team understand and apply the method.
• Development team: The project team members.
• Product owner: Client or customer who selects features.

Tasks are set and then worked on in a ‘sprint’ of a fixed length. The team meets daily, as well as having a larger meeting after the sprint to assess progress.

When To Use the Methodology

Like most Agile methods, Scrum was developed and is used most often by software development firms. It probably works best with a smaller team that can meet all at once and which is able to work closely with a client.

Pros and Cons

Advantages include:

• Focus on creating working products.
• Works closely with the customer.
• Responsive to changing needs.

Disadvantages include:

• Lack of complete documentation.
• Difficult to manage with larger teams.

Kanban: An Agile Method Using a Board to Track Project Progress

This project management methodology method was originally developed for assembly lines in Toyota factories. It is another Agile method, focusing on an iterative process to continually improve. 

The defining feature of this approach is the Kanban board, which helps organize the project into repeated stages. The underlying goal is to remove bottlenecks that can slow the project process and add to the cost.

The board is divided into four or more sections, usually including:

• Ideas: Tasks that are still under discussion.
• To do: Tasks that are ready to be worked on.
• In progress: Tasks that are currently being worked on.
• Done: Completed tasks.

When To Use the Methodology

Kanban allows a decent mix of pre-planning and flexibility. Goals may change and tasks adjust. However, it does require a clear idea of what a ‘finished’ task looks like. 

Pros and Cons

Advantages include:

• Flexibility.
• Clear goals.

Disadvantages include:

• Lacks a clear process.

Extreme Programming (XP): An Agile Method Using Paired Programming

Another Agile software development method, extreme programming methodology is intended to offer small, updated releases periodically that each offers new functionality. It uses a strict testing method to identify problems and resolve them at each stage.

It focuses on several values, such as simple programming and collective ownership. XP is known for pair programming, in which two programmers work together, one programming while the other reviews for errors.

When To Use the Methodology

As the name implies, XP is focused exclusively on programming projects, specifically updating or replacing large, outdated systems. It combines pre-planning and an iterative approach.

Pros and Cons

Advantages include:

• Close relationship with the customer.
• Frequent testing.
• Focused on simple coding.

Disadvantages include:

• Limited application.
• Piecemeal release.

Scrumban: Track Sprints on a Kanban Board

As you might guess from the name, Scrumban combines the project management approaches of Scrum and Kanban. The Kanban board is great for organizing a project and tracking the status of tasks. However, Kanban lacks a connection to higher levels of management, as well as a way to put releases into operation.

Scrumban allows for the easy tracking of tasks through the board, while dividing a project into discrete, iterative phases. This allows the team to work toward concrete goals while advancing the overall project.

When To Use the Methodology

As with most Agile methods, Scrumban is primarily used in software development and is one of the most popular project management methodologies in that field. It is ideal for projects where there is a clear idea of what a finished task looks like, without having well-defined goals overall.

Pros and Cons

Advantages include:

• Flexibility.
• Visibility.
• Continuous improvement.
• Focus on releasing products.

Disadvantages include:

• Difficult for larger teams.
• No clearly defined endpoint.

Adaptive Project Framework (APF): Plan Agile, Work Traditional

Hybrid project management practices seek to combine the flexibility of Agile with the clearly defined goals and processes of traditional project management methodology. Adaptive project framework is an example of such a hybrid.

The methodology recognizes that parts of a project may be open to an Agile approach, such as initial planning, but other parts require clear goals and deadlines. A project is divided into parts, with a plan created with Agile methods that are followed traditionally—lessons learned are applied to the following parts.

When To Use the Methodology

While APF was devised for software development projects, it has become popular in other contexts. Environmental planning, urban planning, and construction projects also use APF.

Pros and Cons

Advantages include:

• Combines flexibility with clear planning.
• Useful for large or long-term projects.
• Responsiveness to changes, while maintaining clear goals.

Disadvantages include:

• Complex.
• Can be difficult to implement.

Lean: Smooth the Path From Supplier, to Production, to Customer

Lean methodologies use Agile concepts to focus on creating a simple, uninterrupted flow from suppliers, to production, and then to the customer. A Lean project may include suppliers in the planning process as a result. 

Additionally, Lean methodology attempts to identify a value for each product or service, in an effort to eliminate wasted effort and resources.

When To Use the Methodology

Lean is used in some IT companies. It may be a good choice whenever a project depends on an uninterrupted flow of resources.

Pros and Cons

Advantages include:

• Customer collaboration.
• Working closely with suppliers.
• Eliminating waste.

Its primary disadvantage is that it might be better thought of as a management philosophy, rather than a true methodology.

Critical Path Method (CPM): Identify Tasks That Can’t Be Delayed

CPM is a traditional methodology focused on pre-planning and a clear path. The goal is to complete the project in the minimum time, at a minimum cost, drawing on as few resources as possible.

The critical path method involves creating a flowchart that can be used to identify critical ‘paths’ or task dependencies, as well as estimate completion times. In other words, it focuses on important tasks that can’t be started until other tasks are finished. This allows managers to focus resources on important points to prevent delays.

When To Use the Methodology

This approach is best suited for complex projects that have limited resources or have to share resources with other projects.

Pros and Cons

Advantages include:

• Clearly defined goals and processes.
• Shared resource utilization.
• Reducing cost and time.

The primary disadvantage to CPM is that it may not be suited for smaller projects or projects in which resource management isn’t a concern.

Critical Chain Project Management (CCPM): Identify Critical Tasks, With a Flexible Schedule

Critical chain project management is similar in broad strokes to the critical path method. Both try to anticipate the path to project completion and identify important tasks along that path.

CCPM differs in assuming each task will be completed as efficiently as possible and so doesn’t need a fixed deadline. Instead, it uses task ‘buffers’, essentially scheduling extra time between one task and the next to allow for delays.

When To Use the Methodology

The context for CCPM is similar to that for CPM, with the difference that time is managed somewhat differently. CCPM might be a better option when it’s difficult to estimate task completion times.

Pros and Cons

Advantages and disadvantages are similar to CPM, with the difference that CCPM allows for more uncertainty in planning.

New Product Introduction (NPI): Cross-Department Cooperation To Bring New Products to Market

An NPI team is made up of representatives from different departments in a company and other interested parties. The team’s role is managing conflict between departments and outlining the overall process.

NPI focuses primarily on the production process, including design, feasibility, and pre-production testing. It’s a traditional methodology in which steps are outlined before work is begun.

When To Use the Methodology

NPI assumes the team is working within a larger organization that has production and testing facilities available. It also is most likely to focus on a physical product.

Pros and Cons

Advantages include:

• Clear goals.
• Well-defined process and schedule.
• Well-established methodology.

Disadvantages include:

• Not responsive to changes.

Outcome Mapping: Tracking Behavior To Plan Community Outreach and Development

Outcome mapping’s key attribute is that it is more concerned with behavior than a product or service. It was developed by an international development agency to organize development programs, such as assisting farmers in producing a wider range of crops. 

It has some characteristics of Agile methods, such as involving the beneficiaries in planning stages and reevaluating after a set period. However, the ‘product’ is a change in behavior in the community being developed.

When To Use the Methodology

Any project that focuses on community reform and development could probably benefit from using outcome mapping. 

Pros and Cons

Advantages include:

• Evaluating changes in community behavior.
• Community involvement.
• Iterative structure to assess and evolve programs.

Its biggest advantage is also its greatest disadvantage, as the method’s narrow focus makes it unsuitable for use in other types of projects.

Six Sigma: Analyze Existing Processes To Eliminate Errors

Six Sigma is a methodology aimed at eliminating defects from products, processes, and transactions. It uses a five-step process that begins by identifying sources of error using statistical tools. In the following steps, users create solutions and ensure that the solution remains effective.

There is also a well-known project management certification program associated with Six Sigma.

When To Use the Methodology

Six Sigma will be most useful when searching for inefficiencies in a process. Using this method, those inefficiencies can be corrected.

Pros and Cons

Advantages include:

• Process focused.
• Clear progression from planning to execution.
• Statistical approach.

Disadvantages include:

•  Narrow use.
• Assumes there is always a problem to solve.

Project Management Institute’s Project Management Book of Knowledge (PMI’s PMBOK): Comprehensive Standards for Project Management

PMBOK was written by a professional association called the Project Management Institute. It has often been identified as a set of standards for different project management methodologies, rather than being a methodology itself. It outlines broad areas of concern, from contract negotiation to cost management. However, it does not give specific tools for addressing those areas. 

When To Use the Methodology

PMBOK is organized along traditional lines and is intended to be applicable in many situations. It is more like an outline for a method, which may be helpful in situations in which an established method isn’t available.

Pros and Cons

Advantages include:

• Traditional approach.
• Wide applicability.
• Created by a project management body.

Disadvantages include:

• Lacking specifics.
• Complexity.

PRINCE2 (PRojects IN Controlled Environments): Traditional Methodology Incorporating Customer Input

Originally developed as a method for managing IT projects by the UK government, PRINCE2 has been expanded for use in other areas. While not an Agile method, it still puts a priority on customer input. PRINCE2 is a complex method that uses nine elements:

• Organization.
• Planning.
• Control.
• Phases.
• Risk management.
• Quality in project management.
• Configuration management.
• Change control.

When To Use the Methodology

PRINCE2 is probably most useful in large software development projects. Its complexity may require some expertise, however.

Pros and Cons

Advantages include:

• Detailed approach.
• Involves the customer in the planning stages.
• Addresses starting and ending a project.

Disadvantages include:

• Complexity.
• Not as useful in smaller projects.

Rapid Application Development (RAD): Methodology With Time Management as a Top Priority

RAD is a project management methodology that breaks each project down into components. Each component has a deadline or ‘time-box’ by which it must be completed, even removing features if necessary to stay within constraints. 

When To Use the Methodology

RAD is perhaps most suited to small projects in which there is a degree of flexibility in the final product, or where there is a tight deadline.

Pros and Cons

Advantages include:

• Staying within time constraints.
• Individual components can be adjusted.
• User input early in the process.

Disadvantages include:

• Possible to miss requirements due to time constraints.
• Infrastructure (backups, documentation, human factors) is neglected in favor of time management.

Final Thoughts on Project Management Methodologies

This brief guide merely touched on some of the most well-known and useful project management methodologies. However, while it is a field that was developed only in the 60s, it has become a broad and highly developed field. 

The complexity and breadth of options may be overwhelming. However, taking some time to investigate and choose the right methodology for your project can pay dividends in time and money saved.