INNOTRAIN IT

IT Service Management

QUICK – SIMPLE - CLEAR

Preview

Extract

Chapter 3.3

2011

IT Service Management

I

Authors

Dr. Mariusz Grabowski, Universität der Wirtschaft Krakau

Dr. Claus Hoffmann, Beatrix Lang GmbH

Philipp Küller, Hochschule Heilbronn

Elena-Teodora Miron, Universität Wien

Dr. Dariusz Put, Universität der Wirtschaft Krakau

Dr. Piotr Soja, Universität der Wirtschaft Krakau

Dr. Janusz Stal, Universität der Wirtschaft Krakau

Marcus Vogt, Hochschule Heilbronn

Dr. Eng. Tadeusz Wilusz, Universität der Wirtschaft Krakau

Dr. Agnieszka Zając, Universität der Wirtschaft Krakau

3.3 Monitoring, improvement & change

3.3.1 Control and audit

Every ITSM guideline needs a section that describes the rules and mechanisms responsible for

monitoring and controlling all IT-related tasks and activities. Auditing and controlling information

systems are part of the internal auditing and controlling functions of organisations.

The Institute of Internal Auditors (IIA) has defined Internal auditing asvii: an independent objective

assurance and consulting activity designed to add value and improve an organization's operations.

It helps an organization accomplish its objectives by bringing a systematic, disciplined approach to

evaluate and improve the effectiveness of risk management, control, and governance processes.

The Committee of Sponsoring Organizations of the Treadway Commission (COSO) has defined

Internal control as:viii: broadly defined as a process, effected by an entity's board of directors,

management and other personnel, designed to provide reasonable assurance regarding the

achievement of objectives in the following categories: (1) Effectiveness and efficiency of

operations; (2) Reliability of financial reporting (3) Compliance with applicable laws and

regulations."

Audit and control are closely related to each other and are frequently mentioned and described

together. Both processes are intended to provide assurance with regard to the achievement of

business objectives. However, there is a clear distinction between the terms:

! Control takes place via self-assessment, i.e. it is carried out by the employees who are

responsible for certain tasks. In the IT area, for example, this can pertain to the system

administrator, who checks systematically to ensure that the tasks he or she carries out are

fulfilled properly.

! In contrast, an audit must be carried out by an independent entity (i.e., without the

involvement of the entity that reports to the manager, who is responsible for an audited unit)

and is concentrated on the effectiveness of control mechanisms. An audit is intended to verify

that the control system is efficient. This, in turn, is expressed in its potential to discover errors

and irregularities that get in the way of attaining business objectives.

Control activities play the most important role in the case of SMEs, which is due to the structure of

the process participants and the corporate structure (see below). For this reason, the name of this

section (3.3.1) has been changed to "Audit and control" instead of "Control and audit," which is

used most frequently in the literature.

Generally speaking, all audit and control activities are concerned with systematically monitoring

multiple defined control objectives. This process determines whether these are met and estimates

the extent to which they are met.

With regard to audit and control of information systems, numerous guidelines and standards are

available. However, there is one generally acknowledged standard that describes how an IT-

related audit and control function is to be run within the company. This standard is COBIT: Control

Objectives for Information and Related Technologyix. There is also a limited version of this standard

called "COBIT Quickstart,"x which has been designed specially for SMEs and is customised to their

special features. These standards can be used as reference models if concrete audit and control

processes are implemented in a company.

Large companies have their own well-organised audit departments with corresponding processes,

while SMEs do not approach this subject in such an organised and systematic manner. This is due

to the fact that SMEs are structurally much smaller than large companies and usually do not

formulate long-term strategies.

Which level is appropriate for audit and control in an average SME? This question has to be

answered in detail by the management of the respective company. However, we can narrow it

down to four specific processes:

1. Providing IT governance

2. Monitoring and evaluating the IT service

3. Ensuring compliance with external requirements

4. Monitoring and evaluating the internal control

Processes 1-3 are solely control processes, as they are carried out in their entirety by employees

who are entrusted with the daily tasks in the areas of the company's business processes and

