Category list

DO S AND DON TS

Here s a summary list of things you should do and things you should not do when first starting out on your organization s process improvement journey using CMMI:

Do

Assume that the organization in which you want to make improvement has already evolved some good management and engineering practices that can be incrementally improved using CMMI as a guide.
Identify, acknowledge , and recognize the existing good management and engineering practices or process strengths.
Identify any existing organizational standards that you can leverage.
Look for evolved business practices in areas of the business that aren t specifically identified as process areas in CMMI.
Find out what the organization s history (if any) for change and process improvement is.
Base the documented processes and procedures first on what people are already doing and then begin the improvements.
Have an open mind; learn as much as you can about the organization and its people before you try to make improvements or implement CMMI.

Don t

Don t assume that the organization already has some good engineering or management practices or standards already in place. (Even if you think this, don t say it publicly .)
Don t throw away or ignore evolved business practices that can be used as a springboard for CMMI-based improvement.
Don t assume that just because people in an organization have been doing something or doing something a particular way that it still has business value. Legacy practices and standards can sometimes be a barrier to process improvement efforts.
Don t take the attitude that the organization is in terrible shape and the only thing that will save it is you and CMMI ” you will absolutely fail every time!

QUIZ: WHAT DID YOU LEARN? WHAT WILL YOU DO?

Now take the post-chapter quiz (Figure 1.7) and think about what you ve learned and how some of your views toward CMMI-based process improvement have changed. Think about what you will do with the information you ve learned (and how it makes you feel).

click to expand
Figure 1.7: Chapter 1: What Did You Learn? What Will You Do?

Chapter 2: The Role of Roles

I m not asking you what you do, Dave. I m asking you who you are.

” Jack Nicholson as Dr. Buddy Rydell in Anger Management ^[50]

WHAT DO YOU THINK? WHAT DO YOU BELIEVE?

This chapter is about defining the roles of people in the organization and the roles of organizations which work together to deliver a system or service. As you will soon learn, it is very easy to make assumptions about roles and responsibilities in an organization. If left unchallenged ” like comparing your assumptions with reality ” the assumptions will soon become hard-held beliefs. Take the quiz in Figure 2.1 to see what kinds of beliefs you may have about organizational roles and then, after reading the chapter, take the quiz in Figure 2.3 to find out what you ve learned.

click to expand
Figure 2.1: Chapter 2: What Do You Think? What Do You Believe?

^[50] Segal, Peter, Anger Management, Sony Pictures, 2003.

THE MODEL AND THE REALITY

Both SW-CMM and CMMI provide either explicit or implicit guidance for establishing roles and responsibilities in the organization. In SW-CMM, there are Ability to Perform key practices that address establishing certain functions to perform processes and activities such as project management, change control, quality assurance, and training. In CMMI, there are no explicit practices that come right out and say, define your roles and responsibilities, but there are several GPs that heavily depend on some level of established roles. GP 2.3 requires that resources be provided for performing the process, developing the work products, etc. A resource doesn t have to be a person or people in the abstract world of CMMI, but resources are almost always people in the world in which we work. GP 2.4 comes as close as a model should to being explicit about roles and responsibilities. Its subpractices address assigning responsibility and authority for performing tasks and processes. However, it doesn t tell you how to go about doing this, nor should it. GP 2.7, which addresses the identification and involvement of relevant stakeholders, is my all-time favorite GP. This practice is difficult to implement, yet such a powerful improvement when implemented well. But there s a catch, implementing this GP will be all but impossible for an organization to get its brains and arms around unless roles and responsibilities are defined and being practiced. People simply don t grasp the idea of being a stakeholder unless they perceive that their roles and responsibilities somehow align with the work for which someone has identified them as stakeholders.

Say you re an analyst and your main job, as you know it, is to perform system tests. A project manager comes to you and tells you that he d like you to participate in peer reviews because you re a stakeholder. But if you re really busy and under a deadline to finish some testing and someone schedules you to participate in a peer review, which activity is going to get flushed? That s right, the peer review. Why? Because as far as you re concerned , you get evaluated and compensated for doing testing, not for doing peer reviews. However, if your defined roles and responsibilities required you to participate in peer reviews and if you knew that at least a part of your compensation, performance evaluation, or promotion was based on peer review participation, you might make a different choice in the previously described situation. Even if you still make the same choice and blow off the peer review, at least you know the cost of your decision.

The authors of CMMI did the right thing; they did not prescribe to organizations how they should be structured in terms of departments, functions, roles, positions , or responsibilities. CMMI (or any other intelligent reference) cannot do this for you because every organization had different strategies, goals, and business needs and it is those things that should influence the organization s structure. This chapter also does not prescribe a particular definition of roles and responsibilities; it simply provides information on the importance of role definition and how an organization can accomplish this important task.