| Posted: January 04, 2012 10:47 AM | Permalink | Email Notifications: ON |

Dominic says:

I have suggested such an approach to groups on PM training that I deliver and have had different responses from enthusiastic to openly hostile. I guess the effectiveness of such an approach is going be reflective of the culture of the organisation, the personality of the PM and the experience/attitudes of the team who will be expected to collaborate on the project. Overall I think such an approach is a good idea as it forces people to think about their own behaviour and commitment as well as reducing the opportunity for personal agendas and politics to distort and derail the project.

Wednesday, January 4, 2012 11:01:58 AM EST

Dave Garrett says:

That's a really good point Dominic - thanks! I've also found that if you win over the most resistant member of the group and make them a big part of the process, it helps a lot. Often that's a question of asking, "What is the most valuable part of this exercise to you?", "Hey, I thought you might be able to help me figure this out." or "How else would you achieve the same result?"

Wednesday, January 4, 2012 11:15:27 AM EST

Harlan Bridges says:

I have used TOA's with varying degrees of acceptance. I like them myself. I have also developed documents akin to an SLA where I've included in the communication expectations things like response times, appropriate media/channels and such. As I have worked with many teams that are spread around the globe sometimes I have added things to address differences in culture, time zones, and work expectations. I have written a white paper on dealing with virtual teams based on these experiences.

I want to add that I echo your advice of making the most resistant member a part of the solution.

Wednesday, January 4, 2012 12:38:57 PM EST

Kevin Schwenker says:

I use them on any major project and have an exercise that I put people through to get answers to questions which essentially result in a Team Charter reflecting the TOA you have posted. As a colleague of mine notes, if you don''t have a system worked out - in advance - of team member expectations, or how to deal with conflict, or how to decide, when it comes to dealing with these issues, it then becomes a negotiation - taking time and energy away from accountability, dealing with adversity or making an actual decision and moving forward with the project.

I also use the exercise in teaching project management at the Sobey School of Business at Saint Mary''s University (Halifax, Canada) where I instruct project management among other applied graduate MBA courses. Students are put into teams - almost randomly - for every course they are in, but have rarely been taught team-building skills. I often get many students taking several of the courses I teach, and team-building instruction and the team charter exercise is integral to most.

Last semester, after instructing the class to break up into teams to begin the exercise, one of the students who had been in a previous class noted that, in that class, her team had just considered the team charter exercise, an "academic" exercise - did the work, created the Charter, submitted it for review and comment, and basically filed the result. They went through a lot of "storming" over the course of the semester and as the project they were on was coming to a close, someone pulled out the team charter and realized that if they had actually paid any attention to it, the semester - and the project - would have turned out so much the better. She advised the class to pay attention to the exercise and make sure that they apply the charter with its operating principles to their assigned project work over the semester. Most groups do - and all have found it to be extremely valuable.

Wednesday, January 4, 2012 5:34:53 PM EST

Dave Garrett says:

Kevin - Sounds like you couldn't have made that turn out any better if you planned it. People always learn best by doing... and sometimes making mistakes.

Wednesday, January 4, 2012 5:50:07 PM EST

Dave Garrett says:

Harlan - your comments about expectations are very important. I think the whole thing is really about collaboratively setting expectations of various types.

Wednesday, January 4, 2012 5:51:51 PM EST

Kevin Hartford says:

Dave,

I can see where TOA would be useful, especially when you have team members from different organizations. I no doubt that everyone on the team wants to do a great job, but that does not mean they will be able to always work together when needed. There are always disagreements on how something needs to be done or why something needs to be done. Sometimes people don't like each other. I think that having a document early in the project that outlines expectations and some basic ground rules works.

I can also see where people might have a problem with this document. They might feel insulted after all they are professionals who will do a great job regardless of personal conflict; right! If everyone really did what they were supposed to do and solved conflict, we wouldn't need managers at all.

Thursday, January 5, 2012 8:51:52 AM EST

Dave Garrett says:

Kevin - I wonder if there is a natural point in the project where people would see it as an obvious step in the process. Obviously doing this at the beginning of the project, versus the middle is less painful - but is there an optimal point in time, like the end of a kick-off meeting or the first meeting after that? Perhaps even earlier?

Thursday, January 5, 2012 9:08:31 AM EST

Kevin Schwenker says:

Actually, the exercise I use spreads itself out over three meetings. it is optimal as part of the kickoff meeting to do the first section, someone drafts up the results and brings it back to the second meeting, where the second part of the exercise takes place - and again, someone drafts up the results and brings it back for discussion and final ratification at the third meeting.

Thursday, January 5, 2012 9:33:31 AM EST

Dave Garrett says:

Thanks Kevin - That's probably a great way to get people to recognize the importance of the exercise (though iterations and repeated exposure).

Thursday, January 5, 2012 9:59:10 AM EST

Bob Waltrip says:

Really? This borders on insulting.

I remember going to a meeting at a vendor site where there was a sign on the wall in the conference room with rules for a meeting (e.g., listen to others, take turns, be polite). I immediately thought it''s time to get out of a company if such a sign is necessary.

Seems to me this sort of stuff is common sense, and if not, should be addressed with individual employees.