corporate IT. Process 4, on the other hand, is an audit process and should be carried out by an

external company.

Generally speaking, each process of an audit and control function is to be carried out in the

following steps:

1. Defining the suitable management processes

2. Reviewing the maturity level of the process

3. Defining the responsibilities in the company

4. Defining the most important measures (metrics) used for process monitoring

When it comes to defining management processes, a company has to set up and elaborate certain

patterns for desired procedures that fulfil the ITSM specifications identified when formulating

business and IT strategies. The desired procedures could, for example, include the following: (1)

Setting up regular reporting about the IT activities for review by corporate management; (2)

Defining a method for discussing the limited quantity of relevant and measurable results and

operating figures for IT that are monitored continuously; (3) Making a review of the method with

which other companies in the industry approach IT topics and important IT decisions or (4)

Identifying the requirements that result with regard to compliance with external regulations. All

management practices are process-dependent. Therefore, they have to be set up separately for

each individual process. With regard to the SME, the number of management practices should be

limited to a reasonable figure of no more than 3 per process.

The maturity level of a certain process can be reviewed by comparing the current and desired state

of the specific process within the company with the objective of the company and the average

value in the industry. This can be done by carrying out the following steps:

1. Defining the current position of the process within the company.

2. Defining the desired position of the process within the company. To carry out this step, an

average position in the industry can be used as reference.

3. Determining the gap between the current and desired position.

4. Defining the change process for getting from the current to the desired position.

5. Defining the integrated implementation program for governance.

The tool for carrying out this task is the maturity model. This concept is taken over from the CMMI

(Capability Maturity Model Integration) method, which is defined by the SEI (Software Engineering

Institute). It consists of 5 levels:xi

1. Initial – the process arises from the situation and is chaotic.

2. Managed – the process is planned and executed in accordance with corporate guidelines.

3. Defined – the process is described and understood well and characterised with respect to

standards, procedures, tools and methods.

4. Quantitatively managed – performance and quality of the process are managed by

quantitative objectives.

5. Optimising – the process is continuously improved using quantitative insights into the

respective business requirements and performance requirements.

The concrete ITSM standards can contain modified versions of the maturity model. Though the

change can involve a different designation and number of levels, the basic philosophy remains the

same: The workflow goes from the lowest to the highest level, were the maturity of the model

increases with each level.

Each process is carried out by persons. Therefore, a company has to define the responsibilities of

the individual roles and verify each management procedure with the suitable corporate role and the

type of responsibility. In the ITSM, this is also called the RASCI (or RACI) diagram:

Responsible – responsible for the actual implementation. Is interpreted as responsibility in the

disciplinary sense.

Accountable (cost responsibility), responsible in the sense of "approve," "authorise" or "sign." The

person with responsibility in the legal or commercial sense of the word.

Supportive . The person can play a supporting role or make operating resources available.

Consulted – specialised responsibility. A person whose advice is solicited. Is also interpreted as

responsibility from a specialised point of view.

Informed – right of information. A person who receives information about the course/the result of

the activity or as the right to obtain information.

In the case of SMEs, the corporate roles can include business owner, managing director, IT

manager, various department heads, head of accounting etc. These roles must be assigned

carefully and adapted to the corporate framework and scope of activities. Using the example of the

auto repair shop, a RASCI matrix could be set up like this:

Figure 12 - Example of a RASCI matrix

Each ITSM method is constructed properly when its effectiveness and efficiency are measured.

Generally speaking, effectiveness pertains to "carrying out the correct actions," while efficiency is

"carrying out the actions correctly." There are two types of metrics with which the above goals can

be measured. From the total number of metrics available, the most important ones are selected

and defined as the primary metric. They are used for reporting and are intended to ensure

efficiency, effectiveness and profitability. These are defined in ITIL as Key Goal Indicators (KGIs)

for measuring effectiveness and Key Performance Indicators (KPIs) for measuring efficiency;

COBIT uses Lag Indicator and Lead Indicator, respectively, as synonyms for these terms.

Key Goal Indicator (KGI) or Lag Indicator

Metrics that show management whether an IT process has fulfilled business requirements. The

