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.
The Project-Driven Organization
An alternative to the matrix organizational model is to create an organization around your key projects (see Figure 3-8). In this way, you develop a portfolio of projects that become your business. As technical project uncertainties create change from within, the business model adapts in turn. And when external influences force changes in the business, the project portfolio is able to more quickly absorb and compensate for the changes.
Figure 3-8: A project-based organization integrates the business strategy with the projects.
The project-driven organization is better suited to agile project environments (see Figure 3-9), with the key point being that business and project decision making are better integrated than in the matrix. The sole goal of project teams is to achieve the business objectives. The multiple, separate, and often conflicting objectives of the matrix organization don’t exist. The silo mentality that so often inhibits project progress, especially when it involves changing requirements, is eliminated. Finally, your unique and key players can be put in place to guide your most important projects, the ones defining your business, without encountering obstacles from competing functional management.
Figure 3-9: Project-based versus matrix organizations in agile and classic project environments.
Capitalizing on the strengths of your key personnel can be one of your strongest arguments for developing a project-driven organization. You can usually find ways to design your organization around your best performers, based on their specific skills, while still remaining on target with your higher-level objectives. This is not to say that you should be catering to the childish whims of a few eccentrics in your organization. However, you should be looking for ways to maximize their contribution and influence across your project set so it favorably impacts your ability to meet business objectives. After all, if your projects are your business and your key players are the heart and soul of your project, then it stands to reason that your key players are your business.
When there is a lot of energy spent on organization or silo building, as in the matrix model, it’s easy to lose sight of the ball. If you play in an agile environment of constant change, then losing sight of your core strategies will be fatal. You need to document the key business objectives that will make you successful, define the projects necessary to execute on those objectives, and then fluently manage the change, whether it’s driven by the projects or the external environment.
Agile Strategy Keep your business strategies in sight by:
Defining your key business objectives
Defining a set of projects that will deliver on those objectives
Managing the project execution in an environment that integrates the project and the business
There is no argument regarding the effectiveness of the matrix management approach, despite its shortcomings and inefficiencies. However, in smaller and more agile companies, if the inefficiencies start to outweigh the benefits, then it’s time to consider transitioning from strict matrix management to more of a project-based approach.
Summary
Classic PM treats projects as distinct entities with well-defined and mostly static boundaries.
Agile PM views projects as a core part of the business, whose boundaries are dynamic and shift with the business needs.
Integrating projects into the business requires developing the organizational and project management capabilities that enable the project manager to look outside of the project boundaries.
Agile PM looks to integrate the project and business environments, and thus their decision-making processes.
Business and project decision making are separated in the matrix management model.
Matrix management integrates the projects with the organization, but not with the business objectives.
Matrix management is an effective project enabler in larger companies, but it can be an impediment to smaller organizations.
A project-based organizational approach that integrates business and project decision making is better suited to the agile PM environment.
Chapter 4: The Cross-Functional Team—Organizing for Agility
Most companies running projects today are set up as some variation of the matrix, where functional managers own the resources and project managers pull individuals from the appropriate functional groups to build a cross-functional project team. The assignment to a project team is usually temporary in nature and individuals return to the their functional group when the project ends or their contribution has been completed. Whether or not your organization is based on matrix management, you will probably still have to put together some type of cross-functional (i.e., made up of multiple skill sets and backgrounds) team to execute your project. This chapter explores some of the dynamics of the cross-functional team that support agility. These concepts are applicable to both the matrix and project-based organizational approaches to project management, although much of the discussion is around the more commonly used matrix model.
The cross-functional team is usually formed with the stated purpose of ensuring that the team gets input and/or representation from all functional areas. This is definitely a step in the right direction to facilitate project communications. However, anyone who has led or been part of a cross-functional team will tell you that there are still challenges to overcome. Two common questions are, “Who’s really leading the team?” and “What am I supposed to do?”
Who’s Really Leading the Team, Anyway?
Project leadership is a sensitive topic and usually involves posturing between R&D, marketing, possibly another functional area, and the project manager. Certainly for technology companies, R&D is critical to business success. In fact, many technology companies are centered on R&D, so it seems logical that the R&D team leader should become the project leader. Then there’s the marketing team leader. This person represents the customer, and it makes sense that the customer’s needs should be driving the project. And finally, there’s the project manager who has been assigned to manage the project. It’s equally logical that he should be the leader.
Before going further, you need to recognize that there is both official and unofficial project leadership. The official leader is easy. That’s the assigned project manager. His name goes on the organization chart and that’s that. However, if another team member feels that she should really be leading the project, she could jockey to become the unofficial leader. If this individual has the organizational clout, a strong enough personality, and the support of her functional manager, she can achieve the status of unofficial project leader, thus pushing the project manager into an administrative support role. This is a real scenario that I’ve seen many times.
Ambiguity around project leadership is a detriment to project agility. Not only does the situation confuse the decision-making process, it creates an inefficient use of valuable resources and causes frustration in team members. Identifying this situation and resolving it as early as possible in the project will greatly increase your agility. In the uncertain and accelerated project environment, you will encounter many decision points. Approaching them in an organized and professional manner will be critical to success.
Agile Strategy Eliminate ambiguity around project leadership by clearly defining and communicating the leadership-specific components of the key team members’ roles and responsibilities (i.e., those related to running meetings, reporting to management, directing activities of other team members, and deciding on project course changes).
While there are numerous reasons that companies find themselves in this situation, one theme always seems to surface: confusion over what the project manager’s role is. Most functional areas have very clear roles and responsibilities defined and agreed to throughout the organization. This is the result of many years of organizational evolution. Not so for the project manager role, which is still relatively new. In fact, I’ve seen organizations hire several project managers and then tell them to go forth and manage projects without any direction whatsoever. In the absence of any organizational consistency, the success of the project manager becomes largely dependent on personal skills. This is hardly a scalable project management model, and it is actually harmful to widespread adoption of project management methodologies because it creates confusion among team members as they move from project to project and see that all project managers do things a little differently.
Agile Strategy Show the value added of project management to the team by defining, discussing, and gaining agreement on the roles and responsibilities of the project manager, including those that are leadership specific.