1

IT governance for SMEs

Part 1.

Software development is a complicated process and requires careful planning to produce

high quality software. In large software development projects, release planning may involve a lot

of unique challenges. Due to time, budget and some other constraints, potentially there are many

problems that may possibly occur. Subsequently, project managers have been trying to identify

and understand release planning, challenges and possible resolutions which might help them in

developing more effective and successful software products. This paper presents the findings

from an empirical study which investigates release planning challenges. It takes a qualitative

approach using interviews and observations with practitioners and project managers at five large

software banking projects in Informatics Services Corporation (ISC) in Iran. The main objective

of this study is to explore and increase the understanding of software release planning challenges

in several software companies in a developing country. A number of challenges were elaborated

and discussed in this study within the domain of software banking projects. These major

challenges are classified into two main categories: the human-originated including people

cooperation, disciplines and abilities; and the system-oriented including systematic approaches,

resource constraints, complexity, and interdependency among the systems.

A satisfactory release for software can be attributed to the well organized and planned

process. Software quality can be achieved through identification of real software defects and

adding suitable features for the new release. This section presented the challenges found during

re-analysis in step 3. The twelve challenges presented in the following section are the findings

from the discussions and the analyses made in the study. Projects and all their characteristics are

2

available in Appendix A, Table 2. Target time of releases One of the most important questions

that project

Danesh and Ahmad 961

managers are challenged with in release planning is when to release the next software

version. The time taken from when the software is conceptualized until it is being available for

new version is important to be planned to ensure that the software is not outmoded in more than

one release. This time refers to the time needed for a new release of product or project and

setting this period of time effectively is a particularly crucial ingredient in successful release

plan. The challenge is to determine an acceptable time of release for a project. All the

interviewees were mainly concerned on time scheduling and one of the developers mentioned

that he always faced problem on the amount of time allocated to him to finish his work. The

setting of time for release planning can be of fixed intervals or flexible ones. For some projects,

this time is fixed and pre-determined and in others, it is flexible or based on new demands or the

condition of the project. In Damoon project, the time for release is fixed and is determined twice

a year. Based on the new requirements of the users, they provide a new release. In Saba, the

release time is considered crucial and it is identified to be three times a year. Three new releases

have been provided annually and until now they have had a total of 6 releases based on their

customers‟ requests. The release time for PKI/CA is fixed and is once a year. Its project manager

intends to concentrate more on security aspects for each new release, because security is one of

the most important considerations in this type of projects. In EXIMBILLS, the time of new

release is flexible and depends on many factors. Creating a new release for EXIMBILLS is based

on new functions and new requirements of banks and Swift organization. There are many

functions planned in this system that must be implemented in the future. In the ILS, a new

3

release is flexible due to the changes in rules and regulations. For this project, they have already

made 9 releases. To set the target time of releases is so much dependent on many realistic factors

of the projects. Hence, the manager has to be aware and sensible to the project they are handling.

Resource constraints One of the main issues that all of the interviewees complained with

their projects, was the problem of resource constraints. If the needed resources were available in

abundance, then the project duration could be shortened to achieve a new release. On the other

hand, if the needed resources are severely limited, the project is more likely to be delayed. When

a new requirement or feature is decided and planned for a next

release, many constraints like time and effort must be faced and planned. Resource

constraints are clearly a key aspect of release planning (Ruhe and Saliu, 2005), since without

considering resource constraints the consequence would be an unrealistic release. In all these

projects, there were no serious financial constraints, because most of the customers were banks

and government institutes but sometimes payments to the client companies were delayed due to

some avoidable circumstances. Damoon and Saba projects face expertise constraints. The

projects have difficulties trying to find required expertise in the area. Project managers believed

that they were “always behind technology in these two projects”. In EXIMBILLS, there was

always the risk of being behind the new version of the system software, because EXIMBILLS is

a new trade finance system for Iranian banks and it is not yet fully understandable in their

requirements and directions. In the PKI/CA project, its project manager perceives that the

project‟s security aspects are hard to attained and achieved. Thus, its project manager is always

willing to increase his investments to improve the overall security aspects of the system.

Unavailability of the new technology was one of their problems in this area as well. In ILS

because of the complexity of the systems, every change needed a lot of budget and time, either

4

from financial or human resources aspects. The project manager scared of new changes and

sometimes tries to keep the old system. Developers always feel that they are working in an old

technology environment and they wish either to change these old technologies or leave the

project. Unclear objective of the system The objectives as stated in (Saliu and Ruhe, 2005)

describe the desired properties for a product, or stated differently, the goals of the product.

Sometimes these objectives are related to a project strategy, features, content, quality, aims and

satisfaction. In many large software projects, the ambiguity in the objectives can lead to many

problems in generating releases. Unclear project goals and objectives, and frequent change of the

objectives during the project are key factors in failures for release planning. In Saba, the

managers, initially were not sure of how secure their system would be. The reason was that the

system is supposed to be the first Internet banking solution which was going to be used in Iran

