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.

CMMI-SVC vs. CMMI-DEV

I have some questions about the CMMI-SVC. As I understand it, the CMMI-SVC is scheduled to be released in March. My company performs IT systems maintenance by adapting the CMMI-DEV to process improvement and conducting appraisals. Of course the CMMI-DEV is good for IT system developement organizations. But I want to know which CMMI constellation, the CMMI-DEV or CMMI-SVC, is a better fit for IT system maintenance organizations. In our case, IT system maintenance provides IT service and maintenance at the same time.

What is the logical basis to switch constellations from CMMI-DEV to CMMI-SVC, especially if the CMMI-SVC is more adequate for IT system maintenance organization?

Also I am now confused about the CMMI-DEV focus. It is only focusing on System development organizations and not System maintenance organizations with the release of the CMMI-SVC?

Some people in my organiztion now think that we have been using the wrong CMMI constellation for our IT maintenance organizations.

Yes, you are correct, the CMMI for Services will be released in March, at the same time as the 2009 SEPG Conference. I think that many maintenance organizations have the same questions and problems with the CMMI-DEV.

The problems arise with the engineering Process Areas (PAs) Requirements Development (RD), Technical Solution (TS), Product Integration (PI), Verification (VER), and Validation (VAL), especially TS and PI. In a maintenance environment, there are not very many opportunities for new development and Technical Solution. The only time that occurs is when there are major changes or updates to the existing product. Then it makes sense to perform the engineering PAs. But the majority of the time the organization is fixing defects, basically delivering a maintenance service. In this situation, it may make more sense to use the CMMI-SVC and its PAs Capacity and Availability Management (CAM), Incident Resolution and Prevention (IRP), Service Continuity (SC), Service Delivery (SD), Service System Development (SSD), Service System Transition (SST), and Strategic Service Management (SSM). It is also possible to blend constellations CMMI-DEV and CMMI-SVC to address both software development and software maintenance.

It is a bit difficult to provide the proper guidance and advice regarding which constellation is the best fit without knowing more information about the specific organization. But in my opinion, I would suggest that if there is very little to no new development work being done by the projects and the organization, then the CMMI-SVC should be examined to see if it provides a better fit for the organization. Being appraised to the CMMI-SVC or CMMI-ACQ is just as prestigious as being appraised to the CMMI-DEV as 16 of the PAs are shared by all three constellations.

And as a final point, there in no change in the focus of the CMMI-DEV with the release of the CMMI-SVC. The CMMI-DEV still applies to the same situations as it always has.

Elicitation vs. Specification

Could you please help me to understand the difference between Requirements Elicitation and Requirements Specification and how they complete each other?

Simply put, Requirements Elicitation is the act of gathering requirements from users, customers, etc. Requirements Specification can either be an activity or the document itself. Requirements Specification is the act of documenting the requirements, which can be in a document called a Requirements Specification.

Appraisal Team Size Redux

For a continuous appraisal of lets say 1 to 2 PAs, does the minimum 4 ATM for SCAMPI A still apply? Seems unreasonable to me. The MDD does not appear to address any tailoring option on this for continuous appraisals.

The SCAMPI Method Description Document (MDD) is clear that the minimum appraisal team size is 4 people. You raise an interesting point. Forgetting the team size for the moment, why would an organization go through the expense of a SCAMPI A just for one or two Process Areas? To me that just doesn’t appear to be a good use of the organization’s money. Seems to me that the organization would be better served by a Continuous SCAMPI A evaluating 4 or more PAs that would provide a better indication to the organization. Now you may want to perform a Class C or Class B on one or two PAs. That makes sense and there are no team size limitations on Bs and Cs. In fact, the Lead Appraiser could be the only person on the team then.

Software Productivity Resources

In today's economic scenario, everyone in my organization is talking about "productivity improvement" but no one has a clue how to measure it. Different people percieve productivity in their own way. As per the metrics definition it is "size of work product/ effort spent", while in my experience I have rarely seen organizations measuring size in Function Points (FP) or Source Lines of Code (SLOC) very accurately. Measuring size itself is a distant reality.

Could you share some of your thoughts or ideas or resources on "improving software productivity" or "measuring developers productivity" in simple terms?

The first thing that you have to do is define what productivity improvement means for your organization. As you have stated, everyone has a different definition. So by asking for help you will receive additional definitions to what you have already encountered in your organization, and these answers may be as unsatisfactory as what you have already discussed internally. Instead I recommend that you hold a meeting with your management team and come to consensus on what productivity means for your organization. What does management care about?

