Process Improvement Programs - What Methodology to Choose

It is time to continue our series of articles on Process Improvement Programs. In the first episode we have talked about Process Improvement Programs - When Are You in Need of One?. Continuing from the brief introduction, I will share an overview on what is available out there in terms of Process Improvement models, and in what kind of scenarios they work best.


CMMI (Capability Maturity Model Integrated)

CMMI addresses three areas of improvement models: development, services, acquisitions. Let’s take them one by one:

CMMI-Acq (Acquisitions) is aimed at organizations that mainly acquire software from external suppliers, who need good processes in place to ensure a certain level of quality. Quality here means predictability, cost, scope and time that you get in return for the money you invested in software.

CMMI-Dev (Development) is for when your main line of business is development (software, systems or hardware). Just like other CMMI models, CMMI-Dev will offer a gradual improvement framework for “what" you need to do in different areas. Gradual means that it starts from level 1 - Initial, up to 5 - Optimizing - where the improvement is continual (details to follow in a future episode of this series, on CMMI).
CMMI-Dev is actually a no-brainer framework for any organization delivering systems, software or hardware for the US Government; the framework itself was developed starting from the quality problems the US Department of Defense used to have with its suppliers. The initial version was developed in collaboration with the US Department of Defense by the Carnegie Mellon Software Engineering Institute. Over time it has become a requirement for most of the work the US government contracts.

If the organization is in the services business, then CMMI-Svc (Services) is the framework to follow to improve processes.

At their core, these three improvement models, contain the same set of process areas, which are standard for all. However, there is specific content embedded in each of them, so that they are better adapted to the specific needs of managing services vs. making software development vs. making software acquisitions.

Dilbert.com

If you want to learn more, check out these great online resources: wibas CMMI Browser & Carnegie Mellon - Software Engineering Institute.

Agile

A few good short sentences to describe the Agile approach (source) would be:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

So Agile is worth considering if you are working in software development - as it focuses on requirements and solutions evolving through collaboration between self-organizing, cross-functional teams. This, in contrast with the more traditional, “heavy weight“ methodologies like the Waterfall model or others that use heavily regulated phases. The focus is on flexibility and delivering the end product (code) as it becomes available, in iterations rather than phases.

When should this not be chosen? Well... when you’re an organization that buys software, then - you don’t really care about how that’s done as long as you get a good end-product.

If you want to learn more, check out the Agile Alliance: Resources.

Six Sigma

This really focuses on improving the quality of process outputs, by identifying and eliminating causes of defects. It has started in the manufacturing area and it was patented by Motorola. Later, it expanded to any process output and the main focus is on reducing process variance as much as possible.

Six Sigma is not a great fit in processes where you can’t actually have a hard measure on each process output. One example would be improving the training processes in your organization - you can surely say you want a 4.5/5 rating from your trainees, but that’s rather subjective. :)

This model is all about using statistics to understand what happened in the past and improve your planning for the future, so it’s a better fit in areas like code writing or manufacturing. Research & Development or Innovation (of any kind) are also areas I wouldn’t say it is a good fit, since it is mostly about looking at the past, fixing existing processes and not really thinking of a new, creative way to achieve even better results.

A good knowledge resource for a beginner in Six Sigma is the following: New to Lean Six Sigma.

ITIL (Information Technology Infrastructure Library)

ITIL is the way to go if you’re in IT operations. If your main areas of concern are capacity and service levels, then this definitely is the framework to follow. It covers software development in the release management area, from an operational perspective. It does not focus on the initial, big development effort, but rather on planning and deploying successive releases with minimal disruptions to the existing environment while, at the same time, meeting changing expectations from the customer.

If you want to know more about ITIL, Wikipedia turns out to be a great resource.

Conclusion

There are other process improvement models available. However, in this article I chose to focus mostly on those that have higher changes of getting applied in the IT world. If you have any questions about them, don’t hesitate to check the resources referenced in this article or to simply leave a comment.

Related content:

Process Improvement Programs - When Are You in Need of One?
Measuring Projects and Change Outcomes
Bridging the divide: project and change managers in business

Comments

Cool! Finally I waited for your post again!

- strep throat symptoms

Thanks! glad this is interesting to you and please let me know if there's any specifics you'd need more details on- so that - if I know about it :) - I can cover it in a future feature.

- nice2 - sales1