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.
Sunday, June 8, 2008
How Often Should Teams Meet?
Teams pose this question to me frequently, especially as they begin formation, or as they enter into a phase shift in their existence (such as from planning phase to execution phase). The answer, I advise, is to specify the minimum necessary to get together and accomplish objectives, and to also be smart enough to know when to add to it or reduce it further. Sometimes holidays and seasonal schedules get in the way, such as a team that meets on Mondays (when holidays tend to fall), or when teams don't have an effective quorum (minimum number of people showing up) when members take vacation time off, especially prone to happening in the summer.
So what happens when a team misses a meeting? I had some recent real-world experience that might be worthwhile to share. A team with whom I work regularly to facilitate and record called off a bi-weekly meeting on a Monday that fell on Memorial Day, a holiday. The team leader decided they would simply skip that meeting, and meet at their next regularly scheduled interval two weeks hence. That meant a month between meetings. What would be the effect?
I planned in advance to observe and identify any adverse effects, and what I saw in this particular team was heartening: 92% attendance of core members (only 1 of 12 persons had an unexcused absence), team members were generally prepared with responses to their action items (they were reminded of such in the agenda issued 3 workdays prior), a new replacement adjunct member showed up and was ready to substitute for someone who recently left the team for a new job, and the team was a lively and engaged group in discussions and debate. In my view, they actually seemed refreshed from not having seen one another in a month, and didn't skip a beat.
Would this "no impact" happen for every team I work with? No, because some team members need the pressure and commitment of a pending team meeting to deliver and complete the tasks they are assigned at a team meeting, otherwise, nothing else forces them to be accountable. They'd simply let the task slip until the next meeting.
The message as I see it: the team leader needs to be savvy enough to know when it's okay to call off a scheduled meeting, and when it necessary to add one in between regular cycles, and not be apprehensive about making either of these moves.
So what happens when a team misses a meeting? I had some recent real-world experience that might be worthwhile to share. A team with whom I work regularly to facilitate and record called off a bi-weekly meeting on a Monday that fell on Memorial Day, a holiday. The team leader decided they would simply skip that meeting, and meet at their next regularly scheduled interval two weeks hence. That meant a month between meetings. What would be the effect?
I planned in advance to observe and identify any adverse effects, and what I saw in this particular team was heartening: 92% attendance of core members (only 1 of 12 persons had an unexcused absence), team members were generally prepared with responses to their action items (they were reminded of such in the agenda issued 3 workdays prior), a new replacement adjunct member showed up and was ready to substitute for someone who recently left the team for a new job, and the team was a lively and engaged group in discussions and debate. In my view, they actually seemed refreshed from not having seen one another in a month, and didn't skip a beat.
Would this "no impact" happen for every team I work with? No, because some team members need the pressure and commitment of a pending team meeting to deliver and complete the tasks they are assigned at a team meeting, otherwise, nothing else forces them to be accountable. They'd simply let the task slip until the next meeting.
The message as I see it: the team leader needs to be savvy enough to know when it's okay to call off a scheduled meeting, and when it necessary to add one in between regular cycles, and not be apprehensive about making either of these moves.
Saturday, June 7, 2008
Virtual Team Coming Together
This past week I had the opportunity to observe a relatively new "virtual" team, perhaps 8 weeks since formation, get together in person for the very first time. This team is comprised of at least 15 persons - including government civil servants, active duty military personnel, and contractors. I say "at least" because the number changes every week based on who calls in. They have been meeting weekly in virtual fashion since early April, using teleconferences supplemented by a nice online package called "GoToMeeting" for sharing documents and keeping everyone on the same page. The majority of the team members are on the U.S. East Coast, but several, including the team leader, are located on the West Coast, a three hour time difference. They're functioning as a project management team, and at this time, and for the next two months or so, they'll be in PMBOK(C) Phase 2 (sometimes referred to as "planning", most commonly a term used by the PMI). Then, in August, some of the work they're planning and scheduling will come to life and get underway - modifications to a ship.
Perhaps a month or so ago, one of the team's principals, the fellow in charge of putting together the master schedule of design changes to the ship, began to plan a "conference" - an in person gathering of the team's key players to discuss their ideas and make decisions on the changes that would be scheduled. This conference would involve a lot of "what if" schedule postulation and discussion, some horse-trading and negotiation of priority projects, and lots of opinions flying around regarding what options were available in terms of satisfying the various external stakeholders (like the operations organization that sends the ship on missions; missions would be sacrificed if the ship was in port getting upgrades).
I spent some time the morning of the first day of the two day "conference" helping the conference leader as the members trickled in to the meeting location in Virginia. They arrived from California and from New Jersey, and from two floors away in the same building. The digital projector was fired up, displays were put up for an agenda, the seats began to fill, and within a half hour there were 18 people in the room. I stayed with the meeting during its entirety for almost seven hours (it was even continued the next day).
I was intrigued with how this team would function as it came together in person for the first time. Would they need some "get to know you" time? Would some be reticent to speak out? Would others attempt to dominate the conversations? Would they have difficulty in reaching consensus oriented decisions? Surprisingly to me, the group functioned well in almost all these regards. They used a flexible agenda, and shared information, opinions, ideas, suggestions, and collectively made decisions on their schedule planning. With the exception of some organizational finger pointing, the team showed little dysfunction. So why did this happen, and what can we learn from it? Here are my opinions:
1. For the most part, everyone demonstrated good listening skills. This was especially evident by the on-the-hot-seat scheduling person (who wasn't the team leader on this day, but who led most of the discussion), and who, along with the team leader, led by example
2. The members showed they could make respectful exchange of ideas without interrupting or showing negative reactions
3. They were polite to one another in terms of their tone, language, and vocal expression (maybe this fades away if they spent more time together!)
4. They appear to have trusted one another, for the most part, from the start. This was especially pleasing to observe since they hailed from different organizations, locations, and vested interests. I can only speculate that most of them gave trust before expecting to have it earned (in other words, "you get my trust unless you do something to violate it"). It also may have been helpful that some of them from disparate locales knew one another from the past - either through common military service or from working on other projects together. This fact alone may have accounted for a significant aspect of why they jelled together so quickly.
It was genuinely impressive to see this virtual team come together for the first time and make real progress on their planning and schedule issues. I don't necessarily expect that this team won't have teamwork problems in the future, but when it mattered to make good use of their limited time, they clicked very fast and worked well together. Would that more teams conducted themselves in this way!
Perhaps a month or so ago, one of the team's principals, the fellow in charge of putting together the master schedule of design changes to the ship, began to plan a "conference" - an in person gathering of the team's key players to discuss their ideas and make decisions on the changes that would be scheduled. This conference would involve a lot of "what if" schedule postulation and discussion, some horse-trading and negotiation of priority projects, and lots of opinions flying around regarding what options were available in terms of satisfying the various external stakeholders (like the operations organization that sends the ship on missions; missions would be sacrificed if the ship was in port getting upgrades).
I spent some time the morning of the first day of the two day "conference" helping the conference leader as the members trickled in to the meeting location in Virginia. They arrived from California and from New Jersey, and from two floors away in the same building. The digital projector was fired up, displays were put up for an agenda, the seats began to fill, and within a half hour there were 18 people in the room. I stayed with the meeting during its entirety for almost seven hours (it was even continued the next day).
I was intrigued with how this team would function as it came together in person for the first time. Would they need some "get to know you" time? Would some be reticent to speak out? Would others attempt to dominate the conversations? Would they have difficulty in reaching consensus oriented decisions? Surprisingly to me, the group functioned well in almost all these regards. They used a flexible agenda, and shared information, opinions, ideas, suggestions, and collectively made decisions on their schedule planning. With the exception of some organizational finger pointing, the team showed little dysfunction. So why did this happen, and what can we learn from it? Here are my opinions:
1. For the most part, everyone demonstrated good listening skills. This was especially evident by the on-the-hot-seat scheduling person (who wasn't the team leader on this day, but who led most of the discussion), and who, along with the team leader, led by example
2. The members showed they could make respectful exchange of ideas without interrupting or showing negative reactions
3. They were polite to one another in terms of their tone, language, and vocal expression (maybe this fades away if they spent more time together!)
4. They appear to have trusted one another, for the most part, from the start. This was especially pleasing to observe since they hailed from different organizations, locations, and vested interests. I can only speculate that most of them gave trust before expecting to have it earned (in other words, "you get my trust unless you do something to violate it"). It also may have been helpful that some of them from disparate locales knew one another from the past - either through common military service or from working on other projects together. This fact alone may have accounted for a significant aspect of why they jelled together so quickly.
It was genuinely impressive to see this virtual team come together for the first time and make real progress on their planning and schedule issues. I don't necessarily expect that this team won't have teamwork problems in the future, but when it mattered to make good use of their limited time, they clicked very fast and worked well together. Would that more teams conducted themselves in this way!
Wednesday, May 28, 2008
Decision making in a project team setting
Have you ever watched how decisions are made in a project team setting? If you really pay attention, they happen more often than you might initially surmise. I suggest you try it sometime soon the next time you attend a meeting - whether a staff meeting or a project team session. Take notes when you perceive a decision being made or, better yet, when there is an opportunity for a decision to be made. Sometimes they're obvious, when a team leader speaks aloud about when the next meeting will take place. Sometimes they're indirect, such as when someone voices a concern over an issue, and it gets brief air time and then the discussion drifts, and voila! there has been a de facto decision about that issue - that there is NO decision rendered. You see, in my opinion, NOT making a decision is tantamount to a decision, because the decision opportunity was exercised, with the result being "no" decision or a "deferred" decision.
Last year I worked with ten product and project management teams for a month during their regular team meetings, and sat in (or listened in) on 25 meetings during that time. My primary motive was to watch (listen) for decisions - if they were made, how they were made, by whom were they made, what types of decisions were made.
Here's what I found:
A. Decision opportunities: an average of 4.6 per meeting, high of 9, low of 1
B. Outcomes: decision reached 51% of the time, meaning 49% of time no decision was made
C. Time to reach decision: average ~10 minutes; high of 2 hours, low (many of them) less than 30 seconds
D. Types of decisions
- Routine: 51% (such as when to hold the next meeting)
- Complex: 49% (has a bearing on cost, schedule, or technical parameters)
E. How and by whom? (more than 100% because many had two features)
- 7% were made unilaterally by team leader
- 59% were made jointly by team leader and other team members
(either by consensus or voting)
- 54% included analysis - inputs, evaluations, or tradeoffs
- 17% included more formal negotiation or escalation to a higher authority
These data are telling about the organization involved, but merely interesting to anyone else.
Are they made in the open or in 'back rooms'? Are decisions ever rescinded? An authoritarian team or organization will have a high percentage of unilateral decisions. A collaborative or inclusive team or organization will be more democratic, and will be made jointly. Recognize too that things change over time, and with the personalities of the leaders that often change (I once tracked team member turnover for 3 consecutive years of a 300+ member organization, and team members turned over at an annual rate of 30%+ each year!).
You might also have the chance to influence some of this by bringing it to the attention of the team leader and other team members. Watch, listen, observe, and learn!
Last year I worked with ten product and project management teams for a month during their regular team meetings, and sat in (or listened in) on 25 meetings during that time. My primary motive was to watch (listen) for decisions - if they were made, how they were made, by whom were they made, what types of decisions were made.
Here's what I found:
A. Decision opportunities: an average of 4.6 per meeting, high of 9, low of 1
B. Outcomes: decision reached 51% of the time, meaning 49% of time no decision was made
C. Time to reach decision: average ~10 minutes; high of 2 hours, low (many of them) less than 30 seconds
D. Types of decisions
- Routine: 51% (such as when to hold the next meeting)
- Complex: 49% (has a bearing on cost, schedule, or technical parameters)
E. How and by whom? (more than 100% because many had two features)
- 7% were made unilaterally by team leader
- 59% were made jointly by team leader and other team members
(either by consensus or voting)
- 54% included analysis - inputs, evaluations, or tradeoffs
- 17% included more formal negotiation or escalation to a higher authority
These data are telling about the organization involved, but merely interesting to anyone else.
Are they made in the open or in 'back rooms'? Are decisions ever rescinded? An authoritarian team or organization will have a high percentage of unilateral decisions. A collaborative or inclusive team or organization will be more democratic, and will be made jointly. Recognize too that things change over time, and with the personalities of the leaders that often change (I once tracked team member turnover for 3 consecutive years of a 300+ member organization, and team members turned over at an annual rate of 30%+ each year!).
You might also have the chance to influence some of this by bringing it to the attention of the team leader and other team members. Watch, listen, observe, and learn!
Monday, May 26, 2008
Robert's Rules of Order - bring larger team meetings to order
Not long ago I delved into something put aside long ago: the notion of applying some of "Robert's Rules of Order" to informal technical project team meetings. First published in 1876 by U.S. Army General Henry M. Robert, it was intended to bring the rules of parliamentary procedure to the use of ordinary societies and their meetings.
Thousands of organizations worldwide use Robert's Rules to guide their meetings - civic associations, clubs, charitable organizations, etc. It is also typically known in brief (1) as the Rules of Order Newly Revised (RONR). It can be adopted into organization and corporate bylaws, and into team or project charters and other records of authorization and formation. The most recent full RONR 10th edition can be purchased at Amazon.com for only $12.24 as of the time of this writing; an "in brief" version, much shorter and concise for a first time reader, can be had for only $6.95. A CD of the full RONR can be ordered from American Legal Publishing for $59.95.
The web site has a very active RONR user group discussion forum. It's certainly not obscure and has highly active and vocal proponents. For instance, on this date, 26 May 2008, a federal holiday (Memorial Day), as of 215pm ET there have been 12 posts with a total of 67 responses.
Another related organization is the National Association of Parliamentarians, based in Independence, MO (hometown of 33rd U.S. President Harry S. Truman!). Founded in 1930, the NAP is the largest non-profit organization of professional parliamentarians in the world. The NAP helps organizations of all sizes conduct business efficiently through education and advocacy of effective meeting procedures and the accreditation of meeting professionals(1).
So if you need to bring a little more order and process to your meetings, even if you're not trying to make them as staid and formal as a session of the U.S. Senate, take a look at Robert's Rules - its web site, its "in brief" book (197 pages), or its full 10th edition publication (704 pages).
You can also see my notes of recommendation for Robert's Rules on my corporate web site, along with my other suggestions, tips, and ideas for effective meeting management.
(1) "RONR" is the standard abbreviation parliamentarians use to cite Henry M. Robert III and others, Robert's Rules of Order Newly Revised, 10th ed. (Cambridge, Mass.: Perseus Publishing, 2000). The standard citation to particular pages and lines is "RONR (10th ed. [for 'edition'], p. [for 'page' or 'pages'], l. [for 'line' or 'lines']."
(2) Cited from the NAP web site http://parliamentarians.org/index.php; downloaded 26May2008
Thousands of organizations worldwide use Robert's Rules to guide their meetings - civic associations, clubs, charitable organizations, etc. It is also typically known in brief (1) as the Rules of Order Newly Revised (RONR). It can be adopted into organization and corporate bylaws, and into team or project charters and other records of authorization and formation. The most recent full RONR 10th edition can be purchased at Amazon.com for only $12.24 as of the time of this writing; an "in brief" version, much shorter and concise for a first time reader, can be had for only $6.95. A CD of the full RONR can be ordered from American Legal Publishing for $59.95.
The web site has a very active RONR user group discussion forum. It's certainly not obscure and has highly active and vocal proponents. For instance, on this date, 26 May 2008, a federal holiday (Memorial Day), as of 215pm ET there have been 12 posts with a total of 67 responses.
Another related organization is the National Association of Parliamentarians, based in Independence, MO (hometown of 33rd U.S. President Harry S. Truman!). Founded in 1930, the NAP is the largest non-profit organization of professional parliamentarians in the world. The NAP helps organizations of all sizes conduct business efficiently through education and advocacy of effective meeting procedures and the accreditation of meeting professionals(1).
So if you need to bring a little more order and process to your meetings, even if you're not trying to make them as staid and formal as a session of the U.S. Senate, take a look at Robert's Rules - its web site, its "in brief" book (197 pages), or its full 10th edition publication (704 pages).
You can also see my notes of recommendation for Robert's Rules on my corporate web site, along with my other suggestions, tips, and ideas for effective meeting management.
(1) "RONR" is the standard abbreviation parliamentarians use to cite Henry M. Robert III and others, Robert's Rules of Order Newly Revised, 10th ed. (Cambridge, Mass.: Perseus Publishing, 2000). The standard citation to particular pages and lines is "RONR (10th ed. [for 'edition'], p. [for 'page' or 'pages'], l. [for 'line' or 'lines']."
(2) Cited from the NAP web site http://parliamentarians.org/index.php; downloaded 26May2008
Memorial Day 2008 - this blog begins
Purpose of this Blog - Today is Memorial Day, and as I begin this Blog, it seems appropriate to outline why I have started it. These are my hopes: to share knowledge and information with others, to learn from others, to serve as a creative outlet, to improve my own written communication skills, to serve as a more permanent record of topics important to me, to leave a bit of a legacy. In my entries, I will maintain the anonymity and confidentiality of the organizations and persons referenced in the stories, unless expressly authorized by them to be identified.
Subscribe to:
Posts (Atom)