DEFINING ROLES

So you know why defining roles and responsibilities is critically important to process improvement and why it is such a difficult task. Don t give up; it s difficult, but not impossible . At some point, people involved in defining roles and responsibilities will start talking to people to find out what they think are their roles and responsibilities. But before anyone starts that activity, people doing this work should first build a design or an architecture for this type of information.

We ve already discussed in the previous sections how a person often has one title or position, multiple roles, and then multiple responsibilities for each role. So following that logic, we can construct an architecture that gives us a way to codify the roles and responsibilities. Table 2.1 is one example of such an architecture.

Position: System Engineer (Byron Davies)

Role: System Engineer

Responsibilities:

Design/architect end-to-end system including logical, user , and process interfaces between subsystems.

Perform peer reviews of system architecture with relevant stakeholders, incorporate feedback, and obtain concurrence on delivered architecture.

Attend system development reviews and provide system engineering perspectives.

Manage system development and delivery risks as assigned by program manager.

Role: SEPG Member

Responsibilities:

Participate in all SEPG meetings.

Develop, revise , and review process definitions and other process assets as assigned by SEPG chair .

Provide system engineering knowledge and perspectives to all SEPG work and outputs.

Role: Employee Management and SE Administration

Responsibilities:

Work with direct reports ( engineers and architects ) to establish and document semiannual individual performance objectives.

Provide coaching, mentoring, and performance feedback (against approved objectives) to direct reports as needed.

Provide formal (documented) semiannual performance feedback and rating to direct reports.

Based on performance and in accordance with HR policies, administer direct report promotions and compensation.

Work with direct reports to establish and document individual training plans.

Role X: Additional role description

Responsibilities:

Responsibility n for Role X

Responsibility n +1 for Role X

Position: B (Sally Somebody)

Role A for Position B: Additional role description

Responsibilities:

Responsibility n for Role A

Responsibility n +1 for Role A

Where to Start

Once a design or architecture is established for defining roles and responsibilities, it s time to start populating that design with live information. The process focus people or process team responsible for defining roles and responsibilities should pilot their design by defining some process focus roles first before trying it out on other people in the organization. This will give the designers/definers a chance to find out what works and what does not with the work products they intend to use to define roles and responsibilities and mitigates the risk of them unnecessarily irritating other people in the organization with a bad and unproven design.

The next step is to take great precautions to avoid yet another common mistake made by well-intentioned process people: defining roles and responsibilities based on academic or textbook definitions or worse , based on myopic views of the business world resulting from limited experience.

For example, an intelligent but inexperienced person responsible for defining roles and responsibilities would quickly determine that he can simply borrow this definition for project manager from CMMI: ^[2]

the person responsible for planning, directing, controlling, structuring, and motivating the project. The project manager is responsible for satisfying the customer.

However, this definition is intentionally broad such that it generically describes every project manager in every systems organization. If someone puts this out into your organization as the definition for project manager, it will have one of two consequences:

1. People who are not project managers will think the definition describes their role. Based on their current position and role, they will either think they just got a promotion or a demotion.

2. Some people who thought they were project managers will not see themselves in the definition and will be either elated or upset that they are no longer a project manager.

The definition for project manager (and all other roles) in an organization must be the definition that describes that role in the context of that organization and its culture. In some cases, an organization has evolved its own labels for roles and there is no reason to change the terminology. For example, the different terms for project manager I ve seen are project lead, software lead, lead engineer, task manager, task lead, and team lead. In each of these organizations, the definition for the role of people doing project management were similar, but they chose different labels for that role. Sometimes in these situations, a SEPG member will insist that the people in the organization change their language, as if there is some secret law that says organizations must structure themselves in accordance with textbooks and other literature. As change agents , people who pursue this route have almost no chance of success. Who cares! Let your organization assign to its roles the labels to which people are accustomed. It is the definition of those roles and the corresponding responsibilities that matter.

To begin defining the roles and responsibilities, it is critical to first realize that many of the organization s roles exist in practice and that the task at hand may be one that is more documenting the existing roles rather than defining them. However, if the organization is just starting out with CMMI and process improvement, assuming that roles are accurately defined and practiced is too risky; someone needs to go find out. It will take a little bit of detective work, but it will be worth the effort to avoid inventing roles that stand a good chance of upsetting people and arming them with justification for why the process improvement is a waste of their time. This is where positions and titles come in handy. There are job and position titles which are almost universally ascribed to groupings or types of work. Table 2.2 lists some typical job and position titles you can find in most software and systems organizations, the type of work people in these positions typically perform, and the CMMI process areas correlating to that type of work.

Table 2.2: Where to Look for Roles in the Organization