and there happen to be many new changes which are unpredictable and unplanned for at the

starting of the project. The bank which will be using the system is actually the largest bank with

over 40 million customers. So, many uncertainties and worries arise around the project that leads

to a poor progress. Like Saba, Damoon faced some changes in objectives which were not

planned before. In Trade Finance (EXIMBILLS), all operations in Iran were manually performed

before implementing this system. Therefore, they always fear of the risk of customer

dissatisfaction or reactions to the system. At this point, the project is expected to face many

changing objectives which might be driven by the customers‟ response to the system. The

stakeholders of ILS project have so much concern on its return on investment (ROI). At the same

time, the project has many requirements which are changing regularly and the rules and

regulations set by CBI (Central bank of Iran) were constantly being modified. Therefore, the

project management has to endlessly put lots of man/days effort to ensure the project is able to

5

meet the demands. ILS project eventually managed to break even financially this year. In

PKI/CA, the security risks was always the main issue in the system, as the project management is

not very sure how complete the project‟s security requirements are set up. In general, it can be

observed from the projects that frequent changes and unclear policies and strategies of the

system can cause hindrance and difficulties in the process of the development of future releases.

Project monitoring by managers One of the main concerns of the managers in all these projects is

monitoring the progress of the projects. It is crucial for project managers to have an accurate

progress report to enable release planning to be successful. Almost all the project managers

believe that project monitoring would have a significant effect on the quality of the new releases.

The important element is that the ability to identify or recognize a problem in software

development process. Once a problem is detected and the problem may be tackled and it can be

no longer present for a new release. If the monitoring is done properly and thoroughly,

achievement of the final goal would be much easier. In all projects, after constructing a Gantt

chart, the project managers is responsible to update the tasks and if any of the tasks were behind

schedule, then the required resources were needed to overcome the shortfall. The monitoring

process in Damoon and Saba was taking place on regular weekly basis, with the exception that in

Saba the resources can be modified according to project needs. In PKI/CA that process was

regularly on monthly basis, and it was taking place every two weeks. In EXIMBILLS, since it is

a new system and the system‟s main structure is not defined yet, there is no fixed schedule for

the monitoring or reporting process. In ILS,

Danesh and Ahmad 963

the monitoring process was regular and it is performed once a month. In short, project

managers monitor the work progress in order to evaluate the flow of the project under

6

development, with the aim of improving future project functionalities. The managers emphasized

that project monitoring is a challenge and the monitoring process has helped them tremendously

to plan easier for the next release. Complexity of the system One of the important elements that

can delay or cause problems in large projects for delivering a new release is the complexity of

the system. This complexity can be innate and is usually seen in all large software projects. Most

project complexity cannot be possibly eliminated completely and can only be reduced.

Sometimes, technical constraints can also cause complexity. Technical constraints refer to any of

a number of technical issues and obstacles that will impact the new release. For example, a

company might be trying to connect many banking branches to a central location via links and

this can produce complexity to the system. Size of the project is another concept that affects the

complexity in each system, because some projects may have hundreds to thousands of features.

In the Saba project, the complexity of the system increased due to the need to connect the

application server to the mainframe running on COBOL/CICS/IMS environment. Project

managers strive hard to decrease this complexity by using the IBM CICS Transaction Gateway

(CTG). This connection problem was also observable in Damoon. In Trade Finance, no big

complex issue was in the system as the platform was on PC environment and the connectivity to

mainframe was always on batch mode and via file transfer (FTP), but the swift messages in

EXIMBILLS were not received on time. The complexity in the ILS was in its data base. They

had two choices: one was to use the existing IMS and the second was to use a better and new

engine such as Oracle, DB2 or Informix. Eventually, they decided to use the DB2. In PKI /CA,

the complexity was the construction of the security room for their system as the room must had

been designed in a particular setting and arrangement with specialized software and hardware

platform with high level security in mind. As it was a new platform they always felt the risk of

7

things not going according to plan. PKI /CA is one of the largest projects in Iran with a lot of

requirements and new demand features, and this cause the project‟s complexity. This complexity

is expected to delay the new release for a few months and even year. For this reason, an

innovative solution to decrease these complexities is required.

Prioritization of requirements or features Prioritizing requirements can be seen as the

process of deriving an order relation on a given set of requirements, with the ultimate goal of

obtaining a shared rationale for partitioning them into subsequent product releases (Avesani and

Susi, 2004). A project manager has to balance the project scope against the constraints of the

schedule, budget, resources, and goals. One balancing strategy is prioritization to drop or

postpone low priority requirements to a later release when there are new, higher priority

requirements. Therefore, it is very important to decide what the prioritization is based on.

Different prioritization techniques can be used in different projects depends on different

parameters.

In release planning tools, there have been a few techniques used for prioritizing the

requirements. Some comparisons are made in (Karlsson et al., 1998). Requirement prioritization

is used in software release planning for assigning which candidate requirements of a software

project should be included in a certain release. When customer expectations are high, time is

