A team project should show both the shared result and your specific contribution. Credit collaborators, identify the work you owned or supported and explain how the parts connected. You do not need to claim the entire project to demonstrate value. Precise ownership makes collaboration easier to assess and prevents an attractive final artefact from obscuring who did what.
Build the evidence before polishing the presentation
Build a contribution map from records such as project notes, task boards, commits, drafts or agreed responsibilities. These records are evidence aids, not perfect measurements of value: a commit count, for example, does not capture every useful discussion or design decision. Use them to reconstruct the work accurately rather than rank teammates.
Describe the overall project briefly, then mark your responsibilities. Separate implementation, review, coordination and research instead of using “we” for everything. Explain a handoff or disagreement that affected your part and how it was resolved. Obtain permission before publishing shared work, and respect confidential or personal information even when your own contribution is substantial.
| Area | Useful approach | What to check |
|---|---|---|
| Shared outcome | Describe what the team delivered together | Do not imply individual ownership of the whole result |
| Individual contribution | Name the components, decisions or coordination you performed | Use evidence rather than broad claims of involvement |
| Collaboration | Explain a handoff, review or resolved disagreement | Credit the people whose work enabled the final artefact |
A fictional worked example
Fictional example: a four-person college team builds an event-registration demo. Maya implemented the form validation and wrote the setup instructions; another teammate designed the screens, while others handled data and presentation. Her portfolio credits the team and shows the parts she changed.
She explains a discussion about error messages and the revised validation behaviour, rather than claiming she designed and built the entire application. The shared outcome remains visible, but her individual evidence is inspectable. She does not use the number of commits as a substitute for explaining the quality or significance of her contribution.
Shared outcome
Show: Describe what the team delivered together
Check: Do not imply individual ownership of the whole result
Individual contribution
Show: Name the components, decisions or coordination you performed
Check: Use evidence rather than broad claims of involvement
Collaboration
Show: Explain a handoff, review or resolved disagreement
Check: Credit the people whose work enabled the final artefact
Apply the process to your own material
- Reconstruct: Use project records to identify responsibilities and actual contributions.
- Separate: Distinguish the shared result from your implementation, review or coordination work.
- Credit: Name collaborators and obtain appropriate permission for shared materials.
- Validate: Check the account with records and, where practical, a teammate before publishing.
Use an actual piece of your own work for this exercise, or create a clearly labelled practice example. Keep the original and revised versions so you can explain what changed. Ask a reviewer to identify the main contribution without additional explanation, then note where their interpretation differs from what you intended. Revise the evidence or wording that caused the mismatch rather than adding an unsupported claim to make the result sound stronger.
- Reconstruct
Use project records to identify responsibilities and actual contributions.
- Separate
Distinguish the shared result from your implementation, review or coordination work.
- Credit
Name collaborators and obtain appropriate permission for shared materials.
- Validate
Check the account with records and, where practical, a teammate before publishing.
Move forward only when the previous step is clear enough to explain. A finished-looking file still needs a content and usability review.
Review the result before sharing
Read every sentence containing “I,” “we,” “led” or “owned.” Check whether the wording matches the actual responsibility. Ask a teammate to review the contribution summary where practical. Keep credits visible and link to shared artefacts only when appropriate. A good team case study should make collaboration more understandable without diminishing others or inflating your own role.
A closer check that strengthens the evidence
Describe a handoff in enough detail to reveal collaboration. State what you received, what you changed and what the next teammate needed from you. This can show practical communication more clearly than a claim that you are a team player. For example, a developer may have clarified missing interface states with a designer, or a writer may have reorganised technical notes after an expert review. Credit both sides of the interaction. The point is to demonstrate how your contribution fitted the work, not to turn every shared decision into proof that you led the entire project.
Common questions
Should I use I or we in the case study?
Use “we” for genuine team actions and “I” for your own contribution, with enough context to avoid ambiguity. Neither pronoun is automatically better. The reader should understand which decisions and outputs you can claim individually and how they fit the shared result, rather than having to infer ownership from the final artefact.
Can I show the whole project in my portfolio?
Possibly, if you have appropriate permission and make your contribution clear. Shared ownership and confidentiality still matter. Explain the team context near the beginning and credit collaborators. Do not assume that participation automatically grants unrestricted permission to publish every file, internal discussion or personal detail from the project.
Do commit counts prove my contribution?
They can provide context but are not a complete measure of work or quality. Design, review, research and coordination may not appear proportionately in commits. Use records to support a specific explanation of what you did. Avoid ranking teammates or claiming leadership solely from a larger activity count.
How do I describe a supporting role?
Name the concrete support you provided, such as reviewing calculations, testing a feature, editing a report or coordinating a handoff. Explain why it mattered to the work. Supporting contributions can be valuable evidence without being renamed as leadership. Precision is more convincing than inflating the role to sound senior.
What if responsibilities changed during the project?
Explain the change briefly when it affects your contribution. Distinguish the original plan from what you actually delivered. Records can help resolve uncertainty. A case study need not reproduce every task reassignment, but it should not claim ownership of work that moved to someone else before completion.
Can I discuss a team disagreement?
Yes, when it reveals useful collaboration and you describe it respectfully. Focus on the competing constraints, evidence and decision process rather than blaming individuals. Avoid exposing private conversations unnecessarily. The purpose is to show how you worked through a problem, not to portray teammates as obstacles in your personal success story.
What if a teammate disagrees with my description?
Review the records and discuss the specific claim before publishing. Clarify or narrow wording where ownership is uncertain. Do not use the portfolio to settle a dispute. If agreement or permission cannot be established, choose a different artefact or describe only the part you can support and appropriately share.
How should credits appear in a short resume bullet?
Keep the wording concise but indicate the team context and your role. For example, describe implementing a specific feature within a team project rather than claiming the whole system. The portfolio can provide fuller credits. The short version should remain accurate even when a reader never opens the longer case study.
Sources and further reading
Reviewed 7 November 2026. Examples and exercises are original editorial guidance. University advice reflects its own context; employer instructions and local requirements take priority.
Resume & Workplace Desk
MP Job Hub’s organisational byline for presenting genuine work and communicating clearly in professional settings.
Resumes · Portfolio evidence · Interviews · Workplace communication
View profile →Read our research process or request a correction.
