Do you send out a "request for comment" when establishing a new company guideline or standard?

Companies need to establish consistent guidelines on things like development process, version control, release procedures, etc. Is it worth the effort to solicit feedback prior to publishing the final guidelines? What do you need to watch out for?

In certain cases, such as when you have experienced engineers who can draft the guidelines, or where guidelines can be revised over time, I think the answer could be "No".

Benefits

Resolve corner cases or ambiguities prior to publication

Better acceptance/adoption because the people that will use the guidelines were involved

2 Answers
2

Yes, I think you're headed in the right direction in a Dale Carnegie sort of way. If you really want to get something accomplished (unit testing, coding standards, etc) often the best approach is to let them craft your ideas themselves. If you have done the research and reached a reasonable conclusion it is likely that your colleagues will reach the same conclusion if given a little guidance.

Let the other person feel that the idea is his or hers.

In general, people have more faith in
ideas that they discover themselves
than those that are handed to them on
a silver platter.

No one likes to be sold something or
told to do a thing. We much prefer to
feel that we are buying of our own
accord or acting on our own ideas. We
like to be consulted about our wishes,
our wants, our thoughts.

Ask others what or where they feel the
problem is. Discuss each point and ask
them their opinions on which is the
best way to proceed. A few, low-key
suggestions, given at the proper
intervals, will influence them. Let
them develop your plan or ideas
themselves.

Ask questions in a friendly way,
showing a cooperative spirit, noting
areas where the other person is right.
This will warm them up and melt any
tension between you. Add in a
carefully put remark here or there to
give birth in the other person of a
new opinion or idea. Be careful not to
let them think that you are making an
issue of something.

Lao-tse, a Chinese sage twenty-five
centuries ago said: "The reason why
rivers and seas receive the homage of
a hundred mountain streams is that
they keep below them. Thus they are
able to reign over all the mountain
streams. So the sage, wishing to be
above men, puts himself below them;
wishing to before them, he puts
himself behind them. Thus, though his
place is above men, they do not feel
his weight; though his place is before
them, they do not count it an injury.

Before you publish the request for comment, consider at least these few points so you have a strategy for handling the issues as they come back to you:

Resolution strategy. How will you handle objections, even if framed as 'minor concerns'? Will certain kinds of objections be handled differently (grammar, tone, style, or structure of the guide, compared with subject at hand)? How will you handle contention; or competing, divergent concerns?

Timeframes of both hard and flexible for response and action. Don't let yourself and your process get stuck in limbo waiting on affirmative congruence from everyone. The period for comment and resolution should be more or less fixed or debate will be endless. Resolving individual, specific issues, should respect some fixed timeframe, but probably won't always be reconcilable within a normal window.

Adoption, Amendment, and Transition. Do you have acceptance criteria for the guideline? What will the process of adoption look like, both initially, and down the road when the standard is changed? How can the standard be changed?

Adherance and enforcement. What are the consequences of not following the guideline? Will the process recognize a waiver, either in part or in whole from the guideline?

While it may seem, and actually be overkill for some guides, for those with broader impact, it may be useful to setup an issue tracker and treat the guideline as a project or subproject unto itself.