How to List Projects on a Resume

A useful project entry explains the setting, your responsibility and what exists. This guide covers selecting, placing and describing project evidence. It does not teach portfolio construction or software development.

The university resources in Sources address their own audiences, including students and technical applicants; they are not universal employer rules. Context, permission, duplication and project-status checks here are WizeCV editorial safeguards, not a hiring formula or an ATS scoring model.

Which projects should you include on a resume?

Select projects that show relevant capabilities through work you can explain. MIT CAPD’s Resumes guidance recognizes class and personal projects among possible experiences; its Career toolkit also includes unpaid, volunteer and freelance activity. Payment is not the selection test, but the original context must remain visible.

• Relevance: identify which task or capability the project demonstrates for the intended vacancy.
• Contribution: name meaningful work you personally performed, rather than only the team’s objective.
• Evidence: retain an accurate private record of the task, tools, output and any claimed result.
• Useful output: explain what was created or investigated, even when there is no business metric.
• Recency: consider whether the work still represents your capabilities; there is no fixed year cutoff.
• Added value: check whether the same evidence is already clear in Experience or Education.

Compare projects before polishing their descriptions. Prefer relevant work with an explainable personal contribution over an impressive name. Unfinished work can qualify if its current output is useful and its status is explicit. Remove entries that merely increase the count.

A resume can have zero worthwhile Projects entries. Neither a separate Projects section nor a universal number of projects is required. The section itself does not establish an ATS score benefit.

Should projects go in Experience, Education or a separate section?

Place a project where its relationship to your history is clearest. UC Berkeley’s Sample Resumes page allows projects within Work Experience or a Projects section. WizeCV’s placement suggestions below preserve the real setting rather than treating all projects as paid work. Education or another accurately labeled context can also be appropriate.

Use one primary detailed entry. If an employer project is already explained under the relevant role, a second full account in Projects usually repeats evidence. A short reference elsewhere can connect contexts when useful. It should add orientation rather than repeat the same tasks and result.

Relevant Experience can include unpaid work with clear context. A heading cannot make a student project a job or a personal project a client engagement. Choose the label and placement together.

What details belong in each project entry?

Build a factual project record before shortening it for the resume. Harvard MCS’s Create a Strong Resume guidance recommends specific, fact-based descriptions. WizeCV’s project-entry model applies that principle to context and scope; not every entry needs every detail or a separate line for each step.

1. Project context: identify employer/internal, genuine client, academic, capstone, research, personal, portfolio or volunteer work.
2. Your contribution: describe the component, task or workstream you personally completed or supported.
3. Tools/methods actually used: connect named tools to your work, rather than the team’s entire technology stack.
4. Output/current status: name the artifact or investigation and distinguish concept, prototype, ongoing work and completed output.
5. Supported result: include an outcome only when it is supported and attributable; an output alone can be enough.
6. Best resume placement: choose the primary section that explains the relationship, then remove duplicate detail.

Use an understandable name and a description that explains context and responsibility. Add dates only when known and useful; never invent completion dates. A permitted link is optional. Keep a fuller private record for review without publishing restricted evidence.

How should employer and internal projects appear?

Keep the official employment title and employer relationship intact. An Operations Analyst who supported an internal initiative remains an Operations Analyst. If you coordinated one workstream, name that workstream; do not describe management of the entire project unless you held that responsibility. A genuine client project needs the same clarity about the actual employment or freelance relationship.

Tracking costs does not establish budget authority. Reviewing a deliverable does not establish approval authority. A project’s total value is not a budget you personally controlled. Participating in implementation does not establish that you led implementation.

Protect employer and client information

Describe restricted work at an accurate, permitted level of generality. A process description may be enough without access to the original system. Permission matters even when a document or repository is technically reachable. If uncertain, clarify what may be shared.

• Do not share confidential documents, restricted source code or client identities without permission.
• Exclude internal URLs, secrets/API keys, proprietary datasets, sensitive screenshots and personal data.
• Omit restricted metrics; do not invent replacement numbers or imply an unverified improvement.

Fictional example: an internal tracking project

All facts in this example are fictional. The weak version deliberately makes unsupported claims; the improved version uses only the supplied facts.

How should academic, capstone and research projects appear?

Name the institution, course or research setting when relevant and factual. Identify a university capstone as a capstone, a research assignment as research, and team work as team work. UC Berkeley’s Sample Resumes guidance asks research applicants to describe their role and contributions; that is different from presenting the entire lab’s work as their own.

State what you personally analyzed, designed, built or documented and what the academic output was. If the work used a public or synthetic dataset, retain that description. Do not turn it into client data. A submitted report, research component or prototype is not evidence of commercial consulting, production deployment or sole authorship.

A genuine paid research appointment can also be employment; describe that appointment accurately. Academic context alone does not prove employment. Keep the distinction visible rather than omitting context to imply greater seniority.

Fictional example: a university research capstone

