Rules — they both frustrate and support us, don’t they? Objectively we know that rules in projects are put in place to stop mistakes from happening; they make sure that we follow best practice procedures and keep the same level of quality throughout each piece of work that we do. But they really cut down on the momentum of work sometimes, don’t they? Andrea Brockmeier understands — having gone to a lacrosse game without knowing any of the rules, however, opened her eyes to one of the main reasons for rules : they give context to what is being done: 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. With this in mind, Brockmeier asked for some imput from colleagues about what types of rules they valued within the world of projects. The feedback included including important information in the header of emails, reporting risks and issues quickly, transparency in communication, and reviewing minutes from meetings with those who were not part of the meeting initially. Brockmeier asks “do these sound constraining or patronizing?”, and the answer is most likely no. Good rules — ones that enable rather than hinder — are almost never seen or experienced as constraining. Ground rules like the ones listed in this post help set up the expectations of the team, removing wasted time with second guessing or frustrated interactions during meetings and in emails. The value of rules, when it comes down to it, is the amount of time and energy they save through definition of actions.