Factors Influencing IT Students’ Selection of Group Project Partners in Collaborative Programming Projects

Abstract

Collaboration is essential in today’s technology-driven world, where IT professionals work in teams to solve complex problems. To mirror industry practices, universities have increasingly adopted project-based learning approaches, requiring students to work collaboratively on tasks such as software development. However, while considerable research has examined group project outcomes, little is known about the decision-making processes students use to select their partners, particularly in software development. This study, therefore, explores the factors influencing IT students’ choices of group project partners and how these choices reflect broader learning priorities. A qualitative approach was employed, collecting open-ended responses from 103 software development students through individual interviews conducted via MS Teams. Thematic analysis was used to identify recurring patterns in the data. Five main themes emerged: Personal Relationships & Familiarity, Work Ethic & Dedication, Communication & Teamwork, Reliability & Accountability, and Technical Skills & Competence. The findings indicate that students prioritise interpersonal trust, reliability, and communication skills over technical ability when selecting partners. This suggests that students view effective collaboration as grounded more in work ethic and relational qualities than in coding proficiency alone.

1. Introduction

Collaboration has become a cornerstone of success in today’s technology-driven world, where IT professionals routinely work in teams to solve complex, multifaceted problems. As Ref. [1] argue, the ability to collaborate effectively is no longer a peripheral skill but a core competency in the digital economy. Recognising this shift, universities have increasingly adopted project-based learning (PBL) approaches to simulate the work environments that students are likely to encounter post-graduation. Group projects have long been promoted as essential for developing both technical expertise and critical interpersonal skills [2]. Particularly in software development, the ability to function within a team can determine the success or failure of complex projects, making early collaborative practice not merely beneficial but vital [3]. Students must learn not only how to code, design databases, and debug systems, but also how to coordinate tasks, communicate clearly, and build trust among team members. Through project-based learning, students engage with real-world problems, working together to co-construct solutions rather than operating in isolation [4,5].

Effective collaboration thus becomes both a technical and a social endeavor, demanding holistic development [6]. Evidence from software-engineering programmes shows that such immersion improves both technical mastery and workplace-ready soft skills. Ref. [7] demonstrated that integrating multiple courses around a single capstone project raised students’ self-reported confidence in requirements analysis, architecture, and cross-team communication. In addition, a systematic review in [8] further links PBL to measurable gains in employability skills, arguing that projects cultivate adaptability and problem-solving abilities required by industry. Complementing these findings, the work in [9] found that embedding computational-thinking techniques inside a PBL software-project course significantly outperformed traditional delivery methods on post-test scores for design, testing, and collaborative debugging. Collectively, this growing body of work substantiates the claim that PBL mirrors real-world development settings and equips graduates with the hybrid skill set demanded in the workplace.

However, the choices students make about their project partners can significantly shape the quality of their learning experience and influence their future professional trajectories. Selecting a partner is not a neutral act; it embeds assumptions about reliability, competence, and compatibility that can either enhance or hinder both individual and group performance. It is therefore crucial that students make these choices for the right reasons, based on factors that promote both task success and personal growth. Poorly motivated selections, such as partnering solely with friends for convenience, risk undermining the educational purpose of group work.

IT curricula deliberately emphasise group-based assignments to replicate real-world scenarios like agile software development teams, where iterative collaboration and distributed responsibility are the norm [10]. In these environments, interpersonal dynamics such as trust, communication, and accountability often prove just as important as technical proficiency. Partner selection thus becomes a critical, yet often underexamined, decision point that can significantly impact not only project outcomes but also the development of professional competencies.

Although collaboration has been widely studied in educational research, the specific decision-making process behind partner selection remains comparatively underexplored, especially in the context of software development. Existing literature tends to focus on group outputs, such as project grades, peer evaluations, or learning gains, rather than the initial preferences and rationales that shape how groups are formed [11,12]. Without insight into why IT students prefer certain partners over others, educators risk implementing group projects that reinforce existing social dynamics or perpetuate inequities, rather than challenging students to develop broader, more adaptable collaboration skills.

