Let’s face it, the collaboration space has no shortage of options. Today’s solutions come in different flavors of SaaS — on-premises or hybrid — all promising that a few mouse clicks will lead to better collaboration. The one attribute most of them have in common is they suck. In fact, many of these solutions actually make collaboration worse. To help navigate the abundance of options, let’s lift the hood and explore many of the common problems with today’s collaboration solutions.
You Get Pieces and Parts
Let’s face it, as a business grows so does its needs. This transition happens slowly and sooner than later, a firm is bombarded with lots of little solutions, each itching a single scratch in helping the company collaborate better. Worse yet, navigating between those tools is often painful. In the best case, the integration features add even more buttons to an already complicated user interface. In the worst case, a firm will have to manage a bunch of bookmarks to get to specific features.
On the subject of user interfaces, today’s solutions are all over the board. Geek-centric solutions might make a firm’s IT teams happy, but they could also alienate project managers, product managers, and upper management. Some solutions create busy-work for team members so that management can have pretty reports. Other solutions are too enterprise-y, trying to be everything to everyone, making everything more complicated instead of more efficient. Their lack of focus makes the user experience painful – with too many links, buttons, and tables, all competing for an individual’s attention.
Finally, the lack of a comprehensive feature set makes portfolio management difficult, if not impossible. Some solutions focus on work (tickets, issues, tasks), some focus on the process (kanbans, CI/CD integration), and others focus on people (chat). But what about the bigger picture?
• How many projects do we have in flight? What’s the relative health of those projects?
• Have we spread our valued team members too thin?
• How do I quickly find what I’m looking for? How about searching all the things (projects, users, tickets, documents)?
Centralized searching isn’t something a company can do without — yep, you guessed it — buying another tool.
Next, let’s discuss the insanity of help desk solutions. It’s common for projects to deliver solutions to customers who need access to a support team. Isn’t a ticket just a ticket? Why do vendors try to upsell a separate help desk solution? Under this model, if a customer raises an issue that requires remediation by a team, the company ends up with two tickets: One ticket in the help desk solution and another ticket in the collaboration solution. In most cases, there is no inherent association between the two.
Now, let’s think about turnover. When someone leaves an organization, how easy is it to revoke their access? Even if administrators have identified the replacement for a departing team member, reflecting that change in multiple projects can be cumbersome. And, once again, if the company’s been upsold, both of those processes become harder.
The final point worth considering is discoverability. This may sound ridiculous, but many solutions don’t allow a company to specify who is able to discover a project in the first place. If a company is doing real portfolio management, then knowledge sharing is critical, and one should be able to specify who can discover projects. Similarly, a firm should have a way to explicitly limit discoverability to certain projects.
Too Small or Too Big, Won’t Scale
Not all projects are created equal. Say that again: Not all projects are created equal. In a world where organizations have dozens or even hundreds of projects, in various phases of development, support, and retirement, it’s important to be able to scale-up or scale-down features without the headache of buying more seats or finding a new solution.
Then there’s the SaaS/cloud versus on-premises discussion. That decision should be made by company leadership and that choice shouldn’t make deployment and management any harder. There’s no shortage of on-premises solutions, yet many require painful, complex installation and upgrade processes. Given the critical role collaboration solutions play, getting them up and running (and keeping them up-to-date) needs to easy. Many of these solutions cannot be installed at all without an internet connection for the server. This means installing a collaboration solution on a super secure network will be difficult if not impossible.
Then, once the system is up and running, how does one control access to the firm’s projects? Access control varies greatly between collaboration solutions. Large projects often have large teams with technical, management, and stakeholder members each playing a role in successful delivery. Believe it or not, some collaboration solutions don’t allow one to define its own roles, instead, imposing a set of roles often giving users access to either too many or too few features. Roles are a key in any real collaboration solution and are often reusable, specifying the level of access users have. And, even if a company can specify roles on a project, if the company’s leaders have been upsold, they may well be stuck having to manage access to each upsold feature separately.
This is where the tools start to run the team. What started out as only a ticketing solution soon includes a wiki, chat, and help desk. Suddenly, engineers are looking at a bunch of tools, held together with duct tape and web hooks, none being the authoritative source of the project’s precious data. All individually impose different ways for the firm to get its job done. When will this nonsense stop?
Who’s Working for Whom?
That question may sound absurd but, yes, we are asking that question with a straight face. Are the company’s tools working for the company or is the company having to bend to the will of the tools? To illustrate, let’s start with something as basic as ticketing. Tickets are the atomic unit of work by which things get done. All a firm’s planning, distribution, and tracking of work happens through tickets. In fact, most collaboration will be centered on the best ways to deliver the work outlined in a ticket. So, why do so many systems get the most important, fundamental needs all wrong? Let’s answer that by identifying common shortcomings of many collaboration tools:
• Duplicate Tickets — When creating a ticket, should the system let the user know he or she may be submitting a duplicate? Furthermore, shouldn’t the system give hints that maybe the problem or goal in a ticket has been addressed already on sites like StackOverflow?
• Batch Updates — Updating multiple tickets in batch should be easy to do. Yet many systems either don’t allow for this or make this far more difficult than it should be.
• Quickly Adding New Tickets — In the planning phase, it is common to create multiple tickets at once all within the same milestone or sprint. Most systems require an individual to rekey many of the same pieces of data instead of using sane defaults.
• Ticket Types — While the distinction about tickets is important (e.g., user story, epic, task, bug), adding flexibility shouldn’t slow the team down or make things more complicated.
• Imposing Workflow — Workflow can help teams stay on track and handle tasks in a consistent way. But a ticketing solution shouldn’t force a specific workflow on a team.
• Dependencies — Dependencies between tickets is common. Solutions should make establishing blocking/non-blocking or parent-child dependencies easy and obvious.
• Spam — Getting notifications that a ticket, sprint, epic, or milestone has been changed is great, but do engineers really have to get a separate email for each update? Solutions should provide the option of receiving daily digests.
• Ticket Previews — Because the work in tickets can be a part of any milestone, release, sprint, etc., one often needs to know more detail than just the ticket number and summary. Yet, surprisingly, many solutions don’t give ticket previews everywhere and every time tickets are referenced.
Comments <> Collaboration
Repeat after me: “Comments aren’t collaboration.” Don’t get me wrong, commenting on a ticket, wiki page, or document aids in collaboration, but it isn’t true collaboration. That’s why we’re seeing all sorts of chat solutions rushed to market. Chat solutions are great and often serve as the central hub of any successful project. Here again, the upsell issue bites us, but, in the case of chat, it is exacerbated. Chat conversations give concise context and often include references to key project artifacts (tasks, support tickets, documents). For those exact reasons, chat should be a foundational and well-connected component of any real collaboration solution, not an upsell. For example, with an upsold chat solution, when a firm adds a new team member, the firm also needs to manually give them access to the corresponding chat rooms or channels. And remember that problem about a centralized search? Did a teammate answer a question inside of a ticket, wiki, or in the chat channel? Shouldn’t a real collaboration solution answer that question? Why should an individual have to run the same search in different places?
A common problem with many collaboration solutions is that their base functionality has a high price tag. And despite that high initial cost, they have a limited scope, implementing only a few well-thought-out features. Make no mistake, this is on purpose — vendors often use this approach to get a company to spend more money. They accomplish this in one of two ways:
1. The Vendor Upsell — Does a company want to add a chat solution to that fancy ticketing system? They have an app for that. Oh, now leadership wants some sort of documentation/wiki solution? Yep, get out the checkbook. The problem with vendor upsells is they often create more problems. On top of having to negotiate a new contract for each product, a company is now on the hook for keeping all those shiny, new tools integrated. Now, this integration may not be an issue if a firm is all-in on cloud-only solutions, but as soon as the company brings any of those solutions in house, it is stuck with keeping them connected.
2. Marketplace Ecosystem — Some collaboration solutions get around their lack of features by offering a marketplace where third parties can offer solutions that integrate with a vendor of choice. This has all the same problems as the vendor upsell, but now a company is adding another vendor to the equation which, on top of the pricing issue, means the integrations are going to be more fragile and any breaks in compatibility puts a firm at the mercy of both vendors.
With collaboration solutions playing such a key role in getting things done, the more a company uses them, the more valuable they become. So, what happens when a firm gets to a point when it wants to make a shift in how it collaborates?
For example, there are a few reasons an organization may want to move from SaaS to on-prem or vice versa, and while it isn’t common, it shouldn’t be impossible, either. And if it isn’t impossible to do, the odds are the work in accomplishing that isn’t trivial. Moves like this should not only be possible but relatively easy to do.
And then there’s our friend “vendor lock-in.” A company should never get into a vendor relationship that it can’t easily get out of. The upsell models make switching out solutions even more costly, time consuming, and error prone. Worse yet, if a firm has independent vendor solutions, each itching a specific scratch, then it means those integrations will break requiring more time to keep them in sync.
What’s Irking You?
It isn’t all doom-and-gloom when it comes to collaboration software, but a solution that is right for a company right now may not be able to grow with that company in the future. To that end, it’s important to understand where many of today’s systems fall short. Make choices that balance where the company is today, and where it wants to go. Does your firm have a collaboration solution driving your engineers crazy? We’d love to hear the reason why your collaboration solution sucks.