Myths about CMMI, or who needs it and why
First about the abbreviation: Capability Maturity Model Integration (CMMI) is a model for assessing the maturity of a company, based on its production, technical and management potential. It was developed by the Software Engineering Institute . Details about it were written in habrastya: Model CMMI and How our company received level 3 CMMI .
Having been “embedded” in CMMI for the past 5 years, I often encounter inquiries and judgments regarding this framework, which, in general, can be summarized as follows: “This is of course good, but impossible in real conditions.” Someone is skeptical from the very beginning, someone is disappointed (first of all, because of excessive expectations). I am neither an apologist nor a CMMI fan, but my direct work is to maintain compliance with CMMI Level 3. This requires, above all, a very serious moral effort. This is due, in my opinion, to the prevalence of a number of myths about CMMI, which appeared due to logical arguments about the benefits of the model (which are cited in all the “advertising” literature), examples of increasing the efficiency of work in such “monsters” as “Boeing”, attempts to introduce in domestic companies (after which “nothing has changed” in them), and experience working with Indian companies that position themselves as corresponding to CMMI Level 5. And with a lack of understanding of how and when to use the model to make it useful.
In the article I will try to “debunk” some myths, dispel skepticism, and maybe I can help those who want to use CMMI, but do not know how.
For those who know nothing about CMMI, I usually present it as follows.
Junior programmer has some basic skills. In order to become a Mid, that is, to move to the next professional level, he must acquire certain skills, learn some engineering practices. At this level, and confidence in the programmer will be more, and salary, respectively. The same scheme applies to organizations. The implementation of certain practices at the company level leads to an increase in the so-called maturity level (maturity level), and consequently, trust from customers and partners.
')
Let us turn, perhaps, to the myths that reveal the causes of CMMI resistance and, I hope, point out the possibilities for the correct use of the model.
The results of the analysis of data on past assessments (since 2006) regarding the CMMI model, published by the SEI in September 2011, show that 66% of evaluations were carried out in companies of the category “1-100 people”, while within this category the main subcategories “25 or less "And" 26-50. "
However, one should understand that pleasure is expensive, so only the company that has this relatively free money can go for an official assessment. And those who really need it. It is logical to assume that the sum “on CMMI” for large companies will not be as frightening as for small ones. But do they need it?
First of all, we must understand that CMMI is a production / service management model , it is focused on improving the efficiency of the process. That is, it is necessary for those who manage the work process, making it more effective in terms of meeting the business needs of the client and reducing the cost of production.
Let us now turn to the peculiarities of the business of relatively large companies in the Ukrainian and, I think, Russian markets. There are organizations (especially typical for domestic outsource) that sell people to the power of a foreign client - to an IT organization that manages the work process (we call it Bodyshop), but not solutions (services), services that satisfy the client’s business goals. In no case do I want to say that companies of the first type are bad, they are simply different approaches to doing business. But if we do not manage the process, it is necessary to think very well whether CMMI will be a cost-effective investment of capital. Most likely, in such a company it will simply not be possible to apply what CMMI requires and recommends. Although, in terms of education does not hurt.
At the same time, small companies that are engaged in the full cycle of providing services to the client, being responsible for the process, managing the work process, should (I intentionally use this word) pay attention to CMMI. Why should? Because it is a collection of lessons that a huge number of companies around the world have learned from their mistakes. (By the way, changing the model versions is adding new lessons, taking into account new trends and realities in the world of software production.) This is a global Lessons Learnt. Are we really so special that for us it is not relevant?
“Attention” can be made formally, through official evaluation with entry into the SEI register, (more expensive) and informally, with the help of consultants (cheaper) or independently (even cheaper). However, it should be understood that the correctness of understanding, the seriousness of the relationship and ROI are directly proportional to the cost (most often).
Everything is simple, given the previous thesis. If your business is a pure bodyshop, then for your potential customers the presence of certification does not really matter. Unless, they are looking for such people who have already worked in the “system”, or are buying the “system” as a whole, along with the management.
If a business is focused on selling independent solutions, then the “rated at CMMI level ...” label can really play into the hands, as it is expected that this company can manage the process and can provide better quality in less time, respectively, for less money. And the client will be less hassle, do not have to interfere and be nervous. Often, such clients organize tenders, setting as a condition the presence of an officially confirmed conformity to a certain level of maturity according to the CMMI model (as in the habrastatie already mentioned by me). These are IT companies that are looking for subcontractors, and not cheap labor, or organizations that are not engaged in the production of software (banks, etc.)
CMMI status is very useful, also, in case you enter the market with your product.
While we are talking about the label, about the status, which can boast to customers and colleagues. If after receiving this label, you will calmly forget everything for the next 3 years, a smart client will get to know you, do not hesitate. A similar danger awaits those companies that, having assessed a separate division (for example, an office in one city), declare that the entire company has such a CMMI level. Being evaluated is much easier than maintaining this status (or extending the skills and process to other departments).
What I am leading to is this: if you really need CMMI for marketing purposes, that is, if your customer expects you to “work on CMMI”, try, nevertheless, to apply the practices that are described there.
Of course, there may be objections: what if we are a small business (freelance), we sell a complete solution, we want to work “in the right way”, but “the customer does not give us”? Well, there are two options: either you work incorrectly with the customer, or you try to apply the “rules” too literally, without tayloring for your specific conditions. And freelancing clients will probably never be affected by the marketing word CMMI. (Although, I could be wrong.)
The model does not give instructions on how you should work, it does not say what documents and processes you should have. The model recommends actions (rather than filling out documents) as part of normal engineering practices that must be carried out to ensure the quality of the product and service.
Here I want to again turn to business models. Satisfying a client in the sale of labor can be done without a CMMI, simply by doing a good job in accordance with the process established by the client. By the way, the client process can be very bureaucratic, but since you are doing what you are told, but do not control the process, you may not even be aware of this bureaucracy.
But in the case of the full cycle of work on our side, the practices indicated in CMMI are simply irreplaceable. At least as a checklist, that is a very lightweight option . But! In the production process, we must constantly make sure that what we do corresponds to the business need of the customer for this product or service, that we do not deviate from these needs. This requires CMMI. Our job is to figure out how we will do it - heavy and bureaucratic, or using the most appropriate tools that will facilitate our work and prevent errors in the process. CMMI requires you to constantly share knowledge, learn from your mistakes, and do it through analyzing both the work results and the process. We decide on the level of formality.
From experience, I can see that the level of bureaucracy, formality and heaviness is inversely proportional to the real level of professionalism of the people who set the process. This is not because smart people don't have to write anything down. Rather, due to the optimization of work with documents and data: instead of three documents, you can create one, but build the process so that it will be used by 3 people, or in 3 sub-processes.
I will give a couple of examples that we have encountered (and are faced with) related to bureaucracy, as well as work optimization options. These examples illustrate that we are creating heaviness, not CMMI:
The process and tools can be offered to us (or peeped from someone). And if it seems to us heavy and bureaucratic, we must first understand the purpose of the process or the document, and then learn how to make the appointment be done, but in a different way. The appointment and purpose of the CMMI practitioner is very rarely applied, but the procedures and documents that we use may be inapplicable (and unacceptable) (but this does not depend on CMMI).
There is already a lot of information on this topic, for example Scrum and CMMI - Does it fit together? , at the Agileee conference this year a report was devoted to this topic.
The bottom line is that CMMI is not tied to any project management methodologies, to any SDLC, it is tied, as I have already said, to engineering and management practices. And these practices are the same, both in the waterfall development model and in the iterative ones; both in RUP and in Agile methodologies. In the latest version of the model, each section specifically highlights how this practice is applied using Agile methods (the report to which I refer, in essence, is a retelling of the CMMI book). Please note that CMMI says “what” to do, and Agile practitioners answer the question “how”.
It is probably worth noting here that this myth feeds on all sorts of speculations on Agile Manifesto. The manifesto uses the word “over” when it refers to communications and processes, work product and documentation, etc. “Over”, but not “instead”. From practice (and from Agile Manifesto): despite all the desire to be Agile and work with the customer very well, our company, having burned itself, nevertheless took up the strengthening of the contractual component of cooperation.
Another slippery moment - the transfer of knowledge. Supporters of Agile explain that the transfer of knowledge occurs in person and in the process of work. CMMI requires "Collect Process Related experience". And the goal is to repeat the best practices, whether it was their carrier who managed to pass them orally, in the course of work, to his successor or not. Frankly, the organization Knowledge Management, we suffer. And noticeable human dependence in success / failure.
NB! Speaking about human independence, I do not in any way encroach on copyrights, personal experience of each individual, I do not question the importance and value of each individual individual, not to mention the need for a system in which each person is a cog. We are talking only about the transfer of knowledge about errors and risks, proven ways to avoid them, about best practices that can be used from project to project, from team to team (that is, if they have different people ). I would be happy if someone shares the experience of organizing an effective, simple and used knowledge base.
As a conclusion, I can say that CMMI is aimed not only at the successful implementation of the project (i.e., needed by project managers and lead teams), but also to ensure business continuity (i.e., needed by the heads of organizations, as in our case with contracts and human dependency) .
Usually, for this purpose, someone who is not very important for the customer is distinguished (so as not to distract valuable personnel from the "real" work). At best, this someone is an expert in a couple of related areas, is not necessarily familiar with the process approach, and does not always have enough authority to demand and control something. It turns out that CMMI and "business", or "work", exist in parallel. The “Responsible” is constantly being imposed on everyone else - by the way, by the way, to busy people, including those from unfamiliar areas of production, with “their CMMI”. It’s quite natural that CMMI causes resistance due to this “amateur theoretician who interferes with productive work by adding unnecessary tasks (which is inconsistent with the client!), Which can only be done during off-hours.” This situation will always work against CMMI: it will be implemented for a long time and ineffectively.
As I mentioned earlier, CMMI is a software production management model. The higher the level of management that understands the necessity of the practices required by the model and associates business success with them, the greater the chances that CMMI will be applied. The more these people are professional in our industry and they themselves follow the best management practices (all this is in the model: applicable for project management as well as organization, division, account management), the more chances that CMMI will be used effectively.
In the ISO 9000 series, priority is given to the so-called management commitment (this also exists in CMMI, but not so vividly). This commitment is not in the management's agreement that “we need a quality management system,” but in its readiness to bet on improving the production process, as the main condition for the growth of its business. When management works in a quality management system, it requires the same from its subordinates, this system will be alive, will be improved, and passing the assessment to the CMMI level will be the least painful, risky and expensive.
In short, you can summarize that CMMI is needed:
Company management to ensure business continuity;
CMMI will live up to expectations (and money spent) if:
Having been “embedded” in CMMI for the past 5 years, I often encounter inquiries and judgments regarding this framework, which, in general, can be summarized as follows: “This is of course good, but impossible in real conditions.” Someone is skeptical from the very beginning, someone is disappointed (first of all, because of excessive expectations). I am neither an apologist nor a CMMI fan, but my direct work is to maintain compliance with CMMI Level 3. This requires, above all, a very serious moral effort. This is due, in my opinion, to the prevalence of a number of myths about CMMI, which appeared due to logical arguments about the benefits of the model (which are cited in all the “advertising” literature), examples of increasing the efficiency of work in such “monsters” as “Boeing”, attempts to introduce in domestic companies (after which “nothing has changed” in them), and experience working with Indian companies that position themselves as corresponding to CMMI Level 5. And with a lack of understanding of how and when to use the model to make it useful.
In the article I will try to “debunk” some myths, dispel skepticism, and maybe I can help those who want to use CMMI, but do not know how.
For those who know nothing about CMMI, I usually present it as follows.
Junior programmer has some basic skills. In order to become a Mid, that is, to move to the next professional level, he must acquire certain skills, learn some engineering practices. At this level, and confidence in the programmer will be more, and salary, respectively. The same scheme applies to organizations. The implementation of certain practices at the company level leads to an increase in the so-called maturity level (maturity level), and consequently, trust from customers and partners.
')
Let us turn, perhaps, to the myths that reveal the causes of CMMI resistance and, I hope, point out the possibilities for the correct use of the model.
Myth 1: CMMI is applicable only in large companies.
The results of the analysis of data on past assessments (since 2006) regarding the CMMI model, published by the SEI in September 2011, show that 66% of evaluations were carried out in companies of the category “1-100 people”, while within this category the main subcategories “25 or less "And" 26-50. "
However, one should understand that pleasure is expensive, so only the company that has this relatively free money can go for an official assessment. And those who really need it. It is logical to assume that the sum “on CMMI” for large companies will not be as frightening as for small ones. But do they need it?
First of all, we must understand that CMMI is a production / service management model , it is focused on improving the efficiency of the process. That is, it is necessary for those who manage the work process, making it more effective in terms of meeting the business needs of the client and reducing the cost of production.
Let us now turn to the peculiarities of the business of relatively large companies in the Ukrainian and, I think, Russian markets. There are organizations (especially typical for domestic outsource) that sell people to the power of a foreign client - to an IT organization that manages the work process (we call it Bodyshop), but not solutions (services), services that satisfy the client’s business goals. In no case do I want to say that companies of the first type are bad, they are simply different approaches to doing business. But if we do not manage the process, it is necessary to think very well whether CMMI will be a cost-effective investment of capital. Most likely, in such a company it will simply not be possible to apply what CMMI requires and recommends. Although, in terms of education does not hurt.
At the same time, small companies that are engaged in the full cycle of providing services to the client, being responsible for the process, managing the work process, should (I intentionally use this word) pay attention to CMMI. Why should? Because it is a collection of lessons that a huge number of companies around the world have learned from their mistakes. (By the way, changing the model versions is adding new lessons, taking into account new trends and realities in the world of software production.) This is a global Lessons Learnt. Are we really so special that for us it is not relevant?
“Attention” can be made formally, through official evaluation with entry into the SEI register, (more expensive) and informally, with the help of consultants (cheaper) or independently (even cheaper). However, it should be understood that the correctness of understanding, the seriousness of the relationship and ROI are directly proportional to the cost (most often).
Myth 2: CMMI is only an effective and effective marketing ploy.
Everything is simple, given the previous thesis. If your business is a pure bodyshop, then for your potential customers the presence of certification does not really matter. Unless, they are looking for such people who have already worked in the “system”, or are buying the “system” as a whole, along with the management.
If a business is focused on selling independent solutions, then the “rated at CMMI level ...” label can really play into the hands, as it is expected that this company can manage the process and can provide better quality in less time, respectively, for less money. And the client will be less hassle, do not have to interfere and be nervous. Often, such clients organize tenders, setting as a condition the presence of an officially confirmed conformity to a certain level of maturity according to the CMMI model (as in the habrastatie already mentioned by me). These are IT companies that are looking for subcontractors, and not cheap labor, or organizations that are not engaged in the production of software (banks, etc.)
CMMI status is very useful, also, in case you enter the market with your product.
While we are talking about the label, about the status, which can boast to customers and colleagues. If after receiving this label, you will calmly forget everything for the next 3 years, a smart client will get to know you, do not hesitate. A similar danger awaits those companies that, having assessed a separate division (for example, an office in one city), declare that the entire company has such a CMMI level. Being evaluated is much easier than maintaining this status (or extending the skills and process to other departments).
What I am leading to is this: if you really need CMMI for marketing purposes, that is, if your customer expects you to “work on CMMI”, try, nevertheless, to apply the practices that are described there.
Of course, there may be objections: what if we are a small business (freelance), we sell a complete solution, we want to work “in the right way”, but “the customer does not give us”? Well, there are two options: either you work incorrectly with the customer, or you try to apply the “rules” too literally, without tayloring for your specific conditions. And freelancing clients will probably never be affected by the marketing word CMMI. (Although, I could be wrong.)
Myth 3: CMMI is bureaucracy and ponderous procedures.
The model does not give instructions on how you should work, it does not say what documents and processes you should have. The model recommends actions (rather than filling out documents) as part of normal engineering practices that must be carried out to ensure the quality of the product and service.
Here I want to again turn to business models. Satisfying a client in the sale of labor can be done without a CMMI, simply by doing a good job in accordance with the process established by the client. By the way, the client process can be very bureaucratic, but since you are doing what you are told, but do not control the process, you may not even be aware of this bureaucracy.
But in the case of the full cycle of work on our side, the practices indicated in CMMI are simply irreplaceable. At least as a checklist, that is a very lightweight option . But! In the production process, we must constantly make sure that what we do corresponds to the business need of the customer for this product or service, that we do not deviate from these needs. This requires CMMI. Our job is to figure out how we will do it - heavy and bureaucratic, or using the most appropriate tools that will facilitate our work and prevent errors in the process. CMMI requires you to constantly share knowledge, learn from your mistakes, and do it through analyzing both the work results and the process. We decide on the level of formality.
From experience, I can see that the level of bureaucracy, formality and heaviness is inversely proportional to the real level of professionalism of the people who set the process. This is not because smart people don't have to write anything down. Rather, due to the optimization of work with documents and data: instead of three documents, you can create one, but build the process so that it will be used by 3 people, or in 3 sub-processes.
I will give a couple of examples that we have encountered (and are faced with) related to bureaucracy, as well as work optimization options. These examples illustrate that we are creating heaviness, not CMMI:
- CMMI requires work plans, and they must be “consolidated”. We created a Project Management Plan (PMP) template that managers had to write, and the rest to read. We created the Project Planning process, during which a plan is created. As a result, our PMPs were created by the end of the project, and no one ever read them. However, all the information that this document should contain is necessarily somewhere near the beginning of the project: usually in letters, in tools, pictures, etc. Having a register of information with references to the sources of this information completely solves the problem of having a PMP, that is, satisfies the requirements of CMMI, and no bureaucracy.
- The SMMI requires maintaining traceability between the client’s business needs and the final product through all intermediate steps (specifications, test documentation, etc.). We create or customize a tool — an excel table, a bugtracker, or something else that is essentially a matrix that allows trace the transformation of requirements into a product and its elements (Requirements Traceability Matrix).
The process and tools can be offered to us (or peeped from someone). And if it seems to us heavy and bureaucratic, we must first understand the purpose of the process or the document, and then learn how to make the appointment be done, but in a different way. The appointment and purpose of the CMMI practitioner is very rarely applied, but the procedures and documents that we use may be inapplicable (and unacceptable) (but this does not depend on CMMI).
Myth 4: CMMI is not applicable in Agile projects.
There is already a lot of information on this topic, for example Scrum and CMMI - Does it fit together? , at the Agileee conference this year a report was devoted to this topic.
The bottom line is that CMMI is not tied to any project management methodologies, to any SDLC, it is tied, as I have already said, to engineering and management practices. And these practices are the same, both in the waterfall development model and in the iterative ones; both in RUP and in Agile methodologies. In the latest version of the model, each section specifically highlights how this practice is applied using Agile methods (the report to which I refer, in essence, is a retelling of the CMMI book). Please note that CMMI says “what” to do, and Agile practitioners answer the question “how”.
It is probably worth noting here that this myth feeds on all sorts of speculations on Agile Manifesto. The manifesto uses the word “over” when it refers to communications and processes, work product and documentation, etc. “Over”, but not “instead”. From practice (and from Agile Manifesto): despite all the desire to be Agile and work with the customer very well, our company, having burned itself, nevertheless took up the strengthening of the contractual component of cooperation.
Another slippery moment - the transfer of knowledge. Supporters of Agile explain that the transfer of knowledge occurs in person and in the process of work. CMMI requires "Collect Process Related experience". And the goal is to repeat the best practices, whether it was their carrier who managed to pass them orally, in the course of work, to his successor or not. Frankly, the organization Knowledge Management, we suffer. And noticeable human dependence in success / failure.
NB! Speaking about human independence, I do not in any way encroach on copyrights, personal experience of each individual, I do not question the importance and value of each individual individual, not to mention the need for a system in which each person is a cog. We are talking only about the transfer of knowledge about errors and risks, proven ways to avoid them, about best practices that can be used from project to project, from team to team (that is, if they have different people ). I would be happy if someone shares the experience of organizing an effective, simple and used knowledge base.
As a conclusion, I can say that CMMI is aimed not only at the successful implementation of the project (i.e., needed by project managers and lead teams), but also to ensure business continuity (i.e., needed by the heads of organizations, as in our case with contracts and human dependency) .
Myth 5: Let's assign someone who will be responsible for CMMI
Usually, for this purpose, someone who is not very important for the customer is distinguished (so as not to distract valuable personnel from the "real" work). At best, this someone is an expert in a couple of related areas, is not necessarily familiar with the process approach, and does not always have enough authority to demand and control something. It turns out that CMMI and "business", or "work", exist in parallel. The “Responsible” is constantly being imposed on everyone else - by the way, by the way, to busy people, including those from unfamiliar areas of production, with “their CMMI”. It’s quite natural that CMMI causes resistance due to this “amateur theoretician who interferes with productive work by adding unnecessary tasks (which is inconsistent with the client!), Which can only be done during off-hours.” This situation will always work against CMMI: it will be implemented for a long time and ineffectively.
As I mentioned earlier, CMMI is a software production management model. The higher the level of management that understands the necessity of the practices required by the model and associates business success with them, the greater the chances that CMMI will be applied. The more these people are professional in our industry and they themselves follow the best management practices (all this is in the model: applicable for project management as well as organization, division, account management), the more chances that CMMI will be used effectively.
In the ISO 9000 series, priority is given to the so-called management commitment (this also exists in CMMI, but not so vividly). This commitment is not in the management's agreement that “we need a quality management system,” but in its readiness to bet on improving the production process, as the main condition for the growth of its business. When management works in a quality management system, it requires the same from its subordinates, this system will be alive, will be improved, and passing the assessment to the CMMI level will be the least painful, risky and expensive.
Bottom line: Who needs CMMI and why?
In short, you can summarize that CMMI is needed:
Company management to ensure business continuity;
- Company management for business development (marketing) subject to the actual use of CMMI practices;
- Company management to assess the credibility of the sub-contractor;
- Managers at various levels (including team lead), as a checklist for early identification of errors and risks, their mitigation and prevention;
- Managers of different levels, as well as, possibly, technicians, for professional growth and development during the development and optimization of the process (if you sincerely believe that everything that is written in the model makes sense and is applicable);
CMMI will live up to expectations (and money spent) if:
- The company sells the solution, manages the process of meeting the business needs of the client.
- At the management level of different levels, there is an understanding of what process improvements to which business effect will result (the stronger the cause-effect relationships and the more specific the expected effect, the more guaranteed the success). That is, business and process improvement (CMMI) are inseparable.
- Specialists who implement CMMI are high-level professionals and have a wide range of knowledge, both engineering and managerial. However, they must work in a team.
- Knowledge of the model by specialists in different areas, whether it be a technical specialist or a project manager, should not be limited to only a narrow process area (for example, only technical process areas, or only project management). It is highly desirable to know and understand the whole mosel, including the areas of process control.
Source: https://habr.com/ru/post/131553/
All Articles