Technology/Platform Development Projects
Classic/Agile
Agile
Agile
Figure 2-7: Applicability of agile PM, based on project type and organizational stakeholders.
Summary
When assessing your project situation for the applicability of agile PM concepts, consider two key dimensions:
Project Type. Is it an operational, product/process development, or technology/platform development project?
Type of Organizational Stakeholders. Is there a single organization? Multiple, distinct organizations? Or is the project a hybrid involving both kinds of stakeholders?
Chapter 3: Projects are the Business
In large companies, at any given time, there will be a number of projects taking place across various parts of the business. Some of these projects will span multiple internal organizations and some will be wholly contained within a single department. In essence, the management, project managers, and project team members consider these projects as part of the business. Individually, these projects will impact some part of the business, but probably will not have substantial impact on the overall business, whether they fail or are successful. As you might expect, this situation is much different for smaller organizations, especially those involved with developing new technologies. In these cases, a single project or small set of projects can define a majority of the total business. It doesn’t really matter if it’s a start-up business or an emerging business unit within a corporate giant. These organizations must deliver concrete results to survive. Success or failure of these projects can make or break the business. It is in these situations that we can no longer think of projects as part of the business. We must be thinking of the projects as the business!
Business Organization
If you look at the makeup of a typical business, it contains two broad parts (see Figure 3-1). The first is an operational part that performs routine day-to-day activities that are related to generating revenue, such as manufacturing, sales, or billing. The second is the project part that focuses on the future vision for the company and may include R&D, marketing programs, and business process improvements.
Operations
Projects
Sales
Manufacturing
Procurement
Distribution
Billing
Technical support
Technology development
Product development
Process development
Product/service launch
Business process reengineering
New capability development
Figure 3-1: Typical business consisting of operational and project elements.
In very general terms, products, services, and processes get created on the project side of the business and are transferred to the operations side of the business. The trick is to facilitate an efficient transfer from one side to the other or, ideally, to have hardly any transfer at all because the two sides are so well integrated. This chapter looks at some tactics for deeply integrating key projects into the overall business to the point where the project team becomes fully attuned to benefits of success and consequences of failure.
The Triple Constraint
In classic PM, projects are treated as distinct entities within the business. They have a scope, resources, and a schedule that are more or less self-contained. The project manager must work within these boundaries, sometimes referred to as the triple constraint or iron triangle of project management, to deliver the expected results. Any decisions that require changing one of these boundaries must come from outside of the project—typically from functional or executive management. For example, if something unexpected happens that requires changing one of the boundaries (i.e., either the scope, resources, or schedule), then the project manager collects all of the relevant information and brings the issue to the project sponsor. The sponsor, in turn, listens to the situation and takes the recommendations of the project manager under advisement. Before making a decision on how to proceed, the sponsor may add new information to the mix, confer with her peers, or bring it to the next level of management. This whole data collection, analysis, escalation, and decision-making process usually takes time, during which the project may be stalled.
This process is valid in many industries, especially mature ones where much of the uncertainty has been removed from the decision-making process by years of experience. In this case, the management decision makers are hopefully seasoned veterans with their finger on the pulse of the business’s finances and market environment. Taking the time to prepare an in-depth analysis for management will likely pay off in the long run on the operational side of the business in areas such as lower production costs, lower support costs, and better overall product quality.
Now let’s take a look at a company operating in an environment of internal and external uncertainty but that is trying to apply classic PM methods. The project comes to a decision point, but the project manager sees no obvious answer from his perspective. He starts collecting data so that he can create an analysis to present to the sponsor. However, in this environment there are limited solid facts upon which to build an analysis. This leads him to make educated assumptions, perhaps based on the consensus opinion of his team, which takes additional time. At the completion of the analysis, he notices that there are multiple possible paths with no clear “best option” to recommend. Oh well, perhaps management has additional information that will help make the decision? And he’s right. Management does add new information to the equation, but they also add some external uncertainties. The analysis now has so many dimensions and possible outcomes that it becomes nearly useless. Yet somehow, a decision is finally made and the project progresses.
Let’s examine what just happened. To make a mediocre decision, the project manager involved himself, a good part of his team, and management. This is both time-consuming and an inefficient use of resources, especially since the same decision, or perhaps a better one, could have been made a lot quicker if the project manager had access to the right information from the start and was allowed to look “outside his box” (i.e., his triple constraint) to make the decision.
In the classic PM model, the project manager is basically put into a box, albeit, a triangular box. He is usually given considerable liberty to operate within the box but very little leeway to work outside it, which is where traditional management gets involved. Even if no explicit directions are given to the project manager, it is human nature to focus on things within one’s control, which again is inside the box.
For the large, complex company, this makes pretty good sense. It is only logical that a large organization requiring numerous distinct roles in order to operate should create a project manager role to run the project and a management role to set the boundaries for the project. However, if freed from the complexity constraint inherent in large organizations, would you still choose these distinct roles for your company?
I would argue that while the natural evolution of project management has created these project boxes that cut across the functional silos of large companies, this is not the most agile way to organize projects for smaller organizations. While this model works for corporate giants in mature industries, it falls apart badly as you move to the opposite end of the PM agility spectrum—where speed is required and uncertainty abounds.
Agile Strategy View your projects in the same perspective as your business, by integrating project and business decision-making processes, and you will better achieve your business objectives.
Equating the Project and the Business
To start, we need to view projects as the business, or at least a core part of the business. This means figuring out how to integrate project and business decision making. When you are running a business in a fast-paced, competitive environment filled with unknowns, isolating your project teams inside boxes is like driving blind. More than just opening a window to look outside the project, we need to fully integrate the project with the business strategy, other related projects, and key operational activities. In a small company, this may involve reorganizing the whole business around a single core project. In a larger company, it may require deeper integration among the project, program, and business objectives.
Achieving this business and project integration involves both internal and external aspects (see Figure 3-2). Internal elements are those that reside within the sponsor organization, such as the high-level business objectives, other projects in the company’s portfolio, and day-to-day operational activities that keep the business running. Ensuring that all of these efforts are, in fact, supportive of each other requires that they are initially aligned and then that the alignment is maintained as decisions are made and the various elements change during project execution.
Figure 3-2: In agile PM, both the internal and external aspects of business and project decision making are integrated.
The external elements include your customers, competition, and any other influences external to your organization that may affect the project or the business. Information from external sources may enter the organization through your project team, a different project team, an operational area, or management or marketing and, quite often, stays in that small area of the organization. Getting this pertinent information to propagate throughout the organization is necessary for agility.