The Characteristics of Agile Project Management

In this book, I define agile environments as those that exhibit internal and/or external uncertainty, may require some unique expertise, and possess a high level of urgency. A more specific way of defining the agile PM environment is as follows:

Project uncertainty is the primary factor making the case for agile PM. Secondly, if your project requires unique expertise, it can also benefit from agile PM. This expertise may be represented by the sole individual who understands how all the pieces of a project fit together technically, such as the system architect, or by the most knowledgeable person in a small but critical area. The need for speed, which I call a multiplying factor, is the third and final component of an environment conducive to agile PM. When combined in varying degrees, these three characteristics, especially uncertainty, can create an environment of changing project requirements. Most project managers know from experience that it is difficult at best, and frustrating at worst, to successfully run a project where the requirements are dynamic. Yet this is the world that many of us live in, and it is the world where the agile PM techniques described in this book will be most applicable.

There are two types of project uncertainty that we will discuss in this book—internal and external.

• Internal uncertainty involves those things under the project umbrella that can be more or less controlled by the project manager, including scope, schedule, and cost.

• External uncertainty involves those factors not under the project umbrella, such as the industry's business environment, the competition, and high-level, business strategy decisions.

Both are critical elements to consider, but one or the other may be more prevalent in any particular project. This, in turn, will help determine how you deal with them.

Internal Uncertainty

Let's look at internal uncertainty first. Some projects may be considered essentially the same as, or at least very similar to, previous projects undertaken by the company. Home or commercial construction, equipment installation, and maintenance come to mind as examples. Even if there are initially some internal unknowns, no matter what pops up, the team has probably already encountered a similar situation on past projects and thus will be able to minimize the impact on the overall project. An example might be the installation of a new piece of manufacturing equipment that upgrades a section of an active production line. This example represents an important project in that it boosts long-term capacity, it is critical that it be executed on time or it will impact short-term production requirements, and it involves unknowns, as this is a new piece of equipment. Yet, in reality, this project has minimal internal uncertainty. Live production lines have been successfully upgraded before. The team knows who needs to be involved, and it knows the potential impacts on all of the crossfunctional areas. While there have been problems in the past, the team has learned from them. In essence, the team has the knowledge to pull together and execute a fairly comprehensive project plan. If anything unusual comes up, which it always seems to, the team is confident that, based on experience, it will be able to handle it. In essence, the internal uncertainty of a project is inversely proportional to the level of experience on similar ones (see Figure 1-2).

Figure 1-2: Internal uncertainty is higher when doing something for the first time, and it diminishes as you gain experience.

On the other hand, development projects, especially those involving scientific discovery, are totally different. Internal unknowns on these projects are usually plentiful, and they may create changes that take the project off its original course for good. Does this mean that you should give up on your original timelines and objectives? No. It means you have to be agile in making your course changes. You should expect that internal uncertainty of this type will have significant impact on the project, so it will have to be actively managed. An example might be a company's development of a new technology that will enable drug targeting for cancer medications. This project is important to the company because it has a potentially huge revenue impact. In addition to the core scientific team, there is a considerable extended team supporting the effort. However, this project has huge amounts of internal uncertainty because the company has never done this kind of development before. Furthermore, very few other people, if any, have ever done this kind of work before. While the team is comfortable with its scientific approach to this project, it doesn't really know what to expect down the road. Therefore, it is reluctant to develop and commit to a comprehensive project plan. The team readily expects some surprises as the project progresses, but it can't anticipate, with any reasonable level of certainty, how it will handle them.

Classic PM was initially developed around mature organizations that had wrung much of the internal uncertainty out of their business.

Generally, the more mature an organization or company, the less internal uncertainty it will have in its projects. By maturity, I essentially mean the length of time a company or organization has been in existence working in its area of expertise. Organizations that are experienced at their craft can usually manage projects with much more predictability because they have removed much of the uncertainty, or unknowns, from their projects. They have learned through trial and error and thus are less likely to repeat mistakes. While not all mature organizations are necessarily large, most large organizations are relatively mature. Almost by definition, large organizations have gained maturity as they grew, and it was here that formal project management methods first took hold.

External Uncertainty

Because this area is largely outside the project manager's control, it is not usually observed in great detail. Nevertheless, it is areas external to the actual project that have, perhaps, the greatest influence on its outcome. As we will discuss later, project managers who successfully work in an agile environment will turn much of their attention away from the project itself and toward the external influences that may blow it off course. The project manager usually cannot control real external forces to his project but, if agile enough, can make the appropriate adjustments to keep the project objectives in sight.

The amount of influence that external uncertainty has on your project is largely determined by the industry in which you operate (see Figure 1-3). Industries that are relatively stable (i.e., where the focus is on evolutionary improvements rather than revolutionary ones) will see less external uncertainty. For instance, wholesale consumerproduct distribution could be considered an industry that operates in a more or less foreseeable environment. Through proven banking relationships, this industry's financing picture is secure. Companies in this area have long-standing relationships with their customers, and they have a good understanding of the competition. The new technologies that may influence them are focused on efficiency improvements, not radical new thinking that can turn the industry upside down. In a nutshell, their business is fairly predictable.

