nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Project Setup Best Practices

Keith Mangold

We currently use BMC for incident tracking (support calls, service requests) and then BugTracker for software development (defect tracking, new features). We are going to start using JIRA Software & Service Desk as a replacement for both systems. We are using JIRA Cloud (strategic initiative to not have anything locally hosted).

** Organization:
We have about 40+ applications that we've developed in house for back office operations and our field teams to use. Each application pretty much only has 1 developer that maintains it (one developer covers several apps).

We have a Helpline of 4 people that fields calls for application support and other business needs (such as payroll, hr, expense questions, type of things). They will be the primary users of Service Desk.

We have our IT infrastructure team that consists of the DBAs & Network Services that maintains and handles all issues regarding your standard IT needs (scripts to update data / run custom sql reports, servers needing maintenance, routers, Citrix, etc.).

Finally, our Client Services team that receives requests from customers (not necessarily our employees) to make changes to their custom installation of our solutions and manages new customer onboarding.

** Projects:
With all this we have the random projects that may span resources from IT infrasturcture and Development and Client Services. The true temporary timeboxed Project that has a clear beginning, middle and end. We need to track all the tasks that go along with all of them.

** Using JIRA:
Is this a good way to structure this within Jira? (Open to better suggestions)

Project #1 = Product A
Project #2 = Product B
Project #3-40 = Product C to XX
Project #41 = Service Desk / Helpline
Project #42 = IT Requests (Server Issues)
Projcet #43 = Client Services (Customer Needs/Onboarding)
Project #44 = DBA Requests
Project #45-?? = PMO Projects

My issue with this comes to if the a PMO project uses Product B & Product D. The PMO wants to see everything needed for that one specific project, but on the Development side, we want to see all the issues/releases for the one specific Product. Where is it best to place that issue, under the Product D project or the PMO Project?

Do we create a matching release for that Project under Product D? What if the release to Product D is for multiple projects at the same time? Should we just use labels instead to group PMO Projects?

** Change Control Board Items
We have some issues that must go through a CCB to approve before they can be completed. This is generally "run this SQL script against production data" or "give user access to this server" or "add more memory" or "deploy v4.56 of Product D to production." Should that be another Project or should we just use issue types to indicate a CCB item?

Surely we can't be the first to need this and somewhat hoping there is a cookie-cutter template we can follow that best sets up for our needs.

Comments

Rachel Wright

Hi Keith,

The fact that you're thinking hard about his now, and not years into your JIRA configuration is great news!! That puts you way ahead of most of us.

The time to create a new project is when you need a different set of project-specific settings, like Permissions, Notifications, or Components (tagging, classification, auto assignment) strategy. If project 1-40 will all operate similarly, there may not be an advantage of splitting them up.

Here's a real use case: Originally, someone created two projects per development team. They had one for maintenance items and one for improvement items. This is of course ridiculous overkill because all we really needed was a distinguisher to indicate which issue was "maintenance" vs "improvement." We could have accomplished that with a Custom Field, Component, Label, Issue Type, or other standard data point. No need for multiple projects per team. This setup lead to each team working a bit differently for no real gain. (Think silly differences, like using the Issue Type wording "Bug" vs" Defect" or the Status name "Closed" vs "Done" - not real process and procedure differences.) Fast forward 4 years and we're moving all software development teams and their 50+ individual proejcts to one shared project, to facilitate a standard process and standard terminology.

If you do decide to do multiple projects for items 1-40, you should know that projects can share the same Workflows, Issue Types, and other configuration elements. In fact, as an administrator, you want projects to share settings, because having every project opperate differently is a maintenance nightmare.

For your items 40+: You want to split up projects based on their function (not based on who is using them.) For example: support vs development vs a simple "to do" list type.

Next, you can take advantage of the "Issue Links" feature, to link a development issue to a PMO issue, for example. Linking works within a project and also between projects.

