Within the openSUSE Community, the topic of resource planning and project management appeared and was discussed in mid-to-late June 2012. Due to factors largely outside the community’s control (hardware issues, the poor state of Factory), the planned release-date of openSUSE 12.2 simply could not be met.
As part of the discussion surrounding that, the possibility of a change of development strategy was brought up, see Stephan Kulow: Calling for a new openSUSE development model.
In the ensuing debate it was suggested that we apply traditional resource planning and regular project management. Almost immediately, this was met with sarcasm and ridicule, suggesting this was simply a ludicrous idea and quite impossible in a FOSS environment.
I disagree, I believe it is entirely possible to apply (at least some of) traditional project management to a FOSS project, in particular a Linux distribution such as e.g. openSUSE.
The three key factors
Traditional Project Management is largely about juggling three key factors:
- resources
- deliverables
- deadlines
Experienced project managers will want add another 20 factors, but let’s ignore those for now.
The simplified view
In typical project management, two of the three key factors above are given, and it is the project manager’s first job to come up with the third factor:
- the resources and the deliverables are given, work out the deadlines.
- the deadline and deliverables are given, work out the resources.
- the resources and the deadlines are given, work out the deliverables.
Throughout the project’s lifetime, deliverables might change, deadlines might slip, and resources might come and go, so it is the PMs job to readjust factors and make predictions about deadline slippage, decisions about scope-limitation, applications for more resources etc.
Examples:
- if the resources change (somebody leaves the project), but the deadline has to be met, the deliverables have to change.
- if the deliverables are changed upward, but the resources remain fixed, the deadlines have to change.
- if the deadline is moved forward, but the resources remain fixed, the deliverables have to change.
And so on and so forth.
As mentioned above, many other factors could come into play – company politics, priorities, money etc.
FOSS Project Management is somewhat different to the above – primarily because the resources are not only not fixed, they are largely unknown and largely voluntary. Secondly because the PM is also (well, at least partially) charged with keeping the volunteer resources (i.e. the community) happy and motivated.
PM Model #1: let the deliverables be the constant factor and vary the deadlines according to the progress made.
PM Model #2: let the deadlines be the constant factor, and let the deliverables vary according to the progress done.
So far, openSUSE has been working with model #2 – a fixed release schedule and varying the deliverables according to that. For openSUSE 12.2, it became clear that the deliverables could simply not be ready on time, regardless of how much they were reduced. Essentially we are now looking at model #1.
Model #1 requires us to measure progress. I suggest that this might be possible by having many and simple (i.e. easy to measure) milestones.
openSUSE current milestones
We have long had the typical set of software project milestones – alpha release, beta release, release candidate 1, maybe a release candidate 2, then Gold Master. Because of openSUSE working according to model #2, those names were actually largely irrelevant. They indicated only deadlines, not deliverables. Due to the varying resources, it was impossible to tell exactly what state the distribution would be in at a given time, so there was no real meaning to the term “alpha release”. It was simply a snapshot on a given date.
If we are to change to model #1, we need to define the deliverables, thereby hopefully adding real meaning to e.g. “alpha release” and “beta release”. To be able to measure progress and state of the deliverables, these would be made up of a set of fine-grained, easy-to-gauge milestones. When for instance 80% of a set of milestones have been met, the deliverable would be 80% complete. The time it took to get thus far could be used to extrapolate the time it would take to complete the remaining 20%. Of course, this is guesstimating at best, but I think it would give us significantly improved control and much better visibility.
There are a few more topics that I ought to discuss here:
- defining deliverables
- defining milestones
- measuring progress
However, I’ll leave those empty for now. I really just wanted to argue that it is entirely possible to apply traditional project management in a FOSS environment/project.
