Lessons in Startup Project Management Part II: The Tools
In a previous post I tried to dispel some of the myth of how entrepreneurs in “hip” startups perceive project management. It is not (well, it doesn’t have to be) a stodgy, stifling bureaucratic nightmare, and, on the other hand, just calling your operations “Lean” or “Agile” does not mean it is effective project management. Lest we forget, somewhere around 80% of IT projects in large organizations fail due to ineffective management, and I surmise that the same is a major contributing factor for why nearly the same percentage of new technology startups also fail within a few years. Today, I’ll demonstrate a few tools of the trade, elaborating on the pro and cons a little of each.
First up, my perennial favorite for smaller scale software development: Trello.
Now, Trello has been praised as a sort of “do-all” type project management application, but I have found it really excels mostly in workflow situations. For example, tracking software development teams in terms of bugs fixed or features requested/under development. The card view provides a wonderful sort of dashboard for management and the price of the application (free to start) can’t hurt either. Outside of project management, Trello is incredible at doing things ranging from tracking sales leads to working an applicant pipeline for HR to keeping tabs on a scalable to-do list. This generalist mentality of the platform comes with a few drawbacks, however. For one, advanced tools to track Agile metrics such as velocity and burndown are basically nonexistent. I’ve tested a few add-ons and such using the API, but nothing really comes close to what most professional teams really need. Overall, if you just need simple, easy to use tracking mechanism for workflows and smaller scale projects, nothing beats Trello as far as I’m concerned.
If you need a more robust solution, here comes Jira.
Jira is sort of like the enterprise Trello, though it is much more specialized, expensive, and complex to set up and maintain. The largest benefit of Jira is the metrics it can provide for Agile/Scrum managers that Trello does not (yet, anyway). Jira also includes nifty features like automatic Sprint planning calculations based on previous velocities, which can certainly save a lot of time. But this sort of specialty and advanced metrics comes at a steep cost – beyond just a handful of users, the annual price goes into the thousands, even tens of thousands, for larger companies. Pivotal Tracker is another similar solution that I have found which tends to be slightly less complicated than Jira but nearly as expensive for teams with more than a few people. Either way, in the early stages of a startup, I highly recommend Trello due to its low price point and generalist nature (which can be overcome if you are bold enough to create your own internal apps using their API). Only when an organization matures to a level where is needs more fine-grained controls for increasingly complex programs would I recommend switching to something like Jira, or if you absolutely need something behind your own firewall.
Now, the 800 pound gorilla in the room – Microsoft Project.
Universally standardized at larger companies, MS Project has long been the dominant player in traditional waterfall project management. Its features are beyond robust, and account for metrics that few of us would typically care about in small projects. Integrating with SharePoint, MS Project and Project Server can create magnificent dashboards the likes of which are currently in use tracking tens of billions of dollars worth of projects at large federal agencies. This robustness, however, comes with several drawbacks. Project was developed in an era of very linear software development, and many of those limitations remain to this day. It is entirely possible and feasible to use Project for Agile/Scum type work, but many advanced metrics and automation tools will be of little use at that point. Setup, especially for the server, can range from a bit complex to requiring an entire IT division. However, recent updates have incorporated many enhancements as a tip of the hat towards the wide adoption of Agile/Scrum and Lean methodologies, with the hope that more will be coming in the future. The biggest drawback with Project, however, is the relative complexity of setting everything up and the lack of malleability in adapting to recent methodologies. Still, many enterprises and virtually every US federal agency require it to be used, holding it in high regard as a gold standard to this day and for the foreseeable future.
You may have noticed I left a very popular “project management” tool out here, one that is common amongst startups. That being Basecamp by 37Signals. I purposely left this out because I feel that Basecamp is a more of a communication tool than a project management solution. This is because task lists work for small teams working on small projects, but quickly grow complex and inundating. Data on assignments, progress, issues and such are easily lost amidst a haystack of communications that rapidly overlap one another. We are visual creatures who gravitate towards simple layouts, graphs and other visualizations yet Basecamp is driven at this time seemingly entirely by lists and message boards with a very verbose interface. There is rumor of a revamped version of Basecamp coming out soon and one can hope that it will learn from the visual cues of the likes of Trello and others, because working on anything beyond simple projects can be quite cumbersome in the current setup.
Well, I’ve covered a few of the tools and various pros and cons of each. Hopefully some of this will be useful. Next time, we will discuss how Netizen Corporation uses some of these tools and some best practices for tracking and managing various types of projects with each.
2 thoughts on “Lessons in Startup Project Management Part II: The Tools”
The problem with Microsoft Project is that you can’t really use it alone in this day and age, but you will need to use it in conjunction with SharePoint for collaboration.
Any PM tool in this day and age should allow for collaboration, saves the project manager a lot of time.
Completely agree. I’ve worked at many places that simply email around MS Project files back and forth and they are almost always stale, single-purpose documents. SharePoint adds some collaboration to it, but there are many tools that are better (and less complex) out there now.