I’ve always wondered how some popular open source and GPL projects keep going. Many times, they seem to implode upon themselves, whether due to internal or external forces imposing their undue influences upon the work at hand. The good ones realize that they are imploding and take measures to stop it from happening… and sometimes, they manage to successfully execute an appropriate plan of action in time.
Here’s an interesting live example: WordPress.
Scenario: WordPress
Jane Wells posted yesterday about an anticipated change to how WordPress development will change to fit a model that should address their scope creep problems that have been hampering their releases, of late. She refers to project management as providing the answer for their woes with scope creep; yes, there’s additional verbiage in the post, but essentially, that is what she is primarily referring to. There is that additional component to the problem, in the form of release scheduling, which plays a part in the problem set.
At this point, some of you will be nodding sagely toward your display screens (LCD’s, iPhones, BlackBerry devices, et al.) and thinking, “Well, project management techniques would help manage what is going on, but… there’s something else in play that needs to be controlled, right?”
Management Perspective
Yes, sage thought (or thinking sagely, perhaps?), indeed.
While project management in general is a useful discipline or tool to have, even for small teams, especially those that conform to a matrixed (or “mixmaster”) configuration, it is not the magic bullet that many people think it is.
In essence, it is a way to react to chaos in the workplace by arbitrarily grouping workstreams into some semblance of order, based on a variety of criteria, like limited resource availability, priorities, scheduling conflicts, release dates, et al.
However:
What if trying to rope in the insanity of scope creep and meandering requirements are symptoms of a greater problem? Using reactive techniques to mitigate further damage to a production schedule is only an immediate-term fix.
Instead, determining a new way to manage requirements intake and development, and a new workflow cycle for controlling change and releases, would be much closer to a longer-term solution. Figuring out the most appropriate mechanism by which to introduce and control change (whether fixes, new features, extensions, etc.) and to align them with ongoing development and documentation is the basis for the transition toward a fully-realized workflow that integrates configuration management with project management. Of course, not an easy task (certainly, easier to simply state what seems to be needed for this scenario, as opposed to actually implementing it)… 
But a lot of the basic tools to build upon are already in-place or being used or available.
So, this will be an interesting live scenario to follow.
{ 1 trackback }
{ 1 comment… read it below or add one }
For the record, all the things you list in the next-to-last paragraph are things that I would consider part of effective project management. Simply setting a release date and writing down the scope are not the bulk of project management, but specific tasks. In any case, future posts will be working out ways to streamline our Trac process, create responsibility tiers to improve workflow, etc. It just would have been too much for one post.