The full name of CCB is configuration control board, that is, configuration control board. CCB is a concept proposed in CMM (I). In some organizations, it may not be called the Decision-Making committee. There is a saying on the Internet that CCB is a change control board (Change Control Board)
The two statements are different, but the concepts and functions are the same. The description of the two in the CMMI-V1.2 is as follows:
Under: "configuration control boards are also known as change control boards
".
[Responsibilities of CCB] CCB is mainly responsible for the establishment and change of the approval benchmark. There are some common misunderstandings about CCB's responsibilities:
- CCB is only responsible for approving benchmark changes and does not need to establish a benchmark for approval. A friend with such an idea can only understand it literally without thinking deeply. Benchmarking is a process from scratch. Isn't it a change?
- CCB is not only responsible for benchmarking and change approval, but also for approving contracts, resources, costs, and technologies.
Contracts, resources, and costs are all reflected in pre-sale projects, project plans, and design schemes. The project plans and other content should be managed on a benchmark basis. For projects/organizations that have implemented benchmark management, regardless of the approval/Decision
Finally, we have to go to the baseline establishment and Change step. Therefore, the description of CCB's responsibilities is highly summarized.
- The scope of CCB is configuration management. Some friends see that CCB is described only in the configuration management process, so they think
The scope of CCB is configuration management. In fact, the scope of CCB is the entire project. So why does CCB only appear in the configuration management process? Because the design and description of the process must follow the principle of "high cohesion and low coupling ".
As far as possible, a responsibility should not be repeated in multiple processes.
[Composition of CCB] CCB should be composed of representatives of project stakeholders from different fields and be able to make management commitments. CCB is generally composed of department managers, business personnel, project managers, development owners, test owners, and quality assurance personnel.
The certificate engineer and configuration management engineer. For different types of projects, CCB members are different. For example, a high-tech project includes a technical director and a system integration project generally includes system engineering.
The project owner and hardware product project owner generally include the hardware owner. Important projects may include senior managers of both parties. Some may ask, so many people must be very busy. Do you have to submit all benchmark establishment/changes to CCB for approval?
? If a large change is necessary, if a small change needs to be submitted to CCB, isn't it inefficient? This is also a question in many organizations. In order to determine this situation, we generally use
By dividing rows and layers, CCB members at different levels can focus on different changes. [CCB level] the CCB level is generally necessary (small projects are generally unnecessary), and some organizations should divide several
Questions about levels are confused. The number of levels of CCB should not be uniform, but should be determined based on the actual situation of the project (as an Organization standard specification, you can make suggestions on the levels of CCB, but should not force project execution
Rows ). In general, the division of CCB is generally taken into account through the following steps:
- Project stakeholder analysis: first, consider who the project is related.
- Stakeholder impact analysis: analyzes the persons associated with the project that can influence various decisions of the project. These persons are members of CCB.
- Decision Content Analysis: analyzes and classifies the content that requires CCB to make decisions.
- Decision matching analysis: match the content to be determined with CCB members to obtain a rough level.
- Level matching analysis: Many people overlap with the decision content in the general level obtained in the previous step. For example, if the project progress plan is changed, the Project Manager can decide the change with a small impact, A change with a large impact needs to be determined by the department manager. A change with a greater impact even needs to be determined by the senior managers of both parties. Therefore, the decision content at different levels needs to be analyzed.
There are two common CCB hierarchies:
- Level 1 CCB is responsible for changes based on the configuration item type, level 2 CCB is responsible for design-related changes, and level 3 CCB is responsible for code-related changes.
- Based on the impact of changes, take the project schedule as an example. If the construction period changes more than 50%, level 1 CCB is responsible for the change, and level 2 CCB is responsible for the change of the construction period, level 3 CCB is responsible for a period change of no more than 20%.
The levels of CCB and their respective responsibilities should be completed during the configuration management planning/planning period and must be reviewed before they can serve as formal content to guide relevant work. [CCB decision-making] After CCB is established, the question to be considered is how to make a decision. Generally, there are three methods to consider: 1. Most opinion decisions: by voting, all members can participate in the decision-making process equally. The advantage is that it fully mobilizes the enthusiasm of members to participate in meetings and propose suggestions. The disadvantage is that the minority is hard to define as the majority, and 2/3 is the majority? What is the absolute majority and relative majority? Another serious problem is that such a mechanism may generate political struggles (gangs), which may seriously affect project decision-making. 2. Centralized right decision-making: Give the decision-making power to a person. The advantage is that the priority of various opinions is encouraged in decision-making. For example, the buyer's project manager acts as the final owner of the project to make decisions. The disadvantage is that the enthusiasm of other Members is suppressed. 3. consensus decision-making: seek the informal (non-voting) Comments of the majority of participants in the meeting. Advantage: Speed
It is fast and allows everyone to express and consider their views. The disadvantage is that a decision cannot be made if an agreement cannot be reached between members. Therefore, a bounce mechanism should be provided. If an agreement cannot be reached within a reasonable period of time
The buyer's project manager makes decisions (because it is invested by the buyer ). [CCB leader] It is equally important to have a CCB leader. The CCB leader is not an executive leader but a responsible leader. It only hosts the meeting and ensures that it does not deviate from the meeting subject. The following members may be given priority to CCB leaders:
- Buyer's project manager: ultimately responsible for product users and Project Investment
- Seller Project Manager: responsible for technical development and maintenance
- Configuration Management Engineer: cm is his main responsibility, and CCB is the focus of configuration management.
- Quality Assurance engineers: act as coordinators rather than decision makers and are not responsible for the implementation of any decision.
[CCB meeting] a ccb meeting is generally held when a decision is made on changes and releases. For CCB meetings, meeting records are required to provide visibility into CCB decisions. CCB meeting records are still available
Meeting records should be accurate and specific, and there should be no misunderstanding. No matter what action is taken, the meeting records should record who is the performer
Information such as when the operation is completed, including attendees and non-attendees. The meeting records should be presented not only to the persons present at the meeting but also to the buyer and the seller's senior managers so that they can track the project. The CCB meeting records are not for formal purposes, but for the purpose of recording the clarity and completeness of the content. People often give away the results of the meeting at the end of the meeting or have different opinions on the agreed issues. Such chaotic and disorderly results are very dangerous, and meeting records avoid this situation.
