The protocol for a group interview is similar to that for the individual interview, except that the team has the added burden of collecting data from four to six (or more) individuals in one session. Usually the groups consist of people selected from the assessed projects all doing a similar job. A typical group might consist of people responsible for system and software requirements, or for design, or for coding and unit test, or for integration and system test, or for quality assurance, or for configuration management, or for engineering process group (software/systems), management processes, among other fields. (In the software engineering process group or engineering process group sessions, it is common to have up to eight people in a session.)
Each group interview typically takes one and a half to two hours.
Sensitive Situations in Group Interviews
Typical problems in group interviews include the following:
One person may dominate the answers for the group, keeping the team from gathering sufficient data. Practitioners do not always have experience with interviews and may allow (or even want) one person to dominate a session. The team should try to prevent this from happening. It is best to make it clear that the questions will rotate through the group and that all the people in the interview session will answer some questions.
In less mature companies, not every project performs the same activity in the same way. This also needs to be anticipated.
When assessing Company R, a group of design engineers was asked how they performed peer reviews. One person from the group answered the question. His project did Fagan Inspections. But the assessment team never asked the other design engineers if they did peer reviews the same way and assumed that if one project did a complete job, the others would have done it as well. It turned out that only one project performed peer reviews, a fact that emerged later and then had to be confirmed with some difficulty.
Sometimes no matter what the team does, some people say very little. Though disappointing, this should not be regarded as a failure. These individuals at least will have learned about how other projects do the same job.
In Company E, one developer said very little even when questions were directed to him. He would either grunt, give the shortest possible answer, or say he agreed with another person being interviewed. However, this person had been listening carefully during his interview and had considered whether the CMM/CMMI method might make his product better. The result was that after the assessment, he volunteered for improvement activities and ultimately became a Lead Assessor.
Two Variations of a Group Interview Seating Configuration
Participants can feel more like they are part of the process if their seats are interspersed with that of the assessment team . The downside is that this arrangement can seem disruptive because of note taking, shifting focus, and so on. The Lead Assessor should experiment with both configurations. (The second configuration, in which the participants sit on the same side of the table, makes the interview easier to conduct and solidifies the participants as a group but can make them feel as if they are an opposing team.)