1. Risk management

3. Definition and Aim  Risk management is examine systematically all risks and react on them, taking into account all the effects of the reaction  Risk management is a systematic method to protect the company’s activa and to guarantee the continuity, in such a way that the objectives can be achieved without interruptions  Risk management, at a professional level, is an investment that will prove its value in difficult moments and that will indirectly contribute to the company’s profit

4. IT - Security policy  Dependent on:  Size of the company  Kind of activities  Level of automation  Level of communication system  No universal management model

5. Risk management RISK Management decide on basic options in security RISK analysis Identification evaluation and selection of security measures design the concepts of the security plan and decisions Execution of the security plan and evaluation feed back

6. Risk analysis Risk identification Risk estimation

7. Risk identification Identify the Assets evaluate Assets identify the dangers identify the weaknesses evaluate the weaknesses

8. Risk estimation Estimation of frequencies of undesirable events calculation of the risks

9. Security level security cost security level cost total expected cost Exposure Cost

10. IT-project Risks  A successful implementation within time and budget depends on a number of factors:  involvement of the contractor;  communication between contractor and project leader;  quality of project team and the project leader;  cooperation of the users;  IT-experience within user department;  quality of the developers, in particular concerning the determination of the needs;  hierarchical distance between contractor and users;  size and technical complexity of the system.

11. Types of Risks  system will never be delivered formally;  system will be delivered late;  budget will be exceeded;  functionality will be insufficient;  system will be unreliable;  system will be difficult to use in practice;  system will not function well;  maintainability will be difficult and/or expensive;  extendibility will be poor.

12. Corrective Actions  modify project organization;  better support for project management;  modify life cycle;  modify project borders and goals;  improve quality control system;  define external conditions;  stop the project; ...

13. Points of Attention  Clear definition of the project;  methodology and standards;  project procedures;  project organization;  reporting and control;  technical infrastructure;  project team;  deliverables.

14. Risks and Dimension StructuredUnstructured A lot of experienceLarge projectlow risklow risk with used technology Small projectvery low riskvery low risk Little experience Large projectmedium riskvery high risk with used technology Small projectlow/medium riskhigh risk Mc Farlan, Harvard Business School

15. General Concerns  The higher the risk, the higher the position of the manager must be.  In the portfolio approach the idea is to have a mixture of pro- jects with different risks, coherent with the company profile.  Factors of influence:  stability of development department;  quality of development department;  dependency of services on IT;  dependency of decision making on IT;  IT experience;  failures during last two years;  New IT-management;  IT compared to competition.

16. Serious Deficiencies in Practice Involving general management and IT management  failure to assess the individual project implementation risk at the time the project is funded  failure to consider the aggregate implementation risk of the portfolio of projects  lack of recognition that different projects require different managerial approaches

17. Elements of Project Implementation Risk  We do not consider project mismanagement (methods, tools)  Risk is not always bad (higher risk, higher potential benefits)  Consequences of risk  not obtain anticipated benefits due to implementation problems  implementation costs much higher than expected  implementation time much longer than expected  technical performance significantly below the estimate  incompatibility of system with selected hardware or software  Project dimensions  project size ( dollars, staffing, number of affected departments,...)  Experience with technology  Project structure ( highly structured, low structure )

18. Assessing Risk of Individual Projects List of questions and weights, derived from previous projects  The presence of risk should encourage better approaches to project management  The higher the assessment score, the greater the need for corporate approval  Managers should ask questions such as:  are the benefits great enough to offset the risks?  can the affected parts of the organization survive if the project fails?  have the planners considered appropriate alternatives ?  The questionnaire is used again periodically  Most fiascoes occur when senior management considers the implementation risk low while IT-management considers it high

19. Portfolio Risk  There is no universally appropriate implementation risk profile  In an industry where IT is strategic, managers should be concerned if there are no high-risk projects  Too many of high-risk projects make a company vulnerable to operational disruptions  Support companies should not take strategic gambles

20. Tools of Project Management  External integration tools  communication between project team and users  at managerial and lower levels  Internal integration tools  ensure that team operates as an integrated unit  Formal planning tools  structure the sequence of tasks in advance  estimate time, money and technical resources  Formal result-control mechanisms  evaluate progress  spot potential discrepancies