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.
