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 structure allowing one customer to have several products/projects.

Ronnie Poulsen

Hi,

I have been looking at a lot of similar questions around the internet, but none have been able to give me a good answer yet. Therefore I turn to you guys.

I work in a consultancy, where we have many different customers. Some of these customers have more than one product / project with us. Our current structure in Jira is having one Jira project per product / project. We're running on Jira Software 6.3.

Now since we have some customers, having more than one product / project / solution / website etc. with us, my team manager have asked me to find a way to create a better project structure in Jira.

He's specifically asking whether it's possible to keep several projects under one customer - i.e. Customer A has three projects and Customer B has two projects and so on. Is this possible in some way, rather than just have 200 projects, where several of them are with the same customer?

One solution could be by using Components. Create the customer as a project, and then have each customers products / projects as a Component. However this would be really bad in my opinion, since we still need to keep each product / project isolated from each other to some degree. Each product / project doesn't always have the same departments and developers allocated.

Another solution could be by using project categories. Create the customer as a Category, and then assign all products / projects by that customer under this category. This however seems like a bad solution too, since right now we have different departments under its own categories.

What is your thoughts on this? Is this possible, or should we keep working with isolated projects in Jira?

Accepted answers

Jack Brickey

@Ronnie Poulsen, let me start w/ a question. Are the products you support shared across customers? That is, does product A apply to Customer A and Customer B?

If the products are shared then my recommendation (FWIW) would be to stick w/ products as projects and leverage a Customer field to distinguish between customers.

If the products are all unique to a customer then it might be best to have the project be associated w/ an individual Customer and use Components for the products.

Also, a very important factor is whether any of your customers are users in your Jira instance. If this is the case, certainly you do not want multiple customers in a single project.

All comments

Meg Holbrook

Hi Ronnie,

I think that Issue Types would be really beneficial for you in this circumstance. This will allow you to keep one overarching project for each product, but allow the flexibility of distinguishing each 'sub project' with its own type.

Have you explored issue types yet?

Benjamin Dains

@Meg Holbrook, is this how Atlassian recommends creating a project structure for a situation like this?

We more or less went down this route, but we have a fixVersion created for each sub-project. I'm always looking for better ways of working, so I'd love to know more about teams that work this way too.

Thanks,

Ben

Jack Brickey

@Ronnie Poulsen, let me start w/ a question. Are the products you support shared across customers? That is, does product A apply to Customer A and Customer B?

If the products are shared then my recommendation (FWIW) would be to stick w/ products as projects and leverage a Customer field to distinguish between customers.

If the products are all unique to a customer then it might be best to have the project be associated w/ an individual Customer and use Components for the products.

Also, a very important factor is whether any of your customers are users in your Jira instance. If this is the case, certainly you do not want multiple customers in a single project.

Ronnie Poulsen

Hi @Jack Brickey,

No the products we support are not shared across customers. The product (being a project of some kind - website, system, solution etc.), is individual to each customer. But some of our customers have several contracts with us on different products. E.g. Customer A has Solution 1 through 3. This is where it would be nice, to have an upper level of project structure. But I guess this is where I could use project categories for the customer, and then have the projects underneath it.

But in terms of reporting we need to be able to isolate both customers and products. I dont know whether Components can be distinguished, when making reports from a project?

Ronnie Poulsen

Hi @Meg Holbrook,

Yes I have explored Issue Types. I really dont think that this is the way to go. On our projects we have different Issue Types. E.g. one project may have both issues of Bug, New Feature, Change Request and Support Question. From what I understand, this is what Issue Types is meant to be used for.

Jack Brickey

Given this I think I would have a project per customer and Components for products. This will allow you to easily keep reporting straight. You still could keep a single project if you wanted but it isn’t as clean and flexible.

SIngle project:

Project = Consulting
Components = Web Design, System, Solution, etc
Customer = A, B, C, etc

Multiple project:

Projects = A, B, C... customers
Components = Web Design, System, Solution, etc

Ronnie Poulsen

I see what you mean @Jack Brickey. Components might be the best solution for this situation. But still. I think that if I have a project per customer, and the customer has maybe three different products (projects), which actually has no relations to each other and therefore need to be isolated, it would create a lot of unnecessary noise in the issues overview screen.

Another thing is that, it is not possible to have Component based permissions in Jira. So I cannot restrict one product (Component) to a group of users.

Nevertheless I have accepted your answer as the solution since nothing else really solves this situation.

Benjamin Dains

@Ronnie Poulsen yeah, and I think it would create a lot of administrative overhead.

Welcome!

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

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

jira-software