short, and budget is limited, you want to make sure the product only

Danesh and Ahmad 965 contains the most necessary features. So, it is important for

managers to prioritize what to include in a next release. The team must collaborate on

requirements prioritization. Damoon, Saba, EXIMBILLS and ILS are Customer centric. They

allow the customers to dictate the priorities for the projects‟ requirements. These projects have

many customers or end users for their banking operations, so the customers‟ demands are high

8

and the necessity of prioritization is considered important. PKI/CA project is more government

centric. The government always has the upper hand in dictating the priorities. This system is

crucial for Central bank of Iran and hence they have the first word in setting the priority. The

project manager mention to us that usually during the meeting with the, central bank, the bank

will instruct them on what to do and the development team has to follow the order obediently.

Supporting old releases One of the issues that always worry project managers is the capability of

a new release to support older releases. Most of the time, it is expected that a new release is

expanded to cover all of the previous releases. However there are occasions that the new releases

are less efficient than the older ones and the users might later on find out and demand to use the

old releases. Therefore, managers are always striving to have the best possible features in the last

release. Usually, a new release is produced when there many requests or requirements made by

customers on the product. As the result, the teams may suggest to bundle the appropriate features

together and then construct a new release to be deployed. On the other hand, according to the

project managers, whenever there is a new release many possibilities might occur even though

many testing and quality assurance procedures have been performed. The most concerned issue

is to ensure that a new release must always support old releases. Software support tool for release

planning

Release planning is a complex process which needs intensive human expertise and

knowledge. It includes many demanding tasks like resource estimation and setting objectives in

release plan generation and decision making. These tasks altogether call for an intelligent tool

support that would be of great value to a project manager who is going to make release decisions.

Most project managers agree that the whole process of preparing, constructing, resource

allocating and so on are very formidable tasks that need to be well planned to be executed. Most

9

of the time, they do not have a proper tool in order to assist them in these difficult operations.

Most managers are looking for some support tools to assist them in this process. Many of them

believe that software tools might give them extra advantages to possibly create a more effective

plan for their releases.

Part 2.

The Control Objectives for Information and related Technology (COBIT) is a good

framework strategy to help an organization maintain standards and develop a system of IT

governance. COBIT is a common methodology used by many companies in order to develop a

systematic means to meet compliance laws.

COBIT is short for the Control Objectives for Information and Related Technology and

was developed by the Information Systems Audit and Control Foundation, ISACF in 1996.

ISACF, founded 1969 later became ISACA, Information Systems Audit and Control

Association. ISACA, is now a global organization with over 50 000 members in more than 140

countries. The founders, a group of IT auditors, recognized the increasing need for control within

IT organizations and decided to create a network for information and guidance in the field. In

1998 ISACA established the IT Governance Institute, ITGI, who is now responsible for COBIT.

During the fall of 2005, ITGI released a version 4.0 of COBIT which constitutes the framework

of reference in this thesis.

COBIT was originally developed as a tool to control IT and reduce risk within IT organizations,

primarily in the banking and e-business industries. It has evolved to become more business

oriented and now gives a high level image on what to accomplish within an organization rather

than how. It is designed to provide fundamental guidance to management and process owners to

10

in best way possible allocate the assets of the organization. Figure 3 shows the overlying

framework principles.

The COBIT framework has the aspiration to be both responsive and practical in the sense of the

business needs, while at the same time being independent to the technical and structural

differences within various organizations. COBIT uses ideas from all frameworks above and even

more standards when creating its definitions and controls.

“For this COBIT update (COBIT 4.0), six of the major global ITrelated standards, frameworks

and practices were focused on as the major supporting references to ensure appropriate coverage,

consistency and alignment”26 The standards, frameworks and practices mentioned in the quote

above are:26

Committee of Sponsoring Organisations of the Treadway Commission (COSO):

− Internal Control—Integrated Framework, 1994

− Enterprise Risk Mangement—Integrated Framework, 2004

Office of Government Commerce (OGC®):

− IT Infrastructure Library® (ITIL®), 1999-2004

International Organisation for Standardisation:

− ISO/IEC 17799:2005, Code of Practice for Information Security Management

Software Engineering Institute (SEI®):

− SEI Capability Maturity Model (CMM®), 1993

− SEI Capability Maturity Model Integration (CMMI®), 2000

Project Management Institute (PMI®):

26IT Governance Institute (2005), COBIT 4.0

FIGURE 3 – COBIT, OVERLYING FRAMEWORK PRINCIPLES.

11

SOURCE: IT GOVERNANCE INSTITUTE, COBIT 4.0

24

− Project Management Body of Knowledge (PMBOK®), 2000

Information Security Forum (ISF):

− The Standard of Good Practice for Information Security, 2003

Originally the framework was based on three separate documents:

Control Objectives is the first of the documents that describes the 34 processes and the control

objectives to each process employed by COBIT. The maturity levels are not regarded in this

section.

Management Guidelines presents the maturity levels and the two measurable indicators

connected to each process type.

