Innovation

Innovation takes into consideration the degree to which the technology and methods you will use on the project are new and untested versus known and standardized. Using methods and processes you are familiar with is conducive to waterfall approaches. Cutting‐edge technology or experimental processes work better with adaptive approaches.

A project to repave eight neighborhoods does not require any innovation. The technology and methods are well known, so a project like this works well with a waterfall approach. Conversely, a project to build a battery that can last for 10 years in 0 gravity requires significant innovation. Therefore, this type of project would work well with iterative and incremental approaches. The team would require a lot of creativity and the ability to experiment and try different ways to achieve the intended result.

Scope Stability

How likely is your customer to change their mind, add new features, or request something different? If you are working on a project where the scope is fixed and unlikely to change, such as installing landscaping in a housing development, you can use a waterfall approach. In contrast, if your customer is fickle or has a lot of new ideas they want to try out, such as rebranding a product line, then you should consider one of the adaptive approaches.

Requirements Certainty

Requirements certainty is related to scope stability, but it is a bit different. The scope is what you are delivering, the requirements are the capabilities that must be present and conditions that must be met to achieve the project objectives.

Some projects have very clear requirements from the start, for example, install a three‐story parking garage that can hold 500 cars. Clear requirements lend themselves to waterfall approaches.

Many projects don't know all their requirements at the start. The team expects the requirements to evolve and new requirements to be added throughout the project. A project to establish a concierge service for a high‐end credit card might start out with some high‐level concepts and ideas, but as the service is rolled out, those requirements might evolve and change based on user requests and feedback.

Ease of Change

Change is a way of life, especially on projects. But not all projects absorb change easily. A project to create an electronic performance dashboard can absorb changes in scope or requirements fairly easily. This type of project fits well with an adaptive development approach.

A project to build a bridge does not respond well to change. For this type of project, you want to make sure you have all the specs correct before you start construction because any change could be very time‐consuming and costly! Therefore, you would want to use a waterfall approach where you lock in your scope and designs prior to starting construction.

Risk

The type of risks on a project indicates the most appropriate risk responses. Risk responses for risks associated with product acceptance or new technology can include using an adaptive development approach. An adaptive approach allows the team to experiment and develop prototypes and then evolve the product based on the outcomes and feedback.

For projects with risks associated with safety or where you can't fix something once it is complete, a waterfall approach is best. For example, if you are launching a satellite, once it is launched you can't redo or rework something; therefore, the up‐front planning and robust risk management that is used in a waterfall approach is best.

Criticality

Criticality deals with the relative importance of a component, deliverable, or project. For example, there is a high degree of criticality with maintaining the power for hospitals. A component or deliverable with a high degree of criticality usually indicates a waterfall approach is best. A component that is easy to replace and does not have a significant effect if it fails may work with an adaptive method. For example, a project to implement an online ordering system would have a requirement to send an automated email confirming the order. If this function fails, it is relatively easy to fix, and no one will be harmed if they don't get the confirmation email.

Safety

When safety issues are involved, most projects rely on a waterfall approach. For example, projects that develop implantable medical devices have significant safety concerns. They require the planning, documentation, and testing that is common in waterfall projects. Conversely, a project to update a gaming application on a smartphone doesn't have a lot of safety issues, and so an adaptive approach would work well.

Regulatory

Many projects are done to achieve or maintain regulatory compliance. This can include plant inspections for facilities that work with hazardous materials or educational institutions that need to maintain compliance with accreditation requirements. Most regulatory agencies want to see detailed documentation and rigorous policies and procedures that demonstrate compliance. These projects use waterfall approaches. Where there isn't a need to demonstrate compliance or alignment with regulatory agencies, both waterfall and adaptive approaches are valid.

Stakeholders

Projects have a wide range of stakeholders, some of which will be well known to the project team, such as the sponsor or product owner, and some that the team will never meet, such as certain end users or members of the public. One of the strengths of Agile methodologies is the access to key stakeholders. In a purely Agile environment, key stakeholders, such as the product owner, are available to the team to answer questions and protect the team from interference. They review work at regularly scheduled intervals, such as demonstrations every two weeks, and they prioritize features in a backlog. Thus, for projects that use Agile methods to develop products, access to key stakeholders is a necessity.

