UFCE8V-20-3 Information Systems Development SHAPE Hong Kong 2010/11

1. UFCE8V-20-3Information Systems DevelopmentSHAPE Hong Kong 2010/11 Lecture 19 : Methodologies – Making the right choice

2. ISD Methodologies: Making the right choice Evaluating Information Systems Development methodologies has been taking place for at least 25 years in August 1983 there was a meeting in Minnesota of the IFIP (International Federation for Information Processing) WG 8.2: to present a multi-perspective view on information systems function and its development Bemelmans, TMA (1984) - Beyond Productivity: Information systems for organizational effectiveness Need contingency frameworks - NO “one best method” Broadly define where and for which purposes the methodology is relevant and then critique them after in-depth study Systems Development, though, is usually a project, a change project, and thus methodologies need some project management perspective – but aren’t ONLY that

3. the substance of the changes introduced, whether this is a computerise management IS or a new factory building or revised payment system defining outcomes and the necessary activities along the way, monitoring activity and progress, and taking remedial action to minimise deviations from the planned project life cycle in public, the rationality of change has to be maintained through logically phased and visible participation (the rational-linear model) but behind the scenes other activities may also be necessary Project Management: The Traditional View: Content Control Process

4. The conceptualisation of the SDLC as an essentially linear process works reasonably well with hard and specific requirements of applications such as financial accounting and stock control WATERFALL MODEL Project Management: revealing the omissions skills in dealing with human factors or behavioural issues are acknowledged but tend to be just another item on the list (often the last item) subordinated to the more important and much broader range of issues concerned with project planning and control tools and techniques this model assumes an unfolding in a logically sequenced manner: • solutions not identified until problems clearly defined • an effective solution not selected until various options systematically compared • implementation does not begin until there is agreement on the solution the rational-linear model

5. WATERFALL MODEL Project Management: Structured Development rational models: The Waterfall Model is very amenable to Project Management: scheduling: it is more straightforward as one phase leads to the next and there is no retreating, no looping, no “unknown” cycles. For SRP the length of “Prototype iteration” can be a problem – how many iterations? How long is each? Do they get shorter or longer as the iteration number increases? Structured Rapid Prototyping (The Spiral Model of Systems Development)

6. Systems Development, though, is usually a project, a change project, and thus methodologies need some project management perspective ... Systems Development is about change What is change management about, then?

7. A metaphor of a change project: a ship’s journey Let’s look at the organisation of the change process in using the story telling metaphor. The theme that we will use is the proposal to embark on a long journey by ship, say from Bristol to Ecuador. Clearly, this is a project and involves change. While preparing to embark on the challenging voyage, and when actually on the voyage, one needs to do certain things to improve the chances of success – to organise the change process, to manage and ensure success of the project.

8. Charles Darwin’s Voyage on HMS Beagle Managing the success of a project: a ship’s journey • It has to be clear why we are taking this trip (the idea and its context). • Next, one needs to understand what one intends to accomplish (define the change initiative). • Have an idea of what the weather will be like on the journey (evaluate the climate for change). • Prior to departure, have a set of accurate charts and sailing plans to overcome obstacles (rocks, South America or pirates) (develop a change plan).

9. Managing the success of a project: a ship’s journey • Line up a powerful and benevolent sponsor to pay for it and do the background “stage setting - the publicity and politics (find and cultivate a sponsor). • Work with the crew to clarify roles, goals and expectations (prepare the target audience, the recipients of the change). • Make sure the ship is capable of accomplishing the task and that the route chosen (given storms and bad weather) (create the cultural fit – making the change last). • Make sure the crew are committed, competent and share the same goal (develop and choose a change leader team). • Create small wins for motivation - specific milestones to provide feedback on how well and how fast one is sailing toward the objective. • Let the sponsor know how well your doing; share this with the crew and learn from the suggestions of the crew (constantly and strategically communicate the change). • Time passes: monitor progress; still going in the right direction or blown off course? Crew morale? Route and plan accommodating change? (measure progress of the change effort). • At the end, an after-action review: (integrate lessons learned). 1. What did we set out to do? 2. What actually happened? 3. Why did it happen? 4. What are we going to do next time?

10. Change Culture: New Technologies SPONSORSHIP OF A CHANGE: THE PARADOX: The higher the organisational level at which managers define a problem or a need, the greater the probability of successful sponsorship and thus initiation of the change The closer the definition and solution of problems or needs are to end-users, the greater the probability of success (effective use of the new system) There is a simultaneous need to sell the case for new technology to top management and the users in the organisation – the need to develop “ownership” Leonard-Barton, D. & Kraus, W.A. (1986) Implementing new technology. In: Planning and Managing Change, B. Mayon-White (ed.), Chapter 19, pp.227-238

