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.