Issuu on Google+

INNOTRAIN IT

IT Service Management QUICK – SIMPLE - CLEAR Preview

Extract

Chapter 3.3

2011


IT Service Management

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

I


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. vii

The Institute of Internal Auditors (IIA) has defined Internal auditing as : 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 viii

Internal control as: : 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 ITrelated audit and control function is to be run within the company. This standard is COBIT: Control ix

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

called "COBIT Quickstart," 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, SarbanesOxley 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 eCommerce, 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 completing

refers a

to

the

project.

time

The

available

cost

for

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/KnowledgeCenter/Research/ResearchDeliverables/Pages/COBIT-4-1.aspx (retrieved on 2011-03-15).


x

IT Governance Institute (2007b) COBIT Quickstart, 2

nd

Edition, IT Governance Institute, Rolling Meadows, IL

http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/COBIT-Quickstart-2ndEdition.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).


ITSM Guide - Extract Chapter 3.3 - Monitoring, improvement & change