number of incidents could be one example of a KGI.

Key Performance Indicator or Lead Indicator

Metrics that determine the performance level of IT processes in terms of supporting target

achievement. They are early indicators of whether or not a target is likely to be attained. Examples

of KPIs include response time or the first-call resolution rate of incidents.

As mentioned previously in this chapter, COBIT Quickstart is a practically oriented

recommendation that can be used as a reference model for setting up control and audit procedures

within SMEs. This recommendation can and should be adapted to the specific features and

structure of the company. The adaptation can, for example, take the form or reducing the number

of corporate units in the RASCI diagram, reducing or expanding the levels for the process maturity

or any other changes. A detailed description is provided in the current COBIT Quickstart from the

IT Governance Institute.

3.3.2 Compliance

In industry jargon, the term compliance is used to refer to fulfilment of national, European and

international laws and directives (e.g. German Federal Data Protection Act, Basel II, Sarbanes-

Oxley Act), as well as voluntary codes of conduct in the company. Compliance also includes a few

IT-related regulations such as security (protection of personal data), health, ergonomics,

confidentiality, legal and regulatory requirements, intellectual property, arrangements for e-

Commerce, insurance contracts and a few industry-specific regulations and procedures such as

the obligation to store recordings for tachographs.

The objective of IT compliance is comprehensive and consistent observance of compliance

requirements. In addition to safeguarding against legal consequences, this provides benefits for the

valuation of the company as well as higher IT security. The core task lies in documenting and

making corresponding adaptations to IT resources when rules and regulations change. In addition,

potential problems or hazards could be evaluated regularly (refer also to Chapter 3.2.3)

All areas of compliance have to be examined with the greatest possible care, as the number of

these regulations increases continuously. In the event of violations of these rules and regulations,

in some countries, executives and board members can be made liable for adherence to the legal

regulations. Failure to comply with these regulations can incur civil and criminal penalties. For

example, the German Federal Data Protection Act (BDSG) provides for violations to be punished

by imprisonment of up to 2 years or fines. Basel II has prescribed extensive verification measures

for financial institutions. As a result, all companies have had to take action to implement IT

compliance, if they had not done so already.

For additional detailed information and examples of processes related to compliance, refer to

current COBIT publications.

3.3.3 Managing changes

Have you ever installed a software update, only to find that nothing works afterwards? If the effects

are limited to your own workstation, it may not be so bad. However, if we imagine the

consequences when updating all of a company's computers, an administrator will quickly learn not

to be careless and check everything twice in future. Change management, which is often

considered too bureaucratic, can be a useful tool for preventing disruptions. It offers interfaces to

other processes, specifically the continuous improvement process or problem management. For

example, within problem management, potential problems are identified, analysed and a solution

defined. If the solution necessitates a change of the current situation, the needed changes are

handed over to the change process via a change request. This defines a structured procedure in

which an element (e.g. workstation computer, server hardware, but also services or processes) are

to be brought from a current state into a desired future state by modifying, adding or removing. The

objective of change management is to facilitate a worthwhile change with minimal interruption of

the IT service.

Change

The word "change" refers to any and all modifications to the existing IT landscape. For example,

identifying a problem (e.g. the spreadsheet software always crashes when the e-mail client is open

at the same time) can cause a change when a solution has been found. The answer to the problem

mentioned here could be increasing the memory in the computers. This is also referred to as a

change.

In addition to the "hard" changes such as the technological changes described above, there are the

"soft" or organizational changes. The massive involvement of the human factor means that a

special procedure has to be followed here; accordingly, a separate chapter (Chapter 5) is

dedicated to this complex topic.

Changes to the information technology of today are, in many cases, a similarly complex task due to

the highly dynamic nature and number of the various elements and their dependencies on each

other. These changes can have multi-layered and far-reaching consequences. For example, if a

new operating system is introduced, after which the printers used and the business management

application systems are not compatible, the consequences can be very far-reaching indeed.

Accordingly, the foremost objective of change management is minimizing risk. By making changes

in a controlled manner, one can also monitor the potential risks that changes incur.