Figure 1-3: Project uncertainty is made up of both internal and external components.

On the other hand, industries that are emerging, or are in the process of remaking themselves, will exhibit signs of external uncertainty. For example, the Internet industry continues to emerge and expand at a fascinating rate. The endless list of potential Internet advancements must all be tried for the first time, and then optimized, all while the underlying and interlinked technology platform that supports the Internet is, itself, changing. The telecommunications sector is an example of an industry remaking itself to remain in step with new technologies such as wireless, voice over IP, instant messaging, PDAs, and even picture phones. Companies playing in this sector must cope with the ups and downs of the financial markets, the unstable technology infrastructure, and fierce competition.

Unlike internal uncertainty, which is more a function of company maturity, external uncertainty is largely a function of industry maturity. Generally, mature industries have weeded out much of the competition and have also erected barriers to entry for newcomers, thus reducing external uncertainty. Emerging industries have many new and smaller companies vying for position, which, in turn, causes a lot of rapid change and thus external uncertainty. However, the dynamics of the business world don't allow us to easily divide industries into two groups labeled "mature" and "immature". At any given time, some entrepreneur is working on a new and disruptive technology that could potentially upset the balance of a seemingly mature industry and, in the process, create a lot of external uncertainty for the entrenched players. When this happens, tried-and-true, classic project management practices may start to exhibit some difficulties. As more and more uncertainty is introduced to the previously mature and stable industry, the classic PM methods are stretched further and further. At some point, you will need to start looking for new ways to be running projects. Hopefully, you will find some of those new methods in Agile Project Management.

Unique Expertise

Projects that have their roots in innovation often require the use of unique expertise. At the heart of most innovative companies are the brilliant minds that drive the ideas and projects. These gurus often contribute significantly to many project areas. Unlike classic project management, where resources within a pool are interchangeable, there are no substitutes for the guru's unique expertise. Making the optimal use of unique expertise is part of agile PM.

Large corporations generally have a relatively large resource pool at their disposal. For example, when a project requires five electrical design engineers, the project planners can assume that electrical engineers (EEs) are a mostly homogeneous bunch (apologies to my many EE friends). If twenty-five of these engineers are employed by the company, then about 20 percent of them will need to be allocated to the project for its duration. If one engineer leaves for some reason, then (for planning purposes) any of the remaining engineers can probably be assigned to fill the gap.

Smaller companies, of course, have fewer resources, which tends to make them less homogeneous overall since a diversity of skills is still required to run the company. For companies driving innovation, the contrast is even more striking. Projects, and sometimes entire businesses, are formed around the unique skills of a single guru (or small number of gurus).

Speed

A lot has been written about how to move projects along faster by crashing the schedule, overlapping stage gates, or fast-tracking. These are all valid and valuable techniques. However, by this book's definition, being agile does not solely equate to being fast. Speed—or more appropriately, quickness—is a multiplying factor of agile PM, but not nearly the whole thing.

"Agile" does not equal "fast" in agile PM. However, speed is a multiplying factor of agility.

Getting projects done faster is a universal desire of management everywhere. So, while nearly all projects are being pushed to move faster, the real urgency is not the same across the board, thus we need to look at it in relative terms. A project coming in late for a small start-up can literally mean the end of the company. If it can't deliver on time, the start-up may run out of money, and that's it—game over! On the other hand, while large company management may push project managers to deliver on a tight timeline, the bottom line is that the impact of a late project on a big company is relatively small. It is not going to go out of business, and it will be able to make the appropriate adjustments to continue to steer forward.

This dynamic of urgency is partially driven by financial security, but it is also directly driven by the level of competition. Companies that feel the threat of competition breathing down their necks certainly have some urgency to execute projects faster. Speed is one tool to fight off competitors. Those that do not have that threat will not feel the urgency associated with it. For example, when a company with a dominant market position decides to upgrade its product, it doesn't have to worry much about racing to the finish line since there really isn't anyone to race against. The presence of competition creates urgency, which, in turn, creates pressure to move projects faster. Speeding up projects has been an area of project management focus for some time; however, when combined with other agile project characteristics, it takes on a new perspective.

The reality of project management is that you never really have the time to create the perfect plan, to analyze all the options, to get buy-in on decisions from all the stakeholders, etc. As the pressure mounts to move ever faster, plans are created and decisions are made with less and less information, creating an environment of uncertainty. So, while you may intuitively think that there is minimal project uncertainty, when combined with the pressure to move fast, it can actually become quite significant (see Figure 1-4).

Figure 1-4: Impact of uncertainty on the project as a function of urgency.