These fictional source facts specify the tool, team context and output. The weak version introduces a client and deployment that never existed.

How should personal, portfolio and volunteer projects appear?

Label independent work as personal or independent. A self-directed design exercise does not become a client engagement because it resembles a real product. State the actual output and status, without inventing customers, users, revenue, adoption or usability findings. A portfolio can display academic, employer or personal work; displaying it does not change its original context.

Volunteer entries should retain the organization, volunteer setting and actual contribution. Being a participant does not establish program leadership, and a volunteer contributor is not automatically an employee. MIT CAPD’s Career toolkit recognizes relevant unpaid and personal experience; WizeCV’s safeguard is to preserve how that experience actually occurred.

Fictional example: a personal portfolio prototype

The fictional facts below support independent design and a clickable prototype. They supply no public URL or user study, so the improved entry adds neither.

How do you distinguish your contribution from the team’s work?

Give the shared project context, then identify your own component. Yale OCS’s Writing Impactful Resume Bullets explicitly directs candidates to describe their own action and contribution. Here that supports attribution, not a requirement to claim a metric or to adopt a complete bullet formula.

Choose verbs such as contributed, designed, implemented, analyzed, documented, supported, coordinated or led according to what happened. “Built X” can imply ownership of the whole output when you built only a limited component. Name the component explicitly. Do not borrow tools or results from teammates whose work you did not perform.

If the team achieved an outcome, distinguish that shared outcome from your contribution and use it only when supported. Where attribution is unclear, describe your task and output without claiming personal credit for the full result. The Accomplishment Bullets guide in Related Articles covers general action/result writing and measurement methods.

How do you describe tools, progress and results accurately?

Use a status that matches what currently exists. A completed prototype is still a prototype; “completed” refers to a defined output, not every possible stage. These WizeCV editorial distinctions prevent a short entry from implying a later stage of development.

Name only technologies and methods you actually used. MIT CAPD’s Resumes guidance recommends contextualizing techniques and tools in experience descriptions. Specify the task where useful. Using a tool for one limited task does not establish advanced expertise. Do not add a technology because a vacancy requests it, because it commonly accompanies another tool or because AI suggested it.

An output is what you created: a prototype, report, workflow or documented component. A result is what happened because of it. A time reduction needs evidence; producing the workflow does not prove the reduction. Completion, delivery, participation and deployment do not by themselves establish a business outcome. You can describe a useful output without inventing a numerical result.

When should you include a project or portfolio link?

Include a link when it adds relevant, permitted evidence and the intended reviewer can access it. Yale OCS’s STEMConnect Technical Resume Sample treats a personal website, portfolio or GitHub link as optional in its technical-resume context. That does not make a link mandatory for every profession or project.

• Check the destination before submission, including access restrictions and what the reviewer will actually see.
• Explain your association with the project, original context and contribution on the destination as well as the resume.
• Share only material you are permitted to disclose; do not publish confidential repositories or restricted employer/client work.
• Leave the link out when it is broken, irrelevant, inaccessible or unsafe to share. The entry can stand without it.

A GitHub repository or portfolio URL does not itself prove authorship, competence, commercial use or project success. A link provides a place to inspect permitted material, not independent verification. If a team repository is appropriate to share, make your component clear; do not imply that everything visible is your work.

How can you add and review projects in WizeCV?

WizeCV supports resume creation and upload, an editable Projects section and project-description improvement. The editor offers a name, description, technologies and optional URL. Express relevant context naturally in the name or description.

There are no dedicated project date, role, employer or completion-status fields. Do not expect a separate control for those details. Templates control section order; review the chosen preview rather than assuming that the project entry can be placed anywhere. PDF and DOCX export include the current project name, description, technologies and URL when present.

Project improvement can suggest a revised description; review it against your source facts. Tailor to Job creates a separate tailored resume and currently preserves project records rather than automatically rebuilding the Projects section. ATS analysis is available for resume/job-description comparison; it does not verify project ownership or test a portfolio destination.

WizeCV does not independently verify project ownership, employment, dates, technologies, leadership, deployment, results, portfolio ownership or competence. An AI revision is a suggestion, not evidence. Reject any change that introduces a client, tool, seniority, completion stage or outcome you cannot support.

Common project-entry mistakes

• Filling space with a section or claiming an automatic ATS benefit.
• Repeating the full employer project under Experience and Projects.
• Hiding original context to imply employment or client work.
• Claiming the team’s output, leadership or budget authority as yours.
• Inflating prototype, ongoing-work or demo status.
• Adding unsupported tools/metrics or impermissible links.

Final project-entry checklist

• Can the reader see the original context and why this project is relevant?
• Does the entry identify your contribution separately from the team’s output?
• Are title, authority, tools, dates and current status accurate?
• Are outputs distinguished from supported results, without invented metrics?
• Are confidential details omitted and any link permitted and accessible?
• Is there one primary detailed entry, and does the exported resume preserve its meaning?