Looking for recommendations on organization of JSM projects.

Question

We have been successfully been using JSM for several years to manage our Library & Technology Services Help Desk requests at Lehigh University. We also use JWM, JS, and Trello for project management across our organization.

We have recently migrated to the cloud and procured additional licenses to make the Atlassian suite more of an enterprise solution. Now everybody seems to want their own forms (that people without licenses can submit requests). This means that they need a JSM project since that is the only tool in the suite that supports letting customers submit requests. We are struggling a bit with how best to organize the projects and portals. We do not want to have a ton of JSM projects that only have a single request form but that is how our requests are coming in. Just curious how other higher education institutions have organized their JSM projects (By College? STEM? Customer group?)

Also interested in talking to any groups that are moving tickets from JSM into JS or JWM through automation so that the actual work can be managed in those tools with some of the better PM features.

Application Services · Accepted Answer

I work for a distribution company with several hundred JIRA projects, of which a dozen need Customer request forms.  Each project form page has a link to the generic default Customer Assistance form page and links to custom form pages that require specific inputs like yes/no logic or drop down selections.  Having these generic and custom forms are priceless for saving time and gathering accurate requirements in a timely fashion.

Todd Thomas · Accepted Answer

Project sprawl is a real issue. We've actively tried to push against having too many projects since:

* Spinning up and then configuring a project takes time and attention, not to mention coordination with a variety of people
* Each project needs a project admin (ideally, multiple). While JSM isn't as complex as other systems, there's enough nuances, quirks, and limitations that making an average worker a project admin is a pretty tall order.
* It's confusing for end users to wade through many different customer portals to find info.

To counteract JSM sprawl, we:

* Utilize Issue Security combined with automation to determine who can see specific issues if data confidentiality is important.
* Purchased the Watch It app to allow people to trigger on their own set of criteria for notifications since watching a large project isn't feasible. We recommend a combination of using Components for teams within a department/area/service and then creating a Watch It Watcher or Rule to get notifications when an issue is created/updated.
* Rely on teams to watch/monitor their own issues vs. creating them for everyone. This is possible through the Watch It app.
* Link multiple Confluence spaces to bring in as much self-help info as possible, so even different teams and space info can be provided for Tier 0 support.
* Used Confluence to document the various steps we take or need to consider when adding a new project. A checklist with ideas is very helpful!

Since doing all of these things we've been pretty successful at limiting our number of projects, though if they increased more we'd probably consider some additional Marketplace apps to help with the administration of spinning up new projects.