Audit Guidelines is based on Management Guidelines and provide advice on who to interview

and what kind of information is demanded to each process type.

THE COBIT FRAMEWORK

COBIT provides a detailed and easily used model to govern IT. The structure and

interrelationship of the processes that COBIT treats is shown in Figure 4. The COBIT control

objectives document is divided into four domains that describe the risks and activities within IT

that needs to be managed. The domains in turn are divided, in all into 34 different high level

control objectives or processes. The processes each encompass detailed control objectives,

activities, roles, different metrics and an incremental measurement scale. The roles in turn have

responsibilities associated to the activities.

The processes apply at different levels of the IT organization and each domain could help to

provide an understanding of the purpose of the processes. The names of all the COBIT processes

12

are displayed in Figure 5. The four COBIT domains; Plan and Organise, Acquire and Implement,

Deliver and Support and Monitor and Evaluate as shown in figure 5, are clarified below.

− Plan and Organise (PO) describes how the business objectives are best reached through the

use of IT. This domain administrates the use of tactics and strategy to plan, communicate and

manage the different perspectives throughout the organization.

− Acquire and Implement (AI) depicts the identifying and acquiring of IT solutions.

Furthermore this domain explains the solutions integration to the business processes and how to

manage and upkeep the existing systems.

− Deliver and Support (DS) handles the actual delivery of the information at hand and see to

the management of service levels, performance and capacity, configurations, operations and the

physical environment, to name a few. This domain is also responsible for the identification and

allocation of costs and the training of users.

− Monitor and Evaluate (ME) describes the monitoring and evaluation of all the processes

employed by the IT organization. This domain also delivers the final statement to “provide IT

governance”

Why COBIT?

COBIT consists of 34 IT processes and is a way for an organization to use in its attempts

to "balance risk and control in a cost-effective manner" (Pederiva, 2003). With newer regulations

such as SOX, HIPAA and other government imposed laws, compliance is a necessary item for

organizations to think about, because the costs associated with non-compliance can come with a

high price tag.

13

These newer legislations have led businesses to have to cope with several quandaries, and

many of them are associated with change and the difficulties associated with the task of enacting

these changes.

Conforming to new laws and regulations entails a lot of alterations, and it is probable

more legislative changes are on the horizon and being prepared by having established control

processes can't hurt.

How COBIT Assists with Compliance

As a part of making changes in order for a company to align with the law and be in total

compliance, companies can utilize the COBIT Framework; it is a tool that can assist in both

internal audits and corrective action.

Using COBIT can help lead businesses towards the path of regulatory compliance

because it systematically outlines the steps a business needs to take to be in accordance with

legislative constraints.

Fundamentally COBIT's structure offers best practices for users to measure their own

business processes. Subsequently they can identify, improve and/or modify any weaknesses in

the various IT control areas that are discovered.

COBIT and Internal Controls

In Section 404 of SOX there is a mandate for the creation and maintenance of feasible

internal controls when it comes to organizational data and information. Due to this mandate,

companies have to test their internal control processes and meet this SOX requirement and pass

an external audit.

Since internal controls affect everyone across an organization at all levels, internal

auditing, monitoring and control is an ongoing process businesses need to engage in to remain

14

compliant. To continue remaining compliant, this is going to need to be revisited on a regular

basis to ensure conformity to laws and regulations.

When faults are found, the company will need to take corrective action, or be penalized

when it fails an external audit. Ideally, the overall goals of organizational quality and compliance

that meets mandates such as SOX, specifications can be accomplished through use of COBIT

methodologies.

Another benefit to COBIT is it helps conduct internal audits because the fundamentals of

internal auditing closely examine the organization's capacity to be in compliance. After the audit

is conducted, the processes then pave the way for subsequent corrective action to occur in the

identified problem areas that may have gone by unnoticed otherwise.

Organizational Change

In addition, since the very nature of change is often led with resistance, confusion or

anxiety, COBIT can help alleviate some of those factors because it is very methodical. Those in

charge of leading the change can follow the steps and present these steps to the rest of the

organization to follow.

Change is easier when the chaos factor is eliminated and COBIT can help a company

meet its compliance objectives and promote change at the same time. When it comes to

compliance, companies have no choice but to enact change and the swifter and smoother the

process goes, the easier the organizational change will be.

COBIT and Business Strategy

Companies who use COBIT as a means to help implement IT governance often find that

this also helps their overall business strategy.

15

Compliance does not come without a hefty price tag, but if companies can marry their

strategy and governance using IT, it becomes a win-win situation. Using a COBIT framework

can help bring both strategy and compliance to fruition.

This benefit is a good motivator because when used strategically, technology gives

businesses a competitive edge, and those companies who can successfully obtain this advantage

and meet compliance needs at the same time are able to bring down the high costs of governance.

While there are other frameworks, COBIT framework is an established methodology that

can help provide an organization with the tools necessary to promote a better system for IT

governance in an organization.

