Archive for September, 2010


ML2 Basics

September 10, 2010

1 Overview

The objective of Maturity Level 2 is to determine what are the practices, processes and tools that succeed most efficiently in responding to the organizational expectations and goals. Once this has been achieved, the organization can efficiently consolidate, document and deploy what are proven best practices, which is the key principle underlying Maturity Level 3 process areas.

In order to achieve this, Maturity Level 2 focuses on a number of key principles explained hereafter.

2 Practices to be implemented at Corporate Level

2.1 Policies

Policies need to be established in order to clearly define the organizational expectations from the processes. The policy serves multiple purposes:

  1. Demonstrate that management has thought about the process or practice and has clearly understood the business benefit they expect to get out of it. This should not be a repeat of what CMMI says, but a clear demonstration that “reaching level x” is an understood business need that can be explained. E.g., a policy that states that “every project needs to demonstrate by-directional traceability” is a policy that was written by someone who is familiar with the CMMI but has no clear understanding as to why this is important to the business.
  2. Clearly communicate to all affected parties what these expectations are. A policy that is not well communicated and understood defeats the very purpose of the policy. While individuals might not be able to recite the policy, or even reference it directly, they should have knowledge of management’s expectations.
  3. Ensure that the key processes and practices are implemented throughout the organization. A policy forms a “constitutional law” of the organization, hence no one, not even the chairman of the board, is above the policy and no one can change or ignore it without serious (explicit) consequences.
  4. Give a basis against which the success, strengths and weaknesses of given practices can be assessed on a regular basis by the management team. They are expected to consider the results of their investment in process improvement and ensure that the results being generated are responding to the expectations as communicated rather than just creating bureaucracy.

2.2 Process and Product Quality Assurance

A clearly defined focus on continuously assuring the quality of the processes and related products needs to be implemented from the top. This is a function that is set up with sufficient objectivity and independence to be able to encourage a quality focused approach to engineering and management practices.

The Quality Assurance function needs to understand the need for practices and processes and be able to encourage and guide in the selection of processes for each project. These business needs and goals are translated into clearly documented criteria and checklists that will assist in both guiding and measuring the results.

2.3 Measurement Objectives

The general purpose of the organization is to serve the customers better. Customer satisfaction needs to be defined in terms that allow measurement and monitoring of each project, product and process. Customer satisfaction should be considered at this point in terms of stakeholders and may include, among others:

  1. The top level objectives of the organization
  2. The service-level agreements with end-users
  3. The principle objectives of the project (on-time, on-budget…)
  4. Staff retention
  5. Transfer to maintenance and support of the products

In order to be able to manage the organization, there needs to be a clear understanding of what information is needed from the projects and engineers and how this information will be captured, analysed and used.

3 Practices to be Implemented at Team Level

3.1 Planning Activities

Planning activities is critical to the success of any activity. If the activity is not appropriately planned, it will not be carried out to fruition. The planning of the activities, naturally, includes the activities related to the project and the development activities, but also the planning of support and annex activities that need to be carried out –even I the implementation of these activities cannot be known beforehand.

The development activities need to be planned in sufficient detail to allow the success of the project, but not to a level of detail that renders the management of the project too bureaucratic. This includes reasonable groups, sequences of activities to be fit into an acceptable “life-cycle”, ensuring that the different activities are carried out with an understanding of their impact and consequences and can be performed in a logical sequence.

Other activities are planned in parallel or in addition to the project activities. These include activities such as when and how QA reviews or configuration audits will be performed.

Finally some activities need to be planned in the abstract, theoretical environment so that they can be implemented when needed. This includes activities such as what to do when a change request is received, when the progress deviates from the plan by more than an acceptable margin, etc.

In order to plan the activities efficiently, there is a need for a clear understanding of the amount of work to be carried out, the tasks required to complete the project, the sequence of the activities, the skills (available and needed) for the tasks, etc. This, therefore, requires a number of additional activities to performed, such as building a work-breakdown structure, selecting a life-cycle, estimating the size of the work, evaluating the time required for different levels of people to perform the work, etc.

Planning activities will include the monitoring of the planned activities and ensuring that they are being carried out as planned. When necessary, they will include the re­planning activities.

Naturally, planning activities will ensure clear and unambiguous assignation of responsibilities and authority, with well defined communication and escalation paths.

3.2 Requirements Management

Managing requirements is critical to the success of any project. Managing requirements aims at ensuring that the customer and the supplier (or end-user and developer) have the same understanding of what will be included or not in the delivered final product, and the related information (when it will be delivered, what it will cost, etc).

In order to be able to do this, there is a need to establish clear understanding of the requirements, ensuring that all parties have the same understanding, throughout the life of the project – this includes the management team, the customer, the developing team members and others. This understanding needs to be maintained at all times, including specifically when the stakeholder needs or expectations change.

A number of artefacts are required to ensure that all requirements are understood and accepted, while at the same time ensuring that they are being correctly (effectively and efficiently) implemented in the final product, in a manner that will demonstrably satisfy the stated requirements.

3.3 Integrity and Completeness

Throughout the life of the project, different things will change and evolve. These need to be controlled to ensure that the changes are justified and understood, while at the same time demonstrating that the latest version of the product is always available.

Particularly before a release of a product (whether at the end of a project or at a milestone within the development lifecycle), it is expected that a demonstration of the completeness and the integrity of all concerned products can be demonstrated through a physical or a function audit3. In order to perform these audits, it is necessary to be able to have:

  • A complete list of everything that is expected to be included in the baseline;
  • A system that allows to review and retrieve the products;
  • A plan for when baselines needs to be created or released;
  • An understanding of all the changes and evolutions that should be included in the baseline.

4 Conclusion

Measuring the maturity of an organization against the expectations of CMMI® Maturity Level 2 practices involves ensuring that the organizational structure is in place to allow a clear understanding of what needs to be performed and a review of the implementation of practices against expectations.

A more appropriate statement would read something like “every project should be able to demonstrate that the budget was used efficiently to develop everything required by the customer and no superfluous, undesired functions or features; every project should be able to demonstrate what is the actual current status of development with regard to customer requirements”.

%d bloggers like this: