It's the Process!

I had just finished attending an advanced project management course today (it is worth 14 hours towards the PMP certification exam). In parts, it was a great refresher course on the stuff that I had forgotten since taking the courses at university. I also learned a few new things through the course. Taking this PMI process and the previous CMMI process together, I have come to some rather curious insights.

The main insight is that most of these processes like to say that they work just as well for anything but I think that most would probably face problems with open source development. I also started to realise that most of these processes require a well-defined hierarchy and job-scopes in order to work. This would probably be useful for larger organisations but would not be very useful for small ones where there is virtually no hierarchy and everyone did everything. It is not that these small organisations lacked processes, they merely had very different processes. Then, if we bring in the issue of open source software where anyone can contribute, it brings about an entirely different organisation and process again.

Firstly, communication channels. In a traditional structure, the number of communication channels is smaller as there is always a reporting hierarchy. However, in an open source project, the communication channels are less obvious because the stake-holders are more numerous. Anyone who has ever contributed any piece of code can be considered as having a direct stake in the project. So, the reporting hierarchy would paralyse traditional processes if they were to be adhered to. Imagine an organisation where your customer wasn’t just an external stake-holder but was also a co-worker and active participant in all the steps of your process. Now, imagine that multiplied by everyone else because every one of your co-workers and you yourself, was also the customer.

Secondly, job descriptions. In a traditional structure, everyone would be assigned roles and responsibilities. While there may be some crossing of boundaries, that would be the exception rather than the rule. In an open source project, responsibilities are not assigned but rather taken on by anyone who wishes to be involved due to the spirit of voluntarism. So, in your traditional process, you could transfer responsibilities but in an open source project, you couldn’t. There would be a lot of crossing of boundaries in open source development, often with a single developer contributing to multiple modules in the system and then being both accountable and responsible for those contributions.

I’ll give you an example of a kind of typical problem. Let’s assume that a feature needs to be added into the software. In a traditional process, someone (whether the client or management) would need to initiate the change, then the process kicks in and we study the impact of the change before kicking it up to the change board to decide whether to make the change or not. In an open source process, anyone can initiate the change, and then proceed to implement the change without approval because it would be faster than studying the impact of the change and if it turns out that the impact is negative, all changes can be rolled back.

So, while I do think that processes are integral to any software development process, I have a feeling that the traditional processes may not fit in easily and a lot of tailoring will need to be done.