Jira Create New Project: The Complete Step-by-Step Guide

Creating a Jira project can feel simple until Jira asks about templates, project types, access, workflows, and permissions. Choose the wrong option, and your team may spend weeks working around a setup that never matched the way you operate.

That frustration grows when people cannot find the right project, tasks follow inconsistent workflows, or private work becomes visible to the wrong team. A rushed setup often creates more administration than productivity.

But here's the truth: you can create a reliable Jira project in a few deliberate steps. This guide shows you how to choose the right project type, configure the essentials, test your setup, and keep the project manageable as work grows.

How to Create a New Jira Project

Creating a new Jira project means choosing a project template, naming the project, setting access controls, and configuring workflows for a specific team or workstream. Jira Cloud usually guides you through this process with a project creation wizard.

1. Open the project creation menu. Sign in to Jira, select Projects in the top navigation, and choose Create project or Create project from the project directory.

2. Select a suitable project template. Choose a template that matches the work. Software teams may need Scrum or Kanban, while business teams may prefer a task tracking, project management, or service management template.

3. Choose the project type. Jira may offer team-managed and company-managed projects. Team-managed projects give smaller teams more independence. Company-managed projects support centralized schemes and consistent administration across several teams.

4. Enter the project name. Use a clear name that explains the team, product, or initiative. For example, “Website Redesign” is easier to recognize than “Project 7.”

5. Review the project key. Jira creates a short key for issue references, such as WEB or OPS. Pick a memorable key because it appears in issue IDs and links.

6. Set the project lead. Choose the person responsible for daily administration, workflow questions, and coordination with the Jira administrator.

7. Configure access. Decide who can browse the project, create issues, edit work, transition issues, and administer project settings. Start with the smallest practical audience.

8. Finish project creation. Confirm the settings, then select Create. Jira opens the new project and makes its board, issue types, and navigation available.

9. Test the setup. Create a sample issue, move it through the workflow, check visibility, and confirm that notifications reach the right people.

10. Remove test content. Delete or close any practice issues before the team begins real work. This keeps reports and activity views accurate.

Here's why this order works: you define the operating model before inviting everyone into the project. A clear template and access plan prevent many problems that otherwise appear after launch.

Choose the Right Jira Project Type

The project type affects administration, customization, permissions, and how much control your team has over its own setup. Choosing one should reflect the team’s size and governance needs.

Team-Managed Projects

Team-managed projects are designed for teams that want to configure their work independently. A project administrator can often adjust issue types, workflows, fields, and board settings without relying on a Jira administrator.

For example, a small marketing team could create a team-managed project with statuses such as Backlog, In Progress, Review, and Done. The team can change those stages as its campaign process develops.

This option works well when speed and local control matter. It can become harder to govern when many teams create different workflows for similar work.

Company-Managed Projects

Company-managed projects use centrally administered schemes. Jira administrators can standardize workflows, permission schemes, notification schemes, issue types, and screens across multiple projects.

A software organization with ten development teams may prefer this approach. Every team can use a familiar bug workflow, while administrators retain control over security and reporting standards.

Company-managed projects suit organizations that need consistency, auditability, or cross-team reporting. They usually require more planning before changes are introduced.

Software, Business, and Service Work

Jira’s templates are organized around different work patterns. Software templates commonly include backlogs, sprints, releases, and development-oriented issue types. Business templates may focus on tasks, approvals, and deadlines.

Service projects are built around requests, queues, service-level targets, and support communication. A help desk should use a service-oriented setup instead of forcing support requests into a software board.

You might be wondering: which template should you choose if your team is unsure? Start with the simplest template that supports the current process. You can expand the configuration after real work reveals a need.

Configure the New Project After Creation

Jira creates a working shell, but your team still needs a practical operating setup. Configure the elements that shape daily work before inviting a large group.

Define Issue Types

Issue types describe the kind of work being tracked. Common examples include task, story, bug, epic, request, and improvement.

Keep the initial list short. If a team has twelve issue types, people may hesitate over basic decisions. A product team might begin with Epic, Story, Task, and Bug.

Add another type only when it supports a distinct workflow, report, or responsibility. A separate “Risk” type may make sense if risks require owners, review dates, and escalation.

Build a Useful Workflow

A workflow shows how work moves from creation to completion. The stages should reflect real decisions rather than every minor activity.

For example, a content team might use To Do, Writing, Editing, Approval, and Published. A development team may need To Do, In Progress, Code Review, Testing, and Done.

