Process mature organizations do not think process is a dirty word. Unfortunately many other organizations have been victims of half-hearted attempts to simply adopt the flavour-of-the-day methodology as their de-facto process without adequate focus on enactment.

My experience working with process mature enterprise organizations has been that a successful process definition really starts when you start thinking about the enactment scenarios it is trying to address. Simply put, convincing a business sponsor that processes are important and worth investing into, is easier when you articulate the advantages it will have on project success. Moreover this assessment has to be data-based and not subjective. Let me take an example from software development to further detail this idea.

It is now widely accepted that design and development go hand in hand. After a designer comes up with software design it is not uncommon (in fact it is expected) for the development team to uncover gaps and further improve design as they go about implementing it. It would be unrealistic to expect the design document to be complete even before writing the first line of code based on it. The same applies to the world of process definition and enactment.

In my view it is not possible to come up with a sustainable process definition without enacting it in real projects. Unless project teams try to enact the defined processes, they cannot uncover process gaps. Unfortunately this is also the reason why in many organizations process has become a dirty word. There have been many anecdotal stories about how someone (usually a consultant from or trained in the latest methodology fad) would create a process (mostly solo with just token efforts to involve all stakeholders) and toss that over to the development team, collect his/her cheque and leave. At best the knowledge workers (I would characterize all practioners in a software development project as knowledge workers) would take a look at this process binder and throw it over to the trash bin. At worst they would try to follow the process in the absence of a process enactment framework in place, fail, and become demotivated vowing never to follow similar imposed processes in future. In both cases the project schedule languishes and help of “hero” practioners is needed to save the project. But how are process mature companies managing their processes and enactment?

To begin with, these enterprises realize that process creation should not be a single user effort. The process management infrastructure should lower the barrier of participation by enabling all stakeholders to collaboratively come up with processes. For an enterprise with a number of teams spread across different time zones this would mean:
- Collaborating while managing a process infrastructure built on a commonly understood, uncomplicated process meta-model that supports all methodologies including home grown.
- Supporting the creation of a process architecture that would map to the organization structure with access control granting visibility into process assets and promote reuse.
- Representing process assets in relational databases allowing subject matter experts to keep updating the vast pool of best practices that is impossible to manage in a file-based system.
- Provisioning a visual, intuitive user interface to create processes. No one wants to spend weeks to understand how to extend an activity.

Putting in place a process management infrastructure is just half the story. Process mature organizations would ensure that the processes created in a manner defined above are validated for enactment. This means an automated mechanism to check for holes in the process, such as usage of work products that become outdated as the process was being developed. Having done that it is time to enact these processes. It is during process enactment that teams would uncover what is missing in their processes. Lessons learned as part of a successful or unsuccessful implementation would provide rich data to improve these processes and institutionalize the lessons across the enterprise. Compliancy reporting would mean teams can self-audit how far/away are they from meeting the compliance points as laid out in the defined process. Finally, with data-based process interventions and the empowerment of project practioners the chances of project success keep getting higher with successive implementations.

So why has Osellus invested more than four years in this process enactment domain and is introducing our second generation enactment tooling later this month. Here are a few reasons:

- Process enactment is emerging as the new frontier in software development process world. Standards such as ISO/IEC 24744 already taking lead in this area. The Osellus SPEM 2.0 submission had enactment as a cornerstone of the process meta-model. There is a strong demand from process mature organizations to address this need.
- Enables wider (more practitioners empowered with buy-in) and deeper (actual “consumption” of processes in real projects) process adoption.
- Increases chances of better software quality since the best practices and guidances are viewed in terms of enactment/endeavor domain on real projects and not just published binders/websites.
- Lays the groundwork for gathering metrics on project health, process compliancy (regulatory and quality frameworks) and data-based process improvement decisions.

In a later post, I am going to share a bit more about the second generation process enactment infrastructure we have built. This draws from direct feedback from enterprise teams as well as our own lessons learned from our first generation tooling around enactment.

Last 5 posts by Kamal Ahluwalia

• Is my process true to my methodology of choice? - January 7th, 2008
• EPF – Failing grade on collaboration - January 2nd, 2008
• Governance Webinar Recording - December 7th, 2007
• Webinar - Effective Software Development Governance - November 28th, 2007
• IRIS Process Central is here... - November 19th, 2007

This entry was posted on Monday, April 23rd, 2007 at 4:52 pm and is filed under Processes & Methodologies. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.