Skip to main content

Our Love-Hate Relationship with Rules

FEATUREAug1stThomas Edison once said, “Hell, there are no rules here – we’re trying to accomplish something.”

Rules, rules, rules. They constrain us, can make us feel patronized, and conflict with our git ‘er done ethos.  But without them…sometimes we’re a mess!

I certainly felt like one earlier this summer while watching our son play his first lacrosse game. There we were on the sidelines trying to figure out what the heck this game is all about. Most of us watching were veteran hockey parents entirely familiar how things work in that game. But this was the first lacrosse game most of us had ever seen and the whole experience was more than a little unnerving.
For starters, the equipment is a little weird. 10-year-olds dressed for hockey look great on the ice. They look like athletes. 10-year-old lacrosse players look like characters created by Pixar – half Oompa-Loompa and half storm trooper.

But what was really irritating was that we didn’t know the rules. Can you move the ball on the ground with that stick or not? What exactly does off-sides actually mean here? Can you hit someone with the stick or not – ‘cause there sure doesn’t seem to be any consistency in calls from the refs. (Maybe they are on a first-name basis with the other team.)

The silence from the sidelines was deafening until someone finally screamed “Ice it!”

It was like we couldn’t even participate as spectators because we didn’t understand the rules. It was no fun!

So it is on projects. Rules help provide context for our interactions with our team. They set expectations for what’s ok and not, and define behavioral guidelines for ourselves and others.

A project environment without rules may feel liberating for awhile, but eventually, without some idea of how people are expected to behave, team members will get frustrated with inconsistencies, perceived favoritism, and lack of fairness. And that undermines trust, the essential ingredient to an effective team.

I solicited input from some of my colleagues on ground rules that have worked well on their projects and here are a few that they shared with me:

  • Include information in email header: e.g., ALERT – must read, or RESPONSE NEEDED, or FYI only.
  • Immediately report issues and risks with appropriate candor.
  • We will only communicate information outside the team that is approved by the PM.
  • We will be transparent and proactive in our communications. Issues that come up with be addressed promptly and openly with the team and project manager.
  • We will thoroughly review minutes, decision logs, and action items lists for any missed meetings as quickly as possible (or within 2 days, etc.)
  • The PM plan will be in a central repository and in a format that all can use and accessible to all team members.
  • If decisions are made while a team member is not in attendance at a meeting, they will defer the decisions to those in attendance.

Do these sound constraining or patronizing? That discomfort may only be exceeded by the confusion and irritation of not having any rules at all.

Think about your biggest frustration on project teams and how ground rules might help. Even 4-5 well-defined, agreed-upon project ground rules might be just what your team needs to get a better sense of what game is being played and how to win it.

Otherwise, they may end up feeling like ignorant spectators with very little to contribute. And that is just no fun.

Don’t forget to leave your comments below.

Comments (7)