Capability Maturity Model Integration (CMMI) is used by many businesses in an effort to improve their internal processes and, particularly in government contracting, to become eligible for contracts that require appraisal at a certain CMMI level. CMMI procedures, while beneficial, are often poorly implemented by small and mid-sized companies and require a disproportionate amount of time and effort on the part of middle-managers filling out duplicative paperwork. Poorly implemented CMMI policies result in managers taking shortcuts, undermining the otherwise positive benefits of CMMI and putting companies at risk of failing CMMI appraisal audits. There are ten simple steps that an organization—whether CMMI appraised or seeking such appraisal—can follow to make CMMI less painful and more effective.
1. Eliminate duplication and redundancy.
Many CMMI implementations require the same information be recorded in multiple places. For example, a company might have ‘budget measures’ and ‘labor measures’ documents that are simply full of information already available in that company’s auto-generated financial documents and invoices. Likewise, some CMMI implementations require separate capturing of ‘schedule measures’, status reports, and deliverables documents that contain similar or identical data. Project plans are also often broken out into many separate documents, when many projects—especially smaller ones—can cover all CMMI requirements in a single set of procedures.
CMMI guidelines require that companies record all of this information, but does not say companies need to pull them all into a complicated, duplicative series of spreadsheets and documents. As long as a company has documented in its company-wide procedures where all the data is to be recorded, there’s no need to have many separate, manually-created documents to do it. The vast majority of the CMMI-required information can be recorded in financial documents and invoices (usually already created for other purposes), one or two simple monthly reports, and one or two project plan documents for each task.
2. Create an alternate CMMI implementation for non-development tasks.
CMMI, by its nature, is oriented toward software/system development. Many companies’ CMMI plans and measures are overly complex, but at least apply logically to development tasks. They do not always apply so logically to non-development (e.g., service and maintenance) tasks. Because of their different nature, service and maintenance tasks do not always have a software engineering methodology, specified deliverables, clear risks to meeting those non-existent specified deliverables, decision analyses, etc., that CMMI requires be documented.
The solution is simple. In addition to a Software/System Development Task CMMI Procedure, companies should develop an alternate Service and Maintenance Task CMMI Procedure and clear policies for when each CMMI implementation should be used. Companies that try to force non-development tasks into the same cookie-cutter as development tasks end up with documents full of, essentially, a bunch of ‘Not Applicables’. By tailoring procedures and documents to each of the two main task types, this will be less likely to occur.
3. Accept ‘Not Applicable’ as a valid answer, when appropriate.
As long as companies continue trying to pigeonhole non-development tasks into a development-oriented CMMI cookie cutter, ‘Not Applicable’ (with appropriate explanation) will need to suffice as an answer in many reporting documents. If a task does not have a development methodology, for example, then its development methodology is correctly listed as ‘N/A’.
While these situations will be less likely once companies have created an alternate non-development CMMI implementation (#2), it will still happen from time to time. Auditors will likely prefer ‘N/A’ with a valid explanation to a false or made-up answer.
4. Automate the creation of most periodic reporting documents.
CMMI, usually implemented in technology firms, is a perfect place to leverage technology expertise to improve internal processes. Much required reporting documentation can be automatically generated from financial/time-tracking systems, bug-trackers, or other technologies already being utilized. This kind of automation should be used to create most periodic CMMI reporting documents.
Automation will never eliminate manual recording of some tracking information or the manual creation of project plans—nor should it—but could greatly alleviate the unnecessary burden on middle-managers of preparing seemingly-endless monthly CMMI documents.
5. Have document originators enter their own documents in the document repository.
Some companies make middle-managers the ‘gatekeepers’ of all reporting documents that go into the CMMI document repository. What sense does it make for the accounting/invoicing office to generate financial documents and invoices, send them to the project managers, and then require the project managers (or their designees) to enter those documents—unchanged—into the document repository?
The accounting/invoicing office should be responsible for entering their own documents into the document repository, as should any other CMMI document originators throughout the organization. This would slightly increase the document originators’ workload, but would additionally alleviate unnecessary CMMI workload on middle-managers.
6. Unify CMMI, ISO 9001:2000, and other certification-related policies and procedures.
CMMI appraisals, ISO 9001:2000, and other process improvement certifications can be very beneficial to an organization, however—thanks to numerous similarities and overlaps between these methodologies—there is no need to maintain separate sets of company-wide or project-specific documents. CMMI and ISO methodologies are not mutually exclusive, and thus the requirements of both can be met through a single set of clear, comprehensive policies and procedures.
By maintaining constant compliance with both certifications through a single policy and reporting structure, companies would reduce or eliminate stressful pre-audit scrambles and be more prepared to seek additional certifications in the future.
7. Establish stable, rarely-changing documentation requirements.
Many middle-managers can relate with having dutifully maintained their CMMI reporting data in the document repository, only to be informed by their compliance manager—usually at an inopportune time—that a new requirement has been established or, worse yet, that what they’ve been doing for the last two years never met the requirements in the first place.
This should not happen. Companies must establish documentation requirements (preferably taking these ten improvement requests into consideration) and set them in stone. Things change—companies seek new certifications, find deficiencies, and improve—but their procedures should not change on a daily or even monthly basis. Most importantly, rare changes to procedures should be announced well ahead of time so middle-managers have time to adjust their reporting before new rules take effect.
8. Clearly communicate all documentation requirements.
Once stable documentation requirements are established, duplication is eliminated, and automation is increased, the remaining manual documentation requirements must be clearly and concisely communicated to all middle-managers. Cheat sheets, bullet lists, and informal email reminders are par-for-the-course in many companies when it comes to time-sheet and other policies, so why not for CMMI policies as well? Managers who are aware of and fully understand simplified CMMI reporting requirements will be much more likely to ensure companies remain in constant compliance. Again, this would help to eliminate stressful pre-audit scrambles.
9. Eliminate last-minute, rush requests for updated documentation.
It is the responsibility of a company’s compliance managers to periodically review the compliance status of all projects and, when non-conformities are identified, communicate with the project managers. Managers must be provided sufficient time to bring their task into compliance without adversely affecting their actual, ongoing task performance.
As mentioned before (#7), many middle-managers have been informed—usually at an inopportune time—that they need to update their CMMI information in short order, even though they have been dutifully trying to keep their documentation current. When an audit is upon a company, it is too late to request immediate documentation updates from project managers.
10. Establish good, non-obstructionist procedures . . . then FOLLOW THEM!
Once a company has established solid CMMI policies and procedures, everybody in the organization must follow them consistently. It is an open secret in many organizations that, largely due to their confusing CMMI implementation, employees follow the requirements reluctantly and complete the documentation haphazardly. This is especially true on non-development tasks, but even some development projects in CMMI-appraised companies loosely comply—if at all—with their existing policies.
This problem will largely solve itself if the preceding nine recommendations are implemented, as following CMMI policies and procedures will no longer be an inefficient, time-consuming, project-interrupting prospect for middle-managers. Reasonably crafted procedures more easily earn buy-in from those who are asked to follow them. But the CMMI process will still require continual oversight from company compliance managers to ensure that the requirements are being met, and non-conformities must be identified and remedied early.
‘10 Steps to Less Painful CMMI Procedures’ is licensed under a Creative Commons Attribution 4.0 International License. This means that you may make copies without limitation—and even modify the content—so long as you attribute the original work to me.