Does anybody use these at work?
They are great for keeping a bunch of people from talking over each other. Like any formal education, it is great to have learned the methodologies and be able to apply parts of it in the situations that require it, like when there's one coworker that cuts people off too often.
Every organization/group is different, if they need rules for their meetings they need to be tailored for that group.
Agreed.
Generally speaking, the more people are involved in something, the more benefit there is to a formal structure.
As I mentioned in another comment, there are still things that can be learned from RRO that might be helpful in a professional setting, but generally speaking it's just way too much.
The key contribution of Robert's Rules is right in the name: order. Everyone has a chance to speak, but in an orderly fashion. No shouting down. And when enough has been said, you vote on it and move on. One party who refuses to cooperate cannot hold the proceedings hostage forever.
In my experience, the biggest benefits are:
- they force a group to define what is being voted on (via ammendments)
- they separate debating from voting
- they make it clear when a decision has been made and it's time to apply it
If you're stuck kicking the can on plans and decisions, it may be worth implementing a version of these rules.
I introduced some of it to our CAB, and it works in the sense that the CAB is just a soft machine that approves or rejects changes. Everything stays on the rails and we are done in time for lunch.
1. Roberts Rules states that the #1 order of business at every meeting is a vote on the prior-meeting's minutes. The written record is king in Robert's rules. In an office environment, this means that any meeting that must "exist" must be written down and secondly (this is _VERY_ important), all stakeholders in the decision need written acknowledgement that the written-record is correct.
Consider ISSUE#55, a hypothetical programming feature that should be implemented before version 3.55 of the computer program you're writing. A meeting occurred on January 5th saying Issue#55 needs to fix the GUI to accept usernames of length 20, but not of length 5. Writing down these issues is not enough or sufficient.
The most important part of this "issue" is the signoff: all people of the meeting (developers, product managers, customers if possible) should be on the email saying "Yes, Issue#55 as written in Jira is an appropriate summary of what we want, and the feature you want to program is a good idea".
Because come 5 months from now when crap happens, we all know everyone's going to point fingers at each other and blame each other. Having an appropriate signoff is as important (if not more important) than the written documentation.
So again: Robert's rules on "Agree to the secretary's meeting summary of the last meeting" is HUGELY important, in practice. But you gotta "see" what that really means in your office environment.
----------
Etc. etc. etc. Every other rule exists for a reason in Robert's rules. Minority talking point. Ability to filibuster and shut down debate by filling the space with crap (and how to avoid the Filibuster through time-requirements or other such features).
The 2-times-to-talk per issue helps prevent nonsensical loops. Give people a point, and then one opportunity for a counterpoint, and that's enough for most situations.
Let dead issues stay dead. Do not allow people to drudge up old issues and distract.
Etc. etc. All of Roberts Rules are rules of this nature, but they don't say the "why", instead they're just written as dry "10 minutes per discussion point, 2-times to talk per issue", style because all the rules are so numerous.
Its very more important to learn the "spirit of the law" and the reasons why parliamentary theory exists.