The following may or may not change the way you plan minor work or home crises. I bear no responsibility for either eventuality.
As we approach the date of the wedding we suffer creeping horrors of what K. calls “the hidden.” All the big problems have been dealt with, by and large, and the management of them ticks over as the second and third parties actually ring us up to whine about details. So the venues are booked, the photographer and florist agreed upon; the forms are with the registrar and we’ve managed to pull teeth of purest information out of the slack, public-facing jaws of both our venues. But little tasks remain undone: buying of clothes; typing up schedules; printing out tickets; and chasing those who are too lazy, incompetent or uninterested to confirm. The end of April was three weeks ago: if we were a 100 bus and not a wedding party then we’d have left by now.
These small problems are those most liable to come back to haunt us, remaining on the periphery of our awareness of what needs to be done as our attention is distracted to the less important issues, most of which are convinced of their own, much greater, importance. Our fear is that we will forget these problems until one or other of them can no longer be handled easily, and they will cause us far more trouble than they would have done earlier in the planning.
With this in mind I spent a fruitless Friday evening trying and failing to set up trac, a ticket-based tracking program, on my home computer. This is not to denigrate trac. It’s revolutionized some of the projects at work. It’s extensible and fast and very well designed. My machine and its environment—a Windows XP laptop on a network routed by a locked-down Speedtouch to which I have lost the password—are simply not suitable for too much tinkering without a decent amount of prior research into compatibility and expected quirks of the set-up.
But a decidedly low-technology alternative made itself available instead. For those that haven’t seen a ticketing system, the principles are as follows:
- The initial problem is broken down into the smallest chunks that can be handled separately. Each chunk is noted down on a “ticket”, which has a brief description of the problem and some sort of label explaning its current status.
- As the contents of each ticket are dealt with, successfully or otherwise, the ticket is updated to track the current state of each chunk of the overall project.
- All tickets exist on a “board,” and you can look at that board from various angles, to see all tickets pertaining to a booking, or all tickets that are waiting on a particular milestone in your project.
- Tickets drop off as their solutions are found; they’re modified and dealt with, barely tractable as some of them might be; all of the little details of the project are all on the board; and 3am night terrors become just another note to fret about in the morning instead.
As you can see, the metaphors driving a ticketing system are derived from an original method that relied on no electrical technology, and was quite simple in its execution. A method which, back-forming those metaphors that had originally driven me to the software in the first place, we have implemented for our wedding:
Each ticket has a short title in black, a description in a muted colour beneath it, and a deadline in its bottom-right hand corner. Tickets start in the middle and, as the deadline approaches, they gravitate towards the left-hand side (if I’m meant to solve them) or to the right (for K’s attention). Unlike in a computerized system we only have these two dimensions to move the tickets over, but it’s more than enough for the complexity of what we have left to solve.
(The special ticket bottom-right, the only one you can probably read to any useful extent, is an attempt to number the weeks to the wedding. My time at Oxford has influenced the choice of “-2nd”, “-1st” and “0th” as labels, much to K’s chagrin as she never actually worked the system out while she was studying there. Well, every plan needs to have its potentially fatal flaw, doesn’t it?)
I’ve heard the myths of agile programmers performing similar paper-based antics, but never really seen it in practice (cue choruses of “well, I think you’ll find that…”). At any rate I can heartily recommend it: the full cost would be as you’d expect less than ten pounds, although we already owned all the equipment involved, but since then we’ve cleared half the tickets off the board (replacing them with another two or three to track ongoing problems) and we’ve had our first few decent nights’ sleep in a couple of weeks.
So, if you’re feeling overwhelmed, put all your problems on a pinboard, and with a little care and attention every now and then you’ll find they’ll gradually free themselves of their pins and float away.