1. University of Sunderland CIFM03Lecture 12 1 Feasibility Lecture Twelve

2. University of Sunderland CIFM03Lecture 12 2 Is It Feasible? Once scope has been defined, with the customer, it is as well to stand back and ask ‘Can this job be done?’ ‘Not everything imaginable is feasible, not even in software.’ Putnam and Myers

3. University of Sunderland CIFM03Lecture 12 3 Four Tests Test One: Technology. Test Two: Finance. Test Three: Time. Test Four: Resources.

4. University of Sunderland CIFM03Lecture 12 4 Failures Large software projects are notoriously difficult to bring in on time, on budget, and to the standard required. But the same story is true in large Engineering projects. Human beings are not good at visualising the work involved in such monsters.

5. University of Sunderland CIFM03Lecture 12 5 Failures: Home Office Project Designed to track details of asylum seekers. Development schedule 1996 - 1998. Targeted £110M pa staff savings.

6. University of Sunderland CIFM03Lecture 12 6 Failures: Performing Rights The Performing Right Society spent £20M in 1987 collecting and distributing royalties. It decided to create a database to encompass all its functions, and migrate to a new hardware and software platform. The system was to be the largest in the world at that time.

7. University of Sunderland CIFM03Lecture 12 7 Failures: Performing Rights The costs were to be offset by huge staff reductions. Late in the project the team found that data on music publishing contracts could not be automatically input to the database, and a two year extension was sought.

8. University of Sunderland CIFM03Lecture 12 8 Failures: Benefits Card Use magnetic stripe cards in Post Offices to claim benefit. Benefit - cut presumed fraud. Costs to develop and run: £1,000,000,000. Started in 1996, dropped in 1999. ‘The complexity and resource requirements had been seriously underestimated.’ National Audit Report

9. University of Sunderland CIFM03Lecture 12 9 Failures: Passports July 1996, Passport Agency decided to replace its 1989 systems System installed in October 98 in Liverpool, then November 98 to Newport.

10. University of Sunderland CIFM03Lecture 12 10 Failures: Ambulances 1991 decision taken to develop a computerised despatch system for London ambulances. Jan 92 deadline missed. ‘Full’ system installed Oct 92. System degraded under load, and locked on 4 Nov 92.

11. University of Sunderland CIFM03Lecture 12 11 Failures: Air Traffic Control Six years late, £180m over budget. Cost £480m. Switched on in January, failed five time by May, and twice in June. Exhaustive spec., tackled by IBM 92-94, Loral 94-96, and Lockheed 96-02. Yet this is a safety-critical system...

12. University of Sunderland CIFM03Lecture 12 12 A Risky Business Developing software is not like building a bridge

13. University of Sunderland CIFM03Lecture 12 13 Quantifying Risk Since risk is part and parcel of every software project, its impact and likelihood need to be quantified. Boehm (1989) started the ball rolling, and gave us a list of the top ten problems of the day, together with ways of minimising impact.

14. University of Sunderland CIFM03Lecture 12 14 Top Ten Software Risks Boehm, 1989. Software Risk Management

15. University of Sunderland CIFM03Lecture 12 15 Top Ten Software Risks Boehm, 1989. Software Risk Management

16. University of Sunderland CIFM03Lecture 12 16 Your Views in Teams How would you rank Boehm’s list? Do you have fresh points to add?

17. University of Sunderland CIFM03Lecture 12 17 Another Version Glass (1998) has a different list:- –Objectives not fully specified –Bad planning and estimating –Technology new to the organisation –Inadequate project management technique –Too few senior client staff on team –Poor suppliers of hardware/software Glass, RL. 1998: Software Runaways: Lessons Learnt from Massive Software Project Failures, New Jersey, Prentice Hall

18. University of Sunderland CIFM03Lecture 12 18 Research on Failure Causes There is some reliable research culled from a very large sample of American software projects. One organisation started to survey software projects in 1994, and has amassed a file of 30,000 completed ones. Each year it analyses the current crop. 1

19. University of Sunderland CIFM03Lecture 12 19 Standish Group Chaos Report 16% success rate in 1994 in the States. 24% overall in 1998, but lower for Governmental projects. Total cost$75 billion. 28% success rate overall in 2000. Cost over-runs fell from 189% in 1994, to 69% in 1998, and only 45% in 2000. Http://www.softwaremag.com/archive/2001feb/CollaborativeMgt.html

