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

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

by Gary Chin

Table of Contents:

Agile Project Management—How to Succeed in the Face of Changing Project Requirements

Preface

Chapter 1 – Defining Agile Project Management

Chapter 2 – Determining When to Use Agile Project Management

Chapter 3 – Projects are the Business

Chapter 4 – The Cross-Functional Team—Organizing for Agility

Chapter 5 – The Project Manager’s Role

Chapter 6 – The Agile Project Team

Chapter 7 – Planning for Agility

Chapter 8 – Approaching Risk in an Agile Environment

Chapter 9 – Management—Creating an Environment of Agility

Chapter 10 – The Operational Project Management Infrastructure

Chapter 11 – Agile Portfolio Management—Aligning Tactical Projects with Business Strategy

Chapter 12 – Integrating Portfolio and Project Management with the Product Development Process for Business Success

Preface

Today’s innovative minds are constantly pushing the envelope: New and often disruptive technologies are filling the product development pipelines of both large and small companies. The business landscape is fast-paced and competitive, and product lifecycles are shorter. Naturally, product development and launch times are also shortening as companies aggressively develop new products and services to compete. This emphasis on speed forces teams to make quick decisions with incomplete information or in an environment of uncertainty. This, in turn, leads to frequent changes in project requirements and direction. Teams need to be light on their feet … they need to be agile!

The need for agility is magnified in highly innovative businesses that are pushing the limits of current technology and thinking, and where key parts of projects often involve discovery or problem solving never encountered before. These types of projects have an inherent uncertainty and involve multiple paths, decision points, and iterations before they can be successfully completed. Technical teams know that it is impossible to precisely plan new discoveries far in advance. Consequently, they only use project management for administrative support, if they use it at all. Their resistance to using project management is, in fact, often valid. The classical project management technique that they have experienced is cumbersome and not as effective in a fast-paced and uncertain environment. Additionally, project management is more often than not perceived as bureaucratic overhead that will probably slow the team down rather than make it more agile. While I don’t fully agree with this viewpoint, I see that many of the commonly known PM practices and tools are geared toward large and relatively slow-moving projects.

On a broader scale, companies realize that they must continue to change and remake themselves to remain competitive—to hit their financial targets and drive the business forward. These business-level changes include not only developing new products and services, but also creating the innovative HR practices, marketing messages, partnerships, acquisitions, and reorganizations that will keep them ahead of the competition. In all of these cases, projects are the engines that power the business transformation and, in turn, enable the organizational flexibility necessary to survive in today’s world. To this end, most companies recognize that effective and agile project management is essential for their survival. The problem is getting there!

Modern project management, as developed in the post–World War II era, was initially employed to manage large government projects for the military and construction and space industries. It has subsequently evolved and been widely adopted in some form by most large commercial companies. Nowadays, these same project management techniques are well on their way into many medium and small companies. However, as you may guess, what works well for a huge government project may not be the optimal solution for an innovative startup or even a smaller entrepreneurial group within a large company. Those early projects had many unique challenges, such as efficiently managing hundreds of subcontractors, that project management was able to address. The ability to meet these challenges created the momentum that carried project management into the mainstream.

While many of these original characteristics are still present in today’s projects, most have evolved along with business in general, and some have changed radically. For the most part, the science of project management has kept pace with the evolution of business over the past few decades. However, in certain areas, project management has not evolved in step with business and therefore cannot effectively address its challenges. It is some of these areas that are the focus of this book.

If we fast-forward from 1950 to 2004, we will notice a dramatic economic shift in business—an increase in the number of small companies versus large companies. This shift was driven largely by the advent of the knowledge-based economy. At one time, only large companies with significant financial capital controlled the resources required to compete in business. Their resources were physical assets, such as buildings, material, and equipment. As knowledge and intellectual property became increasingly more valuable assets, entrepreneurs with little financial capital but significant intellectual capital were able to start small businesses and carve out niches in this new market space.

In their quest to grow and compete, these smaller businesses are looking to PM as a possible competitive advantage. They realize that good PM can add tremendous value to their projects; however, they also recognize that the familiar, classic PM approach is not quite right for them. Yet, they press on, with the understanding that their PM processes will have to undergo optimization over time.

The organizations that need new ideas in (agile) project management the most are likely to be investing the least in developing them.

There are a few subtle points related to this evolution that are worth noting. First, the sponsors and managers of projects generally know that one-size project management does not fit all, so they look to tailor classic PM processes to their particular situation. This approach will address some, but not all, of their challenges. Second, specialized and dedicated process development resources are required to develop, implement, and maintain robust project management processes, especially ones tuned to a unique and dynamic environment. Third, these process development resources quickly dwindle as company size shrinks, yet this is where customized project management processes have perhaps the biggest impact.

In some ways, project management has become a more or less rote mechanical process because it has been proven to work effectively on more or less rote mechanical projects. However, when applied to the more creative, uncertain, and urgent projects, classic PM practices often falter and need assistance. It is in these situations where we will explore various new thinking that will supplement the current body of knowledge on project management and, hopefully, extend its effectiveness into agile environments.

Acknowledgment

For my wonderful family, Cara, Maddie, and Garrett, who gave me the time and support to write this book, and whom I love dearly. Also, thanks to my friends Mark and Anne, who provided encouragement and helped me think through the many details.

Chapter 1: Defining Agile Project Management

Those of you who have managed projects in a technology environment know that balancing the needs of the project management (PM) process against those of a creative technical team is something of an art. You risk stifling innovation with too much process. With too little process, you risk never getting the project completed. The mismatch occurs when you try to employ classic PM methods in an agile environment. While many companies have spent significant money and energy customizing common PM processes to their specific situations, they are still finding that it is more of an art than a science, where certain project managers thrive and others struggle. Building on classic PM methods can take you only so far in the uncertain environment that’s so typical of projects pushing the boundaries of technological and business innovation. Agile PM will provide some new concepts and techniques that I’ve seen to be effective in dynamic environments and that, hopefully, will help you advance your project management foundation in these challenging areas.

Overextension

A primary reason that expanding on classic PM methods is not as effective in certain areas is that it is simply being overstretched. Over the years, classic PM has evolved into a wide and solid platform for delivering all sorts of projects in all kinds of environments. People have taken comprehensive, classic PM methods and customized them for their unique situations. In turn, this has further validated and expanded the classic PM platform. I have yet to encounter a company that hasn’t done some type of PM customization for its specific business, yet the core methods always come back to the classic fundamentals. However, like any platform, classic PM has its constraints, and as we stretch it to address the new scenarios that lie on the fringe of the platform edges, it becomes less effective (see Figure 1-1). It is in these fringe areas at the edge of the classic PM platform that agile PM comes into play.

Figure 1-1: The relationship between classic and agile PM platforms.

As you continue to advance your project management methods to keep pace with your changing project and business requirements, it is generally easier to build off an established idea or concept, rather than starting from scratch. In the agile environment, the problem is that there isn’t a good foundation to start from because classic project management has been overextended. This book will attempt to correct that situation. Agile PM can be viewed as a new foundation element, perhaps just a single post, that will help support the extensions of the classic PM platform in such a way as to enable its practitioners to more effectively manage projects in an uncertain environment.

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 *