One of the challenges in adopting any methodology in an enterprise is in ascertaining the degree to which it is actually used. Although this sounds simplistic enough it brings a key issue out in the open. Even if an organization has converged on a single methodology to use there are subjective and often acrimonious debates on the extent to which a defined process adheres to the key concepts – either fundamental concepts that outline the methodology or the control objectives that have been bolted on to this methodology. It is not enough to have a methodology preamble announcing that this methodology meets so and so concept or follows this philosophy. A process mature organization needs to go behind the rhetoric (and I am not trying to slam this sort of collateral that sells the methodology) and actually give specific mapping between the process elements and the concepts and or control objectives that are promised to be met with this process.

This data-mapping will not only help in auditing your processes for compliance to your business or regulatory objectives but will also serve as an indisputable baseline to have those debates on what kind of process does the project team really need for an upcoming project. If you know where you are now, it is easier to steer where you want to go. Categorization of your process elements is therefore a simple but powerful way to keep measuring if your process is on track to become what you expected it to be or of you need to make modifications so that you can control its flavor at process authoring stage. Off course another benefit in this approach is that when you are ready to share your process with a peer network they can give their feedback so that you can adjust the mapping of your process elements to the methodology concepts and control objectives and validate this mapping.

There are many examples of this sort of categorization that can be seen in the processes available at the IRIS Process Central Sandbox. You are welcome to try out these processes and provide your comments.

I have been keenly watching the progress on what started as a promising project in the Eclipse foundation. Unfortunately after more than two years of opportunity to shine I would have to give the EPF project a failing grade. I fear that when someone at IBM realizes the wasteful investment of resources in this project they will pull the plug on their participation at EPF. This will inevitably kill the project since IBM is the only committer on the tool aspect of EPF and the major committer and donor to the content aspect of EPF.

In my view there are several reasons for this failure and many lessons that I have learnt simply by following the travails of the project. These reasons are not the lack of aptitude and personal contribution of the EPF team but simply a miscalculated approach to building a vibrant self-organizing process community. Today I will highlight the mind boggling high transaction costs of submitting process content to be consumed and critiqued by a peer network. Even by their own admission, it takes “2-3 months” for the eclipse legal process to approve any process contributions to EPF. This is an anachronistic concept in today’s day and age. Communities are self-organizing. If what I contribute is useless to you, you will not use it. Period. Moreover having been tagged as someone who supplies useless content my user ratings will go down and I will have to significantly improve my game to get back my reputation. Communities give rise to wisdom-of-the-crowd, encourage meritocracy and do not tolerate back room machinations. As articulated by Chris Anderson in The Long Tail while discussing the tools needed to support a long tail, “This is the end of spoon-fed orthodoxy and infallible institutions, and the rise of messy mosaics of information that require - and reward – investigation”. Elsewhere in the book he discusses how “a once-monolithic industry structure where professionals produced and amateurs consumed is now a two-way marketplace, where anyone can be in any camp at any time. This is just a hint of the sort of profound change that the democratized tools of production and distribution can foster”. In the case of software process modeling, these tools take the form of easy to use process modeling and consumption tools. With that, rather than a paradigm of a handful of processes being donated by a few process experts, one could feasibly have hundreds of process variants created, put on wikis, blogged and rated! Now if we multiply the 2-3 months timeframe for these 100 processes the EPF legal staff will be kept busy for 20 years…just on this project! Later I will discuss some other pitfalls to avoid based on the lessons learned from following this project.