Governance requires a balance between the conformance (i.e. adhering to legislation,

internal policies and audit requirements) and performance (i.e. improving profitability,

efficiency, effectiveness and growth) goals, as directed by the board [7]. IT (information and

related technology) governance is defined as a structure of relationships and processes to direct

and control the enterprise toward achieving its goals by adding value while balancing risk versus

return over IT and its processes [7].

The best practice of implementing IT governance is COBIT (Control Objectives for

Information and Related Technology). According to COBIT, principles of IT governance are

direct and control, responsibility, accountability and activities. Also the focus areas are given as

strategic alignment, value delivery, risk management, resource management and performance

measurement. The delivery of information is controlled through 34 high-level objectives, one for

each process. For controlling this delivery, COBIT provides three key components, each forming

a dimension of the COBIT cube: Business requirements, IT resources and IT processes. COBIT

has 4 domains [7].

16

In Plan and Organize (PO) domain, formulating strategy and tactics, identifying how IT

can best contribute to achieving business objectives and planning, communicating and managing

the realization of the strategic vision are performed. This domain consists of 10 processes. In

Acquire and Implement (AI) domain, changing and maintaining existing systems and

identifying, developing or acquiring, implementing and integrating IT solutions are performed.

This domain consists of 7 processes. In Deliver and Support (DS) domain, service support for

uers, and the management of security, continuity, data and operational facilities are performed.

This domain has 13 processes. In Monitor and Evaluate (ME) domain, performance

management, monitoring of internal control, regulatory compliance and governance issues are

performed. This domain consists of 4 processes. The business requirements are effectiveness,

efficiency, confidentiality, integrity, availability, compliance and reliability. And IT resources

are applications, information, infrastructure and people according to COBIT.

The main objective of the paper is to relate and construct a mapping between COBIT

framework and ISO 27001 standard when governing an enterprise. Both of the frameworks are

complementary and may be more beneficial to enterprises provided that they are used together to

fulfill the information security governance issues.

So as to govern an enterprise fully, integration of COBIT and ISO 27001 issues is

indispensable. Implementing only COBIT addresses all of the information security duties.

However, several standards like ISO 27001, describe the duties in a more comprehensive manner

than does COBIT. Thus, in order to implement the governance in the enterprises, other standards

like ISO 27001 have to be considered.

Implementation of ISO 27001 in order to manage the security of an enterprise has some

advantages. ISO 27001 certification serves as a public statement of an organization’s ability to

17

manage information security [2]. It ensures that its information security management system and

security policies continue to evolve and adapt to changing risk exposures. Furher, these

organizations will spend less money recovering from security incidents, which may also translate

into lower insurance premiums [2] [4]. Also this standard is more detailed than COBIT, and

provides much more guidance on precisely “how” things must be done [1].

Also ISO 27001 has some disadvantages when implemented alone in order to manage

information security. It is a stand alone guidance and it is not integrated into a wider framework

for IT governance.

IT governance has some benefits. Some of those are more reliable services, more

transparency, responsiveness of IT to business, confidence of the top management and higher

return on investment [7].

Some advantages of COBIT are given below [7]:

1. COBIT is aligned with other standards and best practices and should be used together

with them.

2. It’s framework and supporting best practices provide a well-managed and flexible IT

environment in an organization.

3

3. COBIT provides a control environment that is responsive to business needs and serves

management and audit functions in terms of their control responsibilities.

4. It provides tools to help manage IT activities.

The downside of using COBIT for IT governance is that it is not always very detailed in

terms of “how” to do certain things. The control objectives are more addressed to the “what”

must be done.

18

It therefore seems logical that to get the benefits of both the wider reference and

integrated platform provided by COBIT, and the more detailed guidelines provided by ISO

27001, there can be a lot of benefit in using both together for information security governance

[1].

Information Society Strategy 2006-2010 Activity Plan, prepared by T.R. Prime Ministry

State Planning Organization, consists of several items including item number 88. This item

identifies National Information Systems Security Programme. In this scope, ISO 27001:2005

based ISMS establishment consultancy is performed in four public bodies in Turkey by

TUBITAK UEKAE. However, since there does not exist an IT governance awareness in those

public bodies, benefits of establishing ISMS have not be seen. Some of the reasons are given

below [8]:

1. TUBITAK UEKAE couldn’t find a chance to get into touch with the board of the two

of the public bodies.

2. Private personnel allocation could not be performed by the public bodies except one.

3. The allocated personnel have spent to ISMS establishment only a couple of his work

hours in a week.

4. Establishment of ISMS has been tightened only within IT department.

Some of the misperceptions by public body boards and personnel are given below [8]:

1. Scope of the ISMS is IT department.

2. The responsible of ISMS establishment is the head of IT department.

3. ISMS is an information technology process.

4. Establishment of ISMS can thoroughly be done by other organizations.

The standard sentences to those misperceptions must be as given below [8]:

19

1. Scope of the ISMS is consequently the whole organization.

2. The responsible of ISMS establishment is the head of the organization.

3. ISMS is not an information technology process, indeed it is an information security

