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.

click to expand
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.

click to expand
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.

Second, the definition of the term "roles and responsibilities" is often unclear and varies from person to person. Like many miscommunications, this one is often caused because people are hesitant to ask what a simple and common phrase like "roles and responsibilities" means. Agile teams will recognize this confusion and get together to hammer it out. They won't kill themselves to nail down every last detail because they know the team's dynamics may change, but they will come pretty close. Here are two simple definitions of roles and responsibilities that can be used as a starting point for discussion with your team:

  • Your role defines what you do.

  • Your responsibilities are what you decide. This does not include discussing information, performing analysis, or otherwise contributing information to make a decision. Responsibilities are only those areas that you regularly make decisions on for the team.

Agile Strategy

Since members of agile teams always have multiple roles, break them down into primary, secondary, and tertiary groups.

  • Primary Role refers to something that you do regularly and for which you are considered the owner and are held accountable for.

  • Secondary Role pertains to activities that you contribute to regularly.

  • Tertiary Role pertains to activities that you contribute to occasionally.

Do not confuse your role with your time allocation. Time spent on a task does not necessarily affect your role in the project.

Agile Strategy

Break down the responsibilities of team members to avoid confusion regarding decision making in various project areas.

  • Primary Responsibilities are those things that you regularly decide yourself. Someone else may perform analysis or make a recommendation, but you make the go/no-go decision.

  • Secondary Responsibilities are those things for which you are the technical/business leader and primary recommender, but where someone else makes the ultimate decision.

  • Tertiary Responsibilities are those things for which you are on the committee making the recommendation.

Decision making can fall into many categories that often interact with each other, so it's important to think through decisions critically. Common categories include business decisions, technical decisions, administrative decisions, and strategic decisions. It is also a good idea to define decision making at the milestone level, since it is here that many critical elements come together. Agile teams will find that decision making is spread more or less evenly throughout the team and mostly coincides with their primary roles. In general, the agile team will want to push decision making down to the lowest logical level, to avoid decision bottlenecks at the executive management level. Oldstyle teams will find decision making consolidated into a few higherlevel managers where almost everyone, including the project manager, is a recommender. Decisions must be pushed up through the hierarchy before anything substantial is decided (see Figure 4-3). Obviously, this is not the most agile approach.

click to expand
Figure 4-3: Decision making in an agile versus classic environment.

The primary reason that classic PM tends to push decision making up through management is that the project team usually does not have the information to make informed higher-level project decisions. As discussed in Chapter 3, making the project the business is a way for the project manager and project team to gain a higher-level perspective so that they are better able to make these decisions. In all likelihood, truly critical decisions will still be brought to senior management. However, even if intermediate-level decisions can be handled at the project team level, it will reduce management bottlenecks and increase agility.

Agile Strategy

Handle intermediate-level decisions at the project team level to increase agility. These are the decisions that fall in the gray area between the project team and management, thus usually making for longer and repetitive discussions leading to an actual decision.

As you've guessed by now, when defining the team's roles and responsibilities, you very well may have to define them for certain areas of management as well, since almost by definition managers are involved in decision making. Having this discussion with management can be a valuable exercise. Most agile managers want to push decision making downstream, but they may be uncomfortable in doing so. Nonetheless, the project manager and his team will take a powerful step toward agility if they can convince management to let go of some decision-making authority.

Agile Strategy

Discuss the project decision-making strategy directly with management to get their buy-in and make them comfortable with the idea of letting go of some authority.

Escalations

The process of resolving conflicts around decisions through escalations is a subset of decision making that's worthy of additional focus. This is an area that naturally crosses functional boundaries and, as such, can greatly facilitate agility—provided the process is properly worked out during the definition and planning stages of the project, rather than during a crisis in the execution stage. Many teams prefer to focus on defining "roles" and eliminate the discussion of "responsibilities" because they feel that the two are so closely aligned. That's fine, if by the team's definition, they are indeed aligned—however, this often isn't the case. There is usually alignment when responsibilities lie cleanly within a single role or functional area, but the alignment diverges when project complexities force responsibilities to cross multiple roles or functional areas. In these situations, making a decision that rightfully falls within the purview of your responsibilities may influence other people, thus creating the potential for conflict.