11. Much of the ground-breaking research on participation was done by Coch and French in the 1940s at the Harwood Manufacturing Corporation in Marion, Virginia making pyjamas Participative Project Management: participative change management is thought to be the way forward - to increase user involvement, from being subordinate effective Ownership is the key word But the understanding of what “ownership” really means is a problem Changes to jobs and work methods were usually resisted but “representation” or more full “participation” in redesign and calculation of new time standards increased efficiency and reduced conflicts.

12. Managing the success of a project: a ship’s journey • find and cultivate a sponsor • prepare the target audience, the recipients of the change creating a sense of ownership in the journey • create the cultural fit – making the change last • develop and choose a change leader team • create small wins for motivation • constantly and strategically communicate the change • measure progress of the change effort • integrate lessons learned

13. Participative IS Development: Broad types of Resistance to change • people-focussed – individuals and their personalities, preferences or age • system-focussed – user-friendliness, complexity, ergonomics or access • organisation-focussed – lack of fit between system and organisational context giving rise to conflicts of responsibilities when traditional working cultures need to be changed • politics-focussed – friction between the system and the context which changes the distribution of power, often brought about because of the changing ownership and access patterns to information which affects decision-making this will only frame the explanations for resistance, not answer the resistance however, practical implications flow from this analysis: person- or system-based resistance would lead to better training, better staff, better design and better designers organisational or political domains usually have complex solutions and obscure start points

14. Change Culture: in general change is as much about changing the world view (Weltanschauung) or organisational view as it is with changing: decision-making processes payment systems technologies organisation structures • This means establishing a third unfolding of logic: • problem solving • establishing ownership • establishing legitimacy change means challenging, questioning and breaking down the existing shared assumptions, or “interpretive schemes”, or “cognitive coping mechanisms”, held by the organisation’s members, in order to change attitudes and behaviour also signalling a “counter-culture” with a new “dominant logic”

15. Change Culture: in general signalling a “counter-culture” with a new “dominant logic” can be through the use of established organisational ritualsand appropriation of organisational symbols manipulation of the views of organisational members and establishment of the “unfolding logic” of change through management of meaning whilst maintaining the rationality of change through logically phased and visible participation (the rational-linear model) • the change agent will need: • negotiating skills • selling skills • ability to manipulate the perception of the context • legitimise change proposals This is, of course, still: building effective relationships and teams but with a eye towards building credibility and support rather than understanding and ownership of those affected by the changes

16. Managing the success of a project: a ship’s journey • Needs to encompass the establishment of three unfolding logics: • problem solving • establishing ownership • establishing legitimacy BUT • the rational-linear model has to be seen to be the one being pursued in its purity whilst at the same time probably significant, and unrevealed, backstaging is taking place: • wheeler-dealing • fixing • negotiating • coalition building • trading-off • this cannot be acknowledged otherwise it would damage the legitimacy of the change attempt and the individuals involved in it

17. Adopting a methodology in practice: who makes the choice IS development may be seen as a technical issue so “technicians” make the decision But, shouldn’t the adoption of an organisation’s IS development methodology be in the users’ and business managers’ hands, not in the IS/IT departments’ control? such decisions give IT professionals power in organisations whereas the users and business managers are the ones to make the investment in time, money, effort and business success as a result of IS developments. In most large organisations, though, the decision will be made by the corporate IS team, thus disenfranchising the business managers, the users and most of the IS workers!

18. the best methodology? the methodology should embody a best way of developing systems whether this is true is rarely asked the more usual questions are: • whether it fits in with the organisation’s way of working • whether it specifies what deliverables are required at the end of each stage • whether it enables better control and improved productivity • whether it supports a particular set of CASE tools “a” best way - not“the” best way because there are always trade-offs between quality, quantity, skill levels, reliability, generality

19. Avison & Fitzgerald address many of these issues in their book: Information Systems Development: Methodologies, Techniques and Tools. 4th Edition (2006). BUT Any comparison will be subjective DANGER setting up a framework may identify a set of idealised “features” then the follow up check list correctly scores your methodology the highest! Like selling cars...

20. Why compare methodologies? Academic: better understanding of their nature; to be able to classify them Practical: to choose one (or part of one) for a particular application or an organisation as a whole Methodologies vary greatly in what you get: • details of every stage in the life cycle or vague outline principles • coverage may vary from more strategic to the details of implementation • problem-specific or all-encompassing, general-purpose methodology • may be useable by anyone (including users) or only by highly trained specialists • require a big team to operate it sensibly or may not specify tasks at all • may or may not include CASE tools

21. Davis’ contingency approach to selecting an appropriate methodology (principally directed towards requirements phase): Measure the level of uncertainty in a system: 1. System complexity or ill-structuredness 2. The state of flux of the system 3. The user component of the system, for example, the number of people affected and their skill level 4. The level of skill and experience of the analysts once the level of uncertainty has been determined, the appropriate approach to determining the requirements can be made prototype or evolutionary approach HIGH synthesis from characteristics of existing system UNCERTAINTY LOW interviewing users (ask for requirements)