At the beginning of a new to start project, I get the question how to set up the project organization. I try always to answer it shortly:
The project organization must consist of as few people as possible and only dedicated people that will really contribute to the project and has interests that the project will succeed.
It is a loaded answer with a lot of criteria and questions in it. It can be helpfull to explain the underlying reasoning.
Dedicated people
This is an important reason why projects fail. Usually there are people involved in the project that may have really valuable skills and knowledge but no time to contribute. It causes that other team members (with less skills), get a wait-and-see attitude. It also allows that there arises a hierarchy in the team of higher and lower skilled team members which then causes that the lower skilled members feel no confidence and mandate to take decisions while the higher skilled members (without time) wait until the product is developed so that they can evaluate it. It finally ends with the question why there hasn't made any progress after so much time has elapsed.
As few people as possible
The formula to calculate the number of communication channels on a project is simple: n*(n-1)/2. "n" is the number of team members. So if the project organization consists of 4 people, the number of communication channels is 4*(4-1)/2= 6. But if there are 9 people involved, the number of communication channels is 9*(9-1)/2= 36. That is 6 times more communication channels to keep up to date. The threshold to get away with a simple communication plan and tools such as phone and e-mail is then passed. Team members need instructions for the tools they need to use and clear explanation of how to communicate with each other.
The demarcations for responsibilities are also troublesome with more people involved. The dividing line to determine who is responsible for specific areas of the project needs to be specified. Otherwise duplication of work effort will occur or parts of the project will be untouched because nobody was responsible for it.
Really contribute to the project
It depends on the environment and the project what "real contribution" is. But only talking or giving some instructions is not considered as "real contribution". Vague things as strategic advice, architectural input, conceptual framework can also not be considered as "real contribution". Writing considerably big amounts of code, creating user interfaces in Photoshop and HTML/CSS, setting up the server infrastructure are examples of "real contribution" where people really deliver working software. Getting your hands dirty and taking the risk of creating something really useless or useful can be used as criteria.
Interest that the project will succeed
People get creative if there are interests at stake and cannot passively participate without being affected. There must be a strong incentive for all people involved that the project will be a success. It sounds obvious but there are a lot project with people that could not care less if the project would fail. There are even situations to think that people just benefit if the project fails.
General involvement
Another topic is where to leave all the other people who necessarily want to interfere with the project. Especially when the project is important, the conventional wisdom states that a lot of people must involve in the project. It is a convenient idea that if the project goes wrong that there can always be someone that can save it. So people are added to the project to supervise and micro manage. These people get all confusing roles and responsibilities that detracts members that otherwise could really get work done.
I think it is not a solution to give these people superficial roles to get them busy. I think that being brutally honest is often the best solution. Make them clear that they really aren't needed to be directly involved in the project but they can always monitor the progress of the project by looking at the burndown chart.
The product owner also needs to elicit their requirements for the project and give an explanation of how and when the requirements will be translated into the product or why the requirement will not be a part of the product. (The product owner really needs mandate to do skip requests.)
Stakeholders can be many including CEO at the client-side company, middle management, senior management of partner contractors, intern account managers, funding companies management. It is the task of the Scrum master and the Product Owner to protect the team from outside interruptions. But it is the responsibility of everyone to understand why the team size must kept small.