PM Models and Distributed Open Source Projects.PM Models and Distributed Open Source Projects.

0 Comments

There are multitudes of differing Project Management Models that are in use today, and the PMBOK offers quite a bit of information regarding some of the more popular of these. Searching the Internet and the many differing Project Management Community sites turns up a plethora of specialized/hybrid models. All this, means that there is, most likely, the perfect PMM out there somewhere that will fit your needs no matter the situation.

There are multitudes of differing Project Management Models that are in use today, and the PMBOK offers quite a bit of information regarding some of the more popular of these. Searching the Internet and the many differing Project Management Community sites turns up a plethora of specialized/hybrid models. All this, means that there is, most likely, the perfect PMM out there somewhere that will fit your needs no matter the situation.

However, Distributed Open Source Projects are an entirely different breed of Project that requires not only the traditional concerns be taken into consideration but also a number of other factors that WILL make life difficult for the PM as well as the Project itself. Factors such as free-time contributors/developers, fake/non-productive/one-liner contributors/developers, time-zones, language limitations, organizational issues, egos and more are things that are most unique to Projects in the OS Community today and tend to cause headaches for the Project Managers and may even be a major cause for the failure of such Projects. Language limitations are a factor that, honestly, can be little influenced by the PMM in place. However, with the correct PMM in place such factors lose, in most cases, their ability to cripple a Project.

With the use of MS Project and other PM software we (the Project Managers) are at times, forced or inadvertantly guided, into certain PM Models and lose sight of the fact that there are other possibilities to take into consideration. Now PMMs’ like waterfall or spiral are all well and good but, in my opinion, not well suited for a Distributed OS Project. After long search and much discussion I am currently looking at only 2 models that come into true consideration for Distributed OS Projects. The first is the “train” model and the second is the “evo”, or “evolution”, model. Both of these models have their good points and bad points. Of the two it would seem that only “evo” has received major acceptance in the Project Management Community at large. The “train” model has gained more acceptance in the Open Source Community.

The acceptance of the “train” model in the OS Community could be explained in the fact of it’s simplicity in general. Complete the “Roadmap” of the Project as well as a rough time-frame and off you go. If, by the time a release date is reached, certain features/milestones are not available they are simply dropped in favour of a release. Those dropped milestones are then tacked on to the next release date and development of the Project moves on. This form of Project Management is not uncommon in the OS scene today and seems to be generally accepted even if there is some disconcert from end users regarding the missing features.

The “evo” model is a bit similar to the “train” model in that there are regular release dates and features/milestones are pushed as needed. The difference between the two goes a bit deeper though. The “evo” model is DESIGNED around the concept of postponed features in favour of stability of features, knowing exactly what is required and learning from past mistakes in the current Project. That is why the “Roadmap” for and “evo” based Project is more fluid and has less concrete release dates for most features/milestones. Instead an “evo” based Project will make a release and wait for feedback to help decide the next phase of the Project. If all goes well the Project will proceed toward the next major milestone/feature release. If not then the Project will loop back, fix and learn from the mistakes it made and re-release for a test phase.

This can, at times, make it seem as if an “evo” based Project has stalled when in actuality it has not. This is a planned effect of the model and people seem to forget that aspect of “evo”. In such cases it is always best to inform people, clearly, of the models intent in assuring stable releases and multiple test phases as needed.

Now there are some people that keep preaching the pluses of the “agile” model for Development Projects and to be totally honest I just can’t get behind the push for the “agile” model. When I first heard of the “agile” model I thought it just might be the third viable alternative for Distributed OS Projects but have since come to terms with the fact that it is more attuned to small, fast and dirty projects with no need for real control. It leaves way too much leeway for quality and specs for my tastes and control of the Project is also limited.

It’s also true that one can incorporate “evo” into an “agile” Project to give the project focus and stability in certain areas. However, I see it differently. Why not start with an “evo” based Project and if you need to get really crazy then incorporate “agile” selectively to allow for more freedom where needed. The way I see it is that “evo” is flexible and free enough that “agile” should not really be needed though.

I am currently looking for other models to include in my rather short list of possibilities but have yet to have the fortune of finding any. If you know of one that would make a good candidate please let me know and I will check it out.

Thanks,

Chuck

However, Distributed Open Source Projects are an entirely different breed of Project that requires not only the traditional concerns be taken into consideration but also a number of other factors that WILL make life difficult for the PM as well as the Project itself. Factors such as free-time contributors/developers, fake/non-productive/one-liner contributors/developers, time-zones, language limitations, organizational issues, egos and more are things that are most unique to Projects in the OS Community today and tend to cause headaches for the Project Managers and may even be a major cause for the failure of such Projects. Language limitations are a factor that, honestly, can be little influenced by the PMM in place. However, with the correct PMM in place such factors lose, in most cases, their ability to cripple a Project.

With the use of MS Project and other PM software we (the Project Managers) are at times, forced or inadvertantly guided, into certain PM Models and lose sight of the fact that there are other possibilities to take into consideration. Now PMMs’ like waterfall or spiral are all well and good but, in my opinion, not well suited for a Distributed OS Project. After long search and much discussion I am currently looking at only 2 models that come into true consideration for Distributed OS Projects. The first is the “train” model and the second is the “evo”, or “evolution”, model. Both of these models have their good points and bad points. Of the two it would seem that only “evo” has received major acceptance in the Project Management Community at large. The “train” model has gained more acceptance in the Open Source Community.

The acceptance of the “train” model in the OS Community could be explained in the fact of it’s simplicity in general. Complete the “Roadmap” of the Project as well as a rough time-frame and off you go. If, by the time a release date is reached, certain features/milestones are not available they are simply dropped in favour of a release. Those dropped milestones are then tacked on to the next release date and development of the Project moves on. This form of Project Management is not uncommon in the OS scene today and seems to be generally accepted even if there is some disconcert from end users regarding the missing features.

The “evo” model is a bit similar to the “train” model in that there are regular release dates and features/milestones are pushed as needed. The difference between the two goes a bit deeper though. The “evo” model is DESIGNED around the concept of postponed features in favour of stability of features, knowing exactly what is required and learning from past mistakes in the current Project. That is why the “Roadmap” for and “evo” based Project is more fluid and has less concrete release dates for most features/milestones. Instead an “evo” based Project will make a release and wait for feedback to help decide the next phase of the Project. If all goes well the Project will proceed toward the next major milestone/feature release. If not then the Project will loop back, fix and learn from the mistakes it made and re-release for a test phase.

This can, at times, make it seem as if an “evo” based Project has stalled when in actuality it has not. This is a planned effect of the model and people seem to forget that aspect of “evo”. In such cases it is always best to inform people, clearly, of the models intent in assuring stable releases and multiple test phases as needed.

Now there are some people that keep preaching the pluses of the “agile” model for Development Projects and to be totally honest I just can’t get behind the push for the “agile” model. When I first heard of the “agile” model I thought it just might be the third viable alternative for Distributed OS Projects but have since come to terms with the fact that it is more attuned to small, fast and dirty projects with no need for real control. It leaves way too much leeway for quality and specs for my tastes and control of the Project is also limited.

It’s also true that one can incorporate “evo” into an “agile” Project to give the project focus and stability in certain areas. However, I see it differently. Why not start with an “evo” based Project and if you need to get really crazy then incorporate “agile” selectively to allow for more freedom where needed. The way I see it is that “evo” is flexible and free enough that “agile” should not really be needed though.

I am currently looking for other models to include in my rather short list of possibilities but have yet to have the fortune of finding any. If you know of one that would make a good candidate please let me know and I will check it out.

Thanks,

Chuck

Tags: , , , , , , , , , ,

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.