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

[Charlie Ibarzo]

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

[Nic Brough -Adaptavist-]

Actually, it's quite simple - you want to be Agile, so do many small projects. You'll rapidly find large projects become unmanageable and complex.

To simplify things though, use the same schemes to control the projects, and use roles in permissions. I try to use the same permission scheme over and over, and if you're careful with them, you can delegate all your worries about user maintenance to your project owners. I usually start from something like: "all users can read issues, only people in the role of user can create issues, and only developers can be assigned/work on/resolve". That lets you limit users when it comes to your "create" list.

If I had the chance to start from 0, I'd be very strict on the users "can my project have X" - establish a SHORT list of custom fields, issue types and workflows, and tell people to stick to the standard templates. Classic example at my current client - almost 30 different "date" custom fields, all of which could be covered with "start date" and "end date". Apparantly, it was critical that they're called different things because PMs needed them that way. (No, they didn't, we could have called them "Fred and Chuck dates" and they'd have worked fine)

[Charlie Ibarzo]

If we have many small projects, it's going to be hard for users from the business areas to allocate correctly issues they find on the platform in general.

Is it possible to add the project categories at the new request wizard??

[Radu Dumitriu]

Just a thought here: the term "project" is a notion external to JIRA.

[Nic Brough -Adaptavist-]

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.

[Dimitar Dimitrov]

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.

[Charlie Ibarzo]

Thanks Dimitar!

We will take your tips into consideration for sure.

Cheers

C