Have you ever been overwhelmed by a new software tool, feeling like you’re working in a foreign language, even though it makes perfect sense to colleagues? If yes, then you’ll have some insight into my first months with PTKO last year. Coming from a large enterprise where everything was Microsoft and PC-centric, I had to learn everything from scratch – I hadn’t used a Mac since a graphic design course 20 years ago! How deeply I mourned the loss of all my precious keyboard shortcuts.
Climbing the tech mountain didn’t come easy, but I finally learned to live and breathe on Slack each day, and mastered a bevy of cloud-based operational tools (e.g. JIRA, Teamwork, Confluence, 10,000 Feet, Pipeline, etc.). And just when I thought I had my feet under me, folks started telling me about new tools that were definitely better/faster/more efficient/cheaper than the ones we had. Shouldn’t we consider switching?
We all face similar questions these days – should we come to terms with the imperfections of our current tools, or leap to new ones that may or may not work as brilliantly as promised? Consolidating or switching to the latest and greatest often sounds smart on the surface. But how do you truly know when it’s time for a switch?
Here’s what we advise…
While many of our clients and colleagues wisely want to start with a full assessment of requirements and business needs, then conduct a full landscape analysis of available tools, I want to share a shortcut I like to use: simply take these two steps:
- Make a big, long list of complaints with your current tool
- For each one, go back and ask yourself – would this be better if we improved our processes and governance?
If you’re willing to put in a bit of effort in to drive consistency in how people are using them (perhaps with the help of training, documentation, or clearer governance), you can often reduce that long list of complaints to a much more reasonable list, thus making the newer, shinier tool a bit less shiny and appealing.
To shed more light on this new-tool conundrum, I’ll share two recent software decisions we’ve made at PTKO. In one case, we did decide to switch to a new solution. In the other, we’re not.
Case Study #1: the Wiki tool (which we decided to keep)
We use a Wiki software app called Confluence by Atlassian as a hub for internal documentation. It’s where we keep important stuff like policies, operational plans, meeting minutes, and brainstorming notes. Our employees can view and edit these things whenever they want.
Our Problem. While Confluence gets the job done, we’ve struggled with it in a few ways. The sheer number of documents on our Wiki often has us laboring to find the right information. And too often my colleagues find themselves asking: “Is this document PTKO’s official policy or plan, or is it just a draft or a brainstorm?” In addition, we’ve mostly only used the Wiki to capture basic text, failing to leverage some of Confluence’s more advanced functionality like tagging, macros, and templates. It’s likely that more advanced functionality could simplify or strengthen our work if everyone knew how to use it effectively.
What We Considered (and Why). We thought about migrating to a program called Teamwork Spaces – it’s part of the Teamwork project management platform that we already use heavily. It seemed to hold the promise of simplifying our lives – one less product to know and use each day! Its functionality is very similar to Confluence, and it would have had the side benefit of making it easier to share documents like meeting minutes with clients.
Where We Landed.
With any software switch it’s best to start small, ideally with a little experiment or pilot. We did that by migrating a bit of content from Confluence to Teamwork Spaces, just to see what happened. Alas, we quickly saw that the promise of increased efficiency wasn’t likely to pan out. We faced a lot of the same challenges we already had – who was responsible for updating documentation? What were the guidelines for tagging and categorization? We realized that our main complaints with our current Wiki weren’t technical at all – instead, they were related to inconsistent processes and lack of governance. So we’re sticking with Confluence for now, with renewed commitment to reorganizing content, and developing clear processes for managing it in a sustainable fashion.
Case Study #2: the Project Management Tool (which we decided to switch)
For years we’ve used an Agile project management system called JIRA. It helps us plan and prioritize project work, assign tasks to colleagues, and track project progress.
Our Problem. JIRA was working well for us, but it’s also important for us to give our clients real-time visibility into overall project status beyond just tasking, so we use a second tool for this purpose: Teamwork Projects. However, the tasking functionality in Teamwork almost completely duplicates JIRA’s functionality. We wasted a lot of time replicating information across two tools, largely because we wanted to avoid cluttering Teamwork with a more detailed level of tasking and communications that wasn’t necessary for clients to track or for documenting in a project archive. However, this didn’t seem to justify the effort of tracking work in two places.
What We Considered (and Why). We evaluated whether or not to consolidate by using a single tool – Teamwork Projects – for project management and detailed tasking.
Where We Landed.
We’re now in the process of phasing out JIRA and relying solely on Teamwork Projects. We suspected that we could solve some of the perceived challenges of using Teamwork for tasking with….you guessed it! Better governance of our Teamwork spaces. Unlike with our Wiki, it helps immensely that we didn’t need to migrate tons of existing content to a new platform, and could phase new projects into Teamwork as they began to test out this theory. Furthermore, Teamwork Projects has nearly all the functionality we need, and our team already knew how to use it. The one major challenge? Figuring out which platform(s) to use for nitty-gritty internal communication that doesn’t need to be logged for the duration of the project. We previously relied on JIRA for this, but moving we’ll use privacy settings in Teamwork, and I envision Slack picking up much of the… well, slack.
So how do I know if I should switch?!
The allure of an “easy” technical solution to an annoying business issue is always strong. And as we’ve learned, it sometimes does make sense to switch! But first it’s essential to fully understand why current tools aren’t working well enough. After doing this, you might learn that it’s possible to get most of the improvement you’re seeking through process improvements with the tools you already use. You should be especially cautious of quick decisions to switch if the level of effort is high due to content migration, learning curve, or required customization of a new tool. So next time someone complaints about one of your enterprise systems, don’t forget to ask yourself:
- What isn’t working with our current tool?
- Can I fix it with better processes?
Use this handy shortcut to quickly decide whether you should even use the brain space to consider a more detailed feature comparison!
