What do you prefer, many small projects vs. fewer big projects?

Question

Hi,

We are in the process of expanding JIRA  to JIRA Studio to our new organization (we have merged with other 3 companies). We need your advice to find the best way to configure our new projects structure.

We have two options over the table and would like to have all pros and cons for its better eavaluation:

OPTION A
 We have been told by Management the they mainly will need reporting on some main areas of the organization (products, incidences, suppliers, internal tools,...), but as we all know, they ask for all kind of reporting. At the first instance we have created a draft of architecture that consists of projects with these areas of the organization, and then components for products types, incidences types, and versions for new functionalies and change requests.

* PROS: Only 7-9 projects. Project permissions easy to maintain. Users can select easily the project for their new issues.

* CONS: Each of this projects will have tons of versions and componets. Can't assing permissions to external collaborators to specific projects (because are set as componets).

OPTION B
 Well, on slide 39 in this presentation (http://www.slideshare.net/GoAtlassian/administrivia-golden-tips-for-making-jira-hum-1565231) it is said that its better to have many small projects better than fewer big projects, then have the projects under categories. I haven't found further criteria for this option that can help me to argument for this type of configuration.

* PROS: Better security as permissions can be granted per project.
* CONS: Long list of projects available to the user when selecting for the new issues

We are new on creating this big instance of JIRA Studio and also, consider that we will be implementing Agile methodology with Greenhopper.

So..., if you have a big instance, and you could start from 0, how would you do it?

Thanks,

C

Charlie Ibarzo · Answer

Thanks Dimitar!

We will take your tips into consideration for sure.

Cheers

C

Dimitar Dimitro11 · Answer

There are some hard limitations for projects:

* A project is a namespace for versions and components - in particular if you find that a version applies to only one component or subset of components, that indicates that this component most likely should have been a project on its own.
* A project has one set of permissions and issue/screen/permission/notification schemes - if you need finer granularity, you achieve some things with transition preconditions, but you might find that soon you need a new project.
* GreenHopper does not work well with mega-projects, where some components correspond to teams, some to subsystems, some versions represent binary releases, other - project milestones (which more often form a graph, rather than a tree).

Ahd here are some tips:

* Putting too many people in the same project is convenient, but makes the user's drop-down lists unmanageable. The autocompletion, introduced in more recent versions somehow alleviates that, but it is still a pain in GreenHopper.
* If you work in a mid-sized, environment (less than 50 people), you might consider abolishing permissions altogether and giving everybody full access to all projects - this will save you 90% of the administration calls (but might make the remaining 10% much more severe - make sure you have backups in a different machine)
* To alleviate the problem with users having to browse through multiple projects to submit an issue, you can use a Wiki page (or even static HTML), describing various problems and providing a direct link to the issue creation form - the project and issue type ID's are part of the GET URL. This way you can provide a diffeent, more focused feedback page to each  group of users. 
* You might want to create an issue type 'Feedback' with reduced number of fields (e,g, only summary and description). The benefit is that it is really easy to code a POST form for it in a wiki and the users will not be intimidated by the percieved complexity of JIRA.

Nic Brough -Adaptavist- · Answer

Charlie - consider having separate projects where your business users raise their stuff and don't let them raise directly in the development projects.  That limits their need to know.  You can then let the developers move stuff out of "triage" projects into their own development areas as appropriate, or they can create their own copies and link them to the business user issues.