What is the best argument for me to tell my company not to make projects represent teams?

[al gulseth]

The company I work for is now implementing Jira/Jira Service Desk/ and Confluence.

We have unfortunately hired a consultant that has guided admin to have a project be a team, an epic to be a project, and a task represents an epic... thus every task must be a subtask.

I have warned everyone that will listen to me that this is completely handcuffing the sqa and developers and making a Jira almost unusable.

Things are not being used as designed, so when it comes down to the reports, there is all but a few that will not show correctly and, in effect, be unusable too. 

I've used Jira at my previous employer, but I've never heard of anything so asinine.

I believe the reasoning behind why he is guiding it this way is he claims that as a company you want to limit the number of projects to 15 or less or everything gets slow.

Is this really the case?

I would think each team could be a project category so that filter could hide unwanted viewing of projects by other teams and would most likely speed load times.

I am at my wits end trying to warn the pitfalls coming up if we go down this road.

[Peter DeWitt · Accepted solution]

@al gulseth 

The company I work for is now implementing Jira/Jira Service Desk/ and Confluence.

Hooray!

We have unfortunately hired a consultant that has guided admin to have a project be a team, an epic to be a project, and a task represents an epic... thus every task must be a subtask.

This isn't completely bad depending on what the goal is. It may be better to break up the projects into products. For example, we are a software company, and we have projects based on deliverable software products (good solution). However, setting up projects by team works really well if you are dealing with HR, IT, Legal, Etc...

I have warned everyone that will listen to me that this is completely handcuffing the sqa and developers and making a Jira almost unusable.

A big challenge here is going to be maintaining versions and a cohesive burn-down if you are working in sprints.

Things are not being used as designed, so when it comes down to the reports, there is all but a few that will not show correctly and, in effect, be unusable too. 

Correct, the reports rely heavily on the project structure and will not roll up in a pretty fashion. Be prepared to use a third part app or other software to built reports.

I've used Jira at my previous employer, but I've never heard of anything so asinine.

Just wait young grasshopper :)

I believe the reasoning behind why he is guiding it this way is he claims that as a company you want to limit the number of projects to 15 or less or everything gets slow.

Is this really the case?

Maybe, Jira doesn't care how many projects you have if they share the same back-end configuration. For example, a Jira with 100 projects all sharing the same Schemes could easily out perform a Jira with 25 projects each with their own unique scheme configuration.

I would think each team could be a project category so that filter could hide unwanted viewing of projects by other teams and would most likely speed load times.

We have many development teams and we segregate work by using a specific team field. That way there is one project and boards can display work for individual teams or any combination of teams.

GL - pjd

[al gulseth]

Is this "Team" field a custom field or is it built in?

[Peter DeWitt]

The team field is a custom field. We currently use Elements Connect to pull from a Database. We are probably going to be transitioning it to Insights once we get our CMDB up and running. However, you could just as easily create a pick-list and manually add the teams.