About risks. Goals of the lecture. Contents of the lecture. Motivation. Risklists, ways to handle risks. References:

Transcription

1 About risks Goals of the lecture Contents of the lecture Motivation Risklists, ways to handle risks References: Haikala ja Märijärvi, Ohjelmistotuotanto Tony Moynihan, Coping with IS/IT risk management Somerville, Software Engineering 1

2 Goals After these lectures, a student should know: Recognize different risk categories. Know the basics of risk management process. Recognize the most important risks and risk types. Asses the success of a risk management process. 2

3 Contents From the previous slide... In the risk management process: Recognizing risks. Analyzing risks. Managing risks (preparings). Risk monitoring. Further, we expose some most common project problems and reasons for those. 3

4 Motivation Risks can affect the project schedule and the quality of a product. Most common problems: Exceeded costs. Uncontent customers (is related to quality). Does not meet the goals. Economic losses. Amount of quarantee (repair) work (is related to quality). 4

5 Most common reasons for the problems Work effort estimate not correct. Requirements imperfect (insufficient). Change resistance. Too large project. Client/supplier lack of experience. Unplanned introduction (into use). Personnel turnover. Bad project manager. Problems with tools and equipment. 5

6 Risk categories Project risks affect schedule and resources Product risks affect the quality or efficiency of product Business risks affect the product development organization There are other ways to form risk categories. From the previous slide we mainly find two first types. Technology change and product competition risks could be in the third category. 6

7 Risk management process Recognizing risks. Project, product, and business risks are recognized. Analyze the risks. Estimate the likelihoods and effects of the risks. Prepare for the risks. Avoidance and planning to minimize the effects. Risk tracking. Continues risk estimation (assesments) and mitigation plans (when new information about risks is obtained). 7

8 Risk management process Iterative process continuing through the whole project. Risk recognition Risk analysis Risk management Risk tracking Risk list Prioritized riskilist Risk avoidance and effect minimization plans Risk assessment 8

9 Recognizing risks Brainstorming. Experiences of workers and project manager. Lists do help. Risk types. Some risks. Some of the risks are always project specific. 9

10 Risk types Technology risks. Risks related to people. Organizational risks. Risks related to customers. Risks related to tools. Risks related to requirements. Estimation risks. Depending on the precision, the list may be reduced or enlarged. With each: what individual risks can be found from your project. The project plan template has different pairs (things, questions) in lists, which may contain risks. 10

11 Analyzing risks With each identified risk we estimate likelihood very low, low, moderate, high, very high. seriousness katastroph, serious, tolerable, or insignificant. recognizability (with what certainty the risk can be recognized) very uncertain, low, moderate, high, almost certain Results are collected into a risk table. The table is ordered with the seriousness of the risks. In the end, we decide what are the most important risks which are monitored (e.g risks). 11

12 Preparing for risks; methods to manage risks From the point of view of the most important risks. Is much based on the experience of the project manager. Avoidance strategies to decrease the probability of occurrence (emergence) of a risk. Minimization strategies to minimize the effects of a risk. Emergency plans (plan b s, varasuunnitelmat?) a risk has been prepared somehow. 12

13 Monitoring risks Regular estimation: Has the probabilities or influences changed? In each mile stone (e.g. reviews) the most important risks could be checked. Some risk factors related to the previous, which could be monitored: People Tools Requirements Bad working morale, bad relations. Reluctance to use certain tools, complains about CASE-tools, requirements about more efficient machines. Much change requests, customer complaining. 13

14 Assessing the success of a risk management process Where we did succeed well? What risks could be avoided (which may otherwise would have been realized)? How the realized risks where handled? Did we recognize the in good time? Where the actions effective and sufficient? What actions failed with regards to risks? Could we have avoided some of the risks by acting in other way, or at least been able to decrease the effects? Did some risks emerged that clearly had an effect and which we did not recognize/consider in advance at all? 14

15 In the end some (possible) ways to act shortly. These adviced may decrease some risks. (See the book by Moynihan.) 1. There is no project owner or a person responsible for the project on the other side. That should be found and the advice is that one should try to find one from the upper levels of customer organization, until found. If not found, in any case, the matter should brought into the day light. Many do recommend that the project should be cancelled if this cannot be agreed on. 2. The customer project manager has no authority. One should ask them to replace with one who has authority. If not found, again to upper levels of management and be prepared to cancel the project. 15

16 3. The customer project manager has not skills or time (but authority). One could try to find some support for him or teaching. If this does not work, then one should ask somebody else to be there, or to try work around him somehow (e.g. by adding contacts to other personnel of the customer). 4. One should rely more on key users and managers and less to the official project manager or to the project owner. 5. Unrealistic expectations about the costs, schedule or implementable should be clarified. For ex. by telling similar examples about previous projects, by having meetings, what is the state of the art etc. One could give examples, what can be obtained. One could suggest an external consult to give an objective view. If cannot drive the changes, close the project. 16

