What "process instruction" should instructors give students when assigning a team project?
Before you assign students their first team project some instruction is needed. You can't assume that they will understand teamwork any more than that they will understand recursion without instruction. 

But first, you should decide on how you want their teams to behave. In this answer, I'll consider only a team structure that requires a team leader who will assign tasks and be responsible for the overall project, including the integration of the pieces done by the various team mates. This is only one of many possible team structures but here I'll stick to just this. 

If this is the team structure you assume will be used, don't assume that it will just happen and coalesce without your efforts at the start and throughout. Among other things they are too likely to spend far too much time at the start on organization, leaving too little for the actual work.

The first consideration is to decide on both the teams and on how the leader is to be chosen. You can force it a bit by choosing the leaders yourself, assuming that the scale of things permits it and you know something about the students. One way that I had success with in such a situation is to use a round-robin sandlot baseball method. I would choose the leaders/captains and the captains would alternately choose team members until everyone was chosen. This assumes that the students know one another generally. 

Teams can choose their own leaders, also, perhaps via an election. But make sure that the choice is made immediately and that you learn who the leaders are. 

Alternatively you can choose the teams yourself, either randomly or using some knowledge you have of their abilities. It is probably a mistake to let teams just coalesce into groups of friends as things are likely to be too lopsided in many ways. You want the better students distributed around the teams as well as the strugglers. 

This structure is asymmetric, with a few students, the captains, having a special role. Let them know that "equal participation" isn't the same thing as saying everyone does the same thing. People can contribute differently to a successful programming project, with some doing most of the programming, others writing user manuals, others doing research or testing. But they will need some instruction on the kinds of roles and the leaders will need some instruction about how to assign roles (or take volunteers) for the various tasks. 

Let the leaders know that their job is primarily coordination and communication (with you). Encourage them to have frequent meetings with their teams, and constant feedback if there are any problems. Let the leaders know that flexibility is needed and that some members who take on a task will need help in completing it. Make sure that the leader make allowance for such things. 

One way to communicate all of this to a team is to give them a few descriptions of projects that succeeded and a few that failed, with an explanation of why. Horror stories to help them avoid the most common pitfalls. And one of the big pitfalls is not having adequate time for integration of individual efforts. It isn't going to all fall together in the last few hours. Emphasize that. 

And, since the team members will play different roles in the project, give them a "role book" that describes how to carry out one's own role and interact with others. But everyone should know not only their own role but that of others as well. 

One of the big lessons that some of them, at least, won't have understood, is that it is a learning experience, not product development. Students can learn even if a project doesn't really build much. Put the emphasis on learning, not getting over a finish line on an arbitrary (and possibly too short) time scale. 

Another thing to communicate to the captains is that if trouble arises you need to learn of it immediately. Perhaps the project needs refocusing or rescaling. Perhaps the captain will need help in dealing with a non-participant. And if you have frequent meetings with the captains (perhaps in a group) you can feed them "management" hints for the teams. 

One way to have meaningful meetings with the captains is to do it with the entire class present. You and the captains discuss issues while the others listen and take notes. These can be quite short meetings if the scale is small enough, say five or so teams. 

Part of the instruction of the teams, perhaps through the leaders, is to encourage team members to help one another whenever needed. A team project isn't just the sum of a bunch of individual projects thrown together. 

If you intend to use peer evaluation at the end of the project, make sure that they understand that at the start. In fact, it is best to give them details, such as what precise form it will take. My own preference is to have people say positive things about the most productive members rather than to rate or grade everyone. I also require a self evaluation along with any peer evaluation: "What was your chief contribution?".



Note that this style of project is not my favorite, but it is for many.