The following can indicate room for improvement in a company's own change management:

! Frequent unplanned service outages

! A low success rate when carrying out changes

! A high rate of emergency changes or unauthorised changes

If these reasons apply, it is worthwhile to think about this topic. However, in addition to minimising

risk, professional change management can provide additional added value for IT and customers:

! Highly qualified processing of changes as well as better planning of times, quality and costs

! Cost reduction over the medium term provided by standardised procedures

! Increase of productive service time by reducing service downtimes

! Combined view of business and IT aspects of a change for identifying areas with room for

improvement

To attain a certain level of transparency, a reasonable data platform for making decisions and,

finally, documentation, desired changes are compiled in a Request for Change. For this reason, a

very practical way to enter a request of this nature is in a ticket via the service desk or as a

document template that has to be filled in. However, it is important to define which form is used for

which change type and to ensure that the corresponding variants are available if necessary. In

practice, the changes seem to fall into three categories:

Standard changes

Changes for which a standardised procedure has already been defined in advance and that usually

have only minor effects. Due to their general planning, they do not require a release procedure.

Examples of a change of this nature include setting up a new e-mail account, resetting a password

or setting up a regular workstation.

Normal changes

Changes that are relatively time-uncritical and cannot be treated as a standard change. An

example of such a change could be installing a patch in the ERP system.

Emergency changes

In the event of an incident, it may be necessary to make quick changes. In this case, the normal

procedure is too slow and complex. Accordingly, in this case, changes can be made according to

defined requirements, but much more quickly. This makes a difference, for example, when a

hardware failure has an impact on the services.

Finally, we have to clarify the activities of change management. As usual in the IT Service

Management, this has been defined as a process. The following illustration shows the process.

First, let's explain the two roles of change manager and authority: As the name implies, the change

manager role is in charge of administration for the change. It can be filled by multiple persons. In

many cases, the service desk employee is also responsible for the initial steps of change

management. The person(s) filling the role can be defined according to the needs of the company.

The role of authority is frequently filled by what is called a Change Advisory Board. It consists of

representatives of all IT areas, the business areas and any possible third parties (e.g. external

suppliers). In smaller companies, however, the Change Advisory Board can also be replaced by a

regular team meeting.

Figure 13 - Change process based on ITIL

1. Creating the change request

The change is always requested by the request of an initiator (e.g. employee, organisational unit

and employee of the service desk) with a change request. A change request can be recorded and

documented in different ways (such as paper, e-mail, online form). The degree of detail depends

on the scope and effects of the change. The ideal scenario is to use an integrated service

management tool that documents all data and can map all dependencies (e.g. to configuration

items). Based on the change request, a change record is created that documents all activities.

2. Verifying the change request

In the initial verification, the change request is checked by the change manager to ensure that it

makes sense and is categorised correctly. For example, standard changes are forwarded directly

for processing. On the other hand, enquiries that are not practical, filled in incompletely or have

already been evaluated are filtered out and the initiator is subsequently notified of the rejection of

the application along with a reason. In this process, the person submitting the application should be

given the right to object.

3. Evaluating the change

To make a decision about a change, the following parameters have to be entered. ITIL designates

these parameters as the "seven R‘s of change management."

1. Who RAISED the change?

2. What is the REASON for the change?

3. What is the required RETURN?

4. What are the RISKS?

5. What RESOURCES are required?

6. Who is RESPONSIBLE for required activities like implementation and test?

7. What is the RELATIONSHIP between this change and other changes?

The information determined can be used to determine the correct level of authorization, to identify

the areas of interest ("Who is affected?") or to define the business case, effects, costs, benefits and

risks.

4. Authorising the change

Authorization ensures that all those affected by the change have been notified of it and dealt with it.

The transparency this creates reduces the risks and allows the effects to be checked. Depending

on the type, scope and risk of the change, different stages of authorisation may be most useful. For

example, replacing a tape drive, which has very minor effects, will be discussed and coordinated

only within the IT department. Release changes of the ERP system will surely also be discussed all

the way up to the management level of the company. Depending on the decision made by the