17 6. One should get early feedback for the solution proposals. The solution ideas should as concrete as possible to the client and users. People should be helped to see, how the solution will affect their work. Prototype is ideal, but also simulations with the paper mockups will help. (There may be users who don t want the new system.) 7. The organization changes and things close to people (disagreements, change resistance etc) should be hanlded early. Those people may be prepared for the change to whom the changes affect most. 8. The implementation plan should also be made carefully and with sufficient details in the early phase. The implementation tasks and responsibilities should clear. Preparations of the users and teaching should have enough resources. Taking into use should be planned well. The exact delivery day should be agreed. 17

18 9. If the cliet side erimielisyyksiä, reluctant users or unpleasant politics (e.g. project with hidden goals), one could solve them by teaching. The problem should be given back to the client (to the people who are capable or who have possiblity to solve that problem). One should try to avoid the problem. One may give an advice to take consultation to solve the problems. 10. One should make sure that the customer will accept (take) the whole responsibility for the management of organizational changes, and that the customer will prepare the organization for the introduction of new system (taking into use). One should specificly tell about every change the new system causes to the inner processes. 11. The scope of the project should be limited to correspond the capacity the customer has to adopt changes. 18

19 12. The scope and contents of a project should be limited by what is possible to implement by own resources with regards to time, expensies and technical things. 13. Use incremental or evolutionary life cycle model. Project should be partitioned to several phases each having its own little implementation. The minimum risk or the one that is most urgent should be implemented first. After that one should check the progress and decide, what to do next. 14. Negotiate elasticity for the time limits. 15. If there are a lot of changes at the customer site (side) or if there are a lot of matter related to people, one should take into the group people good with other people (good listeners, conversationalist). 19

20 16. If a project has a lot of learning (to you), you may think if it is a strategic decision. For example, in order to learn one may take losses some of the first projects so that in the future the technique is familiar. 17. If a developer will have a lot of learning, one should try to find out a separate, e.g., smaller subproject by which the thing to be learned could be learned in the beginning before one moves to the main project. Learning while doing has risks. 18. If some matter has a lot of technical risks, one should have a separate settlement phase with own budget. One should not commit to this kind of matter before the risk has been defined in a more specific way or has been solved. 20

21 19. If own team lacks knowhow, one may buy teaching, consultation, contract staff etc. If one brings too many outsiders into a team, the functioning of the team may get disturped. If this is a risk, some part may be left for subcontracting. Or one may try to continue as a collaboration project with some other team. 20. The domain of client business by spending time at the customer site, by tracking the actions of key users. Further, one may try to find out, what kind of solutions others have been done to the competitors of the client. 21

22 21. Negotiate and agree on the time and material usage regarding things that have a lot of studying or things for which you don t have full control, or things that have a lot of disagreements, unpleasant politics or other large uncertainties related to people or technology. These kinds of things can be handled separately on the contracts. Fixed price should accepted only in the cases, where it is possible to put a large contingency money or if the project is especially important (e.g. strategically). 22. Behave byrocratically, write down every matter, agree on everything exactly and on a detailed level. 23. Document and agree on the scope and bounds of the project: what it includes and not, from which it start and where it ends. Every additional request should be handled as a change request with their own budgets. 22

23 24. Negotiate a separate contract for the first phace, where one agrees on the scope, requirements and functional specification. 25. The requirements specification, functional specification and system specification should especially exact and detailed. 26. Determine exactly and clearly the responsibilities and commitments of both the developer and the client. Seek a common understanding and clearness on who will do what and when, and on resources that the client will deliver and when. 27. Keep book about the mistakes/failures of the customer with regards to those things that have been agreed on. This is related to responsibilities, commitments, schedules etc. Further, one could book the problems which are somehow initiated by the customer actions. 23

24 28. Agree beforehand about the success criteria and success metris. This includes the validation tests. 29. Ask signatures from the customer to every product in different phases of project. Without signatures there is no point in continuing. 30. Manage your subcontractor at least as tightly as your own customer manages you. You should add penalty clauses in case of inefficiencies (e.g. if being late). Require signatures for every producement. Make sure that communication works. Determine roles and responsibilities. Study the background of your subcontractors, experience and suitability with respect to your own ways of functioning. 31. If there are third parties in the project, for example other consultants, make sure the responsibilities, roles, and their relation to you in the project have been clearly determined. Study the 24

25 background of third party, experience and suitability with respect to your own ways of functioning. 25

26 32. Don t touch other designers or suppliers products (codes, interfaces etc), if you can avoid it. Handle them as potential problem sources. If possible, try to get the original developer to take responsibility of the changes or to accept the changes with a signature. If not possible, write it again or develop it from the scratch, test a lot. Agree clearly, who will maintain it afterwards, when you have made the changes. 33. Strengthen the quality control and increase the formality level of the development process. 34. Improve the user (action) descriptions when forming using business domain test cases. 35. If application is very critical for the client, make sure that the team has technical and application knowhow. 26

27 36. Increase the management formality and exactness. Manage the project in a more formal way and more stricly. Control with schedules and products. A lot of monitoring (supervising) and control. 37. If the project is not important strategically, walk away... (depends on a situation and it is not easy to find out simple cases when one should react in this way). 27