process.

4. Consultancy service procurement can be done, however the main organization that has

to establish ISMS is the organization itself.

So as to establish an ISMS to an organization, IT governance awareness should be

complete among the organization. So ISMS and IT governance, or ISO 27001 and COBIT is

highly related to each other. When an organization wants to establish ISMS and get ISO 27001

certificate, it has to take care about the issues that COBIT says, and vice versa. There also exists

a mapping between COBIT and ISO 27001 in [3] [5]. It is a kind of building a bridge between

COBIT and ISO 27001. The key point is to govern information security not only using ISO

27001 or COBIT alone, but in conjunction with those two in an enterprise.

What’s the best way to identify and implement process improvement for your business?

Gain the knowledge you need to determine if CMMI will fit the bill.

Many enterprises fully appreciate the business value in assessing their progress through a

program that delivers a measurable maturity or capability rating. In the improvement of business

processes ranging from software development to project management, this effort can be

accomplished by instituting the Capability Maturity Model Integration, or CMMI.

What Is CMMI?

20

Current CMMI best practices are published in documents called models, which each

address a different area of business processes: 1) product and service development and 2) supply

chain management, including acquisition and outsourcing. According to the Software

Engineering Institute (SEI), in each case, CMMI contributes to the interaction of traditionally

separate organizational functions as well as to set process improvement goals and generally

guides the quality process. In software or product development, a business must ask itself, what’s

not working with our current way of developing wares? Decision makers must have a clear

answer to this question in order to understand how the CMMI model can be applied.

Why CMMI?

The business model weighs in as a primary consideration. CMMI will be a must if your

business is involved in product development for federal agencies, or if you are a subcontractor to

a federal agency’s primary contractor. If this is your customer base, CMMI may well come up in

the request for proposal (RFP).

If this is not your principal customer base, you may need more justification for

implementing a process improvement program. According to Bill Smith, president and principal

consultant at Leading Edge Process Consultants of Vienna, Virginia, and veteran SEI-authorized

CMMI instructor, “CMMI forces the business to think long and hard about business objectives.

Organizations X, Y, and Z have differing business priorities,” he says. If time to market, for

example, is a priority, it will become one of the business objectives addressed in your CMMI-

based improvement effort.

21

But clarifying business objectives isn’t the only advantage of CMMI. As Smith notes,

“When applied correctly, it helps the business to operate better, cheaper, and faster, and it

reduces risk.”

Software development is a process that may benefit from CMMI. The SEI reports that, on

average, software businesses dedicate 65 percent or more of their engineering dollars to

addressing quality issues. This means that only one-third of the organization is actually creating

something. Through the application of CMMI, software organizations can reduce this cost of

quality to 40 percent or less, ultimately freeing up funds to pursue actual product development.

CMMI is about process improvement. More specifically, it about improving processes

involved with managing how organizations develop or acquire solution-based wares. So an

important question to first consider is: Do you feel that you should be looking at improving your

processes?

CMMI normally begins with an informal evaluation, also known as an appraisal or gap

analysis. No ratings are associated with this evaluation; the results are used to set the approval

priorities of the business. Other less formal appraisals may be done as well. Finally, there is a

more formal “Class A” appraisal that compares the process or processes you wish to change with

a CMMI model. This leads to a “maturity score” ranging from one through five, where the

highest number signifies the greatest level of “maturity” for the organization. This evaluation

does require investments of time, manpower, and financial resources, and it is the only one that

can result in a level rating

22

These types of appraisals are typically conducted for one or more of the following

reasons:

- To identify how well the organization’s processes compare to CMMI best practices and

identify areas for improvement.

- To inform external customers and suppliers (where necessary or desirable) about how

well the processes of the business compare to CMMI’s best practices.

- To meet contractual requirements that mandate CMMI (for one or more customers).

Smith advises that formal business appraisals using CMMI models must adhere to the

requirements defined in the Appraisal Requirements for CMMI (ARC) document. The

evaluations focus on identifying opportunities for improvement and comparing CMMI best

practices to the processes being used by the organization. Evaluation teams use a CMMI model

and ARC-conformant appraisal method to guide their evaluation of the business and report

conclusions. The results of the appraisal are then used (e.g., by a process group) to plan process

improvements.

Smith cautions, “If your goal is not a level rating, you can do without the formal

appraisals, but you will still need to work with people who know what’s in the model. And the

model documents can run 700 pages or more,” he points out. At the very least, there should be

23

personnel available who have been through process improvements or organizational change

activity. Without this experience in-house, a business may need to invest in an outside consultant

and trainer in order to be able to use this tool for process refinements.

The CMMI Decision

So how do you decide if CMMI is the right approach for your organization? As Smith

suggests, “That depends on what you’re trying to accomplish.” Of course, the decision is also

dependent on the size and resources of the business.

Some feel that CMMI is unnecessary if the business is the master of its own

specifications. While looking at CMMI could be an advantageous consideration for those in

search of change management tools, those businesses that are not compelled to implement

