This is an active topic in my work with project teams. I am attuned to it, so I see it frequently. Many people aren't looking or listening for it. That in itself is a response to conflict - "tuning it out". The model I use most in my training and education is the Thomas-Kilmann Conflict mode (learn more about it here, from Ralph Kilmann's web site). The instrument (30 questions in a booklet) is referred to as the TKI (Thomas-Kilmann Instrument). Quoting from Ralph Kilmann's web site: "it is designed to measure a person's behavior in conflict situations. Conflict situations are those in which the concerns of two people appear to be incompatible. In such situations, we can describe an individual's behavior along two basic dimensions: (1) assertiveness, the extent to which the person attempts to satisfy his own concerns, and (2) cooperativeness, the extent to which the person attempts to satisfy the other person's concerns". Using this as a scale, the instrument categorizes the responses to questions by assigning a numeric value to each of five conflict handling styles: avoid, accommodate, compete, compromise, and collaborate. The numeric value from the TKI response is meant to convey your tendencies toward the use of these styles(highest number reflecting greatest tendency), though it is recognized that we are each capable of any of the styles in a given situation.
The point of using the TKI and exposing project teams to this model is to raise their self awareness and to give them a lens through which to evaluate others and themselves as a group when they face inevitable conflict. Most persons I have educated and trained on this model find it simple and easy to apply. How often they do so is another story! When administering the instrument, I treat the responses as confidential, so I have limited data on tendencies among select populations. A large risk I see is generalizing - such as saying, "Oh yeah, anyone who is a procurement (or contracts, etc) person always tends to be very aggressive, and those people use the COMPETE mode way too often". That's a stereotype I dislike, and I try to enlighten people to look at each person individually, and in certain situations, and recognize our capacity for change in a better way is endless. I'll have more to share on this topic in future posts.
Wednesday, August 27, 2008
Thursday, August 21, 2008
Small Team Leadership
In my professional work I have the opportunity to observe and advise leaders of small project teams. I will begin a series of topics examining the roles, functions, and practices of small team leadership. First, it might be helpful to more succinctly define the term as applied to the entities I will observe.
I define "small" in terms of team headcount - the bell curve hump being between 5 and 15 persons.
I define "project" in terms of member composition - these teams being multi-functional, departmental, multi-firm (and sometimes with multi- and varied objectives and agendas!).
I define "team" only partly consistent with Katzenbach and Smith's definition - "A small number of people with complementary skills who are working to a common purpose". From Katzenbach's definition I replaced 'committed' with 'working', because I do not perceive unwavering commitment by all members. I did not include "..performance goals and approach for which they hold themselves mutually accountable", because I do not usually see a common approach (mostly because of the diversity of organizations who each like to do things in their own way), and the leader does not often establish standards of approach. Mutual accountability is also missing because that same diversity leads to separate standards for acknowledgement and reward (and punishment, if applicable).
This should be an interesting exercise, and I hope to yield some useful perspectives.
I define "small" in terms of team headcount - the bell curve hump being between 5 and 15 persons.
I define "project" in terms of member composition - these teams being multi-functional, departmental, multi-firm (and sometimes with multi- and varied objectives and agendas!).
I define "team" only partly consistent with Katzenbach and Smith's definition - "A small number of people with complementary skills who are working to a common purpose". From Katzenbach's definition I replaced 'committed' with 'working', because I do not perceive unwavering commitment by all members. I did not include "..performance goals and approach for which they hold themselves mutually accountable", because I do not usually see a common approach (mostly because of the diversity of organizations who each like to do things in their own way), and the leader does not often establish standards of approach. Mutual accountability is also missing because that same diversity leads to separate standards for acknowledgement and reward (and punishment, if applicable).
This should be an interesting exercise, and I hope to yield some useful perspectives.
Thursday, June 26, 2008
Meeting Agendas: Topic sequence
Some more thoughts on project team meeting agendas based on my observations of the project teams I currently work with:
When crafting the agenda you should anticipate topic sequence and flow. If your meeting is likely to last an hour or more, remember that energy levels and attention spans will diminish greatly toward the tail end of the hour. My observations during the past year indicate that the shortest-attention span persons pay attention in a meeting for less than 20 minutes before becoming fidgety, show wandering eyes indicating daydreaming, or allow themselves to be distracted by a Blackberry or their laptop, seeming to engage in another activity.
Consider setting topic sequence not by “importance”, but rather according to degree of participation required. Try to put any item that needs participative energy near the beginning of the agenda. Or, conversely, if you know your team well and know how to kick-start them, they might be inclined to do better listening earlier in the agenda (listening topics where they can be still, quiet and contemplative), and do better at talking later in the agenda (engaged topics where they can talk and move around and thus overcome fatigue). And if you exceed an hour, be sure to allow break time to recoup energy and take bio breaks.
When crafting the agenda you should anticipate topic sequence and flow. If your meeting is likely to last an hour or more, remember that energy levels and attention spans will diminish greatly toward the tail end of the hour. My observations during the past year indicate that the shortest-attention span persons pay attention in a meeting for less than 20 minutes before becoming fidgety, show wandering eyes indicating daydreaming, or allow themselves to be distracted by a Blackberry or their laptop, seeming to engage in another activity.
Consider setting topic sequence not by “importance”, but rather according to degree of participation required. Try to put any item that needs participative energy near the beginning of the agenda. Or, conversely, if you know your team well and know how to kick-start them, they might be inclined to do better listening earlier in the agenda (listening topics where they can be still, quiet and contemplative), and do better at talking later in the agenda (engaged topics where they can talk and move around and thus overcome fatigue). And if you exceed an hour, be sure to allow break time to recoup energy and take bio breaks.
Wednesday, June 25, 2008
Meeting Agendas: Get Beyond the Obvious
Many meeting organizers believe they can easily prepare an effective agenda, but for most of us, it takes time and practice to perfect the art of agenda creation. Creating and issuing an agenda for recurring team meetings can be tiresome and tedious –I have too often seen the all-so-human tendency to simply reissue a slight variation of the previous agenda. There are an endless amount of topics that you could cover, but beware: the cardinal sin in the meeting world is meeting just for the sake of meeting. If you don’t have new or useful information to discuss, don’t schedule a meeting. Here are some suggestions to spark some fresh yet pertinent ideas and topics:
- Available stakeholder? Who from outside the team - a genuine stakeholder such as a sponsor, a user, etc – is willing to sit in or call in for five or ten minutes to share their viewpoint, opinion, status, feedback, answer questions, etc? An interested outsider can energize the team, especially if they have a stake in the team’s work.
- Back to the Future. Go back and look at your meeting agendas from the not-so-recent past; hopefully you have them available. What topics were never fully completed and deserve a re-visit? What topics really engaged the team and might be useful to re-address? What have you overlooked during recent meetings?
Don't just issue an agenda while on auto-pilot. Think about what's needed and what's useful!Friday, June 13, 2008
Team Teleconference Protocols
When a team has distributed geography of its members (sometimes called a "virtual team"), the use of audio teleconferencing is a common means of communication and to hold meetings. When there are more than two persons involved in a teleconference (and there certainly would be on a team call!), it is far too common for those communications to fall short of what can be achieved with in-person exchanges. Talkers stumble over one another, discussion move slowly, participants wonder "who said that?" when they don't immediately recognize a voice, people mumble something in the background that you struggle to hear, and we misinterpret something because we have no clues about body and facial language. These problems compound when the number of persons on the teleconference exceeds five or six. In this case I've seen one person can overly dominate the audio exchange, and/or others who want to contribute to the discussion but do not because they think in their minds, "Why bother, it's too difficult to try and say something".
It is my experience that adhering to some basic protocols participants will go a long way to ensure a coherent meeting (eg, for questions and answers) and a common understanding of meeting outcomes. Here are some helpful hints that I've used with teams and audio teleconferencing:
1. Do not assume everyone knows your voice - it may be helpful to state your name as you begin to talk; consider that not all participants may be regular (core) team members
2. Speak clearly, in sufficient volume, and at a reasonable pace so others can better hear and understand when you are speaking; fast rates of speech can easily be distorted or missed
3. Mute any background noise from entering the audio teleconference, which happens frequently with cell phone callers; also don't make noise yourself (tapping pens or fingers) or talk loudly in the background
4. Help everyone understand when you are done speaking. Use a word or a phrase such as “I’m done" or "That’s all" or "Over” to signify that you are done speaking.
5. Be wise when speaking out. Because all participants cannot see one another, they lose the visual clues that tell us we can ‘have the floor’ to speak, or tell the leader that we’d like to speak (like raising your hand). Until/unless the team implements a means to trigger that (eg, someone monitors an IM channel and controls a queue), participants should be patient when wishing to speak out if not called upon. The team leader (or a facilitator) must be especially attuned, ready, and able to enable open discussion while still maintaining order and control.
Audio teleconferencing is a great time and expense saver for teams, but it has its limits (eg, don't use for brainstorming and deep problem solving sessions). Whatever guides or protocols you follow, write them down and agree upon them as a team, and eventually collective enforcement and adaptation will emerge - existing team members will coach and guide new team members on "Here's how we do it on this team".
Training for teams: mandatory or optional?
This topic is a hot button for me, personally, and as one whose role includes being a trainer, I must disclose that I have a professional bias on this topic. I have worked with client organizations that treat it both ways (some make it mandatory, others make it optional). What should you do?
First, let's consider what an initial team training approach might look like:
1. Basic Team Training Content. There are many possibilities here, but in my experience, the minimum basic team training has included topics such as, (a) team member styles (eg, Meyers-Briggs, DISC, Parker Team Player Survey), (b) joint decision making (eg, a survival exercises such as offered by Human Synergistics), (c) a module on trust (eg, with emphasis on the Reina model), and (d) conflict resolution (there are many models and tools in the market, I especially like using Assessing Behavior in Conflict from Alex Hiam). These topics will consume at least one full 8-hour training day. Additional topics would include creative problem solving, listening skills, decision making, and negotiation skills.
2. Delivery of the Training.
a. Group or solo? Topics such as these, in my opinion, should be instructor-led and interactive with others. I have seen several basic team member training offerings, such as by Defense Acquisition University, that are online - which strikes me as an oxymoron! How can someone experience what it's like to make a difficult joint-member team decision when sitting alone at a computer terminal? This type of training needs to be experienced with a group of people, at least four persons in a setting.
b. With home team or not? In other words, should an intact team go through training together? Ideally, yes. However, not always practical, because not all teams are co-located, and more commonly, members are always being added, dropped, and replaced. New and replacement members will almost always, by necessity, have initial team training with people who are not on their team, since their team members have already had training.
c. When? How soon after forming or joining the team? No matter what I would like to suggest, practical considerations are that team members have real work to do, and training is not always high on their list of priorities. In the recent past, my experience for long-term teams has been to allow teams and their members to have 90 days after joining the team to complete their basic team member training. Of course, there has to be training available for them, and not just one event during those 90 days. This kind of time period gives them plenty of slack and undercuts any "I couldn't find the time" excuse, while also getting them early enough in the existence of a long-term team (one that will be in place for a year or more). Shorter duration teams (say, 6 months or less) should shorten this grace period.
So if you've decided what your team's training should consist of, you expect that everyone will readily sign up and get it done, right? Not so fast!!! If it's optional, and members are left to make their own decisions, and are not held accountable to complete it, I have found that up to 80% of any given team population will NOT complete team training during the first six months of their team participation. The "build it and they will come" model simply does not work. Even for those persons who are interested in attending, finding the time can be difficult, and without something to force them to attend, there are too many other distractions and interrupting priorities. Making training mandatory gives team members the impetus to attend, and also gives them a ready rationale to make the time ("Boss, I've got to go to this training, I cannot make the [ever-exciting] staff meeting tomorrow").
The bottom line? If you're serious about building a genuine team, and a real team oriented culture and organizational environment, then you're going to have to make team member training mandatory. This decision is a reflection of your organization's team commitment - would you make ethics training optional? I doubt it, so if you're forming teams to execute a project or manage an operation, get serious and put a mandatory training program in place.
First, let's consider what an initial team training approach might look like:
1. Basic Team Training Content. There are many possibilities here, but in my experience, the minimum basic team training has included topics such as, (a) team member styles (eg, Meyers-Briggs, DISC, Parker Team Player Survey), (b) joint decision making (eg, a survival exercises such as offered by Human Synergistics), (c) a module on trust (eg, with emphasis on the Reina model), and (d) conflict resolution (there are many models and tools in the market, I especially like using Assessing Behavior in Conflict from Alex Hiam). These topics will consume at least one full 8-hour training day. Additional topics would include creative problem solving, listening skills, decision making, and negotiation skills.
2. Delivery of the Training.
a. Group or solo? Topics such as these, in my opinion, should be instructor-led and interactive with others. I have seen several basic team member training offerings, such as by Defense Acquisition University, that are online - which strikes me as an oxymoron! How can someone experience what it's like to make a difficult joint-member team decision when sitting alone at a computer terminal? This type of training needs to be experienced with a group of people, at least four persons in a setting.
b. With home team or not? In other words, should an intact team go through training together? Ideally, yes. However, not always practical, because not all teams are co-located, and more commonly, members are always being added, dropped, and replaced. New and replacement members will almost always, by necessity, have initial team training with people who are not on their team, since their team members have already had training.
c. When? How soon after forming or joining the team? No matter what I would like to suggest, practical considerations are that team members have real work to do, and training is not always high on their list of priorities. In the recent past, my experience for long-term teams has been to allow teams and their members to have 90 days after joining the team to complete their basic team member training. Of course, there has to be training available for them, and not just one event during those 90 days. This kind of time period gives them plenty of slack and undercuts any "I couldn't find the time" excuse, while also getting them early enough in the existence of a long-term team (one that will be in place for a year or more). Shorter duration teams (say, 6 months or less) should shorten this grace period.
So if you've decided what your team's training should consist of, you expect that everyone will readily sign up and get it done, right? Not so fast!!! If it's optional, and members are left to make their own decisions, and are not held accountable to complete it, I have found that up to 80% of any given team population will NOT complete team training during the first six months of their team participation. The "build it and they will come" model simply does not work. Even for those persons who are interested in attending, finding the time can be difficult, and without something to force them to attend, there are too many other distractions and interrupting priorities. Making training mandatory gives team members the impetus to attend, and also gives them a ready rationale to make the time ("Boss, I've got to go to this training, I cannot make the [ever-exciting] staff meeting tomorrow").
The bottom line? If you're serious about building a genuine team, and a real team oriented culture and organizational environment, then you're going to have to make team member training mandatory. This decision is a reflection of your organization's team commitment - would you make ethics training optional? I doubt it, so if you're forming teams to execute a project or manage an operation, get serious and put a mandatory training program in place.
Wednesday, June 11, 2008
The Use and Value of a Project Team Charter
I'm currently working with two teams to prepare new project team Charters: one team already 8 weeks underway, another just forming this month. This caused me to explain to the new team leaders the use and value of a signed project team Charter.
There can be many reasons for having a signed team project Charter. Examples include: (1) authority for the team leader, (2) authorization for the project, (3) commitment by the team members, (4) endorsement and support by sponsoring management, (5) allocating resources for the team by identifying team members and their roles/responsibilities, (6) establishing agreement among stakeholders, (7) identifying team deliverables, (8) setting standards and processes for the team, (9) documenting the project team’s goals so they can be called upon when/if scope is debated. There are further variations on each of these as well.
You might ask: what is the risk of not having a signed Charter? Some risks for the operating tempo of the team – there can be potential disagreements over authority, process, membership, roles and responsibilities. There are risks for auditing and oversight – especially for government agencies and contractors involved in government acquisitions. Oversight agencies such as Inspectors General and the Government Accountability Office (GAO) will almost always ask first for the project team’s Charter when reviewing a project (I have painful experience in this matter....). These kinds of teams should always have a signed project Charter.
Signatures on a Charter can get complicated, and can take a lot of time and may distract the team leader's attention. Accomplishing #6 above can make for multiple signatures (recently, I saw one that was headed for 10+ signatures). This can get very convoluted and may not be worth the time and effort.
Here is a simplifying alternative you can consider: if we want to accomplish #7, 8, 9 above, you can simply have the team leader sign a Charter. It gets something out there, and it can be revised later to add more signatories to bolster stakeholder support, if necessary.
I always recommend some sort of signed project team Charter, even if it doesn't get done before the team forms, though that is ideal. The format doesn't have to be pretty, it doesn't have to be lengthy, and it doesn't have to be formal. What's important is that it represents a documented effort to define the team, which goes a long way toward legitimizing it. And that will help everyone in a variety of circumstances.
There can be many reasons for having a signed team project Charter. Examples include: (1) authority for the team leader, (2) authorization for the project, (3) commitment by the team members, (4) endorsement and support by sponsoring management, (5) allocating resources for the team by identifying team members and their roles/responsibilities, (6) establishing agreement among stakeholders, (7) identifying team deliverables, (8) setting standards and processes for the team, (9) documenting the project team’s goals so they can be called upon when/if scope is debated. There are further variations on each of these as well.
You might ask: what is the risk of not having a signed Charter? Some risks for the operating tempo of the team – there can be potential disagreements over authority, process, membership, roles and responsibilities. There are risks for auditing and oversight – especially for government agencies and contractors involved in government acquisitions. Oversight agencies such as Inspectors General and the Government Accountability Office (GAO) will almost always ask first for the project team’s Charter when reviewing a project (I have painful experience in this matter....). These kinds of teams should always have a signed project Charter.
Signatures on a Charter can get complicated, and can take a lot of time and may distract the team leader's attention. Accomplishing #6 above can make for multiple signatures (recently, I saw one that was headed for 10+ signatures). This can get very convoluted and may not be worth the time and effort.
Here is a simplifying alternative you can consider: if we want to accomplish #7, 8, 9 above, you can simply have the team leader sign a Charter. It gets something out there, and it can be revised later to add more signatories to bolster stakeholder support, if necessary.
I always recommend some sort of signed project team Charter, even if it doesn't get done before the team forms, though that is ideal. The format doesn't have to be pretty, it doesn't have to be lengthy, and it doesn't have to be formal. What's important is that it represents a documented effort to define the team, which goes a long way toward legitimizing it. And that will help everyone in a variety of circumstances.
Subscribe to:
Posts (Atom)