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.
The Focus of This Book
The science of project management is constantly growing and changing to meet the many diverse needs of projects everywhere. The various levels of government, nonprofit organizations, and private-sector companies all run projects. The organizations range in size from the very large to the very small, as do the projects. Finally, there are many unique industries, all with their own project management characteristics. To cover all of these permutations would require a vast text, and it probably would not be very practical.
My feeling is that there is opportunity for advancing project management in those areas that are rife with uncertainty. The goal of this book is to give you some actionable ideas that will help you to better manage projects in these areas.
Agile Project Management provides some core project management methods, but it also looks at how organizations should use project management to become more effective and successful businesses. These concepts need to be taken and customized to your unique business environment. Since agile PM permeates so many project areas, I will be focusing as much on “what” to do as “how” to do it. Moreover, the “what” to do for agile PM is much more than just what the project manager should be doing. It includes understanding the business drivers, developing the right project management infrastructure, and nurturing a supportive project management environment. I’ll also review the roles of the project manager, the project team, and management, and look at how they need to adapt to achieve agile PM.
Summary
Classic PM is becoming overextended as we try to apply it to the agile project environment.
Classic PM was largely developed by organizations that had wrung much of the uncertainty out of their business during a time of less competition and, therefore, less project urgency.
Four dimensions drive the need for agile PM: internal uncertainty, external uncertainty, the use of unique expertise, and speed/ urgency.
Chapter 2: Determining When to Use Agile Project Management
Overview
Agile project management concepts are not for every project, yet they can be invaluable to others. So, how do you know which agile ideas are best applied to your situation?
Agile project management is not an all-or-nothing methodology. You should examine ways of combining classic and agile PM concepts where each makes the most sense. Classic project management is very comprehensive, and it has been proven to work in diverse project situations. Agile project management adds new ideas for addressing the unique project situations formed out of creative, knowledge-based industries.
You will benefit if your project operates in an environment of high uncertainty. You probably will not gain much if you operate in a very predictable environment. (But who does that?) The truth is that you are probably somewhere in between, where you will benefit from some ideas but not others. This chapter discusses two key project criteria that, together, will help you quickly surmise the applicability of agile PM concepts to your particular situation, as well as the potential value it may add to your organization.
Criterion 1: Project Environments
Over the years, I’ve encountered three different types of project environments within the technology and scientific areas. They are the operational environment, the product/process development environment, and the technology development environment. The operational environment is fairly predictable (i.e., low uncertainty), while both the technology and product/process development environments are more unpredictable (i.e., higher uncertainty). There is, of course, some overlap between these broad categories, but understanding generally where your situation fits will help you determine the extent to which agile PM concepts will benefit your project.
The Operational Project Environment
Let’s start with the operational project environment (see Figure 2-1). By operational, I mean those projects that are run with a regular frequency, are very similar to each other, and are critical to the day-to-day running of the business. Service provisioning is a good example of the operational project environment. Setting up a customer for a new service, either as a one-time user or on an ongoing basis, can be a significant project to do properly. However, the general workflow is basically the same for each customer. Contract manufacturing is another example of this type of project environment. While each product may be unique, the process for building out and running the manufacturing systems is common across all products.