This gives the impression that only one person is active.
If the management has this impression, then make your reporting more effective. As against reporting a laundry list of tasks, let your status reports carry more details, such as which team member worked on what task, the complexity involved, the time taken, completion percentage, how much more time is required for completion, what impediments were resolved to get here, etc.
However, it is extremely unlikely that the management carries this impression. Management would not keep paying anyone for several months for doing nothing, and certainly not an entire team (minus one). It is all business.
Hence, if management got the impression that only person was doing all the work, they would either:
- Demand to know what the others have been doing (and/or),
- Fire all the others.
As neither of these seems to have happened, you can assume that they do not think the others are doing nothing.
His ideas could look good from a high-level point of view but they are not always feasible.
Easy! Beat him at his own game.
Assign to him the task of implementing his own excellent ideas. Mention that in the status report as well. Talking about great ideas is easy, but when he is forced to deal with the implementation challenges, one of these things will happen:
- He will reduce or entirely stop showboating, because the more "great ideas" he sends to the boss, the more work would come his way.
- Management will see a lot of incomplete tasks in his name, and demand an explanation from him.
- He will be forced to follow the protocol. He would need cooperation from the rest of the team to decide if the ideas are feasible and to implement the feasible ones.
- He will actually implement those ideas! That would be great, right?
However there is one colleague which communicates for the project and often includes our boss in CC even when there is absolutely no reason to do so.
Rather than getting "disturbed" by this, use it to your advantage. Issue tracker is a very handy tool, not just for tracking issues with the software but also to deal with such issues. :-) Every time he emails great ideas to the manager, respond appreciatively, tell him that you have created a task in the issue tracker, and ask him to update a tentative start date. For example:
Hi XYZ,
This is a fantastic idea! I have created task no. IDEA-12345 so that we don't forget it. Please update the task with a tentative start date and any other details that you deem relevant.
You don't even need to take a "bad guy" stance. Speak positively about him with your manager, praising the great ideas that he keeps posting. That gives him no chance to complain when things go downhill.
My first idea would be to have a chat with the colleague in question. I would find it a bit strange to ask him not to report to our boss.
Your idea is right. You should always try to resolve issues first by directly talking to the person, and escalate only when that doesn't work. You also cannot tell anyone not to talk to their own boss, so don't do that. Tell him that you want to talk about his ideas and prepare a plan to implement them.
Ask him to assign a priority to each idea. In particular, let him decide which idea he wants to take up next, so that you can mention that in the status report. If he doesn't know what he is talking about, he will take an evasive stance, with comments like, "Uhm, actually, I don't think I can do that right now", "I need to talk to XYZ before I can start", etc.
You can then tell him to figure that out after the meeting or raise it at the next team meeting. Let him know that if he doesn't raise it at the next team meeting, it would imply that he has figured it out himself and you would update that in the status report. This will further compel him to either work with the rest of the team or acknowledge that the "great idea" is not so great. In the latter case, you could tell him to post a comment in the issue tracker, or do it yourself, with something like:
XYZ analyzed this idea in more detail, and decided that it is not currently feasible due to problems 1, 2, and 3. Closing this task for now, we will reopen it if needed if/when these problems are resolved.