What I am suggesting that you do is perform Measurement and Analysis SP 1.1 Establish and maintain measurement objectives that are derived from identified information needs and objectives.

Again, what is your management concerned about? Do they want to reduce time to market? Do they want to reduce total lifecycle cost? Do they want to improve product quality? etc. The answers to these and similar questions will provide you with the information you need to determine what productivity improvement means for your company.

And if you are still struggling with this concept, I suggest that you hire a CMMI consultant with a Measurement and Analysis background who can help you and your organization define the specific measures you need for your company.

Appraisal Team Size

We are a small IT company (40 members) that wants to get Maturity Level 3 as a first effort. We are thinking about forming an appraisal team (for a SCAMPI A appraisal) composed of 3 internal members and 1 external team leader. Is there any problem or recommendation about this approach?

The SCAMPI method requires a minimum appraisal team size of four people including the Lead Appraiser. And it is a good practice to have at least two appraisal team members be from the organization being appraised. So having three internal team members plus the Lead Appraiser meets the minimum SCAMPI requirements for an appraisal. From my experience, I would suggest adding some external team members. Having additional people will ease the burden on the team for evaluating the evidence and will also provide some outside perspectives on your processes. Your Lead Appraiser should be able to suggest the proper team size and recommend some external team members. And many times, external team members are willing to participate for free since they may be looking for appraisals in order to maintain their credentials, etc.

Interpreting OPD SP 1.6

While discussing Organizational Process Definition (OPD) Specific Practice (SP) 1.6, we arrived at the following two interpretations for a software development organization:

OPD SP 1.6 "Establish and Maintain Work Environment Standards"

Interpretation 1: Work Environment Standard refers to the environment (Hardware, Software) required by a project for its successful completion. So, if a project mentions its resource requirements (including hardware, software, human resources, trainings, skill set, etc) then it will meet the intent of this practice.

Interpretation 2: We need to explicitly document the "Work Environment Standards of the Organization" for this practice, which includes:

• Standard Hardware & Software on a machine
• Standard Hardware & Software configurations on a machine
• Standard LAN Speed required
• Stanadard Internet Speed required
• Standard Temprature
• Standard Dress Code
• Emergency Numbers
• Fire alarms
• Smoke detectors

Which interpretation is correct?

Reading your question gives me the uneasy feeling that you may have not read the informative material for OPD SP 1.6. The model clearly states that “work environment standards allow the organization and projects to benefit from common tools, training, and maintenance, as well as cost savings from volume purchases.” And then there is a list of 6 examples of work environment standards, which I will repeat here:

• Procedures for operation, safety, and security of the work environment
• Standard workstation hardware and software
• Standard application software and tailoring guidelines for it
• Standard production and calibration equipment
• Process for requesting and approving tailoring or waivers

Given this informative material, it is very clear in my mind what constitutes a work environment standard. I would say that your second interpretation is more correct than your first interpretation, though the correct answer is probably a combination of the two. However, I would question why you would include standard temperature, dress code, emergency numbers, fire alarms, and smoke detectors in your work environment standards for software development and maintenance, unless these are safety standards. Do these items affect how you develop software? The work environment standards I typically encounter at a client site include standards for a workstation (including desk, table, chair, computer), a standard software load (including MS Office), standards for the conference rooms (including wired or wireless connections, laptop or desktop, LCD projector, screen, whiteboard, markers, etc.), standards for the development environment, standards for the test environment, and standards for the production environment.

CMMI Implementation

I recently joined a company where there is no process and management recruited me to implement the CMMI. The organization has different business units. Though everyone sits together, they work very differently. I conducted a Gap analysis based on the CMMI Level 2 processes and here are the findings:

