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]