The worst part of being a Project Manager is that sometimes you have to act like a high school principal. You remember your high school principal, the one who walked the hallways scanning for problems, looking stern, official, and a little grumpy. The principal made sure you were on-time, respectful of the rules, and staying far away from trouble!
Like a school principal, project managers can spend lots of time managing behavioral issues including: admonishing task delinquents, resolving team member disputes, doling out punishment, and reporting slackers to the project sponsor. Sometimes, doesn’t being a project manager just make you feel a little grumpy?
Well, it doesn’t have to be this way.
The secret to building low maintenance project teams is using TEAM RULES.
Team Rules define how a project team works together by describing specific behaviors. They can be simple like not talking over a team member during a meeting, or complicated such as one that defines team decision making (i.e. Majority rules vs. Consensus).
Read my award winning post, “The 8 Things that Kill a Project Manager,” by clicking here.
Organizational Psychologist, Roger Schwartz writes that, “When used consistently, they can help teams to make better decisions, decrease the time needed to effectively implement those decisions, improve working relationships, and increase team member satisfaction.”
And the real beauty of Team Rules is that they are created and owned by the team; not dictated from above. They reflect what’s important to the team members about how they work together. So having rules takes some of the burden of monitoring and doling out punishment (being the “heavy”) away from the Project Manager; and places it into the hands of the team.
Creating Team Rules should be one of the first tasks tackled by a new Project Team. I like to distribute a team rules template before the kick-off meeting. This way, team members can come prepared. Your team will need about 2 hours of meeting time to flush-out the details.
Team Rules are most powerful when everyone understands them, agrees on their meaning, and commits to using them. I like each team member to sign the rules. They get posted in common meeting places, both physical and virtual, so they remain visible over the course of the project. Ultimately, you want them to become second nature.
The Team Rules template has three sections:
Team Processes: States the processes the team will use to complete activities.
Examples: How often will the team meet? What meeting roles need to be filled (time keeper, note taker, facilitator) and how will they be assigned? Where and how will the team store data, notes, and other project information. What is the flow of communication outside the project team? What reports will be completed and distributed?
Team Behaviors: Defines how team members interact with each other.
Examples: How will the team make decisions? How will they problem-solve? How will they handle conflicts? How does the team define respectful behavior? How will people be held accountable?
Team Service Levels: Governs the expectations for activity and task completion.
Examples: What are the standards for meeting attendance, promptness, and participation? How long will it take to return phone messages and e-mails? When should weekly or monthly reports be posted? When will task completion (or not) information be updated in the project schedule?
The final component of team rules is designing “penalties.” I’m not crazy about this term, but it’s important that a team identifies what happens if a rule is broken. For example, if you are late to a project team meeting, then for the next meeting you will bring donuts for the team. The penalties do not need to severe, rather they can be fun – food is always fun!
Of course the project manager is not completely off the hook. Team Rules cannot be created for all situations. Ultimately, the project Manager is the final arbiter for situations not covered under the rules.
So, to those of you out there that like being the school principal, I’m sorry to say your days of walking the halls may be over. By having an established and agreed upon set of Team Rules, a project team can self-regulate many common team interactions and processes. This can free up a project manager to do more important things: like interacting with the sponsor or maybe a few grumpy stakeholders! This may even enable them to go home early enough to spend some quality time with your family.
What do you think about team rules? Do you use them? What are your experiences?
Read my award winning post, “The 8 Things that Kill a Project Manager,” by clicking here.
Benjamin Franklin was a man of many talents. Around this time of year, we tend to remember him as one of America’s Founding Fathers. You know, the old curmudgeon that suffered from gout, kidney stones, and a propensity to use the word “whilst.” This of course fails to take into account his other distinctions that included being an:
I came to a realization this week that I have been “bad mouthing” my profession. Much of what I’ve been writing lately about project management has focused on the negative stuff, the dark under-belly of the profession known only by battle hardened veterans who live to tell the tales. Actually, it’s been kind of fun to write about the bad stuff like: project politics, cranky sponsors, distracted team members, conniving stakeholders, and poorly written business cases. Some readers have thanked me for the “tough love” approach that they feel I bring. Others have asked if I am looking to scare people away from entering the field. One reader keeps calling me “snarky,” which is a term I’d like to see expunged from the English language. My intent is not to be tough or scary, and certainly never “snarky.” Rather, I have been looking for a voice that readers find interesting…
Dale Myers' Blog: Think. Plan. Act. Repeat. 