The first step in this direction is to enable, allow, and encourage project managers to look outside of their projects. Having an outward perspective is a powerful agile paradigm, yet very difficult to realize. Establishing an effective outward orientation is difficult because it involves developing a new project management infrastructure (to enable the outward view) and transforming your business environment (to allow and encourage the outward view). Both of these points will be discussed in more detail in Chapters 5 and 10, on the project manager’s role and the operational infrastructure, respectively.
Agile Strategy Have your project managers take more of an outward-facing perspective from their project, to facilitate the integration of the project and the business.
The primary reason that we need project managers to shift from an inward to an outward orientation is to get them more closely aligned with the real business objectives that the project is intended to achieve. This puts them in a position to feel the threat of competition and to understand the potential consequences of failure. An agile project needs to be more concerned with delivering results that solve business needs, rather than staying within preset project boundaries (see Figure 3-3). Project managers should be focused on beating the competition to market, developing new and unique product features, or making the best utilization of a rare resource. These goals put projects into the business context in a real way. The team is connected to the business outcome and therefore is better able to deliver results that contribute to the bottom line.
Figure 3-3: The primary focus of the project manager in an agile versus classic project environment.
Agile Strategy Focus your project manager’s energy on delivering results that solve business needs rather than staying within preset project boundaries.
One reason that the classic PM model of setting project constraints up-front works well in many situations is that the business objectives are matched to the project constraints at the start of the project. If the business environment is relatively stable, then the project constraints will remain aligned with the higher-level business objectives. However, in fast and uncertain environments where things tend to change, you may soon find that the original constraints no longer align with what’s happening in the real world outside of the project. Then the reality is diverging from the box, and we need to decide whether the project is the box or if the project is the business.
In an uncertain environment, the original project boundaries will quickly diverge from the business reality.
As project boundaries (scope, schedule, resources) become more dynamic, the agile PM concept of integrating the project and the business becomes more applicable (see Figure 3-4). It should be pretty clear that decision making and thus project progress will be slowed if the management team needs to be constantly involved in redefining project boundaries.
Figure 3-4: The predominately static project boundaries of the classic project give way to more dynamic conditions in the agile project.
There is no question that effective boundary management should be a cornerstone of all types of project management, classic or agile. A clear understanding of project boundaries is critical as projects are initiated and planned to ensure that the team knows what it is trying to accomplish (scope), by when (schedule), and with what means of support (resources). At closure, too, the team and sponsor need to know whether the project was successful. How the project team and the business organization approach boundary management during the project execution may differ, however.
In classic PM, the project manager is expected to execute course changes within the schedule, scope, and resources of the project, but not necessarily changes prompted by external events. This makes sense since the project manager has intimate knowledge of what’s happening inside the project but not in the overall business environment. Other people in the company are charged with understanding the various parts of the business environment and communicating relevant events back to the project manager, if deemed necessary.
Agile PM strives to get these two camps integrated so that better decisions can be made in a more timely fashion (see Figure 3-5). The project team is then better able to adapt to the constantly changing requirements inherent in the agile environment. Looking at the project as the business is one way to enable that integration of project and business decision making. Having your project managers take an outward-facing perspective is another.
Figure 3-5: Agile PM looks to integrate the internal and external project environments.
Matrix Management and the Integration of Project and Business Decision Making
Matrix management is one of the most widely adopted approaches to managing projects. Its premise is to establish cross-functional teams, composed of representatives from stakeholder organizations, to run the projects (see Figure 3-6). These cross-functional team members belong to their respective functional organizations, report to the functional manager, and are “loaned” to the project manager for the purpose of completing the project. The idea is that a project team composed of the right diverse resources will be able to deliver the project better and more efficiently than a homogeneous team with no sense of ownership for project results. Concurrent engineering, a derivative of the matrix model, is a good example for product development projects where there is a relatively complex organization and many stakeholders working together on the same product. It has proved to be an effective practice for facilitating the transfer of work (from the project side to the operational side) and eliminating the old “throw it over the wall” product development mentality. Likewise, the matrix management concept has been very successful in larger companies with a fair amount of organizational complexity.
Figure 3-6: Typical organizational structure for matrix management.
The matrix management model integrates the project with the business organization, but not with the business objectives.
While the matrix does help to facilitate the management of projects across multifunctional organizations, it can be a stumbling block in achieving true integration of business and project decision making, which we identified previously as a key to enabling project teams to view their project as the business. The benefits and challenges of matrix management are well known, and you may be thinking that the obvious thing to do is to migrate toward a “stronger matrix”, where project managers wield more influence than functional managers. Even though this would seem to strengthen the position of the project, it still requires some type of balancing act and trade-offs with functional management.
By its very definition, the matrix approach to project management separates business and project decision making, creating an inherent inefficiency for those projects operating in an agile environment.
The matrixed approach to project management separates, rather than integrates, business and project decision making.
Perhaps the most recognized challenge of the matrix management structure is that project team members are put into the position of having two bosses—their functional manager and the project manager—thus potentially creating undercurrents of tension and confusion between team members, their manager, and the project manager. In organizational cultures where the functional and project managers have a mutual respect for each other, this arrangement works quite well. In fact, it may be the only somewhat efficient way to conduct projects in large companies. Additionally, matrix management has a sort of “political correctness” to it, in that it enables cross-functional projects to take place without reconfiguring the established functional organizational roles.
While the matrix organizational structure provides inherent efficiency for larger companies composed of numerous functional silos, it often adds unnecessary complexity to smaller businesses, which are more likely to be operating in an agile environment. Another potential problem with using the matrix approach in an agile environment is that small organizations often just don’t have enough depth to adequately staff all the functional specialties that characterize a matrix approach. Consider the situation where a small business has a unique resource (guru) that is the heart and soul of the business. If this is the case, where do you put this key individual? Most companies give their star players positions at the head of a functional silo—after all, this is what we’ve been conditioned to aspire to in the big company model. However, what’s more important to achieving the business objectives—heading up a functional department or executing key projects? Agile PM argues for the latter. Especially in smaller organizations, projects must be viewed as the business and therefore staffed with the key players necessary to make them successful.
We need to understand when the matrix is appropriate and when it is not. It is easy to default to the matrix mode since it is so commonly used, but this may not always be the best option for organizations at the fuzzy front-end (i.e., those pushing the limits of their field).
Upon review of the pros and cons of the matrix management approach (as outlined in Figure 3-7), we can see that while it is very appropriate for larger more mature businesses, it may not be the best choice for smaller, agile organizations that cannot reap the benefits and are hurt by its deficiencies.