Projects that use waterfall methods usually have less need of and less access to stakeholders. Obviously, there is some interaction, but it is not as consistent or frequent as in Agile projects.

Delivery Options

Does your project have one main deliverable, or can it be decomposed into multiple smaller deliverables? Do all the deliverables have to be released at the same time, or can they be released in batches? The answers to these questions will point you in the right direction for choosing a development approach.

Typically projects with one delivery at the end use a waterfall approach so you can plan the development, testing, and delivery. A project to build a new hotel is an example of a project with one main release. Projects where you can work on several different deliverables but bring them together before release work well with an iterative approach. A project to update a payroll system might have multiple components, but they all have to be integrated before release. Projects that have periodic deliveries, such as a website, work well with incremental approaches.

Funding Availability

Many projects that are involved with new product development, especially digital products, will start with a small budget, and as the product gains market share and becomes profitable, they will add features and functions. This business model essentially uses the profit from the product to fund future upgrades and enhancements. This model is often used with Agile projects or projects that use iterative approaches. The up‐front investment is comparatively minimal, and if the product doesn't do well, the project is cancelled with minimal loss of investment. This model can also be used if there is uncertainty about the amount or timing of funds. An Agile approach allows the team to deliver some value for the investment, even if not all the objectives are realized.

Multiyear projects with large budgets need to consider funding availability. Some projects are constrained by fiscal year funding, necessitating planning around the availability of funds. If there is only one large deliverable at the end, a waterfall approach is often used, and work is planned around funding availability.

Structure

There is a broad spectrum of organizational structures that range from hierarchical to matrix to flat. A hierarchical structure has lots of layers of management, and often the functions are siloed. This type of structure usually has a robust set of policies and procedures, and the communication and interaction between functions may be limited. Projects that use a waterfall approach do better in structures like this than Agile projects. The exception is if a particular function, or group of functions, such as IT, employs Agile methods.

Organizations that are flatter and more responsive to change and adaptation are where adaptive project management practices thrive. There are less layers of bureaucracy that require approval, and development is usually more nimble.

Culture

Company culture is a big determinant in choosing the best way to manage a project. Projects that use Agile methods are based on a climate of trust, where the team is empowered to make many of the decisions about the project. They establish their ways of working, communicating, troubleshooting, and so forth. Agile teams are often self‐managing, without a specific designated leader. This way of working will not work in a highly bureaucratic or “command and control” environment.

Conversely, a project that requires a lot of documentation, sign off on decisions, rigorous processes, and so forth, will do well in a hierarchical environment but will not fit as well in a flatter organization. One of the reasons many organizations struggle or fail in implementing an Agile methodology is that the company culture does not match with Agile ways of working.

Project Team

The size and location of project team members influence the development approach. Agile methods work best with teams that are 5–10 people who are collocated (in the same space). While you can apply Agile methods with larger groups, or with virtual teams, it is more challenging. Agile teams have daily stand‐up meetings, and much of their collaboration takes place in one‐on‐one conversations—preferably with a whiteboard nearby to capture ideas. These practices are more challenging when you have more than 10 team members or if team members are in different locations, especially if they are in different time zones or different countries.

Large teams work better with the structure of a waterfall project. There are fewer meetings, much of the documentation is electronic, and dispersed team members are not uncommon.

Experience and Commitment

The final variable is experience and commitment—both on the part of the team and the organization. Teams and organizations with experience and commitment to a particular method of managing projects can struggle with adopting new ways of working. Even if the team has experience and commitment to working one way, if the organization isn't aligned, it will be a rough ride. On the other hand, if an organization wants to try a new way of working, such as investing in Agile practices, but the team is not on board, it will be a struggle.

Product Variables

Once you have gone through the process of rating your project or deliverables, the best approach may be very obvious. However, if you want to take your evaluation a bit further, you can create a visual display to help you see the big picture.