Typical Positions	Type of Work Typically Performed in these Positions	Related CMMI Process Areas or Practices
Engineer Software Engineer Developer Analyst Programmer Designer Software Developer Architect System Engineer Technical Staff Member Technical Specialist	People having position titles or job descriptions similar to these are usually the people involved with analyzing and defining requirements, designing the system or products, developing software or software- intensive systems, and maintaining (fixing defects) the systems and products they support. People in these positions also are commonly involved in integrating and testing system components .	Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Validation (VAL)
Project Manager Project Lead/Project Leader Software Lead System Engineer Senior Engineer Program Manager Team Lead Task Lead/Task Leader Manager Programming Lead IPT Lead	People with these jobs or position titles are usually individuals who have moved into positions with some level of authority to provide leadership or guidance to other workers. These positions are frequently involved in estimating and planning work and then managing the work performed by others and reporting the results.	Project Planning (PP) Project Monitoring and Control (PMC) Risk Management (RSKM) Integrated Project Management (IPM/ IPPD) Generic Practice 2.2
Quality Assurance Quality Control Quality Manager Quality Specialist Quality Engineer	Although traditional jobs and positions related to quality have been primarily associated with product quality, these people are natural candidates to take on the role and responsibilities for assuring process quality also.	Process and Product Quality Assurance (PPQA) Validation (VAL) Generic Practice 2.8
Configuration Engineer Configuration Manager Configuration Specialist Data Manager Technical Publications Manager Integration Engineer Change Control Board member Configuration Control Board member	People with titles such as these are involved in managing and controlling hardware or software configurations or managing documentation versioning. There are people who argue that there is a difference between change management and configuration management, but they are wrong. Configuration management is merely a subset of the larger change management.	Configuration Management (CM) Generic Practice 2.6
Purchasing Agent Acquisition Manager Procurement Specialist Buyer Contracts Manager Contract Officer Accounts Payable personnel	People in these positions regularly deal with vendors and suppliers to procure materials and services for the organization and for projects. In the government and defense sectors, personnel in these positions usually follow rigorous procedures due to their requirement to be compliant with Federal Acquisition Regulations (FARs) and public law.	Supplier Agreement Management (SAM) Integrated Supplier Management (ISM)

CMMI Process Improvement Roles

Perhaps before someone starts defining the roles and responsibilities for everyone in the organization, it might be prudent to first begin defining the roles and responsibilities needed for the process improvement project. From SEI s Managing Technological Change (MTC) course, ^[46] we know there are three primary roles in any organizational change, including CMMI or CMM-based process improvement:

1. Sponsor

2. Change agent

3. Target (participant or victim )

MTC elaborates on the responsibilities for these process improvement roles, but it still doesn t paint the whole picture because roles are fluid and situational. I may be in the role of a sponsor in one endeavor, but a change agent in another situation, and a target in yet another situation. Meanwhile, I am also a SEPG member and a requirements analyst. And that s all just my work-life roles. Once I get home, I m might also be a spouse, a mother, a steward and protectorate of domestic animals, and a little league football coach. No one gets to be just one role all day, not anymore.

In CMMI process improvement, it is no coincidence that people s roles will closely resemble those you will find on a system engineering project team (read Establishing the Process Improvement Project Team in Chapter 3 ” Managing the Process Improvement Project). The organization will need to define process improvement roles which encapsulate what people do in the process improvement project. Hence the role SEPG member only tells us that a person attends SEPG meetings and we know that processes don t get defined and implemented simply as a result of people attending SEPG meetings.

The critical roles and responsibilities which need to be defined for a CMMI-based process improvement project are:

Customer: If an organization cannot define a customer or customers for process improvement, that is, they cannot define who wants the processes improved and why, then it should reconsider engaging in an activity as expensive as CMMI-based process improvement. The customer or customers of process improvement can be people within the organization using CMMI and they can be people outside of the organization. The customers of CMMI or improvement project are also probably relevant stakeholders in many of the process improvement activities.

Project manager: This is the person or persons who have the ultimate responsibility for planning the process improvement project, obtaining resources to do the work, assigning tasks , and then managing the project in accordance with plans. This person or people can also be the leader of the process focus team (i.e., SEPG), but is not necessarily so.

System engineer: The person or persons responsible for designing the overall process system and ensuring the successful integration of its subsystems and components. This person typically leads the establishment of standards and processes for developing the organization s process assets and also designs the organizations process repositories such as a Process Asset Library (PAL).

Engineers: People responsible for designing and developing the organization s processes and process assets.

Educators/ trainers : People who possess the skill and knowledge to transfer knowledge to others.

Analysts: People who know how to measure and analyze the efficacy of processes in the organization.

Configuration management: By default, the organization s process focus group is usually the change control board for the organization s processes and process assets. However, this should not be the default assumption since configuration and data management is a learned skill and not one always possessed by SEPG members .

Quality assurance: The process improvement team will (or should) be operating and conducting its activities in compliance with defined plans, processes, and standards. The project needs someone to provide objective verification that the project is executed in compliance with those governing plans, processes, and standards.

^[2] The Capability Maturity Model IntegrationSM ” SE/SW/IPPD/SS, V1.1, CMU/SEI-2000-TR-030 , Carnegie Mellon University, March 2002.

^[46] This reference and subsequent references are adapted from SEI s course, Managing Technological Change, which adapted materials developed by Implementation Management Associates, Golden, CO.