Let me explain: a workflow becomes useful when each transition answers a question. “Testing” tells you that implementation has finished and verification is underway. “Done” should have a shared meaning.

Set Up the Board

The board should help the team see current work quickly. Map each workflow status to a visible column and choose a layout that supports the team’s working style.

A Kanban team may add work-in-progress limits to prevent too many tasks from entering development at once. A Scrum team may organize the board around a sprint and monitor unfinished work near the sprint end.

Use filters carefully. A board that hides blocked issues or unassigned work can make performance appear healthier than it is.

Configure Notifications

Notifications should keep people informed without creating constant noise. Review events such as issue creation, assignment, comments, mentions, status changes, and resolution.

For example, a project lead may need updates when a high-priority issue changes status. Every team member may only need notifications for assignments and direct mentions.

Too many alerts encourage people to ignore all alerts. Test the notification experience with a small group before enabling broad communication.

Set Jira Project Permissions and Access

Permissions determine what people can see and do. A carefully configured project protects sensitive work while giving contributors enough access to complete their responsibilities.

Separate Visibility from Administration

Project visibility and project administration are different responsibilities. Someone may need to create and update issues without changing workflows, permissions, or project settings.

Consider three practical groups:

• Contributors: create, edit, comment on, and transition assigned work.
• Leads: manage priorities, assign work, review progress, and coordinate reporting.
• Administrators: manage project configuration, access, workflows, and integrations.

Giving every contributor administrative access makes accidental changes more likely. It also makes ownership unclear when settings need review.

Use Least-Privilege Access

Least privilege means granting only the access required for a role. A contractor who updates assigned tasks may not need permission to browse private planning issues.

Review access with a simple scenario. Ask, “Can this person perform their work without seeing unrelated information?” If the answer is yes, narrow the permission scope.

Check Issue-Level Security

Some projects contain sensitive issues involving budgets, personnel, security findings, or customer details. Issue-level security can restrict individual issues while the broader project remains available to the team.

Use this feature sparingly. Excessive restrictions can prevent collaboration and make reporting confusing. A separate restricted project may be clearer for highly confidential work.

Organize Work in Jira From Day One

A new project becomes valuable when people can quickly understand what matters, what needs attention, and who owns the next action. Organization starts with consistent issue content.

Write Clear Issue Summaries

Use summaries that explain the action or outcome. “Fix checkout error for mobile customers” gives more direction than “Checkout issue.”

A useful summary helps during search, board scanning, sprint planning, and status meetings. It also reduces the need to open every issue for context.

Use Descriptions for Working Context

Give each issue enough information to start work. Include the goal, relevant background, acceptance criteria, constraints, and expected result.

For a website change, acceptance criteria might include mobile behavior, accessibility checks, analytics tracking, and approval by a designated reviewer.

Choose Fields Carefully

Fields can capture priority, assignee, due date, components, labels, estimates, and business impact. Every field should help someone make a decision or produce a useful report.

If people must complete twenty fields before creating a simple task, they may avoid Jira or enter meaningless values. Keep required fields limited to information that genuinely matters.

Create Naming Conventions

Agree on conventions for labels, components, epics, and versions. For example, use customer-facing consistently rather than mixing customer-facing, external, and client.

Consistency improves filtering. It also keeps dashboards useful when several people create issues over many months.

Where ONES.com Fits for Project Work

ONES.com is a project and product management platform that can support teams seeking structured planning, task tracking, collaboration, and reporting in one environment.

You might consider it when your team needs a broader work management experience or wants to compare alternatives before committing to a Jira-centered workflow. The right choice depends on your process, integrations, permissions, and reporting requirements.

Capabilities to Evaluate

• Project planning: organize initiatives, milestones, dependencies, and delivery targets.
• Task management: assign work, set priorities, track progress, and clarify ownership.
• Issue tracking: record problems, requests, defects, and follow-up actions in a structured workflow.
• Agile planning: support backlogs, iterations, prioritization, and team delivery routines.
• Resource visibility: review workload, capacity, and competing commitments across projects.
• Reports and dashboards: monitor status, deadlines, risks, and key performance indicators.
• Team collaboration: keep comments, updates, decisions, and responsibilities connected to work items.
• Workflow customization: adapt statuses, fields, and processes to match how your team operates.

For example, a product organization could compare its Jira setup with ONES.com by testing the same planning scenario in both environments. Track how quickly someone creates a work item, finds dependencies, updates status, and produces a progress view.

The best part? A short hands-on evaluation reveals practical differences faster than feature lists. Include the people who create work, manage delivery, and review progress.