CMMI solutions through RFP or contractual obligation might benefit from a different approach.

There are some obstacles for those who need or want CMMI modeling for managing

process improvements. The greatest obstacle can be a lack of knowledge as to what is in the

model. The model is substantial, and stakeholders should have at least a core understanding prior

to making the decision to embark on the journey. An important step is evangelizing CMMI to

senior management, who would have to provide both policy input and necessary funds for the

project. Selling executives on change and change management is a non-trivial task. An ROI

presentation might be in order, even in cases where CMMI is mandated by contract.

24

There are some improper or ineffective ways to implement CMMI. Probably the least

advised approach is mandating process improvement procedures in a vacuum. An example of

such a situation might be where a business gathers a project group, which subsequently develops

process documents and says, “Here is how we do project management….” Smith asserts, “If they

don’t consult those who actually do the work, it won’t work well.” Simply, the people who are

using the processes must be included in the development.

The Internal Sell

Because CMMI requires investments of time, money, and manpower to implement and

(even more important) to realize cost of quality advantages, the evangelist for CMMI must work

to foster buy-in from the various stakeholders, especially senior management. Gaining executive

support is not simply a matter of helping them to achieve a sophisticated understanding of

CMMI. The lingua franca of business executives is money. Decision making is done in the

context of money, and this is the appropriate context in which to sell the program.

For the small company, the greatest impediment to implementing CMMI is typically the

upfront costs. The advantage for smaller organizations, on the other hand, is that there are fewer

communications agents, and gaining support from the actual process users is not as complicated.

Larger companies might find it easier to absorb the costs, but there are more layers of

management and staff stakeholders to get on board.

When it comes to establishing buy-in. an ROI presentation may prove to be the most

effective approach. In this context, ROI represents a comparison of the costs and benefits of a

25

process improvement effort across a specific organizational scope and time span. Those

presenting the case for the CMMI effort must understand the scope of the analysis, the

appropriate time horizon for analysis, all relevant and related costs (e.g., training, materials,

other soft costs), and the financially quantifiable benefits. The rules of engagement: present all

cost and benefit information in dollars and cents.

Execute

ROI alone may be the selling point for senior management, but while it is a constituent

that may be vitally important, it will not necessarily improve the results of a CMMI effort. You

must execute. As with any process improvement effort, the implementation team should find

ways to leverage best practices in organizational change in order to overcome resistance to the

change. Ultimately, ROI should be determined and tracked not only for its own sake, but also

because it keeps the focus squarely where CMMI belongs…on the material benefits to the

business.

Since many organizations have been using the Software CMM or the SECM, it is

important to see how CMMI is the next generation of process improvement—a clear step

forward and upward. There are unmistakable benefits to making the transition to CMMI products

or to beginning process improvement using CMMI products instead of others.

CMMI provides more detailed coverage of the product life cycle than other process-

improvement products used alone. For example, the engineering emphasis of CMMI has

exceeded that found in the Software CMM. The process management emphasis of CMMI has

exceeded that found in the SECM.

26

CMMI products incorporate many lessons that were learned during the development,

maintenance, and use of the source models from which they were developed. Therefore, CMMI

products have addressed some of the problems found in both the Software CMM and the SECM,

for example.

Organizations that achieved maturity levels 4 or 5 using the Software CMM provided

information to the SEI on their successes and difficulties. This information was used to develop

more robust, high-level best practices in CMMI. Therefore, CMMI products better address the

needs of organizations at higher maturity levels.

CMMI provides an opportunity to eliminate the stovepipes and barriers that typically

exist in different parts of an organization and that typically are not addressed by other process-

improvement models. The combination of useful information on engineering a product and

proved practices for managing processes results in a set of well-integrated models that will

facilitate project management and improve the development process—and the resulting products.

CMMI, which integrates software engineering and systems engineering into product

engineering, is a valuable tool for many organizations. CMMI promotes collaboration between

systems engineering and software engineering, thereby shifting the focus to the end product and

its associated processes. Further, CMMI enables model and appraisal training to be simpler and

more effective.

CMMI is valuable to organizations that produce software-only solutions. The systems

engineering functions, not typically addressed in detail in other software-only models, are

valuable to those producing software-only solutions. The handling of requirements, for example,

is discussed in much more detail than in the Software CMM. Although not previously addressed

in CMMs for software-only organizations, these practices use familiar terminology and model

27

architecture and help to manage and prevent difficulties related to software requirements—a

concept that is not new to many software organizations.

CMMI allows users to select the model representation (or both representations) that best

suits their business objectives. The flexibility built into every CMMI model supports both staged

and continuous approaches to process improvement with common terminology, architecture, and

appraisal methods.

Although the initial focus of CMMI was on product and service engineering, CMMI was

designed for other disciplines as well, thereby supporting enterprise-wide process improvement.

Like any other CMM, CMMI requires you to use professional judgment to interpret the

information in Part Two. Although process areas describe behavior that should be exhibited in

