In large companies, project management is a must; in startups, it’s a radioactive “hot” potato. Large companies have dedicated project managers and sometimes even a Project Management Office (PMO). Small companies like ours don’t have one and we’re pushing 60 employees now after 18 months. Eventually, it’ll make sense to have a full-time project manager, but until then we want to stay agile so we get by using software, process, and face time.
Use the Right Software
When our Product-Engineering team consisted of CEO, CTO, and two engineers, email was our issue tracker and a whiteboard contained our roadmap. That worked well. Soon we hired a few more engineers and email proliferated. Pivotal Tracker (PT) became our issue tracker (still free then!). PT is simple, light, and an engineering team’s dream–a place where only engineers could hang out. We upgraded to Google Spreadsheets for our roadmap so we can do more sharing and simple Gantt charts. Once we hired some product managers, added a QA team, and started developing many projects at once, it was time to swim in the Olympic-size pool: Jira. Besides being created by a hilarious bunch, Jira does everything. That’s part of the reason we resisted using it early on, since we didn’t want to fill out so many corporate-y fields like “hours worked” (::shudder::). As for our roadmap, it broke Google Spreadsheets and I grew tired of the “aw, snap!” pages. I’m experimenting with a few tools and so far I like Asana and Smartsheet. Find what works for you now.
Evolve Your Process But It’s all About Face Time
We tried to add only as much process as we needed over time. You start out with a fast track from feature conception to release. When you have two people who work on a project, you can sit down and have a heart to heart, nod heads, and then start coding. When a product manager has to convey thoughts to a few developers and a few QA–this is a small team still–details get lost in translation. Not only that, conversations may happen between members of the team that aren’t shared with the rest of the team. Let the frustration and angst begin. For a while, we went with the Product Requirements Document (PRD) approach, which is very monolithic. We’ve since moved away from that. Recurring meetings get moved around and their titles and agendas change. We went from 1-week to 2-week releases. Processes should change when the team changes or when the needs of the team change. It all comes down to getting a bunch of people to share ideas and work together efficiently. All this software and process is meant to cheat time–time to talk to one another face-to-face that is very hard to come by.