This document seeks to identify a number of ways in which a good implementation of CMMI would allow to resolve a number of Sarbannes-Oxley and CobiT requirements. This document does not claim to be exhaustive. The usage of this document is to allow people who are responsible for defining and deploying process improvement activities to consolidate their work in such a way as to avoid redundant work. The guidance of Sarbannes-Oxley requirements and CobiT auditing recommendations should assist in defining the correct approach for the implementation of CMMI compliant processes. This document is aimed primarily at CMMI practitioners who are seeking to implement Sarbannes-Oxley and/or CobiT practices. While the document explains some of the context and content of both of these approaches, it is based on the assumption that CMMI is known and does not clarify those practices more than necessary.
The CMMI is a process model that aims to offer the best quality of products and services towards the customer and user. By seeking to ensure that processes and controls are in place to identify and remove as rapidly as possible defects, it seeks to increase the level and quality of service provided. This is a voluntary approach to quality.
25 process areas that cover the engineering, process management, support and project management activities of an organization.
Each process area as a number of key specific practices and goals related to achieving the results and producing the products as well as generic practices that seek to govern the process itself.
The focus of the CMMI implementation is to be the business objectives and understanding the needs of the stakeholders. The CMMI focuses on engineering projects and their reporting structure.
The CMMI includes two levels of ratings:
The maturity level is based on the Capability Maturity Model structure and determines a number of process areas that need to be sufficiently implemented in the organization in order to ensure the quality of the products. 5 maturity levels have been defined (1 - Initial, 2 - Managed, 3 - Defined, 4 - Quantitatively Management and 5 - Optimising)
Capability levels are based on the SECM (EIA 731) structure in which each process is rated based on its capability to deliver 6 capability levels have been defined: 0 - incomplete, 1 - performed, 2 - managed, 3 - defined, 4 - quantitatively managed, 5 - optimising.
Each level of rating, in both approaches is based on clearly defined requirements.
Sarbannes-Oxley is a series of control principles seeks to ensure that financial reporting is correct and understood by the people in charge. The approach seeks to cover and validate the processes and controls that lead to the production of financial statements.
IT is considered key in this element because of the role that played in the production and validation of the data used in the legal reports.
The Sarbannes-Oxley Act came into force in July 2002 and is a compulsory regulation of corporate governance and financial reporting for all US companies This is a US legal requirement which serves to demonstrate firm resolve by the US Congress to improve corporate responsibility. The focus of this approach is to enforce good governance and ethical business practices.
A loose requirement for sufficient controls to be in place. These are covered by a number of audit requirements in the form of questions that cover the control environment, the risk assessment, the control activities, the information and communication and the monitoring activities of an organization.
From an IT point of view, Sarbannes-Oxley is interested in the controls that relate to program development, program changes, computer operations, access to programs and data. This is to be considered in relationship to the executive management and the business processes.
Sarbannes-Oxley suggests that the focus of the implementation needs to be primarily on the risks and needs of the business. The controls to be put in place should be based on a clear understanding of what is needed, using the Sarbannes-Oxley documentation as a guide, not as an absolute rule. Some additional controls may be required; others may prove to be inefficient in the organizational environment.
Carefully consider the appropriate IT control objectives for its own circumstances
This statement to be found on page 5 of the Sarbannes-Oxley documentation demonstrates the flexibility of the approach. The organization needs to consider what controls are required and how they should be implemented – then ensure that this is done sufficiently to achieve the related objectives.
Disclosures in Periodic Reports
Financial statements are published by issuers are required to be accurate and presented in a manner that does not contain incorrect statements or admit to state material information. These financial statements shall also include all material off-balance sheet liabilities, obligations or transactions. The Commission was required to study and report on the extent of off-balance transactions resulting transparent reporting. The Commission is also required to determine whether generally accepted accounting principals or other regulations result in open and meaningful reporting by issuers.
Real time issuer disclosures
Issuers are required to disclose to the public, on an urgent basis, information on material changes in their financial condition or operations. These disclosures are to be presented in terms that are easy to understand supported by trend and qualitative information of graphic presentations as appropriate.
There is no actual rating in Sarbannes-Oxley, this is a pass or fail approach. There is only a high-level recommendation that auditors should evaluate on a regular basis any implications related to potential changes... This should be done according to a recognized auditing standard.
CobiT is a framework that seeks to structure the processes and controls that lead to efficient management of IT governance within an organization. The objective of CobiT is to assist in understanding and managing the links between risks, needs, controls and technical issues that an IT organization face.
The framework includes a number of elements such as a "maturity model" approach and process control and application control points; it also includes a "maturity model" approach by which the capability of each of the 34 processes can be measured.
This is an approach that is voluntarily taken by organizations to assist them in their management and control activities.
34 generic control objectives organized in 4 domains covering the planning and organization, the acquisition and implementation, the distribution and support, and the control activities.
CobiT recommends that the IT skills and priorities be used in determining the most appropriate approach. While the framework gives clear guidance in the approach, the implementation needs to be tailored to the business.
CobiT includes a rating system that includes 6 stages of reliability which are defined loosely as 0 - nonexistent, 1 - Initial/Ad hoc, 2 - repeatable but intuitive, 3 - defined process, 4 - managed and measurable, 5 - optimised.
There are some significant differences between the two rating systems:
The usage of similar numbering and naming principles may lead to believe that there is more similarity between the two approaches. It seems that, on examination, the CMMI is more demanding and productive at every level. The CMMI requires that training and the evaluation of adherence be performed at capability level 2; within CobiT, training is at level 3 and compliance at level 4. The CMMI requires that the process quality be under quantitative (statistical) control at capability level 4; CobiT only states that it is possible to measure compliance (this would be expected at capability level 2 in the CMMI, GP2.8 and GP2.9).
At the highest level, CobiT claims to have arrived (optimised), with the processes being at best practice; the CMMI sees this as a more ongoing process (optimizing) with quality and performance being continuously monitored and improved.
The IT control environment includes the IT governance process, monitoring and reporting. The IT governance process includes the information systems strategic plan, the IT risk management process, compliance and regulatory management, IT policies, procedures and standards. Monitoring and reporting are required to ensure that IT is aligned with business requirements.
The IT governance structure should be designed to help ensure that IT adds value to the business and that IT risks are mitigated. This also includes an IT organization structure that supports adequate segregation of duties and promotes the achievement of the organization’s objectives.
An IT governance process should be designed to help ensure that IT adds value to the business and IT risks are mitigated. Includes an organization structure that supports adequate segregation of duties and promotes achievement of objectives:
The CMMI requires that most of these features be implemented from the beginning. A number of process areas focus on ensuring that the information is based on business needs and requirements (MA Purpose statement, OPF SP1.1, OT SG1). In addition, every process area includes the requirement for the appropriate levels of policy (GP2.1), planning (GP2.2), standards and procedures (GP3.1). Finally risk management is laid out in process areas in both project management (PP SP2.2, PMC SP1.3, RSKM) and support (DAR). The systematic approach to risk is naturally covered by the continuous improvement of the processes (OPF, OPD, OPP, QPM, OID).
A monitoring and reporting process must be in place to ensure that IT is aligned with the business requirements.
This is largely covered throughout the CMMI, starting with MA, requiring that measurement and analysis are based on the management reporting needs (which should, naturally be aligned to the business needs). This information is further verified through process areas such as PPQA and PMC but also through control process areas such as DAR.
The need for the process improvement process to be aligned to business requirements is laid out from the start within the framework for process improvement (see CMMI book page 13: "three categories of factors that may influence your decision ... are business, culture and legacy.")
As we move to more maturity, greater focus is placed on the business needs and requirements by adding the statistical control and quality measurements based on those requirements (OPP SP1.1, QPM SP1.1).
These include controls over the definition, acquisition, installation, configuration, integration and maintenance of the IT infrastructure. Ongoing controls over operation address the day-to-day delivery of information services, including service level management, management of third-party services, system availability, customer relationship management, configuration and systems management, problem and incident management, operations management scheduling and facilities management.
The system software component of operations includes controls over the effective acquisition, implementation, configuration and maintenance of operating system software, database management systems, middleware software, communications software, security software and utilities that run the system and allow applications to function. System software also provides the incident tracking, system logging and monitoring functions. System software can report on uses of utilities, so that if someone accesses these powerful data-altering functions, at the least their use is recorded and reported for review.
The IT infrastructure in Sarbannes-Oxley includes the tools, environment and resources need to effectively perform activities related to:
Most of these are covered directly in both the planning process (PP) and in the generic practices related to the processes being considered. Each process needs to ensure, from the beginning, that "adequate resources" (GP2.3) are provided to produce the results. This includes most of the elements listed. In addition to this, the configuration controls of each process and its related work products are required in order to ensure that the work is done correctly.
If someone accesses these powerful data-altering functions, at least their use is recorded and reported for review.
This is covered throughout the CMMI by ensuring that the process is monitored and controlled (GP2.8), objectively evaluated (GP2.9) and reviewed with management (GP2.10). In addition to this, we have the requirement that activities be continuously monitored throughout any project that could affect one of the above, through project monitoring and control (PMC) and ensuring that traces are maintained under appropriate levels of control (GP2.6)
Access controls over programs and data assume greater importance as internal and external connectivity to entity networks grows. Internal users may be halfway around the world or down the hall, and there may be thousands of external users accessing, or trying to access, entity systems. Effective access security controls can provide a reasonable level of assurance against inappropriate access and unauthorized use of systems. If well designed, they can intercept unethical hackers, malicious software and other intrusion attempts.
Adequate access control activities, such as secure passwords, Internet firewalls, data encryption and cryptographic keys, can be effective methods of preventing unauthorized access. User accounts and related access privilege controls restrict the applications or application functions only to authorized users that need them to do their jobs, supporting an appropriate division of duties. There should be frequent and timely review of the user profiles that permit or restrict access. Former or disgruntled employees can be a threat to a system, and terminated employee passwords and user IDs should be revoked immediately. By preventing unauthorized use of, and changes to, the system, an entity protects its data and program integrity.
Access to the data needs to be monitored and control to ensure that no unauthorized access has been committed. This includes the implementation of activities such as:
These purely security related items are not directly referenced by the model. There is no direct relationship between the CMMI and data security.
Application software development and maintenance has two principle components: the acquisition and implementation of new applications and the maintenance of existing applications.
The acquisition and implementation of new applications continue to be areas with a high degree of failure. Many implementations are considered to be outright failures, as they do not fully meet business requirements and expectations or are not implemented on time or within budget.
To reduce acquisition and implementation risks, some entities have a form of system development and quality assurance methodology. Standard software tools and IT architecture components often support this methodology. The methodology provides structure for the identification of automated solutions, system design and implementation, documentation requirements, testing, approvals, project management and oversight requirements, and project risk assessments.
Application maintenance addresses ongoing change management and the implementation of new releases of software. Appropriate controls over changes to the system should exist to help ensure that they are made properly. There is also a need to determine the extent of testing required for the new release of a system. For example, the implementation of a major new software release may require the evaluation of the enhancements to the system, extensive testing, user retraining and the rewriting of procedures. Controls may involve required authorization of change requests, review of the changes, approvals, documentation, testing and assessment of changes on other IT components and implementation protocols. The change management process also needs to be integrated with other IT processes, including incident management, problem management, availability management and infrastructure change control.
The aspects that need to be covered are typical elements of the lifecycle
The control over these elements is found throughout the CMMI. The key elements to be considered within the Sarbannes-Oxley context are the manner in which security is put in place to ensure that the controls are there and are valid. Remember that the key elements of the act are to ensure that the management people know the real financial data and reports, and are ready to personally vouch for their validity. This is performed throughout the process by ensuring that the decision making is done correctly, the activities are well planned and monitored, there is an independent control of the adherence to the standards and requirements of the process, and the whole thing is regularly reviewed by higher management.
Change management, if badly handled, will open up as many risks as the creation, acquisition and implementation of new products:
These are all standard activities, forming the heart of the CMMI approach. It is a reminder that maintenance activities need to be performed with the same process-based rigour as the rest. The CMMI frequently talks of projects and many believe that maintenance can be excluded as it is not a project...
The following section covers the requirements of the CobiT framework as included in the CobiT v4.0 (IT Governance Institute 2005). For each of the CobiT high-level controls, comments are included indicating possible interpretation, overlap and differentiation with CMMI V1.1 (Software Engineering Institute 2002). The CobiT control framework is generally seen as a valid support and guidance for the implementation of Sarbannes-Oxley.
This domain covers strategy and tactics, and concerns the identification of the way IT can best contribute to the achievement of the business objectives. Furthermore, the realisation of the strategic vision needs to be planned, communicated and managed for different perspectives. Finally, a proper organisation as well as technological infrastructure should be put in place. This domain typically addresses the following management questions:
A number of aspects related to the strategy of IT are not covered by the CMMI, as the model tends to focus on the process improvement, project management and engineering aspects and less on the actual IT departmental and strategic management. However, we do find a number of points that respond to this requirement.
First of all, DAR should ensure that the strategic IT plan is based on an understanding of the needs of the business and the customers. That is further enhanced by the various organizational process areas that ensure that the organizational and business needs in terms of process, training, improvement are prioritised over the needs of the individuals and projects. All these elements underline the need for an organizational wide strategic plan that defines the long- term priorities. Other process areas and practices focus on peculiar aspects of the strategy and its implementation.
Corporate management aspects, such as the participation in steering committees and the reporting to the CEO/CFO/CIO, are not directly referenced.
The information architecture is covered in several process areas. These include project planning and project monitoring and control in which the data management plan and monitoring are referenced and required; organizational process development includes the management and architecture for process and improvement related information; configuration management includes all the aspects of ensuring the integrity of data and work products. In addition to these; MA SP1.2 - The measurements to be collected should be defined based on the information needed. This information needs to be classified and managed appropriately, according to the management policies.
The technical direction is set up first and foremost through the implementation of a process corresponding to the requirements of the "decision analysis and resolution" process area. This is reinforced through "organizational innovation and deployment" in which technological innovations are considered in relation to the needs of the organization. GP2.4 (in every process area) ensures that the people doing the work have the resources and tools they need to be able to do the work efficiently and technical solution. On a project level, the technological choices are covered by TS SP1.1.
More issues are required by the technological direction related to strategic choices and requirements based on the future of the organization - this is not covered by the CMMI but establishes the framework within which the CMMI should be working.
Defining the IT processes is naturally at the heart of the CMMI. While it is specifically laid out in OPF, OPD, OPP and OID, it is the underlying principle of every element of the model.
The IT organization is not mentioned directly within the model; however the clear definition of roles, responsibilities and authority is required for every activity. Additionally, the generic practices require that the people concerned are equipped with the training and resources they need to do the work required of them.
Additional requirements of CobiT include the need of quality assurance, risk, compliance and more. These are clearly laid out in process areas such as PPQA and RSKM.
Managing the investment and the related financial aspects is, of course, critical to an organization that is seeking to respond to the requirements of the Sarbannes-Oxley act of 2002.
There are many relevant areas of the CMMI that seek to cover this aspect, even though the idea of IT investment is never directly mentioned. Naturally one of the main features here would be the decision process in determining how the funds and investments should be established and maintained, which should be run according to the DAR principles.
In addition to that, there is a strong emphasis throughout the project management practices that the resources and budgets need to be managed (planned, monitored and controlled) at all times. This includes the areas defined primarily in PP, PMC and RSKM, but also the approaches used in TS to determine the right technical solution to be implemented and VER and VAL when ensuring that we are achieving our objectives within the context of engineering activities.
It should be borne in mind that the engineering projects are not the only projects to be considered when implementing a process-based quality improvement programme. Creating an investment or a budget is a project and should be managed with the same care as the rest.
A lot of this area's details are about the communication and management of the policies. The implementation, communication and knowledge of the policies are a founding element of the CMMI-based process improvement effort. This is the main reason that the capability level 2 generic practices start with the implementation, communication and respect of a management policy, and finish with a review to ensure that the processes and practices that have been implemented correspond to management's aims and direction.
In addition to this, a number of specific practices support the need for the communication and management of the aims and direction. These include:
The human resource aspect is not covered directly within the context of CMMI
(it is more the objective of the "People CMM"). In particular, there is nothing
within the model regarding recruitment and termination practices. However, a
number of items related to the management of people are included.
PP SP2.2 and RSKM cover the topics related the management of risks related to staffing and people, as well as the other risks that need to be managed: dependence on individuals, personnel clearance, staff retention should be included in the risks being managed both at project and at organizational level
The management of quality is possible the key raison-d'être of the CMMI. I need not go further into this point. If you are doing CMMI without understanding that you need to manage quality, you have not understood what the point of the improvement programme is.
While too many people are restricting the risk management activities within the CMMI to the management of project related risks, it is fairly easy to understand that the other risks (e.g. product or corporate risks) should be managed along the same lines. The implementation of a risk management strategy aims at identifying risks and reducing the amount of risks related to any task. This is well covered in the RSKM process area.
Finally, we come to the management or projects. All the process areas within the project management category of the continuous representation are covered in this area. In addition to the management of the projects, CobiT requests that the projects be managed within the context of a programme framework. This aspect is not covered explicitly within the model; however it seems easy to understand that the management of projects needs to be done at least as well as the management of each project. That is to say that deciding on the priorities of the projects and establishing how the resources are going to be shared out is a key component of the IT governance process and should be managed with the same level of understanding of requirements, needs, resources, risks, costs, etc as each individual project.
To realise the IT strategy, IT solutions need to be identified, developed or acquired, as well as implemented and integrated into the business process. In addition, changes in and maintenance of existing systems are covered with this domain to make sure the solutions continue to meet business objectives. This domain typically addresses the following management questions:
The need to consider alternatives and base the solution on an "effective and efficient approach" is covered directly through the Decision Analysis and Resolution and Risk Management process areas. In addition to this, we may consider
This is naturally the heart of the engineering process areas throughout the CMMI. While going through the detailed control objectives of this area, we will cover most of the practices of the engineering process areas and several support process areas.
The focus on requirements, design and development are at the heart of the engineering process areas. The control and auditability requirements are to be found within the generic practices, in particular GP2.8, GP2.9, GP2.10 and GP3.2. Additionally we have the need for configuration management (GP2.6 and CM) and acceptance and testing procedures (VER and VAL).
The CobiT emphasis placed on maintenance is not covered directly and explicitly within the CMMI.
The technological infrastructure is largely covered within the generic practice GP2.3 which requires that the resources, including technical, be made available for each and every activity
In addition to this the supplier management process areas (SAM and ISM) assure that there are appropriate procedures for the selection and management of suppliers and their products.
Specific infrastructure requirements are covered in specific process areas, such as Validation and planning.
The main focus of this control is to ensure that the required knowledge of the new systems is made available where and when required. This is covered primarily in the following areas:
The IT resources in CobiT, as in CMMI, include all the required resources, including people, hardware, software and services. This is done through the selection of suppliers of those resources as well as the management of the resources internally.
Naturally, the first area where we will look is the GP2.3 in which "adequate" resources are required for each and every process in the model. In addition to that, we have planning for skills and knowledge (PP SP2.5 and IT SP2.1) as well as other resources (PP SP2.4). The usage of Decision Analysis and Resolution within the framework of supplier selection and management completes the picture.
Change management is a key component of any development or engineering environment. In this case, we see the key elements for the change management practices within requirements management, configuration management and project monitoring and control as far as the project is concerned. In addition, we find the management of change permeates the organizational process focus and definition areas as well as the more complex organizational innovation and deployment process area.
The main concerns of this section cover the requirements for testing and release of the product. Most of the practices required are covered in the verification and validation process areas. Additionally, some of the requirements are covered by the product integration practices, particularly SP3.3 and SP3.4, which cover the delivery of a completely evaluated product.
There are additional requirements in CobiT that are not explicitly covered by CMMI. They include the requirement to "automate the system used to monitor changes to application systems..." and the requirement for a "post-implementation review of the operational information system", which goes beyond the milestone review that we would find within PMC.
This domain is concerned with the actual delivery of required services, which includes service delivery, management of security and continuity, service support for users, and management of data and the operational facilities. It typically addresses the following management questions:
A lot of emphasis of the CobiT in this case is placed on the security of the data and the infrastructure. The CMMI focuses more on the processes required for the creation and development of activities and does not directly reference the need for security aspects, except obliquely by mentioning that "security requirements" need to be included in the project plan, or through the risk management process area.
The requirement for good communication between the development organization and the customers and, in particular the definition of the services that will be provided is self-evident in any reasonable engineering environment. The CMMI is frequently criticized for the lack of reference to the customer and the customer needs. This is naturally covered throughout the model through the usage of the term "stakeholder".
In addition to the above a number of business requirements related activities are found throughout the model. They include the business policy requirements (SP2.1) and control (SP2.10) found in every process area, as well as key process areas such as those related to requirements (RD and REQM). The service levels are further managed through the implementation of a valid measurements and their analysis. The usage of these measurements for the identification of process needs and improvements furthers this option. This is finally strengthened by the process performance measurements and quantitative project management to ensure that the service level is maintained throughout the development cycle.
The management of third-party suppliers is found in the CMMI in the "supplier agreement management" and "integrated supplier management" process areas. These two areas effectively cover the requirements of the identifying the services, categorizing them according to supplier types, maintaining formal documentation of relationships, formalizing that relationship, ensuring quality of work and transparency of communication, managing the risks and monitoring the performance of suppliers.
The requirement to be able to manage the performance and capacity of the IT resources is clearly an implementation of the relationship between plans that is covered in the SG1 of the CMMI's Integrated Project Management process area. The requirement here however does go further.
While the CMMI does make a number of requirements in relationship to planning for resources and skills and being able to monitor the availability of those resources (particularly in PP and PMC, but also in SP2.2, SP2.3 and SP2.8), the focus of the CMMI remains on the project rather than on the long-term usage of resources and capacity. One could argue that the management of a programme along the CMMI guidelines would cover this aspect; however the requirements of CobiT would be best covered by bringing the PP and IPM process areas up to capability level 4 in the area of planning for resources and skills.
The continuity and contingency requirements of CobiT could be covered by an implementation of risk management in which the risks of disruption and disaster are properly covered; however the topics of security and continuity are not covered within the CMMI, except obliquely through ensuring that resources are provided, etc.
As with DS4, the security requirements of CobiT could be covered by an implementation of risk management, however the topics of security and continuity are not covered within the CMMI, except obliquely through ensuring that resources are provided, etc. Certain aspects of these requirements should be covered in the data management plan (PP SP2.3).
The management of the IT costs and the allocation of the resources appropriately are done through a good implementation of the process area "decision analysis and resolution". Also, there is coverage of the allocation of the costs through the budget management practices (PP SP1.4 and SP2.1). Again, the CMMI's focus remains at the project level, while the CobiT focus is at the organizational level. Both areas overlap but address different things.
The identification and delivery of training needs for the users, as for the organization are largely covered by the process area relative to organizational training. It should be noted that the organizational training process area does not specifically address the needs of the users by opposition to the needs of the project team members. However, it should be understood that the training needs of the users are requirements that need to be managed and allocated as with all other requirements. The documentation is developed and delivered in parallel to the product (TS SP3.2) and the training courses that need to be developed and delivered are done according to the processes defined within OT SP1.4 and OT SP2.1.
The management of a service desk and incidents is not explicitly covered in the CMMI, however, there are detailed explanations regarding the need for management of change and understanding the customer needs. The requirements management process area does cover some aspects of this control.
The CMMI has a significant number of requirements regarding configuration management. The requirement within the CMMI focuses on ensuring the consistency of data across the life of the product - this is covered both in the configuration management process area and the related generic practice (GP2.6). As is usual within CMMI, the manner in which this is performed is not considered.
CobiT is slightly more demanding, requiring more than just the results and requiring that a single central repository be established which includes "hardware, application software, middleware, parameters, documentation, procedures and tools for operating, accessing and using the systems and services."
The identification, management and resolution is naturally a key element throughout the CMMI, it is one of the guiding factors in project planning and monitoring and control.
In addition to this,
Within CMMI data management is referenced directly in three process areas: project planning, project monitoring and control, configuration management. In addition to that, there are some practices that reference the obligation to understand the needs of the organization and the risks related to the management of the data as well as other aspects. MA SP2.3 references more particularly the storage needs for measurements so as to ensure that they are available and protected appropriately.
Again, the CobiT's requirements for security and backup aspects are not covered explicitly within the CMMI but are only referenced or alluded to in various subpractices.
Once again, we are in a context that is not covered by the CMMI. The physical environment is specifically identified as something to be considered in the context of each process area under GP2.3 which requires the provision of appropriate resources. In addition, there is some reference to the physical environment in the project planning and monitoring process areas. A clearer reference is included in RSKM SP1.1 where it is mentioned as a potential source of risks.
This control references procedures, scheduling, monitoring and management of documents and hardware. Most of the requirements here will be covered by most of the CMMI. In fact, the answer to this area is probably one of the key raison d'être of the CMMI as a whole. The area covers most of the maturity level 2 requirements in terms of management of people and projects as well as configuration management.
All IT processes need to be regularly assessed over time for their quality and compliance with control requirements. This domain addresses performance management, monitoring of internal control, regulatory compliance and providing governance.
It typically addresses the following management questions:
The monitoring and evaluation of performance is identified as a critical practice is many places throughout the CMMI.MA focuses naturally on identifying the needs in terms of measurements, monitoring and control of processes and practices at the organization level. This is identified as one of the most important process areas and is recommended as a key starting point for any quality improvement programme.
Naturally, all these areas are directly related to the need for appropriate corrective (CMMI) or remedial (CobiT) actions.
This control talks primarily about "controlling the controls". Controls are one of the key aspects of the CMMI and typically one of those that create most resistance when they are being implemented within a low maturity organization.
This control focuses on the need to have appropriate levels of reviews and audits to ensure that all the required regulations, standards and laws have been respected. The identification of regulations that need to be respected is naturally a key part of requirements definition and identifying the organization needs within OPF, OT, MA and others. In addition to that, the respect of the those regulatory needs, once defined, are part of the work to be performed by the quality assurance team, which includes the identification of deviations, the communication to appropriate levels of management and ensuring the corrective actions are carried out appropriately.
If IT governance is not directly referenced with the CMMI, all the related detailed controls are referenced. This include
The main requirement of Sarbannes-Oxley is the assurance that management is aware of the real situation and has enough controls in place to be able to demonstrate that they are completely open and above-board in their reporting. Top management takes personal responsibility, under menace of sever penalties, to ensure that the data they are reporting is completely accurate. In order to do this, they need to pay particular attention to the aspects of the IT services. Most of the reports that are generated are being done today through highly complex software-based systems that may mask or falsify data (perhaps unwittingly) through defects in the design, development, parameterization and implementation of the accounting and management software.
The CobiT approach sets out a number of objectives from a management point of view that allows understanding who is responsible and what they should be doing in various stages of the IT activities. These include a description of the controls' objectives as well as a more detailed description of what each control should be considering; management guidelines describing who should be responsible for ensuring that a number of activities are performed; goals, and indicators to be achieved at business level, process level and IT level; ratings as to how the capability progresses. All these are defined at a reasonably simple level.
This approach based on measurement, processes and controls means that a serious culture change has to be implemented in many organization to ensure that the change is implemented within the mentality of the people rather than only through the force of a "police state".
The CMMI approach focuses on achieving results from a business point of view through a continuous improvement trajectory. By implementing a process improvement programme that is based on an understanding of what the people are really doing and helping them to share the best practices, you can instil a culture in which activities such as management reviews, configuration management, quality assurance and audits are seen as a normal part of the improvement culture.
By having the defined processes in place and the controls that the CMMI recommends, you can achieve the level of communication and stability within an organization that makes the additional steps required for a Sarbannes-Oxley approach or the implementation of CobiT style controls a lot faster and easier.
This report may give the feeling that a number of CMMI requirements cover multiple aspects of the CobiT model. This is largely due to the difference in emphasis and grouping of the practices. If this report had been centred on CMMI and referenced the corresponding CobiT approaches, the results would be very different.
Achieving CMMI Maturity Level 3 does not mean you are Sarbannes-Oxley compliant; Sarbannes-Oxley is an accounting and financial reporting requirement and will not be satisfied by having your engineering processes in order. However the context will make it easier to demonstrate that the controls are in place and ready.
Achieving CMMI levels does not correspond to achieving CobiT levels. Generally the CMMI is more demanding that CobiT, however there remain aspects in each of the models that is not found in the other.
Being Sarbannes-Oxley compliant does not mean you have achieved CMMI Maturity Level 2 or whatever. Again, they look at different aspects of your business.
As can be seen in the detail of this report, there appears to be a lot of overlap between the two standards, even though they aim at different aspects of understanding and controlling the quality and reliability of the work being carried out. It is not recommended that a reasonable organization consider one standard as significantly superior and therefore ignore the other. They both ensure a quality improvement approach that is measurable and useful.
After a recent presentation at a conference in Romania on how projects needed to be managed using the whole brain, and explaining how the different elements need to interact, I was asked whether this could mean that there was a particular place for women in project management and engineering.
I have frequently been surprised at the lack of women in engineering and management positions in the Western world. When working in China or central Europe, I find a better level of parity: at the Romanian conference, focused on software engineering, approximately 40% of the participants were women - in more Western countries, that would be amazing. In the UK, I keep on hearing people complaining about the need for more women in politics, in management positions and even on bank-notes. The argument given is usually to state that half the population is female and therefore should be represented, which I find an extremely stupid argument; should we have a better representation of Asian people on British bank notes, what about redheads or homosexuals?
There are better reasons for expecting parity; but that requires acknowledging the fact that men and women are not equal: they are complementary (meaning they are equal, not to be confused with "complimentary" which would mean they are to be congratulated).
I want to give here some averages. These are based on a variety of researches and peer-reviewed publications. I do not claim that these statements are true for every man or every woman, only that we find that there is a tendency to go to one side or the other of the median line when looking at large numbers of men and women.
The testosterone in which the male brain is bathed during its formative years has a destructive effect on certain aspects of the brain, particularly the bridges between the left and right sides. It also promotes growth, which, as men are generally larger than women, means that a man's brain is somewhat larger than a woman's brain. In various tests, it has been seen that the woman's brain is more active, and more active in every part of the brain than the man's; a man's brain is more often at rest.
While a man may have better spacial awareness, the activity in a woman's brain tends to give her a better understanding of her environment, the impact and influence on people, the atmosphere, the feelings of people. This allows a woman to be better at planning and organizing things; while the man, more focused on activity, would be better at doing a job that requires continued concentration.
When faced with danger or provocation, the man's amygdala tends to provoke a "fight or flight" reaction, while the woman's will provoke a "tend and befriend" reaction. A wounded man will want to hide in solitude until he feels better; a wounded woman will want to talk, nurture, care.
The result of this, in my opinion, is that we need more women in positions of management and power: it appears that a natural tendency of women would be to be compassionate and understanding, as well as having more natural skills towards planning and organizing. On the other hand, perhaps men's ability to focus on a continued task is a reason why there are more men in the engineering world.It also explains why I would like to see more women in governments and in boardrooms. We are not equal, our differences make our value. We complete one another. That is why we need equality of opportunity, of access, of pay so that we can recognize the unique skills of every individual.
But, of course, these are generalities and each and every one of us is different and unique.
I am regularly approached by organizations who want to be appraised at CMMI Maturity Level x. When asked why, they give me a variety of responses, which basically come down to the fact that they would like a certificate to hang in the lobby. It may be that a customer or prospect has requested this, or it may be that someone on the board of directors read an article. When challenged and questioned on the level of investment, the disruptive aspect of an appraisal, management’s responsibility for the results, they often show that they have no understanding of what they are trying to do.
Another traditional subject covered is that “we are looking at achieving maturity level 3, we do not need to go higher (it is too expensive)” and the question “is this little bit enough to satisfy the maturity level?”
We must ask ourselves how much money I am willing to spend on getting a piece of paper in the lobby. It might open the door to being able to respond to a request for proposal from a potential customer, but that paper will not noticeably improve quality, time-to-market, productivity, reliability, ability to meet deadlines, customer satisfaction, employee retention, or make sure repeat business from satisfied customers. Just like a university diploma does not make you intelligent.
The aim of an improvement programme, of a change programme (using CMMI or any other technique) is to improve organizational performance, and not to implement fancy processes. If what you are doing does not help you to manage your organizational performance, you are wasting time and energy and not really improving anything. It is the difference between studying what may be useful in your career and studying to pass the test and forget everything the next day. CMMI, ISO, Six-Sigma, Lean and the others are not necessary to improve organizational performance: they are tools and if they are used intelligently, they may help guide you, but implementing them without thinking will only lead to expensive long-term failure. Within CMMI, there is a process area called “Organizational Performance Management” (or OPM). OPM is listed at the highest level (maturity level 5), because this is the goal, the rest of the model, practices, goals, process areas, etc. are only some of the steps which are required to be able to manage your organizational performance effectively and efficiently.
Managing performance requires understanding performance. That can only be done when you have stabilized the performance of your teams, projects, services and are delivering products in a predictable way. In order to do that, you need to understand the level of predictability of your most important work practices (or processes), which means they need to be regularly monitored and analysed. You can only do that if you are sharing the practices in teams and projects enough to get statistically significant data. And of course, you only want to share the practices and processes which are bringing real benefit to your business, your staff, your products and services.
And so, we look at what you need to do, from the beginning, we can travel through your capability maturity (maturity is how well you know your own strengths and weaknesses, how well you understand what are the limits of your potential, this comes with time, experience, successes and failures).
The first step we must consider is what you are trying to achieve. If I talk about your productivity, what do you understand? Are you trying to produce the highest number of widgets, reduce the time to market, offer zero-defect products, or be the cheapest service provider in the world? This is necessarily the first step in your improvement programme: decide, define, document and distribute your vision for the organization; there is little point in trying to be recognized as the best in the world, if your staff is cutting corners to keep down costs. Your goals are well communicated, and you are putting metrics in place which support them. From the start, you need to understand that people act according to how they are measured. I am always amazed at the number of companies which tell me that “quality” is their primary motivation, but then only measure delays and budgets: you are in fact communicating that quality means fast and cheap.
After this, you need to allow the professionals to do their jobs as they believe is most appropriate to meet these goals. The results, practices and methods are analysed and compared so that we can figure which are the tools, practices and processes worth sharing across the organization. Once they are shared, we can start to measure the predictability of the results and refine them which will finally allow us to manage our organizational performance.
The starting point is not to identify steps and document this as the standard process which must be obeyed at all costs. The starting point is not to just talk about quality, but measure only delays and budgets. The starting point is not to find the minimum required to satisfy some theory; the starting point is to inspire your teams to reach the end-point.
The end point is organizational performance management.
In CMMI terms: maturity level 5 is the only destination possible, the rest are dead-ends.
When the waiter shows you the label on the bottle of wine, that "Verification". When he pours a little for you to taste, that's "Validation". It's that simple.
When coming into an organisation for the first time, I am always surprised at the lack of understanding of the concept of quality. Of course, management talk about quality and the need for quality. But, when I ask for a definition of quality, they do not really know, or -- worse? -- they state banalities like "fit for purpose" without really understanding what that means. If I bring up the topic of measurement, they will typically tell me that they measure time-to-market and budget; but maintain (because they believe that is what I want to hear?) that quality always comes first. To make things worse, they implement a "quality assurance" group, based on something they have read and not quite understood, which does not consider assuring quality, but controlling compliance to some standard. Naturally, respect of standards, in particular industry related standards such as those in place in the financial, security or transport industries. But the respect of standards and the certificates hanging behind the receptionist's desk are not guarantees of quality.
Understanding quality is the most critical aspect of your job, whatever it is. Quality is what differentiates your products and services from the others. If your sole focus - as reflected by measurements is quick and cheap, you will lose the battle: there will always be someone cheaper than you.
Quality involves understanding the expectations of your customers and the aspirations of those who are not yet your customers. Quality involves the right mix of innovation and tradition. Quality requires commitment and leadership. Quality means understanding your own skills and limitations, and when to call on external skills to assist you in overcoming a particular issue or hurdle and when to make sure you do it on your own.
Quality starts with the people doing the work: they need to understand your vision of quality which needs to be communicated in a clear and memorable manner, then reinforced through every action, every standard, rule, process, principle or communication. Measurement follows; once you have a clear and clearly communicated vision of quality, measurements can be easily identified and implemented throughout the organisation.
Then your quality will be reflected in the attitude of all team members and, more noticeably, in their level of job satisfaction. Few people are satisfied when they are encouraged to rush their work, even less are interested in filling out forms and following bureaucratic standards. But, knowing that someone out there is, consciously or not, appreciating your work...
Once the team members have job satisfaction, we will be able to build up trust, that precious commodity which is so lacking in many management-staff relationships. Trust means that team member meet their commitments, they do not need a lot of paper work telling them what to do, when and how, reporting what they have done, etc. You know that they will do as they agreed, they will show up on time and they will go to their management if they feel they are not able to perform as expected. But, first, they need to believe in your vision of quality.
"Time is Money" Benjamin Franklin made the assertion in 1748 (it was used in various manners before this, since antiquity, but this is the generally recognized origin of the phrase as quoted); the first result of this was the encouragement to start paying workers by the hour instead of paying them for the work they were accomplishing, which is probably a critical change for our "post industrial revolution world".
Over the past few years, something has happened in the world. Sometime during the second half of the twentieth century, we ran out of time. Notwithstanding an amazing list of "time-saving" devices, it seems that people have less and less time available. They don't have time to cook a meal, they don't have time to walk to work, they don't have time to day-dream, they don't have time to go to the theatre .. and then, as a natural result, in the beginning of the twenty-first century, we ran out money as well. If time is money, it stands to reason that no-time is no-money.
This is true in our personal life, but it is also true in the business world. I see many companies and one of the most common complaints I hear is that "we don't have the resources we need..."; my response is always the same: you have the resources you need, the problem is you have too much work. When the day is used up, there are no spare minutes. Does this mean that companies need to learn to refuse work? Do we need to send our customers to our competitors because we are full? Possibly, but more likely, you need to learn to focus on what really matters. The twentieth century French author Boris Vian said (I believe it was in "L'écume des jours") that people spent too much time living instead of working. What he meant was probably the opposite of you are thinking: he explains that you should take the time to think how to do your work more efficiently, develop the tools that will help you, but you are in such a rush to get things done, that you forget to take time to improve your work habits. You have probably heard the story about the lumberjack who had so many trees to cut, he did not have time to sharpen his saw.
Imagine an organization in which the roles and responsibilities are well defined. The people who were hired because they are good at their job are focused on doing the job at which they are good, rather than sitting in meetings, trying to repair their computer, being called off their work to help the sales team fill out a bid. Imagine an organization in which you could focus on doing your job, doing your work from beginning to end, without significant or frequent interruptions...
It has often been demonstrated that if people can do three jobs, one after the other, all three will be finished earlier then if they are required to do all three at the same time because they are all high-priority. Yet, managers continue to get their engineers, their technical staff and their project managers to share their time on a continuous basis between multiple completely different projects and activities.
Most companies now appear to live under the idea that faster is better, promises are made to customers without a clear understanding of the time really required to do the work, employees are pressured into producing faster. Management needs to learn to allow staff to concentrate on their work, take the time to do the work correctly, with adequate time to check what they are doing and think about how best to do the work for which they were hired. By being able to do the work correctly, and take the time necessary to do the work efficiently, they will be able to produce higher quality work, thus reducing the time and cost required for quality verification and validation activities, correction and maintenance.
Invest time, because time is money, and there is no return on investment without an investment.
It is so rewarding when one gets the opportunity to encounter real maturity and growth. When I first visited this company a little over two years ago, it was a typical organization, seeking to have a CMMI "certification" in order to be able to advertise their success. They had made the usual mistakes, taking short-cuts in the wrong places, trying to force through an approach that did not really correspond to the company's culture or their business objectives.
Today, I am faced with a company that is well on its way to a successful maturity level 4. Engineers are telling me how useful quality assurance is, people at every level of the organization can explain how an intelligent use of measurements has made them more productive, has increased the quality of the products and services they deliver to their customers. Staff are pleased with the way things have progressed, particularly over the past year. The expansion of the company has been facilitated by this improvement, as they have learned that rather than using CMMI to attract customers, it is more interesting to use quality to keep them.
Measurements and trends of cost of quality and numbers of defects are progressing beautifully. Of course, all is not perfect, but progress is accelerating in all aspects. They are demonstrating how an international organization can combine a successful, flexible and cost efficient approach through a combination of Agile, CMMI and Prince2.
Over the past few years, I have given them some training, I have tried - as is my wont - to educate rather than to instruct them - and so, I feel I can take some pride in this beautiful success story, but they did it. They understood the principles, they changed the culture, they used training and well placed measurement. They understood that the principles behind models and standards are focused on communication, learning and sharing - and not (as many would have you believe) on bureaucracy and pointless paperwork.
I am proud of this company, and I am willing to grab my little bit of responsibility in their success. But, more than anything, I need to say: congratulations, ISDC! Keep it up.
Statistically, there are about nine men for every woman in the world. This is based on a survey of the Holiday Inn breakfast room this morning.
Based on historical evidence, on average I do not die.