any organization, all practices must be interpreted using an in-depth knowledge of CMMI, the

organization, the business environment, and the circumstances involved.

CMMI for Development is a reference model that covers the development and

maintenance activities applied to both products and services. Organizations from many

industries, including aerospace, banking, computer hardware, software, defense, automobile

manufacturing, and telecommunications, use CMMI for Development. Models in the CMMI for

Development constellation contain practices that cover project management, process

management, systems engineering, hardware engineering, software engineering, and other

supporting processes used in development and maintenance. The CMMI for Development +IPPD

model also covers the use of integrated teams for development and maintenance activities

(IPPD).

The Group of IPPD Additions

28

In CMMI, “additions” are used to include material that may be of interest to particular users. For

the CMMI for Development constellation, additional material was included to address IPPD.

The IPPD group of additions covers an IPPD approach that includes

practices that help organizations achieve the timely collaboration of relevant stakeholders

throughout the life of the product to satisfy customers’ needs, expectations, and requirements

[DoD 1996]. When using processes that support an IPPD approach, you should integrate these

processes with other processes in the organization. To support those using IPPD-related

processes, the CMMI for Development constellation allows organizations to optionally select the

IPPD group of additions. When you select CMMI for Development +IPPD, you are selecting the

CMMI for Development model plus all the IPPD additions. When you select CMMI for

Development, you are selecting the model without the IPPD additions. In the text in Part One of

this book, we may use “CMMI for Development” to refer to either of these models, for the sake

of brevity.

Resolving Different Approaches of CMMs

The definition of a CMM allows the community to develop models supporting different

approaches to process improvement. As long as a model contains the essential elements of

effective processes for one or more disciplines and describes an evolutionary improvement path

from ad hoc, immature processes to disciplined, mature processes with improved quality and

effectiveness, it is considered a CMM. CMMI enables you to approach process improvement and

appraisals using two different representations: continuous and staged. The continuous

representation enables an organization to select a process area (or group of process areas) and

improve processes related to it. This representation uses capability levels to characterize

29

improvement relative to an individual process area. The staged representation uses predefined

sets of process areas to define an improvement path for an organization. This improvement

path is characterized by maturity levels. Each maturity level provides a set of process areas that

characterize different organizational behaviors.

Choosing a Representation

If you are new to process improvement and are not familiar with either the staged or the

continuous representation, you cannot be wrong if you choose one representation or the other.

There are many valid reasons to select either representation. If you have been using a CMM and

you are familiar with a particular representation, we suggest that you continue to use that

representation because it will make the transition to CMMI easier. Once you have become

completely comfortable with CMMI, you might then decide to use the other representation.

Because each representation has advantages over the other, some organizations use both

representations to address particular needs at various times in their improvement programs. In

the following sections, we provide the advantages and disadvantages of each representation to

help you decide which representation is best for your organization.

Continuous Representation

The continuous representation offers maximum flexibility when using a CMMI model for

process improvement. An organization may choose to improve the performance of a single

process-related trouble spot, or it can work on several areas that are closely aligned to the

organization’s business objectives. The continuous representation also allows an organization to

improve different processes at different rates. There are some limitations on an organization’s

choices because of the dependencies among some process areas. If you know the processes that

need to be improved in your organization and you understand the dependencies among the

30

process areas described in CMMI, the continuous representation is a good choice for your

organization.

Staged Representation

The staged representation offers a systematic, structured way to approach model-based process

improvement one stage at a time. Achieving each stage ensures that an adequate process

infrastructure has been laid as a foundation for the next stage. Process areas are organized by

maturity levels that take some of the guesswork out of process improvement. The staged

representation prescribes an order for implementing process areas according to maturity levels,

which define the improvement path for an organization from the initial level to the optimizing

level. Achieving each maturity level ensures that an adequate improvement foundation has been

laid for the next maturity level and allows for lasting, incremental improvement. If you do not

know where to start and which processes to choose to improve, the staged representation is a

good choice for you. It gives you a specific set of processes to improve at each stage that has

been determined through more than a decade of research and experience with process

improvement.

Comparison of the Continuous and Staged Representations

Table 1.1 compares the advantages of each representation and may assist you with determining

which representation is right for your organization.

Factors in Your Decision

Three categories of factors that may influence your decision when selecting a representation are

business, culture, and legacy.

Business Factors

31

An organization with mature knowledge of its own business objectives is likely to have a strong

mapping of its processes to its business objectives. Such an organization may find the continuous

representation useful to appraise its processes and in determining how well the organization’s

processes support and meet its business objectives. If an organization with a product-line focus

decides to improve processes across the entire organization, it might be served best by the staged

representation. The staged representation will help an organization select the critical processes to

focus on for improvement.

32

Works Cited

http://www.helium.com/items/1614768-benefits-of-using-the-cobit-framework-for-it-

governance?page=2

http://www.informit.com/articles/article.aspx?p=98146&seqNum=8

http://itcertificationsguide.com/evaluating-cmmi-when-is-it-a-good-fit/