Project managers, we love issue and project tracking software like Basecamp, Redmine, JIRA and the long list of similar applications that let us put our noses in your work. We see them, too many times, as the panacea for miscommunication or project scope creep.
This would be SO great, if only other parts involved in the project (developers, designers, testers, product owners, business managers and the long list of roles that usually get the real shit done) had the same feelings towards these tools. News is, they don’t.
Working with this systems is, for many of them, ‘not my job’. Small tasks are usually managed out of our systems, developers forget to put their tasks ‘in progress’, product owners omit part of their requirements and communicate them by email, and managers just drop by people’s desk to change deadlines, merciless.
This causes us, the project managers, a fair amount of trouble; and we are experts in cascading that down. No issue in progress after 3 days of work? I will drop by the developer desk and ask him about this task. No requirement for post code validation? Let me ask the product owner. You asked for a feature in person and it is (surprise) built in a completely wrong way? Send me the that 20 pages document you printed about it and I’ll try to find what the problem was… And this is how we become ‘the annoying person always asking stupid questions’. If only you’d create tickets…
No change without ticket is a great policy to implement in any project where more than 2 people collaborate. Some of the benefits of tickets are:
- They are a great way of communicating requirements. Tickets are public and can be edited or commented by any members in the team. This makes them a great place to make sure requirements are complete and coherent with other requirements and whatever already exists.
- Issue tracking systems let you assign work. No more team members idle and not knowing what to do, no more overworked developers. Whether you use a pull or a push system, tickets are great for monitoring who’s supposed to do what.
- Tickets track discussions, and help us all keep track of decisions, changes, and resolutions. Have all discussions happen online in a place where you can track them and you’ll get rid of the broken phone problem. Who approved that change? Who spotted that bug? Easy to answer if it happened inside of the system, good luck with that if it did not.
- Spot missing steps in your workflows and processes and manage dependencies. Adding one ticket per task and creating blocking relationships help you identify when something is missing or when something needs to be done in order to keep working. This helps you build your critical path and organize work more efficiently.
- This kind of systems let product owners specify priorities for the tasks that need to be done, and helps developers confirm they are working on what needs work right now.
- Estimate times. Most issue tracking software apps come with time estimation and time tracking functions, so you can estimate how long you’ll need to complete a task. This helps us, project managers, since we can then know how much work you have and how much more we can give you without burning you up.
- We can spot bottlenecks and find out where more people is needed or where a badly designed process is keeping us from working better.
Do you have other good reasons to use a ticketing system? Is there any reason why we shouldn’t?
Bonus: Pick your ‘no ticket, no party poster’. Thanks to Jan for inspiring the chocolate related (and actually the really convincing) part of it. Made with the Swiss Poster Generator.