This research seeks to answer the question: What factors influence IT students’ selection of group project partners in collaborative programming environments? By analysing qualitative responses from 103 software development students, the study sheds light on what students perceive as the most desirable traits in a teammate, offering a window into how they approach collaborative work and what they implicitly value in professional relationships. Because students in these courses were allowed to self-select their project partners, the study aimed to understand the factors driving these decisions and how they reflect students’ collaborative priorities.

Understanding these partner-selection dynamics can help educators design more effective group assignments, better structure team-formation processes, and scaffold reflective practices that promote intentional and skill-enhancing collaborations. Moreover, it contributes to the broader discussion on collaborative learning in technical disciplines, where the stakes of group success mirror the high-performance demands of industry. The thematic analysis of student responses identified five key themes.

The remainder of this paper is structured as follows. Section 2 outlines the methodology, detailing participant recruitment processes, data collection through interviews, and the thematic analysis approach used to interpret the data. Section 3 presents the results, highlighting the emergent themes identified from student responses. Finally, conclusions are given in Section 5.

2. Materials and Methods

2.1. Research Design

This study employed a qualitative, exploratory design with descriptive quantitative elements. While the primary analysis was qualitative (thematic analysis of open-ended responses), frequency counts and percentages were calculated to indicate the prevalence of themes across participants. These quantitative descriptors serve to contextualize the qualitative findings rather than test hypotheses, maintaining the study’s fundamentally qualitative orientation while providing transparency about theme distribution across the sample. Qualitative inquiry is well suited to questions that probe how and why people act in context, privileging depth over breadth [13]. An exploratory stance allowed themes to surface inductively rather than testing pre-set hypotheses, a cornerstone of discovery-oriented studies in education [14,15]. Such a design is particularly appropriate for studies of collaborative programming, where interpersonal, technical, and organisational dimensions intertwine in ways that resist simple quantification [16].

2.2. Participants

One hundred and three undergraduate students enrolled in a Diploma in Software Development at a South African university constituted the sample. Second and third-year cohorts were targeted to ensure participants had prior experience with compulsory group programming projects, thereby providing information-rich cases. A convenience sampling strategy was employed, where volunteers were recruited through course announcements and class mailing lists. Although non-probabilistic, this approach enabled timely access to students familiar with the study context while acknowledging the practical constraints of term-time research. Importantly, the course structure allowed students to self-select their group members for these projects, providing a natural context for examining authentic partner-selection behaviors and preferences.

2.3. Data Collection

Data were collected in two phases to explore students’ reasons for selecting group members for their projects.

2.3.1. Google Form Design and Administration

The initial data collection employed a Google Form designed with open-ended questions to minimize researcher bias and allow themes to emerge naturally from student responses. The form contained two primary components:

Primary Questions:

“Please describe the main reasons why you chose your current group members for your software development project”

“What qualities or characteristics do you look for when selecting project partners in programming assignments?”

“Can you provide a specific example of a time when you chose (or avoided) a particular partner and explain your reasoning?”

Demographic Questions:

Year of study (second or third year)

Number of previous group programming projects completed

Self-assessed programming skill level

Preferred group size for projects

Critically, no predetermined categories, lists of potential factors, or multiple-choice options were provided to respondents. This open-ended approach ensured that the factors identified emerged directly from student experiences rather than being constrained by researcher assumptions or leading questions. The form was pilot tested with five students from a similar program to ensure question clarity and identify any potential ambiguities before full deployment. The form was distributed through the university’s learning management system and course email lists, with announcements made during lecture sessions. Students were encouraged to complete the form during designated class time to ensure adequate response rates and minimize selection bias in participation. The form remained open for two weeks, with reminder announcements made during the second week to maximize participation.

2.3.2. Interview Participant Selection and Conduct

