One Project Management Tool to Rule them All



Is there a single software solution for project management that does everything a project manager needs? Is there one ring to rule them all? One does not simply come across a single piece of software that just does *everything* in terms of communication, task management, timelines, Gannt charts, writing silly notes to yourself and others, bug reporting, and generally running projects.

Is there a single software solution for project management that does everything a project manager needs? Is there one ring to rule them all? One does not simply come across a single piece of software that just does everything in terms of communication, task management, timelines, Gannt charts, writing silly notes to yourself and others, bug reporting, and generally running projects.

Does such a solution exist? Or do we have to make one?

This account is written by someone new to project management, who has been learning on the job from the outset. It’s been pretty complicated coming into a world that seems fractured along the lines of the traditional way of doing things, and the new, popular agile methodologies. As someone standing at the crossroads with no formal background in this job role, this has proved a little daunting, but also very interesting with many new things to learn.

The situation a new startup finds itself it in.

As a startup with modest origins but an ambitious vision, the need to manage new business, projects and communications effectively was respected from the outset.

We started out using Stickies in OSX; this worked well enough for a while, but eventually chaos broke out. The stickies were local to one machine, each sticky was unrelated to the others, and the list of problems went on and on. A new system was needed, so we engaged in a search for a dedicated project management tool. We engaged in only a brief daliance with our first choice, Pivotal Tracker: this was a powerful and complex tool, but one that ultimately proved fruitless; we needed something less development-oriented, for the sake of our managers.

Many many awesome tools (with cool names and logos).

The next tool we tried was Trello, and things were very good for a long time. Trello allowed blissful real-time communication with everyone in the team, with displays across machines updating immediately. It uses a Kanban board system of cards in columns which progress from the lefthand side of the screen to the right as progress occurs. We used Trello for all of our projects, including design processes, development, communications with clients and software testing. In addition, we had Trello boards for project overviews.

Trello has a very generous pricing model, and is very friendly to use. It is hard to find fault with Trello considering its simplicity, its ease of use, and how well it can be applied to different facets of project management and development work. However, despite this, Trello is not the perfect tool for everything and problems did begin to emerge.

The key issue manifested itself when we began to use Trello to manage a much larger software development projects, which had several subsequent versions. This required the use of duplicate Trello boards for what was essentially a single project. As anyone who deals with data knows, duplication is a wicked, wicked thing. We did cunning things with the links between Trello boards, but the strain began to show. The main issue here was with bug reporting. Trello is not a bug tracker. Trying to impose feedback rounds and specific states for issues is risky in Trello as the boards allow people to break the layout fairly easily. We realised that we needed a dedicated bug tracker, among other things.

The same issues also started to appear in the use of Gannt charts. Very large projects often required multiple versions of a chart. Henri Gannt would not have approved, and we were well aware of the need for changes to the pipeline we used to run projects.

A colleague commented jokingly a few days ago that we have a lot of different pieces of software all working under the guise of communication and general project tools. I was forced to agree but pointed out that there seems to be no single tool that does everything. If there is, the makers of it usually impose terrifying pricing models, or have broken the tool into two or more different products that also have terrifying pricing models and charge more still to integrate with each other. The issues of lots of separate systems is at least a set of known evils.

Many many requirements

Trying to identify the many requirements of the ideal project management software solution yields the following list (and some known popular products):


Email sucks. Trying to use email to resolve design issues, converse and have a meaningful dialogue with lots of people is not a nice experience. It works, after a fashion, but it is a joyless process. Something along the lines of Basecamp would be nicer.


As stated, a nice Gannt tool. Currently we are using Smartsheet. It’s alright, but I’m not overwhelmed by it but Smartsheet works fine. We reviewed Liquid Planner and were blinded by the light of its power and fled back to the darkness. The image below in on a par with the complexity of Liqued Planner. That thing will make you a black hole if you are not careful.

Task Allocation:

Trello is not bad at this, but you quickly begin to allocate multiple columns for the various types of tasks that appear (design, development, testing, general wrangling). The chaos is always seeking a way in. As discussed above, something a little more strict would be good.