1. Project Planning & PMC -- they create project plans and they have the regular project team meetings and they share the minutes. Each team has their own format and templates. The projects don't really do estimations. Can we satisfy the PP & PMC PA'ss without doing any estimation? I know it can't be that way, but can it be tailored?
2. Requirements Management: Some of the business units have CCBs to discuss change requests and other business units discuss requirements changes in their project team meetings. The most significant gap I found is in Requirements Traceability. Traceability of Customer requirements to the Functional Requirements and Traceability of Use cases to the Test cases are missing. Is this reason enough to fail the RM PA? One of the Engineering directors asked me how much traceability you need to satisfy this condition. At that time I said 100% of all the requirements. Then I also read from somewhere that it is OK to define that we maintain traceability for at least the MUST BE CUSTOMER REQUIREMENTS. Traceability of other requirements can be made optional. Can it be possible like that?
3. Configuration Management: The projects thought they have a CMP which is embedded in the project plan. What I found missing are the Configuration Audits ( PCA & FCA). Is it possible to satisfy the Configuration Management PA without doing Configuration Audits to check the document status, builds, and backup strategy?
4. PPQA: One of the business units has a Software Quality Assurance plan, but it is done by one of the testers from another project. As a part of PPQA the SQA will do some spot checks based on a pre-defined checklist, which includes Project Planning, Risk Management, Project Monitoring and Control, Integration and releases. But I guess this can be improved by my role as a independent software quality engineer.
5. M&A: I am very much worried with this process area, as of now the organization status is nil with respect to metrics collection, they don't have a metrics database and no metrics have been defined yet. Is it OK to start now to form a team to do some reasearch and come up with metrics definitions, deploy them and start collecting data? My question is how much data do we need to collect to satisfy this PA? And do we need to provide evidence of analyzing these collected data and show some improvements steps taken at the time of SCAMPI apprisals? How long will it take in general to satisfy the Measurement & Analysis PA?
6. SAM: can we tailor this PA if we are not dealing with suppliers? If yes how can it be possible?
   

The directive from the Leadership team is to acheive CMMI Level 3 by end of 2009. I was baffled to hear this. Under these circumstances, what are the chances of getting CMMI Level 3 or my traget is at least CMMI Level 2? That is what my initial target. Can I acheive CMMI Level 2 by the end of 2009? If so, what are the things I need to address?

Here are some of the things I have already started:

1. CMMI Overview training to all the teams
2. Dailogue session on metrics identification
3. Looking into some Requirements tools which provide Traceability
4. Need to push the project team to have configuration audits.

In addition we already have established a process data base and the processes are defined and templates are being used from the parent organization. Since our company is a multi-site company, one of our counter parts has already acheived CMMI Level 3. We will be using the same process database and their templates. I thinking of providing their training on each Process Area as well. Is this a correct way to use the processes and templates of our parent organization? If not, do we need to establish our own local process data base?

First of all, I sympathize with you and the challenges you face. I applaud the fact that you had the foresight to conduct a Gap Analysis of the organization. You have highlighted a number of key weaknesses within the organization. However, to provide you meaningful feedback on all of your points would require working directly with you and your company.

1. What is your CMMI experience? Have you taken the SEI’s Introduction to CMMI class? If not, I strongly recommend that you and possibly those others in your company who are responsible for your processes take the three day class. The class should provide you a more thorough understanding of the CMMI, its interpretations, and material for constructing an internal Overview class.
2. You have identified some serious deficiencies within the organization in all of the ML 2 Process Areas. These need to be analyzed, addressed, corrected, solutions implemented, and then re-evaluated some months into the future before you can consider a formal SCAMPI at any Maturity Level. The length of time before the next evaluation is a function of a number of factors: number of people in the organization, number of projects, typical project duration, how much time and other resources are dedicated to process improvement, etc.
3. The organization needs to first implement Maturity Level 2 to form a firm foundation before considering moving to Maturity Level 3. The issues you have identified are fairly typical. Basically, it sounds like your organization does not perform PPQA or MA and is challenged with Project Management, Requirements Management, and Configuration Management. The first steps here should be to identify the necessary skills-based training classes you need to bring in-house and train your staff on these concepts. If you just purchase tools and push for audits, you most likely will not achieve the desired effect. You have to understand your process first and the reasons for why it is important to perform each of the steps.
4. Since another division has already achieved ML 3, it is a good idea to learn from their mistakes. But be very careful of the temptation to “clone” their processes and procedures. You have to implement the processes and procedures that match the way you conduct business today.
5. Based on what you have outlined, and given how much time and effort it could take just to address the ML 2 issues, I would say that ML 3 is out of the question for 2009. You could conduct a ML 3 SCAMPI A by the end of this year, but in all likelihood it would not be successful.
6. The best suggestion I have for you is to hire a CMMI consultant and Lead Appraiser to provide you with the proper advice and guidance. Otherwise, you could be spending a lot more time and effort than originally anticipated.