The 25 interview participants were selected through purposive sampling using maximum variation sampling techniques. From the 103 Google Form respondents, 47 students indicated willingness to participate in follow-up interviews. Selection criteria included: (1) thematic diversity—ensuring representation across all emerging themes from Google Form analysis, (2) year level balance—proportional representation of second and third-year students, (3) experience variation—students with 2–8 previous group projects, and (4) response depth—prioritizing students who provided detailed, reflective Google Form responses. The final sample of 25 was determined by theoretical saturation principles, where additional interviews were not yielding new thematic insights.

To address potential selection bias, demographic characteristics and response patterns of interview participants were compared with the full Google Form sample. No significant differences were found in year level distribution, self-assessed skill levels, or general response themes between interview participants and the broader sample.

The interviews were conducted online via Microsoft Teams to accommodate both campus-based and commuting students, maximizing participation while ensuring a standardized digital environment for recording and secure data storage. Individual sessions fostered candor, allowing participants to narrate detailed, personal stories about their partner-selection experiences. An interview guide with open-ended prompts was developed based on preliminary analysis of Google Form responses, with questions such as:

“Can you walk me through how you typically choose project partners?”

“What qualities make you choose one partner over another?”

“Have you ever regretted a partner choice? What happened?”

“How do you balance technical skills versus personal qualities when selecting partners?”

The semi-structured format allowed for follow-up questions and elaboration without steering respondents toward predefined categories. Interviews averaged 25 min (range: 18–35 min) and were audio-recorded with explicit consent, then transcribed verbatim using professional transcription software with manual verification for accuracy.

2.4. Data Analysis

2.4.1. Researcher Roles and Analysis Process

Data analysis was conducted by the primary researcher with methodological oversight from two academics experienced in qualitative research methods. To enhance analytical rigour and credibility, multiple validation strategies were employed throughout the analysis process. The primary researcher carried out all initial coding and theme development, with regular peer debriefing sessions held with the research team to discuss emerging patterns and challenge interpretations. Member checking was carried out with a subset of eight interview participants who were invited to review preliminary themes and provide feedback on the accuracy of interpretations, ensuring that findings resonated with participants’ lived experiences.

The analysis process consisted of four distinct stages: (1) the primary researcher independently coding all data, (2) developing themes collaboratively through team discussion and consensus, (3) refining themes through an iterative process of constant comparison, and (4) validating the findings by systematically re-examining the raw data against the themes to ensure comprehensive coverage.

2.4.2. Analytical Framework and Approach

This study employed a qualitative, exploratory design with descriptive quantitative elements. While the primary analysis was qualitative through thematic analysis of open-ended responses, frequency counts and percentages were calculated to show the prevalence of themes across participants. These quantitative measures serve to contextualise the qualitative findings rather than test hypotheses, maintaining the study’s fundamentally qualitative approach while providing transparency about theme distribution across the sample.

Data from both Google Form responses and interview transcripts were analyzed using thematic analysis following Ref. [17]’s six-step framework: (1) familiarization through repeated reading of all data, (2) systematic initial coding of data extracts, (3) active theme construction through code clustering, (4) comprehensive theme review and refinement, (5) theme definition and naming with clear boundaries, and (6) analytic write-up integrating themes with supporting evidence.

2.4.3. Coding Process and Theme Development

The coding process started with a detailed examination of Google Form responses to uncover initial ideas and patterns related to partner selection criteria. Open coding was used at first, allowing codes to emerge directly from the data without preset categories. Examples of initial codes included “friendship_matters,” “reliable_worker,” “good_communicator,” “coding_ability,” and “meets_deadlines.” This inductive method ensured that student voices led the development of themes rather than researcher assumptions.

After initially coding Google Form data, interview transcripts were examined to add depth and detail to emerging patterns. The constant comparison method was employed throughout, where new data were continuously contrasted with existing codes and emerging themes. This iterative process enabled the refinement of themes and the identification of relationships between different aspects of partner selection.