committee, the result is communicated to all those involved, particularly the person applying for the

change.

5. Planning the change

When changing the software, it often makes sense to combine all changes into what are known as

releases and then to make them available in a single step. Here, the advantages (e.g. improved

planning, better implementation rate) are examined compared to the disadvantages (e.g. time

delay). In addition, the actual implementation should be planned and co-ordinated. This must take

into account that active services are affected as little as possible. The result of this is to be clearly

defined work packages.

6. Implementing the change

The authorised changes are forwarded (formally) as work packages to the corresponding

employees or teams. These carry out the actual implementation. However, change management is

responsible for co-ordinating the activities and their on-time completion.

7. Checking and closing out the change

In a last step, the change is again reviewed and closed out. This happens with the following

activities:

! Compiling the documentation for the change

! Reviewing the change and its documentation

! Closing out the change document (after completing all activities)

! Reporting the close-out to all participants and presenting it for acceptance

! If referenced faults or problems exist, these can likewise be reviewed and closed out

If a change is very time-critical (e.g. failure of a server), we refer to it as an emergency change. In

this case, we should follow a similar procedure, but individual steps can be shortened. For

example, the evaluation and planning phases are greatly shortened and his comprehensive

documentation. In this case, the authorization also takes place by the relevant participants who are

available at the time (this is also called an Emergency Change Advisory Board (CAB)). Tests are

reduced or, in an extreme case, are omitted entirely. As a rule, the emergency change takes place

retroactively. This is intended to ensure that the change follows a reasonable workflow, despite the

time pressure.

3.3.4 Continual service improvement

Continual service improvement (CSI) is part of ITSM. In doing so, methods from quality

management are used to learn from past successes and failures and, in this way, develop solutions

that continually improve the effectiveness and efficiency of IT services and processes. CSI has to

prove its value to the company in order to justify its continued existence. A clearly defined purpose

with clear and unambiguous benefits that impact the entire company must be present. CSI, as

defined by ITIL, consists of four process:

! Service Evaluation – Process Objective: To evaluate service quality on a regular basis. This

includes identifying areas where the targeted service levels are not reached, and holding

regular talks with business to make sure that the agreed service levels are still in line with

business needs.

! Process Evaluation ! Process Objective: To evaluate processes on a regular basis. This

includes identifying areas where the targeted process metrics are not reached, and holding

regular benchmarkings, audits, maturity assessments and reviews.

! Definition of CSI Initiatives ! Process Objective: To define specific initiatives aimed at

improving services and processes, based on the results of service and process evaluation.

Process Objective: To verify if improvement initiatives are proceeding according to plan, and

to introduce corrective measures where necessary.

! CSI monitoring ! Process Objective: To verify if improvement initiatives are proceeding

according to plan. In addition, correction measures are carried out.

The CSI process requires three actors. The first actor, the CSI manager, is responsible for

managing the improvements to ITSM processes and IT services. The CSI manager measures the

service provider's performance continually and designs improvements to changes, services and

infrastructure in order to increase efficiency, effectiveness and profitability. The second actor, the

process manager, is responsible for planning and co-ordinating all process management activities.

He or she supports all actors involved in managing and improving processes, which also includes

the process owners. This role also co-ordinates all changes to processes, thus ensuring that all

processes work together seamlessly. The third actor, the process owner, is responsible for

ensuring that a process is suitable for its purpose. The responsibilities of the role include

supporting, designing and continually improving the process and its metrics.

Companies that want to improve services have to be clear about the effect of trends in the

business and market area on the IT area. To justify any and all improvements, the company should

compare costs and earnings (or savings). The difficulty lies in the fact that though the costs can be

measured relatively easily, it is more difficult to express in figures the increase in earnings as a

direct result of the Service Improvement Plan (SIP). The SIP is a formal plan for implementing

improvements to services and IT processes. The SIP is used to manage and log improvement

initiatives triggered by CSI. Improvement initiatives are either of the following:

! Internal initiatives tracked by the service provider, for example for improving processes or to

better utilise resources

! Initiatives required for working together with the customer, for example improving services

The following information are typically included in the SIP for each defined initiative for process or