For instance, making the decision to modify a product feature because of a technical obstacle may influence the ultimate market position of the modified product, the compatibility with a sister product that is under development by another division, and the overall development costs. While the technical leader should be the owner of this decision, he must realize that it involves the product manager, the technical lead from the sister product, and functional management that will have to furnish additional resources to support the modification. If these people cannot agree on the technical leader's decision or, worse, were never asked in the first place, considerable conflict may arise. Who is going to unravel this mess?

The best way for the agile team to gain traction on this subject is by defining an escalation process—namely, how the team will handle conflicts in the decision-making process. If the team does decide to document responsibilities, then the escalation process should be woven into that definition. If it decides to forgo the definition of responsibilities, then the escalation process should be defined separately for the team, perhaps in the communications plan. (A detailed communications plan template is furnished at the end of this chapter.)

Agile Strategy

Define the process for escalating conflicts on the various types of decisions your team may encounter, either as part of the team responsibilities or in a separate document.

Note: Escalations are focused on conflicts or disagreements about a decision and not the decision itself. Agile teams will want to push the core decision making down to the lowest level and reserve management involvement for conflict resolution.

Often the best escalation process resolves a conflict before it actually has to be escalated at all. To this end, the agile escalation process should include a mediation step, facilitated by a third party, before bringing the problem to management. The project manager is logically this third party and therefore should be fairly skilled in conflict resolution. In fact, conflict resolution (as part of escalation) should probably be listed as a formal role of the project manager.

Agile Strategy

Include a step in the escalation process where the project manager works with the involved parties to resolve the conflict before it is actually escalated to management.

Helping the Project Team Define Its Roles and Responsibilities

Try this exercise. Document your team's current roles and responsibilities as perceived by the individual team members themselves. Have each individual write down what they think their roles and responsibilities are. While this may seem like a straightforward exercise, you are probably going to experience some confusion and debate over what a role is and what a responsibility is. The facilitator of this exercise must have a very good understanding of the differences herself in order to help the team through this question. It is not imperative that you stick strictly to my definitions, but modifications must be defendable and consistent.

Based on your particular team's dynamics, you may decide to create these definitions as a group or one-on-one. I like to have individuals create their roles and responsibilities separately and then present them to the group for discussion because it removes the potential for groupthink. In a group atmosphere, people may feel that they need to confine their roles and responsibilities to things related directly to their functional area. In reality, though, they may see other areas where they can add value. Remember, getting people to expand beyond their usual functional area, to move outside their comfort zone, should be encouraged in an agile environment. This is an opportunity to get individuals more engaged as a team, by making them think about where they can and want to contribute.

Once the whole team is done with their first pass at documenting roles and responsibilities, map the individual roles and responsibilities against the complete universe of roles and responsibilities required for a successful project. If you have not already defined the complete set required for the project, this is a good time to do that. As a team, discuss the following:

  • Are there any gaps (i.e., required roles that are not covered)?

  • Is there any overlap of primary roles?

  • Is there a good distribution of primary and secondary roles among team members?

  • Is there a good distribution of primary and secondary responsibilities among the team?

  • Is the team taking ownership for intermediate-level decisions or pushing them to management?

  • How are escalations handled?

Identification of the right resources and well-defined roles and responsibilities can have a major impact on almost all phases of a project, because without the right expertise working on the right things, the core project plan may be developed leaving critical gaps. For example, each role or responsibility should have one primary owner, but may have several secondary or tertiary contributors. If you don't coverall the bases the potential for problems—rework, delays, overruns—should be obvious. Better yet, cover "extra" bases by anticipating the unexpected. Being agile requires team members to always be looking ahead, watching out for hazards, and surveying the horizon for their next move.

Agile Strategy

Map out the entire universe of roles and responsibilities required for the project and then ensure that there is one, and only one, primary owner for each.




Agile Project Management(c) How to Succeed in the Face of Changing Project Requirements
Agile Project Management: How to Succeed in the Face of Changing Project Requirements
ISBN: 0814471765
EAN: 2147483647
Year: 2006
Pages: 96
Authors: Gary Chin

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net