20. University of Sunderland CIFM03Lecture 12 20 Categories Standish categorise projects into: –Successful –Challenged –Failed Most of us would call a ‘challenged’ project a failure.

21. University of Sunderland CIFM03Lecture 12 21 Standish Group Points out that projects should be limited to six months for six people… So does the Agile Alliance who advocate creation of software modules and very frequent validations of completed work. http://www.cio.com/archive/070101/secret_content.html

22. University of Sunderland CIFM03Lecture 12 22 Success Factors Standish now suggest the following success factors as a guide to good practice. Top of the pile is support from senior client management. Techniques like PRINCE 2 demand high level user involvement...

23. University of Sunderland CIFM03Lecture 12 23 Conclusions: Success Factors Executive Support18 User Involvement16 Experienced Proj. Manager14 Clear Business Objectives12 Minimised Scope10 Standard Software Infrastructure8 Firm Basic Requirements6 Formal Methodology6 Reliable Estimates5 Other Criteria5

24. University of Sunderland CIFM03Lecture 12 24 Whither Next? Standish suggest that the trend is to micro projects (or modular developments) that use only four people for four months. Or you can have massive upheaval projects that take forever, cost the earth the moon and the stars, and then fail…

25. University of Sunderland CIFM03Lecture 12 25 Risk Management Introduction –Will look at the management of risk during the project. –Risks vary in importance. –The importance of a particular risk depends on the project. –Risk Management should reduce the impact of a potential risk.

26. University of Sunderland CIFM03Lecture 12 26 Murphy’s Law ‘If something can go wrong, it will.’ The extended law is:-’If something cannot possibly go wrong, it will, and usually on a Monday.’

27. University of Sunderland CIFM03Lecture 12 27 Risk Categories Project Risk Types –Those caused by the inherent difficulties of estimation. –Those due to assumptions made during the planning process. –Those arising from unforeseen events.

28. University of Sunderland CIFM03Lecture 12 28 Risk Categories Estimation Errors Planning Errors Eventualities

29. University of Sunderland CIFM03Lecture 12 29 Managing Risk There are various models of risk management. They are generally similar, and identify two main elements:- –Risk identification –Risk management A popular model is the Boehm Risk Engineering Model.

30. University of Sunderland CIFM03Lecture 12 30 Managing Risk From Boehm: Tutorial on software risk management IEEE Computer Society 1989

31. University of Sunderland CIFM03Lecture 12 31 Reducing Risks There are five broad categories for risk reduction –Hazard Prevention –Likelihood Reduction –Risk Reduction –Risk Transfer –Contingency Planning

32. University of Sunderland CIFM03Lecture 12 32 Risk Identification Identification of hazards that may affect a project must be the first steps in a risk assessment A hazard is an event that if it occurs may adversely affect the project

33. University of Sunderland CIFM03Lecture 12 33 Risk Identification Checklists are often used to help in identifying hazards Knowledge-based software is also available to help with the task of hazard identification

34. University of Sunderland CIFM03Lecture 12 34 Risk Identification Various categories of risk factors will need to be considered. For software:- –Application factors –Staff factors –Project Factors –Project Methods

35. University of Sunderland CIFM03Lecture 12 35 Risk Identification –Hardware / Software Factors –System Changeover Factor –Supplier Factors –Environmental and Social Factors –Health and Safety Factors

36. University of Sunderland CIFM03Lecture 12 36 Risk Analysis Once identified, risks should be assessed for their possible affect on the project The level of importance of a risk must also be established This is often done by assessing the risk value

37. University of Sunderland CIFM03Lecture 12 37 Risk Analysis Risk impact is estimated in monetary terms Risk likelihood is assessed as a probability (say 1-10) Risk exposure therefore is an expected cost Ranking schemes can be used to assess impact and likelihood

38. University of Sunderland CIFM03Lecture 12 38 Risk Ranking Table Hazard ChanceImpact Exposure 1.Changes to the requirements 1 8 8 specification during coding 2.Specification takes longer than 3 7 21 expected 3.Staff sickness affecting 5 7 35 critical path activities 4.Staff sickness affecting 10 3 30 non-critical activities

39. University of Sunderland CIFM03Lecture 12 39 Risk Analysis Managing risk involves the use of two strategies: –Reducing the risk exposure –Drawing up contingency plans.

40. University of Sunderland CIFM03Lecture 12 40 Other Factors Other factors should be taken into account when prioritising risk management:- –Confidence of risk assessment –The number of risks –Cost of action