Since every project has one manager only, this is an attribute of a project and should be stored there. I didn't get this part:
I could just set a projectmanager-field in the project table and get the information from the Team table but then I would have the unwanted possibility to select the project manager in the project team also. Some will do it, some will not.
In my Team table I have all the personnel at work. All of them can be project managers and project team members.
I made a dwindling list of the lot to choose from as a project team.
If I save the project manager in a field within the project table, this name will still be visible in the dwindling list as a possible team member.
The user initiating a project then has the possibility to include the project manager within the project team or not include him (forget).
At our workplace we tend to change project managers from time to time depending on workload. The previous project manager then takes place as a regular team member.
If the project manager is not chosen as a team member he will not be included in the group automatically when he steps down.
This is one reason. The other would be that I in the future would like to exclude and include projects depending on the user.
User A would only see projects of which he is manager of as a start screen and be able to choose all projects of which he is a member(and manager) when he registers his time.
In my imagination it would be easier for me if all of this information will be stored in one table.
Although; empirical studies show that chances of me being wrong: 95%
You are mixing structure with user-interface. Structurally, the identity of the manager is an attribute of a project. The user-interface issue can be solved by allowing project manager to be selected only from team members assigned to the project - by using a restricted value list, for example, or by selecting from the portal. The important thing is that selecting a manager this way automatically deselects the previous manager.