Bug Tracking and Testing:

Bug tracking means coding, and coding means repositories and version control, which represents another system. Something geared towards letting developers share code, and also allow issues to be logged so that fixes can be made, would be ideal. In particular, a solution which can manage feedback rounds, and how many times a bug has been addressed would be good.

With a creeping sense of dread, and a very bad meme, it became apparent that what we were looking for -- an all-seeing, all-doing piece of software, which was additionally free and open source -- existed only in myth.

The Quest

With all of the requirements above in mind, I started looking around, thinking that there had to be something which fit. This Wiki page, whilst terrifying, was comprehensive and proved very useful.

Trying to introduce a new system to an established way of working is not a simple decision, especially something as comprehensive as this one. The stakeholders in the business were supportive and the team appreciated that the current software was causing problems. However, asking everyone to demo a huge range of alternatives was unlikely to prove popular and unlikely to be supported. Whatever system was chosen needed to be selected very carefully.

Several systems were tried. Many 30-day trials were started, and lots of people from sales teams kept calling the office asking to speak with me, generally making moderately hard sells.

No one was happy though, and the group consensus was that that it would be very bad to start using a new tool, only to drop it after a few weeks due to a complete lack of interest and uptake.


Oddly, the Wiki page did not list one product which quickly caught our attention, Phabricator.

Phabricator was originally a tool developed by Facebook and was subsequently spun out under a new company named Phacility. The fact that this was both a free, open source software product that we could demo ourselves (with no time limit), and one which is already in use with several notable organisations, pushed Phabricator to the front of the queue.

The range of tools which Phabricator offers is huge, and frankly overwhelming. With that said, it offered pretty much everything we wanted, with the exception of a Gannt Tool. This was something we were prepared to be flexible over, as the remaining features were good.

First and foremost, Phabricator allows a rigid control of tasks and their allocation. Its styling will be familiar to anyone familiar with bug trackers like Bugzilla, and our developers took to it quickly. The backend is MySQL (which upset our Postgres aficionados) and you need to get grimy on the command line to set things up. The people at Phabricator definitely have a sense of humour, and this shows frequently in their documentation.

The UI for Phabricator is comprehensive, but to UX obsessives, it will seem a little older in style than some of the newer interfaces, like that offered by Trello. This should not detract from judging Phabricator. A study of the system and a read of the change logs shows that the development team behind it are very clearly focussed on the core feature support and stability first, with UI coming second. This is not to say that this is not appreciated, because it is, and over the course of several updates we have noticed numerous insightful enhancements to the front-end. Phacility's key objective, though, is to ensure that their system functions well, and is stable.

We were able to link Phabricator to our various Git repositories (we like BitBucket), setup unlimited specific projects, each of which supported its own Wiki (great for project-specific documentation) and use Phabricator to store design files. A great feature we found was that Phabricator also offer Workboards similar in style to Trello (not as powereful or as refined, but usable and very helpful):-

A full review of Phabricator is a topic for another post. The focus here was on the journey we undertook to find and settle on Phabricator as our project management tool of choice. To conclude, however, I can say that we are pleased with the choice we made. Some of the systems Phabricator offers do need further development: a good example would be the internal messaging system. As a company, we have embraced the awesome Slack, which is so good that no one cares that it is a seperate system. We still use Trello as well for a total overview of all projects and it works very nicely this way.

We still need better support for external players, such as allowing specific clients access to specific projects, such as is offered very well by Basecamp. The support for this still seems to need work. The impression we have, though, is that Phabricator will continue to enhance, and that these areas are going to get better in time.

Following our deployment of Phabricator, we learned that Wikipedia had also been engaged in the process to select a new tool which lasted over six months.

Wikipedia describe their choice of Phabricator as allowing them to have

"an opportunity to centralize our various project and product management tools into a single platform, making it easier to follow technical discussions you’re interested in."

The full story on this can be viewed here and is well worth looking at.