How to manage projects vs tasks
Asked by Tyler Miller:

Hello, We are currently using Jira Work Managed to manage our teams tasks. Right now I have 2 projects built, one is for our network team and one is for our systems team. We use these projects to track tasks that need to be done, but these are mainly break/fix, or internal IT tasks (like updating hostnames on devices, or ensuring telnet is turned off on all switches, etc). The teams uses these projects for tracking individual tasks that are potentially unrelated to each other.

What I am struggling with as a manager is how to integrate these tasks and workflows with project work. Sometimes we have additional projects that come up where both network and systems teams are involved. I could create tasks for each of the teams in their current project, but then its hard for me so see what the status of a project is. I could create another Jira project for the work, but then its forcing the team to look at several projects in Jira to see the work they need to do (we could have 20 projects in-flight at the same time).

How have others managed the difference between projects (and the overall work and project completion) vs the individual tasks required for that project and the other tasks the teams are working on?

Open to advice and direction, thank you!


Answers:
author: Lisa Forstberg
body: Hi [@Tyler Miller](/t5/user/viewprofilepage/user-id/1675103) ,

Welcome to the community!

To help you we need to know a little bit more on what you have in your toolbox to work with. You are on Cloud but which Cloud plan are you on? If you are on Jira Cloud Free you have less features to configure.

You are describing exactly what many other companies need, which is a way to handle Operations work (incidents and service requests) separately to Development work. They are two different beasts! Operations is unplanned work with the aim to ensure that business is running with a minimun of disturbance to users and Dev is plannable work which can be a bit more experimental. But sometimes the teams and people involved to a bit of both. They need to have a view for them to see their scope.

Since Jira is flexible, there are many solutions

#### Get started with basic functionality {#toc-hId-351480405}

A first clue to a solution is to explore using different **Boards** to display project work on one and total team work on another. A board can display all the issues from one Jira project or display a specific collection of issues from many Jira Projects so your team don't need to "jump around".

If you store your project work in one Jira Project then each issue in this project needs to have an attribute that signals what teams are involved in the particular issue. Using the Team Custom field could perhaps work for that purpose. I would not really recommend to use the Assignee field as I think it is a good practice for users to actively assign themselves to tasks.

If you have such a field you can create a board for the team that pull issues from multiple projects. Your Filter for the Network Team Board would have a JQL that would look a bit like this:

project = "Network Operations Jira project" OR project = "Project work Jira project" AND Team = Network

That means you will be able to look in the "Project work Jira project" to track the overall progress of a project + the team will look at their board serving them with issues from both work types.

If you have plenty of Jira projects (one for each project) you can also use the Project Categories to group them together and use that in your JQL instead of finding a specific project.

You could swap this solution around and instead add f ex unique issuetypes in your existing team projects to signal that they are "project work" and have a board that collates all issues of the project work issue type into one board where you track project progress. Then the project work is essentially stored inside the existing team projects.

Also another basic step to explore is the use of **Dashboards** to collect issue data from multiple projects. Same here, a clear categorization of "Project work" vs "Operations work" is needed.

Today it seems you have created Team based Jira projects (Network Team vs System Team). Another structure is to make the Jira projects classified per work type (Operations vs Development). I have seen both work:-)

#### More options depending on your toolbox {#toc-hId--1455974058}

If you are on a ++Jira Cloud Premium++ you have the option to use "[Plans](https://support.atlassian.com/jira-software-cloud/docs/get-started-with-advanced-roadmaps/)" functionality. here you can build deeper issue hierarchy structures (Project \> initiative \> Epic \> Story \> Subtask) + other features (timelines and dependency tracking etc )that project tracking often need.

If you have Jira Service Management then the clear recommendation is to use that for your Operations type work, and Jira Work management or Jira software project for your project work.

Also you can extend your Jira with different apps from the marketplace to get additional features (Have a look under Apps if you have any installed)

As you can tell there are many different options for solutions here. All sort of depends on what you have in your toolbox (Free/Standard/Premium + Apps), how big company you are running, what solution will be easiest to scale, how can we minimise admin work for all involved users, are there any transparency restrictions in some projects, what are the needs of the different stakeholders involved (do you have PM's? what are their needs?) etc

Best of luck

Lisa


Tags: cloud

jira-cloud

jira-work-management