In this essay I intend to introduce the case study that we have been provided with and briefly summarise it. I will analyse the problems and the issues to allow me to determine what needs to be taken into account in terms of designing a new system for the organisation at hand. I plan on evaluating exactly what should be taken into account when designing a new system that has the purpose of completely satisfying the requirements of the users as well as the organisation as a whole and will clearly assist the employees with their jobs. I will then move onto recommending a systems development methodology that I think would be appropriate for the organisation while giving support for my methodology of choice. I will also attempt to take gender relations into account with this discussion.
The case study describes an organisation that is seen as a large utility with thousands of employees that serve millions of customers. The new system they plan to design is known as the Dispatch system. Up until the 1980's the organisation mainly used mainframes, however by the early 1990's, PC's on a large scale began to make an entrance. Much of the customer-related service work was not done by the Utility, but carried out by outside contractors. The Utility would send out work orders to the contractors and the purpose of the Dispatch system was to automatically download theinformation required by the contractors. There are two main employee groups within the Utility, the Dispatch employees and Information Systems (IS) employees.
Large tension and conflict exists between these two groups and they have an 'us against them' view of each other to a large extent. A figure referred to as DM in the case study became the Dispatch manager and the Dispatch staff saw him as their main weapon as far as their on-going conflicts with IS staff were concerned. DM was viewed as a problem-solver and had experience in PC-application development, where as IS had more mainframe-oriented experience. A figure known as IS3 within the case study was the project leader for the development of the new system and he and DM had several continuing conflicts over the approaches that should be used to develop the new system.
(Halonen, Clement, 1998)I will now discuss some of the aspects that must be taken into account when developing a system within a context of a techno-organisational change. One aspect is testing. This is because an un-tested system can lead to various bugs and problems occurring after the system has already has been implemented which is usually too late. This is why testing needs to be introduced during the development stage.
"All software has to undergo a rigorous testing process before it can be released. When a new system is developed, the testing process may typically consist of five stages:" (Heathcote, 1998:336). Another aspect to take into account is prototyping. A prototype is basically a smaller version of the main system to be developed, which is given to the users to try and test whether it is a suitable system or not. "This (prototyping) gives the user a chance to experience the 'look and feel' of the input process and suggest alterations before going any further.
The earlier the user is involved, the easier it will be to make changes. (Heathcote, 1998:212) One thing mentioned in the above quote, user-involvement, is an extremely important point that I will discuss further, later in this essay.Designers should also take into account how the system they are developing is going to change the organisation's work procedure. For example, if it is going to dramatically change the way work is done then perhaps documentation such as user manuals should be produced, where as if it will only slightly alter the work procedure then time need not be spent producing such manuals.
Training is something else that should be carefully considered when developing a new system. This is because if unequal or insufficient training is given, then this can result in the users being unable to use the system efficiently."Training staff in the use of new technology is crucial to the success of any computer system. Unless staff at all levels of the organisation know how to use the technology effectively, investment in a computer system can be a waste of money." (Heathcote, 1998:265) Another aspect that should be taken into account is user requirements. This is because the designers must know clearly and fully exactly what the requirements of the system they are developing are, as this will enable them to create a system that completely satisfies the user's needs.
The user expectations of the system must also be realistic and they must only be expecting the system to be able to do things that are actually possible for it to do. A final aspect to take into account is whether the designers are happy to carry out the development of a new system.The reason being that if they are unhappy, and are perhaps put into a situation where they have to develop one, then the system they produce may be ineffective at fulfilling its purpose and meeting the requirements of the users. In relation to the case study the designers would have been the IS staff, the end-users would have been the Dispatch staff and the directors would have been the people managing both employee groups.
A final aspect that designers should take into account is the different views that users have of a stable system. "For IS a 'stable' system was one which had manageable well-structured code. For Dispatch, s table system, was one which performed well as a tool-at-hand for Dispatch workers, and this stability took procedure over the appearance of the program code." (Clement, Halonen: 1998:7)I now plan to look at what needs to be done in order to encompass the needs, concerns and experience of the intended users and user groups. Different types of knowledge possessed by different types of employees should be shared when ever possible during the development stage of a system. For example an end-user employee who has tacit knowledge can share this with a programmer or designer who has background knowledge and this will aid in the systems design.
"Tacit knowledge may be reflected through personal exchanges between colleagues in the form of emails, memos, personal notes" (Bandyo-padhyay, 2002:135) "Whilst the availability of background knowledge depends on the ability of a leader to share it with others."(Bandyo-padhyay, 2002:135) Another thing that should be done is a thorough requirements analysis to be carried out by the system designers. This will aid them in identifying the end-user requirements of the system and will give them targets to try and meet during the development. The development of the system should also have a collaborative effort behind it from all of the employees involved, from the directors, to the designers, to the end-users. This will avoid the system being designed from only one point of view, for example, the designers, and will stop the system from not being effective from other's point of view.I now intend to suggest a systems methodology that I think would be most appropriate for the Utility for the development of their Dispatch system.
However, before I do so, I will first talk about the general difference between hard and soft approaches. Hard approaches focus on the technological aspects and regard the social aspects as less important. Therefore, they don't take the user issues into account as much as they do the technical issues. "Hard approaches focus on the technology and the application, and ignore the people." (Burton, 1992:71-72). A soft systems approach will concentrate more on the users then the technology and views the social aspects as of higher importance than the technical aspects.
The user's needs and issues and focused on and held above everything else. "Later on soft systems methodology was introduced which took account of multiple perceptions of a problem by users with different needs." (Bandyo-padhyay, 2000:212)
