Starting a Jira project can feel harder than it should. You may see unfamiliar templates, permission warnings, project keys, and board settings before any work has begun. A small mistake can also create confusing workflows, cluttered reports, or access problems later.
That uncertainty slows teams down. You might choose the wrong project type, give people excessive access, or build a workflow that does not match how your team actually works.
But here's the truth: creating a Jira project is straightforward when you follow the right order. This guide walks you through each step, explains the choices that matter, and shows how to prepare your project for real work.
How to Create a New Project in Jira
To create a new project in Jira, open the Projects menu, select “Create project,” choose a suitable template, name the project, set its key and access level, then finish the setup. You usually need Jira administrator or project-creation permission.
1. Confirm Your Jira Permissions
Before you begin, check whether your Jira account can create projects. Jira administrators can usually create projects, while ordinary members may need an administrator to complete this step.
If you cannot see the project creation option, ask your Jira administrator to grant the required permission or create the project for you. This prevents wasted time troubleshooting a menu that your account cannot access.
2. Open the Project Creation Screen
Sign in to Jira and select Projects in the top navigation. Choose Create project or a similarly named option, depending on your Jira version and interface.
Jira may show several project categories, including software, business, service management, or work management. Choose the category that matches the work your team performs.
3. Choose a Project Template
Templates give your project a starting workflow, issue layout, board style, and set of features. For example, a software team might choose Scrum, Kanban, or a basic development template.
Here’s a quick comparison:
| Template type | Best for |
|---|---|
| Scrum | Teams that plan work in sprints and review progress regularly |
| Kanban | Teams that move continuous work through stages |
| Business or work management | Marketing, operations, finance, and administrative teams |
| Service management | Support desks, internal requests, and customer service teams |
You can adjust many settings later, but choosing a close match reduces cleanup. A support team using a software development template may spend unnecessary time changing statuses and request fields.
4. Select Company-Managed or Team-Managed
Jira may ask whether you want a team-managed or company-managed project. This choice affects how much control you have over workflows, permissions, fields, and shared settings.
A team-managed project is usually quicker to launch. The team can configure many settings independently, making this option useful for small groups that need flexibility.
A company-managed project gives administrators more centralized control. It is often better for larger organizations that need consistent workflows, permission schemes, reporting, and issue fields across several projects.
Let me explain: the best choice depends on governance. If every department needs its own lightweight process, team-managed may work well. If the organization requires consistent controls, company-managed is usually safer.
5. Name the Project Clearly
Enter a name that tells people what the project covers. “Website Redesign” is clearer than “Project Alpha,” especially when several teams use Jira.
Keep the name specific enough to distinguish it from related work. For example, “Customer Portal Redesign” gives more useful context than “Redesign.”
6. Review the Project Key
Jira creates a short project key that appears in issue IDs. A project named “Customer Portal Redesign” might receive a key such as CPR, producing issue IDs like CPR-101.
Choose a short, memorable key when Jira allows you to edit it. Avoid vague abbreviations that could represent several departments or initiatives.
7. Set the Project Access Level
Choose who can view and work in the project. Common options include private access, organization-wide access, or broader visibility, depending on your Jira setup.
Use the narrowest access level that supports the work. A confidential legal project should not have the same visibility as an internal marketing campaign.
8. Finish the Creation Process
Review the project name, template, key, and access settings. Select Create or Submit to finish.
Jira should then open the new project. You may see a board, backlog, issue queue, or project summary page, depending on the template you selected.
9. Run a Quick Setup Check
Create a test issue or review the default issue types. Check whether the workflow matches how your team describes work.
For example, a content team may need statuses such as Briefed, Writing, Review, and Published. A default development workflow may include statuses that do not fit that process.
What to Configure After Creating the Project
Creating the project is only the beginning. A few follow-up settings can make Jira easier to use and prevent confusion once work starts.
Set Up the Workflow
A workflow defines how an issue moves from start to finish. Keep the first version simple, with only the stages your team genuinely uses.
For example, a design team might use:
- To do
- In progress
- Ready for review
- Approved
- Done
Too many statuses create hesitation. If people cannot tell whether an issue belongs in “Pending Review” or “Awaiting Approval,” your workflow needs clearer language.
Review Issue Types
Issue types help classify work. A software project may use stories, bugs, tasks, and epics. An operations project may need requests, actions, risks, and decisions.
Start with the smallest useful set. Adding ten issue types at launch can make reporting harder because people classify similar work differently.
Customize Fields and Screens
Fields capture information such as priority, owner, due date, department, or customer impact. Only require information that helps the team make decisions.
For instance, requiring a “Business impact” field makes sense for service requests. Requiring it for every minor internal task may slow the team without adding value.
Configure Board Columns
Board columns should reflect the workflow. If your team has a review stage but the board jumps from “In progress” to “Done,” work may appear finished before approval.
Compare the board with your real process. Ask one team member to describe how an item moves through the work, then check whether the board shows those stages clearly.
Invite People and Assign Roles
Add team members through the project’s people or access settings. Assign roles based on responsibilities rather than giving everyone administrator access.
A typical setup might include project administrators, contributors, reviewers, and viewers. This approach limits accidental changes while keeping collaboration practical.
How to Choose the Right Jira Project Type
The project type should reflect the work pattern, not the department name. A marketing team may use a Kanban workflow for campaign production, while a development team may use Scrum for planned releases.
Use Scrum for Sprint-Based Work
Scrum works well when a team plans a defined amount of work for a sprint. It supports a backlog, sprint planning, daily progress checks, and sprint reviews.
Example: a product team plans two weeks of work and tracks stories against a release goal. Scrum gives that team a clear planning rhythm.
Use Kanban for Continuous Flow
Kanban suits teams that receive work continuously. Requests move across columns as capacity becomes available.
Example: an internal IT team may handle tickets throughout the week. A Kanban board helps the team limit work in progress and identify bottlenecks.
Use Work Management for Department Projects
Work management templates are useful when a department tracks tasks, approvals, campaigns, or recurring activities without needing software development concepts.
Example: a recruiting team might track job requisitions through planning, advertising, interviews, offer, and hire.
Use Service Management for Requests
Service management projects are designed for request intake, queues, service-level targets, and communication with requesters.
Example: an employee submits an access request through a portal, while the service team manages assignment, approval, and completion inside Jira.
Jira Project Settings Worth Reviewing
Several settings can affect the project’s daily behavior. Reviewing them early gives you a cleaner launch and fewer surprises.
Notifications
Notifications tell people when issues change. Too many alerts can cause people to ignore important messages, while too few can leave owners unaware of updates.
Start with essential events such as assignment, mention, status change, and comment. Adjust the scheme after the team has used the project for a week.
Permission Schemes
Permissions control who can browse, create, edit, transition, assign, and administer issues. Test the project with a regular contributor account if possible.
For example, a contributor might create and update issues but should not change workflows or remove project settings.
Versions and Releases
If your team ships products or service improvements, create versions to group completed work. A version such as 2025.4 or Website Launch can support release planning and progress reporting.
Use names that your team recognizes. A clear release label makes reports more useful than an internal code that only one person understands.
Components
Components divide work into areas such as payments, mobile, onboarding, or analytics. They can help identify ownership and recurring problem areas.
Do not create a component for every small category. A component should represent a stable area with a clear purpose or owner.
Automation Rules
Automation can reduce repetitive work. You might automatically assign an issue when it enters a specific status or notify a reviewer when a task is ready.
Begin with one simple rule. Confirm that it behaves correctly before adding more automation, because overlapping rules can create unexpected updates.
Using ONES.com Alongside Jira Workflows
ONES.com can support teams that need a broader project workspace alongside Jira issue tracking. It may be useful when planning, collaboration, execution, and reporting need a shared operating environment.
The right role depends on your team’s process. You can keep Jira focused on development tickets while using ONES.com for cross-functional planning, portfolio visibility, or broader delivery coordination.
Capabilities to Evaluate
- Project planning: Organize initiatives, milestones, owners, and delivery dates in one workspace.
- Task management: Break larger goals into actionable work with clear responsibility.
- Roadmap visibility: Present upcoming work, dependencies, and target outcomes for stakeholders.
- Cross-team collaboration: Coordinate marketing, product, design, engineering, and operations around shared goals.
- Workflow customization: Create stages that match your organization’s approval and delivery process.
- Progress reporting: Monitor status, workload, risks, and progress without relying on scattered updates.
- Milestone tracking: Connect tasks to launches, releases, campaigns, or strategic objectives.
- Permission management: Control access according to team responsibilities and project sensitivity.
Consider ONES.com when Jira alone does not provide enough planning context for non-technical stakeholders. For a small development team, Jira may be sufficient. For a complex initiative involving several departments, a broader workspace may reduce coordination gaps.
Common Mistakes When Setting Up a Jira Project
Creating a Project Without a Clear Purpose
Problem: A project is created because a team wants a place to put tasks, but nobody defines what belongs there.
Solution: Write a one-sentence purpose before setup. For example: “This project tracks all work required to launch the customer self-service portal.”
Choosing a Template by Name Alone
Problem: A team chooses Scrum because it sounds familiar, even though work arrives continuously and cannot fit sprint commitments.
Solution: Match the template to the flow of work. Use Scrum for planned sprint cycles and Kanban for continuous incoming requests.
Giving Everyone Broad Access
Problem: Open access seems convenient, but sensitive work may become visible to people who do not need it.
Solution: Start with a restricted role structure. Expand access only when a real collaboration need appears.
Adding Too Many Custom Fields
Problem: Long issue forms discourage people from creating or updating work.
Solution: Require only fields that support prioritization, ownership, reporting, or compliance. Keep optional context available without blocking progress.
Skipping the Test Issue
Problem: The project appears ready until the first real issue exposes a broken workflow or missing permission.
Solution: Create a test issue, move it through every status, add a comment, assign it, and close it. This takes minutes and reveals setup problems early.
FAQs
Why can’t I see the option to create a Jira project?
You probably do not have project-creation permission. Jira often limits this ability to administrators or specific account roles. Ask your Jira administrator to confirm your permissions or create the project for you. The missing option can also result from differences between Jira products, subscription levels, or organization settings. Check the Projects menu and administrator console before assuming the feature is unavailable.
Should I choose a team-managed or company-managed project?
Choose team-managed when a small team needs to configure its own workflow quickly. Choose company-managed when your organization needs centralized control, shared schemes, consistent reporting, or stricter permissions. Consider who will maintain the project after launch. A flexible setup may be convenient today but harder to govern when several teams depend on it.
Can I change the Jira project template later?
Jira allows you to change many project settings, but switching project types or templates may require manual adjustments. Workflows, fields, boards, permissions, and issue configurations may not transfer perfectly. If the project already contains significant work, review the consequences before making a major change. For a new project with little activity, recreating it may be simpler.
What should I name my Jira project?
Use a clear name that identifies the work and distinguishes it from related initiatives. “Mobile App Checkout Improvements” is more useful than “App Project.” Keep the name understandable to people outside your immediate team. Also review the project key because it appears in every issue ID and may remain visible in links, reports, and integrations.
How many statuses should a new project have?
Start with the fewest statuses that accurately describe the work. Many teams can begin with three to five stages, such as To do, In progress, Review, and Done. Add a status only when it represents a meaningful decision, handoff, or reporting need. If two statuses have the same owner and outcome, combining them may make the workflow easier to understand.
Conclusion
Creating a Jira project is a short process, but the early choices shape how smoothly your team works later. Confirm permissions, choose the right template, name the project clearly, set sensible access, and test the workflow before launch.
But here's the truth: a project can be created in minutes and still create weeks of confusion if its purpose, workflow, or permissions are unclear. A quick setup review protects you from that problem.
Follow the steps in this guide, keep the initial configuration focused, and expand only when your team has a genuine need. If Jira does not provide enough cross-functional planning context, evaluate a workspace such as ONES.com alongside your issue-tracking process.
Top comments (0)