When presenting work in progress to a group or team, setting the tone and trimming the attendees can mean the difference between success and frustration.

I am sure many of you have experienced this all-too-common scenario, both as a manager and an individual contributor:

You have been asked to research a new software component, plan a transition, or solve some other problem.  This usually happens outside of a standardized agile or waterfall process.  Approximately halfway through the implementation, you responsibly decide to present your findings to a larger group. You know that mistakes that are discovered early are easier to correct, and you want to ensure your final idea will be acceptable to everyone.

Confidently, you stand in front of the room, and explain and demonstrate what you have accomplished thus far.

Instead of the feedback you need, the room comes alive with criticism and nitpicking. The group is focusing on the unfinished details, and items that are well out of scope of your task. You leave the room discouraged or angry, wondering why you even had the meeting in the first place.

Here are three suggestions for managing these types of meetings:

Limit your attendees.

The more people in the room, the easier it becomes to give feedback, and the pressure to contribute increases. When person A gives nitpicky feedback, person B thinks, “Hey, I saw small issues as well but was going to keep them to myself, but now I feel like I should participate.” This quickly turns into a race to the bottom.

I would be willing to bet that if you require feedback on your work, you know exactly which 3-4 people can give you the best feedback. While you may feel it is important to involve more people, the best role for them may be later in the process.

Set the appropriate tone.

Your first instinct will be to immediately identify what you’re presenting as a work in progress, and emphasize it whenever anyone finds a problem. You need to remind yourself that everyone in the room is a professional and understands the concept of incomplete work. Every time you respond to a comment with “I know that’s not in there yet, but I was planning to add it this week” you’re telling the room that any change is possible, and the scope of the project will grow.

Ask specific questions.

If you present incomplete work, and simply throw it out to the group without any agenda, you will quickly lose control of the meeting. If you are still at the point where you need high level general feedback, this will be accomplished more efficiently in a one-on-one meeting or demo. You should walk into the meeting with an agenda of the specific points you need feedback on, and attempt to limit discussion to those items. Instead of “What do you think of this new process?” or “Does this new module look useful?” the question should be, “Will this step of the new process cause too much overhead?” and “Lets discuss how you might use this new module so I can ensure I didn’t miss anything.”

These three simple suggestions can help you gather the feedback you need, without all of the headaches.