Dude, Where’s My Project?
A Hands-on Guide to Choosing Project Management Software
There are thousands of project management tools out there and one thousand and one ways to choose between them. Unfortunately, a lot of advice on the topic ranges from generic (“define your goals”) to clichéd (“consider a cloud solution”) to vapid (“obtain a feature list from the vendor”). I wanted to share a different perspective, the one formed by practical experience of setting up project management infrastructure at Contentful, a small Berlin-based startup.
In the first months at Contentful, I saw project management tools come and go without as much as a squeak. Typically, there was always some key feature missing from the existing tool that the next one promised to fulfill and, inevitably, the next tool would suffer from just as many limitations. Wunderlist, Evernote, Trello, Leankit were just some of the apps we used to coordinate projects. Eventually, we settled on using Podio as a project management tool for business and marketing teams, Zendesk — for customer support, and Pivotal Tracker — for all the engineering work.
Having multiple tools helped individual teams get their own work done, but coordinating work that cuts across boundaries was hard: the tools required separate logins, they had a complex structure and fidgety navigation, and tribal labels concealed the content even from the brightest outsiders. In this initial phase, the only chance to find out what’s cooking in other departments’ pots was actually to attend meetings and talk to people. Unfortunately, that works only as long as people are in the same room and their overall number is small. And we were growing fast.
Quite apart from the problem of siloed knowledge, the tools in themselves caused a fair amount of frustration. Take Pivotal Tracker, an online reviewer once described as s a tool for people “who build skyscrapers by describing the size of the bricks on the 17th floor before building floors 1–16.” There is some truth in this summary, since tickets describing minor bugs and major epics all look identical, save the tiny icon, and the concept of filters is entirely alien to this tool. Pivotal Tracker also takes agile concepts very seriously, which makes it hard to tweak sprint lengths or change velocities to accommodate for occasional variations in a team’s work rhythm.
On some level, everybody realized that this setup sapped our productivity, but it wasn’t until we started signing up lots of paying customers that we recognized the fact officially. With customers trusting us to run a vital piece of their infrastructure, we sought to respond quickly to critical bugs, inform the community about new features, and share our roadmap with important stakeholders. Plus, as a team, we wanted to speed up our development cycle, avoid operational bottlenecks, and continue to stay nimble, even as our ranks were swelled by new recruits. We had to find a better way of managing our projects and that meant moving beyond the provisional set of tools we were using.
Eight Million Wrong Answers
With more than eight million hits for “project management software” on Google, finding the right tool should be a simple pimple. Yet hoping to stumble on the right solution without articulating your startup needs is as likely as sourcing new recruits to the Church of Scientology at a Bangkok nightclub. I am not saying it is impossible, I am just saying it will take a whole lot of Mojitos to do it and the result might not last.
Mindful of this pitfall, we began our search for a perfect tool by documenting our development process. Luckily, the core elements, such as weekly iterations, engineering backlogs, and feature releases were already there, thus, allowing us to focus our attention on the lower level details. Bi-weekly sprint retrospectives that we hold at Contentful were especially useful in articulating our operational assumptions and, later, rallying the team around the vision of the development process we developed.
Once everybody agreed on how we wanted to work, coming up with criteria for selecting a new PM tool was very straightforward. We thought that the software should be intelligent enough to support agile methodologies and flexible enough to accommodate eclectic teams under one roof.
The first criterion recognized an obvious fact — if you develop software for a living, your process will always incorporate some obvious assumptions. There will have to be different types of entities (e.g. bugs, tasks, features, and epics), preferably linked in a meaningful hierarchy. Entities will pass through certain phases and will have a set of attributes attached to them. Work will be organized in time slots and there will be alternative views designed to help you see the bigger picture. And so on.
The need to accommodate eclectic teams, on the other hand, is linked to increasing specialization that one finds in any startup as it grows. Once marketing, support, and operations folks get into the flow, it becomes painfully obvious that, in addition to a set of common practices embraced by the entire company, they also need a unique methodology for dealing with ‘local’ tasks. For example, setting your task status to “shipped” might make a lot of sense when developing a new feature, but it is useless in describing an ongoing marketing campaign.
When it came to screening potential solutions, we cast our net wide: in the space of two weeks, we signed up for and tested Aha, Blossom, Asana, Kanbantool, Twoodoo, Proofhub, SensorSix, 10,000 ft, Smartsheet, Gather Space, Mango Apps, and ProdPad. Some of these tools had great UX, others touted proper implementation of agile concepts, while the remaining few bet all their money on easy onboarding flow. Of course, there were some obvious failures too: a certain founder called us “c***s” after we asked to be removed from their mailing list due to the insane number of emails we were receiving.
The biggest drawback of all these tools, however, stemmed from their failure to accommodate a very straightforward scenario where a user can 1) start with a built-in agile methodology; 2) tweak it to fit her own unique process; and c) allow individual teams to follow different methodologies without provoking a riot. Solving this problem requires the team behind the tool to be dogged enough to build powerful customization capabilities and brilliant enough to prevent users from shooting themselves in a foot while using them. Unfortunately, Google Search is not good at revealing these qualities.
Mirror Mirror on the Wall
The rich and powerful of the Disney world usually turn to the Magic Mirror to find out “who is the fairest of them all.” As a puny startup, we had to make do with more primitive ways and instead asked friends, colleagues, and mentors for recommendations. The two names we heard again and again were Jira and Targetprocess. Indeed, both tools showed a lot of promise, which convinced us to set up a pilot project and go through the typical cycle of sprint tasks (e.g. backlog grooming, sprint planning, task management, and updating the roadmap) to see the tools in action. At the same time, we asked individual developers to test both alternatives and used their feedback to seal our final decision.
In short, there were three things that set Jira and Targetprocess apart from most other tools in the project management category. Firstly, they enable users to define an internal project logic: what entities are there, how they are related, what phases they go through and what happens between the phases. Secondly, users can specify what data and in what form should be attached to individual items. And finally, users can construct unique dashboards to visualize the big picture or view information they are interested in.
It’s not difficult to see how this feature set can help you model even the most complex processes. Indeed, Jira and Targetprocess can be used for pretty much anything — from developing an umpteenth Snapchat clone to running North Korea’s nuclear program. The million dollar question is not so much whether you should use these tools, but rather which one it should be. I strongly encourage you to try both of them before committing yourself, but here is what helped the Contentful team to decide in favor of Targetprocess.
The Art Of Start
What if I was to say that you can have a production-ready environment setup in half a day? Yep, Targetprocess can make that happen. Its configuration process is very intuitive and the software comes with smart defaults, solid documentation, and informative errors. Plus, there is a big library of ready-made dashboard templates to choose from and the support team is quick to answer questions on live chat.
While Jira comes with a lot of advantages, easy or quick setup is not among them. Since it makes fewer assumptions about what users want to do, the burden of defining even the most obvious behaviors lies squarely with you. And then there is the issue of documentation, which runs hundreds of pages and takes time to grok. We do have friends and colleagues who are happy with Jira, but all of them admitted either having dedicated developers or were relying on external consultants to align the software with the needs of their companies.
All project management tools excel at displaying individual pieces of a puzzle, it is when it comes to visualizing the big picture that you can distinguish the best from the rest. Say, your CEO wants to know who works on a specific enterprise commitment; team A discovers a blocker that can only be resolved by team B; or a product manager wants to find out where a certain feature has gone off the rails. To answer all the questions, users must move between multiple contexts — from epic to individual tasks, frontend to backend backlog, or present to the past.
Both — Jira and Targetprocess are aware of the problem and go to great lengths to enable users to cross-reference individual items and switch contexts with a click of a mouse. However, in the case of Jira, poor usability stands in the way of effectively using the feature: there is little distinction between parent and child entities, user interface is littered with duplicates (e.g. history, activity and date tabs display almost identical information), and navigation is cryptic to the point where even R2-D2 would have a hard time making sense of it.
By contrast, Targetprocess’ decision to organize individual entities in a strict hierarchy and follow commonsense usability guidelines means that whether you are drilling down to more granular views, reviewing history or linking tasks across teams, you always understand where you are and how to get back to where you were before. In fact, good UX does not end here: Targetprocess automates a number of routine tasks for users’ convenience, but even in such scenarios, clever use of relations and log entries makes it very easy to make sense of batch changes.
Keeping It Personal
Rolling out a company-wide tool inevitably provokes discussions on how certain things should be done. Some of the discussions serve to resolve important nuances of the development process, while others are provoked by the outsized importance users attach to specific details. Thus, don’t be surprised if soon after the rollout you find yourself adjudicating disputes on the optimal number of dashboards, necessity of providing task estimates, or the correct way of pronouncing ‘GIF’.
Again, Targetprocess seems to have spent some time thinking about these problems and offers multiple ways of resolving the disputes: users can create unlimited views, group/personalize/hide them as they see fit, switch between alternative visualization modes or tweak the common methodology to match specific team’s flow better. In many cases, personalized views nip any arguments in the bud and allow the team to get on with more pressing matters.
Jira does not limit you from doing the same per se, but its layout and tricky navigation make it very impractical to have more than a dozen dashboards per project, or to be able to personalize them to the liking of an individual user. Heck, even customizing the general views, the ones used by the entire team, is time-consuming and exhausting due to the insufficient visual feedback and maze-like app structure. As a result, a common outcome of customizing Jira are dashboards that equally annoy all the parties of a dispute.
In retrospective, the Contentful team covered a long and windy road in the last year: our headcount went from ten to almost thirty, we evolved to follow a clearly articulated development process, and replaced half a dozen of siloed tools with a single project management platform. It was not a smooth ride all the way, but eventually we arrived at the point where Targetprocess answers most important questions about our projects right off the bat.
What’s more, all the trial-and-error learnings that went into setting up the current arrangement made us confident that, as new questions come along, we will be able to answer them by following a similar set of straightforward steps. The biggest lesson of all, though, was realizing that by selecting a project management tool you are not so much buying a software as buying into a software. And it is thinking about how this new relationship will affect your internal processes that produces the most valuable insights and relevant selection criteria.
Jira is a bug tracking, issue tracking and project management software. Company subscriptions start from $20/month. More info at Atlassian.
Targetprocess is a visual project management software supporting Scrum, Kanban and other agile methodologies. Free for personal use, commercial subscriptions — $20/user/month. More info at Targetprocess.
Contentful is an API-driven cloud CMS for mobile apps, websites, and connected devices. Free for personal use, company plans start at $99/month. More info at Contentful.