I'd suggest the department focus on process -- especially its goals for the process -- before worrying about which tool and/or the number of tools.
For e.g. issues like:
-- what information are you trying to capture?
-- how will the information be combined and referenced over time?
-- what information management problems have been seen before?
-- how many forms does the information need to be in for productive use?
-- what is the desired workflow?
-- ABOVE ALL, what is the potential for a lack of clarity, and how damaging would that be?
In general you want a single version of the truth. But that probably should be an "eyes open" goal. Different tools have different capabilities -- for e.g. JIRA & MS Project combine well because they don't try to do the same things (generally) and don't need to share information (typically; caveat: JIRA is evolving pretty rapidly).
You will likely also find some specific times where this type of tool consideration is not unlike that of developers' tools: IDE may be up for grabs (in some shops) but the code repository is not.
Some team members' areas of responsibility may be clearly defined enough that it doesn't matter if a day to day to-do list is in Excel, a text file, a general purposes list tool (e.g. Basecamp) or a team management tool (e.g. my company's tools). But for non-self directed work, or where there are dependencies or required collaboration, that heterogeneity isn't going to cut it.
So what people are independently responsible for is also a consideration; basically what is team information vs. what is more subject to the needs of individual productivity.
In the end, if everything else is uncertain or contested, go for the solution(s) that keep the relationships between team members and their work clear.