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.
What Am I Supposed to Do on This Team, Anyway?
As new projects get kicked off, project managers and functional managers alike agree that representatives from the involved functional areas need to participate on the project team. What is missing is an understanding of what all these functional representatives are supposed to do—or more appropriately, a consistent understanding of what they’re supposed to do.
There are usually a few core groups and several support groups involved in projects. Core team members are likely to allocate 100 percent of their time to the project, while support team members may be only 10 percent allocated. This dynamic of teams composed of members with varying time commitments is critical to understand and can affect PM agility.
For dedicated team members, it is generally clear what their role is on the team. It is likely related to development or implementation, and they are accustomed to project work. These team members are looked to as leaders on the team and also tend to have more of a vested interest in the project’s success, given their time and dedication to it. The danger to team agility comes when these dedicated members try to create excessive focus on their specific area of interest, giving it a false level of importance in the overall project and thus overshadowing other important areas. You can legitimately argue that it is your role to be a champion for your functional area; however, it should not be at the expense of other team members. The core team members need to learn to balance their influence on other team members between support of their individual/functional efforts and support of team agility.
It is very easy for an influential team member to fall into the trap of giving orders to other team members (who are perhaps looking for direction, anyway) on tasks that support his particular area alone. While this may indeed advance the core of the project, it potentially can have a negative effect on overall project agility if, for instance, a 20 percent allocated team member spends his limited time supporting the core member instead of his own area. It would be much more beneficial to the overall team effort and dynamics for the core team member to spend a small percentage of his time helping other support team members to get engaged, so they can better contribute to the project.
We will take a closer look at the roles of team members on the agile project later in Chapter 6, which covers the project team.
Agile Strategy Get your whole team engaged in the project by encouraging the core team members to support the support team members.
Roles and Responsibilities
Defining clear roles and responsibilities is something that every project team should get into the habit of doing up-front, and it is especially important when agility is required. When I start working with a project team, either an existing team that I am joining or a new one starting up, I like to know what everyone’s roles and responsibilities are. As a consultant, it helps me develop a “big picture” view of the situation. As a project manager, it helps me to help the team to properly define, plan, and execute the project. And as a participant, it helps me understand what I should and shouldn’t be working on.
In the classic project management paradigm, roles and responsibilities are at least partially defined by your title or by which department you hail from. This works well in very structured organizations that have the luxury of time and that are working on largely familiar projects. It falls apart when urgency and uncertainty are introduced, in which case members need to contribute to and accept aid from all parts of the team. They define their roles and responsibilities by their expertise and their desire to achieve project milestones that are often of a cross-functional nature not seen before in the organization (see Figure 4-1). They understand that they have primary and secondary roles that are entwined with the rest of the team, and that others have roles entwined with theirs.
Figure 4-1: How team member roles are defined in an agile versus classic environment.
In essence, defined roles and responsibilities create boundaries that channel the efforts of the project team. I need to clarify that boundaries, in this case, are not barriers. Boundaries are permeable, flexible, and allow communications and information to cross over them. They allow and enable visibility into the workings of other areas. Boundaries can be thought of as guidelines that help keep individual team members and the whole team heading in the right direction. Barriers, on the other hand, tend to restrict information flow, communications, and visibility. Barriers are remnants of the old “need to know” project management mentality, whereas boundaries are facilitators of agility.
Agile Strategy When defining the roles and responsibilities of individual team members, strive to create boundaries to guide the team, rather than barriers to restrict the team.
In an agile environment, be prepared for roles to change, be swapped, grow, shrink, and be eliminated. This is fun and it’s exciting. Traditional PM defines roles and responsibilities largely to avoid turf battles. Agile PM defines them to encourage others to enter our turf (see Figure 4-2). Team members should want everyone to know what they’re doing because they value their contributions. Likewise, team members should want to make their teammates successful, and it sure helps if they know what they’re working on.
Figure 4-2: Roles and responsibilities in the agile versus classic environment.
In the agile environment, team members need to develop the art of crossing boundaries—not because they want to be involved or share credit for parts of the project, but because diverse contributions are valuable and needed. The agile project environment is complex in nature. It requires people to stretch beyond their traditionally defined areas of expertise to solve multidimensional problems that have never presented themselves before. It used to be that if you didn’t know something, then someone else usually did. In the agile environment, when you don’t know something, you can’t count on someone else. You need to go out and figure it out, perhaps with the help of others, and then educate the team. Everyone needs to move outside his comfort zone. You will be forced to see things from new perspectives, and this is good. In this way, you will be better able to recognize seemingly unrelated events or situations spanning several areas and find ways to pull them together for the benefit of the project.
Agile Strategy Encourage team members to cross boundaries—not to be intrusive, but to identify and create synergy among related or seemingly unrelated parts of the project.
Invariably, everyone agrees that there is great value in having clear roles and responsibilities for the project team. Yet very few teams actually spend the time to define and document them. Some teams may have a brief discussion on the topic but then forget about it. This is actually worse than doing nothing because it gives the team a false impression that there is agreement on the topic when in reality there is not. I have found that there are two primary reasons that an indepth discussion on roles and responsibilities does not happen.
Agile Strategy Allocate the time and energy to adequately define and discuss team roles and responsibilities. Cutting corners in this area can be worse than not doing it at all.
First, people tend to define the roles and responsibilities of their fellow teammates based on their functional area. For example, the marketing guy handles everything related to marketing, right? Well, maybe and maybe not. You may be thinking of product marketing, but the marketing guy is thinking he only handles marketing communication activities. The role of upper management and/or the project sponsor is usually quite fuzzy, too, because they haven’t really given it a great deal of thought, let alone communicated their role to the working team. This situation is definitely not agile and it needs to be figured out.