You need certifying...

You hear the cry all too often. ″Our employees are our biggest asset″ This is usually issued as a proud boast intended to indicate the high level of ability within the braggart′s organisation.

We are meant to infer from this that the high levels of individual skill are, in some way, due to good management on his part and his organisation is one worthy of the highest esteem.

But there is a lie here! What the boaster is really saying is his company relies heavily on individual knowledge and skills because they have not been able to figure out a way of capturing tacit knowledge, making it explicit and available to everyone. Results in his organisation depend heavily on individual effort and any success they have has nothing to do with good management at all.

Most of us in software development have probably been there too. This is the code-and-fix organisation where everyone is responsible for their own section of code, where knowledge exists in silos and is jealously guarded.

As far as CMMI appraisal is concerned this is level one, the Initial Level. This level is sometimes known as the chaotic level because it′s certainly not process-driven in any way.

Now I know that I′m always promoting agile software development techniques and the first line of the agile manifesto says, ″people over process″ but even I recognise dependence on individuals is not healthy for any organisation. You need at least some process to capture knowledge and avoid the ′truck′ problem: i.e. if Joe walks under a truck, there is no-one else who can understand the flurblewangling algorithm. What do we do now?

On the other hand, I picked up one of the trade weeklies a couple of weeks ago and read an article in which the head of a large recruitment agency was extolling the virtues of CMMI accreditation. He fervently cited the burgeoning Indian software industry as an example of how such accreditation brings success.

He seemed to believe level five CMMI certification was such a good thing every software company should be aiming for it, as it would necessarily make them better companies. As far as he was concerned, the highest level of CMMI certification cured all known ills.

Having mentioned the two extremes of CMMI certification, we should maybe look at what the CMM/CMMI is and what you need to do to get from one level to another.

CMM, or more correctly the software-CMM (SW- CMM), is the software Capability Maturity Model. The Software Engineering Institute (SEI) based at Carnegie Mellon University in America developed it in 1991 after collating the results of a questionnaire they had issued on software best practices. Essentially, it is a list of key practices that need to be performed by any company developing software.

The practices are in order of importance, the more of them you do the higher your level of capability and maturity. You need to progress through each level in turn before going on to the next.

Unfortunately, shortly afterwards a plethora of CMMs started springing up for virtually everything, the people CMM (P-CMM), the systems security engineering CMM (SSE-CMM), the Software Acquisition CMM (SA-CMM) and so on. In August 2000, the SEI decided to publish a version of the CMM that was applicable across the board, the integrated CMM or CMMI. The SEI has promised to support the old SW-CMM until the end of 2005.

We′ve already said that level one is the Initial Level and this is where everyone starts, it′s the same as being uncertified. The next level up is the Managed Level and requires that requirements management is in place, your processes are planned and their performance is measured and controlled. The measurements and control at this level should also give management visibility of project status. It will come as absolutely no surprise to anyone that quality assurance, or rather the lack of it, is cited as the most frequent cause of certification failure at this level.

The next level after that, level 3, entails defining your processes so that they can be consistently applied, reused and tailored when necessary. The major differences between this and the previous level are the amount of standardisation in your processes and the detail in their descriptions. This is the Defined Level.

Level four is Quantitatively Measured. At this level the company is able to establish quantitative objectives for performance and use them as assessment criteria for its processes. Statistical analysis of past performance is used for decision-making. They are able to differentiate between special and common causes of process variation and deal with special causes appropriately.

The very highest level is the Optimising Level, so called because the organisation understands common causes of variation in its performance and has in place practices for continuous improvement, or optimisation, of its processes. All processes within the organisation are targets for improvement activities.

So there are five levels, each demanding a higher set of demonstrable competencies with an audit required before you can go on to the next. It takes a fair amount of time, effort and resources to get from level one to level five and I′ve seen estimates from five years for the whole journey to two years for each stage.

Cost estimates range from $1,350 per member of staff per stage, to $1.2M to take the whole company all the way to level 5. This is a large enough investment for even the largest of companies, so this might be an opportune moment to look at what the benefits actually are. Why would you want to be certified?

The first and simplest reason is necessity. There are institutions and organisations that will only deal with CMMI certified organisations. If you need to do business with them, you need the certification. It′s as simple as that. Thankfully, I′m only aware of commercial requirements for level three certification.

The second and probably most common reason, is marketing. Having the highest known quality certification available is bound to impress your customers, isn′t it! There seem to be plenty of companies claiming to be officially certified by the SEI at Level 5 so you′d think there must be some value in it!

However, a company could state that the assessment has been done at that level, without actually pointing out which criteria have been assessed and satisfied, therefore the overall CMMI assessment of the organisation could be at a much lower level. Perish the thought that anyone would actually do this!

We can only trust that all those claiming SEI certification do indeed possess it. Interestingly the SEI′s website has this to say about certification, ″The terms SEI certified and CMM certification are simply incorrect since there is no such thing. The SEI does not certify organisations. The SEI only licenses and authorises lead appraisers to conduct appraisals. Neither the SEI nor any other organisation is a ″certifying authority″ of the results from an appraisal.″

It goes on to say, ″The main intended goal and purpose of the models and appraisal methods developed by the SEI is for self-improvement. The outcome, which is entirely dependent on the organisation that follows these practices, is to raise the level of quality of the products developed with a better ability to predict the time and budget needed to develop the product.″

Since there are only ever commercial reasons to get to level three, it′s nice to know that there are many software companies so hooked on self-improvement that they′re willing to make the extra effort to get to level five.

Level five may well be the highest you can be appraised at but getting there is not necessarily the good thing it might seem to be. I had the good fortune to be at the EuroSP3 conference last year and attended a presentation on the role of entropy in deciding your appropriate level of process improvement. The presenters explained that most process improvement models are based on standardisation and reducing the amount of variation within the system. This standardisation has the effect of reducing the flexibility of an organisation and the number of possible states it can have and forces a preference for some states over others.

Their research claimed that differences between the rate of change in the environment and within the organisation strain profitability. Therefore, if the organisation exists in an environment with a high rate of change (and who doesn′t nowadays) it needs to have a high internal rate of change too.

The ultimate conclusion is that high levels of process improvement are inappropriate in volatile industry sectors. Which makes a bit of a mockery of the exhortations for everybody to achieve CMMI level five.

As a manager, the people in your organisation should be the most important thing to you but the most valuable thing your organisation has is the knowledge of how it provides value to its customers. That′s what creates the competitive difference between organisations.

If that knowledge is stored in individuals, where will you be when they leave, especially if they join a competitor? Having knowledge captured in processes makes this an unlikely event but the processes need to be examined and updated continually so they can evolve and adapt to changes in the rest of the world.

This can only be done by people and is why the agile manifesto claims that people are more important than process. If the process was more important, ordinary people wouldn′t be allowed to change it.

As for whether you should have your processes certified, this is entirely up to you. At least there is a chance they will be examined occasionally, which is better than never at all. Crucially, you should determine which level of process improvement is most appropriate for your organisation and industry sector rather than opting blindly for the highest available.

  • CMMI: Guidelines for Process Integration and Product Improvement, Chrissis, Konrad & Shrum, Addison Wesley, 2003.
  • The Entropy Constraint in Process Maturity, Paul Siemons and Frans van Veen, EuroSP3 December 2004.
  • Software Engineering Information Repository (SEIR)
  • Process Maturity Profile, Software Engineering Institute, April 2003.

First published in Application Development Advisor Mar/Apr 2005