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.

Additionally, without a clearly defined role, team members tend to make their own assumptions about the duties of the project manager. The visions usually involve someone telling them what to do and then constantly calling them up to ask if they're done yet. The project manager role is more often perceived as negative than positive. This is another hindrance to PM agility. You will not be able to attain effective agility without the perception that project management is adding considerable value to the project.

Determining official and unofficial project leadership, including the role of the project manager, is difficult because it touches on politics, personalities, and organizational inertia. Effectively implementing these roles is even harder. There is no easy template solution. It's a complex organizational issue that must be addressed by any business striving to become more effective at project management. In Chapter 5, I discuss some ideas for defining the role of the project manager and having that role accepted and embraced in the organization.