Codes were systematically grouped into potential themes based on frequency, internal coherence, and explanatory power. For instance, codes such as “friendship_matters,” “previous_collaboration,” “comfort_level,” and “shared_humour” were assembled under the broader theme of “Personal Relationships and Familiarity.” This process of clustering was repeated multiple times to guarantee thematic stability and coherence.

2.4.4. Data Integration and Triangulation

The integration of Google Form and interview data was achieved through methodological triangulation, where both sources were used to validate and enrich thematic findings. Google Form responses offered a broad perspective across the full sample (n = 103), while interview data provided depth and contextual understanding from the purposive subsample (n = 25). Themes were regarded as robust when they appeared consistently across both sources and were supported by multiple participant voices.

Frequency analysis was carried out to determine the prevalence of each theme within the sample. Participants were marked as referencing a theme if their Google Form responses or interview transcripts explicitly mentioned factors within that thematic category. For instance, a participant was marked as referencing “Work Ethic and Dedication” if they mentioned concepts such as “hard work,” “meeting deadlines,” “commitment to the project,” or “showing up consistently.”

2.4.5. Quality Assurance and Rigor

Several measures were implemented to ensure analytical rigor and trustworthiness. First, an audit trail was maintained throughout the analysis process, documenting coding decisions, the rationale behind theme development, and methodological choices. Second, negative case analysis was conducted to actively seek data that contradicted emerging themes, ensuring comprehensive representation of the dataset.

Third, reflexive journaling was used by the primary researcher to recognise potential biases and preconceptions that might influence analysis. Regular team meetings offered opportunities for collaborative reflection on analytical choices and alternative interpretations of the data.

Finally, inter-coder reliability was evaluated by having a second researcher experienced in qualitative methods independently code 20% of the interview transcripts. Initial agreement was substantial (Cohen’s κ = 0.78), and any discrepancies were resolved through discussion and consensus. This process enhanced confidence in the analytical method and thematic findings.

Thematic analysis was chosen because it offers a flexible yet rigorous way to identify patterns of meaning in qualitative data while preserving participants’ authentic voices and experiences [18]. The method’s capacity to accommodate both inductive and deductive reasoning allowed themes to emerge from the data while staying linked to established theoretical frameworks concerning collaboration and team formation.

3. Results

The thematic findings presented in this section were derived from an initial analysis of responses submitted by 103 students via a Google Form, which provided a broad overview of partner selection factors. The frequency of factors influencing partner selection is presented in Figure 1. To deepen the understanding of these emerging patterns, semi-structured interviews were conducted with a purposive sub-sample of 25 students. This two-phase approach enabled both thematic breadth and narrative depth, allowing the research to capture not only the frequency of particular criteria but also the nuanced reasoning and lived experiences that shaped students’ choices. The integration of survey and interview data enhanced the validity of the findings by triangulating recurring themes across multiple sources.

3.1. Personal Relationships and Familiarity

Personal relationships and familiarity emerged as the second-most influential factor in partner selection, cited by 72% of participants. For many students, pre-existing relationships served as a psychological shortcut to trust, with prior friendships or previous collaborations indicating established communication norms, shared humor, and aligned effort levels. This familiarity mitigated the uncertainties of new collaborative settings. As Participant 07 noted, “If we’ve survived a database project together, I know we can survive this one,” while Participant 18 remarked, “A friend means less time tip-toeing and more time coding.” These sentiments align with findings by [19] who concluded that familiarity accelerates the group formation phase and enhances perceived cohesion.

From an interpretive perspective, familiarity functions as a form of relational currency, where past shared experiences are leveraged to anticipate effective future coordination. This pattern resonates with research on group homophily, which demonstrates that individuals gravitate toward collaborators who are similar or familiar, as such connections reduce coordination costs and enhance predictability [20]. However, this preference for familiar partners carries trade-offs. Several interviewees conceded that choosing friends sometimes “locks the team into one way of thinking,” limiting diverse perspectives. One respondent reflected, “We’re comfortable, but maybe too comfortable—we finish tasks the old way instead of trying new libraries,” corroborating findings that friendship-based teams may exhibit reduced innovation due to lower skill diversity [21].

