Agile Project Management: How to Succeed in the Face of Changing Project Requirements by Gary Chin

Planning Versus Execution

When the term project management is mentioned, the image that most often pops to mind is that of the Gantt chart, also known as the project timeline or schedule. From an academic perspective, we know that project management encompasses the end-to-end project lifecycle. Yet in practical application, there’s a strong emphasis on the planning stage, perhaps at the expense of other important process areas. This is partially due to the focus on planning by the affordable project management software applications, as well as the proven track record of solid planning over the past decades. However, as project and business environments become more dynamic, the effective planning horizon becomes shorter. If we insist on holding fast to our planning-focused approach to project management and do not recognize the shifting horizon, we will be setting ourselves up for failure and frustration.

In the agile environment, the PM emphasis is moved from planning to execution. It is during project execution that crucial decisions are made that determine success or failure of the project. This is not to say that the areas of project definition and planning will be ignored, just that their focus will shift to supporting decisions during project execution rather than making them all up-front.

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.

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

Leave a Reply 0

Your email address will not be published. Required fields are marked *