Author: Rory Hart

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.