Figure 2-1: The operational project environment is more conducive to classic PM.
These types of projects are fairly regular, and the organization knows how to do them because it has done many others in the past. Because the level of uncertainty is low, these projects are often better served by classic methods, which are more process-oriented.
The Technology Development Project Environment
Next, let’s look at the projects at the opposite end of the spectrum—those focused on the development of a new technology (see Figure 2-2). I am not talking about a new product or application, but rather the development of breakthrough technology, upon which future products will be built. As such, these developments are often referred to as technology platforms. They often become the basis for entirely new companies or industries. Technology development projects are very unique in nature. There is no template project teams can work from and, in fact, a project management template, or any template for that matter, may greatly restrict the team creativity required to create such a new technology platform.
Figure 2-2: The technology development project environment is more conducive to agile PM.
Agile PM is most applicable in the technology/platform development project environment.
These early-stage, groundbreaking projects have never been done before under the same circumstances. The level of internal uncertainty is high. The team requires creativity, determination, and commitment. The project management environment, in turn, needs to support the team’s needs and not conflict with them. The general approach to these projects is vastly different from the way the team would approach something that it has done before. The team will likely need to pursue multiple pathways and iterations as it progresses toward its end goal (unlike the more classic approach of focusing on a single, primary, critical path). Agile project management can provide great value in these situations.
The Product/Process Development Project Environment
Finally, let’s examine a project situation somewhere in the middle—the product/process development project (see Figure 2-3). While the product/process may be unique, the technology platform is usually already in place, and a well-defined product development process (PDP) is most likely utilized. In the large corporation, product development projects can be complex, cross-functional efforts with many stakeholders, or in a small business, they may be the center of the entire company. While the pure technology development project involves mostly a scientific and engineering team, product/process development involves less front-end science/engineering expertise and more business acumen. Therefore, marketing and manufacturing are usually involved because of their know-how in bringing products to market. These kinds of projects still require a great deal of engineering creativity, yet they must balance those needs with the discipline required to launch and maintain successful products or services.
Figure 2-3: The product development project environment requires a mix of classic PM and agile PM.
These types of projects can also have a relatively high level of uncertainty, especially for those companies in the high-tech and scientific industries. In addition to the scientific uncertainties associated with the technology development project, product/process development must deal with business and market uncertainties, which are classified here as external uncertainties. Since there are many varied perspectives on the cross-functional team, agile PM can create value both by helping to navigate around uncertainty and by providing a mechanism for pulling together diverse teams. Additionally, while product development projects really need a combination of both classic and agile techniques, there is considerable opportunity for applying agile methods, since these comprise such a large percentage of projects in the innovative space.
Criterion 2: Organizational Stakeholders
The second project dimension that will help you determine the applicability of agile concepts is your type of organizational stakeholders. Specifically, do they include customers, partners, and subcontractors? The agile PM concepts in this book revolve largely around how the organization applies its project management efforts. In addition to addressing specific tools and processes, agile PM is concerned with organizational dynamics and attitudes. In concrete terms, what this means is that agile PM concepts have the best chance of success when the project operates under, more or less, a single organizational umbrella (see Figure 2-4.)
Figure 2-4: Agile PM is more applicable when there are fewer organizational stakeholders.
The Single Organization
An early-stage technology development project may have widespread potential applications but no specific external customer. The only real customer of the project is the business that is sponsoring it. This project is likely to be undertaken in its entirety within the company, perhaps only within R&D, and thus there are no partners or subcontractors on the team. In essence, there is a single organizational umbrella under which the project resides and, hopefully, there are common project objectives for the team. By operating under a single organizational umbrella, you will have a much better chance of creating an agile project environment in which to operate than if you had multiple stakeholder organizations to deal with.
Multiple Organizations
At the other extreme is the project that spans multiple, distinct organizations. While it is not impossible to create a successful agile environment across multiple organizations, it will be significantly more challenging. At this end of the spectrum, classic PM techniques are often more appropriate because they do a good job of setting expectations for multiple stakeholders, which include all of the distinct, external customers, partners, and subcontractors (see Figure 2-5). Since projects are, by definition, of finite duration, it often doesn’t make sense to try to create an agile PM environment across multiple corporate cultures. The time and effort required to create the agile culture may not have time to pay off, depending on the length of the project. Additionally, when many different companies are involved, it is unlikely that they will all have the common objectives required for ultimate project success within the agile paradigm. The chief reason for this is money. Everyone will be working to ensure that they get paid their fair share, as they should. Under a single organization, it is easier to justify sacrifices in one area for the good of the overall project. However, it is unlikely that one subcontractor will agree to work significantly more than originally planned without additional compensation for the benefit of the other subcontractors or even for the overall project.
Figure 2-5: Classic PM is more applicable when there are multiple organizational stakeholders.
Agile project management cuts across organizational boundaries to confront and constructively address complex interactions and interfaces.
This does not mean that agile concepts are totally inapplicable in this type of project situation. You should just be judicious in deciding which concepts to use. You should be aware of the challenges of driving environmental change across multiple organizations. For multiyear projects, or for situations where there is a strong, prime contractor that can drive organizational change across subcontractors, agile PM may be a powerful tool you can use to gain a competitive advantage.
Single Company, Multiple Organizations
The in-between case is when a project operates within a single corporate umbrella, but where the divisions or functional areas involved operate as, more or less, autonomous organizations with their own objectives (see Figure 2-6). Depending on how the leaders of these organizations are motivated, it could be easy (or difficult) to introduce agile PM concepts. This is where most technology projects that can benefit from agile PM reside, and thus, it is an area with a strong potential return.
Figure 2-6: Both agile and classic PM may be applicable when there are multiple organizations within a single company.
Since projects are a very visible mechanism that cut across multiple organizations, they also have the unique ability to influence organizational effectiveness across the entire business. Projects bring out the organizational dynamics that are not seen when one looks at the business from a strictly operational view. Nonstandard interfaces and complex interactions surface. How the organization learns to deal with these situations can determine the long-term success or failure of the business itself. Agile project management identifies these organizational complexities and confronts them constructively within the project management paradigm. While the immediate goal is enhanced project performance, the ultimate objective of agile PM is increased organizational performance.
Deciding to employ agile PM is not a simple, black-and-white question. As you read this book, you will see that there are several areas that affect, and are affected by, agile PM concepts. Some of these areas will be very applicable to your unique situation and others will not. Agile PM is about new perspectives and techniques around project management. It is a culture-changing concept that may take patience to employ, but it will be worth the effort.
This chapter has provided some guidelines to help you understand how well agile PM may apply to your project situations by looking at two key project dimensions—the type of project environment and the organizational stakeholders. Figure 2-7 will help you quickly identify whether agile PM is suitable for your situation.
Multiple, External Stakeholders
Multiple, Internal Stakeholders
Single Organization
Operational Projects
Classic
Classic
Classic
Product/Process Development Projects
Classic/Agile
Classic/Agile
Agile