In terms of group dynamics, high familiarity facilitated rapid role negotiation and minimized socio-emotional conflicts, allowing teams to allocate more cognitive resources to technical tasks. However, code-review quality and learning gains can plateau when friendship masks uneven competence, or when social ties inhibit honest peer critique. These findings suggest that lecturers could optimize group composition by permitting one familiar pair per team while integrating unfamiliar members to broaden the team’s skill set and idea pool, thereby balancing the benefits of trust with the advantages of lack of diversity.

3.2. Work Ethic and Dedication

Seventy-eight percent of students said they pick partners who work hard and stick to deadlines. In their view, a teammate who “shows up every lab and pushes code on time” protects the group from last-minute chaos that hurts grades. This finding matches earlier work showing that perceived reliability often matters more than raw skill when students form teams [22].

“I’d rather pick someone who grinds as hard as I do—it’s about mutual respect, not just marks.”—P03

“We can debug skills, but we can’t debug absenteeism.”—P21

“A coding genius who disappears until the night before still sinks the team.”—P14

These comments reveal a moral logic: hard work signals integrity. Through the lens of Social-Exchange Theory, students balance the chance of shared effort against the risk of freeloading. In effect, diligence works like an insurance premium that lowers the fear of unequal contribution. Prior studies agree that self-selected groups feel more comfortable and confident precisely because members trust one another to carry their share of the load [23].

However, some interviewees admitted that choosing reliable friends with weak coding skills can backfire later. They echoed that giving too much weight to dedication can trade short-term peace of mind for long-term “technical debt.” The work in [24] report a similar pattern: high conscientiousness does not always lead to better decisions when competence is lacking.

When every member shares a strong work ethic, early progress is smooth. Regular commits build collective confidence, shorten the “storming” stage, and leave more mental space for tough debugging. When effort levels differ, the harder-working student drifts into an informal leader role. This shift can breed resentment and overload. Simple, transparent tools such as Git contribution dashboards can realign expectations and strengthen the unspoken contract that students view as essential for effective collaboration.

3.3. Technical Skills and Competence

Only 34% of students named Technical Skills & Competence as a main reason for choosing a partner. This share is far below relational factors, yet students still see skill as the “spark plug” that turns group effort into working code. They often choose a peer because “he’s the database wizard we’re missing” (P02) or “she can debug Java in minutes” (P19). Skill, then, is a task resource the team must stock, even if it is not the first trait they look for. The pattern echoes earlier research. In self-formed computer-science teams, technical ability matters, but it usually follows softer guarantees of trust and communication [22]. A later capstone study found the same order: reliability ranked first, interpersonal fit second, and complementary skill third—yet teams that did balance their skills earned higher project scores [25]. One respondent captured the idea neatly: “Talent helps only if the person is also present” (P28).

This observation suggests that students treat competence as a conditional advantage. Once they feel safe from free-riding, deeper skills add value in two ways:

Shared memory. Each member knows “who knows what,” so problems travel to the right person quickly.

Wider solution space. Mixed skills let the team explore more ideas. This was also observed in software engineering courses, where diverse teams outperform uniform high-skill groups when coordination norms are strong [26].

Skill can also create tensions. Two students who teamed with extremely good programmers felt pushed into trivial tasks and learned less. This echoes evidence that steep expertise gaps silence lower-skill voices unless teachers scaffold fair task rotation [27]. Thus, competence is a double-edged sword: it speeds progress yet risks inequality if collaboration rules are weak. Pairing complementary skills can raise project quality, but only when clear accountability and communication channels exist.

In short, students see Technical Skills & Competence not as the ticket into a team but as the amplifier that works after relational trust is in place. They want ability, but they want it packaged in partners they can rely on and talk to.

