Showing posts with label process documentation. Show all posts
Showing posts with label process documentation. Show all posts

Tuesday, August 4, 2009

CMMI Documentation Request

I have read your blog. Can you provide me some documented CMMI processes (Draft)? I would like to learn and implement the process. I have good experience using ISO 9001 for the past 10 years.

There is no such thing as a set of documented CMMI processes that can be provided for a company, though some unscrupulous consultants will try to sell you a set. Rather, there are industry accepted standards for documenting processes, such as ETVX. These process documentation standards are easily available by searching on the internet. The actual processes for REQM , PP, PMC, SAM, MA, PPQA, CM, etc. are a function of the organization’s business and its practices, though there is some commonality across companies and organizations. However, this commonality exists at the CMMI level. The CMMI is a set of guidelines for process improvement. The implementation of these guidelines will differ from organization to organization. The best advice that I can give you is to document all of your current business practices using an industry accepted process documentation standard, avoiding the temptation to improve the process. By simply documenting your existing processes, you will discover opportunities for improvement, but don’t make them at this point. Just document the process as it is currently practiced. Once you have all of your processes documented, then compare the results to the CMMI, add the missing practices, and address any improvement opportunities. Then you will have a set of processes that your employees will have ownership of and will also comply with the CMMI.

Friday, April 10, 2009

Requesting Processes and Assets

I have read your CMMI blog. Can I have some draft CMMI process documentation? I would like to learn and implement the process.

There is no such thing as a set of documented CMMI processes that can be provided for a company, though some unscrupulous consultants will try to sell you a set. Rather, there are industry accepted standards for documenting processes, such as ETVX. These process documentation standards are easily available by searching on the internet. The actual processes for REQM , PP, PMC, SAM, MA, PPQA, CM, etc. are a function of the organization’s business and its practices, though there is some commonality across companies and organizations. However, this commonality exists at the CMMI level. The CMMI is a set of guidelines for process improvement. The implementation of these guidelines will differ from organization to organization. The best advice that I can give you is to document all of your current business practices using an industry accepted process documentation standard, avoiding the temptation to improve the process. By simply documenting your existing processes, you will discover opportunities for improvement, but don’t make them at this point. Just document the process as it is currently practiced. Once you have all of your processes documented, then compare the results to the CMMI, add the missing practices, and address any improvement opportunities. Then you will have a set of processes that your employees will have ownership of and will also comply with the CMMI.

And, if you are interested in learning more about the CMMI, take the SEI-licensed Introduction to CMMI class from an SEI-authorized instructor.

Tuesday, February 24, 2009

Maturity Level 2 Requirements

Does achieving Maturity Level 2 (ML 2) require that all the processes for the ML 2 Process Areas be developed and documented? Can we achieve ML2 if we have artifacts for the practices but not the documented processes?

The short answer is no. You won't meet Generic Practice (GP) 2.2 without documented processes.

When you read the definition of GP 2.2 Establish and maintain the plan for performing the process, the first item in the bulleted list is process description and the second sub-practice is define and document the process description. If the process isn’t documented, then you cannot perform GP 2.9 Objectively evaluate adherence of the process against its process description, standards, and procedures, and address noncompliance (emphasis added). The CMMI glossary defines Process Description as a documented expression of a set of activities performed to achieve a given purpose that provides an operational definition of the major components of a process (emphasis added). And ML 2 is all about institutionalizing each Process Area as a managed process, which embodies all 10 GPs. So I don’t see how it is possible NOT to document your processes and yet expect to be ML 2. Planning the use of an unwritten tribal process is still ML 1, though better than being completely ad hoc in your approach.

Thursday, May 15, 2008

Process Documentation

There are two basic audiences for process documentation:
  1. Process Engineers (those who define and document the processes) and
  2. Practitioners (those who have to follow the processes).
The process engineers are very interested in the overall process architecture, inputs/outputs, interfaces, etc. In contrast, the practitioners simply want to know exactly what they have to do in order to get their jobs done. When you read the purpose of Organizational Process Description (OPD), one of the key messages is establishing and maintaining a USABLE set of processes and process assets. Therefore, in order for your processes and process assets to be usable by the practitioners, it doesn’t help if you provide them all of the process architecture, inputs/outputs, interfaces, etc. that the process engineers need and want. The simplest approach that I have seen for the practitioners is to provide a “swim lane” process flow chart. Then it is very easy for the practitioner to see where they fit into the process. Also providing good, as well as bad, examples of how a template or checklist should be filled out is also a good idea.

But keep in mind, that an approach that works in one organization for achieving “buy-in” may not work in another. You really need to work with the organization and jointly determine the best method for the organization. If most of the practitioners, for example, do not relate to visual process flows, then the “swim lane” approach may not work.