It is important to understand specific communication decisions such as whether there will be a team web site, wiki, email and so forth. Also whether the team is a democracy or leader led on decisions such as ship / no ship. But to need to write down to avoid interpersonal conflicts, don't blaming others, and to make decisions based on fact would make many team members feel belittled.

Thursday, January 5, 2012 11:08:44 AM EST

Dave Garrett says:

... and that's the other common view. (Thanks Bob for putting it out there)

Thursday, January 5, 2012 3:58:27 PM EST

Darrel Raynor says:

Good article and template!

Here is what we find working with teams small to enormous, local to world-wide... Everyone has an expectation in dozens of personal performance categories. Each is different -- when they do not match you have at least wasted time if not caused friction and lowered team morale.

We usually start with a small "Norms" document, with three or four items: examples are: What is a reasonable email/phone response time? How many people should review a document or other deliverable (code or physical)? How do we break a logjam of decision between team members?

This is usually about all the attention span you can expect at the beginning. This serves to get them thinking about the process rather than blaming the person.

Here is the beauty part: Then, whenever you sense friction, make a judgment whether a "Norm" could help -- if so bring it up privately with the two+ parties, then in the next meeting. Our "Norms" grow pretty fast in the first stages of a project then slower afterwards. A collaborative effort.

Nit: in template, you mean 'and' but typed 'an'.

Friday, January 6, 2012 1:08:56 PM EST

Dave Garrett says:

Thanks Darrel. So if we add your input to Kevin''s, we can say that it might be good to develop a Team Operating Agreement over a few iterations, starting with a few basic rules and expanding it over time.

Bob - maybe starting small and only detailing things that are not commonly agreed upon is a good way to ensure its not an insulting exercise.

If you take this approach, you could use the template as a set of suggestions to draw from as needed. BTW - we fixed the typo in the overview - thanks very much for pointing it out.

Friday, January 6, 2012 3:04:06 PM EST

Craig Curran-Morton PMP says:

Dave,

From my experience, the template is an entre to a good conversation with the team. It presents an opportunity to start and carryon a conversation with them about their expectations. I love the word expectations because everyone has different expectations when it comes to the project, how the project will be managed and how everyone wil communicate. We are all different and having an opportunity to talk those difference is a great steps towards building a high performance team.

To Bob's point, seeing a sign on the wall with rules about how we will communciate is bordering on insulting because these are rules that are often defined by someone external to the project, not the project team members themselves. People do not need to be "told" how to communicate. They have voices to express their own thoughts and are often more than willing to talk about them. They just need to be asked. To have imposed rules is insulting and condescending.

Monday, January 9, 2012 12:17:38 AM EST

Dave Garrett says:

Thanks Craig - I agree that it's absolutely appropriate to use the template (or something like it) to have a discussion and raise awareness about a number of related "rules of engagement", but again - only document what makes sense for the group.

Monday, January 9, 2012 2:28:02 PM EST

Mark Dyslin says:

If you are going to do something like this, you have to be careful as Bob stated above. You don't want the (un)intended message to be pedantic. That being said, I like the approach of "rules on the wall" (real or virtual) only if they address things of a more "lofty" nature. For instance, rather than focusing on behavior during a meeting, focus on stuff like, "all meetings will be no longer than x minutes in length" or, "please record all meeting notes using the wonderfully simple meeting notes template and distribute forthwith". Things that are more process driven to keep folks on the same track without

It has also been my experience that a grocery list of these process guidelines will also push people away. The first time I put one together, I thought it would help everyone to be really detailed. Wrong! It turns out folks will, maybe, read the whole list, but only pay attention to 3 or 4 at the most. I have since become more selective and try to break down these rules of process by process, making sure to only introduce short lists when appropriate - not all at once.

Wednesday, February 1, 2012 5:39:03 PM EST

Dave Garrett says:

Good points - keeping it simple and focused on the most important things first always helps.

Wednesday, February 1, 2012 5:43:46 PM EST

	Agile Estimation Webinar AtTask CA Gantthead PMO Workshops Headstrong Microsoft Project Conference MSIT Degree Online! Project Pain Reliever Velociteach More White Papers

CA - Can you build a more agile company? Save the Date - Global IT Luminaries ‘12

Gartner - $300 Early-bird discount ends March 2. The must-attend event for BPM practitioners.

Simplilearn - Hit The Wall? PM Training Options For You

See all Vendor Offers

vendor events

March 15, 2012 - Deliver customer-driven, projects and products with high business value to market fast and efficiently

March 19 - 22, 2012 - Microsoft Project Conference 2012

April 15-17, 2012 - 3rd Annual Resource Planning Summit

See all Vendor Events

coming events February 27, 2012: Agile NYC Open Feb. 28-March 28, 2012: gantthead 2012 Conference Series: Redefining the PMO February 28-29, 2012: Creating Results Based Teams March 19-22, 2012: Microsoft Project Conference 2012

newsletters Feb 15: Agile Alternatives Feb 1: Morale Boosting PM Jan 25: Penny Pinching PMs

Copyright © 2012 gantthead.com  All rights reserved.
About Us | Send Feedback | Privacy Policy | User Agreement | Contact Us | Shop | Hat
Advertise on gantthead | Publish on gantthead | Submit a Template | Membership | Mobile-friendly Site
Departments | Processes | Downloads | Tools | Training | Reference | Discussions | Articles