Over the last 10 months, Armedia engaged in a committed effort to achieve a CMMI Maturity Level 3 rating.  While it is unusual to go directly for a ML3 rating from scratch, it was an additional challenge for a small business to do the same.  Luckily for us, Armedia has always had a process-driven approach, we just needed to solidify those processes and institutionalize them across projects.  We are happy to report after those 10 months, SEI has granted us a ML3 rating, and over the next few months I’ll be writing a series of blogs about some of the challenges, opportunities, and lessons learned that the appraisal process presented to us in an effort to help others out there who are trying to do the same.

For my first blog in the series, I wanted to talk about one of the opportunities presented by the CMMI appraisal process that was a surprise to me – the flexibility of the model.

Some background information – over my last few years in the IT industry, the idea of implementing the CMMI model has been tossed around at different projects and everyone said the same thing, “we’re going to be overcome by documentation, there goes our productivity…” or more bluntly (and most often from developers) “I’m not going to write down every little thing I do.” So frankly, I was not terribly excited that my new task at Armedia was to help us get our ML3 rating and I was going to burden everyone in the company with process and documentation.

I was new to Armedia at the time and spent a few weeks just going through our document repository and learning how our projects were run.  So when it came time to delve into the model, SEI provides suggested documentation that meets each practice, I combed through our document repository and sometimes came up empty for the documents they suggested, but I often found myself saying “I know we do this…it just doesn’t look like that.”  After consulting with our partner in the appraisal process, I realized that documents and artifacts are allowed to look a little different than what you might expect from reading the model.  As a small business, this realization becomes crucial because you often don’t have the time or resources to meet these practices on a grandiose scale like some of the large systems integrators.

I think the most telling example is how we decided to conduct our measurement and analysis (MA) – the MA Process Area and GP3.2 for those of you keeping score at home.  We don’t have a need (or the resources) to collect massive amounts of data on every project we do.  However, as long as you tie your goals and business objectives within your process improvement plan to the measurements you do collect, analyze that data and make adjustments based on it, you are still meeting the intent of the model.  The good news is that you can always adjust the measurements you take, adding new ones as needed and disposing of those that aren’t providing any useful information to the organization.  For us, since one of our primary objectives was to ensure that processes were being distributed throughout projects, we focused on using the process audits to provide us with our measurements.

Therefore, every time we checked whether the project had followed all the processes, all the non-compliance issues were logged as part of the audit and counted and assessed to provide data for our measurement and analysis reporting.  An added bonus – because we audit every process area, we were able to take measurements on each process area without inventing unique measurements for every process area.  It was also useful to know which processes were the most non-compliant across projects so we could take a closer look at those and see if the process itself was meeting our needs.  While we still collected other data, approaching the MA process in a somewhat unorthodox way allowed us to spend a little less time on data collection, meet the model AND learn how we were doing on rolling out processes organization-wide which was of immense value to the organization.