Test and Launch the Jira Project

Testing gives you a chance to fix friction before it affects real work. Treat the first setup as a controlled pilot rather than a finished operating model.

Run a Sample Workflow

Create a sample issue and move it through every relevant status. Check whether required fields appear at the right time and whether transitions match actual responsibilities.

For example, if only a tester can move an issue into Verified, confirm that the permission works. Then test what happens when the issue fails verification.

Test Different Roles

Sign in with accounts representing a contributor, project lead, and administrator. Confirm that each role can complete its expected tasks and cannot access unrelated controls.

Role testing often catches problems that an administrator account hides. An administrator may see every project and action, while a contributor encounters a missing permission or an invisible board.

Prepare a Short Team Guide

Explain how to create issues, choose issue types, set priorities, update statuses, mention teammates, and report blockers. Keep the guidance close to the actual workflow.

A short example is more helpful than a long policy. Show one well-written task, one bug, and one blocked issue so people can copy the expected pattern.

Review After Two Weeks

After the team has completed real work, review the project for recurring friction. Look for unused fields, unclear statuses, stale assignments, duplicate labels, and notification complaints.

Make changes in small batches. Changing the workflow, issue types, and permissions at the same time makes it difficult to understand what improved or caused new confusion.

Common Challenges

Challenge: The Wrong Template Was Chosen

Problem: The project has features your team never uses, while essential views or workflows are missing.

Solution: Compare the team’s daily work with the available templates. Simplify the current project where practical, or create a better-aligned project and migrate carefully after reviewing issue history and reporting needs.

Challenge: People Cannot See or Update Issues

Problem: A contributor receives permission errors, cannot access the board, or sees fewer issues than expected.

Solution: Check project roles, permission schemes, issue-level security, board filters, and group membership. Test with the affected person’s role instead of relying on an administrator account.

Challenge: The Workflow Has Too Many Statuses

Problem: Team members debate which status to choose, and issues remain stuck between similar stages.

Solution: Combine statuses that represent the same decision. Keep a stage only when it changes ownership, reporting, approval, or the next action.

Challenge: Notifications Become Distracting

Problem: People receive alerts for every change and begin ignoring important messages.

Solution: Prioritize assignments, mentions, priority changes, and meaningful workflow transitions. Review notification settings with the team after the first few weeks.

Challenge: Reports Do Not Match Reality

Problem: Dashboards show work as active or complete even though the team’s actual progress differs.

Solution: Review board filters, status mappings, resolution rules, stale issues, and required fields. Reports are only as reliable as the habits and definitions behind them.

FAQs

Can anyone create a new Jira project?

That depends on your Jira permissions and organization settings. Many Jira environments restrict project creation to administrators or approved project creators. If you cannot see the creation option, ask your Jira administrator to grant the appropriate permission or create the project for you.

What is the difference between team-managed and company-managed Jira projects?

Team-managed projects give individual teams more control over configuration. Company-managed projects use centralized schemes and administration, which helps organizations standardize workflows and permissions. Choose team-managed for local flexibility and company-managed for stronger governance across multiple teams.

Can I change the Jira project key after creation?

Jira may allow an administrator to change a project key, depending on your edition and configuration. Changing it can affect issue references, links, integrations, automation, and reports. Treat the key as a long-term identifier and choose it carefully during setup.

Should I create one Jira project for every team?

There is no universal rule. Create separate projects when teams need different access controls, workflows, reporting, or administration. Keep work together when teams share the same process and need visibility across a common backlog. Too many projects can fragment reporting and make work harder to discover.

Can I create a Jira project from a template?

Yes. Jira provides templates for software development, business work, service management, and other common processes. A template gives you a starting structure, including issue types, boards, and workflows. Review every setting before launch because a template may include stages or fields your team does not need.

How should I name a Jira project?

Use a name that clearly identifies the product, team, service, or initiative. “Mobile Checkout” is more useful than “Team Alpha.” Avoid temporary names when the project will remain active for a long time. Also choose a concise project key that people can recognize in issue references.

Conclusion

A Jira project works best when its template, project type, permissions, workflow, and board all reflect real team behavior. Start with the simplest structure that supports the work, then refine it after people have used it.

Remember the main steps: create the project, choose the right management model, define issue types, map a practical workflow, test access, and review the setup after launch. Small decisions early can prevent major administration later.

If project creation feels confusing, the problem is usually unclear process design rather than Jira itself. Agitate the right questions before launch, test the full work cycle, and your new project can give the team a dependable place to plan and deliver work.