Wednesday, May 6, 2009
On Releasing
Inspired by a veritable outpouring of interest (by which I mean a coworker mentioned to me that he had read at least one of my posts on the topic), today is the continuation of an occasional series on project management. It is my profound hope that by posting my thoughts here, I would be less likely to pontificate in person, when someone asks me an innocent question such as "So, project management..."
Today, I want to start with the short version of an exchange I once had with Richard Stallman (RMS), whom I idolize. I was tasked with making a piece of software, and RMS, who was looking over my shoulder, asked what I was making. I responded, "it's a content management system."
Stop me if I've told this story before.
RMS responded, "That's like saying you're doing something with stuff. What is it really?" A short chain of questions and answers followed, after which we decided I was writing a piece of software to publish news articles on the Internet. We called it an "Article Publisher." RMS talked a little more after that about how important it is to use the right words to describe software.
In that vein, the word "project" is one we should be careful with. Typically, outside of software, a project is something one does, and then one is done with. In software, however, that is called a "release." I like the word release a lot. It signifies the point at which a piece of software is let go. The word project is ambiguous: sometimes used to talk about a release, sometimes to talk about a product, sometimes to talk about something-someone-is-working-on.
On that topic, I want to offer clarification to one thing I mentioned to the coworker in question. I told him I was unsure how much common ground there is between building a tank and releasing software. In particular, I mentioned that too often people think of a release as incorporating both a scope and a deadline (when in fact it can be only one or the other).
The clarification is this: when building a tank, it's done when you've got a tank. Even if one really wants the tank very soon (which I presume is often the case), it's done when the tank is done, deadline be damned. Software, however, may be quite useful long before the full scope is completed. In fact, once a minimal set of functionality is achieved, release becomes more a matter of negotiation than of reality.
The mistake made when planning a software release is to presume this means we can have a fixed scope and a fixed deadline and necessarily stick to both of them. That's just silly, and over the long term the only thing it achieves is to get programmers to excessively pad estimates.
We get either one or the other: fixed scope or fixed deadline, and recognizing that at the outset makes the release run a lot more smoothly. There is, of course, software which has neither fixed deadlines nor fixed scope, and that software is either the best, or the worst, but certainly a topic for another day.
Today, I want to start with the short version of an exchange I once had with Richard Stallman (RMS), whom I idolize. I was tasked with making a piece of software, and RMS, who was looking over my shoulder, asked what I was making. I responded, "it's a content management system."
Stop me if I've told this story before.
RMS responded, "That's like saying you're doing something with stuff. What is it really?" A short chain of questions and answers followed, after which we decided I was writing a piece of software to publish news articles on the Internet. We called it an "Article Publisher." RMS talked a little more after that about how important it is to use the right words to describe software.
In that vein, the word "project" is one we should be careful with. Typically, outside of software, a project is something one does, and then one is done with. In software, however, that is called a "release." I like the word release a lot. It signifies the point at which a piece of software is let go. The word project is ambiguous: sometimes used to talk about a release, sometimes to talk about a product, sometimes to talk about something-someone-is-working-on.
On that topic, I want to offer clarification to one thing I mentioned to the coworker in question. I told him I was unsure how much common ground there is between building a tank and releasing software. In particular, I mentioned that too often people think of a release as incorporating both a scope and a deadline (when in fact it can be only one or the other).
The clarification is this: when building a tank, it's done when you've got a tank. Even if one really wants the tank very soon (which I presume is often the case), it's done when the tank is done, deadline be damned. Software, however, may be quite useful long before the full scope is completed. In fact, once a minimal set of functionality is achieved, release becomes more a matter of negotiation than of reality.
The mistake made when planning a software release is to presume this means we can have a fixed scope and a fixed deadline and necessarily stick to both of them. That's just silly, and over the long term the only thing it achieves is to get programmers to excessively pad estimates.
We get either one or the other: fixed scope or fixed deadline, and recognizing that at the outset makes the release run a lot more smoothly. There is, of course, software which has neither fixed deadlines nor fixed scope, and that software is either the best, or the worst, but certainly a topic for another day.
Labels: project management, scheduling
// posted by David @ 4:02 PM
Sunday, May 3, 2009
In Praise of Focus
Managing software projects involves a great deal of scoping. I like that word: scoping. It brings to mind the microscope we had when I was a kid, which my dad had when he was a kid, which is very much like the one my own kids have now.
Scoping, for those new to the conversation, is the act of describing a feature and subsequently deciding whether it will be included in a given release. If it's to be included, it's in scope. Otherwise, it's out of scope.
I like this metaphor in part because there's no presumption that it's something done at the outset; rather, it's a continuous activity throughout the course of the project. A good project manager will be managing the scope in such a way that features bringing very little benefit for a great deal of risk can be scoped out. Alternatively, features with a great deal of benefit requiring relatively little work can be scoped in, but that's a topic for another day.
Today, I want to make only one subtle point, which is that when an actual, physical scop is in use, the activity of narrowing the scope is called "focusing." And it's not something to be avoided- it's something to be embraced.
The end of a release cycle can be a stressful time, and it is made even more stressful by managing it as if the scope and schedule are fixed. Only one of them can be, and in general, I recommend fixing the schedule rather than the scope. There's nothing like a real deadline to bring focus.
And by focus, I mean both clarity, and reduction of scope.
Scoping, for those new to the conversation, is the act of describing a feature and subsequently deciding whether it will be included in a given release. If it's to be included, it's in scope. Otherwise, it's out of scope.
I like this metaphor in part because there's no presumption that it's something done at the outset; rather, it's a continuous activity throughout the course of the project. A good project manager will be managing the scope in such a way that features bringing very little benefit for a great deal of risk can be scoped out. Alternatively, features with a great deal of benefit requiring relatively little work can be scoped in, but that's a topic for another day.
Today, I want to make only one subtle point, which is that when an actual, physical scop is in use, the activity of narrowing the scope is called "focusing." And it's not something to be avoided- it's something to be embraced.
The end of a release cycle can be a stressful time, and it is made even more stressful by managing it as if the scope and schedule are fixed. Only one of them can be, and in general, I recommend fixing the schedule rather than the scope. There's nothing like a real deadline to bring focus.
And by focus, I mean both clarity, and reduction of scope.
Labels: project management
// posted by David @ 6:59 PM
Subscribe to Posts [Atom]