Myths about CMMI, or who needs it and why

    First, about the abbreviation: Capability Maturity Model Integration (CMMI) - a company’s maturity assessment model based on its production, technical and managerial potential. It was developed by the Software Engineering Institute . Details were written about it in habrasta: Model CMMI and How our company received level 3 CMMI .

    Having been “embedded” in CMMI for 5 years now, I often come across requests and opinions regarding this framework, which, in general, can be summarized as follows: “This is certainly good, but impossible in real conditions.” Someone is skeptical from the very beginning, someone is disappointed (first of all, due to excessive expectations). I am neither an “apologist” nor a fan of CMMI, but my immediate job is to maintain CMMI Level 3 compliance. This requires, first of all, a very serious moral effort. In my opinion, this is due to the prevalence of a number of myths about CMMI, which appeared due to logical arguments about the usefulness of the model (which are given in all the "advertising" literature), examples of increasing the efficiency of work in such "monsters" as Boeing,

    In the article I will try to “debunk” some myths, dispel skepticism, and, perhaps, I will be able to 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. To become the Mid-th, that is, to move to the next professional level, he must acquire certain skills, learn some engineering practices. At this level, there will be more confidence in the programmer, and salary, respectively. The same pattern 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's move on to myths that reveal the causes of CMMI resistance and, I hope, point out the possibility of using the model correctly.

    Myth 1: CMMI is applicable only to large companies

    The results of the analysis of data on past (since 2006) evaluations of the CMMI model published by SEI in September 2011 show that 66% of the evaluations were carried out in companies of the “1-100 people” category, while within this category the main subcategories were “25 or less” "And" 26-50 ".

    However, one must understand that pleasure is expensive, so only the company that has this relatively free money can go for an official evaluation. And those who really need it. It is logical to assume that the amount “on CMMI” for large companies will not be as scary as for small ones. But do they need it?

    First of all, you need to understand that CMMI is a management modelproduction / service, it is focused on improving the efficiency of the process. That is, it is needed by 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 turn now to the specifics of the business of relatively large companies in the Ukrainian and, I think, Russian markets. There are organizations (especially characteristic of the domestic outsource) that sell people to the power of a foreign client — an IT organization that manages the work process (we call it Bodyshop), but not solutions(solution), services that satisfy the client’s business goals. By no means do I want to say that companies of the first type are bad, they are just different approaches to doing business. But if we do not control the process, we need to think very carefully whether CMMI will be a cost-effective investment. Most likely, in such a company there simply will not be the opportunity to apply what CMMI requires and recommends. Although, in the educational plan it will not hurt.

    At the same time, small companies that are engaged in the full cycle of providing services to the client, responsible for the process, managing the process of work, should (I use this word intentionally) 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 model versions is adding new lessons, taking into account new trends and realities in the world of software product production.) This is the global Lessons Learnt. Are we so special that this is not relevant for us?

    “Pay attention” can be formally, through official assessment with recording in the SEI register, (more expensive) and informally, with the help of consultants (cheaper) or on your own (even cheaper). However, one must understand that the correct understanding, the seriousness of the relationship and the ROI are directly proportional to the cost (most often).
    Myth 2: CMMI is only a spectacular and effective marketing move

    Everything is simple, given the previous thesis. If your business is pure bodyshop, then for your potential customers the availability of certification does not really matter. Unless, they are looking for people who have already worked in the "system", or buy the whole "system", along with management.

    If a business focuses on selling stand-alone solutions, then the “rated at CMMI level ...” label can really play into the hands, as it is expected that this company can control the process and can provide better quality in less time, respectively, for less money. And the client will have less trouble, do not have to interfere and get nervous. Often, such clients organize tenders, subject to the condition of having officially confirmed compliance with a certain level of maturity according to the CMMI model (as in the one I have already indicatedhabrastatje ). These are IT companies that are looking for subcontractors, and not cheap labor, or organizations that themselves do not produce software (banks, etc.)

    CMMI status is very useful, also if you enter the market with your product.

    While we are talking about the label, about the status that you can brag to customers and colleagues. If after receiving this label, you calmly forget everything for the next 3 years, a smart client will figure you out, do not hesitate. A similar danger awaits those companies that, having evaluated a separate subdivision (for example, an office in one city), declare that the whole company has a certain level of CMMI. Being evaluated is much easier than maintaining that status (or extending skills and process to other departments).

    I’m leading to this: if you really need CMMI for marketing purposes, that is, if your customer expects you to "work on CMMI", try to still 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 are not working correctly with the customer, or you are trying to apply the "rules" too literally, without tayloring for your specific conditions. And freelance customers will probably never be affected by the marketing word CMMI. (Although, I could be wrong.)

    Myth 3: CMMI is bureaucracy and heavy procedures

    The model does not prescribe 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 performed to guarantee the quality of the product and service.

    Here I want to turn again to business models. It is possible to satisfy the client in the sale of labor without CMMI, simply by doing well 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 not managing the process, you may not even know about this bureaucracy.

    But in the case of the full cycle of work on our side, the practices specified in CMMI are simply irreplaceable. At least as a checklist, that is, a very lightweight version . But! In the production process, we must constantly make sure that what we do corresponds to the business needs of the client for this product or service, that we do not deviate from these needs. This requires CMMI. Our business is to figure out how we will do it - heavily and bureaucratically or using the most suitable tools that will facilitate our work and prevent mistakes in the process. CMMI requires a constant exchange of knowledge, learn from their mistakes, and do this through analysis of both the results of the work 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 establish 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 facing) related to bureaucracy, as well as options for optimizing work. These examples illustrate that we are creating the heaviness, not CMMI:
    • CMMI requires work plans, whereby they must be “consolidated”. We created the Project Management Plan (PMP) template, which managers had to write and everyone else read. We have created the Project Planning process, during which a plan is created. As a result, our PMPs were created at the end of the project, and no one ever read them. Nevertheless, all the information that this document should contain is already necessarily somewhere at the beginning of the project: usually in letters, in tools, pictures, etc. The presence of a register of information with links to the sources of this information completely solves the problem of the availability of PMP, that is, it meets the requirements of CMMI, and no bureaucracy.
    • CMMI requires maintaining traceability between the client’s business needs and the final product through all the intermediate steps (specifications, test documentation, etc.). We create or customize the tool — an excel table, bug tracker, or something else, which is essentially a matrix that allows track the transformation of requirements into a product and its elements (Requirements Traceability Matrix).

    The process and tools can be offered to us (or spied on by someone). And if it seems to us heavy and bureaucratic, we must first understand the purpose of the process or document, and then learn to make sure that the appointment is carried out, but in a different way. The purpose and purpose of CMMI practices is very rarely applicable, but the procedures and documents that we use (but this does not depend on CMMI) may not be applicable (and unacceptable).

    Myth 4: CMMI is not applicable in Agile projects.

    There is already a lot of information on this subject, for example Scrum and CMMI - Does it fit together? , at this year's Agileee conference , a report was dedicated to this topic .

    The bottom line is that CMMI is not tied to any project management methodologies, nor to any SDLC, it is tied, as I said, to engineering and management practices. And these practices are the same, both in the waterfall development model and in the iterative ones; in both RUP and Agile methodologies. In the latest version of the model, each section specifically outlines how this practice is applied using Agile methods (the report that I refer to is essentially a retelling of the CMMI book). Note that CMMI says “what” to do, and Agile practitioners answer the “how” question.

    Here, it is probably worth noting that this myth feeds on all kinds of speculation on Agile Manifesto. The manifest uses the word “over” when referring to communications and processes, a 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 close, our company, having burned itself, nevertheless took up the strengthening of the contract component of cooperation.

    Another slippery moment is the transfer of knowledge. Agile proponents explain that knowledge transfer takes place in person and during work. CMMI requires a “Collect Process Related experience”. And the goal here is to repeat the best practices regardless of whether his carrier managed to pass them orally, in the process of work, to his successor or not. Frankly, the organization Knowledge Management suffers from us. And human dependence in success / failure is noticeable.

    NB! Speaking of human independence, I in no way infringe on copyrights, the personal experience of each individual person, I do not question the importance and value of each individual individual, I do not speak about the need for a system in which each person is a screw. It is only about transferring knowledge about mistakes and risks, proven ways to avoid them, about the best practices that can be used from project to project, from team to team (that is, if they have different people ). I would be glad if someone shares their experience in organizing an effective, simple and used knowledge base.

    As a conclusion, I can say that CMMI is aimed not only at successful project implementation (i.e., project managers and team leads need), but also at ensuring business continuity (that is, managers of organizations need it, as in our case with contracts and human dependence) .

    Myth 5: Let's assign someone who will be responsible for CMMI

    Usually, for this, someone who is not very important for the customer is allocated (so as not to distract valuable personnel from the "real" work). In the best case, this someone is an expert in a couple of related fields, is not necessarily familiar with the process approach, and does not always have sufficient authority to demand and control something. It turns out that CMMI and "business", or "work", exist in parallel. The “Responsible” is constantly imposed on everyone else - very, by the way, busy people, including those from production fields unfamiliar to him - with “his CMMI”. It is natural that CMMI causes resistance due to this “amateur theoretician who interferes with productive work, adding unnecessary tasks (which is inconsistent with the client!), Which can only be done after hours.” This situation will always work against CMMI:

    As I mentioned before, CMMI is a software production management model. The higher the level of management that understands the need for the practices required by the model and associates business success with them, the greater the chance that CMMI will be applied. The more these people are professional in our industry and themselves follow the best management practices (all this is in the model: it is applicable both for project management, as well as for managing an organization, department, account¬th), the more chances are that CMMI will be applied effectively.

    In the ISO 9000 series, priority is given to the so-called management commitment (this also exists in CMMI, but not so pronounced). This commitment does not lie in the management’s agreement that “we need a quality management system”, but in its willingness to bet on improving the production process, as the main condition for the growth of our business. When management works in a quality management system, requires the same from its subordinates, this system will be alive, will be improved, and passing assessments at the CMMI level will be the least painful, risky and expensive.

    Bottom line: Who needs CMMI and why?

    In short, we can summarize what CMMI is needed for:
    Company management in order to ensure business continuity;
    • Company management for business development (marketing) subject to the actual application of CMMI practices;
    • Company management to assess the possibility of trust in a sub-contractor;
    • To managers of different levels (including lead-s of teams), as a checklist for early identification of errors and risks, their mitigation and prevention;
    • Managers of different levels, as well as, possibly, technical specialists, 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 a solution, manages the process of satisfying the business needs of the client.
    • At the leadership level at different levels, there is an understanding of which process improvements will lead to which business effect (the stronger the cause-effect relationships and the more specific the expected effect, the more guaranteed success). That is, business and process improvement (CMMI) are inseparable.
    • The specialists who are involved in the implementation of CMMI are high-level professionals and have a wide range of knowledge, both engineering and managerial. Moreover, they must work in a team.
    • The knowledge of the model by specialists in different fields, 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 advisable to know and understand the whole, including process control areas.

    Also popular now: