The Mobile Phone Project is, metaphorically, tipping over the summit of the whole development life cycle and reaching that point where it will begin to slither at ever increasing speed towards completion. Those doomed to stand between the majestic unstoppable oncoming mass of it and the fragile walls of deadlines risk being crushed. That’d be me, then. There is one fact which, at first sight, seems to offer hope; the deadline is entirely of our own making and subject only to our control, for the moment. This puts us in the allegedly happy situation where the developers of the project are also those mandating the pace and dates for development. However, it’s not actually that convenient. In fact, it’s been rather annoying.
There seems to be a general truism about most people (including me; I’m sure there are exceptions). We know what we have to do today. We’re pretty sure what we have to do this week. We have a general idea of how next week may go… but beyond that, things get fuzzy. Yes, there’s a to-do list, maybe even a task database and a project plan, but conceptually there’s this big empty space under the carpet of the future where it’s all too easy to sweep anything that you can’t get around to right now.
There are, of course, many ways in which time-perception affects work, and those of us who do project management have seen this particular demon before. But I’m not really referring to the problem of estimating, more to the way in which it’s easy to become unmoored and to drift in the timeline of a project if there’s no definite end.
So, we’re fixing the end date. Nailing it, in fact, by commiting external parties and actual financial resources even though, in theory, we don’t actually need to do that yet. When that date’s attached to huge anchors and embedded in the calendar, all sorts of good consequences flow. Chief amongst them is that the project’s paths now extend backwards in time from that point, forming chains of tasks in dependency order. It’s actually easier to do this backwards, since it focuses attention on the actual things needed for product launch as opposed to the things-we-thought-we-would-need-to-do-but-don’t. Not being a fan of BigDesignUpFront, I find this a liberating and useful shift of focus.
Incidentally, I make no apologies for linking ad nauseam to the C2 Wiki on Programs, Patterns and Projects; one of the best resources out there for anyone even nominally in charge of software development, whether or not Extreme Programming is your bag.