It makes good sense for you as a project manager to take a defensive posture in most areas of risk. If the client is inclined to vacillate, you take pains to nail down the product specifications; if a contract vendor tends to “forget” promises, you publish minutes after each meeting. These are common risk mitigation techniques a project manager should use. There is one area, though, where defensiveness will always backfire: You cannot protect yourself against your own people’s incompetence. If your own people are not up to the job at hand, you will fail.
Of course, if the people are badly suited to the job, you should get new people. But once you have decided to go with a given group, your best tactic is to trust them. Any defensive measure taken to guarantee success “in spite of them” will only make things worse. It may give you some relief from worry in the short term, but it will not help in the long run, and it will poison any chance for the team to gel.
Project managers who do not trust their own people are afraid they might deliver something that is wrong to the client. They are worried that mistakes may reflect badly on them. Only their own judgment is competent; they are more experienced and have a higher standard of excellence. At any point in the project where they do not interpose their own judgment, team members are more likely to make a mistake.
So what? Let them make some mistakes. You can always override a decision (very occasionally) or give specific direction to the project. But if staff come to believe they are not allowed to make any mistakes of their own, the clear message you are sending is that you do not trust them. There is no message you can send that will better inhibit team formation.
Most project managers grant autonomy to the team while everything is running smoothly, but that is not true autonomy. The team will only feel free if it is allowed to proceed down a different path to the one set by the project manager. Only he with the right to err is truly free. If the project manager interferes in every technical decision or prescribes a methodology applicable to each task, then the team will not feel trusted, and will have little inclination to bond together into a cooperative team.