3.4. Communication and Teamwork

Communication and teamwork ranked mid-priority, with 56% of respondents describing them as the “glue” of collaboration. One student noted, “If my partner can’t talk through their logic, every merge request becomes a guessing game”, while another added, “I pick people who answer messages fast and aren’t shy; silent coders slow the whole sprint”. These comments highlight that both the quality and frequency of team communication predict stronger project results [28]. When viewed through a socio-technical lens, communication acts as coordination capital: clear dialogue lowers mental load when roles overlap, speeds agreement, and turns code reviews into joint learning rather than defensive posturing. Research on the success factors of capstone projects shows that sharpening message clarity and enforcing simple channel rules can raise deliverable quality even when technical skill remains constant [29].

However, communication can also backfire when quantity eclipses structure. Two students who partnered with talkative friends found that “constant chatter without structure” stretched decision times, mirroring findings that unstructured talk can flood teams with noise and erode trust if messages lack task focus [30,31]. These mixed experiences suggest that lightweight protocols can preserve the trust benefits of open dialogue while filtering out counter-productive noise. In essence, students treat communication not as a soft-skill nicety but as an operational necessity that can speed up or stall a programming project, depending on how well it is managed.

3.5. Reliability and Accountability

Reliability and accountability mattered to 38% of the participants. Students said partners must own their tasks, report progress openly, and keep their promises. While work ethic highlights effort, this theme stresses follow-through and answerability. Students expressed sentiments that teammates should work hard and show evidence of that work, accepting consequences when they fall short.

“Deadlines mean nothing if people don’t admit when they’re slipping.”—P09

“He never misses stand-up, and if a bug is his, he owns the fix before the next sprint.”—P24

“I need someone who documents what they did—otherwise we can’t trace errors.”—P30

These remarks point to an unspoken accountability contract. In social-exchange terms, visible responsibility lowers the chance of hidden labour or blame-shifting. Studies of project-based learning report the same pattern: when personal accountability is clear, peer satisfaction and output quality rise, even with minimal instructor oversight [32].

In addition, research conducted on life-science students concluded that students like the idea of working in teams, yet they believe group projects break down when responsibility is not shared or monitored fairly. Ref. [33] shows that this imbalance breeds frustration, erodes trust, and ultimately causes the group to underperform, even though students still value collaboration in principle. In other words, positive attitudes toward teamwork are not enough; clear and equal accountability is essential for group work to succeed. Interpretively, accountability and reliability act as a trust accelerator. It signals respect for both the project and one’s partners. Yet too much monitoring can feel like surveillance and erode goodwill. One student said that “a check-in every few hours” felt like micromanagement, hinting that accountability without autonomy breeds friction. Computer-science educators make a similar observation: too little accountability invites social loafing, but too much stifles creative risk-taking and slows decisions [34].

4. Discussion

The findings of this study shed light on the nuanced and multifaceted criteria that IT students use when selecting group project partners in collaborative programming settings. Across the five identified themes—Personal Relationships & Familiarity, Work Ethic & Dedication, Communication & Teamwork, Reliability & Accountability, and Technical Skills & Competence—it is evident that students prioritize interpersonal trust and collaborative fit over technical proficiency when forming teams.

The preference for familiar partners supports previous findings in the literature that emphasize the role of existing social bonds in reducing coordination costs and enhancing perceived cohesion [19,20]. Familiarity, as observed in this study, functioned not only as a proxy for trust but also as a facilitator of quicker team formation and smoother initial collaboration. However, this preference may inadvertently limit exposure to diverse perspectives, a concern echoed by [21], who warned that close-knit teams can experience reduced innovation due to homogeneity in thought and approach.