service improvement:

1. Affected process or service

2. Person responsible for the process (process owner) or service (service owner)

3. Initiative owner (person responsible for the initiative, frequently roles in service

management such as Service Level Manager, capacity manager, availability manager,

process owner, service owner)

4. Approval by upper management

5. Description of the initiative

6. Source of the measure (e.g. service review, process audit)

7. Business scenario (expected result of the initiative, cost estimate, specific desired result of

the initiative, e.g. a certain cost reduction when provisioning a service)

8. Schedule and status of the implementation (target date, current status)

CSI is a part of every successful service management implementation. CSI ensures that the IT

services grow along with the business and adapt to it, and enables continuous improvement of

service stability, performance and functionality. CSI projects can be implemented in many different

forms: simplified request of services by customers, fewer required documents and shorter wait

times for service enquiries, creating an outstanding service catalogue by means of better

understanding etc.

The purpose of CSI is to continually align the IT services with changing business requirements. For

this purpose, improvements to IT services that support business processes are identified and

implemented. The objectives of CSI are the following:

! Reviewing, analysing and drafting suggestions for the service strategy, concept, transition and

procedures

! Reviewing and analysing the results when the service level is attained

! Identifying and implementing individual activities to improve the IT service quality

! Improving profitability when providing IT services without negative effects on customer

satisfaction

! Ensuring that suitable methods of quality management can be used to support continuous

improvement activities

Figure 14 - CSI model based on ITIL

According to the CSI model (Figure 14), the process for improving services is a constant cycle that

consists of the following steps.

! Understanding the business mission, objective and requirements in order to create a vision for

improvements based on this vision (What is the vision?)

! Reviewing the current situation in terms of business, company, employees, processes and

technology in order to obtain an accurate snapshot of the current state of the company

(Where are we now?)

! Understanding priorities for improvements and making corresponding agreements based on a

development of the principles from the vision (Where do we want to be?)

! Drawing up a detailed CSI plan for attaining a higher level of quality of the provided services

by implementing ITSM process (How do we get there?)

! Reviewing measurements and metrics if they ensure that the milestones are reached, the

compliance of the processes is high and business objectives and priorities are attained by the

service level (Did we get there?)

3.3.5 IT project management

A project is a limited-time initiative for developing a specific product or a certain service, such as a

building or a new computer system. Each product extends from the start to close-out and can take

days, weeks, months or even years. For Charly's company, introducing an online store would be a

project, but running the online store is part of everyday business operations.

Project

A project has limited time and monetary resources and is undertaken to create a one-of-a-kind

product, service or result. It has clear goals, requirements and quality specifications. A project can

also take on the form of a temporary organisation.

Project management is described as a series of principles, practical workflows and techniques that

are used to check the project schedule as well as costs and performance. It consists of a series of

tasks with which a project is run from beginning to end in order to attain the goals determined

earlier. Relative to this definition, IT project management can be understood as a sub-area in which

information technology projects are planned, monitored and controlled. In this regard, it is important

to pay due attention to the broad spectrum of tasks. The new areas of knowledge of the PMBOK

(Figure 15) provide an insight into the various subject areas that are to be considered within project

management.

Figure 15 - Areas of knowledge of project management according to the PMBOK

Regardless of type, all projects are carried out and implemented within the framework of certain

constraints. The three constraints of time, costs and scope are frequently referred to as the

"magical" Project Management Triangle. The time

constraint refers to the time available for

completing a project. The cost constraint

describes the budget available for a project. The

last constraint, cost, specifies which activities

have to be carried out to reach a goal. For a

Figure 16 - Project Management Triangle

project to be successful, these three constraints have to be in balance.

Various approaches can be taken into account in project management. Two important ways of

looking at it are:

! Traditional approach: Identifying a sequence of steps that have to be carried out

! Agile approach: The project as a series of relatively small tasks (not a complete process).

Traditional project management requires highly disciplined planning and control methods. In this

approach, we can distinguish between five phases in the development of a project. Each phase

contains processes with which the project is advanced from idea to implementation. The individual

phases include:

1. Project initiation phase

2. Project planning and design phase

3. Project execution and implementation phase

4. Project monitoring and control systems

5. Project completion

The traditional approach assumes that it is possible to foresee the effects of certain results on the

project. For this reason, all tasks have to be carried out one after the other, in the correct

sequence.

In contrast to the traditional approach, agile project management is based on the principle that

interaction between the individuals should be in the centre of the management. The project is

viewed as a series of relatively small tasks that have to be adapted according to the respective

situation and not designed and implemented as part of a process planned entirely in advance.

A number of project management methods are used to formally define how the project is managed.

For example, the following sections explain Project Management Body of Knowledge (PMBOK),

Projects in Controlled Environments (PRINCE) or SCRUM as an agile method for software or

product development. The objective of each of the three techniques is to standardise the workflows

of the development team in order to make it more predictable and manageable.

Project Management Body of Knowledge (PMBOK)

PMBOK is a guide for project management that compiles standard technology (IEEE, ANSI) that

provides the basics of project management and their application to a wide variety of projects. The

first version of the PMBOK guideline was published by the Project Management Institute in 1987. It

is concerned with applying knowledge, skills, tools and techniques to fulfil project requirements. A

project is implemented by integrating the project management processes. A project team is active

in nine areas of knowledge: Integration, scope, time, costs, quality, human resources,

communication, risks, procurement. These define a series of basic processes and describe them in

terms of input, tools, techniques and output. The project manager is responsible for the project

goals for creating the defined end product. In this regard, the constraints of project scope, time,

costs and the required quality have to be observed.

Project in Controlled Environments (PRINCE2)

PRINCE2 is a product-based approach for project management developed by the UK government

and used internationally, especially in IT environments. As a scalable method for managing IT and

other business projects, PRINCE2 defines forty different activities and structures these into seven

processes: (1) Starting up a project, (2) Initiating a project, (3) Directing a project, (4) Controlling a

stage, (5) Managing stage boundaries, (6) Managing product delivery and (7) Closing a project.

The method specifies each process with central inputs and outputs as well as certain objectives

and activities that have to be carried out. This enables automatic control of any and all deviations

from the plan. The method is broken down into manageable phases and enables efficient control of

resources. Based on close monitoring the project can be executed in a controlled and organised

manner. PRINCE2 is a flexible method and can be used on all types of projects.

SCRUM

In today's global economy, software developers are under pressure to deliver the right products

faster. As a framework concept for executing projects based on the principles and values of agile

project management, SCRUM can be used for managing and controlling complex software product

developments with repetitive, incremental procedures. It is necessary to take into account that this

method was originally planned for projects in the software development area, but can be used for

both simple and complex innovation projects.

As with the other methods derived from the agile method, SCRUM does not attempt to define

everything at the beginning of a project. Rather, SCRUM uses an empirical approach in which the

entire project is split up to sprints, i.e. time increments of typically two to four weeks. At the end of

each sprints, the team members hold meetings to discuss the progress of a project and discuss the

next steps.

vii http://www.theiia.org/theiia/about-the-profession/internal-audit-faqs/?i=1077 (retrieved on 2011-03-15). viii http://coso.org/IC-IntegratedFramework-summary.htm (retrieved on: 15.03.2011).

ix IT Governance Institute (2007a) Control Objectives for Information and Related Technology (COBIT) 4.1, IT

Governance Institute, Rolling Meadows, IL, http://www.isaca.org/Knowledge-

Center/Research/ResearchDeliverables/Pages/COBIT-4-1.aspx (retrieved on 2011-03-15).

x IT Governance Institute (2007b) COBIT Quickstart, 2nd Edition, IT Governance Institute, Rolling Meadows, IL

http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/COBIT-Quickstart-2nd-

Edition.aspx (retrieved on: 15.03.2011). xi Software Engineering Institute (2010) CMMI for Development, Version 1.3, Carnegie Mellon University

Software Engineering Institute, TECHNICAL REPORT CMU/SEI-2010-TR-033, ESC-TR-2010-033,

November, http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm (retrieved on: 9.05.2011).