2. UFCE8V-20-3 Information Systems Development SHAPE Hong Kong 2010/11 Lecture 6 : Methodologies – Making the right choice

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

4. Project Management: Content Control Process the substance of the changes introduced, whether this is a computerise management IS or a new factory building or revised payment system 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 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 The Traditional View:

5. Project Management: revealing the omissions skills in dealing with human factors or behavioural issues are acknowledged this model assumes an unfolding in a logically sequenced manner: 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 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 WATERFALL MODEL 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

6. 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? Project Management: Structured Development rational models: WATERFALL MODEL Structured Rapid Prototyping (The Spiral Model of Systems Development)

7. Systems Development is about change Systems Development, though, is usually a project, a change project, and thus methodologies need some project management perspective... What is change management about, then? UFCE8V-20-3 Information Systems Development SHAPE 2010/11

8. 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. A metaphor of a change project: a ship’s journey UFCE8V-20-3 Information Systems Development SHAPE 2010/11

9. It has to be clear why we are taking this trip (the idea and its context). Charles Darwin’s Voyage on HMS Beagle Managing the success of a project: a ship’s journey 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). UFCE8V-20-3 Information Systems Development SHAPE 2010/11

10. 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). 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? Managing the success of a project: a ship’s journey 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).

11. Change Culture: New Technologies 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 PARADOX: 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 SPONSORSHIP OF A CHANGE: UFCE8V-20-3 Information Systems Development SHAPE 2010/11

12. Participative Project Management: But the understanding of what “ownership” really means is a problem Ownership is the key word 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. 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 change management is thought to be the way forward - to increase user involvement, from being subordinate effective

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

14. Participative IS Development: 1. people-focussed – individuals and their personalities, preferences or age 2. system-focussed – user-friendliness, complexity, ergonomics or access 3. organisation-focussed – lack of fit between system and organisational context giving rise to conflicts of responsibilities when traditional working cultures need to be changed 4. 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 Broad types of Resistance to change 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 UFCE8V-20-3 Information Systems Development SHAPE 2010/11

15. 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” UFCE8V-20-3 Information Systems Development SHAPE 2010/11

16. This is, of course, still: the change agent will need: negotiating skills selling skills ability to manipulate the perception of the context legitimise change proposals whilst maintaining the rationality of change through logically phased and visible participation (the rational-linear model) signalling a “counter-culture” with a new “dominant logic” can be through the use of established organisational rituals and appropriation of organisational symbols manipulation of the views of organisational members and establishment of the “unfolding logic” of change through management of meaning 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 Change Culture: in general UFCE8V-20-3 Information Systems Development SHAPE 2010/11

17. 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 Needs to encompass the establishment of three unfolding logics: problem solving establishing ownership establishing legitimacy BUT Managing the success of a project: a ship’s journey UFCE8V-20-3 Information Systems Development SHAPE 2010/11

18. Adopting a methodology in practice: who makes the choice 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. IS development may be seen as a technical issue so “technicians” make the decision 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! UFCE8V-20-3 Information Systems Development SHAPE 2010/11

19. 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 the best methodology? “a” best way - not “the” best way because there are always trade-offs between quality, quantity, skill levels, reliability, generality UFCE8V-20-3 Information Systems Development SHAPE 2010/11

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

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

22. 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 interviewing users (ask for requirements) prototype or evolutionary approach LOW HIGH UNCERTAINTY synthesis from characteristics of existing system