On Projects, and having too many of them

Projects— all software developers have them; many of us would say that we have too many, but how do you manage yours?

Working for a small newspaper with extremely limited resources and even more limited understanding of technology has taught me many things about managing workloads and ensuring that everybody is looped in on various projects for which they are stakeholders— whether they like it or not.

Use a project management solution

For projects under my management, I’ve set up an instance of Trac that I use to keep everybody on the same page with regard to scheduling, priority, and project details. Trac is spectacular because it’s open-source, and can be easily set up on a linux box hidden in a closet somewhere.

Projects are always more complex than they appear initially; do not expect to be able to keep in mind every single detail about things you’re working on, all of the comments people have made, and all of the project details that become apparent as stakeholders and you, yourself, become aware of along the way.

Weeding through thousands of e-mails looking for a proof for an ad, a feature request, or even just a note regarding a color being slightly too blue is a potentially excessive time sink, and tying people to their own decisions is the only way to manage

The road to success is paved with failures

If you mess something up, say so; keep track of it, write it down, and absolutely do not try and cover it up. This may not be good for personal marketing, but it will be essential for your being able to record where things went awry in the past, and will prevent you from making the same sorts of mistakes in the future.

Track your hours

Time tracking always seems like a waste of time, but people are really, really bad at keeping track of how long things take. If you do not keep track of things, you will perpetually over-crowd your development schedule due to underestimating any of the thousands of coding-unrelated time costs.

When asked to estimate how long a project will take, programmers like me are likely to estimate assuming that they are staring at a computer screen for four hour blocks, building a solution. Things that are inevitably left out include meetings, telephone calls, unexpected problems, hangovers, and the like. Programming costs time.

Personally, I use a little python app named TimeBook, and a little script that will read through my time tracking entries, searching for ticket numbers. If it finds a ticket number in the annotation for a specific time tracking entry, those hours are added to an “hours spent” field on the ticket itself. This institutes transparency day-to-day with regard to how far along a project is, and helps you make better hours estimates in the future.

Double your hour estimates

Accurate hours estimates are essential for scheduling and setting expectations. Projects are always more complex than they appear, and the human mind is extremely bad at adding in tangential costs. Especially if you haven’t been rigorously tracking hours spent per-project, using a simple “this will take about twice as much of my attention as I think I’ll spend coding it up” is relatively accurate, and much, much better than over-estimation.

Nominate a primary stakeholder

On every single project I enter into my ticket queue, I always have at least one person on the CC list— the person nominated as the primary stakeholder.

Do not let people convince you into divvying up various aspects of a project into more than one primary stakeholder— developer hours are expensive, let the primary stakeholder determine who to send the request to. Also, this way, there’s at least one person who should know all aspects of the project at hand moment-to-moment.

Assume you’ll have time to code only 20-30 hours per week

Even if you’re on a solid 60 hour work week, you must make sure that you have enough of a buffer in your schedule to handle unexpected issues requiring your immediate attention like meetings not directly (or, not directly yet) tied to a specific project.

If you assume that you’ll be able to operate at 100% coding efficiency, you’ll be sadly mistaken when a server room catches fire, when a salesperson has pitched a project requiring a two-hour project initiation meeting, or when you’ve found a wonderful refactoring opportunity in your code that will save time in the future.

Bugs, refactoring and generalization, and meetings are all costs that may not be expected, but they absolutely do happen.