Our Search for the Perfect Project Management Tool
As the Project Manager at Smashing Boxes, I would not claim to be an hardened expert with all of the answers, but I have been doing this whole project management thing for a short while now. However, during that short while I have run into a fair share of tools that promise to make me into that hardened expert, but I have yet to find one that is a perfect fit. We’ve tried Co-Human (now MindJet), Redmine, Trello, OmniPlan, Pivotal Tracker, heck even Microsoft has given a shot at the PM tool marketplace. Each PM tool has a set of features that set it apart from the other; time tracking, estimates, client delivery, to do lists, budgets, assignments, etc. The general discontent with all of these tools became clear to me at the last PM meet-up that I went to; quite a few PMs from large well established companies and agencies were there. Not one had a PM tool that they were satisfied with, in fact many were still using Skype, excel, and google docs. Is this 2005?
The more and more that I try different tools based on recommendations from other PMs and blog posts, I have come to realize that there are two key factors that seem to be do or die for PM tools in our agency:
- Does it fit our process?
- Does it fit our team?
First of all, it has to fit with our current process. Not only how we do development, but also the completely different world of design, and even further out there to customer recruitment and on boarding. These are such different worlds with different time scales (manager & maker), different requirements (budget & task tickets), and even storage needs (version tracking & psd storage). I mean we could split it all up, but then we get into the problem where everybody has to check three or more different PM tools, and that’s just not efficient.
What does our process need, you ask? Lets stick to development and design- Sales can take care of itself for now. Design needs a way to put up images, and discuss them with the client in a more efficient manner than email and dropbox. Design also needs a place to easily keep track of the many different clients they may be working on. In a two week period, our design team may touch ten or so projects, each one having different requirements and tasks to be accomplished, with differing levels of priority. So we need a collaborative storage space, clean and clear task creation and allocation, a calendar and deadlines, and a nice way to deliver to the client.
Just as we dip our toe into the design requirements, let’s take a look at development. The development team may be working on one project for 14 weeks. In those 14 weeks, once again everything is split up into two week bites. So we need differing levels of tasks, and a capability for discussion and collaboration between developers. Once one of these tasks, or large ‘bites’ is complete we need a good way to do code review, and then a way to submit it to the client for approval or review. Add on top of this version tracking, calendar and deliverable milestones, and hour to hour management, now we’re talking!
What happens when we find a tool that works for our process? It must also work for our team (rule number two). I found and loved Planscope, it had 90% of what we were looking for. But it was not a fit with the team. Some wanted to use it one way, and others another way. By the time we had come to an agreed way to use the tool, excitement had petered out, and we found other potential tools, which is where we are today.
Today we use Asana. It doesn’t have it all, but it has enough. Asana has a great and simple layout for creating and viewing tasks. Clients can view our progress, and clarify any questions that have been discussed on the issues. There are due dates and task allocation that are done in a clean and efficient way. It doesn’t have time tracking, but Harvest works well for that. It doesn’t have version tracking, but github is unbeatable for that. Outside of that, dropbox, Skype, and plenty of emails are working quite well until we find another solution.
For my parting piece of knowledge, figure out what your team needs, why they need it, and how they would plan on using it. Then when you find that tool, take the two hours to sit down with everybody, agree on a standard way of using said tool, and give it the good ole college try. But if that tool is not working, don’t hang on for fear of finding something else. We’re not marrying these tools, in fact, were serially dating them. The more PM tools we all use, the better they will get, and the more efficient we can get, making our developer’s lives easier. If developers lives are easier, then clients lives will be happier, and thus everybody in the world will be happier.