home | about | email | voice: 614.360.3326

Avoid the Collaboration Tool Evaluation ‘Death Spiral’

Are you using collaboration tools today to get things done through your team(s)? You probably are in some form or another (a shared folder on a server is a very simple collaboration tool). Do you wish you had that killer tool that solved all your problems? Well, the bad news is that one probably doesn’t exist. But to find the one (or two, or three) that best suit your needs, you need to spend some time developing your requirements before you hit Google and go crazy with trials. Chances are that you may have jumped into this process before without doing some up-front work, only to end up in the ‘death spiral’ into trial software evaluation hell.

This post assumes that you are in the application development space, although many of the concepts apply to other disciplines. Please also know that I won’t make any specific recommendations or in-depth comparisons of actual tools. That may come later, but the thrust of this post is to help you think about the many different considerations that should go into the selection of a tool for your needs.

Methodology
OK, so you’ve probably heard this or said this before. Make sure you understand your requirements! Trust me, you will save a lot of time and hassle if you do this up front. Here is the process I try to follow when evaluating software:

  • Develop list of functional requirements
  • Establish criteria for each functional requirement
  • Create tracking mechanism for evaluation results
  • Short-list tools for evaluation based on requirements
  • Evaluate and record results
  • Score results
  • Choose!

General considerations
Here are a few things to consider before developing your requirements and scoring criteria. These will help generate some specific requirements based on your needs.

Team Geography
Teams that are disparate in location have some different needs, and if the location disparity involves significant time zone differences, the needs are even more specific. For example, if you are agile, you may want to use a tool that not only provides robust story management, but also includes some visual representations of the ‘big board’.

Development Methodology
If you want to use your collaboration tool(s) to enable your existing methodology, you will want to consider the key portions of your workflow that you want the tool to enable. For example, a lot of tools that I found are really geared toward agile methodologies. If you’re not using agile, and need to manage things at a more granular level, you might find that agile-focused tools won’t fit the bill.

Deployment
Are you prepared to host the software yourself? Remember, this means you’re on the hook to support it, install upgrades, deal with versioning issues, and all that fun stuff. If you even think that will be a struggle, then you’re probably not ready for it.

Cost Structure
There is little consistency in pricing structures for these tools. Drivers can be based on number of users, number of projects, storage, etc. Consider developing a couple of usage scenarios before evaluating tools. i.e. a scenario might assume 5 users, 10 active projects, 5 inactive projects, etc. Bump the numbers up based on a 6-12 month growth assumption to see how the cost scales.

Tasks
Task functionality could be as simple as being able to assign tasks to people and see the status of those tasks. It could be as complex as being integrated with project planning functions like milestone management, dependency management, GANTT views, etc. Does the tool send email notifications when tasks are assigned, when they are overdue? Are there customizable views for each user?

Document Management
This is probably the most common function of a collaboration tool. Think about whether or not you’ll need robust version control within the tool. Will you need to grant different users to the same project different permissions on different documents? Will you need to keep documents outside a ‘project’ (for example, process documents that are relevant across all projects). Is an automated workflow/approval process necessary to ensure the integrity of the documents being managed?

Issues/Defects
In my opinion, issues and defects are the two most critical aspects of a collaboration tool being used for software development. In essence, both require very similar elements. Description, priority, assignment, and status. Across those elements, you might have attachments, screenshots, etc. Consider workflow, as well. Is it important that defects pass through a specific workflow process to ensure that all are addressed appropriately? Some tools provide static, fixed workflows, while others allow you to create your own. Again, think about reporting, notification, and view customization as important considerations.

Source Code/Build Integration
Depending on your build/deployment process, you may desire some integration between your source code management system (Subversion, GIT, etc). There are a lot of considerations and variables here, so I won’t go into detail…that would be an entire post by itself.

Nuggets to Start With
As much as I’d love to just give you a ‘top 5′ list of the best tools out there, I don’t think that be fair. However, here are a few resources that should help get you started…enjoy!

Wikipedia list of collaboration software

Wikipedia comparison of project management software

Overview of available project management software

Posted in Project Management | Tagged , | 1 Comments