You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
One of the most common questions that we get from our larger clients is whether they should combine all of their Help Desk teams into a single project or have multiple projects. If you just want the TL;DR - the answer is almost always implement a project for each team.
Before I lay out the reasons that having multiple projects is preferable, lets look at why some clients want to have a single service desk. The most common concern is that multiple projects leads to fragmentation and administration overhead as each project becomes specialized, doing their own thing. The thinking is that by forcing everyone into a single project, it will be much easier to enforce a single organization-wide approach to service desk management.
This concern is quite valid. We have been called into plenty of clients where they have allowed each project to "do their own thing" and the results are not pretty. There has been a fair amount of cost, both financial and cultural, in pulling everyone back into a coherent implementation model.
The answer to this concern, though, is not to have a single project but to have a single set of schemes that are only modified through a centralized review process. When a team finds that they need to operate differently from the rest of the organization, let them make their case and allow the Change Approval Board to determine whether the cost is worth the change. What may happen is that other teams recognize that the change is not a specialization but an overall improvement that everyone should adopt. The right answer to fragmentation is not to lean Jira but to implement a business process that introduces a thoughtful approach to Jira administration.
I promised my arguments in favor of multiple projects.
Lets start by laying out some standard assumptions about how these different teams typically work:
Arguments in favor of multiple projects:
There you have it - a lengthy list of reasons that I argue for multiple projects.
Are there arguments that I have missed? Do you think that there are compelling reasons to pull all service desk teams into a single project?
C_ Derek Fields