Situations Matter: Understanding How Context Transforms Your World
is the highly acclaimed book by Sam Sommers which explains the many ways in which situations influence our thoughts and behaviors. I believe that understanding these situational concepts are invaluable tools that a Project Manager can use to develop a productive project team.
The key concepts presented in Situations Matter are:
· WYSISYG (What You See Is What You Get)
· Help Wanted
· Go with the Flow
· You’re Not the Person You Thought You Were
· Love
· Hate
For more details on the book please refer to my review.
Ironically what I have taken away from Sommers’ writing is that in order to develop a successful project team we first create a new ‘in-group’ project crowd to eliminate biases and bring the team together but then second we need to establish individual identities to keep each person from falling prey to the crowd mentality and paralyzing group norms.
In the remainder of this posting I will explore how three of these key situational concepts (Hate, Go With the Flow, Help Wanted and You’re Not the Person You Thought You Were) can be applied to developing a productive project team.
Hate – Although Hate is the last section of Situation Matters, we need to consider it first when developing a project team. Hopefully it is obvious that Project Managers should not advocate hate on any project, but instead to eliminate hate. The word hate may be a little strong here, so instead we should focus on eliminating biases or misconceptions that could negatively impact a project team.
Based on Sommers’ research we learn that a common origin of misconceptions is how we classify people or object by putting them in groups. ‘In groups’ are those that we belong to, such as when we indentify ourselves with our own nationality, race, profession, religion or even project team. Conversely we place those who don’t fit into our ‘in groups’ into ‘out groups’. People from other counties, races or project teams can be examples of our ‘out groups’.
For members of our ‘in groups’, we more commonly associate traits to individual members, where as we will typically generalize traits across everyone in the particular ‘out group’. Unfortunately when these ‘out groups’ involve race or religion is when we start seeing hate and its negative consequences.
On projects we typically and unconsciously associate support groups as the ‘out groups’. These support groups perform organizational functions that are not involved in the day to day project tasks, but instead are needed for specific highly specialized tasks. On IT development projects for example, common support groups may be Procurement and Network Support.
Issues that impede team development can arise when we generalize traits to these project ‘out groups’. Have you ever heard these types of comments on your project?
"The Contracts group is such a bottleneck; they never get us the resources we need on time."
"That Database group is so difficult to work with; they are always complaining and are never helpful."
Sound familiar?
These types of generalization will ultimately cause conflict on your project.
The solution is to bring these ‘out group’ members into a project ‘in group’. This will allow us to associate individual traits to our new ‘in group’ members. Our goal is to turn the above comment regarding the Contracts Group into; "Wow, Frank from Contracts is very diligent and detail oriented!" Notice how we now refer to the individual instead of the group. This is subtle but very significant in terms of team development.
To accomplish this change, Project Managers must take the necessary steps to bring all team contributors into the ‘in group’. This can be achieved by using a number of easy strategies, including the following two. The first is to identify all contributors on team lists and charts. Although this may seem burdensome it is a relatively simple effort. If this makes your lists and team charts too busy, there is nothing that says you cannot have multiple team charts; one that contains the core team (those involved in day to day tasks) which your organization may typically require, and one that shows the extended team with the supporting groups.
The second strategy is to communicate to the supporting team members on a regular basis, even if they are not yet involved in any project activities. For example identify and communicate with Training and Help Deck staff from the beginning of the project, well before they are assigned tasks. These communications can be in many forms from inviting them to status meetings to including them on project updates.
Many times I have seen Project Managers struggle with the most efficient approach for including supporting team members, especially in the regular (daily or weekly) team meetings. The last thing that anyone wants is to have someone attend an hour long status meeting every week which is a perceived waste of their time. If this is the case then the Project Manager should consider holding separate less frequent meeting with supporting team members to keep them up to date and involved. In these cases, you can also consider a monthly extended team meeting to keep everyone in touch and communicating!
The Project Managers’ Challenge – overcome the ‘out group’ misconceptions by brining all the project team contributors into the project ‘in group’.
The good news is that you have now built a project team crowd; the bad news is if you have work on avoiding the crowd mentality and paralyzing group norms.
Go With the Flow/Help Wanted – As most anyone who has extensive experience with groups will know it does not take long for group norms to be established. These norms can range from the trivial, everyone sitting in the same seat in the meeting room each week, to the disastrous, an atmosphere where issues and risks are not brought forward. I have seen too many times where project team members feel there is pressure against them from speaking up and raising their concerns on a project.
As Sommers points out, the key to breaking people from the crowd norms is to emphasize individual identity. There are two effective ways that a Project Manager can emphasize individual identity, by: 1) modeling desired behavior and 2) directing requests to specific individuals.
Behavioral research has shown that just one person breaking from the norm can move the whole group away from a paralyzing norm. If your team is stuck in a group norm, break the norm yourself - choose a different seat at your next meeting! More seriously, if your team seems reluctant to talk about risks, start the conversation yourself. Trying something like this, “I am really worried about….”. Make it something you are really worried about because this approach will hopefully generate discussion, as long as you are coming across as genuinely interested in the team’s ideas.
The next method is to direct requests to specific individuals. Following the above example, once you discuss your concern, you should next solicit the concerns of others. Don’t just ask the entire group, but target a specific person, “Mary what is your biggest concern for the project going forward?” This technique is also useful when needing a volunteer or soliciting feedback. You can call on specific individuals either in a meeting or via e-mail.
Try this, if you are looking for review and feedback on a specific document or idea that you would normally send to a group, instead send the same request to everyone in the group individually and see if the latter approach leads to more responses. I am betting it does. Research shows you will get more responses and as an added benefit the individual recipients will feel more valued.
The Project Managers’ Challenge – break the paralyzing group norms!
These techniques may sound easy and you know what? You are right; they actually are easy to implement and can produce dramatic results.
One other important topic from Situations Matter that I want to conclude with is to keep context in mind when defining your team members.
You’re Not the Person You Thought You Were – In Situations Matter, Sommers demonstrates how at various times and situations we will view ourselves differently. We can apply this concept on projects by resisting our tendency to define team members. As when we view ourselves we need to consider context and situation when defining others.
The result of considering context and situations is that we should never simply classify someone as a ‘good’ or ‘bad’ performer. Instead we need to understand the situations (or project roles) on which a person excels and the situations under which they don’t perform as well as expected.
Unfortunately too many Project Managers will classify someone as a non-productive team member and immediately look to replace them. This is very unfair to the individual and can send the wrong message to the rest of the team. In these situations I first try to understand why the individual is performing below expectations. Maybe they don’t know what their expected performance is, or maybe they are not getting needed direction or resources needed to complete their tasks. In other words we need to identify if there is a situational factor which is the real cause of the poor performance.
If there are no identifiable situational factors causing the performance issues, I next look at where we may be able to use the resource elsewhere on the project or another project before removing them altogether. I believe almost anyone can bring value to a team if the appropriate role can be found which will match their knowledge, skills and abilities.
It should almost go without saying but happier team members are typically more productive contributors to a project. One reason for this as Sommers points out is that happier people think they have more influence on a situation even when they don't. I believe this leads them to be more productive and active contributors to a project.
The Project Managers’ Challenge – consider context and situation when reviewing team members and keep everyone happy and productive!
Summary
Project Managers need to take situation into account throughout the life of a project in order to build and maintain a productive team. The critical steps in the process are:
· Create the Project ‘In Group’
· Avoid or remove paralyzing group norms
· Consider situation and context when reviewing performance
For more insight I highly recommend reading Situations Matter. In the meantime try some of the tips discussed above and leave your comments.
is the highly acclaimed book by Sam Sommers which explains the many ways in which situations influence our thoughts and behaviors. I believe that understanding these situational concepts are invaluable tools that a Project Manager can use to develop a productive project team.The key concepts presented in Situations Matter are:
· WYSISYG (What You See Is What You Get)
· Help Wanted
· Go with the Flow
· You’re Not the Person You Thought You Were
· Love
· Hate
For more details on the book please refer to my review.
Ironically what I have taken away from Sommers’ writing is that in order to develop a successful project team we first create a new ‘in-group’ project crowd to eliminate biases and bring the team together but then second we need to establish individual identities to keep each person from falling prey to the crowd mentality and paralyzing group norms.
In the remainder of this posting I will explore how three of these key situational concepts (Hate, Go With the Flow, Help Wanted and You’re Not the Person You Thought You Were) can be applied to developing a productive project team.
Hate – Although Hate is the last section of Situation Matters, we need to consider it first when developing a project team. Hopefully it is obvious that Project Managers should not advocate hate on any project, but instead to eliminate hate. The word hate may be a little strong here, so instead we should focus on eliminating biases or misconceptions that could negatively impact a project team.
Based on Sommers’ research we learn that a common origin of misconceptions is how we classify people or object by putting them in groups. ‘In groups’ are those that we belong to, such as when we indentify ourselves with our own nationality, race, profession, religion or even project team. Conversely we place those who don’t fit into our ‘in groups’ into ‘out groups’. People from other counties, races or project teams can be examples of our ‘out groups’.
For members of our ‘in groups’, we more commonly associate traits to individual members, where as we will typically generalize traits across everyone in the particular ‘out group’. Unfortunately when these ‘out groups’ involve race or religion is when we start seeing hate and its negative consequences.
On projects we typically and unconsciously associate support groups as the ‘out groups’. These support groups perform organizational functions that are not involved in the day to day project tasks, but instead are needed for specific highly specialized tasks. On IT development projects for example, common support groups may be Procurement and Network Support.
Issues that impede team development can arise when we generalize traits to these project ‘out groups’. Have you ever heard these types of comments on your project?
"The Contracts group is such a bottleneck; they never get us the resources we need on time."
"That Database group is so difficult to work with; they are always complaining and are never helpful."
Sound familiar?
These types of generalization will ultimately cause conflict on your project.
The solution is to bring these ‘out group’ members into a project ‘in group’. This will allow us to associate individual traits to our new ‘in group’ members. Our goal is to turn the above comment regarding the Contracts Group into; "Wow, Frank from Contracts is very diligent and detail oriented!" Notice how we now refer to the individual instead of the group. This is subtle but very significant in terms of team development.
To accomplish this change, Project Managers must take the necessary steps to bring all team contributors into the ‘in group’. This can be achieved by using a number of easy strategies, including the following two. The first is to identify all contributors on team lists and charts. Although this may seem burdensome it is a relatively simple effort. If this makes your lists and team charts too busy, there is nothing that says you cannot have multiple team charts; one that contains the core team (those involved in day to day tasks) which your organization may typically require, and one that shows the extended team with the supporting groups.
The second strategy is to communicate to the supporting team members on a regular basis, even if they are not yet involved in any project activities. For example identify and communicate with Training and Help Deck staff from the beginning of the project, well before they are assigned tasks. These communications can be in many forms from inviting them to status meetings to including them on project updates.
Many times I have seen Project Managers struggle with the most efficient approach for including supporting team members, especially in the regular (daily or weekly) team meetings. The last thing that anyone wants is to have someone attend an hour long status meeting every week which is a perceived waste of their time. If this is the case then the Project Manager should consider holding separate less frequent meeting with supporting team members to keep them up to date and involved. In these cases, you can also consider a monthly extended team meeting to keep everyone in touch and communicating!
The Project Managers’ Challenge – overcome the ‘out group’ misconceptions by brining all the project team contributors into the project ‘in group’.
The good news is that you have now built a project team crowd; the bad news is if you have work on avoiding the crowd mentality and paralyzing group norms.
Go With the Flow/Help Wanted – As most anyone who has extensive experience with groups will know it does not take long for group norms to be established. These norms can range from the trivial, everyone sitting in the same seat in the meeting room each week, to the disastrous, an atmosphere where issues and risks are not brought forward. I have seen too many times where project team members feel there is pressure against them from speaking up and raising their concerns on a project.
As Sommers points out, the key to breaking people from the crowd norms is to emphasize individual identity. There are two effective ways that a Project Manager can emphasize individual identity, by: 1) modeling desired behavior and 2) directing requests to specific individuals.
Behavioral research has shown that just one person breaking from the norm can move the whole group away from a paralyzing norm. If your team is stuck in a group norm, break the norm yourself - choose a different seat at your next meeting! More seriously, if your team seems reluctant to talk about risks, start the conversation yourself. Trying something like this, “I am really worried about….”. Make it something you are really worried about because this approach will hopefully generate discussion, as long as you are coming across as genuinely interested in the team’s ideas.
The next method is to direct requests to specific individuals. Following the above example, once you discuss your concern, you should next solicit the concerns of others. Don’t just ask the entire group, but target a specific person, “Mary what is your biggest concern for the project going forward?” This technique is also useful when needing a volunteer or soliciting feedback. You can call on specific individuals either in a meeting or via e-mail.
Try this, if you are looking for review and feedback on a specific document or idea that you would normally send to a group, instead send the same request to everyone in the group individually and see if the latter approach leads to more responses. I am betting it does. Research shows you will get more responses and as an added benefit the individual recipients will feel more valued.
The Project Managers’ Challenge – break the paralyzing group norms!
These techniques may sound easy and you know what? You are right; they actually are easy to implement and can produce dramatic results.
One other important topic from Situations Matter that I want to conclude with is to keep context in mind when defining your team members.
You’re Not the Person You Thought You Were – In Situations Matter, Sommers demonstrates how at various times and situations we will view ourselves differently. We can apply this concept on projects by resisting our tendency to define team members. As when we view ourselves we need to consider context and situation when defining others.
The result of considering context and situations is that we should never simply classify someone as a ‘good’ or ‘bad’ performer. Instead we need to understand the situations (or project roles) on which a person excels and the situations under which they don’t perform as well as expected.
Unfortunately too many Project Managers will classify someone as a non-productive team member and immediately look to replace them. This is very unfair to the individual and can send the wrong message to the rest of the team. In these situations I first try to understand why the individual is performing below expectations. Maybe they don’t know what their expected performance is, or maybe they are not getting needed direction or resources needed to complete their tasks. In other words we need to identify if there is a situational factor which is the real cause of the poor performance.
If there are no identifiable situational factors causing the performance issues, I next look at where we may be able to use the resource elsewhere on the project or another project before removing them altogether. I believe almost anyone can bring value to a team if the appropriate role can be found which will match their knowledge, skills and abilities.
It should almost go without saying but happier team members are typically more productive contributors to a project. One reason for this as Sommers points out is that happier people think they have more influence on a situation even when they don't. I believe this leads them to be more productive and active contributors to a project.
The Project Managers’ Challenge – consider context and situation when reviewing team members and keep everyone happy and productive!
Summary
Project Managers need to take situation into account throughout the life of a project in order to build and maintain a productive team. The critical steps in the process are:
· Create the Project ‘In Group’
· Avoid or remove paralyzing group norms
· Consider situation and context when reviewing performance
For more insight I highly recommend reading Situations Matter
. In the meantime try some of the tips discussed above and leave your comments.
Very insightful for Groups, applying the research from Prof. Sommer. Thank you. In our context as a selfhelp-movement in Germany, applying systemic approaches and the 12-step-method, there are good hints for me...
ReplyDelete