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.

Pros	Cons
Separates business and project decision making, therefore enabling better long-term decisions	Separates business and project decision making, therefore adding inefficiencies to project management
Tames the organizational and political complexities of large organizations	Creates unnecessary complexity for smaller organizations
Enables cross-functional projects to take place without reconfiguration of established roles	Creates tension and/or confusion by creating the "two bosses" environment
Enables focus on development of functional skills and processes	Doesn't make the best use of unique resources

Figure 3-7: The pros and cons of matrix management.

Agile Strategy

Switch from a matrix to a project-based organization if you don't have the depth to effectively staff a matrix and need to make the best use of key expertise, or if you need to better integrate project and business decision making.