CMMI maturity level 2 and higher requires that organizations institutionalize processes so that in times of stress they are not discarded.

In an earlier post, I described how tools, such as integrated application life-cycle management (ALM) systems, and process and project portals, can substantially reduce the duration of appraisal process. Achieving institutionalization is another area where these tools are extremely beneficial.

First, ALM systems capture and automate many aspects of CMMI processes, hence, reducing the additional overhead imposed by CMMI related activities.  With minimal imposed overhead, there is much less incentives for the project team to discard the CMMI activities in times of stress.

Second, process and project portals, such as Osellus Process Central, substantially increase organization wide awareness of processes by providing central access to all organization’s standard set of processes (OSSP) and project-specific process, as well as, provide a forum where these processes are discussed by all.  Overtime, this result in processes becoming a part of the fabric of the organization and ingrained in project teams. It is unlikely that such teams would abandon processes in times of stress.

In the realm of software development, enactment is codification and execution of software development life-cycle (SDLC) processes.

These days we have a methodology overload.  It’s not that I don’t recognize the importance of SDLC methodologies, rather I feel we already have more than enough methodologies to satisfy the needs of any organization. My proposal: lets put methodology development on pause for two years.  During this grace period everyone should focus on development and deployment of tools that support existing methodologies and processes. These tools should codify any existing methodology and simplify its application in real-world projects. In short, lets give what organizations have planted a chance to grow so it bear  fruits.

Just consider the wide variety of methodologies available today: SCRUM, Extreme Programming and other agile methodologies, MSF, Eclipse Way, RUP, EssentialUP, OpenUP, double-Chocalte-PestasioUP (and other flavor of the day UPs).

This methodology overload has resulted in confusion and  paralysis of many organizations trying to adopt and deploy processes in their software development projects.

As a final note, I would be grateful if methodology theories put their book authorship careers on hold for two years for the the betterment of the end users.

In an earlier post, I mentioned that one my favorite CMMI phrase is “Say what you do; Do what you say; Prove it”. The “prove it” part of this phrase is especially important during the Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A.  SCAMPI A provides maturity rating, and traditionally in preparation for it an organization spends hundreds (in some cases thousand) of tedious hours compiling, verifying and cataloging paper-based compliance evidence.

An integrated application lifecycle management (ALM) system, such as Microsoft VSTS, substantially reduces this burden by digitizing the majority of the required evidence, and making it accessible from a single portal (SharePoint in the case of VSTS). This portal goes beyond paper-based documents. It provides bi-directional traceability and search functionality. Moreover, the generation of the evidence documentation is automated.

In a very interesting case, an organization, utilizing VSTS, was able of to achieve CMMI maturity level 2 in an six months.

As a side note.  I strongly believe that CMMI is not just for the organization who intend to get an official rating.  Any organization, regardless of size, can greatly benefit from CMMI best practices.  These best practices are the result of over a decade work by some of the industries best minds.  They are quantitatively improved and empirically validated.  I feel, this has much more merit than unverified (latest fad) concepts introduced by methodology theorists.

My advice is not to view CMMI not just as a certification mechanism, rather adopt parts of CMMI that are relevant and beneficial to your organization.

Project-specific process tailoring falls within Organizational Process Definition (OPD), a CMMI-DEV level 3 process area. The purpose of OPD is to establish and maintain the overall organization’s processes.  This include definition of processes (based on organization’s process requirements), establishment of organization’s process architecture (how processes relate to each other to best suit the organization’s structure and environments), and definition of tailoring guidelines and procedures. OPD has one specific goal SG 1 Establish Organizational Process Assets, which in turn, has six practices

SP 1.1 Establish Standard Processes

SP 1.2 Establish Lifecycle Model Description

SP 1.3 Establish Tailoring Criteria and Guideline

SP 1.4 Establish the Organization’s Measurement Repository

SP 1.5 Establish the Organization’s Process Asset Library

SP 1.6 Establish Work Environment Standards

In this post, I am only going to get into the details of SP 1.3, but I will talk about other specific practices of this process area in future posts.  Also, I really want to do a post on CMMI level 3 in general.  For me this is the most interesting CMMI level, as it’s so process-focused.

As I have mentioned in my previous post, process tailoring is the process by which organization’s set of standard process are adjusted to better suit a specific development project. In CMMI terminology, organization’s set of standard processes (OSSP) are tailored into a defined process (a suitable process for a project).  More specifically this practice requires that tailoring to start by selecting standard processes–to be tailored–based on defined criteria, adjustments to the selected processes be made based on well defined tailoring guidelines, and defined procedures followed for any deviation from tailoring guidelines.

This may be too formal and demanding for most organizations, but is very beneficial for mature process-centric organizations.   Keep in mind that tools, such as IRIS, automate many aspects of tailoring, such as creations and management of tailoring guidelines and enforcement of the tailoring procedures, hence, substantially reducing the overhead involved.

Many maturity models and quality frameworks’ view of quality assurance involves more than just end product quality. Rather, the underlying philosophy of most of these standards heavly rely on the quality of the processes used in the development of the products.

This is my favorite phrase in CMMI literature. It is what CMMI appraisal follows.

For a process-centric organization modeling its processes using a process modeling tool such as IRIS covers “Say what you do”; enacting the modeled processes during projects covers “Do what you say”; and all the project and process reports and metrics automatically generated by the enactment system more than “Prove it”.

Last Friday Negin, our head of software development, was telling me about a custom software development project that one of her teams had just wrapped up. This is a commercial grade web application, developed for a local customer here in Toronto area. Negin told me that the project was done under four months!

This morning I quickly glanced over the requirements and design documents of the system. It consisted of over 306 UI screens and massive amount of business logic (629 methods, 68,875 lines of code, 44 tables and 287 store procedures).

Negin attributed the rapid development cycle to VSTS and the process that was used. As I am not familiar with the project, I asked her and her team members to provide details of their experiences during this project.

It’s exciting to see VSTS and processes bringing so much tangible benefits to our own development projects.

I talked about “search and selection” aspects of process tailoring in an earlier post. In this post I’ll get into some of the concepts of “process adjustment”, the next step in process tailoring. Once the project manager has selected a process from his/her organization’s standard processes–based on his/her project criteria, he/she then should adjust the selected process to better suit the project.

The nature of adjustment in this context is difficult to define. It varies greatly from organization to organization.

The first issue is the amount of flexibility allowed during adjustment. It’s important that commonality, generality and integrity of the organization’s standard processes are not compromised as they are adjusted for a particular project. One way to achieve this is by “tailoring guidelines”. Tailoring guidelines are heavily supported and promoted by CMMI. They are developed as a part of process creation. So as process modelers define the organization’s standard processes, they also define tailoring guidelines for these processes. This requires a flexible process modeling tool. IRIS, our process modeling tool, supports user definable attributes for all process elements–roles, activities, workproducts–and has in built-in reporting facility. Using these capabilities we have been able to automate customers’ needs by capturing tailoring information during modeling and generating organization specific tailoring guidelines automatically.

Of course there is much more to process adjustment than tailoring guidelines. I will cover other aspects of this topic in future posts.

I highly recommend a white paper titled “Process Tailoring and the Software Capability Maturity Model” by Mark Ginsberg and Lauren Quinn. Although written in 1995, the content of this paper is still very relevant today. The full version of this paper is available for download from SEI (Software Development Institute, Carnegie Mellon University) website. Keep in mind that this is a long paper: 53 pages.

I specially found the coverage of “Tailoring Guidelines” informative. I will get into how tailoring guidelines fit in the overall tailoring process in future posts.