Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
What is the maximum number of project management tools a department could use? If more than one is used for the same purpose or several are used for linked purposes double data entry occurs or synchronisation between them is needed.
Tools I consider in this category
One.
Is this a trick question?
There is no set maximum or minimum number of tools you should use. What it comes down to is what works best for your organization.
If you can find a single tool that can do everything, that is ideal because there is less duplication. But in most cases your needs are more specific, and one package won't do everything you need.
The next best scenario is to find tools that integrate easily. For instance, some bug tracking software has hooks to connect to version control comments. Since committing files and making updates to the bug tracking software are usually done together, as well as sending updates to team members, it makes sense to integrate these.
But other things don't need to be so tightly coupled. For instance, the tools you use to maintain the Risk Registry probably don't need to integrate with your Subversion repository.
Depends on what this "department" is doing. It's better to discuss what tools a project could use (it's a project management Q&A site after all).
Ultimately a project needs to have a project management information system, which integrates time, scope, quality, communication, risk, HR, and procurement management operations and documents. Actually, I've never seen such all-in-one systems. You always have to integrate smaller tools/instruments and you should always try to minimize data duplication. For a small project I would suggest the following components:
The minimum amount to get the job done right.
In this case, sounds like you could cut out at least one tool by finding a tool that integrates the task planning and management with bug/issue tracking.
You could go even farther by using a tool that further has time tracking built in.
If you are working for a department in a larger organization, its best to find time tracking that can integrate with the existing corporate accounting system.
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.