There are a few ways to deal with PMO-type issues. Some put them in their own project, some create them as issues within the project where they are worked, others use a paid add-on called Portfolio for JIRA (https://www.atlassian.com/software/jira/portfolio), which creates an additional hirearchy level called "Initiatives."

Don't worry too much about visibility. The JQL (JIRA Query Language) is very powerful. It's easy to see and search for issues regardless of whether they are in one project or many projects. You do need to care about reporting however. This is a different topic than what you asked about, but before you create your project(s) and definately before you create any custom fields, you should make a list of what data you want to report on and what questions the data needs to answer.

You can use Versions feature to categorize issues in a specific release. Version are project-specific too, although you can certainly add a Version of the same name to multiple projects.

In the end, err towards simplicity both for your users and for your JIRA admin team. Once you've entered the land of over-customization, it's hard to dig out of it.

Hope some of this helps. Happy to answer followup questions, as I'm sure others in the Commuity are too.

Good luck!
Rachel Wright

Jason Michaud_bbxqv9

Thanks for all that feedback Rachel as you have great insight. Our organization is in a similar boat as Keith. We are about to begin with the implementation of Jira in our environment. We are replacing our Service Desk solution (BMC service Desk) as well as our Project Management solution (Workfront AtTask) into this one tool. On the project management side - within Jira - I haven't really gotten a handle on how it manages individual tasks within a project. The projects our department handle have a clear start and end. They aren't necessarily projects that live on forever. So i'm trying to figure out how Jira can help with our basic project management needs of managing tasks with start and end dates. I'm assuming that tasks are now called issues within the project. Our project management philosphy within our department is very simple. We have one portfolio view of all projects with start and end dates. Then within each project we manage the tasks and who they are assigned to with start and end dates. That's it - really simple. So i'm trying to figure out the best approach to have Jira handle this for us as it is a much larger solution than what we will use it for.

Thank you for any insight you might have

Best

Jason

Rachel Wright

Hi Jason,

It takes a little while to get used to the terminology. Yes, you're right, a task is an "issue."

An “issue” is an individual item in JIRA.
Issues are used to request new projects, features, report bugs and log tasks.
A “project” is a collection or a container of issues. But a project in JIRA is not necessarily equivalent to a project you might work on at your company.

Let's say the company wants me to build a car and also build an RV. Those are two pretty big projects, but they can live within the same "container" (project) in JIRA. Since the car and RV will both have the same type of design and building process, and be built by the same types of teams, it's OK (desireable) to have them both, and lots of other "things to build" in the same JIRA project.

Let's give this immaginary JIRA project a long name of "Things to Build" and a unique key of "BUILD."

First, I'll create an Epic for the car and another Epic for the RV. Then, I'd create Stories and Tasks underneath the Epics for the steps that need to occur to get the vehicles built. I can further break up the Stories and Tasks with child issues (Sub-tasks.) When flaws are detected, I'll create Bug issues to get them fixed. I'll give all these issues (Epics, Stories, Tasks, Bugs, Sub-Tasks) due dates, so I know when target completion is. I'll also assign all these issues to a release, using the "Version" field. (Hopefully this helps answer your time boxing question.) When all the (child) Sub-Tasks are closed, I can close any of the (parent) Stories and Tasks. When all the Stories, Tasks, and Bugs are closed, I can close the (grandparent) Epics. And then I can take a cool trip in my new vehicles.

Here's how these issues might look if descripted in plain old text. I added the name of the issue type you might use in parenthesis.

BUILD-1: Build a Car (Epic)
- BUILD-3: Research How to Build a Car (Task)
- BUILD-4: Develop Requirements (Task)
- BUILD-5: As a driver, I want the car to go fast (Story)
  - BUILD-6: Make the Car go 60 MPH (Sub-task)
  - BUILD-7: Install a Speedometer (Sub-task)
- BUILD-8: The Speedometer Displays Only One Speed (Bug)
- ...
BUILD-2: Build an RV (Epic)
- BUILD-9: You get the idea!...
- ...

Each issue in a JIRA project has a unique ID. The IDs are sequential, based on the order issues are created.

You have three possible levels of hirearchy out of the box.

Now, let's say the Legal team has to respond to law suits related to my poor buiding of these vehicles. (Where are these examples ideas coming from??? It's late on a Friday...LOL.)

Since the Components, Permissions, Notifications, and types of users would differ in the project to support law suits, that would be a good use case for a second JIRA project. Let's call that project "Legal" with the key "LEGAL."

LEGAL-1 is filed due to more flaws in the speedometer. I could indicate LEGAL-1 was caused by BUILD-7 by linking the two issues in JIRA.

Further, the LEGAL project could be used to support any legal issue at the company. No need for one JIRA project for everything the LEGAL team might handle.

Hope this helps one or more of you!

Rachel Wright

A Raadls

Great post Rachel, one of the best I've seen talking about best understanding Projects in Jira as containers of distinct work instances in an organization. I am in the process of setting up as well - small web company managing multitude or websites and with a terrible previous implementation of Jira which was run by many teams that have come and gone in the last 6 years while the company has pretty much not developed anything new and spent 90% of time servicing technical debt. We are actually going to switch the entirety over all of the company tasks to Jira, including finance (I plan to import invoices out of Quickbooks into related Projects where our one sales lead will attach CRM to a large project called "site content," since he sells sponsorships to advertisers who we in turn handle getting on our sites by making sure engineering gets them implemented into the webpage, so I am going to pass on doing a "sales" project and just have the function of sales represented by the other tools like custom fields, etc. at my disposal. We are going to add a "Legal" project for the few issues we have there, very cool to see you mention that!

perspmk

Hi All,

I have few question about this topic. We use to separate Functional and customer based issues in a separate project (Jira) from development frameworks projects. We made this choice because we have multiple software technologies used for each solution, essentially backend (Java), frontend(.NET) and legacy (Cobol...sorry but this is reality).

Each technology has it's own versioning and release timing, so we decided to have a Jira Project for each technology code (we also have bitbucket, bamboo...) and a functional/ business project for each customer or branch.

As you can understand it's hard to mantain all the issue aligned. Our project are both Agile (Kanban and Scrum) and PMI pure (we are evaluating Clarizen and Big Picture).

Everytime we hacve to face with the problem of multiple Jira Project maintenance (Version, Components, labels...).

Do you have a suggestion or a way that give us a best practice approach?

Thank you

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

project

jira-cloud

administration

configuration