What is a project? Seeking best practices in defining scope of a Jira project

I am trying to define "what is a project" in our environment, and am now contemplating just putting everything under one single project. 

We have many hundreds of open bugs in another system to migrate over, but the single most critical piece appears to be defining what a project is in Jira. This gets pretty hairy when you consider that we have multi-layer/multi-team dependencies that impact the product, and its not strictly hierarchical. Just as an example, if I were to define each company product family as a product in Jira, there would be dependencies that span across projects making management and queries complicated, and people would 'live' in the 'advanced' query land. Or I could go extreme and make it so that whenever anyone hiccups there is a new project, making things even worse (some users would be very happy having their own 'turf', but only in the first few days, and other things would be bad such as producing high level reports and keeping things aligned in general between projects). 

The question is: What were to happen if I go to the other extreme and put the entire company (small mid-size) under one single project?

In that world, all fields would be (more or less) flat, no trees - just attributes, making queries pretty precise - very manageable - producing exactly what we want to see, and no cross project stuff going on. Some of the downsides I see are carrying a lot of history, some difficulty when making large admin changes, as everyone is impacted, but ... is that it? What key features and capabilities would I be missing that would haunt me? it seems that a lot of things can be programmable to compensate, but what would be the real challenges? FWIW, another data points is that some of the teams will be leveraging Jira Agile to varying degrees. 

Thanks,
Mike

P.S. If this has already been chewed on as such in another thread - I'd also appreciate a link to that.

3 answers

1 accepted

Ian,

Thanks for the info - I actually watched the entire thing - Good job on sorting out the real-life "mess" :-) You have obvioulsy put a lot of thought into "what is a project".

I agree with the mindset with which you approached the problem, especially the notion of making the system reflect the way we think. FWIW, we actually have a somewhat similar environment, FW, and other components all coming together (sort of) to form releases.

One of the challenges is that the company/product structure itself is not always consistent, and may not be tomorrow what it is today. One release might have a subset of components and one might have other ones altogether - typically they are similar but it could happen. Additionally, one might be, as in a library, shared across products, but at the same time have customizations for each. The library is released prior to the other releases, and they base their work on that. [[ On a side note, For this reason I shy away from configuring tools in a way that reflects the product too tightly. its simply too heavy of a load to carry. Instead, I try and make everything flat. Anything is an attribute (as in field), including the project. In many cases, it simply removes any "clerical" or administrative tangibles from managing the tool. Of course, YMMV depending on the tool. Also, some exceptions may apply :-) ]]

In the solution you presented, it seems like each discipline (FW/ SW, etc) had their own project in Jira.

If I take this approach I am concerned that, since they all work towards common goal, there are many things that need to be duplicated between the different Jira projects, such as components, flow related items, and so forth (actually I am still working to figure out what 'so forth ' is in this context). Also, when users submit bugs, they don't always know where it goes at first, cuasing a need for some sort of common "front door". Additionally, maintaining the queries, such as the 'mother query' in your presentation appears to require a lot of housekeeping making sure things are inline between projects and a fairly high level of weightlifting involved to kick off a project. Furthermore, I foresee people standing in line to have their own Jira-project created, just so that they can have their own playground, yet another project to maintain and keep in line with the others. Would a single project not solve all of that?  I mean I know that it will have advantages, but what are the specific problems and limitations I will face if I do that? Where am I shooting myself in the foot?

Thanks again,

Mike

 

Just to close this loop, at the end I implemented this inline with most of the advice I have seen, which is to align JIRA projects with company products, which also have a shared release cycle.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,708 views 17 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you