Students also highly valued work ethic and accountability—traits perceived as non-negotiable in a team environment where contribution inequality can derail group outcomes. This aligns with [22], who found that reliability often supersedes skill in initial partner selection. Participants in this study articulated a clear moral economy in which dedication and responsibility act as social contracts that guard against free-riding. These relational dynamics reflect the findings by [32], who emphasized the importance of accountability in enhancing project-based learning outcomes.

Interestingly, while technical skill was acknowledged as valuable, it was not the dominant factor in partner selection. Students often saw competence as an amplifier of team performance only when trust and communication were already established. This mirrors findings by [25], who noted that self-formed teams that prioritized reliability and interpersonal fit before skill balance performed better overall. Similarly, Ref. [26] reported that diverse teams outperformed homogeneous high-skill groups when strong communication norms were present.

The importance of communication and teamwork further illustrates the socio-technical nature of programming education, where interpersonal interaction is critical to managing complexity and maintaining cohesion. The work in [28] highlighted that clear and consistent communication positively correlates with project quality, a point reinforced by several students in this study who described communication as the “glue” holding their teams together. However, as noted by [31], communication without structure can backfire, introducing inefficiencies or even mistrust. This underscores the need for instructional scaffolding to promote not only open dialogue but also task-focused interaction.

These insights suggest that while students appreciate the technical demands of software development, they conceptualize successful collaboration primarily through a relational and behavioral lens. Effective group work, in their view, stems more from shared commitment and open communication than from isolated pockets of technical brilliance. This supports broader pedagogical arguments for project-based learning (PBL) as a vehicle for holistic skill development [8,9].

From a curricular standpoint, these findings offer implications for how group formation is managed in computing education. Allowing full self-selection may reinforce existing social dynamics and limit students’ growth in collaborative flexibility. As the work in [10] suggest, scaffolding group processes and encouraging diversity in team composition can improve learning outcomes and better simulate professional environments. Future interventions might include guided team formation with partial instructor input, reflective partner-choice exercises, or tools to balance familiarity with skill complementarity.

While this study provides valuable insights, several limitations must be acknowledged. First, the use of a convenience sample drawn from a single institution restricts the generalizability of the findings. Future studies could broaden the scope by including multiple institutions across diverse cultural and educational contexts to strengthen external validity. Second, the reliance on self-reported motivations introduces the risk of social desirability bias, as students may have portrayed their partner choices in an idealised manner. Triangulating self-reports with observational data, peer evaluations, or digital trace data (e.g., GitHub commits) would provide a more balanced view. Third, the present study captured students’ initial partner-selection preferences without examining how these choices influenced actual project outcomes, learning gains, or team performance over time. Longitudinal designs that track teams from formation through project completion would help reveal whether initial preferences translate into effective collaboration and measurable learning benefits.

Despite these limitations, the study establishes an important foundation for understanding the relational dynamics that guide partner selection in collaborative programming. By highlighting students’ priorities and rationales, it opens the door for future research to connect selection practices with actual outcomes, thereby advancing both theory and pedagogy in computing education.

5. Conclusions

This study explored the factors influencing IT students’ selection of group project partners within collaborative programming environments. By analysing qualitative responses from 103 software development students, the research identified five key themes shaping partner choice: Personal Relationships & Familiarity, Work Ethic & Dedication, Communication & Teamwork, Reliability & Accountability, and Technical Skills & Competence. The findings highlight that students tend to prioritise interpersonal trust, dedication, and communication effectiveness over pure technical skill, suggesting that relational dynamics are central to how collaborative work is navigated in educational settings.

The results offer important implications for project-based learning design in IT curricula. Understanding the factors students value can help educators create more intentional group-formation strategies, balancing the need for psychological safety with the benefits of diverse technical skill sets. However, several limitations must be acknowledged. First, the study employed a convenience sample from a single institution, which may limit the generalisability of the findings across different educational and cultural contexts. Second, self-reported motivations may be subject to social desirability bias, with students possibly presenting idealised reasons for their choices. Third, the study focused on initial selection preferences rather than tracking how these choices impacted actual project outcomes or learning gains over time.