Establishing Team Operating Rules
,PMBOK does not include establishing team operating rules as part of any process group. I believe that having these rules developed and agreed to by every team member is critical to project success. The rules of the engagement will help solve many project-related problems. Project teams all too often fail to define and agree on the team operating rules. This can be a real problem, especially when you are managing a multi-team project. (See Chapter 17 for a lengthy discussion of that type of situation.) These operating rules define how the team works together, makes decisions, resolves conflicts, reports progress, and deals with a host of other administrative chores. Even before the work of the project begins, the team members should agree on how they will work together. This section looks at the areas where operating rules are needed, and then covers the specifics of those operating rules.
Situations that Require Team Operating Rules
Some general situations may arise during the course of a project that will require some action on the part of the team. I have grouped them into the following six action areas:
- Problem solving
- Decision making
- Conflict resolution
- Consensus building
- Brainstorming
- Team meetings
Consider the following questions from Managing the Project Team: The Human Aspects of Project Management, Volume 3, by Vijay K. Verma (Project Management Institute, 1997) that must be answered at some point in the project life cycle:
- What has to be done and where? (Scope)
- Why should it be done? (Justification)
- How well must it be done? (Quality)
- When is it required and in what sequence? (Schedule)
- How much will it cost? (Budget/Cost)
- What are the uncertainties? (Risk)
- Who would do the job? (Human resources)
- How should people be organized into teams? (Communication/Interpersonal skills)
- How will you know if you have done the job? (Information dissemination/Communication)
Each one of these questions will engage one or more of the six action areas listed previously. The team needs to decide ahead of time how it will carry out each of the action areas — that is, the rules of engagement. Now take a look at those action areas in more detail and see what is involved on the part of the team.
Problem Solving
There will be many situations during the course of the project work in which the team will be challenged to figure out how to satisfactorily meet the client's needs while maintaining the schedule and the budget within the assigned resources. Some situations will be easily resolved, whereas others will challenge even the most creative of minds. The problem-solving process is well known, and many variations are in print. Creativity and problem solving go hand in hand. A good problem solver will think outside the box. He or she will conceive of approaches that may have been overlooked. As you will see next, each of the learning styles mentioned earlier in the chapter relates to a different part of the problem-solving model. That means the team must have all learning styles represented in order to solve problems effectively. In this section, you see how those learning styles relate to the problem-solving process.
The model that seems most appropriate for project problem solving is one put forward by J. Daniel Couger in his book Creative Problem Solving and Opportunity Finding (Boyd and Fraser Publishing, 1995). The model is shown in Figure 6-1.
Figure 6-1: Couger's Creative Problem Solving (CPS) model
Couger's process begins with an outside stimulus: Something has arisen that creates an out-of-control situation in the project and must be rectified. That launches a series of actions that clarifies the situation, identifies and assembles relevant data, gets a number of ideas and approaches on the table, and analyzes the ideas. It then selects the idea that would appear most promising as the way to rectify the situation and return it to normal. Finally, an action plan is put in place and executed (the exit point of the model is the action itself). You will see how all of the learning styles are needed to complete each step in the model. Couger identifies the following five steps that make up this problem-solving process:
Step 1: Delineate the opportunity and define the problem — This is a scoping step in which the team members attempt to establish a formulation and definition of the problem and the desired results that a solution to the problem will provide. It helps the team develop the boundaries of the problem — that is, what is in scope and what is out of scope. This step is best performed by team members who have a preference for the assimilator style. These individuals look at the problem independently of any focus on people and try to present the problem at the conceptual level and put it into a logical framework. Their penchant for collecting and concisely reporting data is an early task in this model.
Step 2: Compile the relevant information — With a definition of the problem in hand, the team can now identify and specify the data elements that are needed to further understand the problem and provide a foundation on which possible solutions can be formulated. Again, the assimilator is well suited to this task.
Step 3: Generate ideas — This step typically begins with a brainstorming session. The team should identify as many solutions as possible. This is the time to think outside the box and look for creative and innovative ways to approach a solution. Ideas will spawn new ideas until the team has exhausted its creative energies. The diverger is well suited to the tasks that take place in this step. The job of this individual is to look at the problem from a number of perspectives. Like the assimilator, the diverger also has an interest in collecting data in order to generate ideas, but he or she is not interested in generating solutions.
Step 4: Evaluate and prioritize ideas — In this step, the list of possible solutions needs to be winnowed down to the one or two solutions that will actually be planned. Criteria for selecting the best solution ideas need to be developed (that's a job for the converger), metrics for assessing advantages and disadvantages need to be developed (again, a job for the converger), and then the metrics are used to prioritize the solutions. The calculation of the metric value for each alternative and the ranking of the alternatives based on those metric values are straightforward exercises that anyone on the team can perform. This individual has the ability to take a variety of ideas and turn them into solutions. This person's work is not finished, however, until he or she has established criteria for evaluating those solutions and made recommendations for action.
Step 5: Develop the implementation plan — The solution has been identified, and it's now time to build a plan to implement the solution. This step is a whole-team exercise that draws on the team's collective wisdom for planning and implementation. When it is results that you want, call on the accommodator. His or her contribution will be to put a plan in place for delivering the recommended solution and making it happen. The accommodator is a good person to lead this planning and implementation exercise.
Although this five-step process may seem cumbersome and involved, many of the steps can often be executed in a simple and straightforward manner. Situations requiring a problem-solving effort occur frequently and are often done from start to finish by one team member. Of course, more complex situations will require several team members and the collective creativity of the whole team. The five steps should become second nature to each team member. As team members become familiar with the five steps, the steps will begin to form a commonsense sequence, and they should not be overly burdensome to anyone on the team.
Decision Making
Team members make decisions continuously as they engage in the work of the project. Some of those decisions are obvious and straightforward and may not require the involvement of other team members; other decisions are more complex and may require the involvement and active participation of the team, the client, and even people outside of the project. The three major types of decision-making models are as follows:
Directive — In this model, the person with the authority (the project manager for the project and the task manager for the task) makes the decision for all team members. Although this approach is certainly expedient, it has obvious drawbacks. The only information available is the information that the decision maker possesses, which may or may not be correct or complete. An added danger is that those who disagree or were left out of the decision may be resistant or unwilling to carry it out. A directive approach is often used when time is of the essence and a decision is needed immediately. It makes no sense to hold a committee meeting to get everyone's input before proceeding.
Participative — In this model, everyone on the team contributes to the decision-making process. A synergy is created as the best decision is sought. Because everyone has an opportunity to participate, commitment will be much stronger than in the directive approach. Obviously, there is an additional benefit to team building — empowerment of the team. I recommend that you use this participative approach whenever possible. Because the team members have a chance to participate in the decision-making process, they will be much more committed to the decision that is made and more likely to support it during implementation. From a political perspective, the project manager is much better off using this approach than a directive approach.
Consultative — This middle-ground approach combines the best of the other two approaches. The person in authority makes the final decision, but this decision is made only after consulting with all members to get their input and ideas. This approach is participative at the input stage but directive at the point of decision making. In some cases, when expediency is required, this approach is a good one to take. Rather than having to involve the entire team, the project manager can decide whose input should be sought and then make the decision based on that input. Politically this is a very good strategy, and it can have positive effects on those whose input was sought.
Selecting the Appropriate Decision-Making Model
Selecting a model to use in a specific situation is generally a function of the gravity and time sensitivity of the pending decision. Some organizations have constructed categories of decisions, with each category defined by some financial parameters, such as the value of the decision, or by some scope parameters, such as the number of business units or clients affected by the decision. The person responsible for making the decision is defined for each decision category — the more serious the category, the higher the organizational level of the decision maker. Some decisions might be made by an individual team member, some by a task manager, some by the project manager, some by the client, and some by senior management. Yet others might require a group decision, using either a participative or a consultative approach.
Decision Making and the Learning Styles Inventory
Just as the LSI relates to the problem-solving process as discussed earlier in the chapter, it also relates to the decision-making process. Although decision making and problem solving are closely related, it is instructive for you to see just how the LSI relates to decision making as well. Problem solving cannot happen without some decisions having been made. In that sense, decision making can be thought of as a subset of problem solving.
Decision making can also occur outside of the problem-solving context. For example, suppose a project is behind schedule and the design phase is not yet complete. You could start some preliminary programming, but you risk having to rework some of this programming when the design is complete. Do you begin programming to make up lost time and take the risk, or do you wait for the design to be finished before you begin programming? This is clearly a decision-making situation and not a problem-solving one.
Decision making is pervasive throughout the life of the project. How will the project team make decisions? Will they be based on a vote? Will they be a result of team consensus? Will they be left up to the project manager? Just how will the team operate?
Determining how decisions are made is only one piece of the puzzle. Another piece is whether the team can make a decision, and if not, what they do about it. This section takes a closer look at the decision-making environment that the project team faces.
In their book Organizational Behavior in Action: Skill Building Experiences (West Publishing, 1976), William C. Morris and Marshall Sashkin propose a six-phase model for rational decision making. The six phases in their approach are outlined in the list that follows. However, as I have indicated, there is a lot of similarity between using the LSI in problem solving and in decision making, and the following list also reflects how the LSI applies to Morris and Sashkin's rational decision making in a way similar to how it applied to Couger's problem-solving process.
Phase I: Situation definition — This phase is one of discovery for the team, clarifying the situation to ensure a shared understanding of the decision the team faces. Phase I requires the services of an assimilator. As part of the process of discovery, the assimilator will collect data and information and formulate the situation and the required decision.
Phase II: Situation decision generation — Through brainstorming, the team tries to expand the decision space in search of alternative decisions. This is the province of the diverger, although it is a collaborative effort because it continues to involve the assimilator in a definition type of task.
Phase III: Ideas to action — Metrics are devised to attach a reward and penalty to each possible decision that might be made. With the alternatives identified, the work can be turned over to the converger in Phase III. His or her job is to establish criteria. This person's work is complete when a plan for implementing the decision is in place in Phase IV.
Phase IV: Decision action plan — The decision has been made, and the development of a plan to implement it is now needed. In this phase, the accommodator takes over and implements the decision.
Phase V: Decision evaluation — This phase is kind of a post-decision audit of what worked and what didn't work. Some lessons learned will be the likely deliverable as well. The team, under the direction of an accommodator, will take an honest look at how effective the decision was.
Phase VI: Evaluation of the outcome and process — The team needs to determine whether the decision got the job done and whether another attempt at the situation is needed. An evaluation of the results from Phase IV puts the work back into the hands of the assimilator. If the expected results were not attained, another round may be required.
Table 6-1 provides a summary of the six decision-making phases and the required learning styles.
This discussion has been brief and is only a summary of a complex and interesting topic. The decision-making model discussed here is described in more detail in my book Building Effective Project Teams (Wiley, 2001).
Table 6-1: The Six Phases of the Decision-Making Process
Conflict Resolution
The next area for which operating rules are needed deals with how the team resolves conflicts. Conflicts arise when two or more team members have a difference of opinion, when the client takes issue with an action to be taken by the project team, or in a variety of other situations involving two parties with different points of view. In all of these examples, the difference must be resolved. Clearly, conflict resolution is a much more sensitive situation than the decision-making rule because it is confrontational and situational, whereas the decision-making rule is procedural and structured. Depending on the particular conflict situation, the team might adopt one of the following three conflict resolution styles:
Avoidant — Some people will do anything to avoid a direct confrontation. They agree even though they are opposed to the outcome. This style cannot be tolerated on the project team. Each person's input and opinion must be sought. It is the responsibility of the project manager to ensure that this happens. A simple device is to ask all of the team members in turn what they think about the situation and what they suggest should be done about it. Often this approach will defuse any direct confrontation between two individuals on the team.
Combative — Some people avoid confrontation at all costs; others seem to seek it out. Some team members play devil's advocate at the least provocation. At times this is advantageous — testing the team's thinking before making the decision. At other times it tends to raise the level of stress and tension, when many team members will see it as a waste of time and not productive. The project manager must be able to identify these combative team members and act to mitigate the chances of these combative situations arising.
One technique I have used with success is to put potentially combative individuals in charge of forming a recommendation for the team to consider. Such an approach offers less opportunity for combative discussion because the combative team member is sharing recommendations before others give reasons for disagreement.
Collaborative — In this approach, the team looks for win-win opportunities. The approach seeks a common ground as the basis for moving ahead to a solution. This approach encourages each team member to put his or her opinions on the table and not avoid any conflict that may result. At the same time, team members do not seek to create conflict unnecessarily. This approach is constructive, not destructive.
Further discussion of conflict resolution styles is beyond the scope of this book. You can consult several resources on the topic. Two that I have found particularly helpful are “Conflict and Conflict Management” by Kenneth Thomas in The Handbook of Industrial and Organizational Psychology (Wiley, 1983) and The Dynamics of Conflict Resolution: A Practitioner's Guide by Bernard S. Mayer (Jossey-Bass, 2000). Of particular importance are the variety of collaborative models that might be adopted.
Consensus Building
Consensus building is a process used by the team to reach agreement on which among several alternatives to follow. The agreement is not reached by a majority vote, or any vote for that matter. Rather, the agreement is reached through discussion, whereby each participant reaches a point when he or she has no serious disagreement with the decision that is about to be made. The decision will have been revised several times for the participants to reach that point.
Consensus building is an excellent tool to have in the project team toolkit. In all but a few cases, there will be a legitimate difference of opinion as to how a problem or issue should be addressed, where no clear-cut actions can be agreed upon. In such situations, the team must fashion an action or decision with which no team members have serious disagreement even though they may not agree in total with the chosen action. To use the method successfully, make sure that everyone on the team has a chance to speak. Talk through the issue until an acceptable action is identified. Conflict is fine, but try to be creative as you search for a compromise action. As soon as no one has serious objections to the defined action, you have reached a consensus. After a decision is reached, all team members must support it.
If you (as the project manager) choose to operate on a consensus basis, you must clearly define the situations in which consensus will be acceptable and convey this to your team.
Brainstorming
Brainstorming is an essential part of the team operating rules because, at several points in the life of the project, the creativity of the team will be tested. Brainstorming is a technique that can focus creativity and help the team discover solutions. In some situations, acceptable ideas and alternatives do not result from the normal team deliberations. In such cases, the project manager might suggest a brainstorming session. A brainstorming session is one in which the team contributes ideas in a stream-of-consciousness mode, as described in the next paragraph. Brainstorming sessions have been quite successful in uncovering solutions where none seemed present. The team needs to know how the project manager will conduct such sessions and what will be done with the output.
Here is a simple and quick method for brainstorming:
- Assemble any individuals whether they are team members, consultants, or others who may have some knowledge of the problem area. They don't need to be experts. In fact, it may be better if they are not. You need people to think creatively and outside the box. Experts tend to think inside the box.
- The session begins with everyone throwing any idea out on the table. No discussion (except clarification) is permitted. This continues until no new ideas are forthcoming. Silence and pauses are fine.
- After all the ideas are on the table, discuss the items on the list. Try to combine ideas or revise ideas based on each member's perspective.
- In time, some solutions will begin to emerge. Don't rush the process, and by all means test each idea with an open mind. Remember that you are looking for a solution that no individual could identify but that you hope the group is able to identify collectively.
This is a creative process, one that must be approached with an open mind. Convention and “we've always done it that way” have no place in a true brainstorming session.
Team Meetings
The project manager and the project team need to define and agree upon team meetings in terms of frequency, length, meeting dates, agenda preparation and distribution, who calls the meeting, and who is responsible for recording and distributing the minutes. The entire team needs to participate in and understand the rules and structure of the meetings that will take place over the life of the project. Different types of team meetings, perhaps with different rules governing their conduct and format, may occur.
Team meetings are held for a variety of reasons, including problem definition and resolution, scheduling work, planning, discussing situations that affect team performance, and decision making. The team needs to decide on several procedural matters, including the following:
Meeting frequency — How often should the team meet? If it meets too frequently, precious work time will be lost. If it meets too infrequently, problems may arise and the window of opportunity may close before a meeting can be held to discuss and solve these problems. If meetings happen too infrequently, the project manager risks losing control over the project. Meeting frequency will vary according to the length and size of the project. There is no formula for frequency. The project manager must simply make a judgment call.
Agenda preparation — When the project team is fortunate enough to have a project administrative assistant, that person can receive agenda items and prepare and distribute the agenda. In the absence of an administrative assistant, the assignment should be rotated to each team member. The project manager may set up a template agenda so that each team meeting covers essentially the same general topics.
Meeting coordinator — Just as agenda preparation can be circulated around to each team member, so can the coordination responsibility. Coordination involves reserving a time, a place, and equipment.
Recording and distributing meeting minutes — Meeting minutes are an important part of project documentation. In the short term, they are the evidence of discussions about problem situations and change requests, the actions taken, and the rationale for those actions. When confusion arises and clarifications are needed, the meeting minutes can settle the issue. Recording and distributing the minutes are important responsibilities and should not be treated lightly. The project manager should establish a rotation among the team members for recording and distributing the meeting minutes.
Daily Status Meetings
For some of you, this will seem like overkill and not something you want to engage in. You can already see the expressions on your team members' faces when you announce that there will be daily team meetings. I remember the first time I encountered the daily team meeting. I reacted the same way, but I quickly changed my mind, as I hope you will change yours. This is one of those “try it, you'll like it” cases.
For one thing, the meeting lasts only 15 minutes and everybody stands. The attendees are the task managers of all tasks that are open for work and are not yet completed. In other words, the scheduled start date for the task has passed, and the work on it is not yet complete. The only valid reports for such a task are as follows:
- I'm on plan.
- I am x hours behind schedule but have a plan to be caught up by this time tomorrow.
- I am x hours behind plan and need help.
- I am x hours ahead of plan and available to help with other tasks.
There is no discussion of solutions to schedule slippages. There is no taking of pizza orders for lunch or other irrelevant discussions. Such discussions are taken offline and involve only the team members who are affected by the problem or issue being raised.
You'll probably experience a learning curve for this process. My first 15-minute team meeting took 45 minutes, but the team quickly learned to bring the meeting time within the 15-minute limit and within the next few meetings were inside the 15-minute window consistently.
CASE STUDY – PIZZA DELIVERED QUICKLY (PDQ)
Due to the complexity and lack of clarity in defining the solution, daily meetings are essential. For outside contractors, this may not be their cup of tea. The challenge to the project manager is to get a firm commitment from the contractors. They must feel like part of the team for this to happen.
Problem Resolution Meetings
Problem resolution should never be handled in the team status meeting. Instead, a special meeting should be called and the attendees should include only the team members directly involved in the problem or its solution. The reason you don't deal with problems in the team status meeting is that not everyone in attendance will have an interest in or connection to the problem. You don't want to waste team members' time by having them sit through a discussion of something that does not involve them or interest them.
The problem resolution meeting should be planned around the problem-solving methodology discussed previously.
Project Review Meetings
These are formal meetings held at milestone events or other defined points in the life of the project. Oftentimes the stage gate that passes a project from one phase to another is used as the time for a project review meeting. These meetings are attended by the project manager, the client, the sponsor, stakeholders, a senior manager who officiates, and two or three technical subject matter experts (such as managers of similar projects). The project manager may invite others whose input will be valuable to the review. The meeting focuses on any variances from the plan, and identifying corrective action steps as suggested by the subject matter experts present. If this is not the first project review meeting for the project, there might also be a status review of corrective action steps recommended from previous project review meetings.
Team War Room
In the ideal setting, the team war room is the physical facility that the team owns during the lifetime of the project. Ideally all team members are co-located there, and all team meetings take place there. However, I recognize that this is not possible for all projects, so some variations are discussed in the sections that follow.
Physical Layout
Ideally, all of the walls are covered with whiteboards. Depending on the size of the team, the team war room may be one large room that accommodates everyone or several smaller rooms that are adjacent to a larger community-type room for group meetings and presentations. These adjacent rooms can double as breakout rooms. Each team member has his or her own private workspace, but there is a minimum number of partitions. A line of sight between each team member is ideal. The project artifacts are displayed so everyone has immediate access.
Variations
I realize that the preceding physical layout may seem idealistic, but several vendors and consulting companies that I have worked with make it a point to provide such facilities for their teams. A few of my clients have even designed their space with the thought of accommodating team war rooms and providing such space when the vendor cannot.
The first ideal to be sacrificed is co-location. In the global marketplace, project teams and the client are often spread over the globe. The cost of face-to-face meetings is prohibitive (travel expenses) and getting everyone to these meetings is a great waste of time (unproductive time while en route). While being geographically distributed has a few advantages (a 24-hour work day for example), it does create a logistics nightmare for the project manager and team members. In place of trying to schedule face-to-face meetings, teleconferences and even video conferences have become affordable and commonplace.
The second ideal to be sacrificed is the co-located team room. Many organizations simply do not have contiguous spaces they can release to a team for the duration of their project. Space is at a premium and has to be shared. In these situations, the project artifacts must be mobile rather than fixed. Although this may be an inconvenience, it is not a show stopper. Electronically posting the artifacts is another workaround.
The third ideal to be sacrificed is 100-percent assignment to a project. The commitments, loyalties, and priorities of the project team members may be spread over two or more projects as well as their home assignments.
Operational Uses
A well-planned team war room is not only for the use of the team as it conducts the work of the project, but it also serves other needs of the project. All scoping, planning, kick-off, status, and review meetings will take place there. Depending on the layout, parts of the space may be reserved for use by others outside the project on an as-needed and as-available basis. This will partially alleviate a space shortage problem for some organizations.