Multiple projects versus single project for a set of related applications

[dchisholm]

Hi,

I'm looking for some feedback and suggestions on managing multiple, inter-related projects versus a single, all-in-one project.

My company has a core platform on which it builds separate modules which can then be combined into applications. All three have their own lifecycles and versioning, and the application is the final product. If a bug is found in the application, it can be linked to a module, and the module may in turn link it to a platform bug.

Currently we track each with its own project, and we often have 3 levels of issue dependencies from application to module to platform. Each time a bug is determined to come from or depend upon a lower level bug, a new issue has to be created (or cloned) in the lower level project.

The development teams are finding this hard to manage and report on. So now they are considering merging everything into a single project. So project level attributes like components and versions have to be shared across everything, and they will have to create name spaces to qualify all of these attributes.

I'm sure this is not an uncommon situation. Does anyone have suggestions or feedback on either approach?

[Alicja Snarska]

Hey, it is possible to set up notifications in SLA PowerBox plugin. You can set up and send notifications x hours before the deadline.

[EddieW]

Focusing in on your comment that they are versioned independently makes me feel you were on the right track.

But there may be means to make it easier to "manage and report on". For instance GreenHopper allows srum and kanban boards to span multiple projects. Also, if you assign the related projects to the same category, you can use that in JQL queries (searching) rather then the project names

project in (a, b, c) ---- > category = "awesome platform"

If you care to share some of the specific pains I may have some additional insight (our team manages 40+ applications, many of which make up larger service offering)